mirror of
https://github.com/autc04/Retro68.git
synced 2024-10-24 15:24:56 +00:00
30173 lines
1.1 MiB
30173 lines
1.1 MiB
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
|
|
"http://www.w3.org/TR/html4/strict.dtd">
|
|
<html>
|
|
<head>
|
|
<title>C++ Standard Library Active Issues List</title>
|
|
<style type="text/css">
|
|
p {text-align:justify}
|
|
li {text-align:justify}
|
|
blockquote.note
|
|
{
|
|
background-color:#E0E0E0;
|
|
padding-left: 15px;
|
|
padding-right: 15px;
|
|
padding-top: 1px;
|
|
padding-bottom: 1px;
|
|
}
|
|
ins {background-color:#A0FFA0}
|
|
del {background-color:#FFA0A0}
|
|
</style>
|
|
</head>
|
|
<body>
|
|
<table>
|
|
<tr>
|
|
<td align="left">Doc. no.</td>
|
|
<td align="left">N4484</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="left">Date:</td>
|
|
<td align="left">2015-05-23</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="left">Project:</td>
|
|
<td align="left">Programming Language C++</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="left">Reply to:</td>
|
|
<td align="left">Marshall Clow <<a href="mailto:lwgchair@gmail.com">lwgchair@gmail.com</a>></td>
|
|
</tr>
|
|
</table>
|
|
<h1>C++ Standard Library Active Issues List (Revision R93)</h1>
|
|
<p><p>Revised 2015-05-23 at 15:05:40 UTC</p>
|
|
</p>
|
|
<p>Reference ISO/IEC IS 14882:2014(E)</p>
|
|
<p>Also see:</p>
|
|
<ul>
|
|
<li><a href="lwg-toc.html">Table of Contents</a> for all library issues.</li>
|
|
<li><a href="lwg-index.html">Index by Section</a> for all library issues.</li>
|
|
<li><a href="lwg-status.html">Index by Status</a> for all library issues.</li>
|
|
<li><a href="lwg-defects.html">Library Defect Reports List</a></li>
|
|
<li><a href="lwg-closed.html">Library Closed Issues List</a></li>
|
|
</ul>
|
|
<p>The purpose of this document is to record the status of issues
|
|
which have come before the Library Working Group (LWG) of the INCITS PL22.16
|
|
and ISO WG21 C++ Standards Committee. Issues represent
|
|
potential defects in the ISO/IEC IS 14882:2014(E) document.
|
|
</p>
|
|
|
|
<p>This document contains only library issues which are actively being
|
|
considered by the Library Working Group, i.e., issues which have a
|
|
status of <a href="lwg-active.html#New">New</a>, <a href="lwg-active.html#Open">Open</a>,
|
|
<a href="lwg-active.html#Ready">Ready</a>, or <a href="lwg-active.html#Review">Review</a>.
|
|
See <a href="lwg-defects.html">Library Defect Reports List</a> for issues considered defects
|
|
and <a href="lwg-closed.html">Library Closed Issues List</a> for issues considered closed.</p>
|
|
|
|
<p>The issues in these lists are not necessarily formal ISO Defect
|
|
Reports (DR's). While some issues will eventually be elevated to
|
|
official Defect Report status, other issues will be disposed of in
|
|
other ways. See <a href="#Status">Issue Status</a>.</p>
|
|
|
|
<p>Prior to Revision 14, library issues lists existed in two slightly
|
|
different versions; a Committee Version and a Public
|
|
Version. Beginning with Revision 14 the two versions were combined
|
|
into a single version.</p>
|
|
|
|
<p>This document includes <i>[bracketed italicized notes]</i> as a
|
|
reminder to the LWG of current progress on issues. Such notes are
|
|
strictly unofficial and should be read with caution as they may be
|
|
incomplete or incorrect. Be aware that LWG support for a particular
|
|
resolution can quickly change if new viewpoints or killer examples are
|
|
presented in subsequent discussions.</p>
|
|
|
|
<p>For the most current official version of this document see
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/">http://www.open-std.org/jtc1/sc22/wg21/</a>.
|
|
Requests for further information about this document should include
|
|
the document number above, reference ISO/IEC 14882:2014(E), and be
|
|
submitted to Information Technology Industry Council (ITI), 1250 Eye
|
|
Street NW, Washington, DC 20005.</p>
|
|
|
|
<p>Public information as to how to obtain a copy of the C++ Standard,
|
|
join the standards committee, submit an issue, or comment on an issue
|
|
can be found in the comp.std.c++ FAQ.
|
|
</p>
|
|
|
|
<p><a name="submit_issue"></a><b>How to submit an issue</b></p>
|
|
|
|
<ol style="list-style-type:upper-alpha">
|
|
<li><a name="submit_issue_A"></a>
|
|
Mail your issue to the author of this list.
|
|
</li>
|
|
<li><a name="submit_issue_B"></a>
|
|
Specify a short descriptive title. If you fail to do so, the subject line of your
|
|
mail will be used as the issue title.
|
|
</li>
|
|
<li><a name="submit_issue_C"></a>
|
|
If the "From" on your email is not the name you wish to appear as issue submitter,
|
|
then specify issue submitter.
|
|
</li>
|
|
<li><a name="submit_issue_D"></a>
|
|
Provide a brief discussion of the problem you wish to correct. Refer to the latest
|
|
working draft or standard using [section.tag] and paragraph numbers where appropriate.
|
|
</li>
|
|
<li><a name="submit_issue_E"></a>
|
|
Provide proposed wording. This should indicate exactly how you want the standard
|
|
to be changed. General solution statements belong in the discussion area. This
|
|
area contains very clear and specific directions on how to modify the current
|
|
draft. If you are not sure how to word a solution, you may omit this part.
|
|
But your chances of a successful issue greatly increase if you attempt wording.
|
|
</li>
|
|
<li><a name="submit_issue_F"></a>
|
|
It is not necessary for you to use html markup. However, if you want to, you can
|
|
<ins><ins>insert text like this</ins></ins> and <del><del>delete text like
|
|
this</del></del>. The only strict requirement is to communicate clearly to
|
|
the list maintainer exactly how you want your issue to look.
|
|
</li>
|
|
<li><a name="submit_issue_G"></a>
|
|
It is not necessary for you to specify other html font/formatting
|
|
mark-up, but if you do the list maintainer will attempt to respect your
|
|
formatting wishes (as described by html markup, or other common idioms).
|
|
</li>
|
|
<li><a name="submit_issue_H"></a>
|
|
It is not necessary for you to specify open date or last modified date (the date
|
|
of your mail will be used).
|
|
</li>
|
|
<li><a name="submit_issue_I"></a>
|
|
It is not necessary for you to cross reference other issues, but you can if you
|
|
like. You do not need to form the hyperlinks when you do, the list maintainer will
|
|
take care of that.
|
|
</li>
|
|
<li><a name="submit_issue_J"></a>
|
|
One issue per email is best.
|
|
</li>
|
|
<li><a name="submit_issue_K"></a>
|
|
Between the time you submit the issue, and the next mailing deadline
|
|
(date at the top of the Revision History), you <em>own</em> this issue.
|
|
You control the content, the stuff that is right, the stuff that is
|
|
wrong, the format, the misspellings, etc. You can even make the issue
|
|
disappear if you want. Just let the list maintainer know how you want
|
|
it to look, and he will try his best to accommodate you. After the
|
|
issue appears in an official mailing, you no longer enjoy exclusive
|
|
ownership of it.
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
<h2>Revision History</h2>
|
|
<ul>
|
|
<li>R93: 2014-05-22 2015 post-Lenexa mailing<ul>
|
|
<li><b>Summary:</b><ul>
|
|
<li>256 open issues, down by 36.</li>
|
|
<li>1770 closed issues, up by 48.</li>
|
|
<li>2026 issues total, up by 12.</li>
|
|
</ul></li>
|
|
<li><b>Details:</b><ul>
|
|
<li>Added the following 2 Ready issues: <a href="lwg-active.html#2492">2492</a>, <a href="lwg-active.html#2494">2494</a>.</li>
|
|
<li>Added the following 10 New issues: <a href="lwg-active.html#2493">2493</a>, <a href="lwg-active.html#2495">2495</a>, <a href="lwg-active.html#2496">2496</a>, <a href="lwg-active.html#2497">2497</a>, <a href="lwg-active.html#2498">2498</a>, <a href="lwg-active.html#2499">2499</a>, <a href="lwg-active.html#2500">2500</a>, <a href="lwg-active.html#2501">2501</a>, <a href="lwg-active.html#2502">2502</a>, <a href="lwg-active.html#2503">2503</a>.</li>
|
|
<li>Changed the following 2 issues to Ready (from Review): <a href="lwg-active.html#2111">2111</a>, <a href="lwg-active.html#2380">2380</a>.</li>
|
|
<li>Changed the following 20 issues to Ready (from New): <a href="lwg-active.html#2244">2244</a>, <a href="lwg-active.html#2250">2250</a>, <a href="lwg-active.html#2259">2259</a>, <a href="lwg-active.html#2336">2336</a>, <a href="lwg-active.html#2353">2353</a>, <a href="lwg-active.html#2367">2367</a>, <a href="lwg-active.html#2384">2384</a>, <a href="lwg-active.html#2385">2385</a>, <a href="lwg-active.html#2435">2435</a>, <a href="lwg-active.html#2462">2462</a>, <a href="lwg-active.html#2466">2466</a>, <a href="lwg-active.html#2473">2473</a>, <a href="lwg-active.html#2476">2476</a>, <a href="lwg-active.html#2477">2477</a>, <a href="lwg-active.html#2483">2483</a>, <a href="lwg-active.html#2484">2484</a>, <a href="lwg-active.html#2485">2485</a>, <a href="lwg-active.html#2486">2486</a>, <a href="lwg-active.html#2487">2487</a>, <a href="lwg-active.html#2489">2489</a>.</li>
|
|
<li>Changed the following 12 issues to Ready (from Open): <a href="lwg-active.html#1169">1169</a>, <a href="lwg-active.html#2072">2072</a>, <a href="lwg-active.html#2101">2101</a>, <a href="lwg-active.html#2119">2119</a>, <a href="lwg-active.html#2127">2127</a>, <a href="lwg-active.html#2133">2133</a>, <a href="lwg-active.html#2156">2156</a>, <a href="lwg-active.html#2181">2181</a>, <a href="lwg-active.html#2218">2218</a>, <a href="lwg-active.html#2219">2219</a>, <a href="lwg-active.html#2447">2447</a>, <a href="lwg-active.html#2469">2469</a>.</li>
|
|
<li>Changed the following issue to Tentatively Ready (from Open): <a href="lwg-active.html#2224">2224</a>.</li>
|
|
<li>Changed the following issue to Review (from New): <a href="lwg-active.html#2296">2296</a>.</li>
|
|
<li>Changed the following issue to Review (from Open): <a href="lwg-active.html#2328">2328</a>.</li>
|
|
<li>Changed the following 11 issues to Open (from New): <a href="lwg-active.html#2262">2262</a>, <a href="lwg-active.html#2289">2289</a>, <a href="lwg-active.html#2338">2338</a>, <a href="lwg-active.html#2348">2348</a>, <a href="lwg-active.html#2349">2349</a>, <a href="lwg-active.html#2370">2370</a>, <a href="lwg-active.html#2398">2398</a>, <a href="lwg-active.html#2402">2402</a>, <a href="lwg-active.html#2422">2422</a>, <a href="lwg-active.html#2450">2450</a>, <a href="lwg-active.html#2456">2456</a>.</li>
|
|
<li>Changed the following 8 issues to Open (from SG1): <a href="lwg-active.html#2245">2245</a>, <a href="lwg-active.html#2265">2265</a>, <a href="lwg-active.html#2276">2276</a>, <a href="lwg-active.html#2309">2309</a>, <a href="lwg-active.html#2363">2363</a>, <a href="lwg-active.html#2379">2379</a>, <a href="lwg-active.html#2426">2426</a>, <a href="lwg-active.html#2441">2441</a>.</li>
|
|
<li>Changed the following issue to LEWG (from New): <a href="lwg-active.html#2372">2372</a>.</li>
|
|
<li>Changed the following issue to EWG (from New): <a href="lwg-active.html#2432">2432</a>.</li>
|
|
<li>Changed the following issue to Deferred (from Open): <a href="lwg-active.html#2202">2202</a>.</li>
|
|
<li>Changed the following 14 issues to WP (from Ready): <a href="lwg-defects.html#2160">2160</a>, <a href="lwg-defects.html#2168">2168</a>, <a href="lwg-defects.html#2364">2364</a>, <a href="lwg-defects.html#2403">2403</a>, <a href="lwg-defects.html#2406">2406</a>, <a href="lwg-defects.html#2411">2411</a>, <a href="lwg-defects.html#2425">2425</a>, <a href="lwg-defects.html#2427">2427</a>, <a href="lwg-defects.html#2428">2428</a>, <a href="lwg-defects.html#2433">2433</a>, <a href="lwg-defects.html#2434">2434</a>, <a href="lwg-defects.html#2438">2438</a>, <a href="lwg-defects.html#2439">2439</a>, <a href="lwg-defects.html#2440">2440</a>.</li>
|
|
<li>Changed the following 18 issues to WP (from Tentatively Ready): <a href="lwg-defects.html#2059">2059</a>, <a href="lwg-defects.html#2076">2076</a>, <a href="lwg-defects.html#2239">2239</a>, <a href="lwg-defects.html#2369">2369</a>, <a href="lwg-defects.html#2378">2378</a>, <a href="lwg-defects.html#2410">2410</a>, <a href="lwg-defects.html#2415">2415</a>, <a href="lwg-defects.html#2418">2418</a>, <a href="lwg-defects.html#2437">2437</a>, <a href="lwg-defects.html#2448">2448</a>, <a href="lwg-defects.html#2454">2454</a>, <a href="lwg-defects.html#2455">2455</a>, <a href="lwg-defects.html#2458">2458</a>, <a href="lwg-defects.html#2459">2459</a>, <a href="lwg-defects.html#2463">2463</a>, <a href="lwg-defects.html#2467">2467</a>, <a href="lwg-defects.html#2470">2470</a>, <a href="lwg-defects.html#2482">2482</a>.</li>
|
|
<li>Changed the following 3 issues to WP (from New): <a href="lwg-defects.html#2420">2420</a>, <a href="lwg-defects.html#2464">2464</a>, <a href="lwg-defects.html#2488">2488</a>.</li>
|
|
<li>Changed the following issue to WP (from Open): <a href="lwg-defects.html#2063">2063</a>.</li>
|
|
<li>Changed the following 2 issues to WP (from SG1): <a href="lwg-defects.html#2407">2407</a>, <a href="lwg-defects.html#2442">2442</a>.</li>
|
|
<li>Changed the following issue to Resolved (from Review): <a href="lwg-defects.html#2228">2228</a>.</li>
|
|
<li>Changed the following 3 issues to Resolved (from Open): <a href="lwg-defects.html#1526">1526</a>, <a href="lwg-defects.html#2274">2274</a>, <a href="lwg-defects.html#2397">2397</a>.</li>
|
|
<li>Changed the following 5 issues to NAD (from New): <a href="lwg-closed.html#2079">2079</a>, <a href="lwg-closed.html#2251">2251</a>, <a href="lwg-closed.html#2351">2351</a>, <a href="lwg-closed.html#2373">2373</a>, <a href="lwg-closed.html#2386">2386</a>.</li>
|
|
<li>Changed the following issue to NAD (from Open): <a href="lwg-closed.html#2388">2388</a>.</li>
|
|
</ul></li>
|
|
</ul>
|
|
</li>
|
|
<li>R92:
|
|
2015-04-09 pre-Lenexa mailing
|
|
<ul>
|
|
<li><b>Summary:</b><ul>
|
|
<li>292 open issues, up by 33.</li>
|
|
<li>1722 closed issues, up by 0.</li>
|
|
<li>2014 issues total, up by 33.</li>
|
|
</ul></li>
|
|
<li><b>Details:</b><ul>
|
|
<li>Added the following 5 Tentatively Ready issues: <a href="lwg-active.html#2459">2459</a>, <a href="lwg-active.html#2463">2463</a>, <a href="lwg-active.html#2467">2467</a>, <a href="lwg-active.html#2470">2470</a>, <a href="lwg-active.html#2482">2482</a>.</li>
|
|
<li>Added the following 27 New issues: <a href="lwg-active.html#2460">2460</a>, <a href="lwg-active.html#2461">2461</a>, <a href="lwg-active.html#2462">2462</a>, <a href="lwg-active.html#2464">2464</a>, <a href="lwg-active.html#2465">2465</a>, <a href="lwg-active.html#2466">2466</a>, <a href="lwg-active.html#2468">2468</a>, <a href="lwg-active.html#2471">2471</a>, <a href="lwg-active.html#2472">2472</a>, <a href="lwg-active.html#2473">2473</a>, <a href="lwg-active.html#2474">2474</a>, <a href="lwg-active.html#2475">2475</a>, <a href="lwg-active.html#2476">2476</a>, <a href="lwg-active.html#2477">2477</a>, <a href="lwg-active.html#2478">2478</a>, <a href="lwg-active.html#2479">2479</a>, <a href="lwg-active.html#2480">2480</a>, <a href="lwg-active.html#2481">2481</a>, <a href="lwg-active.html#2483">2483</a>, <a href="lwg-active.html#2484">2484</a>, <a href="lwg-active.html#2485">2485</a>, <a href="lwg-active.html#2486">2486</a>, <a href="lwg-active.html#2487">2487</a>, <a href="lwg-active.html#2488">2488</a>, <a href="lwg-active.html#2489">2489</a>, <a href="lwg-active.html#2490">2490</a>, <a href="lwg-active.html#2491">2491</a>.</li>
|
|
<li>Added the following Open issue: <a href="lwg-active.html#2469">2469</a>.</li>
|
|
<li>Changed the following issue to Tentatively Ready (from Review): <a href="lwg-active.html#2378">2378</a>.</li>
|
|
<li>Changed the following 11 issues to Tentatively Ready (from New): <a href="lwg-active.html#2076">2076</a>, <a href="lwg-active.html#2239">2239</a>, <a href="lwg-active.html#2369">2369</a>, <a href="lwg-active.html#2410">2410</a>, <a href="lwg-active.html#2415">2415</a>, <a href="lwg-active.html#2418">2418</a>, <a href="lwg-active.html#2437">2437</a>, <a href="lwg-active.html#2448">2448</a>, <a href="lwg-active.html#2454">2454</a>, <a href="lwg-active.html#2455">2455</a>, <a href="lwg-active.html#2458">2458</a>.</li>
|
|
<li>Changed the following issue to Tentatively Ready (from Open): <a href="lwg-active.html#2059">2059</a>.</li>
|
|
<li>Changed the following issue to Tentatively NAD (from New): <a href="lwg-active.html#2337">2337</a>.</li>
|
|
<li>Changed the following issue to Tentatively NAD (from Open): <a href="lwg-active.html#760">760</a>.</li>
|
|
<li>Changed the following 5 issues to Open (from New): <a href="lwg-active.html#2312">2312</a>, <a href="lwg-active.html#2388">2388</a>, <a href="lwg-active.html#2393">2393</a>, <a href="lwg-active.html#2444">2444</a>, <a href="lwg-active.html#2447">2447</a>.</li>
|
|
<li>Changed the following 4 issues to LEWG (from New): <a href="lwg-active.html#2391">2391</a>, <a href="lwg-active.html#2417">2417</a>, <a href="lwg-active.html#2436">2436</a>, <a href="lwg-active.html#2451">2451</a>.</li>
|
|
<li>Changed the following issue to EWG (from Open): <a href="lwg-active.html#2089">2089</a>.</li>
|
|
<li>Changed the following issue to Core (from New): <a href="lwg-active.html#2452">2452</a>.</li>
|
|
<li>Changed the following 13 issues to SG1 (from New): <a href="lwg-active.html#2236">2236</a>, <a href="lwg-active.html#2245">2245</a>, <a href="lwg-active.html#2265">2265</a>, <a href="lwg-active.html#2276">2276</a>, <a href="lwg-active.html#2309">2309</a>, <a href="lwg-active.html#2334">2334</a>, <a href="lwg-active.html#2363">2363</a>, <a href="lwg-active.html#2379">2379</a>, <a href="lwg-active.html#2407">2407</a>, <a href="lwg-active.html#2412">2412</a>, <a href="lwg-active.html#2426">2426</a>, <a href="lwg-active.html#2442">2442</a>, <a href="lwg-active.html#2445">2445</a>.</li>
|
|
<li>Changed the following issue to SG1 (from Open): <a href="lwg-active.html#2441">2441</a>.</li>
|
|
</ul></li>
|
|
</ul>
|
|
</li>
|
|
<li>R91:
|
|
2014-11-23 post-Urbana mailing
|
|
<ul>
|
|
<li><b>Summary:</b><ul>
|
|
<li>259 open issues, up by 32.</li>
|
|
<li>1722 closed issues, down by 20.</li>
|
|
<li>1981 issues total, up by 12.</li>
|
|
</ul></li>
|
|
<li><b>Details:</b><ul>
|
|
<li>Added the following 12 New issues: <a href="lwg-active.html#2447">2447</a>, <a href="lwg-defects.html#2448">2448</a>, <a href="lwg-active.html#2449">2449</a>, <a href="lwg-active.html#2450">2450</a>, <a href="lwg-active.html#2451">2451</a>, <a href="lwg-active.html#2452">2452</a>, <a href="lwg-active.html#2453">2453</a>, <a href="lwg-defects.html#2454">2454</a>, <a href="lwg-defects.html#2455">2455</a>, <a href="lwg-active.html#2456">2456</a>, <a href="lwg-active.html#2457">2457</a>, <a href="lwg-defects.html#2458">2458</a>.</li>
|
|
<li>Changed the following 2 issues to Ready (from Review): <a href="lwg-defects.html#2160">2160</a>, <a href="lwg-defects.html#2364">2364</a>.</li>
|
|
<li>Changed the following 11 issues to Ready (from New): <a href="lwg-defects.html#2403">2403</a>, <a href="lwg-defects.html#2406">2406</a>, <a href="lwg-defects.html#2411">2411</a>, <a href="lwg-defects.html#2425">2425</a>, <a href="lwg-defects.html#2427">2427</a>, <a href="lwg-defects.html#2428">2428</a>, <a href="lwg-defects.html#2433">2433</a>, <a href="lwg-defects.html#2434">2434</a>, <a href="lwg-defects.html#2438">2438</a>, <a href="lwg-defects.html#2439">2439</a>, <a href="lwg-defects.html#2440">2440</a>.</li>
|
|
<li>Changed the following issue to Ready (from Open): <a href="lwg-defects.html#2168">2168</a>.</li>
|
|
<li>Changed the following issue to Review (from New): <a href="lwg-active.html#2424">2424</a>.</li>
|
|
<li>Changed the following 5 issues to Open (from New): <a href="lwg-active.html#2307">2307</a>, <a href="lwg-active.html#2310">2310</a>, <a href="lwg-active.html#2383">2383</a>, <a href="lwg-active.html#2414">2414</a>, <a href="lwg-active.html#2441">2441</a>.</li>
|
|
<li>Changed the following 2 issues to Open (from NAD Future): <a href="lwg-active.html#760">760</a>, <a href="lwg-active.html#1173">1173</a>.</li>
|
|
<li>Changed the following 4 issues to LEWG (from New): <a href="lwg-active.html#2419">2419</a>, <a href="lwg-active.html#2430">2430</a>, <a href="lwg-active.html#2443">2443</a>, <a href="lwg-active.html#2446">2446</a>.</li>
|
|
<li>Changed the following 48 issues to LEWG (from NAD Future): <a href="lwg-active.html#255">255</a>, <a href="lwg-active.html#423">423</a>, <a href="lwg-active.html#484">484</a>, <a href="lwg-active.html#523">523</a>, <a href="lwg-active.html#532">532</a>, <a href="lwg-active.html#708">708</a>, <a href="lwg-active.html#839">839</a>, <a href="lwg-active.html#851">851</a>, <a href="lwg-active.html#877">877</a>, <a href="lwg-active.html#933">933</a>, <a href="lwg-active.html#935">935</a>, <a href="lwg-active.html#936">936</a>, <a href="lwg-active.html#961">961</a>, <a href="lwg-active.html#1025">1025</a>, <a href="lwg-active.html#1031">1031</a>, <a href="lwg-active.html#1041">1041</a>, <a href="lwg-active.html#1052">1052</a>, <a href="lwg-active.html#1053">1053</a>, <a href="lwg-active.html#1112">1112</a>, <a href="lwg-active.html#1120">1120</a>, <a href="lwg-active.html#1121">1121</a>, <a href="lwg-active.html#1150">1150</a>, <a href="lwg-active.html#1154">1154</a>, <a href="lwg-active.html#1184">1184</a>, <a href="lwg-active.html#1188">1188</a>, <a href="lwg-active.html#1201">1201</a>, <a href="lwg-active.html#1203">1203</a>, <a href="lwg-active.html#1217">1217</a>, <a href="lwg-active.html#1235">1235</a>, <a href="lwg-active.html#1238">1238</a>, <a href="lwg-active.html#1242">1242</a>, <a href="lwg-active.html#1282">1282</a>, <a href="lwg-active.html#1289">1289</a>, <a href="lwg-active.html#1317">1317</a>, <a href="lwg-active.html#1320">1320</a>, <a href="lwg-active.html#1396">1396</a>, <a href="lwg-active.html#1406">1406</a>, <a href="lwg-active.html#1422">1422</a>, <a href="lwg-active.html#1459">1459</a>, <a href="lwg-active.html#1484">1484</a>, <a href="lwg-active.html#1488">1488</a>, <a href="lwg-active.html#1493">1493</a>, <a href="lwg-active.html#1499">1499</a>, <a href="lwg-active.html#1521">1521</a>, <a href="lwg-active.html#2040">2040</a>, <a href="lwg-active.html#2055">2055</a>, <a href="lwg-active.html#2226">2226</a>, <a href="lwg-active.html#2232">2232</a>.</li>
|
|
<li>Changed the following 2 issues to Pending NAD (from Tentatively NAD): <a href="lwg-closed.html#2302">2302</a>, <a href="lwg-closed.html#2382">2382</a>.</li>
|
|
<li>Changed the following 11 issues to WP (from Ready): <a href="lwg-defects.html#2016">2016</a>, <a href="lwg-defects.html#2170">2170</a>, <a href="lwg-defects.html#2340">2340</a>, <a href="lwg-defects.html#2354">2354</a>, <a href="lwg-defects.html#2377">2377</a>, <a href="lwg-defects.html#2396">2396</a>, <a href="lwg-defects.html#2399">2399</a>, <a href="lwg-defects.html#2400">2400</a>, <a href="lwg-defects.html#2401">2401</a>, <a href="lwg-defects.html#2404">2404</a>, <a href="lwg-defects.html#2408">2408</a>.</li>
|
|
<li>Changed the following 12 issues to WP (from Tentatively Ready): <a href="lwg-defects.html#2106">2106</a>, <a href="lwg-defects.html#2129">2129</a>, <a href="lwg-defects.html#2212">2212</a>, <a href="lwg-defects.html#2217">2217</a>, <a href="lwg-defects.html#2230">2230</a>, <a href="lwg-defects.html#2233">2233</a>, <a href="lwg-defects.html#2266">2266</a>, <a href="lwg-defects.html#2325">2325</a>, <a href="lwg-defects.html#2361">2361</a>, <a href="lwg-defects.html#2365">2365</a>, <a href="lwg-defects.html#2376">2376</a>, <a href="lwg-defects.html#2387">2387</a>.</li>
|
|
<li>Changed the following issue to Resolved (from Ready): <a href="lwg-defects.html#2319">2319</a>.</li>
|
|
<li>Changed the following issue to Resolved (from Review): <a href="lwg-defects.html#2118">2118</a>.</li>
|
|
<li>Changed the following issue to Resolved (from New): <a href="lwg-defects.html#2416">2416</a>.</li>
|
|
<li>Changed the following issue to Resolved (from Open): <a href="lwg-defects.html#2108">2108</a>.</li>
|
|
<li>Changed the following issue to NAD (from New): <a href="lwg-closed.html#2429">2429</a>.</li>
|
|
</ul></li>
|
|
</ul>
|
|
</li>
|
|
<li>R90:
|
|
2014-10-13 pre-Urbana mailing
|
|
<ul>
|
|
<li><b>Summary:</b><ul>
|
|
<li>227 open issues, up by 31.</li>
|
|
<li>1742 closed issues, up by 0.</li>
|
|
<li>1969 issues total, up by 31.</li>
|
|
</ul></li>
|
|
<li><b>Details:</b><ul>
|
|
<li>Added the following 31 New issues: <a href="lwg-defects.html#2416">2416</a>, <a href="lwg-active.html#2417">2417</a>, <a href="lwg-defects.html#2418">2418</a>, <a href="lwg-active.html#2419">2419</a>, <a href="lwg-defects.html#2420">2420</a>, <a href="lwg-active.html#2421">2421</a>, <a href="lwg-active.html#2422">2422</a>, <a href="lwg-active.html#2423">2423</a>, <a href="lwg-active.html#2424">2424</a>, <a href="lwg-defects.html#2425">2425</a>, <a href="lwg-active.html#2426">2426</a>, <a href="lwg-defects.html#2427">2427</a>, <a href="lwg-defects.html#2428">2428</a>, <a href="lwg-closed.html#2429">2429</a>, <a href="lwg-active.html#2430">2430</a>, <a href="lwg-active.html#2431">2431</a>, <a href="lwg-active.html#2432">2432</a>, <a href="lwg-defects.html#2433">2433</a>, <a href="lwg-defects.html#2434">2434</a>, <a href="lwg-active.html#2435">2435</a>, <a href="lwg-active.html#2436">2436</a>, <a href="lwg-defects.html#2437">2437</a>, <a href="lwg-defects.html#2438">2438</a>, <a href="lwg-defects.html#2439">2439</a>, <a href="lwg-defects.html#2440">2440</a>, <a href="lwg-active.html#2441">2441</a>, <a href="lwg-defects.html#2442">2442</a>, <a href="lwg-active.html#2443">2443</a>, <a href="lwg-active.html#2444">2444</a>, <a href="lwg-active.html#2445">2445</a>, <a href="lwg-active.html#2446">2446</a>.</li>
|
|
<li>No issues changed.</li>
|
|
</ul></li>
|
|
</ul>
|
|
</li>
|
|
<li>R89:
|
|
2014-07-08 post-Rapperswil mailing
|
|
<ul>
|
|
<li><b>Summary:</b><ul>
|
|
<li>196 open issues, up by 14.</li>
|
|
<li>1742 closed issues, up by 12.</li>
|
|
<li>1938 issues total, up by 26.</li>
|
|
</ul></li>
|
|
<li><b>Details:</b><ul>
|
|
<li>Added the following 6 Ready issues: <a href="lwg-defects.html#2396">2396</a>, <a href="lwg-defects.html#2399">2399</a>, <a href="lwg-defects.html#2400">2400</a>, <a href="lwg-defects.html#2401">2401</a>, <a href="lwg-defects.html#2404">2404</a>, <a href="lwg-defects.html#2408">2408</a>.</li>
|
|
<li>Added the following 15 New issues: <a href="lwg-active.html#2391">2391</a>, <a href="lwg-active.html#2392">2392</a>, <a href="lwg-active.html#2393">2393</a>, <a href="lwg-active.html#2394">2394</a>, <a href="lwg-active.html#2398">2398</a>, <a href="lwg-active.html#2402">2402</a>, <a href="lwg-defects.html#2403">2403</a>, <a href="lwg-defects.html#2406">2406</a>, <a href="lwg-defects.html#2407">2407</a>, <a href="lwg-defects.html#2410">2410</a>, <a href="lwg-defects.html#2411">2411</a>, <a href="lwg-active.html#2412">2412</a>, <a href="lwg-active.html#2413">2413</a>, <a href="lwg-active.html#2414">2414</a>, <a href="lwg-defects.html#2415">2415</a>.</li>
|
|
<li>Added the following Open issue: <a href="lwg-defects.html#2397">2397</a>.</li>
|
|
<li>Added the following 3 WP issues: <a href="lwg-defects.html#2390">2390</a>, <a href="lwg-defects.html#2395">2395</a>, <a href="lwg-defects.html#2409">2409</a>.</li>
|
|
<li>Added the following NAD issue: <a href="lwg-closed.html#2405">2405</a>.</li>
|
|
<li>Changed the following issue to Ready (from New): <a href="lwg-defects.html#2377">2377</a>.</li>
|
|
<li>Changed the following 2 issues to Ready (from Deferred): <a href="lwg-active.html#2253">2253</a>, <a href="lwg-active.html#2255">2255</a>.</li>
|
|
<li>Changed the following 2 issues to Tentatively Ready (from New): <a href="lwg-defects.html#2325">2325</a>, <a href="lwg-defects.html#2387">2387</a>.</li>
|
|
<li>Changed the following issue to Tentatively NAD (from New): <a href="lwg-closed.html#2382">2382</a>.</li>
|
|
<li>Changed the following 3 issues to Review (from New): <a href="lwg-defects.html#2364">2364</a>, <a href="lwg-defects.html#2378">2378</a>, <a href="lwg-active.html#2380">2380</a>.</li>
|
|
<li>Changed the following 2 issues to Review (from Open): <a href="lwg-defects.html#2118">2118</a>, <a href="lwg-defects.html#2160">2160</a>.</li>
|
|
<li>Changed the following 3 issues to Open (from New): <a href="lwg-defects.html#2168">2168</a>, <a href="lwg-active.html#2238">2238</a>, <a href="lwg-active.html#2273">2273</a>.</li>
|
|
<li>Changed the following 3 issues to Open (from Deferred): <a href="lwg-active.html#2254">2254</a>, <a href="lwg-active.html#2264">2264</a>, <a href="lwg-active.html#2277">2277</a>.</li>
|
|
<li>Changed the following 3 issues to WP (from New): <a href="lwg-defects.html#2371">2371</a>, <a href="lwg-defects.html#2374">2374</a>, <a href="lwg-defects.html#2389">2389</a>.</li>
|
|
<li>Changed the following 4 issues to Resolved (from Deferred): <a href="lwg-defects.html#2282">2282</a>, <a href="lwg-defects.html#2283">2283</a>, <a href="lwg-defects.html#2287">2287</a>, <a href="lwg-defects.html#2333">2333</a>.</li>
|
|
<li>Changed the following issue to NAD (from Deferred): <a href="lwg-closed.html#2305">2305</a>.</li>
|
|
</ul></li>
|
|
</ul>
|
|
</li>
|
|
<li>R88:
|
|
2014-05-24 pre-Rapperswil mailing
|
|
<ul>
|
|
<li><b>Summary:</b><ul>
|
|
<li>182 open issues, up by 29.</li>
|
|
<li>1730 closed issues, up by 0.</li>
|
|
<li>1912 issues total, up by 29.</li>
|
|
</ul></li>
|
|
<li><b>Details:</b><ul>
|
|
<li>Added the following 3 Tentatively Ready issues: <a href="lwg-defects.html#2361">2361</a>, <a href="lwg-defects.html#2365">2365</a>, <a href="lwg-defects.html#2376">2376</a>.</li>
|
|
<li>Added the following 26 New issues: <a href="lwg-active.html#2362">2362</a>, <a href="lwg-active.html#2363">2363</a>, <a href="lwg-defects.html#2364">2364</a>, <a href="lwg-active.html#2366">2366</a>, <a href="lwg-active.html#2367">2367</a>, <a href="lwg-active.html#2368">2368</a>, <a href="lwg-defects.html#2369">2369</a>, <a href="lwg-active.html#2370">2370</a>, <a href="lwg-defects.html#2371">2371</a>, <a href="lwg-active.html#2372">2372</a>, <a href="lwg-closed.html#2373">2373</a>, <a href="lwg-defects.html#2374">2374</a>, <a href="lwg-active.html#2375">2375</a>, <a href="lwg-defects.html#2377">2377</a>, <a href="lwg-defects.html#2378">2378</a>, <a href="lwg-active.html#2379">2379</a>, <a href="lwg-active.html#2380">2380</a>, <a href="lwg-active.html#2381">2381</a>, <a href="lwg-closed.html#2382">2382</a>, <a href="lwg-active.html#2383">2383</a>, <a href="lwg-active.html#2384">2384</a>, <a href="lwg-active.html#2385">2385</a>, <a href="lwg-closed.html#2386">2386</a>, <a href="lwg-defects.html#2387">2387</a>, <a href="lwg-closed.html#2388">2388</a>, <a href="lwg-defects.html#2389">2389</a>.</li>
|
|
<li>Changed the following 5 issues to Tentatively Ready (from Open): <a href="lwg-defects.html#2106">2106</a>, <a href="lwg-defects.html#2129">2129</a>, <a href="lwg-defects.html#2212">2212</a>, <a href="lwg-defects.html#2230">2230</a>, <a href="lwg-defects.html#2233">2233</a>.</li>
|
|
</ul></li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
|
|
<h2><a name="Status"></a>Issue Status</h2>
|
|
|
|
<p>Issues reported to the LWG transition through a variety of statuses,
|
|
indicating their progress towards a resolution. Typically, most issues
|
|
will flow through the following stages.
|
|
</p>
|
|
|
|
<p><b><a name="New">New</a></b> - The issue has not yet been
|
|
reviewed by the LWG. Any <b>Proposed Resolution</b> is purely a
|
|
suggestion from the issue submitter, and should not be construed as
|
|
the view of LWG.</p>
|
|
|
|
<p><b><a name="Open">Open</a></b> - The LWG has discussed the issue
|
|
but is not yet ready to move the issue forward. There are several
|
|
possible reasons for open status:</p>
|
|
<ul>
|
|
<li>Consensus may have not yet have been reached as to how to deal
|
|
with the issue.</li>
|
|
<li>Informal consensus may have been reached, but the LWG awaits
|
|
exact <b>Proposed Resolution</b> wording for review.</li>
|
|
<li>The LWG wishes to consult additional technical experts before
|
|
proceeding.</li>
|
|
<li>The issue may require further study.</li>
|
|
</ul>
|
|
|
|
<p>A <b>Proposed Resolution</b> for an open issue is still not be
|
|
construed as the view of LWG. Comments on the current state of
|
|
discussions are often given at the end of open issues in an italic
|
|
font. Such comments are for information only and should not be given
|
|
undue importance.</p>
|
|
|
|
<p><b><a name="Review">Review</a></b> - Exact wording of a
|
|
<b>Proposed Resolution</b> is now available for review on an issue
|
|
for which the LWG previously reached informal consensus.</p>
|
|
|
|
<p><b><a name="Ready">Ready</a></b> - The LWG has reached consensus
|
|
that the issue is a defect in the Standard, the <b>Proposed
|
|
Resolution</b> is correct, and the issue is ready to forward to the
|
|
full committee for further action as a Defect Report (DR).</p>
|
|
|
|
<p>Typically, an issue must have a proposed resolution in the currently
|
|
published issues list, whose wording does not change during LWG review, to
|
|
move to the Ready status.</p>
|
|
|
|
<p><b><a name="Voting">Voting</a></b> - This status should not be seen
|
|
in a published issues list, but is a marker for use during meetings to
|
|
indicate an issues was Ready in the pre-meeting mailing, the <b>Proposed
|
|
Resolution</b> is correct, and the issue will be offered to the working
|
|
group at the end of the current meeting to apply to the current working
|
|
paper (WP) or to close in some other appropriate manner. This easily
|
|
distinguishes such issues from those moving to Ready status during the
|
|
meeting itself, that should not be forwarded until the next meeting. If
|
|
the issue does not move forward, it should fall back to one of the other
|
|
open states before the next list is published.</p>
|
|
|
|
<p><b><a name="Immediate">Immediate</a></b> - This status should not be
|
|
seen in a published issues list, but is a marker for use during meetings
|
|
to indicate an issues was not Ready in the pre-meeting mailing, but the
|
|
<b>Proposed Resolution</b> is correct, and the issue will be offered to
|
|
the working group at the end of the current meeting to apply to the
|
|
current working paper (WP) or to close in some other appropriate manner.
|
|
This status is used only rarely, typically for fixes that are both small
|
|
and obvious, and usually within a meeting of the expected publication of
|
|
a revised standard. If the issue does not move forward, it should fall
|
|
back to one of the other open states before the next list is published.</p>
|
|
|
|
<p>In addition, there are a few ways to categorise and issue that remains
|
|
open to a resolution within the library, but is not actively being worked
|
|
on.
|
|
</p>
|
|
|
|
<p><b><a name="Deferred">Deferred</a></b> - The LWG has discussed the issue,
|
|
is not yet ready to move the issue forward, but neither does it deem the
|
|
issue significant enough to delay publishing a standard or Technical Report.
|
|
A typical deferred issue would be seeking to clarify wording that might be
|
|
technically correct, but easily mis-read.</p>
|
|
|
|
<p>A <b>Proposed Resolution</b> for a deferred issue is still not be
|
|
construed as the view of LWG. Comments on the current state of
|
|
discussions are often given at the end of open issues in an italic
|
|
font. Such comments are for information only and should not be given
|
|
undue importance.</p>
|
|
|
|
<p><b><a name="Core">Core</a></b> - The LWG has discussed the issue, and feels
|
|
that some key part of resolving the issue is better handled by a cleanup of
|
|
the language in the Core part of the standard. The issue is passed to the Core
|
|
Working Group, which should ideally open a corresponding issue that can be
|
|
linked from the library issue. Such issues will be revisitted after Core have
|
|
made (or declined to make) any changes.
|
|
</p>
|
|
|
|
<p><b><a name="EWG">EWG</a></b> - The LWG has discussed the issue, and wonder
|
|
that some key part of resolving the issue is better handled by some (hopefully
|
|
small) extension to the language. The issue is passed to the Evolution Working
|
|
Group, which should ideally open a corresponding issue that can be linked from
|
|
the library issue. Such issues will be revisitted after Evoltion have made (or
|
|
declined to make) any recommendations. Positive recommendations from EWG will
|
|
often mean the issue transition to <i>Core</i> status while we wait for some
|
|
proposed new feature to land in the working paper.
|
|
</p>
|
|
|
|
<p><b><a name="LEWG">LEWG</a></b> - The LWG has discussed the issue, and deemd
|
|
the issue is either an extension, however small, or changes the library design
|
|
in some fundamental way, and so has delegated the initial work to the Library
|
|
Evolution Working Group.
|
|
</p>
|
|
|
|
<p>Ultimately, all issues should reach closure with one of the following statuses.
|
|
</p>
|
|
|
|
<p><b><a name="DR">DR</a></b> - (Defect Report) - The full WG21/PL22.16
|
|
committee has voted to forward the issue to the Project Editor to be
|
|
processed as a Potential Defect Report. The Project Editor reviews
|
|
the issue, and then forwards it to the WG21 Convenor, who returns it
|
|
to the full committee for final disposition. This issues list
|
|
accords the status of DR to all these Defect Reports regardless of
|
|
where they are in that process.</p>
|
|
|
|
<p><b><a name="WP">WP</a></b> - (Working Paper) - The proposed resolution has not been
|
|
accepted as a Technical Corrigendum, but the full WG21/PL22.16 committee has voted to
|
|
apply the Defect Report's Proposed Resolution to the working paper.</p>
|
|
|
|
<p><b><a name="C++11">C++14</a></b> - (C++ Standard, as revised for 2014) - The full
|
|
WG21/PL22.16 committee has voted to accept the Defect Report's Proposed Resolution into
|
|
the published 2011 revision to the C++ standard, ISO/IEC IS 14882:2014(E).</p>
|
|
|
|
<p><b><a name="C++11">C++11</a></b> - (C++ Standard, as revised for 2011) - The full
|
|
WG21/PL22.16 committee has voted to accept the Defect Report's Proposed Resolution into
|
|
the published 2011 revision to the C++ standard, ISO/IEC IS 14882:2011(E).</p>
|
|
|
|
<p><b><a name="CD1">CD1</a></b> - (Committee Draft 2008) - The full
|
|
WG21/PL22.16 committee has voted to accept the Defect Report's Proposed
|
|
Resolution into the Fall 2008 Committee Draft.</p>
|
|
|
|
<p><b><a name="TC1">TC1</a></b> - (Technical Corrigenda 1) - The full
|
|
WG21/PL22.16 committee has voted to accept the Defect Report's Proposed
|
|
Resolution as a Technical Corrigenda. Action on this issue is thus
|
|
complete and no further action is possible under ISO rules.</p>
|
|
|
|
<p><b><a name="TRDec">TRDec</a></b> - (Decimal TR defect) - The LWG has voted to
|
|
accept the Defect Report's Proposed Resolution into the Decimal TR. Action on this
|
|
issue is thus complete and no further action is expected.</p>
|
|
|
|
<p><b><a name="Resolved">Resolved</a></b> - The LWG has reached consensus
|
|
that the issue is a defect in the Standard, but the resolution adopted to
|
|
resolve the issue came via some other mechanism than this issue in the
|
|
list - typically by applying a formal paper, occasionally as a side effect
|
|
of consolidating several interacting issue resolutions into a single issue.</p>
|
|
|
|
<p><b><a name="Dup">Dup</a></b> - The LWG has reached consensus that
|
|
the issue is a duplicate of another issue, and will not be further
|
|
dealt with. A <b>Rationale</b> identifies the duplicated issue's
|
|
issue number.</p>
|
|
|
|
<p><b><a name="NAD">NAD</a></b> - The LWG has reached consensus that
|
|
the issue is not a defect in the Standard.</p>
|
|
|
|
<p><b><a name="NAD Editorial">NAD Editorial</a></b> - The LWG has reached consensus that
|
|
the issue can either be handled editorially, or is handled by a paper (usually
|
|
linked to in the rationale).</p>
|
|
|
|
<p><b>Tentatively</b> - This is a <i>status qualifier</i>. The issue has
|
|
been reviewed online, or at an unofficial meeting, but not in an official meeting, and
|
|
some support has been formed for the qualified status. Tentatively qualified issues may
|
|
be moved to the unqualified status and forwarded to full committee (if Ready) within the
|
|
same meeting. Unlike Ready issues, Tentatively Ready issues will be reviewed in
|
|
subcommittee prior to forwarding to full committee. When a status is qualified with
|
|
Tentatively, the issue is still considered active.</p>
|
|
|
|
<p><b>Pending</b> - This is a <i>status qualifier</i>. When prepended to a status this
|
|
indicates the issue has been processed by the committee, and a decision has been made to
|
|
move the issue to the associated unqualified status. However for logistical reasons the
|
|
indicated outcome of the issue has not yet appeared in the latest working paper.</p>
|
|
|
|
<p>The following statuses have been retired, but may show up on older issues lists.</p>
|
|
|
|
<p><b><a name="NAD Future">NAD Future</a></b> - In addition to the regular status, the
|
|
LWG believes that this issue should be revisited at the next revision of the standard.
|
|
That is now an ongoing task managed by the Library Evolution Working Group, and most
|
|
issues in this status were reopended with the status <a href="#NAD Editorial">LEWG</a>.
|
|
</p>
|
|
|
|
<p><b><a name="NAD Concepts">NAD Concepts</a></b> - This status reflects an evolution
|
|
of the language during the development of C++11, where a new feature entered the
|
|
language, called <i>concepts</i>, that fundamentally changed the way templates would
|
|
be specified and written. While this language feature was removed towards the end of
|
|
the C++11 project, there is a clear intent to revisit this part of the language design.
|
|
During that development, a number of issues were opened against the updated library
|
|
related to use of that feature, or requesting fixes that would require exlicit use of
|
|
the concepts feature. All such issues have been closed with this status, and may be
|
|
revisitted should this or a similar language feature return for a future standard.</p>
|
|
|
|
<p>Issues are always given the status of <a href="lwg-active.html#New">New</a> when
|
|
they first appear on the issues list. They may progress to
|
|
<a href="lwg-active.html#Open">Open</a> or <a href="lwg-active.html#Review">Review</a>
|
|
while the LWG is actively working on them. When the LWG has reached consensus on
|
|
the disposition of an issue, the status will then change to
|
|
<a href="lwg-active.html#Dup">Dup</a>, <a href="lwg-active.html#NAD">NAD</a>, or
|
|
<a href="lwg-active.html#Ready">Ready</a> as appropriate. Once the full PL22.16 committee
|
|
votes to forward Ready issues to the Project Editor, they are given the status of Defect
|
|
Report (<a href="lwg-active.html#DR">DR</a>). These in turn may become the basis for
|
|
Technical Corrigenda (<a href="lwg-active.html#TC1">TC1</a>), an updated standard
|
|
(<a href="lwg-defects.html#C++11">C++11</a>, <a href="lwg-defects.html#C++14">C++14</a>),
|
|
or are closed without action other than a Record of Response
|
|
(<a href="lwg-active.html#Resolved">Resolved</a>) where the desired effect has already
|
|
been achieved by some other process. The intent of this LWG process is that only issues
|
|
which are truly defects in the Standard move to the formal ISO DR status.
|
|
</p>
|
|
|
|
|
|
<h2>Active Issues</h2>
|
|
<hr>
|
|
<h3><a name="255"></a>255. Why do <tt>basic_streambuf<>::pbump()</tt> and <tt>gbump()</tt> take an int?</h3>
|
|
<p><b>Section:</b> 27.6.3 [streambuf] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-08-12 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#streambuf">issues</a> in [streambuf].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The basic_streambuf members gbump() and pbump() are specified to take an
|
|
int argument. This requirement prevents the functions from effectively
|
|
manipulating buffers larger than std::numeric_limits<int>::max()
|
|
characters. It also makes the common use case for these functions
|
|
somewhat difficult as many compilers will issue a warning when an
|
|
argument of type larger than int (such as ptrdiff_t on LLP64
|
|
architectures) is passed to either of the function. Since it's often the
|
|
result of the subtraction of two pointers that is passed to the
|
|
functions, a cast is necessary to silence such warnings. Finally, the
|
|
usage of a native type in the functions signatures is inconsistent with
|
|
other member functions (such as sgetn() and sputn()) that manipulate the
|
|
underlying character buffer. Those functions take a streamsize argument.
|
|
</p>
|
|
|
|
<p><i>[
|
|
2009-07 Frankfurt
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<p>
|
|
This is part of a bigger problem. If anyone cares enough, they should
|
|
write a paper solving the bigger problem of offset types in iostreams.
|
|
</p>
|
|
<p>
|
|
This is related to the paper about large file sizes. Beman has already
|
|
agreed to drop the section of that paper that deals with this.
|
|
</p>
|
|
<p>
|
|
int is big enough for reasonable buffers.
|
|
</p>
|
|
<p>
|
|
Move to NAD Future.
|
|
</p>
|
|
<p>
|
|
This is related to LWG <a href="lwg-active.html#423">423</a>.
|
|
</p>
|
|
</blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Change the signatures of these functions in the synopsis of template
|
|
class basic_streambuf (27.5.2) and in their descriptions (27.5.2.3.1, p4
|
|
and 27.5.2.3.2, p4) to take a streamsize argument.
|
|
</p>
|
|
|
|
<p>
|
|
Although this change has the potential of changing the ABI of the
|
|
library, the change will affect only platforms where int is different
|
|
than the definition of streamsize. However, since both functions are
|
|
typically inline (they are on all known implementations), even on such
|
|
platforms the change will not affect any user code unless it explicitly
|
|
relies on the existing type of the functions (e.g., by taking their
|
|
address). Such a possibility is IMO quite remote.
|
|
</p>
|
|
|
|
<p>
|
|
Alternate Suggestion from Howard Hinnant, c++std-lib-7780:
|
|
</p>
|
|
|
|
<p>
|
|
This is something of a nit, but I'm wondering if streamoff wouldn't be a
|
|
better choice than streamsize. The argument to pbump and gbump MUST be
|
|
signed. But the standard has this to say about streamsize
|
|
(27.4.1/2/Footnote):
|
|
</p>
|
|
|
|
<blockquote><p>
|
|
[Footnote: streamsize is used in most places where ISO C would use
|
|
size_t. Most of the uses of streamsize could use size_t, except for
|
|
the strstreambuf constructors, which require negative values. It
|
|
should probably be the signed type corresponding to size_t (which is
|
|
what Posix.2 calls ssize_t). --- end footnote]
|
|
</p></blockquote>
|
|
|
|
<p>
|
|
This seems a little weak for the argument to pbump and gbump. Should we
|
|
ever really get rid of strstream, this footnote might go with it, along
|
|
with the reason to make streamsize signed.
|
|
</p>
|
|
|
|
|
|
<p><b>Rationale:</b></p>
|
|
<p>The LWG believes this change is too big for now. We may wish to
|
|
reconsider this for a future revision of the standard. One
|
|
possibility is overloading pbump, rather than changing the
|
|
signature.</p>
|
|
<p><i>[
|
|
[2006-05-04: Reopened at the request of Chris (Krzysztof ?elechowski)]
|
|
]</i></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="423"></a>423. effects of negative streamsize in iostreams</h3>
|
|
<p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#input.output">issues</a> in [input.output].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
A third party test suite tries to exercise istream::ignore(N) with
|
|
a negative value of N and expects that the implementation will treat
|
|
N as if it were 0. Our implementation asserts that (N >= 0) holds and
|
|
aborts the test.
|
|
</p>
|
|
|
|
<p>
|
|
I can't find anything in section 27 that prohibits such values but I don't
|
|
see what the effects of such calls should be, either (this applies to
|
|
a number of unformatted input functions as well as some member functions
|
|
of the basic_streambuf template).
|
|
</p>
|
|
|
|
<p><i>[
|
|
2009-07 Frankfurt
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<p>
|
|
This is related to LWG <a href="lwg-active.html#255">255</a>.
|
|
</p>
|
|
<p>
|
|
Move to NAD Future.
|
|
</p>
|
|
</blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
I propose that we add to each function in clause 27 that takes an argument,
|
|
say N, of type streamsize a Requires clause saying that "N >= 0." The intent
|
|
is to allow negative streamsize values in calls to precision() and width()
|
|
but disallow it in calls to streambuf::sgetn(), istream::ignore(), or
|
|
ostream::write().
|
|
</p>
|
|
|
|
<p><i>[Kona: The LWG agreed that this is probably what we want. However, we
|
|
need a review to find all places where functions in clause 27 take
|
|
arguments of type streamsize that shouldn't be allowed to go
|
|
negative. Martin will do that review.]</i></p>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="484"></a>484. Convertible to <tt>T</tt></h3>
|
|
<p><b>Section:</b> 24.2.3 [input.iterators] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2004-09-16 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#input.iterators">issues</a> in [input.iterators].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>From comp.std.c++:</p>
|
|
|
|
<p>
|
|
I note that given an input iterator a for type <tt>T</tt>,
|
|
then <tt>*a</tt> only has to be "convertable to <tt>T</tt>",
|
|
not actually of type <tt>T</tt>.
|
|
</p>
|
|
|
|
<p>Firstly, I can't seem to find an exact definition of "convertable to <tt>T</tt>".
|
|
While I assume it is the obvious definition (an implicit conversion), I
|
|
can't find an exact definition. Is there one?</p>
|
|
|
|
<p>Slightly more worryingly, there doesn't seem to be any restriction on
|
|
the this type, other than it is "convertable to <tt>T</tt>". Consider two input
|
|
iterators <tt>a</tt> and <tt>b</tt>. I would personally assume that most people would
|
|
expect <tt>*a==*b</tt> would perform <tt>T(*a)==T(*b)</tt>, however it doesn't seem that
|
|
the standard requires that, and that whatever type <tt>*a</tt> is (call it <tt>U</tt>)
|
|
could have == defined on it with totally different symantics and still
|
|
be a valid inputer iterator.</p>
|
|
|
|
<p>Is this a correct reading? When using input iterators should I write
|
|
<tt>T(*a)</tt> all over the place to be sure that the object I'm using is the
|
|
class I expect?</p>
|
|
|
|
<p>This is especially a nuisance for operations that are defined to be
|
|
"convertible to <tt>bool</tt>". (This is probably allowed so that
|
|
implementations could return say an <tt>int</tt> and avoid an unnessary
|
|
conversion. However all implementations I have seen simply return a
|
|
<tt>bool</tt> anyway. Typical implemtations of STL algorithms just write
|
|
things like <tt>while(a!=b && *a!=0)</tt>. But strictly
|
|
speaking, there are lots of types that are convertible to <tt>T</tt> but
|
|
that also overload the appropriate operators so this doesn't behave
|
|
as expected.</p>
|
|
|
|
<p>If we want to make code like this legal (which most people seem to
|
|
expect), then we'll need to tighten up what we mean by "convertible
|
|
to <tt>T</tt>".</p>
|
|
|
|
<p><i>[Lillehammer: The first part is NAD, since "convertible" is
|
|
well-defined in core. The second part is basically about pathological
|
|
overloads. It's a minor problem but a real one. So leave open for
|
|
now, hope we solve it as part of iterator redesign.]</i></p>
|
|
|
|
|
|
<p><i>[
|
|
2009-07-28 Reopened by Alisdair. No longer solved by concepts.
|
|
]</i></p>
|
|
|
|
|
|
<p><i>[
|
|
2009-10 Santa Cruz:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
Mark as NAD Future. We agree there's an issue, but there is no
|
|
proposed solution at this time and this will be solved by concepts in
|
|
the future.
|
|
</p></blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
<p><b>Rationale:</b></p>
|
|
<p><i>[
|
|
San Francisco:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
Solved by
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2758.pdf">N2758</a>.
|
|
</p></blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="523"></a>523. regex case-insensitive character ranges are unimplementable as specified</h3>
|
|
<p><b>Section:</b> 28 [re] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Eric Niebler <b>Opened:</b> 2005-07-01 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#re">active issues</a> in [re].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#re">issues</a> in [re].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
A problem with TR1 regex is currently being discussed on the Boost
|
|
developers list. It involves the handling of case-insensitive matching
|
|
of character ranges such as [Z-a]. The proper behavior (according to the
|
|
ECMAScript standard) is unimplementable given the current specification
|
|
of the TR1 regex_traits<> class template. John Maddock, the author of
|
|
the TR1 regex proposal, agrees there is a problem. The full discussion
|
|
can be found at http://lists.boost.org/boost/2005/06/28850.php (first
|
|
message copied below). We don't have any recommendations as yet.
|
|
</p>
|
|
<p>
|
|
-- Begin original message --
|
|
</p>
|
|
<p>
|
|
The situation of interest is described in the ECMAScript specification
|
|
(ECMA-262), section 15.10.2.15:
|
|
</p>
|
|
<p>
|
|
"Even if the pattern ignores case, the case of the two ends of a range
|
|
is significant in determining which characters belong to the range.
|
|
Thus, for example, the pattern /[E-F]/i matches only the letters E, F,
|
|
e, and f, while the pattern /[E-f]/i matches all upper and lower-case
|
|
ASCII letters as well as the symbols [, \, ], ^, _, and `."
|
|
</p>
|
|
<p>
|
|
A more interesting case is what should happen when doing a
|
|
case-insentitive match on a range such as [Z-a]. It should match z, Z,
|
|
a, A and the symbols [, \, ], ^, _, and `. This is not what happens with
|
|
Boost.Regex (it throws an exception from the regex constructor).
|
|
</p>
|
|
<p>
|
|
The tough pill to swallow is that, given the specification in TR1, I
|
|
don't think there is any effective way to handle this situation.
|
|
According to the spec, case-insensitivity is handled with
|
|
regex_traits<>::translate_nocase(CharT) -- two characters are equivalent
|
|
if they compare equal after both are sent through the translate_nocase
|
|
function. But I don't see any way of using this translation function to
|
|
make character ranges case-insensitive. Consider the difficulty of
|
|
detecting whether "z" is in the range [Z-a]. Applying the transformation
|
|
to "z" has no effect (it is essentially std::tolower). And we're not
|
|
allowed to apply the transformation to the ends of the range, because as
|
|
ECMA-262 says, "the case of the two ends of a range is significant."
|
|
</p>
|
|
<p>
|
|
So AFAICT, TR1 regex is just broken, as is Boost.Regex. One possible fix
|
|
is to redefine translate_nocase to return a string_type containing all
|
|
the characters that should compare equal to the specified character. But
|
|
this function is hard to implement for Unicode, and it doesn't play nice
|
|
with the existing ctype facet. What a mess!
|
|
</p>
|
|
<p>
|
|
-- End original message --
|
|
</p>
|
|
|
|
<p><i>[
|
|
John Maddock adds:
|
|
]</i></p>
|
|
|
|
|
|
<p>
|
|
One small correction, I have since found that ICU's regex package does
|
|
implement this correctly, using a similar mechanism to the current
|
|
TR1.Regex.
|
|
</p>
|
|
<p>
|
|
Given an expression [c1-c2] that is compiled as case insensitive it:
|
|
</p>
|
|
<p>
|
|
Enumerates every character in the range c1 to c2 and converts it to it's
|
|
case folded equivalent. That case folded character is then used a key to a
|
|
table of equivalence classes, and each member of the class is added to the
|
|
list of possible matches supported by the character-class. This second step
|
|
isn't possible with our current traits class design, but isn't necessary if
|
|
the input text is also converted to a case-folded equivalent on the fly.
|
|
</p>
|
|
<p>
|
|
ICU applies similar brute force mechanisms to character classes such as
|
|
[[:lower:]] and [[:word:]], however these are at least cached, so the impact
|
|
is less noticeable in this case.
|
|
</p>
|
|
<p>
|
|
Quick and dirty performance comparisons show that expressions such as
|
|
"[X-\\x{fff0}]+" are indeed very slow to compile with ICU (about 200 times
|
|
slower than a "normal" expression). For an application that uses a lot of
|
|
regexes this could have a noticeable performance impact. ICU also has an
|
|
advantage in that it knows the range of valid characters codes: code points
|
|
outside that range are assumed not to require enumeration, as they can not
|
|
be part of any equivalence class. I presume that if we want the TR1.Regex
|
|
to work with arbitrarily large character sets enumeration really does become
|
|
impractical.
|
|
</p>
|
|
<p>
|
|
Finally note that Unicode has:
|
|
</p>
|
|
<p>
|
|
Three cases (upper, lower and title).
|
|
One to many, and many to one case transformations.
|
|
Character that have context sensitive case translations - for example an
|
|
uppercase sigma has two different lowercase forms - the form chosen depends
|
|
on context(is it end of a word or not), a caseless match for an upper case
|
|
sigma should match either of the lower case forms, which is why case folding
|
|
is often approximated by tolower(toupper(c)).
|
|
</p>
|
|
<p>
|
|
Probably we need some way to enumerate character equivalence classes,
|
|
including digraphs (either as a result or an input), and some way to tell
|
|
whether the next character pair is a valid digraph in the current locale.
|
|
</p>
|
|
<p>
|
|
Hoping this doesn't make this even more complex that it was already,
|
|
</p>
|
|
|
|
<p><i>[
|
|
Portland: Alisdair: Detect as invalid, throw an exception.
|
|
Pete: Possible general problem with case insensitive ranges.
|
|
]</i></p>
|
|
|
|
|
|
<p><i>[
|
|
2009-07 Frankfurt
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<p>
|
|
We agree that this is a problem, but we do not know the answer.
|
|
</p>
|
|
<p>
|
|
We are going to declare this NAD until existing practice leads us in some direction.
|
|
</p>
|
|
<p>
|
|
No objection to NAD Future.
|
|
</p>
|
|
<p>
|
|
Move to NAD Future.
|
|
</p>
|
|
</blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="532"></a>532. Tuple comparison</h3>
|
|
<p><b>Section:</b> 20.4.2.7 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> David Abrahams <b>Opened:</b> 2005-11-29 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#tuple.rel">active issues</a> in [tuple.rel].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#tuple.rel">issues</a> in [tuple.rel].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Duplicate of:</b> <a href="lwg-closed.html#348">348</a></p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Where possible, <tt>tuple</tt> comparison operators <,<=,=>, and > ought to be
|
|
defined in terms of <tt>std::less</tt> rather than <tt>operator<</tt>, in order to
|
|
support comparison of tuples of pointers.
|
|
</p>
|
|
|
|
<p><i>[
|
|
2009-07-28 Reopened by Alisdair. No longer solved by concepts.
|
|
]</i></p>
|
|
|
|
|
|
<p><i>[
|
|
2009-10 Santa Cruz:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<p>
|
|
If we solve this for <tt>tuple</tt> we would have to solve it for <tt>pair</tt>
|
|
algorithms, etc. It is too late to do that at this time. Move to NAD Future.
|
|
</p>
|
|
</blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
change 6.1.3.5/5 from:
|
|
</p>
|
|
|
|
<blockquote><p>
|
|
Returns: The result of a lexicographical comparison between t and
|
|
u. The result is defined as: (bool)(get<0>(t) < get<0>(u)) ||
|
|
(!(bool)(get<0>(u) < get<0>(t)) && ttail < utail), where rtail for
|
|
some tuple r is a tuple containing all but the first element of
|
|
r. For any two zero-length tuples e and f, e < f returns false.
|
|
</p></blockquote>
|
|
|
|
<p>
|
|
to:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
Returns: The result of a lexicographical comparison between t and
|
|
u. For any two zero-length tuples e and f, e < f returns false.
|
|
Otherwise, the result is defined as: cmp( get<0>(t), get<0>(u)) ||
|
|
(!cmp(get<0>(u), get<0>(t)) && ttail < utail), where rtail for some
|
|
tuple r is a tuple containing all but the first element of r, and
|
|
cmp(x,y) is an unspecified function template defined as follows.
|
|
</p>
|
|
<p>
|
|
Where T is the type of x and U is the type of y:
|
|
</p>
|
|
|
|
<p>
|
|
if T and U are pointer types and T is convertible to U, returns
|
|
less<U>()(x,y)
|
|
</p>
|
|
|
|
<p>
|
|
otherwise, if T and U are pointer types, returns less<T>()(x,y)
|
|
</p>
|
|
|
|
<p>
|
|
otherwise, returns (bool)(x < y)
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p><i>[
|
|
Berlin: This issue is much bigger than just tuple (pair, containers,
|
|
algorithms). Dietmar will survey and work up proposed wording.
|
|
]</i></p>
|
|
|
|
|
|
|
|
|
|
<p><b>Rationale:</b></p>
|
|
<p>
|
|
Recommend NAD. This will be fixed with the next revision of concepts.
|
|
</p>
|
|
|
|
<p><i>[
|
|
San Francisco:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
Solved by
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>.
|
|
</p></blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="708"></a>708. Locales need to be per thread and updated for POSIX changes</h3>
|
|
<p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-07-28 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#localization">issues</a> in [localization].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The POSIX "Extended API Set Part 4,"
|
|
</p>
|
|
<blockquote><p>
|
|
<a href="http://www.opengroup.org/sib/details.tpl?id=C065">http://www.opengroup.org/sib/details.tpl?id=C065</a>
|
|
</p></blockquote>
|
|
<p>
|
|
introduces extensions to the C locale mechanism that
|
|
allow multiple concurrent locales to be used in the same application
|
|
by introducing a type <tt>locale_t</tt> that is very similar to
|
|
<tt>std::locale</tt>, and a number of <tt>_l</tt> functions that make use of it.
|
|
</p>
|
|
<p>
|
|
The global locale (set by setlocale) is now specified to be per-
|
|
process. If a thread does not call <tt>uselocale</tt>, the global locale is
|
|
in effect for that thread. It can install a per-thread locale by
|
|
using <tt>uselocale</tt>.
|
|
</p>
|
|
<p>
|
|
There is also a nice <tt>querylocale</tt> mechanism by which one can obtain
|
|
the name (such as "de_DE") for a specific <tt>facet</tt>, even for combined
|
|
locales, with no <tt>std::locale</tt> equivalent.
|
|
</p>
|
|
<p>
|
|
<tt>std::locale</tt> should be harmonized with the new POSIX <tt>locale_t</tt>
|
|
mechanism and provide equivalents for <tt>uselocale</tt> and <tt>querylocale</tt>.
|
|
</p>
|
|
|
|
<p><i>[
|
|
Kona (2007): Bill and Nick to provide wording.
|
|
]</i></p>
|
|
|
|
|
|
<p><i>[
|
|
San Francisco: Bill and Nick still intend to provide wording, but this
|
|
is a part of the task to be addressed by the group that will look into
|
|
issue <a href="lwg-defects.html#860">860</a>.
|
|
]</i></p>
|
|
|
|
|
|
<p><i>[
|
|
2009-07 Frankfurt:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<p>
|
|
It's our intention to stay in sync with WG14. If WG14 makes a decision
|
|
that requires a change in WG21 the issue will be reopened.
|
|
</p>
|
|
<p>
|
|
Move to NAD Future.
|
|
</p>
|
|
</blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="760"></a>760. The emplace issue</h3>
|
|
<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="lwg-active.html#NAD">Tentatively NAD</a>
|
|
<b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2007-11-11 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively NAD">Tentatively NAD</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
In an <tt>emplace</tt> member function the function parameter pack may be bound
|
|
to a priori unlimited number of objects: some or all of them can be
|
|
elements of the container itself. Apparently, in order to conform to the
|
|
blanket statement 23.2 [container.requirements]/11, the
|
|
implementation must check all of them for that possibility. A possible
|
|
solution can involve extending the exception in 23.2 [container.requirements]/12 also to the emplace member. As a
|
|
side note, the <tt>push_back</tt> and <tt>push_front</tt> member
|
|
functions are luckily not affected by this problem, can be efficiently
|
|
implemented anyway.
|
|
</p>
|
|
|
|
<p><i>[
|
|
Related to <a href="lwg-defects.html#767">767</a> and to <a href="lwg-active.html#2164">2164</a>
|
|
]</i></p>
|
|
|
|
|
|
<p><i>[
|
|
Bellevue:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<p>
|
|
The proposed addition (13) is partially redundant with the existing
|
|
paragraph 12. Why was the qualifier "rvalues" added to paragraph 12? Why
|
|
does it not cover subelements and pointers?
|
|
</p>
|
|
<p>
|
|
Resolution: Alan Talbot to rework language, then set state to Review.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p><i>[
|
|
2009-07 Frankfurt
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<p>
|
|
The problem is broader than <tt>emplace</tt>. The LWG doesn't
|
|
feel that it knows how to write wording that prohibits all of the
|
|
problematic use cases at this time.
|
|
</p>
|
|
<p>
|
|
NAD Future.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p><i>[2015-02 Cologne]</i></p>
|
|
|
|
<p>
|
|
LWG believes that <a href="lwg-active.html#2164">2164</a> addresses this issue and therefore considers <a href="lwg-active.html#760">760</a> as NAD.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Add after 23.2 [container.requirements]/12:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-12- Objects passed to member functions of a container as rvalue
|
|
references shall not be elements of that container. No diagnostic
|
|
required.
|
|
</p>
|
|
<p>
|
|
<ins>
|
|
-13- Objects bound to the function parameter pack of the
|
|
<tt>emplace</tt> member function shall not be elements or sub-objects of
|
|
elements of the container. No diagnostic required.
|
|
</ins>
|
|
</p>
|
|
|
|
</blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="839"></a>839. Maps and sets missing splice operation</h3>
|
|
<p><b>Section:</b> 23.4 [associative], 23.5 [unord] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Alan Talbot <b>Opened:</b> 2008-05-18 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#associative">active issues</a> in [associative].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#associative">issues</a> in [associative].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Splice is a very useful feature of <tt>list</tt>. This functionality is also very
|
|
useful for any other node based container, and I frequently wish it were
|
|
available for maps and sets. It seems like an omission that these
|
|
containers lack this capability. Although the complexity for a splice is
|
|
the same as for an insert, the actual time can be much less since the
|
|
objects need not be reallocated and copied. When the element objects are
|
|
heavy and the compare operations are fast (say a <tt>map<int, huge_thingy></tt>)
|
|
this can be a big win.
|
|
</p>
|
|
|
|
<p>
|
|
<b>Suggested resolution:</b>
|
|
</p>
|
|
|
|
<p>
|
|
Add the following signatures to map, set, multimap, multiset, and the unordered associative containers:
|
|
</p>
|
|
<blockquote><pre>
|
|
void splice(list<T,Allocator>&& x);
|
|
void splice(list<T,Allocator>&& x, const_iterator i);
|
|
void splice(list<T,Allocator>&& x, const_iterator first, const_iterator last);
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
Hint versions of these are also useful to the extent hint is useful.
|
|
(I'm looking for guidance about whether hints are in fact useful.)
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
void splice(const_iterator position, list<T,Allocator>&& x);
|
|
void splice(const_iterator position, list<T,Allocator>&& x, const_iterator i);
|
|
void splice(const_iterator position, list<T,Allocator>&& x, const_iterator first, const_iterator last);
|
|
</pre></blockquote>
|
|
|
|
<p><i>[
|
|
Sophia Antipolis:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<p>
|
|
Don't try to <tt>splice "list"</tt> into the other containers, it should be container-type.
|
|
</p>
|
|
<p>
|
|
<tt>forward_list</tt> already has <tt>splice_after</tt>.
|
|
</p>
|
|
<p>
|
|
Would "<tt>splice</tt>" make sense for an <tt>unordered_map</tt>?
|
|
</p>
|
|
<p>
|
|
Jens, Robert: "<tt>splice</tt>" is not the right term, it implies maintaining ordering in <tt>list</tt>s.
|
|
</p>
|
|
<p>
|
|
Howard: <tt>adopt</tt>?
|
|
</p>
|
|
<p>
|
|
Jens: <tt>absorb</tt>?
|
|
</p>
|
|
<p>
|
|
Alan: <tt>subsume</tt>?
|
|
</p>
|
|
<p>
|
|
Robert: <tt>recycle</tt>?
|
|
</p>
|
|
<p>
|
|
Howard: <tt>transfer</tt>? (but no direction)
|
|
</p>
|
|
<p>
|
|
Jens: <tt>transfer_from</tt>. No.
|
|
</p>
|
|
<p>
|
|
Alisdair: Can we give a nothrow guarantee? If your <tt>compare()</tt> and <tt>hash()</tt> doesn't throw, yes.
|
|
</p>
|
|
<p>
|
|
Daniel: For <tt>unordered_map</tt>, we can't guarantee nothrow.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p><i>[
|
|
San Francisco:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<p>
|
|
Martin: this would possibly outlaw an implementation technique that is
|
|
currently in use; caching nodes in containers.
|
|
</p>
|
|
<p>
|
|
Alan: if you cache in the allocator, rather than the individual
|
|
container, this proposal doesn't interfere with that.
|
|
</p>
|
|
<p>
|
|
Martin: I'm not opposed to this, but I'd like to see an implementation
|
|
that demonstrates that it works.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p><i>[
|
|
2009-07 Frankfurt:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
NAD Future.
|
|
</p></blockquote>
|
|
|
|
<p><i>[
|
|
2009-09-19 Howard adds:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<p>
|
|
I'm not disagreeing with the NAD Future resolution. But when the future gets
|
|
here, here is a possibility worth exploring:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
Add to the "unique" associative containers:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
typedef <i>details</i> node_ptr;
|
|
|
|
node_ptr remove(const_iterator p);
|
|
pair<iterator, bool> insert(node_ptr&& nd);
|
|
iterator insert(const_iterator p, node_ptr&& nd);
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
And add to the "multi" associative containers:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
typedef <i>details</i> node_ptr;
|
|
|
|
node_ptr remove(const_iterator p);
|
|
iterator insert(node_ptr&& nd);
|
|
iterator insert(const_iterator p, node_ptr&& nd);
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
<tt>Container::node_ptr</tt> is a smart pointer much like <tt>unique_ptr</tt>.
|
|
It owns a node obtained from the container it was removed from. It maintains a
|
|
reference to the allocator in the container so that it can properly deallocate
|
|
the node if asked to, even if the allocator is stateful. This being said, the
|
|
<tt>node_ptr</tt> can not outlive the container for this reason.
|
|
</p>
|
|
|
|
<p>
|
|
The <tt>node_ptr</tt> offers "<tt>const</tt>-free" access to the node's
|
|
<tt>value_type</tt>.
|
|
</p>
|
|
|
|
<p>
|
|
With this interface, clients have a great deal of flexibility:
|
|
</p>
|
|
|
|
<ul>
|
|
<li>
|
|
A client can remove a node from one container, and insert it into another
|
|
(without any heap allocation). This is the splice functionality this issue
|
|
asks for.
|
|
</li>
|
|
<li>
|
|
A client can remove a node from a container, change its key or value, and insert
|
|
it back into the same container, or another container, all without the cost of
|
|
allocating a node.
|
|
</li>
|
|
<li>
|
|
If the Compare function is nothrow (which is very common), then this functionality
|
|
is nothrow unless modifying the value throws. And if this does throw, it does
|
|
so outside of the containers involved.
|
|
</li>
|
|
<li>
|
|
If the Compare function does throw, the <tt>insert</tt> function will have the
|
|
argument <tt>nd</tt> retain ownership of the node.
|
|
</li>
|
|
<li>
|
|
The <tt>node_ptr</tt> should be independent of the <tt>Compare</tt> parameter
|
|
so that a node can be transferred from <tt>set<T, C1, A></tt>
|
|
to <tt>set<T, C2, A></tt> (for example).
|
|
</li>
|
|
</ul>
|
|
|
|
<p>
|
|
Here is how the customer might use this functionality:
|
|
</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
Splice a node from one container to another:
|
|
</p>
|
|
<blockquote><pre>
|
|
m2.insert(m1.remove(i));
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
Change the "key" in a <tt>std::map</tt> without the cost of node reallocation:
|
|
</p>
|
|
<blockquote><pre>
|
|
auto p = m.remove(i);
|
|
p->first = new_key;
|
|
m.insert(std::move(p));
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
Change the "value" in a <tt>std::set</tt> without the cost of node reallocation:
|
|
</p>
|
|
<blockquote><pre>
|
|
auto p = s.remove(i);
|
|
*p = new_value;
|
|
s.insert(std::move(p));
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
Move a move-only or heavy object out of an associative container (as opposed to
|
|
the proposal in <a href="lwg-active.html#1041">1041</a>):
|
|
</p>
|
|
<blockquote><pre>
|
|
MoveOnly x = std::move(*s.remove(i));
|
|
</pre></blockquote>
|
|
<ol>
|
|
<li>
|
|
<tt>remove(i)</tt> transfers ownership of the node from the set to a temporary
|
|
<tt>node_ptr</tt>.
|
|
</li>
|
|
<li>
|
|
The <tt>node_ptr</tt> is dereferenced, and that non-const reference is sent to
|
|
<tt>move</tt> to cast it to an rvalue.
|
|
</li>
|
|
<li>
|
|
The rvalue <tt>MoveOnly</tt> is move constructed into <tt>x</tt> from
|
|
the <tt>node_ptr</tt>.
|
|
</li>
|
|
<li>
|
|
<tt>~node_ptr()</tt> destructs the moved-from <tt>MoveOnly</tt> and deallocates
|
|
the node.
|
|
</li>
|
|
</ol>
|
|
|
|
<p>
|
|
Contrast this with the <a href="lwg-active.html#1041">1041</a> solution:
|
|
</p>
|
|
<blockquote><pre>
|
|
MoveOnly x = std::move(s.extract(i).first);
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
The former requires one move construction for <tt>x</tt> while the latter
|
|
requires two (one into the <tt>pair</tt> and then one into <tt>x</tt>). Either
|
|
of these constructions can throw (say if there is only a copy constructor for
|
|
<tt>x</tt>). With the former, the point of throw is outside of the container
|
|
<tt>s</tt>, after the element has been removed from the container. With the latter,
|
|
one throwing construction takes place prior to the removal of the element, and
|
|
the second takes place after the element is removed.
|
|
</p>
|
|
|
|
</li>
|
|
</ul>
|
|
|
|
<p>
|
|
The "node insertion" API maintains the API associated with inserting <tt>value_type</tt>s
|
|
so the customer can use familiar techniques for getting an iterator to the
|
|
inserted node, or finding out whether it was inserted or not for the "unique"
|
|
containers.
|
|
</p>
|
|
|
|
<p>
|
|
Lightly prototyped. No implementation problems. Appears to work great
|
|
for the client.
|
|
</p>
|
|
|
|
</blockquote>
|
|
</blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="851"></a>851. simplified array construction</h3>
|
|
<p><b>Section:</b> 23.3.2 [array] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Benjamin Kosnik <b>Opened:</b> 2008-06-05 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#array">active issues</a> in [array].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#array">issues</a> in [array].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
This is an issue that came up on the libstdc++ list, where a
|
|
discrepancy between "C" arrays and C++0x's <tt>std::array</tt> was pointed
|
|
out.
|
|
</p>
|
|
|
|
<p>
|
|
In "C," this array usage is possible:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
int ar[] = {1, 4, 6};
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
But for C++,
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
std::array<int> a = { 1, 4, 6 }; // error
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
Instead, the second parameter of the <tt>array</tt> template must be
|
|
explicit, like so:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
std::array<int, 3> a = { 1, 4, 6 };
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
Doug Gregor proposes the following solution, that assumes
|
|
generalized initializer lists.
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
template<typename T, typename... Args>
|
|
inline array<T, sizeof...(Args)>
|
|
make_array(Args&&... args)
|
|
{ return { std::forward<Args>(args)... }; }
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
Then, the way to build an <tt>array</tt> from a list of unknown size is:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
auto a = make_array<T>(1, 4, 6);
|
|
</pre></blockquote>
|
|
|
|
<p><i>[
|
|
San Francisco:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<p>
|
|
Benjamin: Move to Ready?
|
|
</p>
|
|
<p>
|
|
Bjarne: I'm not convinced this is useful enough to add, so I'd like us
|
|
to have time to reflect on it.
|
|
</p>
|
|
<p>
|
|
Alisdair: the constraints are wrong, they should be
|
|
</p>
|
|
<blockquote><pre>
|
|
template<ValueType T, ValueType... Args>
|
|
requires Convertible<Args, T>...
|
|
array<T, sizeof...(Args)> make_array(Args&&... args);
|
|
</pre></blockquote>
|
|
<p>
|
|
Alidair: this would be useful if we had a constexpr version.
|
|
</p>
|
|
<p>
|
|
Bjarne: this is probably useful for arrays with a small number of
|
|
elements, but it's not clearly useful otherwise.
|
|
</p>
|
|
<p>
|
|
Consensus is to move to Open.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p><i>[
|
|
2009-06-07 Daniel adds:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<p>
|
|
I suggest a fix and a simplification of the current proposal: Recent
|
|
prototyping by
|
|
Howard showed, that a fix is required because narrowing conversion
|
|
8.5.4 [dcl.init.list]/6 b.3
|
|
would severely limit the possible distribution of argument types, e.g.
|
|
the expression
|
|
<tt>make_array<double>(1, 2.0)</tt> is ill-formed, because the narrowing
|
|
happens <em>inside</em> the
|
|
function body where no constant expressions exist anymore. Furthermore
|
|
given e.g.
|
|
</p>
|
|
<blockquote><pre>
|
|
int f();
|
|
double g();
|
|
</pre></blockquote>
|
|
<p>
|
|
we probably want to support
|
|
</p>
|
|
<blockquote><pre>
|
|
make_array<double>(f(), g());
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
as well. To make this feasible, the currently suggested expansion
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
{ std::forward<Args>(args)... }
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
needs to be replaced by
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
{ static_cast<T>(std::forward<Args>(args))... }
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
which is safe, because we already ensure convertibility via the
|
|
element-wise <tt>Convertible<Args, T></tt> requirement. Some other fixes are
|
|
necessary: The <tt>ValueType</tt> requirement for the function <em>parameters</em>
|
|
is invalid, because all lvalue arguments will deduce to an lvalue-reference,
|
|
thereby no longer satisfying this requirement.
|
|
</p>
|
|
|
|
<p>
|
|
The suggested simplification is to provide a default-computed effective
|
|
type for the result array based on common_type and decay, in
|
|
unconstrained form:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
template<typename... Args>
|
|
array<typename decay<typename common_type<Args...>::type>::type,
|
|
sizeof...(Args)>
|
|
make_array(Args&&... args);
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
The approach used below is similar to that of <tt>make_pair</tt> and <tt>make_tuple</tt>
|
|
using a symbol <tt>C</tt> to represent the decayed common type [Note: Special
|
|
handling of <tt>reference_wrapper</tt> types is intentionally <em>not</em> provided, because
|
|
our target has so satisfy <tt>ValueType</tt>, thus under the revised proposal only
|
|
an all-<tt>reference_wrapper</tt>-arguments would be well-formed and an array of
|
|
<tt>reference_wrapper</tt> will be constructed]. I do currently not suggest to
|
|
add new concepts reflecting <tt>decay</tt> and <tt>common_type</tt>, but an implementor will
|
|
need something like this to succeed. Note that we use a similar fuzziness for
|
|
<tt>make_pair</tt> and <tt>make_tuple</tt> currently. This fuzziness is not related to
|
|
the currently
|
|
missing <tt>Constructible<Vi, Ti&&></tt> requirement for those functions. The following
|
|
proposal fixes that miss for <tt>make_array</tt>. If the corresponding <tt>C</tt> type
|
|
deduction is
|
|
explicitly wanted for standardization, here the implementation
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
auto concept DC<typename... T> {
|
|
typename type = typename decay<typename common_type<T...>::type>::type;
|
|
}
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
where <tt>C</tt> is identical to <tt>DC<Args...>::type</tt> in the proposed resolution below.
|
|
</p>
|
|
<p>
|
|
I intentionally added no further type relation between type and the concept
|
|
template parameters, but instead added this requirement below to make
|
|
the specification as transparent as possible. As written this concept is
|
|
satisfied, if the corresponding associated type exists.
|
|
</p>
|
|
|
|
<p><b>Suggested Resolution:</b></p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>
|
|
Add to the array synopsis in 23.3 [sequences]:
|
|
</p>
|
|
<blockquote><pre>
|
|
<ins>
|
|
template<ReferentType... Args>
|
|
requires ValueType<C> && IdentityOf<Args> && Constructible<C, Args&&>...
|
|
array<C, sizeof...(Args)>
|
|
make_array(Args&&... args);
|
|
</ins>
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
Append after 23.3.2.9 [array.tuple] Tuple interface to class template array
|
|
the following new section:
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
23.4.1.7 Array creation functions [array.creation]
|
|
</p>
|
|
|
|
<pre>
|
|
<ins>
|
|
template<ReferentType... Args>
|
|
requires ValueType<C> && IdentityOf<Args> && Constructible<C, Args&&>...
|
|
array<C, sizeof...(Args)>
|
|
make_array(Args&&... args);</ins>
|
|
</pre>
|
|
|
|
<blockquote>
|
|
<p><ins>
|
|
Let <tt>C</tt> be <tt>decay<common_type<Args...>::type>::type</tt>.
|
|
</ins></p>
|
|
<p>
|
|
<ins><i>Returns:</i> an <tt>array<C, sizeof...(Args)></tt> initialized with
|
|
<tt>{ static_cast<C>(std::forward<Args>(args))... }</tt>.
|
|
</ins></p>
|
|
</blockquote>
|
|
</blockquote>
|
|
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
</blockquote>
|
|
|
|
<p><i>[
|
|
2009-07 Frankfurt:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<p>
|
|
The proposed resolution uses concepts.
|
|
</p>
|
|
<p>
|
|
Daniel to rewrite the proposed resolution.
|
|
</p>
|
|
<p>
|
|
Leave Open.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p><i>[
|
|
2009-07-25 Daniel provides rewritten proposed resolution.
|
|
]</i></p>
|
|
|
|
|
|
<p><i>[
|
|
2009-10 Santa Cruz:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
Argument for NAD future: everything about this could be added on. This
|
|
does not require changes to the existing text.
|
|
</p></blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>
|
|
Add to the array synopsis in 23.3 [sequences]:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
<ins>template<class... Args>
|
|
array<<i>CT</i>, sizeof...(Args)>
|
|
make_array(Args&&... args);</ins>
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
Append after 23.3.2.9 [array.tuple] "Tuple interface to class template array" the
|
|
following new section:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<ins>XX.X.X.X Array creation functions [array.creation]</ins>
|
|
</p>
|
|
|
|
<pre><ins>
|
|
template<class... Args>
|
|
array<<i>CT</i>, sizeof...(Args)>
|
|
make_array(Args&&... args)
|
|
</ins></pre>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<ins>Let <i>CT</i> be <tt>decay<common_type<Args...>::type>::type</tt>.</ins>
|
|
</p>
|
|
<p>
|
|
<ins><i>Returns:</i> An <tt>array<<i>CT</i>, sizeof...(Args)></tt> initialized with <tt>{
|
|
static_cast<<i>CT</i>>(std::forward<Args>(args))... }</tt>.</ins>
|
|
</p>
|
|
|
|
<p><ins>
|
|
[<i>Example:</i>
|
|
</ins></p>
|
|
<blockquote><pre><ins>
|
|
int i = 0; int& ri = i;
|
|
make_array(42u, i, 2.78, ri);
|
|
</ins></pre></blockquote>
|
|
<p><ins>
|
|
returns an array of type
|
|
</ins></p>
|
|
<blockquote><pre><ins>
|
|
array<double, 4>
|
|
</ins></pre></blockquote>
|
|
|
|
<p><ins>
|
|
—<i>end example</i>]</ins>
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="877"></a>877. to <tt>throw()</tt> or to <i>Throw:</i> Nothing.</h3>
|
|
<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-08-23 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#library">active issues</a> in [library].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#library">issues</a> in [library].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
|
|
Recent changes to
|
|
the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">working
|
|
draft</a> have introduced a gratuitous inconsistency with the C++ 2003
|
|
version of the specification with respect to exception guarantees
|
|
provided by standard functions. While the C++ 2003 standard
|
|
consistenly uses the empty exception specification, <tt>throw()</tt>,
|
|
to declare functions that are guaranteed not to throw exceptions, the
|
|
current working draft contains a number of "<i>Throws:</i> Nothing."
|
|
clause to specify essentially the same requirement. The difference
|
|
between the two approaches is that the former specifies the behavior
|
|
of programs that violate the requirement (<tt>std::unexpected()</tt>
|
|
is called) while the latter leaves the behavior undefined.
|
|
|
|
</p>
|
|
<p>
|
|
|
|
A survey of the working draft reveals that there are a total of 209
|
|
occurrences of <tt>throw()</tt> in the library portion of the spec,
|
|
the majority in clause 18, a couple (literally) in 19, a handful in
|
|
20, a bunch in 22, four in 24, one in 27, and about a dozen in D.9.
|
|
|
|
</p>
|
|
<p>
|
|
|
|
There are also 203 occurrences of "<i>Throws:</i> Nothing." scattered
|
|
throughout the spec.
|
|
|
|
</p>
|
|
<p>
|
|
|
|
While sometimes there are good reasons to use the "<i>Throws:</i>
|
|
Nothing." approach rather than making use of <tt>throw()</tt>, these
|
|
reasons do not apply in most of the cases where this new clause has
|
|
been introduced and the empty exception specification would be a
|
|
better approach.
|
|
|
|
</p>
|
|
<p>
|
|
|
|
First, functions declared with the empty exception specification
|
|
permit compilers to generate better code for calls to such
|
|
functions. In some cases, the compiler might even be able to eliminate
|
|
whole chunks of user-written code when instantiating a generic
|
|
template on a type whose operations invoked from the template
|
|
specialization are known not to throw. The prototypical example are
|
|
the <tt>std::uninitialized_copy()</tt>
|
|
and <tt>std::uninitialized_fill()</tt> algorithms where the
|
|
entire <tt>catch(...)</tt> block can be optimized away.
|
|
|
|
</p>
|
|
<p>
|
|
|
|
For example, given the following definition of
|
|
the <tt>std::uninitialized_copy</tt> function template and a
|
|
user-defined type <tt>SomeType</tt>:
|
|
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
template <class InputIterator, class ForwardIterator>
|
|
ForwardIterator
|
|
uninitialized_copy (InputIterator first, InputIterator last, ForwardIterator res)
|
|
{
|
|
typedef iterator_traits<ForwardIterator>::value_type ValueType;
|
|
|
|
ForwardIterator start = res;
|
|
|
|
try {
|
|
for (; first != last; ++first, ++res)
|
|
::new (&*res) ValueType (*first);
|
|
}
|
|
catch (...) {
|
|
for (; start != res; --start)
|
|
(&*start)->~ValueType ();
|
|
throw;
|
|
}
|
|
return res;
|
|
}
|
|
|
|
struct SomeType {
|
|
SomeType (const SomeType&) <ins>throw ()</ins>;
|
|
}</pre>
|
|
</blockquote>
|
|
<p>
|
|
|
|
compilers are able to emit the following efficient specialization
|
|
of <tt>std::uninitialized_copy<const SomeType*, SomeType*></tt>
|
|
(note that the <tt>catch</tt> block has been optimized away):
|
|
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
template <> SomeType*
|
|
uninitialized_copy (const SomeType *first, const SomeType *last, SomeType *res)
|
|
{
|
|
for (; first != last; ++first, ++res)
|
|
::new (res) SomeType (*first);
|
|
|
|
return res;
|
|
}</pre>
|
|
</blockquote>
|
|
<p>
|
|
|
|
Another general example is default constructors which, when decorated
|
|
with <tt>throw()</tt>, allow the compiler to eliminate the
|
|
implicit <tt>try</tt> and <tt>catch</tt> blocks that it otherwise must
|
|
emit around each the invocation of the constructor
|
|
in <i>new-expressions</i>.
|
|
|
|
</p>
|
|
<p>
|
|
|
|
For example, given the following definitions of
|
|
class <tt>MayThrow</tt> and <tt>WontThrow</tt> and the two
|
|
statements below:
|
|
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
struct MayThrow {
|
|
MayThrow ();
|
|
};
|
|
|
|
struct WontThrow {
|
|
WontThrow () <ins>throw ()</ins>;
|
|
};
|
|
|
|
MayThrow *a = new MayThrow [N];
|
|
WontThrow *b = new WontThrow [N];</pre>
|
|
|
|
</blockquote>
|
|
<p>
|
|
|
|
the compiler generates the following code for the first statement:
|
|
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
MayThrow *a;
|
|
{
|
|
MayThrow *first = operator new[] (N * sizeof (*a));
|
|
MayThrow *last = first + N;
|
|
MayThrow *next = first;
|
|
try {
|
|
for ( ; next != last; ++next)
|
|
new (next) MayThrow;
|
|
}
|
|
catch (...) {
|
|
for ( ; first != first; --next)
|
|
next->~MayThrow ();
|
|
operator delete[] (first);
|
|
throw;
|
|
}
|
|
a = first;
|
|
}</pre>
|
|
</blockquote>
|
|
<p>
|
|
|
|
but it is can generate much more compact code for the second statement:
|
|
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
WontThrow *b = operator new[] (N * sizeof (*b));
|
|
WontThrow *last = b + N;
|
|
for (WontThrow *next = b; next != last; ++next)
|
|
new (next) WontThrow;
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
|
|
Second, in order for users to get the maximum benefit out of the new
|
|
<tt>std::has_nothrow_xxx</tt> traits when using standard library types
|
|
it will be important for implementations to decorate all non throwing
|
|
copy constructors and assignment operators with <tt>throw()</tt>. Note
|
|
that while an optimizer may be able to tell whether a function without
|
|
an explicit exception specification can throw or not based on its
|
|
definition, it can only do so when it can see the source code of the
|
|
definition. When it can't it must assume that the function may
|
|
throw. To prevent violating the One Definition Rule,
|
|
the <tt>std::has_nothrow_xxx</tt> trait must return the most
|
|
pessimistic guess across all translation units in the program, meaning
|
|
that <tt>std::has_nothrow_xxx<T>::value</tt> must evaluate to
|
|
<tt>false</tt> for any <tt>T</tt> whose <tt>xxx</tt>
|
|
(where <tt>xxx</tt> is default or copy ctor, or assignment operator)
|
|
is defined out-of-line.
|
|
|
|
</p>
|
|
<p>
|
|
|
|
<b>Counterarguments:</b>
|
|
|
|
</p>
|
|
<p>
|
|
|
|
During the discussion of this issue
|
|
on <a href="mailto:c++std-lib@accu.org">c++std-lib@accu.org</a>
|
|
(starting with post <tt>c++std-lib-21950</tt>) the following arguments
|
|
in favor of the "<i>Throws:</i> Nothing." style have been made.
|
|
|
|
</p>
|
|
<ol>
|
|
<li>
|
|
|
|
Decorating functions that cannot throw with the empty exception
|
|
specification can cause the compiler to generate suboptimal code for
|
|
the implementation of the function when it calls other functions that
|
|
aren't known to the compiler not to throw (i.e., that aren't decorated
|
|
with <tt>throw()</tt> even if they don't actually throw). This is a
|
|
common situation when the called function is a C or POSIX function.
|
|
|
|
</li>
|
|
<li>
|
|
|
|
Alternate, proprietary mechanisms exist (such as
|
|
GCC <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>
|
|
or Visual
|
|
C++ <a href="http://msdn.microsoft.com/en-us/library/49147z04(VS.80).aspx"><tt>__declspec(nothrow)</tt></a>)
|
|
that let implementers mark up non-throwing functions, often without
|
|
the penalty mentioned in (1) above. The C++ standard shouldn't
|
|
preclude the use of these potentially more efficient mechanisms.
|
|
|
|
</li>
|
|
<li>
|
|
|
|
There are functions, especially function templates, that invoke
|
|
user-defined functions that may or may not be
|
|
declared <tt>throw()</tt>. Declaring such functions with the empty
|
|
exception specification will cause compilers to generate suboptimal
|
|
code when the user-defined function isn't also declared not to throw.
|
|
|
|
</li>
|
|
</ol>
|
|
<p>
|
|
|
|
The answer to point (1) above is that implementers can (and some have)
|
|
declare functions with <tt>throw()</tt> to indicate to the compiler
|
|
that calls to the function can safely be assumed not to throw in order
|
|
to allow it to generate efficient code at the call site without also
|
|
having to define the functions the same way and causing the compiler
|
|
to generate suboptimal code for the function definition. That is, the
|
|
function is declared with <tt>throw()</tt> in a header but it's
|
|
defined without it in the source file. The <tt>throw()</tt>
|
|
declaration is suppressed when compiling the definition to avoid
|
|
compiler errors. This technique, while strictly speaking no permitted
|
|
by the language, is safe and has been employed in practice. For
|
|
example, the GNU C library takes this approach. Microsoft Visual C++
|
|
takes a similar approach by simply assuming that no function with C
|
|
language linkage can throw an exception unless it's explicitly
|
|
declared to do so using the language extension <tt>throw(...)</tt>.
|
|
|
|
</p>
|
|
<p>
|
|
|
|
Our answer to point (2) above is that there is no existing practice
|
|
where C++ Standard Library implementers have opted to make use of the
|
|
proprietary mechanisms to declare functions that don't throw. The
|
|
language provides a mechanism specifically designed for this
|
|
purpose. Avoiding its use in the specification itself in favor of
|
|
proprietary mechanisms defeats the purpose of the feature. In
|
|
addition, making use of the empty exception specification
|
|
inconsistently, in some areas of the standard, while conspicuously
|
|
avoiding it and making use of the "<i>Throws:</i> Nothing." form in
|
|
others is confusing to users.
|
|
|
|
</p>
|
|
<p>
|
|
|
|
The answer to point (3) is simply to exercise caution when declaring
|
|
functions and especially function templates with the empty exception
|
|
specification. Functions that required not to throw but that may call
|
|
back into user code are poor candidates for the empty exception
|
|
specification and should instead be specified using "<i>Throws:</i>
|
|
Nothing." clause.
|
|
|
|
</p>
|
|
|
|
<p><i>[
|
|
2009-07 Frankfurt
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<p>
|
|
We need someone to do an extensive review.
|
|
</p>
|
|
<p>
|
|
NAD Future.
|
|
</p>
|
|
</blockquote>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
|
|
We propose two possible solutions. Our recommendation is to adopt
|
|
Option 1 below.
|
|
|
|
</p>
|
|
<p>
|
|
|
|
<b>Option 1:</b>
|
|
|
|
</p>
|
|
<p>
|
|
|
|
Except for functions or function templates that make calls back to
|
|
user-defined functions that may not be declared <tt>throw()</tt>
|
|
replace all occurrences of the "<i>Throws:</i> Nothing." clause with
|
|
the empty exception specification. Functions that are required not to
|
|
throw but that make calls back to user code should be specified to
|
|
"<i>Throw:</i> Nothing."
|
|
|
|
</p>
|
|
<p>
|
|
|
|
<b>Option 2:</b>
|
|
|
|
</p>
|
|
<p>
|
|
|
|
For consistency, replace all occurrences of the empty exception
|
|
specification with a "<i>Throws:</i> Nothing." clause.
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="933"></a>933. Unique_ptr defect</h3>
|
|
<p><b>Section:</b> 20.8.1.2.5 [unique.ptr.single.modifiers] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-11-27 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#unique.ptr.single.modifiers">issues</a> in [unique.ptr.single.modifiers].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
If we are supporting stateful deleters, we need an overload for
|
|
<tt>reset</tt> that
|
|
takes a deleter as well.
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
void reset( pointer p, deleter_type d);
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
We probably need two overloads to support move-only deleters, and
|
|
this
|
|
sounds uncomfortably like the two constructors I have been ignoring
|
|
for
|
|
now...
|
|
</p>
|
|
|
|
<p><i>[
|
|
Batavia (2009-05):
|
|
]</i></p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
Howard comments that we have the functionality via move-assigment.
|
|
</p>
|
|
<p>
|
|
Move to Open.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p><i>[
|
|
2009-10 Santa Cruz:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
Mark as NAD Future.
|
|
</p></blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="935"></a>935. clock error handling needs to be specified</h3>
|
|
<p><b>Section:</b> 20.12.7 [time.clock] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-11-24 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Each of the three clocks specified in Clocks 20.12.7 [time.clock]
|
|
provides the member function:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
static time_point now();
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
The semantics specified by Clock requirements 20.12.3 [time.clock.req]
|
|
make no mention of error handling. Thus the function may throw <tt>bad_alloc</tt>
|
|
or an implementation-defined exception (17.6.5.12 [res.on.exception.handling]
|
|
paragraph 4).
|
|
</p>
|
|
|
|
<p>
|
|
Some implementations of these functions on POSIX, Windows, and
|
|
presumably on other operating systems, may fail in ways only detectable
|
|
at runtime. Some failures on Windows are due to supporting chipset
|
|
errata and can even occur after successful calls to a clock's <tt>now()</tt>
|
|
function.
|
|
</p>
|
|
|
|
<p>
|
|
These functions are used in cases where exceptions are not appropriate
|
|
or where the specifics of the exception or cause of error need to be
|
|
available to the user. See
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2828.html">N2828</a>,
|
|
<i>Library Support for hybrid error
|
|
handling (Rev 1)</i>, for more specific discussion of use cases. Thus some change in
|
|
the interface of now is required.
|
|
</p>
|
|
|
|
<p>
|
|
The proposed resolution has been implemented in the Boost version of the
|
|
chrono library. No problems were encountered.
|
|
</p>
|
|
|
|
<p><i>[
|
|
Batavia (2009-05):
|
|
]</i></p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
We recommend this issue be deferred until the next Committee Draft
|
|
has been issued and the prerequisite paper has been accepted.
|
|
</p>
|
|
<p>
|
|
Move to Open.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p><i>[
|
|
2009-10 Santa Cruz:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
Mark as NAD future. Too late to make this change without having already
|
|
accepted the hybrid error handling proposal.
|
|
</p></blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Accept the proposed wording of
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2828.html">N2828</a>,
|
|
<i>Library Support for hybrid error handling (Rev 1)</i>.
|
|
</p>
|
|
|
|
<p>
|
|
Change <tt>Clock</tt> requirements 20.12.3 [time.clock.req] as indicated:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-2- In Table 55 <tt>C1</tt> and <tt>C2</tt> denote clock types. <tt>t1</tt> and
|
|
<tt>t2</tt> are values returned by <tt>C1::now()</tt> where the call
|
|
returning <tt>t1</tt> happens before (1.10) the call returning <tt>t2</tt> and
|
|
both of these calls happen before <tt>C1::time_point::max()</tt>.
|
|
<ins><tt>ec</tt> denotes an object of type <tt>error_code</tt>
|
|
(19.5.2.1 [syserr.errcode.overview]).</ins>
|
|
</p>
|
|
|
|
<table border="1">
|
|
<caption>Table 55 — Clock requirements</caption>
|
|
<tr>
|
|
<th>Expression</th><th>Return type</th><th>Operational semantics</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>...</td>
|
|
<td>...</td>
|
|
<td>...</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>C1::now()</tt></td>
|
|
<td><tt>C1::time_point</tt></td>
|
|
<td>Returns a <tt>time_point</tt> object representing the current point in time.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt><ins>C1::now(ec)</ins></tt></td>
|
|
<td><tt><ins>C1::time_point</ins></tt></td>
|
|
<td><ins>Returns a <tt>time_point</tt> object representing the current point in time.</ins>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
</blockquote>
|
|
|
|
<p>
|
|
Change class <tt>system_clock</tt> 20.12.7.1 [time.clock.system] as indicated:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
static time_point now(<ins>error_code& ec=throws()</ins>);
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
Change class <tt>monotonic_clock</tt> X [time.clock.monotonic] as indicated:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
static time_point now(<ins>error_code& ec=throws()</ins>);
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
Change class <tt>high_resolution_clock</tt> 20.12.7.3 [time.clock.hires] as indicated:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
static time_point now(<ins>error_code& ec=throws()</ins>);
|
|
</pre></blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="936"></a>936. Mutex type overspecified</h3>
|
|
<p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-12-05 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#thread.mutex.requirements">active issues</a> in [thread.mutex.requirements].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Duplicate of:</b> <a href="lwg-active.html#961">961</a></p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
|
|
|
|
<p>
|
|
30.4.1 [thread.mutex.requirements] describes the requirements for a type to be
|
|
a "Mutex type". A Mutex type can be used as the template argument for
|
|
the <tt>Lock</tt> type that's passed to <tt>condition_variable_any::wait</tt> (although
|
|
<tt>Lock</tt> seems like the wrong name here, since <tt>Lock</tt> is given a different
|
|
formal meaning in 30.4.2 [thread.lock]) and, although the WD doesn't quite say
|
|
so, as the template argument for <tt>lock_guard</tt> and <tt>unique_lock</tt>.
|
|
</p>
|
|
|
|
<p>
|
|
The requirements for a Mutex type include:
|
|
</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<tt>m.lock()</tt> shall be well-formed and have [described] semantics, including a return type of <tt>void</tt>.
|
|
</li>
|
|
<li>
|
|
<tt>m.try_lock()</tt> shall be well-formed and have [described] semantics, including a return type of <tt>bool</tt>.
|
|
</li>
|
|
<li>
|
|
<tt>m.unlock()</tt> shall be well-formed and have [described] semantics, including a return type of <tt>void</tt>.
|
|
</li>
|
|
</ul>
|
|
|
|
<p>
|
|
Also, a Mutex type "shall not be copyable nor movable".
|
|
</p>
|
|
|
|
<p>
|
|
The latter requirement seems completely irrelevant, and the three
|
|
requirements on return types are tighter than they need to be. For
|
|
example, there's no reason that <tt>lock_guard</tt> can't be instantiated with a
|
|
type that's copyable. The rule is, in fact, that <tt>lock_guard</tt>, etc. won't
|
|
try to copy objects of that type. That's a constraint on locks, not on
|
|
mutexes. Similarly, the requirements for <tt>void</tt> return types are
|
|
unnecessary; the rule is, in fact, that <tt>lock_guard</tt>, etc. won't use any
|
|
returned value. And with the return type of <tt>bool</tt>, the requirement should
|
|
be that the return type is convertible to <tt>bool</tt>.
|
|
</p>
|
|
|
|
<p><i>[
|
|
Summit:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<p>
|
|
Move to open. Related to conceptualization and should probably be tackled as part of that.
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
The intention is not only to place a constraint on what types such as
|
|
<tt>lock_guard</tt> may do with mutex types, but on what any code, including user
|
|
code, may do with mutex types. Thus the constraints as they are apply to
|
|
the mutex types themselves, not the current users of mutex types in the
|
|
standard.
|
|
</li>
|
|
<li>
|
|
This is a low priority issue; the wording as it is may be overly
|
|
restrictive but this may not be a real issue.
|
|
</li>
|
|
</ul>
|
|
</blockquote>
|
|
|
|
<p><i>[
|
|
Post Summit Anthony adds:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<p>
|
|
Section 30.4.1 [thread.mutex.requirements] conflates the
|
|
requirements on a generic Mutex type (including user-supplied mutexes)
|
|
with the requirements placed on the standard-supplied mutex types in an
|
|
attempt to group everything together and save space.
|
|
</p>
|
|
<p>
|
|
When applying concepts to chapter 30, I suggest that the concepts
|
|
<tt>Lockable</tt> and <tt>TimedLockable</tt> embody the requirements for
|
|
*use* of a mutex type as required by
|
|
<tt>unique_lock/lock_guard/condition_variable_any</tt>. These should be
|
|
relaxed as Pete describes in the issue. The existing words in 30.4.1 [thread.mutex.requirements] are requirements on all of
|
|
<tt>std::mutex</tt>, <tt>std::timed_mutex</tt>,
|
|
<tt>std::recursive_mutex</tt> and <tt>std::recursive_timed_mutex</tt>,
|
|
and should be rephrased as such.
|
|
</p>
|
|
</blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="961"></a>961. Various threading bugs #11</h3>
|
|
<p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#thread.mutex.requirements">active issues</a> in [thread.mutex.requirements].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Duplicate of:</b> <a href="lwg-active.html#936">936</a></p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
30.4.1 [thread.mutex.requirements] describes required member
|
|
functions of mutex types, and requires that they throw exceptions under
|
|
certain circumstances. This is overspecified. User-defined types can
|
|
abort on such errors without affecting the operation of templates
|
|
supplied by standard-library.
|
|
</p>
|
|
|
|
<p><i>[
|
|
Summit:
|
|
]</i></p>
|
|
|
|
<blockquote><p>
|
|
Move to open. Related to conceptualization and should probably be
|
|
tackled as part of that.
|
|
</p></blockquote>
|
|
|
|
<p><i>[
|
|
2009-10 Santa Cruz:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<p>
|
|
Would be OK to leave it as is for time constraints, could loosen later.
|
|
</p>
|
|
|
|
<p>
|
|
Mark as NAD Future.
|
|
</p>
|
|
</blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1025"></a>1025. The library should provide more specializations for <tt>std::hash</tt></h3>
|
|
<p><b>Section:</b> 20.9.13 [unord.hash] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#unord.hash">active issues</a> in [unord.hash].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#unord.hash">issues</a> in [unord.hash].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p><b>Addresses UK 208 [CD1]</b></p>
|
|
|
|
<p>
|
|
<tt>std::hash</tt> should be implemented for much more of the standard
|
|
library. In particular for <tt>pair</tt>, <tt>tuple</tt> and all the
|
|
standard containers.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1031"></a>1031. Need <tt>shared_ptr</tt> conversion to a <tt>unique_ptr</tt></h3>
|
|
<p><b>Section:</b> 20.8.2.2 [util.smartptr.shared] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p><b>Addresses US 78 [CD1]</b></p>
|
|
|
|
<p>
|
|
There is presently no way to convert directly from a <tt>shared_ptr</tt> to a
|
|
<tt>unique_ptr</tt>. Add an interface that performs the conversion.
|
|
</p>
|
|
|
|
<p><i>[
|
|
Summit:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
We look forward to a paper on this topic. We recommend no action until a
|
|
paper is available. We believe that the shared pointer must use the default
|
|
deleter for the conversion to succeed.
|
|
</p></blockquote>
|
|
|
|
<p><i>[
|
|
Peter Dimov adds:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
This is basically a request for <tt>shared_ptr<>::release</tt> in
|
|
disguise, with all the associated problems. Not a good idea.
|
|
</p></blockquote>
|
|
|
|
<p><i>[
|
|
2009-07 post-Frankfurt:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<p>
|
|
The rationale for the omission of a release() member function from shared_ptr is given in:
|
|
<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>
|
|
</p>
|
|
<p>
|
|
The implementation of such a member is non-trivial (and maybe
|
|
impossible), because it would need to account for the deleter.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p><i>[
|
|
2009-07-26 Howard sets to Tentatively NAD Future.
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<p>
|
|
I took an online poll and got 3 votes for NAD and 3 for NAD Future. Personally
|
|
I prefer NAD Future as this does refer to an extension that could conceivably be
|
|
considered beyond C++0X.
|
|
</p>
|
|
|
|
<p>
|
|
However such an extension would need to solve a couple of problems:
|
|
</p>
|
|
|
|
<ol>
|
|
<li>What is the interface for such a conversion when the <tt>shared_ptr</tt> does
|
|
not have unique ownership? Throw an exception? Create a null <tt>unique_ptr</tt>?
|
|
Undefined behavior?
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
How does one handle custom deleters given to the <tt>shared_ptr</tt> constructor?
|
|
</p>
|
|
<p>
|
|
I do not believe it is possible to implement a general answer to this question.
|
|
The <tt>shared_ptr</tt> deleter is a run time (or construction time) characteristic.
|
|
The <tt>unique_ptr</tt> deleter is a compile time characteristic. In general one
|
|
can not know to what type of <tt>unqiue_ptr</tt> you are converting to.
|
|
</p>
|
|
<p>
|
|
One answer is for the user of the conversion to specify the deleter type and perhaps
|
|
throw an exception if the specification turns out to be incorrect.
|
|
</p>
|
|
<p>
|
|
Another answer is for the conversion to only be valid when the underlying deleter
|
|
is <tt>default_delete</tt>. We would probalby need to specify that this is indeed the
|
|
underlying deleter of a <tt>shared_ptr</tt> when a custom deleter is not given in
|
|
the constructor.
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>
|
|
At any rate, there are non-trivial design issues which would need to be implemented
|
|
and tested in the field for usability prior to standardization.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p><i>[
|
|
2009 Santa Cruz:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
Moved to NAD Future.
|
|
</p></blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1041"></a>1041. Add associative/unordered container functions that allow to extract elements</h3>
|
|
<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p><b>Addresses UK 239 [CD1]</b></p>
|
|
|
|
<p>
|
|
It is not possible to take a move-only key out of an unordered
|
|
container, such as (<tt>multi</tt>)<tt>set</tt> or
|
|
(<tt>multi</tt>)<tt>map</tt>, or the new unordered containers.
|
|
</p>
|
|
|
|
<p>
|
|
Add below <tt>a.erase(q)</tt>, <tt>a.extract(q)</tt>, with the following notation:
|
|
</p>
|
|
<p>
|
|
<tt>a.extract(q)></tt>, Return type <tt>pair<key, iterator></tt>
|
|
Extracts the element pointed to by <tt>q</tt> and erases it from the
|
|
<tt>set</tt>. Returns a <tt>pair</tt> containing the value pointed to by
|
|
<tt>q</tt> and an <tt>iterator</tt> pointing to the element immediately
|
|
following <tt>q</tt> prior to the element being erased. If no such
|
|
element exists,returns <tt>a.end()</tt>.
|
|
</p>
|
|
|
|
<p><i>[
|
|
Summit:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
We look forward to a paper on this topic. We recommend no action until a
|
|
paper is available. The paper would need to address exception safety.
|
|
</p></blockquote>
|
|
|
|
<p><i>[
|
|
Post Summit Alisdair adds:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
Would <tt>value_type</tt> be a better return type than <tt>key_type</tt>?
|
|
</p></blockquote>
|
|
|
|
<p><i>[
|
|
2009-07 post-Frankfurt:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
Leave Open. Alisdair to contact Chris Jefferson about this.
|
|
</p></blockquote>
|
|
|
|
<p><i>[
|
|
2009-09-20 Howard adds:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
See the 2009-09-19 comment of <a href="lwg-active.html#839">839</a> for an API which
|
|
accomplishes this functionality and also addresses several other use
|
|
cases which this proposal does not.
|
|
</p></blockquote>
|
|
|
|
<p><i>[
|
|
2009-10 Santa Cruz:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
Mark as NAD Future. No consensus to make the change at this time.
|
|
</p></blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
In 23.2.4 [associative.reqmts] Table 85, add:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 85 -- Associative container requirements (in addition to container)</caption>
|
|
<tr>
|
|
<th>Expression</th>
|
|
<th>Return type</th>
|
|
<th>Assertion/note<br/>pre-/post-condition</th>
|
|
<th>Complexity</th>
|
|
</tr>
|
|
<tr>
|
|
<td><tt>a.erase(q)</tt></td>
|
|
<td>...</td>
|
|
<td>...</td>
|
|
<td>...</td>
|
|
</tr>
|
|
<tr>
|
|
<td><ins><tt>a.extract(q)</tt></ins></td>
|
|
<td><ins><tt>pair<key_type, iterator></tt></ins></td>
|
|
<td><ins>Extracts the element pointed to by <tt>q</tt> and erases it from the <tt>set</tt>.
|
|
Returns a <tt>pair</tt> containing the value pointed to by <tt>q</tt> and an <tt>iterator</tt>
|
|
pointing to the element immediately following <tt>q</tt> prior to the element being
|
|
erased. If no such element
|
|
exists, returns <tt>a.end()</tt>.</ins></td>
|
|
<td><ins>amortized constant</ins></td>
|
|
</tr>
|
|
</table>
|
|
</blockquote>
|
|
|
|
<p>
|
|
In 23.2.5 [unord.req] Table 87, add:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 87 -- Unordered associative container requirements (in addition to container)</caption>
|
|
<tr>
|
|
<th>Expression</th>
|
|
<th>Return type</th>
|
|
<th>Assertion/note<br/>pre-/post-condition</th>
|
|
<th>Complexity</th>
|
|
</tr>
|
|
<tr>
|
|
<td><tt>a.erase(q)</tt></td>
|
|
<td>...</td>
|
|
<td>...</td>
|
|
<td>...</td>
|
|
</tr>
|
|
<tr>
|
|
<td><ins><tt>a.extract(q)</tt></ins></td>
|
|
<td><ins><tt>pair<key_type, iterator></tt></ins></td>
|
|
<td><ins>Extracts the element pointed to by <tt>q</tt> and erases it from the <tt>set</tt>.
|
|
Returns a <tt>pair</tt> containing the value pointed to by <tt>q</tt> and an <tt>iterator</tt>
|
|
pointing to the element immediately following <tt>q</tt> prior to the element being
|
|
erased. If no such element
|
|
exists, returns <tt>a.end()</tt>.</ins></td>
|
|
<td><ins>amortized constant</ins></td>
|
|
</tr>
|
|
</table>
|
|
</blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1052"></a>1052. <tt>reverse_iterator::operator-></tt> should also support smart pointers</h3>
|
|
<p><b>Section:</b> 24.5.1.3.5 [reverse.iter.opref] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#reverse.iter.opref">issues</a> in [reverse.iter.opref].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p><b>Addresses UK 281 [CD1]</b></p>
|
|
|
|
<p>
|
|
The current specification for return value for <tt>reverse_iterator::operator-></tt>
|
|
will always be a true pointer type, but <tt>reverse_iterator</tt> supports proxy
|
|
iterators where the pointer type may be some kind of 'smart pointer'.
|
|
</p>
|
|
|
|
<p><i>[
|
|
Summit:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<p>
|
|
<tt>move_iterator</tt> avoids this problem by returning a value of the wrapped
|
|
Iterator type.
|
|
study group formed to come up with a suggested resolution.
|
|
</p>
|
|
<p>
|
|
<tt>move_iterator</tt> solution shown in proposed wording.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p><i>[
|
|
2009-07 post-Frankfurt:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
Howard to deconceptize. Move to Review after that happens.
|
|
</p></blockquote>
|
|
|
|
<p><i>[
|
|
2009-08-01 Howard deconceptized:
|
|
]</i></p>
|
|
|
|
|
|
<p><i>[
|
|
2009-10 Santa Cruz:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<p>
|
|
We can't think of any reason we can't just define reverse
|
|
iterator's pointer types to be the same as the underlying iterator's
|
|
pointer type, and get it by calling the right arrow directly.
|
|
</p>
|
|
<p>
|
|
Here is the proposed wording that was replaced:
|
|
</p>
|
|
<blockquote><pre>
|
|
template <class Iterator>
|
|
class reverse_iterator {
|
|
...
|
|
typedef <del>typename iterator_traits<</del>Iterator<del>>::pointer</del> pointer;
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
Change 24.5.1.3.5 [reverse.iter.opref]:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
pointer operator->() const;
|
|
</pre>
|
|
<blockquote><p>
|
|
<i>Returns:</i>
|
|
</p><blockquote><pre>
|
|
<del>&(operator*());</del>
|
|
<ins>this->tmp = current;</ins>
|
|
<ins>--this->tmp;</ins>
|
|
<ins>return this->tmp;</ins>
|
|
</pre></blockquote>
|
|
</blockquote>
|
|
</blockquote>
|
|
|
|
</blockquote>
|
|
|
|
<p><i>[
|
|
2010-03-03 Daniel opens:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<ol>
|
|
|
|
<li>
|
|
There is a minor problem with the exposition-only declaration of the private
|
|
member <tt>deref_tmp</tt> which is modified in a const member function (and the
|
|
same problem occurs in the specification of <tt>operator*</tt>). The fix is to
|
|
make it a mutable member.
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
The more severe problem is that the resolution for some reasons
|
|
does not explain in the rationale why it was decided to differ from
|
|
the suggested fix (using <tt>deref_tmp</tt> instead of <tt>tmp</tt>) in the
|
|
[ 2009-10 Santa Cruz] comment:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
this->deref_tmp = current;
|
|
--this->deref_tmp;
|
|
return this->deref_tmp;
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
combined with the change of
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
typedef typename iterator_traits<Iterator>::pointer pointer;
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
to
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
typedef Iterator pointer;
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
The problem of the agreed on wording is that the following rather
|
|
typical example, that compiled with the wording before 1052 had
|
|
been applied, won't compile anymore:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
#include <iterator>
|
|
#include <utility>
|
|
|
|
int main() {
|
|
typedef std::pair<int, double> P;
|
|
P op;
|
|
std::reverse_iterator<P*> ri(&op + 1);
|
|
ri->first; // Error
|
|
}
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
Comeau online returns (if a correspondingly changed
|
|
<tt>reverse_iterator</tt> is used):
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
"error: expression must have class type
|
|
return deref_tmp.operator->();
|
|
^
|
|
detected during instantiation of "Iterator
|
|
reverse_iterator<Iterator>::operator->() const [with
|
|
Iterator=std::pair<int, double> *]""
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
Thus the change will break valid, existing code based
|
|
on <tt>std::reverse_iterator</tt>.
|
|
</p>
|
|
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
<p>
|
|
IMO the suggestion proposed in the comment is a necessary fix, which harmonizes
|
|
with the similar specification of <tt>std::move_iterator</tt> and properly
|
|
reflects the recursive nature of the evaluation of <tt>operator-></tt>
|
|
overloads.
|
|
</p>
|
|
|
|
<p>
|
|
Suggested resolution:
|
|
</p>
|
|
|
|
<ol>
|
|
|
|
<li>
|
|
<p>
|
|
In the class template <tt>reverse_iterator</tt> synopsis of 24.5.1.1 [reverse.iterator]
|
|
change as indicated:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
namespace std {
|
|
template <class Iterator>
|
|
class reverse_iterator : public
|
|
iterator<typename iterator_traits<Iterator>::iterator_category,
|
|
typename iterator_traits<Iterator>::value_type,
|
|
typename iterator_traits<Iterator>::difference_type,
|
|
<del>typename iterator_traits<</del>Iterator<del>>::pointer</del>,
|
|
typename iterator_traits<Iterator>::reference> {
|
|
public:
|
|
[..]
|
|
typedef <del>typename iterator_traits<</del>Iterator<del>>::pointer</del> pointer;
|
|
[..]
|
|
protected:
|
|
Iterator current;
|
|
private:
|
|
<ins>mutable</ins> Iterator deref_tmp; // exposition only
|
|
};
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li>
|
|
Change 24.5.1.3.5 [reverse.iter.opref]/1 as indicated:
|
|
|
|
<blockquote><pre>
|
|
pointer operator->() const;
|
|
</pre>
|
|
|
|
<blockquote><p>
|
|
1 <i><del>Returns</del> <ins>Effects</ins>:</i> <del><tt>&(operator*())</tt>.</del>
|
|
</p><blockquote><pre>
|
|
<ins>deref_tmp = current;</ins>
|
|
<ins>--deref_tmp;</ins>
|
|
<ins>return deref_tmp;</ins>
|
|
</pre></blockquote>
|
|
</blockquote>
|
|
</blockquote>
|
|
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
</blockquote>
|
|
|
|
<p><i>[
|
|
2010 Pittsburgh:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<p>
|
|
We prefer to make to use a local variable instead of <tt>deref_tmp</tt> within
|
|
<tt>operator->()</tt>. And although this means that the <tt>mutable</tt>
|
|
change is no longer needed, we prefer to keep it because it is needed for
|
|
<tt>operator*()</tt> anyway.
|
|
</p>
|
|
|
|
<p>
|
|
Here is the proposed wording that was replaced:
|
|
</p>
|
|
|
|
<blockquote class="note">
|
|
<p>
|
|
Change 24.5.1.3.5 [reverse.iter.opref]:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
pointer operator->() const;
|
|
</pre>
|
|
|
|
<blockquote><p>
|
|
<i>Returns:</i>
|
|
</p><blockquote><pre>
|
|
<del>&(operator*());</del>
|
|
<ins>deref_tmp = current;
|
|
--deref_tmp;
|
|
return deref_tmp::operator->();</ins>
|
|
</pre></blockquote>
|
|
|
|
</blockquote>
|
|
</blockquote>
|
|
|
|
|
|
</blockquote>
|
|
</blockquote>
|
|
|
|
<p><i>[
|
|
2010-03-10 Howard adds:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<p>
|
|
Here are three tests that the current proposed wording passes, and no
|
|
other solution I've seen passes all three:
|
|
</p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>
|
|
Proxy pointer support:
|
|
</p>
|
|
<blockquote><pre>
|
|
#include <iterator>
|
|
#include <cassert>
|
|
|
|
struct X { int m; };
|
|
|
|
X x;
|
|
|
|
struct IterX {
|
|
typedef std::bidirectional_iterator_tag iterator_category;
|
|
typedef X& reference;
|
|
struct pointer
|
|
{
|
|
pointer(X& v) : value(v) {}
|
|
X& value;
|
|
X* operator->() const {return &value;}
|
|
};
|
|
typedef std::ptrdiff_t difference_type;
|
|
typedef X value_type;
|
|
// additional iterator requirements not important for this issue
|
|
|
|
reference operator*() const { return x; }
|
|
pointer operator->() const { return pointer(x); }
|
|
IterX& operator--() {return *this;}
|
|
|
|
};
|
|
|
|
int main()
|
|
{
|
|
std::reverse_iterator<IterX> ix;
|
|
assert(&ix->m == &(*ix).m);
|
|
}
|
|
</pre></blockquote>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
Raw pointer support:
|
|
</p>
|
|
<blockquote><pre>
|
|
#include <iterator>
|
|
#include <utility>
|
|
|
|
int main() {
|
|
typedef std::pair<int, double> P;
|
|
P op;
|
|
std::reverse_iterator<P*> ri(&op + 1);
|
|
ri->first; // Error
|
|
}
|
|
</pre></blockquote>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
Caching iterator support:
|
|
</p>
|
|
<blockquote><pre>
|
|
#include <iterator>
|
|
#include <cassert>
|
|
|
|
struct X { int m; };
|
|
|
|
struct IterX {
|
|
typedef std::bidirectional_iterator_tag iterator_category;
|
|
typedef X& reference;
|
|
typedef X* pointer;
|
|
typedef std::ptrdiff_t difference_type;
|
|
typedef X value_type;
|
|
// additional iterator requirements not important for this issue
|
|
|
|
reference operator*() const { return value; }
|
|
pointer operator->() const { return &value; }
|
|
IterX& operator--() {return *this;}
|
|
|
|
private:
|
|
mutable X value;
|
|
};
|
|
|
|
int main()
|
|
{
|
|
std::reverse_iterator<IterX> ix;
|
|
assert(&ix->m == &(*ix).m);
|
|
}
|
|
</pre></blockquote>
|
|
</li>
|
|
</ol>
|
|
</blockquote>
|
|
|
|
<p><i>[
|
|
2010 Pittsburgh:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
Moved to NAD Future, rationale added.
|
|
</p></blockquote>
|
|
|
|
|
|
|
|
|
|
<p><b>Rationale:</b></p>
|
|
<p>
|
|
The LWG did not reach a consensus for a change to the WP.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<ol>
|
|
|
|
<li>
|
|
<p>
|
|
In the class template <tt>reverse_iterator</tt> synopsis of 24.5.1.1 [reverse.iterator] change as indicated:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
namespace std {
|
|
template <class Iterator>
|
|
class reverse_iterator : public
|
|
iterator<typename iterator_traits<Iterator>::iterator_category,
|
|
typename iterator_traits<Iterator>::value_type,
|
|
typename iterator_traits<Iterator>::difference_type,
|
|
<del>typename iterator_traits<</del>Iterator<ins>&</ins><del>>::pointer</del>,
|
|
typename iterator_traits<Iterator>::reference> {
|
|
public:
|
|
[..]
|
|
typedef <del>typename iterator_traits<</del>Iterator<ins>&</ins><del>>::pointer</del> pointer;
|
|
[..]
|
|
protected:
|
|
Iterator current;
|
|
private:
|
|
<ins>mutable</ins> Iterator deref_tmp; // exposition only
|
|
};
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li>
|
|
Change 24.5.1.3.5 [reverse.iter.opref]/1 as indicated:
|
|
|
|
<blockquote><pre>
|
|
pointer operator->() const;
|
|
</pre>
|
|
|
|
<blockquote><p>
|
|
1 <i><del>Returns</del> <ins>Effects</ins>:</i> <del><tt>&(operator*())</tt>.</del>
|
|
</p><blockquote><pre>
|
|
<ins>deref_tmp = current;</ins>
|
|
<ins>--deref_tmp;</ins>
|
|
<ins>return deref_tmp;</ins>
|
|
</pre></blockquote>
|
|
</blockquote>
|
|
</blockquote>
|
|
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1053"></a>1053. Unify algorithms with operator and function object variants</h3>
|
|
<p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#algorithms">active issues</a> in [algorithms].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#algorithms">issues</a> in [algorithms].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p><b>Addresses UK 295 [CD1]</b></p>
|
|
|
|
<p>
|
|
There is a level of redundancy in the library specification for many
|
|
algorithms that can be eliminated with the combination of concepts and
|
|
default parameters for function templates. Eliminating redundancy simplified
|
|
specification and reduces the risk of introducing accidental
|
|
inconsistencies.
|
|
</p>
|
|
<p>
|
|
Proposed resolution: Adopt
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2743.pdf">N2743</a>.
|
|
</p>
|
|
|
|
<p><i>[
|
|
Summit:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<p>
|
|
NAD, this change would break code that takes the address of an algorithm.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p><i>[
|
|
Post Summit Alisdair adds:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<p>
|
|
Request 'Open'. The issues in the paper go beyond just reducing
|
|
the number of signatures, but cover unifying the idea of the ordering
|
|
operation used by algorithms, containers and other library components. At
|
|
least, it takes a first pass at the problem.
|
|
</p>
|
|
|
|
<p>
|
|
For me (personally) that was the more important part of the paper, and not
|
|
clearly addressed by the Summit resolution.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p><i>[
|
|
2009-10 Santa Cruz:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
Too inventive, too late, would really need a paper. Moved to NAD Future.
|
|
</p></blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1112"></a>1112. bitsets and new style for loop</h3>
|
|
<p><b>Section:</b> 20.6 [template.bitset] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-06 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
<tt>std::bitset</tt> is a homogeneous container-like sequence of bits, yet it does
|
|
not model the Range concept so cannot be used with the new for-loop syntax.
|
|
It is the only such type in the library that does NOT support the new for
|
|
loop.
|
|
</p>
|
|
<p>
|
|
The obvious reason is that bitset does not support iterators.
|
|
</p>
|
|
<p>
|
|
At least two reasonable solutions are available:
|
|
</p>
|
|
<ol style="list-style-type:lower-roman">
|
|
<li>
|
|
Add an iterator interface to <tt>bitset</tt>, bringing its interface close to that
|
|
of <tt>std::array</tt>
|
|
</li>
|
|
<li>
|
|
Provide an unspecified concept_map for <tt>Range<bitset></tt>.
|
|
</li>
|
|
</ol>
|
|
<p>
|
|
The latter will still need some kind of iterator-like adapter for <tt>bitset</tt>,
|
|
but gives implementers greater freedom on the details. E.g. begin/end return
|
|
some type that simply invokes <tt>operator[]</tt> on the object it wraps, and
|
|
increments its index on <tt>operator++</tt>. A vendor can settle for <tt>InputIterator</tt>
|
|
support, rather than wrapping up a full <tt>RandomAccessIterator</tt>.
|
|
</p>
|
|
<p>
|
|
I have a mild preference for option (ii) as I think it is less work to
|
|
specify at this stage of the process, although (i) is probably more useful
|
|
in the long run.
|
|
</p>
|
|
<p>
|
|
Hmm, my wording looks a little woolly, as it does not say what the element
|
|
type of the range is. Do I get a range of <tt>bool</tt>, <tt>bitset<N>::reference</tt>, or
|
|
something else entirely?
|
|
</p>
|
|
<p>
|
|
I guess most users will assume the behaviour of reference, but expect to
|
|
work with <tt>bool</tt>. <tt>Bool</tt> is OK for read-only traversal, but you really need to
|
|
take a reference to a <tt>bitset::reference</tt> if you want to write back.
|
|
</p>
|
|
|
|
<p><i>[
|
|
Batavia (2009-05):
|
|
]</i></p>
|
|
|
|
<blockquote><p>
|
|
Move to Open.
|
|
We further recommend this be deferred until after the next Committee Draft.
|
|
</p></blockquote>
|
|
|
|
<p><i>[
|
|
2009-05-25 Alisdair adds:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<p>
|
|
I just stumbled over the <tt>Range concept_map</tt> for <tt>valarray</tt> and this should
|
|
probably set the precedent on how to write the wording.
|
|
</p>
|
|
|
|
<p><i>[
|
|
Howard: I've replaced the proposed wording with Alisdair's suggestion.
|
|
]</i></p>
|
|
|
|
|
|
</blockquote>
|
|
|
|
<p><i>[
|
|
2009-07-24 Daniel modifies the proposed wording for non-concepts.
|
|
]</i></p>
|
|
|
|
|
|
<p><i>[
|
|
2009-10 post-Santa Cruz:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
Mark as Tentatively NAD Future due to the loss of concepts.
|
|
</p></blockquote>
|
|
|
|
|
|
|
|
<p><b>Rationale:</b></p>
|
|
<p>
|
|
All concepts-related text has been removed from the draft.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<ol>
|
|
<li>
|
|
<p>
|
|
Modify the section 20.6 [template.bitset] <tt><bitset></tt> synopsis by adding
|
|
the following at the end of the synopsis:
|
|
</p>
|
|
<blockquote><pre>
|
|
<ins>
|
|
// XX.X.X bitset range access [bitset.range]
|
|
template<size_t N> <i>unspecified-1</i> begin(bitset<N>&);
|
|
template<size_t N> <i>unspecified-2</i> begin(const bitset<N>&);
|
|
template<size_t N> <i>unspecified-1</i> end(bitset<N>&);
|
|
template<size_t N> <i>unspecified-2</i> end(const bitset<N>&);
|
|
</ins>
|
|
</pre></blockquote>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
Add a new section <ins>"bitset range access" [bitset.range]</ins>
|
|
after the current section 20.6.4 [bitset.operators] with the following series of
|
|
paragraphs:
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
<ins>
|
|
1. In the <tt>begin</tt> and <tt>end</tt> function templates that follow, <i>unspecified-1</i>
|
|
is a type that meets the requirements of a mutable random access
|
|
iterator (24.2.7 [random.access.iterators]) whose <tt>value_type</tt> is <tt>bool</tt> and
|
|
whose reference type is <tt>bitset<N>::reference</tt>.
|
|
<i>unspecified-2</i> is a type that meets the requirements of a constant
|
|
random access iterator (24.2.7 [random.access.iterators]) whose <tt>value_type</tt>
|
|
is <tt>bool</tt> and whose reference type is <tt>bool</tt>.
|
|
</ins>
|
|
</p>
|
|
<pre>
|
|
<ins>
|
|
template<size_t N> <i>unspecified-1</i> begin(bitset<N>&);
|
|
template<size_t N> <i>unspecified-2</i> begin(const bitset<N>&);
|
|
</ins>
|
|
</pre>
|
|
<blockquote><p>
|
|
<ins>2. Returns: an iterator referencing the first bit in the bitset.</ins>
|
|
</p></blockquote>
|
|
|
|
<pre><ins>
|
|
template<size_t N> <i>unspecified-1</i> end(bitset<N>&);
|
|
template<size_t N> <i>unspecified-2</i> end(const bitset<N>&);
|
|
</ins></pre>
|
|
|
|
<blockquote><p>
|
|
<ins>3. Returns: an iterator referencing one past the last bit in the
|
|
bitset.</ins>
|
|
</p></blockquote>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1120"></a>1120. New type trait - remove_all</h3>
|
|
<p><b>Section:</b> 20.10 [meta] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#meta">active issues</a> in [meta].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#meta">issues</a> in [meta].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Sometimes it is necessary to remove all qualifiers from a type before
|
|
passing on to a further API. A good example would be calling the
|
|
<tt>tuple</tt> query APIs <tt>tuple_size</tt> or <tt>tuple_element</tt>
|
|
with a deduced type inside a function template. If the deduced type is
|
|
cv-qualified or a reference then the call will fail. The solution is to
|
|
chain calls to
|
|
<tt>remove_cv<remove_reference<T>::type>::type</tt>, and
|
|
note that the order matters.
|
|
</p>
|
|
<p>
|
|
Suggest it would be helpful to add a new type trait,
|
|
<tt>remove_all</tt>, that removes all top-level qualifiers from a type
|
|
i.e. cv-qualification and any references. Define the term in such a way
|
|
that if additional qualifiers are added to the language, then
|
|
<tt>remove_all</tt> is defined as stripping those as well.
|
|
</p>
|
|
|
|
<p><i>[
|
|
2009-10-14 Daniel adds:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
<tt>remove_all</tt> seems too generic, a possible alternative matching
|
|
the current naming style could be <tt>remove_cv_reference</tt> or
|
|
<tt>remove_reference_cv</tt>. It should also be considered whether this
|
|
trait should also remove 'extents', or pointer 'decorations'. Especially
|
|
if the latter situations are considered as well, it might be easier to
|
|
chose the name not in terms of what it <em>removes</em> (which might be
|
|
a lot), but in terms of it <em>creates</em>. In this case I could think
|
|
of e.g. <tt>extract_value_type</tt>.
|
|
</p></blockquote>
|
|
|
|
<p><i>[
|
|
2009-10 Santa Cruz:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
NAD Future.
|
|
</p></blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1121"></a>1121. Support for multiple arguments</h3>
|
|
<p><b>Section:</b> 20.11.4 [ratio.arithmetic] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-25 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#ratio.arithmetic">issues</a> in [ratio.arithmetic].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Both add and multiply could sensibly be called with more than two arguments.
|
|
The variadic template facility makes such declarations simple, and is likely
|
|
to be frequently wrapped by end users if we do not supply the variant
|
|
ourselves.
|
|
</p>
|
|
<p>
|
|
We deliberately ignore divide at this point as it is not transitive.
|
|
Likewise, subtract places special meaning on the first argument so I do not
|
|
suggest extending that immediately. Both could be supported with analogous
|
|
wording to that for add/multiply below.
|
|
</p>
|
|
<p>
|
|
Note that the proposed resolution is potentially incompatible with that
|
|
proposed for <a href="lwg-defects.html#921">921</a>, although the addition of the typedef to ratio would be
|
|
equally useful.
|
|
</p>
|
|
|
|
<p><i>[
|
|
2009-10-30 Alisdair adds:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<p>
|
|
The consensus of the group when we reviewed this in Santa Cruz was that
|
|
<a href="lwg-defects.html#921">921</a> would proceed to Ready as planned, and the
|
|
multi-paramater add/multiply templates should be renamed as
|
|
<tt>ratio_sum</tt> and <tt>ratio_product</tt> to avoid the problem
|
|
mixing template aliases with partial specializations.
|
|
</p>
|
|
|
|
<p>
|
|
It was also suggested to close this issue as NAD Future as it does not
|
|
correspond directly to any NB comment. NBs are free to submit a
|
|
specific comment (and re-open) in CD2 though.
|
|
</p>
|
|
|
|
<p>
|
|
Walter Brown also had concerns on better directing the order of
|
|
evaluation to avoid overflows if we do proceed for 0x rather than TR1,
|
|
so wording may not be complete yet.
|
|
</p>
|
|
|
|
<p><i>[
|
|
Alisdair updates wording.
|
|
]</i></p>
|
|
|
|
|
|
</blockquote>
|
|
|
|
<p><i>[
|
|
2009-10-30 Howard:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
Moved to Tentatively NAD Future after 5 positive votes on c++std-lib.
|
|
</p></blockquote>
|
|
|
|
|
|
|
|
<p><b>Rationale:</b></p>
|
|
<p>
|
|
Does not have sufficient support at this time. May wish to reconsider for a
|
|
future standard.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<p>
|
|
Add the following type traits to p3 20.11 [ratio]
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
// ratio arithmetic
|
|
template <class R1, class R2> struct ratio_add;
|
|
template <class R1, class R2> struct ratio_subtract;
|
|
template <class R1, class R2> struct ratio_multiply;
|
|
template <class R1, class R2> struct ratio_divide;
|
|
<ins>template <class R1, class ... RList> struct ratio_sum;</ins>
|
|
<ins>template <class R1, class ... RList> struct ratio_product;</ins>
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
after 20.11.4 [ratio.arithmetic] p1: add
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
template <class R1, class ... RList> struct ratio_sum; // declared, never defined
|
|
|
|
template <class R1> struct ratio_sum<R1> : R1 {};
|
|
</pre>
|
|
|
|
<blockquote><p>
|
|
<i>Requires:</i> <tt>R1</tt> is a specialization of class template <tt>ratio</tt>
|
|
</p></blockquote>
|
|
|
|
<pre>
|
|
template <class R1, class R2, class ... RList>
|
|
struct ratio_sum<R1, R2, RList...>
|
|
: ratio_add< R1, ratio_sum<R2, RList...>> {
|
|
};
|
|
</pre>
|
|
|
|
<blockquote><p>
|
|
<i>Requires:</i> <tt>R1</tt> and each element in parmater pack
|
|
<tt>RList</tt> is a specialization of class template <tt>ratio</tt>
|
|
</p></blockquote>
|
|
</blockquote>
|
|
|
|
<p>
|
|
after 20.11.4 [ratio.arithmetic] p3: add
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
template <class R1, class ... RList> struct ratio_product; // declared, never defined
|
|
|
|
template <class R1> struct ratio_product<R1> : R1 {};
|
|
</pre>
|
|
|
|
<blockquote><p>
|
|
<i>Requires:</i> <tt>R1</tt> is a specialization of class template <tt>ratio</tt>
|
|
</p></blockquote>
|
|
|
|
<pre>
|
|
template <class R1, class R2, class ... RList>
|
|
struct ratio_sum<R1, R2, RList...>
|
|
: ratio_add< R1, ratio_product<R2, RList...>> {
|
|
};
|
|
</pre>
|
|
|
|
<blockquote><p>
|
|
<i>Requires:</i> <tt>R1</tt> and each element in parmater pack
|
|
<tt>RList</tt> is a specialization of class template <tt>ratio</tt>
|
|
</p></blockquote>
|
|
</blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1150"></a>1150. wchar_t, char16_t and char32_t filenames</h3>
|
|
<p><b>Section:</b> 27.9.1.14 [fstream] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p><b>Addresses JP 73</b></p>
|
|
|
|
<p><b>Description</b></p>
|
|
<p>It is a problem
|
|
from C++98, <tt>fstream</tt> cannot appoint a filename of wide
|
|
character string(<tt>const wchar_t</tt> and <tt>const wstring&</tt>).</p>
|
|
<p><b>Suggestion</b></p>
|
|
<p>Add
|
|
interface corresponding to <tt>wchar_t</tt>, <tt>char16_t</tt> and <tt>char32_t</tt>.</p>
|
|
|
|
<p><i>[
|
|
2009-07-01 Alisdair notes that this is a duplicate of <a href="lwg-closed.html#454">454</a> which has more
|
|
in-depth rationale.
|
|
]</i></p>
|
|
|
|
|
|
<p><i>[
|
|
2009-09-21 Daniel adds:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
I suggest to mark this issue as NAD Future with the intend to
|
|
solve the issue with a single file path c'tor template assuming
|
|
a provision of a TR2 filesystem library.
|
|
</p></blockquote>
|
|
|
|
<p><i>[
|
|
2009 Santa Cruz:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
NAD Future. This is a duplicate of <a href="lwg-closed.html#454">454</a>.
|
|
</p></blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1154"></a>1154. <tt>complex</tt> should accept integral types</h3>
|
|
<p><b>Section:</b> 26.4 [complex.numbers] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#complex.numbers">active issues</a> in [complex.numbers].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#complex.numbers">issues</a> in [complex.numbers].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p><b>Addresses FR 35</b></p>
|
|
|
|
<p><b>Description</b></p>
|
|
<p>Instantiations of the class
|
|
template <tt>complex<></tt> have to be allowed for integral
|
|
types, to reflect existing practice and ISO standards
|
|
(LIA-III).</p>
|
|
|
|
<p><b>Suggestion</b></p>
|
|
|
|
<p><i>[
|
|
2009-10-26 Proposed wording in
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3002.pdf">N3002</a>.
|
|
]</i></p>
|
|
|
|
|
|
<p><i>[
|
|
2010 Pittsburgh:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
Moved to NAD Future. Rationale added.
|
|
</p></blockquote>
|
|
|
|
|
|
|
|
<p><b>Rationale:</b></p>
|
|
<p>
|
|
There is no consensus for making this change at this time.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p><p>
|
|
Adopt
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3002.pdf">N3002</a>.
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1169"></a>1169. <tt>num_get</tt> not fully compatible with <tt>strto*</tt></h3>
|
|
<p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Cosmin Truta <b>Opened:</b> 2009-07-04 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
As specified in the latest draft,
|
|
<a
|
|
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>,
|
|
<code>num_get</code> is still not fully compatible with the following C
|
|
functions: <code>strtoul</code>, <code>strtoull</code>,
|
|
<code>strtof</code> and
|
|
<code>strtod</code>.
|
|
</p>
|
|
<p>
|
|
In C, when conversion of a string to an unsigned integer type falls
|
|
outside the
|
|
representable range, <code>strtoul</code> and <code>strtoull</code> return
|
|
<code>ULONG_MAX</code> and <code>ULLONG_MAX</code>, respectively,
|
|
regardless
|
|
whether the input field represents a positive or a negative value.
|
|
On the other hand, the result of <code>num_get</code> conversion of
|
|
negative
|
|
values to unsigned integer types is zero. This raises a compatibility
|
|
issue.
|
|
</p>
|
|
<p>
|
|
Moreover, in C, when conversion of a string to a floating-point type falls
|
|
outside the representable range, <code>strtof</code>, <code>strtod</code>
|
|
and
|
|
<code>strtold</code> return <code>±HUGE_VALF</code>,
|
|
<code>±HUGE_VAL</code> and <code>±HUGE_VALL</code>, respectively.
|
|
On the other hand, the result of <code>num_get</code> conversion of such
|
|
out-of-range floating-point values results in the most positive/negative
|
|
representable value.
|
|
Although many C library implementations do implement <code>HUGE_VAL</code>
|
|
(etc.) as the highest representable (which is, usually, the infinity),
|
|
this isn't required by the C standard. The C library specification makes no
|
|
statement regarding the value of <code>HUGE_VAL</code> and friends, which
|
|
potentially raises the same compatibility issue as in the above case of
|
|
unsigned integers.
|
|
In addition, neither C nor C++ define symbolic constants for the maximum
|
|
representable floating-point values (they only do so only for the maximum
|
|
representable <i>finite</i> floating-point values), which raises a
|
|
usability
|
|
issue (it would be hard for the programmer to check the result of
|
|
<code>num_get</code> against overflow).
|
|
</p>
|
|
<p>
|
|
As such, we propose to adjust the specification of <code>num_get</code> to
|
|
closely follow the behavior of all of its underlying C functions.
|
|
</p>
|
|
|
|
|
|
|
|
<p><i>[
|
|
2010 Rapperswil:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
Some concern that this is changing the specification for an existing C++03 function, but it was
|
|
pointed out that this was underspecified as resolved by issue 23. This is clean-up for that
|
|
issue in turn. Some concern that we are trying to solve the same problem in both clause 22 and 27.
|
|
</p>
|
|
<p>
|
|
Bill: There's a change here as to whether val is stored to in an error case.
|
|
</p>
|
|
<p>
|
|
Pablo: Don't think this changes whether val is stored to or not, but changes the value that is stored.
|
|
</p>
|
|
<p>
|
|
Bill: Remembers having skirmishes with customers and testers as to whether val is stored to, and the resolution was not to store in error cases.
|
|
</p>
|
|
<p>
|
|
Howard: Believes since C++03 we made a change to always store in overflow.
|
|
</p>
|
|
<p>
|
|
Everyone took some time to review the issue.
|
|
</p>
|
|
<p>
|
|
Pablo: C++98 definitely did not store any value during an error condition.
|
|
</p>
|
|
<p>
|
|
Dietmar: Depends on the question of what is considered an error, and whether overflow is an error or not, which was the crux of LWG 23.
|
|
</p>
|
|
<p>
|
|
Pablo: Yes, but given the "zero, if the conversion function fails to convert the entire field", we are requiring every error condition to store.
|
|
</p>
|
|
<p>
|
|
Bill: When did this happen?
|
|
</p>
|
|
<p>
|
|
Alisdair: One of the last two or three meetings.
|
|
</p>
|
|
<p>
|
|
Dietmar: To store a value in case of failure is a very bad idea.
|
|
</p>
|
|
<p>
|
|
Move to Open, needs more study.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p><i>[2011-03-24 Madrid meeting]</i></p>
|
|
|
|
|
|
<p>Move to deferred</p>
|
|
|
|
<p><i>[
|
|
2011 Bloomington
|
|
]</i></p>
|
|
|
|
|
|
<p>
|
|
The proposed wording looks good, no-one sure why this was held back before. Move to Review.
|
|
</p>
|
|
|
|
|
|
<p><i>[2012,Kona]</i></p>
|
|
|
|
<p>
|
|
Move to Open.
|
|
</p>
|
|
<p>
|
|
THe issues is what to do with <tt>-1</tt>. Should it match 'C' or do the "sane" thing.
|
|
A fix here changes behavior, but is probably what we want.
|
|
</p>
|
|
<p>
|
|
Pablo to provide wording, with help from Howard.
|
|
</p>
|
|
|
|
<p><i>[2015-05-06 Lenexa: Move to Ready]</i></p>
|
|
|
|
<p>STL: I like that this uses strtof, which I think is new in C99. that avoids truncation from using atof. I have another issue ...</p>
|
|
<p>MC: yes LWG 2403 (stof should call strtof)</p>
|
|
<p>PJP: the last line is horrible, you don't assign to err, you call setstate(ios_base::failbit). Ah, no, this is inside num_get so the caller does the setstate.</p>
|
|
<p>MC: we need all these words. are they the right words?</p>
|
|
<p>JW: I'd like to take a minute to check my impl. Technically this implies a change in behaviour (from always using strtold and checking the extracted floating point value, to using the right function). Oh, we already do exactly this.</p>
|
|
<p>MC: Move to Ready</p>
|
|
<p>6 in favor, none opposed, 1 abstention</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<p>
|
|
Change 22.4.2.1.2 [facet.num.get.virtuals] as follows:
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
<b>Stage 3:</b>
|
|
The sequence of <code>char</code>s accumulated in stage 2 (the field) is
|
|
converted to a numeric value by the rules of one of the functions declared in
|
|
the header <code><cstdlib></code>:
|
|
</p>
|
|
<ul>
|
|
<li>For a signed integer value, the function <code>strtoll</code>.</li>
|
|
<li>For an unsigned integer value, the function <code>strtoull</code>.</li>
|
|
<li><ins>For a <code>float</code> value, the function
|
|
<code>strtof</code>.</ins></li>
|
|
<li><ins>For a <code>double</code> value, the function
|
|
<code>strtod</code>.</ins></li>
|
|
<li>For a <del>floating-point</del> <ins><code>long double</code></ins>
|
|
value, the function <code>strtold</code>.</li>
|
|
</ul>
|
|
<p>
|
|
The numeric value to be stored can be one of:
|
|
</p>
|
|
<ul>
|
|
<li>zero, if the conversion function fails to convert the entire field.
|
|
<del><code>ios_base::failbit</code> is assigned to <code>err</code>.</del></li>
|
|
<li>the most positive <ins>(or negative)</ins> representable value, if
|
|
the field <ins>to be converted to a signed integer type</ins> represents a
|
|
value too large positive <ins>(or negative)</ins> to be represented in
|
|
<code>val</code>.
|
|
<del><code>ios_base::failbit</code> is assigned to <code>err</code>.</del></li>
|
|
<li><del>the most negative representable value or zero for an unsigned integer
|
|
type, if the field represents a value too large negative to be represented
|
|
in <code>val</code>.
|
|
<code>ios_base::failbit</code> is assigned to <code>err</code>.</del></li>
|
|
<li><ins>the most positive representable value, if the field to be converted to
|
|
an unsigned integer type represents a value that cannot be represented in
|
|
<code>val</code>.</ins></li>
|
|
<li>the converted value, otherwise.</li>
|
|
</ul>
|
|
<p>
|
|
The resultant numeric value is stored in <code>val</code>.
|
|
<ins>If the conversion function fails to convert the entire field, or if the
|
|
field represents a value outside the range of representable values,
|
|
<code>ios_base::failbit</code> is assigned to <code>err</code>.</ins>
|
|
</p>
|
|
</blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1173"></a>1173. "Equivalence" wishy-washiness</h3>
|
|
<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-07-14 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#library">active issues</a> in [library].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#library">issues</a> in [library].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Issue: The <tt>CopyConstructible</tt> requirements are wishy-washy. It requires
|
|
that the copy is "equivalent" to the original, but "equivalent" is never
|
|
defined.
|
|
</p>
|
|
<p>
|
|
I believe this to be an example of a more general lack of rigor around
|
|
copy and assignment, although I haven't done the research to dig up all
|
|
the instances.
|
|
</p>
|
|
<p>
|
|
It's a problem because if you don't know what <tt>CopyConstructible</tt> means,
|
|
you also don't know what it means to copy a pair of <tt>CopyConstructible</tt>
|
|
types. It doesn't prevent us from writing code, but it is a hole in our
|
|
ability to understand the meaning of copy.
|
|
</p>
|
|
<p>
|
|
Furthermore, I'm pretty sure that vector's copy constructor doesn't
|
|
require the elements to be <tt>EqualityComparable</tt>, so that table is actually
|
|
referring to some ill-defined notion of equivalence when it uses ==.
|
|
</p>
|
|
|
|
<p><i>[
|
|
2009 Santa Cruz:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
Move to "Open". Dave is right that this is a big issue. Paper D2987
|
|
("Defining Move Special Member Functions", Bjarne Stroustrup and
|
|
Lawrence Crowl) touches on this but does not solve it. This issue is
|
|
discussed in Elements of Programming.
|
|
</p></blockquote>
|
|
|
|
|
|
<p><i>[
|
|
2010 Rapperswil:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
This issue is quite vague, so it is difficult to know if and when it has been resolved.
|
|
John Lakos wrote a paper covering this area a while back, and there is a real interest
|
|
in providing some sort of clean-up in the future. We need a more clearly draughted
|
|
issues with an addressable set of concerns, ideally with a paper proposing a resolution,
|
|
but for a future revision of the standard. Move to Tentatively NAD Future.
|
|
</p></blockquote>
|
|
|
|
<p><i>[
|
|
Moved to NAD Future at 2010-11 Batavia
|
|
]</i></p>
|
|
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1175"></a>1175. <tt>unordered</tt> complexity</h3>
|
|
<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2009-07-17 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#unord.req">issues</a> in [unord.req].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
When I look at the <tt>unordered_*</tt> constructors, I think the complexity is poorly
|
|
described and does not follow the style of the rest of the standard.
|
|
</p>
|
|
|
|
<p>
|
|
The complexity for the default constructor is specified as constant.
|
|
Actually, it is proportional to <tt>n</tt>, but there are no invocations of
|
|
<tt>value_type</tt> constructors or other <tt>value_type</tt> operations.
|
|
</p>
|
|
|
|
<p>
|
|
For the iterator-based constructor the complexity should be:
|
|
</p>
|
|
|
|
<blockquote><p>
|
|
<i>Complexity:</i> exactly <tt>n</tt> calls to construct <tt>value_type</tt>
|
|
from <tt>InputIterator::value_type</tt> (where <tt>n = distance(f,l)</tt>).
|
|
The number of calls to <tt>key_equal::operator()</tt> is proportional to
|
|
<tt>n</tt> in the average case and <tt>n*n</tt> in the worst case.
|
|
</p></blockquote>
|
|
|
|
<p><i>[
|
|
2010 Rapperswil:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
Concern that the current wording may require O(1) where that cannot be delivered. We need to look at
|
|
both the clause 23 requirements tables and the constructor description of each unordered container to be sure.
|
|
</p>
|
|
<p>
|
|
Howard suggests NAD Editorial as we updated the container requirement tables since this issue was written.
|
|
</p>
|
|
<p>
|
|
Daniel offers to look deeper, and hopefully produce wording addressing any outstanding concerns at the next meeting.
|
|
</p>
|
|
<p>
|
|
Move to Open.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p><i>[2011-02-26: Daniel provides wording]</i></p>
|
|
|
|
|
|
<p>I strongly suggest to clean-up the differences between requirement tables and individual
|
|
specifications. In the usual way, the most specific specifications wins, which is in this
|
|
case the wrong one. In regard to the concern expressed about missing <tt>DefaultConstructible</tt>
|
|
requirements of the value type I disagree: The function argument <tt>n</tt> is no size-control
|
|
parameter, but only some effective capacity parameter: No elements will be value-initialized
|
|
by these constructors. The necessary requirement for the value type, <tt>EmplaceConstructible</tt>
|
|
into <tt>*this</tt>, is already listed in Table 103 — Unordered associative container requirements.
|
|
Another part of the proposed resolution is the fact that there is an inconsistency of the
|
|
complexity counting when both a range <strong>and</strong> a bucket count is involved compared
|
|
to constructions where only bucket counts are provided: E.g. the construction <tt>X a(n);</tt>
|
|
has a complexity of <tt>n</tt> bucket allocations, but this part of the work is omitted for
|
|
<tt>X a(i, j, n);</tt>, even though it is considerable larger (in the average case) for
|
|
<tt>n ≫ distance(i, j)</tt>.
|
|
</p>
|
|
|
|
<p><i>[2011-03-24 Madrid meeting]</i></p>
|
|
|
|
|
|
<p>Move to deferred</p>
|
|
|
|
<p><i>[
|
|
2011 Bloomington
|
|
]</i></p>
|
|
|
|
|
|
<p>
|
|
The proposed wording looks good. Move to Review.
|
|
</p>
|
|
|
|
<p><i>[2012, Kona]</i></p>
|
|
|
|
<p>
|
|
Fix up some presentation issues with the wording, combining the big-O expressions into single
|
|
expressions rather than the sum of two separate big-Os.
|
|
</p>
|
|
<p>
|
|
Strike "constant or linear", prefer "linear in the number of buckets".
|
|
This allows for number of buckets being larger than requested <tt>n</tt> as well.
|
|
</p>
|
|
<p>
|
|
Default <tt>n</tt> to "unspecified" rather than "implementation-defined". It seems an un-necessary
|
|
burden asking vendors to document a quantity that is easily determined through the public API of
|
|
these classes.
|
|
</p>
|
|
<p>
|
|
Replace <tt>distance(f,l)</tt> with "number of elements in the range <tt>[f,l)</tt>"
|
|
</p>
|
|
<p>
|
|
Retain in Review with the updated wording
|
|
</p>
|
|
|
|
<p><i>[2012, Portland: Move to Open]</i></p>
|
|
|
|
<p>
|
|
The wording still does not call out Pablo's original concern, that the element constructor is called
|
|
no more than <tt>N</tt> times, and that the <tt>N</tt> squared term applies to moves during rehash.
|
|
</p>
|
|
|
|
<p>
|
|
Inconsistent use of O(n)+O(N) vs. O(n+N), with a preference for the former.
|
|
</p>
|
|
|
|
<p>
|
|
AJM to update wording with a reference to "no more than <tt>N</tt> element constructor calls".
|
|
</p>
|
|
|
|
<p>
|
|
Matt concerned that calling out the O(n) requirements is noise, and dangerous noise in suggesting a precision
|
|
we do not mean. The cost of constructing a bucket is very different to constructing an element of user-supplied
|
|
type.
|
|
</p>
|
|
|
|
<p>
|
|
AJM notes that if there are multiple rehashes, the 'n' complexity is probably not linear.
|
|
</p>
|
|
|
|
<p>
|
|
Matt suggests back to Open, Pablo suggests potentially NAD if we keep revisitting without achieving a resolution.
|
|
</p>
|
|
|
|
<p>
|
|
Matt suggests complexity we are concerned with is the number of operations, such as constructing elements, moving
|
|
nodes, and comparing/hashing keys. We are less concerned with constructing buckets, which are generally noise in
|
|
this bigger picture.
|
|
</p>
|
|
|
|
<p><i>[2015-01-29 Telecon]</i></p>
|
|
|
|
<p>
|
|
AM: essentially correct, but do we want to complicate the spec?
|
|
<p/>
|
|
HH: Pablo has given us permission to NAD it
|
|
<p/>
|
|
JM: when I look at the first change in the P/R I find it mildly disturbing that the existing wording says you have a
|
|
constant time constructor with a single element even if your <tt>n</tt> is 10^6, so I think adding this change makes people
|
|
aware there might be a large cost in initializing the hash table, even though it doesn't show up in user-visible constructions.
|
|
<p/>
|
|
HH: one way to avoid that problem is make the default ctor <tt>noexcept</tt>. Then the container isn't allowed to create
|
|
an arbitrarily large hash table
|
|
<p/>
|
|
AM: but this is the constructor where the user provides <tt>n</tt>
|
|
<p/>
|
|
MC: happy with the changes, except I agree with the editorial recommendation to keep the two 𝒪s separate.
|
|
<p/>
|
|
JW: yes, the constant '<tt>k</tt>' is different in 𝒪(n) and 𝒪(N)
|
|
<p/>
|
|
GR: do we want to talk about buckets at all
|
|
<p/>
|
|
JM: yes, good to highlight that bucket construction might be a significant cost
|
|
<p/>
|
|
HH: suggest we take the suggestion to split 𝒪(n+N) to 𝒪(n)+𝒪(N) and move to Tentatively Ready
|
|
<p/>
|
|
GR: 23.2.1p2 says all complexity requirements are stated solely in terms of the number of operations on the contained
|
|
object, so we shouldn't be stating complexity in terms of the hash table initialization
|
|
<p/>
|
|
HH: channeling Pete, there's an implicit "unless otherwise specified" everywhere.
|
|
<p/>
|
|
VV: seem to be requesting modifications that render this not Tentatively Ready
|
|
<p/>
|
|
GR: I think it can't be T/R
|
|
<p/>
|
|
AM: make the editorial recommendation, consider fixing 23.2.1/3 to give us permission to state complexity in terms
|
|
of bucket initialization
|
|
<p/>
|
|
HH: only set it to Review after we get new wording to review
|
|
</p>
|
|
|
|
<p><i>[2015-02 Cologne]</i></p>
|
|
|
|
<p>
|
|
Update wording, revisit later.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<ol>
|
|
<li><p>Modify the following rows in Table 103 — Unordered associative container requirements to
|
|
add the explicit bucket allocation overhead of some constructions. As editorial recommendation it is
|
|
suggested <em>not</em> to shorten the sum <tt>𝒪(n) + 𝒪(<em>N</em>)</tt> to
|
|
<tt>𝒪(n + <em>N</em>)</tt>, because two different work units are involved.</p>
|
|
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 103 — Unordered associative container requirements (in addition to container)</caption>
|
|
|
|
<tr>
|
|
<th>Expression</th>
|
|
<th>Return type</th>
|
|
<th>Assertion/note pre-/post-condition</th>
|
|
<th>Complexity</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="4" style="text-align:center;">…</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>X(i, j, n, hf, eq)</tt><br/>
|
|
<tt>X a(i, j, n, hf, eq)</tt>
|
|
</td>
|
|
<td><tt>X</tt></td>
|
|
<td>…<br/>
|
|
<i>Effects</i>: Constructs an empty container with at least <tt>n</tt><br/>
|
|
buckets, using <tt>hf</tt> as the hash function and <tt>eq</tt> as the key<br/>
|
|
equality predicate, and inserts elements from <tt>[i, j)</tt> into it.
|
|
</td>
|
|
<td>Average case 𝒪(<tt><i><ins>n + </ins>N</i></tt>) (<tt><i>N</i></tt> is <tt>distance(i, j)</tt>),<br/>
|
|
worst case <ins>𝒪(<tt>n</tt>) +</ins> 𝒪(<tt><i>N</i><sup>2</sup></tt>)</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>X(i, j, n, hf)</tt><br/>
|
|
<tt>X a(i, j, n, hf)</tt>
|
|
</td>
|
|
<td><tt>X</tt></td>
|
|
<td>…<br/>
|
|
<i>Effects</i>: Constructs an empty container with at least <tt>n</tt><br/>
|
|
buckets, using <tt>hf</tt> as the hash function and <tt>key_equal()</tt> as the key<br/>
|
|
equality predicate, and inserts elements from <tt>[i, j)</tt> into it.
|
|
</td>
|
|
<td>Average case 𝒪(<tt><i><ins>n + </ins>N</i></tt>) (<tt><i>N</i></tt> is <tt>distance(i, j)</tt>),<br/>
|
|
worst case 𝒪(<tt><i><ins>n + </ins>N</i><sup>2</sup></tt>)</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>X(i, j, n)</tt><br/>
|
|
<tt>X a(i, j, n)</tt>
|
|
</td>
|
|
<td><tt>X</tt></td>
|
|
<td>…<br/>
|
|
<i>Effects</i>: Constructs an empty container with at least <tt>n</tt><br/>
|
|
buckets, using <tt>hasher()</tt> as the hash function and <tt>key_equal()</tt> as the key<br/>
|
|
equality predicate, and inserts elements from <tt>[i, j)</tt> into it.
|
|
</td>
|
|
<td>Average case 𝒪(<tt><i><ins>n + </ins>N</i></tt>) (<tt><i>N</i></tt> is <tt>distance(i, j)</tt>),<br/>
|
|
worst case 𝒪(<tt><i><ins>n + </ins>N</i><sup>2</sup></tt>)</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="4" style="text-align:center;">…</td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote>
|
|
|
|
</li>
|
|
|
|
<li><p>Modify 23.5.4.2 [unord.map.cnstr] p. 1-4 as indicated (The edits of p. 1 and p. 3 attempt to fix some
|
|
editorial oversight.):</p>
|
|
|
|
<blockquote><pre>
|
|
explicit unordered_map(size_type n = <i>see below</i>,
|
|
const hasher& hf = hasher(),
|
|
const key_equal& eql = key_equal(),
|
|
const allocator_type& a = allocator_type());
|
|
</pre><blockquote><p>
|
|
1 <i>Effects</i>: Constructs an empty <tt>unordered_map</tt> using the specified hash function, key equality function,
|
|
and allocator, and using at least <tt>n</tt> buckets. If <tt>n</tt> is not provided, the number of buckets is
|
|
<ins>unspecified</ins><del>impldefdefault number of buckets in <tt>unordered_map</tt></del>.
|
|
<tt>max_load_factor()</tt> returns <tt>1.0</tt>.
|
|
</p></blockquote>
|
|
<blockquote><p>
|
|
2 <i>Complexity</i>: <del>Constant</del><ins>Linear in the number of buckets</ins>.
|
|
</p></blockquote>
|
|
</blockquote>
|
|
|
|
<blockquote><pre>
|
|
template <class InputIterator>
|
|
unordered_map(InputIterator f, InputIterator l,
|
|
size_type n = <i>see below</i>,
|
|
const hasher& hf = hasher(),
|
|
const key_equal& eql = key_equal(),
|
|
const allocator_type& a = allocator_type());
|
|
</pre><blockquote><p>
|
|
3 <i>Effects</i>: Constructs an empty <tt>unordered_map</tt> using the specified hash function, key equality function,
|
|
and allocator, and using at least <tt>n</tt> buckets. If <tt>n</tt> is not provided, the number of buckets is
|
|
<ins>unspecified</ins><del>impldefdefault number of buckets in <tt>unordered_map</tt></del>.
|
|
Then inserts elements from the range <tt>[f, l)</tt>. <tt>max_load_factor()</tt> returns <tt>1.0</tt>.
|
|
</p></blockquote>
|
|
<blockquote><p>
|
|
4 <i>Complexity</i>: <del>Average case linear, worst case quadratic</del><ins>Linear in the number of buckets.
|
|
In the average case linear in <tt><i>N</i></tt> and in the worst case quadratic in <tt><i>N</i></tt> to insert
|
|
the elements, where <tt><i>N</i></tt> is equal to number of elements in the range <tt>[f,l)</tt></ins>.
|
|
</p></blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Modify 23.5.5.2 [unord.multimap.cnstr] p. 1-4 as indicated (The edits of p. 1 and p. 3 attempt to fix some
|
|
editorial oversight.):</p>
|
|
|
|
<blockquote><pre>
|
|
explicit unordered_multimap(size_type n = <i>see below</i>,
|
|
const hasher& hf = hasher(),
|
|
const key_equal& eql = key_equal(),
|
|
const allocator_type& a = allocator_type());
|
|
</pre><blockquote><p>
|
|
1 <i>Effects</i>: Constructs an empty <tt>unordered_multimap</tt> using the specified hash function, key equality function,
|
|
and allocator, and using at least <tt>n</tt> buckets. If <tt>n</tt> is not provided, the number of buckets is
|
|
<ins>unspecified</ins><del>impldefdefault number of buckets in <tt>unordered_multimap</tt></del>.
|
|
<tt>max_load_factor()</tt> returns <tt>1.0</tt>.
|
|
</p></blockquote>
|
|
<blockquote><p>
|
|
2 <i>Complexity</i>: <del>Constant</del><ins>Linear in the number of buckets</ins>.
|
|
</p></blockquote>
|
|
</blockquote>
|
|
|
|
<blockquote><pre>
|
|
template <class InputIterator>
|
|
unordered_multimap(InputIterator f, InputIterator l,
|
|
size_type n = <i>see below</i>,
|
|
const hasher& hf = hasher(),
|
|
const key_equal& eql = key_equal(),
|
|
const allocator_type& a = allocator_type());
|
|
</pre><blockquote><p>
|
|
3 <i>Effects</i>: Constructs an empty <tt>unordered_multimap</tt> using the specified hash function, key equality function,
|
|
and allocator, and using at least <tt>n</tt> buckets. If <tt>n</tt> is not provided, the number of buckets is
|
|
<ins>unspecified</ins><del>impldefdefault number of buckets in <tt>unordered_multimap</tt></del>.
|
|
Then inserts elements from the range <tt>[f, l)</tt>. <tt>max_load_factor()</tt> returns <tt>1.0</tt>.
|
|
</p></blockquote>
|
|
<blockquote><p>
|
|
4 <i>Complexity</i>: <del>Average case linear, worst case quadratic</del><ins>Linear in the number of buckets.
|
|
In the average case linear in <tt><i>N</i></tt> and in the worst case quadratic in <tt><i>N</i></tt> to insert
|
|
the elements, where <tt><i>N</i></tt> is equal to number of elements in the range <tt>[f,l)</tt></ins>.
|
|
</p></blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Modify 23.5.6.2 [unord.set.cnstr] p. 1-4 as indicated (The edits of p. 1 and p. 3 attempt to fix some
|
|
editorial oversight.):</p>
|
|
|
|
<blockquote><pre>
|
|
explicit unordered_set(size_type n = <i>see below</i>,
|
|
const hasher& hf = hasher(),
|
|
const key_equal& eql = key_equal(),
|
|
const allocator_type& a = allocator_type());
|
|
</pre><blockquote><p>
|
|
1 <i>Effects</i>: Constructs an empty <tt>unordered_set</tt> using the specified hash function, key equality function,
|
|
and allocator, and using at least <tt>n</tt> buckets. If <tt>n</tt> is not provided, the number of buckets is
|
|
<ins>unspecified</ins><del>impldefdefault number of buckets in <tt>unordered_set</tt></del>.
|
|
<tt>max_load_factor()</tt> returns <tt>1.0</tt>.
|
|
</p></blockquote>
|
|
<blockquote><p>
|
|
2 <i>Complexity</i>: <del>Constant</del><ins>Linear in the number of buckets</ins>.
|
|
</p></blockquote>
|
|
</blockquote>
|
|
|
|
<blockquote><pre>
|
|
template <class InputIterator>
|
|
unordered_set(InputIterator f, InputIterator l,
|
|
size_type n = <i>see below</i>,
|
|
const hasher& hf = hasher(),
|
|
const key_equal& eql = key_equal(),
|
|
const allocator_type& a = allocator_type());
|
|
</pre><blockquote><p>
|
|
3 <i>Effects</i>: Constructs an empty <tt>unordered_set</tt> using the specified hash function, key equality function,
|
|
and allocator, and using at least <tt>n</tt> buckets. If <tt>n</tt> is not provided, the number of buckets is
|
|
<ins>unspecified</ins><del>impldefdefault number of buckets in <tt>unordered_set</tt></del>.
|
|
Then inserts elements from the range <tt>[f, l)</tt>. <tt>max_load_factor()</tt> returns <tt>1.0</tt>.
|
|
</p></blockquote>
|
|
<blockquote><p>
|
|
4 <i>Complexity</i>: <del>Average case linear, worst case quadratic</del><ins>Linear in the number of buckets.
|
|
In the average case linear in <tt><i>N</i></tt> and in the worst case quadratic in <tt><i>N</i></tt> to insert
|
|
the elements, where <tt><i>N</i></tt> is equal to number of elements in the range <tt>[f,l)</tt></ins>.
|
|
</p></blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Modify 23.5.7.2 [unord.multiset.cnstr] p. 1-4 as indicated (The edits of p. 1 and p. 3 attempt to fix some
|
|
editorial oversight.):</p>
|
|
|
|
<blockquote><pre>
|
|
explicit unordered_multiset(size_type n = <i>see below</i>,
|
|
const hasher& hf = hasher(),
|
|
const key_equal& eql = key_equal(),
|
|
const allocator_type& a = allocator_type());
|
|
</pre><blockquote><p>
|
|
1 <i>Effects</i>: Constructs an empty <tt>unordered_multiset</tt> using the specified hash function, key equality function,
|
|
and allocator, and using at least <tt>n</tt> buckets. If <tt>n</tt> is not provided, the number of buckets is
|
|
<ins>unspecified</ins><del>impldefdefault number of buckets in <tt>unordered_multiset</tt></del>.
|
|
<tt>max_load_factor()</tt> returns <tt>1.0</tt>.
|
|
</p></blockquote>
|
|
<blockquote><p>
|
|
2 <i>Complexity</i>: <del>Constant</del><ins>Linear in the number of buckets</ins>.
|
|
</p></blockquote>
|
|
</blockquote>
|
|
|
|
<blockquote><pre>
|
|
template <class InputIterator>
|
|
unordered_multiset(InputIterator f, InputIterator l,
|
|
size_type n = <i>see below</i>,
|
|
const hasher& hf = hasher(),
|
|
const key_equal& eql = key_equal(),
|
|
const allocator_type& a = allocator_type());
|
|
</pre><blockquote><p>
|
|
3 <i>Effects</i>: Constructs an empty <tt>unordered_multiset</tt> using the specified hash function, key equality function,
|
|
and allocator, and using at least <tt>n</tt> buckets. If <tt>n</tt> is not provided, the number of buckets is
|
|
<ins>unspecified</ins><del>impldefdefault number of buckets in <tt>unordered_multiset</tt></del>.
|
|
Then inserts elements from the range <tt>[f, l)</tt>. <tt>max_load_factor()</tt> returns <tt>1.0</tt>.
|
|
</p></blockquote>
|
|
<blockquote><p>
|
|
4 <i>Complexity</i>: <del>Average case linear, worst case quadratic</del><ins>Linear in the number of buckets.
|
|
In the average case linear in <tt><i>N</i></tt> and in the worst case quadratic in <tt><i>N</i></tt> to insert
|
|
the elements, where <tt><i>N</i></tt> is equal to number of elements in the range <tt>[f,l)</tt></ins>.
|
|
</p></blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1184"></a>1184. Feature request: dynamic bitset</h3>
|
|
<p><b>Section:</b> 23.3.6 [vector] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-07-29 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#vector">issues</a> in [vector].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Opened at Alisdair's request, steming from <a href="lwg-closed.html#96">96</a>.
|
|
Alisdair recommends NAD Future.
|
|
</p>
|
|
|
|
<p><i>[
|
|
2009-10 Santa Cruz:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
NAD Future. We want a heap allocated bitset, but we don't have one today and
|
|
don't have time to add one.
|
|
</p></blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1188"></a>1188. Unordered containers should have a minimum load factor as well as a maximum</h3>
|
|
<p><b>Section:</b> 23.2.5 [unord.req], 23.5 [unord] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Matt Austern <b>Opened:</b> 2009-08-10 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#unord.req">issues</a> in [unord.req].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Unordered associative containers have a notion of a maximum load factor:
|
|
when the number of elements grows large enough, the containers
|
|
automatically perform a rehash so that the number of elements per bucket
|
|
stays below a user-specified bound. This ensures that the hash table's
|
|
performance characteristics don't change dramatically as the size
|
|
increases.
|
|
</p>
|
|
|
|
<p>
|
|
For similar reasons, Google has found it useful to specify a minimum
|
|
load factor: when the number of elements shrinks by a large enough, the
|
|
containers automatically perform a rehash so that the number of elements
|
|
per bucket stays above a user-specified bound. This is useful for two
|
|
reasons. First, it prevents wasting a lot of memory when an unordered
|
|
associative container grows temporarily. Second, it prevents amortized
|
|
iteration time from being arbitrarily large; consider the case of a hash
|
|
table with a billion buckets and only one element. (This was discussed
|
|
even before TR1 was published; it was TR issue 6.13, which the LWG
|
|
closed as NAD on the grounds that it was a known design feature.
|
|
However, the LWG did not consider the approach of a minimum load
|
|
factor.)
|
|
</p>
|
|
|
|
<p>
|
|
The only interesting question is when shrinking is allowed. In principle
|
|
the cleanest solution would be shrinking on erase, just as we grow on
|
|
insert. However, that would be a usability problem; it would break a
|
|
number of common idioms involving erase. Instead, Google's hash tables
|
|
only shrink on insert and rehash.
|
|
</p>
|
|
|
|
<p>
|
|
The proposed resolution allows, but does not require, shrinking in
|
|
rehash, mostly because a postcondition for rehash that involves the
|
|
minimum load factor would be fairly complicated. (It would probably have
|
|
to involve a number of special cases and it would probably have to
|
|
mention yet another parameter, a minimum bucket count.)
|
|
</p>
|
|
|
|
<p>
|
|
The current behavior is equivalent to a minimum load factor of 0. If we
|
|
specify that 0 is the default, this change will have no impact on
|
|
backward compatibility.
|
|
</p>
|
|
|
|
|
|
<p><i>[
|
|
2010 Rapperswil:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
This seems to a useful extension, but is too late for 0x.
|
|
|
|
Move to Tentatively NAD Future.
|
|
</p></blockquote>
|
|
|
|
<p><i>[
|
|
Moved to NAD Future at 2010-11 Batavia
|
|
]</i></p>
|
|
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Add two new rows, and change rehash's postcondition in the unordered
|
|
associative container requirements table in 23.2.5 [unord.req]:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 87 — Unordered associative container requirements
|
|
(in addition to container)</caption>
|
|
|
|
<tr>
|
|
<th>Expression</th><th>Return type</th><th>Assertion/note pre-/post-condition</th>
|
|
<th>Complexity</th>
|
|
</tr>
|
|
<tr>
|
|
<td><ins>
|
|
<tt>a.min_load_factor()</tt>
|
|
</ins></td>
|
|
<td><ins>
|
|
<tt>float</tt>
|
|
</ins></td>
|
|
<td><ins>
|
|
Returns a non-negative number that the container attempts to keep the
|
|
load factor greater than or equal to. The container automatically
|
|
decreases the number of buckets as necessary to keep the load factor
|
|
above this number.
|
|
</ins></td>
|
|
<td><ins>
|
|
constant
|
|
</ins></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><ins><tt>a.min_load_factor(z)</tt></ins></td>
|
|
<td><ins><tt>void</tt></ins></td>
|
|
<td><ins>Pre: <tt>z</tt> shall be non-negative. Changes the container's minimum
|
|
load factor, using <tt>z</tt> as a hint. [<i>Footnote:</i> the minimum
|
|
load factor should be significantly smaller than the maximum.
|
|
If <tt>z</tt> is too large, the implementation may reduce it to a more sensible value.]
|
|
</ins></td>
|
|
<td><ins>
|
|
constant
|
|
</ins></td>
|
|
</tr>
|
|
<tr>
|
|
<td><tt>a.rehash(n)</tt></td>
|
|
<td><tt>void</tt></td>
|
|
<td>
|
|
Post: <ins><tt>a.bucket_count() >= n</tt>, and <tt>a.size() <= a.bucket_count()
|
|
* a.max_load_factor()</tt>. [<i>Footnote:</i> It is intentional that the
|
|
postcondition does not mention the minimum load factor.
|
|
This member function is primarily intended for cases where the user knows
|
|
that the container's size will increase soon, in which case the container's
|
|
load factor will temporarily fall below <tt>a.min_load_factor()</tt>.]</ins>
|
|
<del>
|
|
<tt>a.bucket_cout > a.size() / a.max_load_factor()</tt> and <tt>a.bucket_count()
|
|
>= n</tt>.
|
|
</del>
|
|
</td>
|
|
<td>
|
|
Average case linear in <tt>a.size()</tt>, worst case quadratic.
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
</blockquote>
|
|
|
|
<p>
|
|
Add a footnote to 23.2.5 [unord.req] p12:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
The insert members shall not affect the validity of references to
|
|
container elements, but may invalidate all iterators to the container.
|
|
The erase members shall invalidate only iterators and references to the
|
|
erased elements.
|
|
</p>
|
|
|
|
<blockquote><p>
|
|
[A consequence of these requirements is that while insert may change the
|
|
number of buckets, erase may not. The number of buckets may be reduced
|
|
on calls to insert or rehash.]
|
|
</p></blockquote>
|
|
</blockquote>
|
|
|
|
<p>
|
|
Change paragraph 13:
|
|
</p>
|
|
|
|
<blockquote><p>
|
|
The insert members shall not affect the validity of iterators if
|
|
<del><tt>(N+n) < z * B</tt></del> <ins><tt>zmin * B <= (N+n) <= zmax * B</tt></ins>,
|
|
where <tt>N</tt> is the number of elements in
|
|
the container prior to the insert operation, <tt>n</tt> is the number of
|
|
elements inserted, <tt>B</tt> is the container's bucket count,
|
|
<ins><tt>zmin</tt> is the container's minimum load factor,</ins>
|
|
and <tt>z<ins>max</ins></tt> is the container's maximum load factor.
|
|
</p></blockquote>
|
|
|
|
<p>
|
|
Add to the <tt>unordered_map</tt> class synopsis in section 23.5.4 [unord.map],
|
|
the <tt>unordered_multimap</tt> class synopsis
|
|
in 23.5.5 [unord.multimap], the <tt>unordered_set</tt> class synopsis in
|
|
23.5.6 [unord.set], and the <tt>unordered_multiset</tt> class synopsis
|
|
in 23.5.7 [unord.multiset]:
|
|
</p>
|
|
|
|
<blockquote><pre><ins>
|
|
float min_load_factor() const;
|
|
void min_load_factor(float z);
|
|
</ins></pre></blockquote>
|
|
|
|
<p>
|
|
In 23.5.4.2 [unord.map.cnstr], 23.5.5.2 [unord.multimap.cnstr], 23.5.6.2 [unord.set.cnstr], and
|
|
23.5.7.2 [unord.multiset.cnstr], change:
|
|
</p>
|
|
|
|
<blockquote><p>
|
|
... <tt>max_load_factor()</tt> returns 1.0 <ins>and
|
|
<tt>min_load_factor()</tt> returns 0</ins>.
|
|
</p></blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1201"></a>1201. Do we always want to unwrap <tt>ref</tt>-wrappers in <tt>make_tuple</tt></h3>
|
|
<p><b>Section:</b> 20.4.2.4 [tuple.creation], 20.3 [pairs] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-09-05 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#tuple.creation">issues</a> in [tuple.creation].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Spotting a recent thread on the boost lists regarding collapsing
|
|
optional representations in <tt>optional<optional<T>></tt> instances, I wonder if
|
|
we have some of the same issues with <tt>make_tuple</tt>, and now <tt>make_pair</tt>?
|
|
</p>
|
|
|
|
<p>
|
|
Essentially, if my generic code in my own library is handed a
|
|
<tt>reference_wrapper</tt> by a user, and my library in turn delegates some logic
|
|
to <tt>make_pair</tt> or <tt>make_tuple</tt>, then I am going to end up with a <tt>pair</tt>/<tt>tuple</tt>
|
|
holding a real reference rather than the intended reference wrapper.
|
|
</p>
|
|
|
|
<p>
|
|
There are two things as a library author I can do at this point:
|
|
</p>
|
|
|
|
<ol style="list-style-type:lower-roman">
|
|
<li>
|
|
document my library also has the same reference-wrapper behaviour as
|
|
<tt>std::make_tuple</tt>
|
|
</li>
|
|
<li>
|
|
roll my own <tt>make_tuple</tt> that does not unwrap rereferences, a lost
|
|
opportunity to re-use the standard library.
|
|
</li>
|
|
</ol>
|
|
|
|
<p>
|
|
(There may be some metaprogramming approaches my library can use to wrap
|
|
the <tt>make_tuple</tt> call, but all will be significantly more complex than
|
|
simply implementing a simplified <tt>make_tuple</tt>.)
|
|
</p>
|
|
|
|
<p>
|
|
Now I don't propose we lose this library facility, I think unwrapping
|
|
references will be the common behaviour. However, we might want to
|
|
consider adding another overload that does nothing special with
|
|
<tt>ref</tt>-wrappers. Note that we already have a second overload of
|
|
<tt>make_tuple</tt> in the library, called <tt>tie</tt>.
|
|
</p>
|
|
|
|
<p><i>[
|
|
2009-09-30 Daniel adds:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote>
|
|
<p>
|
|
I suggest to change the currently proposed paragraph for
|
|
<tt>make_simple_pair</tt>
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
template<typename... Types>
|
|
pair<typename decay<Types>::type...> make_simple_pair(Types&&... t);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
<del><i>Type requirements:</i> <tt>sizeof...(Types) == 2</tt>.</del>
|
|
<ins><i>Remarks:</i> The program shall be ill-formed, if
|
|
<tt>sizeof...(Types) != 2</tt>.</ins>
|
|
</p>
|
|
<p>
|
|
...
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
|
|
<p>
|
|
or alternatively (but with a slightly different semantic):
|
|
</p>
|
|
|
|
<blockquote>
|
|
<blockquote><p>
|
|
<i>Remarks:</i> If <tt>sizeof...(Types) != 2</tt>, this function shall not
|
|
participate in overload resolution.
|
|
</p></blockquote>
|
|
</blockquote>
|
|
|
|
<p>
|
|
to follow a currently introduced style and because the library does
|
|
not have yet a specific "<i>Type requirements</i>" element. If such thing
|
|
would be considered as useful this should be done as a separate
|
|
issue. Given the increasing complexity of either of these wordings
|
|
it might be preferable to use the normal two-argument-declaration
|
|
style again in either of the following ways:
|
|
</p>
|
|
|
|
<ol style="list-style-type:upper-alpha">
|
|
<li>
|
|
<pre>template<class T1, class T2>
|
|
pair<typename decay<T1>::type, typename decay<T2>::type>
|
|
make_simple_pair(T1&& t1, T2&& t2);
|
|
</pre>
|
|
</li>
|
|
<li>
|
|
<pre>template<class T1, class T2>
|
|
pair<V1, V2> make_simple_pair(T1&& t1, T2&& t2);
|
|
</pre>
|
|
<blockquote><p>
|
|
Let <tt>V1</tt> be <tt>typename decay<T1>::type</tt> and <tt>V2</tt> be
|
|
<tt>typename decay<T2>::type</tt>.
|
|
</p></blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
</blockquote>
|
|
|
|
<p><i>[
|
|
2009-10 post-Santa Cruz:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
Mark as Tentatively NAD Future.
|
|
</p></blockquote>
|
|
|
|
|
|
|
|
<p><b>Rationale:</b></p>
|
|
<p>
|
|
Does not have sufficient support at this time. May wish to reconsider for a
|
|
future standard.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Add the following function to 20.3 [pairs] and signature in
|
|
appropriate synopses:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
template<typename... Types>
|
|
pair<typename decay<Types>::type...> make_simple_pair(Types&&... t);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
<i>Type requirements:</i> <tt>sizeof...(Types) == 2</tt>.
|
|
</p>
|
|
<p>
|
|
<i>Returns:</i> <tt>pair<typename decay<Types>::type...>(std::forward<Types>(t)...)</tt>.
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
|
|
<p><i>[
|
|
Draughting note: I chose a variadic representation similar to <tt>make_tuple</tt>
|
|
rather than naming both types as it is easier to read through the
|
|
clutter of metaprogramming this way. Given there are exactly two
|
|
elements, the committee may prefer to draught with two explicit template
|
|
type parameters instead
|
|
]</i></p>
|
|
|
|
|
|
<p>
|
|
Add the following function to 20.4.2.4 [tuple.creation] and
|
|
signature in appropriate synopses:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
template<typename... Types>
|
|
tuple<typename decay<Types>::type...> make_simple_tuple(Types&&... t);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
<i>Returns:</i> <tt>tuple<typename decay<Types>::type...>(std::forward<Types>(t)...)</tt>.
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1203"></a>1203. More useful rvalue stream insertion</h3>
|
|
<p><b>Section:</b> 27.7.3.9 [ostream.rvalue], 27.7.2.6 [istream.rvalue] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-09-06 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
27.7.3.9 [ostream.rvalue] was created to preserve the ability to insert
|
|
into (and extract from 27.7.2.6 [istream.rvalue]) rvalue streams:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
template <class charT, class traits, class T>
|
|
basic_ostream<charT, traits>&
|
|
operator<<(basic_ostream<charT, traits>&& os, const T& x);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
1 <i>Effects:</i> <tt>os << x</tt>
|
|
</p>
|
|
<p>
|
|
2 <i>Returns:</i> <tt>os</tt>
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
|
|
<p>
|
|
This is good as it allows code that wants to (for example) open, write to, and
|
|
close an <tt>ofstream</tt> all in one statement:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
std::ofstream("log file") << "Some message\n";
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
However, I think we can easily make this "rvalue stream helper" even easier to
|
|
use. Consider trying to quickly create a formatted string. With the current
|
|
spec you have to write:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
std::string s = static_cast<std::ostringstream&>(std::ostringstream() << "i = " << i).str();
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
This will store "<tt>i = 10</tt>" (for example) in the string <tt>s</tt>. Note
|
|
the need to cast the stream back to <tt>ostringstream&</tt> prior to using
|
|
the member <tt>.str()</tt>. This is necessary because the inserter has cast
|
|
the <tt>ostringstream</tt> down to a more generic <tt>ostream</tt> during the
|
|
insertion process.
|
|
</p>
|
|
|
|
<p>
|
|
I believe we can re-specify the rvalue-inserter so that this cast is unnecessary.
|
|
Thus our customer now has to only type:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
std::string s = (std::ostringstream() << "i = " << i).str();
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
This is accomplished by having the rvalue stream inserter return an rvalue of
|
|
the same type, instead of casting it down to the base class. This is done by
|
|
making the stream generic, and constraining it to be an rvalue of a type derived
|
|
from <tt>ios_base</tt>.
|
|
</p>
|
|
|
|
<p>
|
|
The same argument and solution also applies to the inserter. This code has been
|
|
implemented and tested.
|
|
</p>
|
|
|
|
<p><i>[
|
|
2009 Santa Cruz:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
NAD Future. No concensus for change.
|
|
</p></blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Change 27.7.2.6 [istream.rvalue]:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
template <class <del>charT, class traits</del> <ins>Istream</ins>, class T>
|
|
<del>basic_istream<charT, traits>&</del> <ins>Istream&&</ins>
|
|
operator>>(<del>basic_istream<charT, traits></del> <ins>Istream</ins>&& is, T& x);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
1 <i>Effects:</i> <tt>is >> x</tt>
|
|
</p>
|
|
<p>
|
|
2 <i>Returns:</i> <tt><ins>std::move(</ins>is<ins>)</ins></tt>
|
|
</p>
|
|
<p><ins>
|
|
3 <i>Remarks:</i> This signature shall participate in overload resolution if
|
|
and only if <tt>Istream</tt> is not an lvalue reference type and is derived from
|
|
<tt>ios_base</tt>.
|
|
</ins></p>
|
|
</blockquote>
|
|
</blockquote>
|
|
|
|
<p>
|
|
Change 27.7.3.9 [ostream.rvalue]:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
template <class <del>charT, class traits</del> <ins>Ostream</ins>, class T>
|
|
<del>basic_ostream<charT, traits>&</del> <ins>Ostream&&</ins>
|
|
operator<<(<del>basic_ostream<charT, traits></del> <ins>Ostream</ins>&& os, const T& x);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
1 <i>Effects:</i> <tt>os << x</tt>
|
|
</p>
|
|
<p>
|
|
2 <i>Returns:</i> <tt><ins>std::move(</ins>os<ins>)</ins></tt>
|
|
</p>
|
|
<p><ins>
|
|
3 <i>Remarks:</i> This signature shall participate in overload resolution if
|
|
and only if <tt>Ostream</tt> is not an lvalue reference type and is derived from
|
|
<tt>ios_base</tt>.
|
|
</ins></p>
|
|
</blockquote>
|
|
</blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1213"></a>1213. Meaning of valid and singular iterator underspecified</h3>
|
|
<p><b>Section:</b> 24.2 [iterator.requirements] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-09-19 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The terms <em>valid</em> iterator and <em>singular</em> aren't
|
|
properly defined. The fuzziness of those terms became even worse
|
|
after the resolution of <a href="lwg-defects.html#208">208</a> (including further updates by <a href="lwg-defects.html#278">278</a>). In
|
|
24.2 [iterator.requirements] as of
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
|
|
the standard says now:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
5 - These values are called past-the-end values. Values of an iterator <tt>i</tt> for
|
|
which the expression <tt>*i</tt> is defined are called dereferenceable. The library
|
|
never assumes that past-the-end values are dereferenceable. Iterators
|
|
can also have singular values that are not associated with any
|
|
container. [...] Results of most expressions are undefined for singular
|
|
values; the only exceptions are destroying an iterator that holds a
|
|
singular value and the assignment of a non-singular value to an iterator
|
|
that holds a singular value. [...] Dereferenceable values are always
|
|
non-singular.
|
|
</p>
|
|
|
|
<p>
|
|
10 - An invalid iterator is an iterator that may be singular.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p>
|
|
First, issue <a href="lwg-defects.html#208">208</a> intentionally removed the earlier constraint that past-the-end
|
|
values are always non-singular. The reason for this was to support null
|
|
pointers as past-the-end iterators of e.g. empty sequences. But there
|
|
seem to exist different views on what a singular (iterator) value is. E.g.
|
|
according to the <a href="http://www.sgi.com/tech/stl/trivial.html">SGI definition</a>
|
|
a null pointer is <em>not</em> a singular value:
|
|
</p>
|
|
|
|
<blockquote><p>
|
|
Dereferenceable iterators are always nonsingular, but the converse is
|
|
not true.
|
|
For example, a null pointer is nonsingular (there are well defined operations
|
|
involving null pointers) even thought it is not dereferenceable.
|
|
</p></blockquote>
|
|
|
|
<p>
|
|
and <a href="http://www.sgi.com/tech/stl/InputIterator.html">proceeds</a>:
|
|
</p>
|
|
|
|
<blockquote><p>
|
|
An iterator is valid if it is dereferenceable or past-the-end.
|
|
</p></blockquote>
|
|
|
|
<p>
|
|
Even if the standard prefers a different meaning of singular here, the
|
|
change was incomplete, because by restricting feasible expressions of singular
|
|
iterators to destruction and assignment isn't sufficient for a past-the-end
|
|
iterator: Of-course it must still be equality-comparable and in general be a readable value.
|
|
</p>
|
|
|
|
<p>
|
|
Second, the standard doesn't clearly say whether a past-the-end value is
|
|
a valid iterator or not. E.g. 20.7.12 [specialized.algorithms]/1 says:
|
|
</p>
|
|
|
|
<blockquote><p>
|
|
In all of the following algorithms, the formal template parameter <tt>ForwardIterator</tt>
|
|
is required to satisfy the requirements of a forward iterator (24.1.3)
|
|
[..], and is required to have the property that no exceptions are thrown from [..], or
|
|
dereference of valid iterators.
|
|
</p></blockquote>
|
|
|
|
<p>
|
|
The standard should make better clear what "singular pointer" and "valid
|
|
iterator" means. The fact that the meaning of a valid <em>value</em>
|
|
has a core language meaning doesn't imply that for an iterator concept
|
|
the term "valid iterator" has the same meaning.
|
|
</p>
|
|
|
|
<p>
|
|
Let me add a final example: In X [allocator.concepts.members] of
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>
|
|
we find:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
pointer X::allocate(size_type n);
|
|
</pre>
|
|
|
|
<blockquote><p>
|
|
11 <i>Returns:</i> a pointer to the allocated memory. [<i>Note:</i> if <tt>n == 0</tt>, the return
|
|
value is unspecified. —<i>end note</i>]
|
|
</p></blockquote>
|
|
|
|
<p>
|
|
[..]
|
|
</p>
|
|
|
|
<pre>
|
|
void X::deallocate(pointer p, size_type n);
|
|
</pre>
|
|
|
|
<blockquote><p>
|
|
<i>Preconditions:</i> <tt>p</tt> shall be a non-singular pointer value obtained from a call
|
|
to <tt>allocate()</tt> on this allocator or one that compares equal to it.
|
|
</p></blockquote>
|
|
</blockquote>
|
|
|
|
<p>
|
|
If singular pointer value would include null pointers this make the
|
|
preconditions
|
|
unclear if the pointer value is a result of <tt>allocate(0)</tt>: Since the return value
|
|
is unspecified, it could be a null pointer. Does that mean that programmers
|
|
need to check the pointer value for a null value before calling deallocate?
|
|
</p>
|
|
|
|
<p><i>[
|
|
2010-11-09 Daniel comments:
|
|
]</i></p>
|
|
|
|
|
|
<p>
|
|
A later paper is in preparation.
|
|
</p>
|
|
|
|
<p><i>[
|
|
2010 Batavia:
|
|
]</i></p>
|
|
|
|
|
|
<p>
|
|
Doesn't need to be resolved for Ox
|
|
</p>
|
|
|
|
|
|
<p><i>[2014-02-20 Re-open Deferred issues as Priority 4]</i></p>
|
|
|
|
|
|
<p>
|
|
Consider to await the paper.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1217"></a>1217. Quaternion support</h3>
|
|
<p><b>Section:</b> 26.4 [complex.numbers] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Ted Shaneyfelt <b>Opened:</b> 2009-09-26 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#complex.numbers">active issues</a> in [complex.numbers].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#complex.numbers">issues</a> in [complex.numbers].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Concerning mathematically proper operation of the type:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
complex<complex<T> >
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
Generally accepted mathematical semantics of such a construct correspond
|
|
to quaternions through Cayly-Dickson construct
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
(w+xi) + (y+zi) j
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
The proper implementation seems straightforward by adding a few
|
|
declarations like those below. I have included operator definition for
|
|
combining real scalars and complex types, as well, which seems
|
|
appropriate, as algebra of complex numbers allows mixing complex and
|
|
real numbers with operators. It also allows for constructs such as
|
|
<tt>complex<double> i=(0,1), x = 12.34 + 5*i;</tt>
|
|
</p>
|
|
|
|
<p>
|
|
Quaternions are often used in areas such as computer graphics, where,
|
|
for example, they avoid the problem of Gimbal lock when rotating objects
|
|
in 3D space, and can be more efficient than matrix multiplications,
|
|
although I am applying them to a different field.
|
|
</p>
|
|
|
|
<pre>
|
|
/////////////////////////ALLOW OPERATORS TO COMBINE REAL SCALARS AND COMPLEX VALUES /////////////////////////
|
|
template<typename T,typename S> complex<T> operator+(const complex<T> x,const S a) {
|
|
complex<T> result(x.real()+a, x.imag());
|
|
return result;
|
|
}
|
|
template<typename T,typename S> complex<T> operator+(const S a,const complex<T> x) {
|
|
complex<T> result(a+x.real(), x.imag());
|
|
return result;
|
|
}
|
|
template<typename T,typename S> complex<T> operator-(const complex<T> x,const S a) {
|
|
complex<T> result(x.real()-a, x.imag());
|
|
return result;
|
|
}
|
|
template<typename T,typename S> complex<T> operator-(const S a,const complex<T> x) {
|
|
complex<T> result(a-x.real(), x.imag());
|
|
return result;
|
|
}
|
|
template<typename T,typename S> complex<T> operator*(const complex<T> x,const S a) {
|
|
complex<T> result(x.real()*a, x.imag()*a);
|
|
return result;
|
|
}
|
|
template<typename T,typename S> complex<T> operator*(const S a,const complex<T> x) {
|
|
complex<T> result(a*x.real(), a*x.imag());
|
|
return result;
|
|
}
|
|
|
|
/////////////////////////PROPERLY IMPLEMENT QUATERNION SEMANTICS/////////////////////////
|
|
template<typename T> double normSq(const complex<complex<T> >q) {
|
|
return q.real().real()*q.real().real()
|
|
+ q.real().imag()*q.real().imag()
|
|
+ q.imag().real()*q.imag().real()
|
|
+ q.imag().imag()*q.imag().imag();
|
|
}
|
|
template<typename T> double norm(const complex<complex<T> >q) {
|
|
return sqrt(normSq(q));
|
|
}
|
|
/////// Cayley-Dickson Construction
|
|
template<typename T> complex<complex<T> > conj(const complex<complex<T> > x) {
|
|
complex<complex<T> > result(conj(x.real()),-x.imag());
|
|
return result;
|
|
}
|
|
template<typename T> complex<complex<T> > operator*(const complex<complex<T> > ab,const complex<complex<T> > cd) {
|
|
complex<T> re(ab.real()*cd.real()-conj(cd.imag())*ab.imag());
|
|
complex<T> im(cd.imag()*ab.real()+ab.imag()*conj(cd.real()));
|
|
complex<complex<double> > q(re,im);
|
|
return q;
|
|
}
|
|
//// Quaternion division
|
|
template<typename S,typename T> complex<complex<T> > operator/(const complex<complex<T> > q,const S a) {
|
|
return q * (1/a);
|
|
}
|
|
template<typename S,typename T> complex<complex<T> > operator/(const S a,const complex<complex<T> > q) {
|
|
return a*conj(q)/normSq(q);
|
|
}
|
|
template<typename T> complex<complex<T> > operator/(const complex<complex<T> > n, const complex<complex<T> > d) {
|
|
return n * (conj(d)/normSq(d));
|
|
}
|
|
</pre>
|
|
|
|
<p><i>[
|
|
2009-10 Santa Cruz:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
NAD Future. There is no consensus or time to move this into C++0X.
|
|
</p></blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1235"></a>1235. Issue with C++0x random number proposal</h3>
|
|
<p><b>Section:</b> X [rand.concept.dist] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Matthias Troyer <b>Opened:</b> 2009-10-12 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
There exist optimized, vectorized vendor libraries for the creation of
|
|
random number generators, such as Intel's MKL [1] and AMD's ACML [2]. In
|
|
timing tests we have seen a performance gain of a factor of up to 80
|
|
(eighty) compared to a pure C++ implementation (in Boost.Random) when
|
|
using these generator to generate a sequence of normally distributed
|
|
random numbers. In codes dominated by the generation of random numbers
|
|
(we have application codes where random number generation is more than
|
|
50% of the CPU time) this factor 80 is very significant.
|
|
</p>
|
|
|
|
<p>
|
|
To make use of these vectorized generators, we use a C++ class modeling
|
|
the <tt>RandomNumberEngine</tt> concept and forwarding the generation of random
|
|
numbers to those optimized generators. For example:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
namespace mkl {
|
|
class mt19937 {.... };
|
|
}
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
For the generation of random variates we also want to dispatch to
|
|
optimized vectorized functions in the MKL or ACML libraries. See this
|
|
example:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
mkl::mt19937 eng;
|
|
std::normal_distribution<double> dist;
|
|
|
|
double n = dist(eng);
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
Since the variate generation is done through the <tt>operator()</tt> of the
|
|
distribution there is no customization point to dispatch to Intel's or
|
|
AMD's optimized functions to generate normally distributed numbers based
|
|
on the <tt>mt19937</tt> generator. Hence, the performance gain of 80 cannot be
|
|
achieved.
|
|
</p>
|
|
|
|
<p>
|
|
Contrast this with TR1:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
mkl::mt19937 eng;
|
|
std::tr1::normal_distribution<double> dist;
|
|
std::tr1::variate_generator<mkl::mt19937,std::tr1::normal_distribution<double> > rng(eng,dist);
|
|
double n = rng();
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
This - admittedly much uglier from an aestethic point of view - design
|
|
allowed optimization by specializing the <tt>variate_generator</tt> template for
|
|
<tt>mkl::mt19937</tt>:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
namespace std { namespace tr1 {
|
|
|
|
template<>
|
|
class variate_generator<mkl::mt19937,std::tr1::normal_distribution<double> > { .... };
|
|
|
|
} }
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
A similar customization point is missing in the C++0x design and
|
|
prevents the optimized vectorized version to be used.
|
|
</p>
|
|
|
|
<p>
|
|
Suggested resolution:
|
|
</p>
|
|
|
|
<p>
|
|
Add a customization point to the distribution concept. Instead of the
|
|
<tt>variate_generator</tt> template this can be done through a call to a
|
|
free function <tt>generate_variate</tt> found by ADL instead of
|
|
<tt>operator()</tt> of the distribution:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
template <RandomNumberDistribution, class RandomNumberEngine>
|
|
typename RandomNumberDistribution ::result_type
|
|
generate_variate(RandomNumberDistribution const& dist, RandomNumberEngine& eng);
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
This function can be overloaded for optimized enginges like
|
|
<tt>mkl::mt19937</tt>.
|
|
</p>
|
|
|
|
<p><i>[
|
|
2009-10 Santa Cruz:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
NAD Future. No time to add this feature for C++0X.
|
|
</p></blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1238"></a>1238. defining algorithms taking iterator for range</h3>
|
|
<p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-10-15 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#algorithms">active issues</a> in [algorithms].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#algorithms">issues</a> in [algorithms].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The library has many algorithms that take a source range represented by
|
|
a pair of iterators, and the start of some second sequence given by a
|
|
single iterator. Internally, these algorithms will produce undefined
|
|
behaviour if the second 'range' is not as large as the input range, but
|
|
none of the algorithms spell this out in Requires clauses, and there is
|
|
no catch-all wording to cover this in clause 17 or the front matter of
|
|
25.
|
|
</p>
|
|
|
|
<p>
|
|
There was an attempt to provide such wording in paper
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2944.pdf">n2944</a>
|
|
but this
|
|
seems incidental to the focus of the paper, and getting the wording of
|
|
this issue right seems substantially more difficult than the simple
|
|
approach taken in that paper. Such wording will be removed from an
|
|
updated paper, and hopefully tracked via the LWG issues list instead.
|
|
</p>
|
|
|
|
<p>
|
|
It seems there are several classes of problems here and finding wording
|
|
to solve all in one paragraph could be too much. I suspect we need
|
|
several overlapping requirements that should cover the desired range of
|
|
behaviours.
|
|
</p>
|
|
|
|
<p>
|
|
Motivating examples:
|
|
</p>
|
|
|
|
<p>
|
|
A good initial example is the <tt>swap_ranges</tt> algorithm. Here there is a
|
|
clear requirement that <tt>first2</tt> refers to the start of a valid range at
|
|
least as long as the range <tt>[first1, last1)</tt>. <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2944.pdf">n2944</a> tries to solve this
|
|
by positing a hypothetical <tt>last2</tt> iterator that is implied by the
|
|
signature, and requires <tt>distance(first2,last2) < distance(first1,last1)</tt>.
|
|
This mostly works, although I am uncomfortable assuming that <tt>last2</tt> is
|
|
clearly defined and well known without any description of how to obtain
|
|
it (and I have no idea how to write that).
|
|
</p>
|
|
|
|
<p>
|
|
A second motivating example might be the <tt>copy</tt> algorithm. Specifically,
|
|
let us image a call like:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
copy(istream_iterator<int>(is),istream_iterator(),ostream_iterator<int>(os));
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
In this case, our input iterators are literally simple <tt>InputIterators</tt>,
|
|
and the destination is a simple <tt>OutputIterator</tt>. In neither case am I
|
|
happy referring to <tt>std::distance</tt>, in fact it is not possible for the
|
|
<tt>ostream_iterator</tt> at all as it does not meet the requirements. However,
|
|
any wording we provide must cover both cases. Perhaps we might deduce
|
|
<tt>last2 == ostream_iterator<int>{}</tt>, but that might not always be valid for
|
|
user-defined iterator types. I can well imagine an 'infinite range'
|
|
that writes to <tt>/dev/null</tt> and has no meaningful <tt>last2</tt>.
|
|
</p>
|
|
|
|
<p>
|
|
The motivating example in <a
|
|
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2944.pdf"
|
|
>n2944</a> is <tt>std::equal</tt>, and that seems to fall somewhere between the
|
|
two.
|
|
</p>
|
|
|
|
<p>
|
|
Outlying examples might be <tt>partition_copy</tt> that takes two output
|
|
iterators, and the <tt>_n</tt> algorithms where a range is specified by a
|
|
specific number of iterations, rather than traditional iterator pair.
|
|
We should also <em>not</em> accidentally apply inappropriate constraints to
|
|
<tt>std::rotate</tt> which takes a third iterator that is not intended to be a
|
|
separate range at all.
|
|
</p>
|
|
|
|
<p>
|
|
I suspect we want some wording similar to:
|
|
</p>
|
|
|
|
<blockquote><p>
|
|
For algorithms that operate on ranges where the end iterator of the
|
|
second range is not specified, the second range shall contain at least
|
|
as many elements as the first.
|
|
</p></blockquote>
|
|
|
|
<p>
|
|
I don't think this quite captures the intent yet though. I am not sure
|
|
if 'range' is the right term here rather than sequence. More awkwardly,
|
|
I am not convinced we can describe an Output sequence such as produce by
|
|
an <tt>ostream_iterator</tt> as "containing elements", at least not as a
|
|
precondition to the call before they have been written.
|
|
</p>
|
|
|
|
<p>
|
|
Another idea was to describe require that the trailing iterator support
|
|
at least distance(input range) applications of <tt>operator++</tt> and may be
|
|
written through the same number of times if a mutable/output iterator.
|
|
</p>
|
|
|
|
<p>
|
|
We might also consider handling the case of an output range vs. an input
|
|
range in separate paragraphs, if that simplifies how we describe some of
|
|
these constraints.
|
|
</p>
|
|
|
|
<p><i>[
|
|
2009-11-03 Howard adds:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
Moved to Tentatively NAD Future after 5 positive votes on c++std-lib.
|
|
</p></blockquote>
|
|
|
|
|
|
<p><b>Rationale:</b></p>
|
|
<p>
|
|
Does not have sufficient support at this time. May wish to reconsider for a
|
|
future standard.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1242"></a>1242. Enable SCARY iterators</h3>
|
|
<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Herb Sutter <b>Opened:</b> 2009-10-21 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#containers">active issues</a> in [containers].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#containers">issues</a> in [containers].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2980.pdf">N2980</a>.
|
|
</p>
|
|
|
|
<p><i>[
|
|
2009-10 Santa Cruz
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
The paper was lengthy discussed but considerable concern remained to add this feature to C++0x.
|
|
Strong consensus was found to consider it for C++1x, though.
|
|
</p></blockquote>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p><p>
|
|
The LWG does not wish to make a change at this time.
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1282"></a>1282. A proposal to add <tt>std::split</tt> algorithm</h3>
|
|
<p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Igor Semenov <b>Opened:</b> 2009-12-07 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#algorithms">active issues</a> in [algorithms].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#algorithms">issues</a> in [algorithms].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<ol style="list-style-type:upper-roman">
|
|
|
|
<li>
|
|
<p>
|
|
Motivation and Scope
|
|
</p>
|
|
<p>
|
|
Splitting strings into parts by some set of delimiters is an often task, but
|
|
there is no simple and generalized solution in C++ Standard. Usually C++
|
|
developers use <tt>std::basic_stringstream<></tt> to split string into
|
|
parts, but there are several inconvenient restrictions:
|
|
</p>
|
|
|
|
<ul>
|
|
<li>
|
|
we cannot explicitly assign the set of delimiters;
|
|
</li>
|
|
<li>
|
|
this approach is suitable only for strings, but not for other types of
|
|
containers;
|
|
</li>
|
|
<li>
|
|
we have (possible) performance leak due to string instantiation.
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
Impact on the Standard
|
|
</p>
|
|
<p>
|
|
This algorithm doesn't interfere with any of current standard algorithms.
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
Design Decisions
|
|
</p>
|
|
<p>
|
|
This algorithm is implemented in terms of input/output iterators. Also, there is
|
|
one additional wrapper for <tt>const CharType *</tt> specified delimiters.
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
Example implementation
|
|
</p>
|
|
<pre>
|
|
template< class It, class DelimIt, class OutIt >
|
|
void split( It begin, It end, DelimIt d_begin, DelimIt d_end, OutIt out )
|
|
{
|
|
while ( begin != end )
|
|
{
|
|
It it = std::find_first_of( begin, end, d_begin, d_end );
|
|
*out++ = std::make_pair( begin, it );
|
|
begin = std::find_first_of( it, end, d_begin, d_end,
|
|
std::not2( std::equal_to< typename It::value_type >() ) );
|
|
}
|
|
}
|
|
|
|
template< class It, class CharType, class OutIt >
|
|
void split( It begin, It end, const CharType * delim, OutIt out )
|
|
{
|
|
split( begin, end, delim, delim + std::strlen( delim ), out );
|
|
}
|
|
</pre>
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
Usage
|
|
</p>
|
|
<pre>
|
|
std::string ss( "word1 word2 word3" );
|
|
std::vector< std::pair< std::string::const_iterator, std::string::const_iterator > > v;
|
|
split( ss.begin(), ss.end(), " ", std::back_inserter( v ) );
|
|
|
|
for ( int i = 0; i < v.size(); ++i )
|
|
{
|
|
std::cout << std::string( v[ i ].first, v[ i ].second ) << std::endl;
|
|
}
|
|
// word1
|
|
// word2
|
|
// word3
|
|
</pre>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
<p><i>[
|
|
2010-01-22 Moved to Tentatively NAD Future after 5 positive votes on c++std-lib.
|
|
Rationale added below.
|
|
]</i></p>
|
|
|
|
|
|
|
|
<p><b>Rationale:</b></p>
|
|
<p>
|
|
The LWG is not considering completely new features for standardization at this
|
|
time. We would like to revisit this good suggestion for a future TR and/or
|
|
standard.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Add to the synopsis in 25.1 [algorithms.general]:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
template< class ForwardIterator1, class ForwardIterator2, class OutputIterator >
|
|
void split( ForwardIterator1 first, ForwardIterator1 last,
|
|
ForwardIterator2 delimiter_first, ForwardIterator2 delimiter_last,
|
|
OutputIterator result );
|
|
|
|
template< class ForwardIterator1, class CharType, class OutputIterator >
|
|
void split( ForwardIterator1 first, ForwardIterator1 last,
|
|
const CharType * delimiters, OutputIterator result );
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
Add a new section [alg.split]:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
template< class ForwardIterator1, class ForwardIterator2, class OutputIterator >
|
|
void split( ForwardIterator1 first, ForwardIterator1 last,
|
|
ForwardIterator2 delimiter_first, ForwardIterator2 delimiter_last,
|
|
OutputIterator result );
|
|
</pre>
|
|
|
|
<blockquote>
|
|
<p>
|
|
1. <i>Effects:</i> splits the range <tt>[first, last)</tt> into parts, using any
|
|
element of <tt>[delimiter_first, delimiter_last)</tt> as a delimiter. Results
|
|
are pushed to output iterator in the form of <tt>std::pair<ForwardIterator1,
|
|
ForwardIterator1></tt>. Each of these pairs specifies a maximal subrange of
|
|
<tt>[first, last)</tt> which does not contain a delimiter.
|
|
</p>
|
|
<p>
|
|
2. <i>Returns:</i> nothing.
|
|
</p>
|
|
<p>
|
|
3. <i>Complexity:</i> Exactly <tt>last - first</tt> assignments.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<pre>
|
|
template< class ForwardIterator1, class CharType, class OutputIterator >
|
|
void split( ForwardIterator1 first, ForwardIterator1 last,
|
|
const CharType * delimiters, OutputIterator result );
|
|
</pre>
|
|
|
|
<blockquote>
|
|
<p>
|
|
1. <i>Effects:</i> split the range <tt>[first, last)</tt> into parts, using any
|
|
element of <tt>delimiters</tt> (interpreted as zero-terminated string) as a
|
|
delimiter. Results are pushed to output iterator in the form of
|
|
<tt>std::pair<ForwardIterator1, ForwardIterator1></tt>. Each of these
|
|
pairs specifies a maximal subrange of <tt>[first, last)</tt> which does not
|
|
contain a delimiter.
|
|
</p>
|
|
<p>
|
|
2. <i>Returns:</i> nothing.
|
|
</p>
|
|
<p>
|
|
3. <i>Complexity:</i> Exactly <tt>last - first</tt> assignments.
|
|
</p>
|
|
</blockquote>
|
|
|
|
</blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1289"></a>1289. Generic casting requirements for smart pointers</h3>
|
|
<p><b>Section:</b> 20.2 [utility] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Ion Gaztañaga <b>Opened:</b> 2009-12-14 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#utility">active issues</a> in [utility].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#utility">issues</a> in [utility].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
In section 17.6.3.5 [allocator.requirements], Table 40 — Allocator requirements,
|
|
the following expression is required for allocator pointers:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 40 — Allocator requirements</caption>
|
|
<tr>
|
|
<th>Expression</th>
|
|
<th>Return type</th>
|
|
<th>Assertion/note<br/>pre-/post-condition</th>
|
|
<th>Default</th>
|
|
</tr>
|
|
<tr>
|
|
<td><tt>static_cast<X::pointer>(w)</tt></td>
|
|
<td><tt>X::pointer</tt></td>
|
|
<td><tt>static_cast<X::pointer>(w) == p</tt></td>
|
|
<td> </td>
|
|
</tr>
|
|
</table>
|
|
</blockquote>
|
|
|
|
<p>
|
|
To achieve this expression, a smart pointer writer must introduce an explicit
|
|
conversion operator from <tt>smart_ptr<void></tt> to
|
|
<tt>smart_ptr<T></tt> so that
|
|
<tt>static_cast<pointer>(void_ptr)</tt> is a valid expression.
|
|
Unfortunately this explicit conversion weakens the safety of a smart pointer
|
|
since the following expression (invalid for raw pointers) would become valid:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
smart_ptr<void> smart_v = ...;
|
|
smart_ptr<T> smart_t(smart_v);
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
On the other hand, <tt>shared_ptr</tt> also defines its own casting functions in
|
|
20.8.2.2.9 [util.smartptr.shared.cast], and although it's unlikely that a
|
|
programmer will use <tt>shared_ptr</tt> as <tt>allocator::pointer</tt>, having
|
|
two different ways to do the same cast operation does not seem reasonable. A
|
|
possible solution would be to replace <tt>static_cast<X::pointer>(w)</tt>
|
|
expression with a user customizable (via ADL)
|
|
<tt>static_pointer_cast<value_type>(w)</tt>, and establish the
|
|
<tt>xxx_pointer_cast</tt> functions introduced by <tt>shared_ptr</tt> as the
|
|
recommended generic casting utilities of the standard.
|
|
</p>
|
|
|
|
<p>
|
|
Unfortunately, we've experienced problems in Boost when trying to establish
|
|
<tt>xxx_pointer_cast</tt> as customization points for generic libraries (<a
|
|
href="http://objectmix.com/c/40424-adl-lookup-explicit-template-parameters.html"
|
|
>http://objectmix.com/c/40424-adl-lookup-explicit-template-parameters.html</a>)
|
|
because these casting functions are called with explicit template parameters and
|
|
the standard says in 14.8.1 [temp.arg.explicit] p.8 "Explicit template
|
|
argument specification":
|
|
</p>
|
|
|
|
<blockquote><p>
|
|
8 ...But when a function template with explicit template arguments is used, the
|
|
call does not have the correct syntactic form unless there is a function
|
|
template with that name visible at the point of the call. If no such name is
|
|
visible, the call is not syntactically well-formed and argument-dependent lookup
|
|
does not apply.
|
|
</p></blockquote>
|
|
|
|
<p>
|
|
So we can do this:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
template<class BasePtr>
|
|
void generic_ptr_swap(BasePtr p)
|
|
{
|
|
//ADL customization point
|
|
swap(p, p);
|
|
//...
|
|
}
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
but not the following:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
template<class BasePtr>
|
|
void generic_ptr_algo(BasePtr p)
|
|
{
|
|
typedef std::pointer_traits<BasePtr>::template
|
|
rebind<Derived> DerivedPtr;
|
|
DerivedPtr dp = static_pointer_cast<Derived>(p);
|
|
}
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
The solution to make <tt>static_pointer_cast</tt> a customization point is to
|
|
add a generic declaration (no definition) of <tt>static_pointer_cast</tt> in a
|
|
namespace (like <tt>std</tt>) and apply "<tt>using
|
|
std::static_pointer_cast</tt>" declaration to activate ADL:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
namespace std{
|
|
|
|
template<typename U, typename T>
|
|
<i>unspecified</i>
|
|
static_pointer_cast(T&&) = delete;
|
|
|
|
}
|
|
|
|
template<class BasePtr>
|
|
void generic_ptr_algo(BasePtr p)
|
|
{
|
|
typedef std::pointer_traits<BasePtr>::template
|
|
rebind<Derived> DerivedPtr;
|
|
|
|
//ADL applies because static_pointer_cast is made
|
|
// visible according to [temp.arg.explicit]/8
|
|
using std::static_pointer_cast;
|
|
|
|
DerivedPtr dp = static_pointer_cast<Derived>(p);
|
|
|
|
//...
|
|
}
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
A complete solution will need also the definition of
|
|
<tt>static_pointer_cast</tt> for raw pointers, and this definition has been
|
|
present in Boost (<a
|
|
href="http://www.boost.org/boost/pointer_cast.hpp">http://www.boost.org/boost/
|
|
pointer_cast.hpp</a>) for years.
|
|
</p>
|
|
|
|
<p><i>[
|
|
2010-03-26 Daniel made editorial adjustments to the proposed wording.
|
|
]</i></p>
|
|
|
|
|
|
<p><i>[
|
|
Moved to NAD Future at 2010-11 Batavia
|
|
]</i></p>
|
|
|
|
<blockquote><p>
|
|
This is a new feature rather than a defect.
|
|
It can be added later: "this is such a hairy area that people will put up with changes"
|
|
</p></blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Add to section 20.2 [utility] Utility components, Header
|
|
<tt><utility></tt> synopsis:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
// 20.3.X, generic pointer cast functions
|
|
|
|
template<typename U, typename T>
|
|
<i>unspecified</i>
|
|
static_pointer_cast(T&&) = delete;
|
|
|
|
template<typename U, typename T>
|
|
<i>unspecified</i>
|
|
dynamic_pointer_cast(T&&) = delete;
|
|
|
|
template<typename U, typename T>
|
|
<i>unspecified</i>
|
|
const_pointer_cast(T&&) = delete;
|
|
|
|
//Overloads for raw pointers
|
|
template<typename U, typename T>
|
|
auto static_pointer_cast(T* t) -> decltype(static_cast<U*>(t));
|
|
|
|
template<typename U, typename T>
|
|
auto dynamic_pointer_cast(T* t) -> decltype(dynamic_cast<U*>(t));
|
|
|
|
template<typename U, typename T>
|
|
auto const_pointer_cast(T* t) -> decltype(const_cast<U*>(t));
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
Add to section 20.2 [utility] Utility components, a new subclause
|
|
20.3.X Pointer cast utilities [pointer.cast]:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
20.3.X Pointer cast utilities [pointer.cast]
|
|
</p>
|
|
|
|
<p>
|
|
1 The library defines generic pointer casting function templates so that template code
|
|
can explicitly make these names visible and activate argument-dependent lookup
|
|
for pointer cast calls.
|
|
</p>
|
|
|
|
<pre>
|
|
//Generic declarations
|
|
template<typename U, typename T>
|
|
<i>unspecified</i>
|
|
static_pointer_cast(T&&) = delete;
|
|
|
|
template<typename U, typename T>
|
|
<i>unspecified</i>
|
|
dynamic_pointer_cast(T&&) = delete;
|
|
|
|
template<typename U, typename T>
|
|
<i>unspecified</i>
|
|
const_pointer_cast(T&&) = delete;
|
|
</pre>
|
|
|
|
<p>
|
|
2 The library also defines overloads of these functions for raw pointers.
|
|
</p>
|
|
|
|
<pre>
|
|
//Overloads for raw pointers
|
|
template<typename U, typename T>
|
|
auto static_pointer_cast(T* t) -> decltype(static_cast<U*>(t));
|
|
</pre>
|
|
|
|
<blockquote><p>
|
|
<i>Returns:</i> <tt>static_cast<U*>(t)</tt>
|
|
</p></blockquote>
|
|
|
|
<pre>
|
|
template<typename U, typename T>
|
|
auto dynamic_pointer_cast(T* t) -> decltype(dynamic_cast<U*>(t));
|
|
</pre>
|
|
|
|
<blockquote><p>
|
|
<i>Returns:</i> <tt>dynamic_cast<U*>(t)</tt>
|
|
</p></blockquote>
|
|
|
|
<pre>
|
|
template<typename U, typename T>
|
|
auto const_pointer_cast(T* t) -> decltype(const_cast<U*>(t));
|
|
</pre>
|
|
|
|
<blockquote><p>
|
|
<i>Returns:</i> <tt>const_cast<U*>(t)</tt>
|
|
</p></blockquote>
|
|
|
|
<p>
|
|
[<i>Example:</i>
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
#include <utility> //static_pointer_cast
|
|
#include <memory> //pointer_traits
|
|
|
|
class Base{};
|
|
class Derived : public Base{};
|
|
|
|
template<class BasePtr>
|
|
void generic_pointer_code(BasePtr b)
|
|
{
|
|
typedef std::pointer_traits<BasePtr>::template
|
|
rebind<Derived> DerivedPtr;
|
|
|
|
using std::static_pointer_cast;
|
|
//ADL applies now that static_pointer_cast is visible
|
|
DerivedPtr d = static_pointer_cast<Derived>(b);
|
|
}
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
— <i>end example</i>]
|
|
</p>
|
|
|
|
</blockquote>
|
|
|
|
<p>
|
|
Replace in section 17.6.3.5 [allocator.requirements] Table 40 — Allocator
|
|
requirements, the following table entries for allocator pointers:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 40 — Allocator requirements</caption>
|
|
<tr>
|
|
<th>Expression</th>
|
|
<th>Return type</th>
|
|
<th>Assertion/note<br/>pre-/post-condition</th>
|
|
<th>Default</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>static<ins>_pointer</ins>_cast<<del>X::pointer</del><ins>T</ins>>(w)</tt></td>
|
|
<td><tt>X::pointer</tt></td>
|
|
<td><tt>static<ins>_pointer</ins>_cast<<del>X::pointer</del><ins>T</ins>>(w) == p</tt></td>
|
|
<td> </td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>static<ins>_pointer</ins>_cast<<del>X::const_pointer</del><ins>const T</ins>>(w)</tt></td>
|
|
<td><tt>X::const_pointer</tt></td>
|
|
<td><tt>static<ins>_pointer</ins>_cast<<del>X::const_pointer</del><ins>const T</ins>>(z) == q</tt></td>
|
|
<td> </td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1317"></a>1317. make_hash</h3>
|
|
<p><b>Section:</b> 20.9.13 [unord.hash] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Nicolai M. Josuttis <b>Opened:</b> 2010-02-10 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#unord.hash">active issues</a> in [unord.hash].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#unord.hash">issues</a> in [unord.hash].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Currently, the library lacks a convenient way to provide a hash function that
|
|
can be used with the provided unordered containers to allow the usage of non
|
|
trivial element types.
|
|
</p>
|
|
|
|
<p>
|
|
While we can easily declare an
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
std::unordered_set<int>
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
or
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
std::unordered_set<std::string>
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
we have no easy way to declare an <tt>unordered_set</tt> for a user defined
|
|
type. IMO, this is a big obstacle to use unordered containers in practice. Note
|
|
that in Java, the wide usage of <tt>HashMap</tt> is based on the fact that there
|
|
is always a default hash function provided.
|
|
</p>
|
|
|
|
<p>
|
|
Of course, a default hash function implies the risk to provide poor hash
|
|
functions. But often even poor hash functions are good enough.
|
|
</p>
|
|
|
|
<p>
|
|
While I really would like to see a default hash function, I don't propose it
|
|
here because this would probably introduce a discussion that's too big for this
|
|
state of C++0x.
|
|
</p>
|
|
|
|
<p>
|
|
However, I strongly suggest at least to provide a convenience variadic template
|
|
function <tt>make_hash<>()</tt> to allow an easy definition of a (possibly
|
|
poor) hash function.
|
|
</p>
|
|
|
|
<p>
|
|
As a consequence for a user-defined type such as
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
class Customer {
|
|
friend class CustomerHash;
|
|
private:
|
|
string firstname;
|
|
string lastname;
|
|
long no;
|
|
...
|
|
};
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
would allow to specify:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
class CustomerHash : public std::unary_function<Customer, std::size_t>
|
|
{
|
|
public:
|
|
std::size_t operator() (const Customer& c) const {
|
|
return make_hash(c.firstname,c.lastname,c.no);
|
|
}
|
|
};
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
instead of:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
class CustomerHash : public std::unary_function<Customer, std::size_t>
|
|
{
|
|
public:
|
|
std::size_t operator() (const Customer& c) const {
|
|
return std::hash<std::string>()(c.firstname) +
|
|
std::hash<std::string>()(c.lastname) +
|
|
std::hash<long>()(c.no);
|
|
}
|
|
};
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
Note that, in principle, we can either specify that
|
|
</p>
|
|
|
|
<blockquote><p>
|
|
<tt>make_hash</tt> returns the sum of a call of
|
|
<tt>std::hash<T>()(x)</tt> for each argument <tt>x</tt> of type
|
|
<tt>T</tt>
|
|
</p></blockquote>
|
|
|
|
<p>
|
|
or we can specify that
|
|
</p>
|
|
|
|
<blockquote><p>
|
|
<tt>make_hash</tt> provides a hash value for each argument, for which a
|
|
<tt>std::hash()</tt> function is provided
|
|
</p></blockquote>
|
|
|
|
<p>
|
|
with the possible note that the hash value may be poor or only a good hash value
|
|
if the ranges of all passed arguments is equally distributed.
|
|
</p>
|
|
|
|
<p>
|
|
For my convenience, I propose wording that describes
|
|
the concrete implementation.
|
|
</p>
|
|
|
|
<p><i>[
|
|
2010 Pittsburgh: Moved to NAD Editorial, rationale added below.
|
|
]</i></p>
|
|
|
|
|
|
|
|
|
|
<p><b>Rationale:</b></p>
|
|
<p>
|
|
There is no consensus to make this change at this time.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
In Function objects 20.9 [function.objects]
|
|
in paragraph 2 at the end of the Header <tt><functional></tt> synopsis
|
|
insert:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
// convenience functions
|
|
template <class T>
|
|
size_t make_hash (const T&);
|
|
template <class T, class... Types>
|
|
size_t make_hash (const T&, const Types&...);
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
In Class template hash 20.9.13 [unord.hash]
|
|
add:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<b>20.7.16.1 Hash creation functions [hash.creation]</b>
|
|
</p>
|
|
|
|
<pre>
|
|
template <class T>
|
|
size_t make_hash (const T& val);
|
|
</pre>
|
|
|
|
<blockquote><p>
|
|
<i>Returns:</i> <tt>hash<T>()(val);</tt>
|
|
</p></blockquote>
|
|
|
|
<pre>
|
|
template <class T, class... Types>
|
|
size_t make_hash (const T& val, const Types&... args);
|
|
</pre>
|
|
|
|
<blockquote><p>
|
|
<i>Returns:</i> <tt>hash<T>()(val) + std::make_hash(args...)</tt>
|
|
</p></blockquote>
|
|
|
|
</blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1320"></a>1320. Header for <tt>iter_swap</tt></h3>
|
|
<p><b>Section:</b> 24.3 [iterator.synopsis] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2010-02-16 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#iterator.synopsis">issues</a> in [iterator.synopsis].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The <tt>iter_swap</tt> function template appears in the
|
|
<tt><algorithm></tt> header, yet its main use is in building further
|
|
algorithms, not calling existing ones. The main clients are implementers of data
|
|
structures and their iterators, so it seems most appropriate to place the
|
|
template in the <tt><iterator></tt> header instead.
|
|
</p>
|
|
|
|
<p>
|
|
Note that this is not an issue for implementers of the standard library, as they
|
|
rarely use the standard headers directly, designing a more fine-grained set of
|
|
headers for their own internal use. This option is not available to customers
|
|
of the standard library.
|
|
</p>
|
|
|
|
<p>
|
|
Note that we cannot remove <tt>iter_swap</tt> from <tt><algorithm></tt>
|
|
without breaking code, but there is no reason we cannot offer the same
|
|
declaration via two standard headers. Alternatively, require
|
|
<tt><algorithm></tt> to <tt>#include <iterator></tt>, but
|
|
introducing the dependency on the iterator adaptors seems un-necessary.
|
|
</p>
|
|
|
|
<p><i>[
|
|
]</i></p>
|
|
|
|
|
|
<p>
|
|
Discussed possibly moving to <tt><utility></tt> but don't like that. Some not seeing this
|
|
as a defect, and want to keep it in <tt><algorithm></tt>. No one seems to feel strongly
|
|
about moving to <tt><iterator></tt>.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<p>
|
|
Add the declaration of <tt>iter_swap</tt> to the <tt><iterator></tt>
|
|
header synopsis (24.3 [iterator.synopsis]), with a note that it is
|
|
documented in clause 25 [algorithms].
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
...
|
|
template <class T, size_t N> T* end(T (&array)[N]);
|
|
|
|
<ins><i>// documented in 25 [algorithms]</i>
|
|
template<class ForwardIterator1, class ForwardIterator2>
|
|
void iter_swap(ForwardIterator1 a, ForwardIterator2 b);</ins>
|
|
</pre></blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1396"></a>1396. <tt>regex</tt> should support allocators</h3>
|
|
<p><b>Section:</b> 28.8 [re.regex] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#re.regex">issues</a> in [re.regex].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Duplicate of:</b> <a href="lwg-closed.html#1451">1451</a></p>
|
|
<p><b>Discussion:</b></p>
|
|
<p><b>Addresses US-104, US-141</b></p>
|
|
<p>
|
|
<tt>std::basic_regex</tt> should have an allocator for all the
|
|
reasons that a <tt>std::string</tt> does. For example, I can use
|
|
<tt>boost::interprocess</tt> to put a <tt>string</tt> or <tt>vector</tt>
|
|
in shared memory, but not a <tt>regex</tt>.
|
|
</p>
|
|
|
|
<p><i>[
|
|
Resolution proposed by ballot comment
|
|
]</i></p>
|
|
|
|
<p>
|
|
Add allocators to regexes
|
|
</p>
|
|
|
|
<p><i>[
|
|
2010-10-24 Daniel adds:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3171.pdf">n3171</a>
|
|
would solve this issue.
|
|
</p></blockquote>
|
|
|
|
<p><i>[2011-03-22 Madrid]</i></p>
|
|
|
|
|
|
<p>Close 1396 as NAD Future.</p>
|
|
|
|
|
|
<p><b>Rationale:</b></p><p>No consensus for a change at this time</p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1406"></a>1406. Support hashing smart-pointers based on <i>owner</i></h3>
|
|
<p><b>Section:</b> 20.8.2.2 [util.smartptr.shared] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Japan <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p><b>Addresses JP-5</b></p>
|
|
<p>
|
|
Hash support based on ownership sharing should be
|
|
supplied for <tt>shared_ptr</tt> and <tt>weak_ptr</tt>.
|
|
For two <tt>shared_ptr</tt> objects <tt>p</tt> and <tt>q</tt>, two distinct
|
|
equivalence relations can be defined. One is based on
|
|
equivalence of pointer values, which is derived from the
|
|
expression <tt>p.get() == q.get()</tt> (hereafter called <i>address based
|
|
equivalence relation</i>), the other is based on
|
|
equivalence of ownership sharing, which is derived from
|
|
the expression <tt>!p.owner_before(q) && !q.owner_before(p)</tt>
|
|
(hereafter called <i>ownership-based equivalence relation</i>).
|
|
These two equivalence relations are independent in
|
|
general. For example, a <tt>shared_ptr</tt> object created by the
|
|
constructor of the signature <tt>shared_ptr(shared_ptr<U>
|
|
const &, T *)</tt> could reveal a difference between these two
|
|
relations. Therefore, hash support based on each
|
|
equivalence relation should be supplied for <tt>shared_ptr</tt>.
|
|
However, while the standard library provides the hash
|
|
support for address-based one (20.9.11.6 paragraph 2), it
|
|
lacks the hash support for ownership-based one. In
|
|
addition, associative containers work well in combination
|
|
with the <tt>shared_ptr</tt>'s ownership-based comparison but
|
|
unordered associative containers don't. This is
|
|
inconsistent.
|
|
</p>
|
|
<p>
|
|
For the case of <tt>weak_ptr</tt>, hash support for the ownership based
|
|
equivalence relation can be safely defined on
|
|
<tt>weak_ptr</tt>s, and even on expired ones. The absence of
|
|
hash support for the ownership-based equivalence
|
|
relation is fatal, especially for expired <tt>weak_ptr</tt>s. And the
|
|
absence of such hash support precludes some quite
|
|
effective use-cases, e.g. erasing the <tt>unordered_map</tt> entry
|
|
of an expired <tt>weak_ptr</tt> key from a customized deleter
|
|
supplied to <tt>shared_ptr</tt>s.
|
|
</p>
|
|
<p>
|
|
Hash support for the ownership-based equivalence
|
|
relation cannot be provided by any user-defined manner
|
|
because information about ownership sharing is not
|
|
available to users at all. Therefore, the only way to provide
|
|
ownership-based hash support is to offer it intrusively by
|
|
the standard library.
|
|
</p>
|
|
<p>
|
|
As far as we know, such hash support is implementable.
|
|
Typical implementation of such hash function could return
|
|
the hash value of the pointer of the counter object that is
|
|
internally managed by <tt>shared_ptr</tt> and <tt>weak_ptr</tt>.
|
|
</p>
|
|
|
|
<p><i>[2010 Rapperswil:]</i></p>
|
|
|
|
<blockquote>
|
|
<p>No consensus to make this change at this time.</p>
|
|
</blockquote>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Add the following non-static member functions to
|
|
<tt>shared_ptr</tt> and <tt>weak_ptr</tt> class template;
|
|
</p>
|
|
<p>
|
|
Update [util.smartptr.shared], 20.9.11.2 paragraph 1
|
|
</p>
|
|
<pre>
|
|
namespace std{
|
|
template<class T> class shared_ptr {
|
|
public:
|
|
...
|
|
<ins>size_t owner_hash() const;</ins>
|
|
...
|
|
};
|
|
}
|
|
</pre>
|
|
<p>
|
|
Update [util.smartptr.weak], 20.9.11.3 paragraph 1
|
|
</p>
|
|
<pre>
|
|
namespace std{
|
|
template<class T> class weak_ptr {
|
|
public:
|
|
...
|
|
<ins>size_t owner_hash() const;</ins>
|
|
...
|
|
};
|
|
}
|
|
</pre>
|
|
<p>
|
|
These functions satisfy the following
|
|
requirements. Let <tt>p</tt> and <tt>q</tt> be objects of either
|
|
<tt>shared_ptr</tt> or <tt>weak_ptr</tt>, <tt>H</tt> be a hypothetical
|
|
function object type that satisfies the hash
|
|
requirements ([hash.requirements], 20.2.4) and <tt>h</tt> be an object of the
|
|
type <tt>H</tt>. The expression <tt>p.owner_hash()</tt> behaves
|
|
as if it were equivalent to the expression <tt>h(p)</tt>. In
|
|
addition, <tt>h(p) == h(q)</tt> must become <tt>true</tt> if <tt>p</tt> and
|
|
<tt>q</tt> share ownership.
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1422"></a>1422. <tt>vector<bool></tt> iterators are not random access</h3>
|
|
<p><b>Section:</b> 23.3.7 [vector.bool] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#vector.bool">issues</a> in [vector.bool].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p><b>Addresses GB-118</b></p>
|
|
<p>
|
|
<tt>vector<bool></tt> iterators are not random access iterators
|
|
because their reference type is a special class, and not
|
|
<tt>bool &</tt>. All standard libary operations taking iterators
|
|
should treat this iterator as if it was a random access iterator, rather
|
|
than a simple input iterator.
|
|
</p>
|
|
|
|
<p><i>[
|
|
Resolution proposed in ballot comment
|
|
]</i></p>
|
|
|
|
<p>
|
|
Either revise the iterator requirements to support proxy iterators
|
|
(restoring functionality that was lost when the Concept facility was
|
|
removed) or add an extra paragraph to the <tt>vector<bool></tt>
|
|
specification requiring the library to treat <tt>vector<bool></tt>
|
|
iterators as-if they were random access iterators, despite having the wrong
|
|
reference type.
|
|
</p>
|
|
|
|
<p><i>[
|
|
Rapperswil Review
|
|
]</i></p>
|
|
|
|
<p>
|
|
The consensus at Rapperswil is that it is too late for full support for
|
|
proxy iterators, but requiring the library to respect <tt>vector<bool></tt>
|
|
iterators as-if they were random access would be preferable to flagging
|
|
this container as deliberately incompatible with standard library algorithms.
|
|
</p>
|
|
<p>
|
|
Alisdair to write the note, which may become normative <i>Remark</i> depending
|
|
on the preferences of the project editor.
|
|
</p>
|
|
|
|
<p><i>[
|
|
Post-Rapperswil Alisdair provides wording
|
|
]</i></p>
|
|
|
|
<p>
|
|
Initial wording is supplied, deliberately using <i>Note</i> in preference to
|
|
<i>Remark</i> although the author notes his preference for <i>Remark</i>. The
|
|
issue of whether <tt>iterator_traits<vector<bool>>::iterator_category</tt>
|
|
is permitted to report <tt>random_access_iterator_tag</tt> or must report
|
|
<tt>input_iterator_tag</tt> is not addressed.
|
|
</p>
|
|
|
|
<p><i>[
|
|
Old Proposed Resolution:
|
|
]</i></p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
Insert a new paragraph into 23.3.7 [vector.bool] between p4 and p5:
|
|
</p>
|
|
<blockquote><p>
|
|
[<i>Note</i> All functions in the library that take a pair of iterators to
|
|
denote a range shall treat <tt>vector<bool></tt> iterators as-if they were
|
|
random access iterators, even though the <tt>reference</tt> type is not a
|
|
true reference.<i>-- end note</i>]
|
|
</p></blockquote>
|
|
</blockquote>
|
|
|
|
<p><i>[
|
|
2010-11 Batavia:
|
|
]</i></p>
|
|
|
|
<blockquote><p>
|
|
Closed as NAD Future, because the current iterator categories cannot correctly describe
|
|
<tt>vector<bool>::iterator</tt>. But saying that they are Random Access Iterators
|
|
is also incorrect, because it is not too hard to create a corresponding test that fails.
|
|
We should deal with the more general proxy iterator problem in the future, and see no
|
|
benefit to take a partial workaround specific to <tt>vector<bool></tt> now.
|
|
</p></blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
<p><b>Rationale:</b></p>
|
|
<p>
|
|
No consensus to make this change at this time.
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1459"></a>1459. Overlapping evaluations are allowed</h3>
|
|
<p><b>Section:</b> 29.3 [atomics.order] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Canada <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#atomics.order">active issues</a> in [atomics.order].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#atomics.order">issues</a> in [atomics.order].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Duplicate of:</b> <a href="lwg-closed.html#1458">1458</a></p>
|
|
<p><b>Discussion:</b></p>
|
|
<p><b>Addresses CA-21, GB-131</b></p>
|
|
<p>
|
|
29.4 [atomics.lockfree] p.8 states:
|
|
</p>
|
|
<blockquote><p>
|
|
An atomic store shall only store a value that has
|
|
been computed from constants and program input values
|
|
by a finite sequence of program evaluations, such
|
|
that each evaluation observes the values of variables
|
|
as computed by the last prior assignment in the
|
|
sequence.
|
|
</p></blockquote>
|
|
<p>
|
|
... but 1.9 [intro.execution] p.13 states:
|
|
</p>
|
|
<blockquote><p>
|
|
If A is not sequenced before B and B is not
|
|
sequenced before A, then A and B are unsequenced.
|
|
[ <em>Note</em>: The execution of unsequenced
|
|
evaluations can overlap. — <em>end note</em> ]
|
|
</p></blockquote>
|
|
<p>
|
|
Overlapping executions can make it impossible to
|
|
construct the sequence described in 29.4 [atomics.lockfree] p.8. We are not
|
|
sure of the intention here and do not offer a suggestion for
|
|
change, but note that 29.4 [atomics.lockfree] p.8 is the condition that prevents
|
|
out-of-thin-air reads.
|
|
</p>
|
|
<p>
|
|
For an example, suppose we have a function invocation
|
|
f(e1,e2). The evaluations of e1 and e2 can overlap.
|
|
Suppose that the evaluation of e1 writes y and reads x
|
|
whereas the evaluation of e2 reads y and writes x, with
|
|
reads-from edges as below (all this is within a single
|
|
thread).
|
|
</p>
|
|
<pre>
|
|
e1 e2
|
|
Wrlx y-- --Wrlx x
|
|
rf\ /rf
|
|
X
|
|
/ \
|
|
Rrlx x<- ->Rrlx y
|
|
</pre>
|
|
<p>
|
|
This seems like it should be allowed, but there seems to
|
|
be no way to produce a sequence of evaluations with the
|
|
property above.
|
|
</p>
|
|
<p>
|
|
In more detail, here the two evaluations, e1 and e2, are
|
|
being executed as the arguments of a function and are
|
|
consequently not sequenced-before each other. In
|
|
practice we'd expect that they could overlap (as allowed
|
|
by 1.9 [intro.execution] p.13), with the two writes taking effect before the two
|
|
reads. However, if we have to construct a linear order of
|
|
evaluations, as in 29.4 [atomics.lockfree] p.8, then the execution above is not
|
|
permited. Is that really intended?
|
|
</p>
|
|
|
|
<p><i>[
|
|
Resolution proposed by ballot comment
|
|
]</i></p>
|
|
|
|
<p>
|
|
Please clarify.
|
|
</p>
|
|
|
|
<p><i>[2011-03-09 Hans comments:]</i></p>
|
|
|
|
|
|
<p>I'm not proud of 29.3 [atomics.order] p9 (formerly p8), and I agree with the comments that this
|
|
isn't entirely satisfactory. 29.3 [atomics.order] p9 was designed to preclude
|
|
out-of-thin-air results for races among <tt>memory_order_relaxed</tt> atomics, in spite of
|
|
the fact that Java experience has shown we don't really know how to do that adequately. In
|
|
the long run, we probably want to revisit this.
|
|
<p/>
|
|
However, in the short term, I'm still inclined to declare this NAD, for two separate reasons:
|
|
</p>
|
|
|
|
<ol>
|
|
<li><p>1.9 [intro.execution] p15 states: "If a side effect on a scalar
|
|
object is unsequenced relative to either another side
|
|
effect on the same scalar object or a value computation
|
|
using the value of the same scalar object, the behavior is undefined."
|
|
I think the examples presented here have undefined behavior as a result.
|
|
It's not completely clear to me whether examples can be constructed
|
|
that exhibit this problem, and don't have undefined behavior.</p></li>
|
|
|
|
<li><p>This comment seems to be using a different meaning of "evaluation"
|
|
from what is used elsewhere in the standard. The sequence of evaluations
|
|
here doesn't have to consist of full expression evaluations. They
|
|
can be evaluations of operations like lvalue to rvalue conversion,
|
|
or individual assignments. In particular, the reads and writes
|
|
executed by <tt>e1</tt> and <tt>e2</tt> in the example could be treated as separate
|
|
evaluations for purposes of producing the sequence.
|
|
The definition of "sequenced before" in 1.9 [intro.execution] makes
|
|
little sense if the term "evaluation" is restricted to any notion
|
|
of complete expression. Perhaps we should add yet another note
|
|
to clarify this? 29.3 [atomics.order] p10 probably leads to
|
|
the wrong impression here.
|
|
<p/>
|
|
An alternative resolution would be to simply delete our flakey
|
|
attempt at preventing out-of-thin-air reads, by removing 29.3 [atomics.order] p9-11,
|
|
possibly adding a note that explains that we technically allow,
|
|
but strongly discourage them. If we were starting this from scratch
|
|
now, that would probably be my preference. But it seems like too drastic
|
|
a resolution at this stage.
|
|
</p></li>
|
|
</ol>
|
|
|
|
<p><i>[2011-03-24 Madrid]</i></p>
|
|
|
|
<p>
|
|
Moved to NAD Future
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1484"></a>1484. Need a way to join a thread with a timeout</h3>
|
|
<p><b>Section:</b> 30.3.1 [thread.thread.class] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p><b>Addresses US-183</b></p>
|
|
|
|
<p>
|
|
There is no way to join a thread with a timeout.
|
|
</p>
|
|
|
|
<p><i>[
|
|
Resolution proposed by ballot comment:
|
|
]</i></p>
|
|
|
|
<blockquote><p>
|
|
Add <tt>join_for</tt> and <tt>join_until</tt>. Or decide one should
|
|
never join a thread with a timeout since <tt>pthread_join</tt> doesn't have a
|
|
timeout version.
|
|
</p></blockquote>
|
|
|
|
<p><i>[
|
|
2010 Batavia
|
|
]</i></p>
|
|
|
|
<p>
|
|
The concurrency working group deemed this an extension beyond the scope of C++0x.
|
|
</p>
|
|
<p><b>Rationale:</b></p><p>The LWG does not wish to make a change at this time.</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1488"></a>1488. Improve interoperability between the C++0x and C1x threads APIs</h3>
|
|
<p><b>Section:</b> 30.4 [thread.mutex] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#thread.mutex">issues</a> in [thread.mutex].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p><b>Addresses US-185</b></p>
|
|
|
|
<p>
|
|
Cooperate with WG14 to improve interoperability between
|
|
the <tt>C++0x</tt> and <tt>C1x</tt> threads APIs. In particular, <tt>C1x</tt>
|
|
mutexes should be conveniently usable with a <tt>C++0x</tt>
|
|
<tt>lock_guard</tt>. Performance overheads for this combination
|
|
should be considered.
|
|
</p>
|
|
|
|
<p><i>[
|
|
Resolution proposed by ballot comment:
|
|
]</i></p>
|
|
|
|
<blockquote><p>
|
|
Remove <tt>C++0x</tt> <tt>timed_mutex</tt> and
|
|
<tt>timed_recursive_mutex</tt> if that facilitates
|
|
development of more compatible APIs.
|
|
</p></blockquote>
|
|
|
|
<p><i>[
|
|
2010 Batavia
|
|
]</i></p>
|
|
|
|
<p>
|
|
The concurrency sub-group reviewed the options, and decided that closer harmony should wait until both standards are published.
|
|
</p>
|
|
|
|
<p><b>Rationale:</b></p>
|
|
<p>
|
|
The LWG does not wish to make any change at this time.
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1493"></a>1493. Add <tt>mutex</tt>, <tt>recursive_mutex</tt>, <tt>is_locked</tt> function</h3>
|
|
<p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#thread.mutex.requirements">active issues</a> in [thread.mutex.requirements].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p><b>Addresses US-189</b></p>
|
|
|
|
<p>
|
|
<tt>mutex</tt> and <tt>recursive_mutex</tt> should have an <tt>is_locked()</tt>
|
|
member function. <tt>is_locked</tt> allows a user to test a lock
|
|
without acquiring it and can be used to implement a lightweight
|
|
<tt>try_try_lock</tt>.
|
|
</p>
|
|
|
|
<p><i>[
|
|
Resolution proposed by ballot comment:
|
|
]</i></p>
|
|
|
|
<blockquote><p>
|
|
Add a member function:
|
|
</p>
|
|
<pre>
|
|
bool is_locked() const;
|
|
</pre>
|
|
<p>
|
|
to <tt>std::mutex</tt> and <tt>std::recursive_mutex</tt>. These
|
|
functions return true if the current thread would
|
|
not be able to obtain a mutex. These functions do
|
|
not synchronize with anything (and, thus, can
|
|
avoid a memory fence).
|
|
</p></blockquote>
|
|
|
|
<p><i>[
|
|
2010 Batavia
|
|
]</i></p>
|
|
|
|
<p>
|
|
The Concurrency subgroup reviewed this issue and deemed it to be an extension to be handled after publishing C++0x.
|
|
</p>
|
|
|
|
<p><b>Rationale:</b></p><p>The LWG does not wish to make a change at this time.</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1499"></a>1499. Condition variables preclude wakeup optimization</h3>
|
|
<p><b>Section:</b> 30.5 [thread.condition] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#thread.condition">issues</a> in [thread.condition].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p><b>Addresses US-193</b></p>
|
|
|
|
<p>
|
|
Condition variables preclude a wakeup optimization.
|
|
</p>
|
|
|
|
<p><i>[
|
|
Resolution proposed by ballot comment:
|
|
]</i></p>
|
|
|
|
|
|
<blockquote><p>
|
|
Change condition_variable to allow such
|
|
optimization. See Appendix 1 - Additional Details
|
|
</p></blockquote>
|
|
|
|
<p><i>[
|
|
2010 Batavia
|
|
]</i></p>
|
|
|
|
<p>
|
|
The Concurrency subgroup reviewed the issue, and deemed it an extension to be handled after C++0x.
|
|
</p>
|
|
|
|
<p><b>Rationale:</b></p><p>The LWG does not wish to make the change at this time.</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="1521"></a>1521. Requirements on internal pointer representations in containers</h3>
|
|
<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Mike Spertus <b>Opened:</b> 2010-10-16 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p><b>Addresses US-104, US-141</b></p>
|
|
|
|
<p>
|
|
The standard doesn't say that containers should use abstract pointer
|
|
types internally. Both Howard and Pablo agree that this is the intent.
|
|
Further, it is necessary for containers to be stored, for example, in
|
|
shared memory with an interprocess allocator (the type of scenario that
|
|
allocators are intended to support).
|
|
</p>
|
|
<p>
|
|
In spite of the (possible) agreement on intent, it is necessary to make
|
|
this explicit:
|
|
</p>
|
|
<p>
|
|
An implementations may like to store the result of dereferencing the
|
|
pointer (which is a raw reference) as an optimization, but that prevents
|
|
the data structure from being put in shared memory, etc. In fact, a
|
|
container could store raw references to the allocator, which would be a
|
|
little weird but conforming as long as it has one by-value copy.
|
|
Furthermore, pointers to locales, ctypes, etc. may be there, which also
|
|
prevents the data structure from being put in shared memory, so we
|
|
should make explicit that a container does not store raw pointers or
|
|
references at all.
|
|
</p>
|
|
|
|
<p><i>[
|
|
Pre-batavia
|
|
]</i></p>
|
|
|
|
<p>
|
|
This issue is being opened as part of the response to NB comments US-104/141.
|
|
See paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3171.pdf">N3171</a>
|
|
in the pre-Batavia mailing.
|
|
</p>
|
|
|
|
<p><i>[2011-03-23 Madrid meeting]</i></p>
|
|
|
|
|
|
<p>Deferred</p>
|
|
|
|
<p><i>[
|
|
2011 Batavia
|
|
]</i></p>
|
|
|
|
|
|
<p>
|
|
This may be an issue, but it is not clear. We want to gain a few years experience
|
|
with the C++11 allocator model to see if this is already implied by the existing
|
|
specification.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Add to the end of 23.2.1 [container.requirements.general] p. 8:
|
|
</p>
|
|
<blockquote><p>
|
|
[..] In all container types defined in this Clause, the member <tt>get_allocator()</tt> returns
|
|
a copy of the allocator used to construct the container or, if that allocator has been replaced,
|
|
a copy of the most recent replacement. <ins>The container may not store internal objects whose
|
|
types are of the form <tt>T *</tt> or <tt>T &</tt> except insofar as they are part of the
|
|
item type or members.</ins>
|
|
</p></blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2035"></a>2035. Output iterator requirements are broken</h3>
|
|
<p><b>Section:</b> 24.2.4 [output.iterators] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2011-02-27 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#output.iterators">active issues</a> in [output.iterators].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#output.iterators">issues</a> in [output.iterators].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>During the Pittsburgh meeting the proposal <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html">N3066</a>
|
|
became accepted because it fixed several severe issues related to the iterator specification. But the current working draft (N3225)
|
|
does not reflect all these changes. Since I'm unaware whether every correction can be done editorial, this issue is submitted to take
|
|
care of that. To give one example: All expressions of Table 108 — "Output iterator requirements" have a post-condition
|
|
that the iterator is incrementable. This is impossible, because it would exclude any finite sequence that is accessed by an output
|
|
iterator, such as a pointer to a C array. The N3066 wording changes did not have these effects.
|
|
</p>
|
|
|
|
<p><i>[2011-03-01: Daniel comments:]</i></p>
|
|
|
|
|
|
<p>This issue has some overlap with the issue <a href="lwg-active.html#2038">2038</a> and I would prefer if we
|
|
could solve both at one location. I suggest the following approach:
|
|
</p>
|
|
<ol>
|
|
<li><p>The terms <tt><i>dereferencable</i></tt> and <tt><i>incrementable</i></tt> could be defined in a more
|
|
general way not restricted to iterators (similar to the concepts <tt>HasDereference</tt> and
|
|
<tt>HasPreincrement</tt> from working draft N2914). But on the other hand, all current usages of
|
|
<tt><i>dereferencable</i></tt> and <tt><i>incrementable</i></tt> are involved with types that satisfy
|
|
iterator requirements. Thus, I believe that it is sufficient for C++0x to add corresponding definitions to
|
|
24.2.1 [iterator.requirements.general] and to let all previous usages of these terms refer to this
|
|
sub-clause. Since the same problem occurs with the past-the-end iterator, this proposal suggest providing
|
|
similar references to usages that precede its definition as well.
|
|
</p></li>
|
|
<li><p>We also need to ensure that all iterator expressions get either an operational semantics in
|
|
terms of others or we need to add missing pre- and post-conditions. E.g. we have the following
|
|
ones without semantics:
|
|
</p><blockquote><pre>
|
|
*r++ = o // output iterator
|
|
*r-- // bidirectional iterator
|
|
</pre></blockquote><p>
|
|
According to the <a href="http://www.sgi.com/tech/stl/OutputIterator.html">SGI specification</a>
|
|
these correspond to
|
|
</p><blockquote><pre>
|
|
{ *r = o; ++r; } // output iterator
|
|
{ reference tmp = *r; --r; return tmp; } // bidirectional iterator
|
|
</pre></blockquote><p>
|
|
respectively. Please note especially the latter expression for bidirectional iterator. It fixes a problem
|
|
that we have for forward iterator as well: Both these iterator categories provide stronger guarantees
|
|
than input iterator, because the result of the dereference operation is <tt>reference</tt>, and <strong>not</strong>
|
|
only convertible to the value type (The exact form from the SGI documentation does not correctly refer to
|
|
<tt>reference</tt>).
|
|
</p></li>
|
|
</ol>
|
|
|
|
<p><i>[2011-03-14: Daniel comments and updates the suggested wording]</i></p>
|
|
|
|
|
|
<p>In addition to the before mentioned necessary changes there is another one need, which
|
|
became obvious due to issue <a href="lwg-defects.html#2042">2042</a>: <tt>forward_list<>::before_begin()</tt> returns
|
|
an iterator value which is not dereferencable, but obviously the intention is that it should
|
|
be incrementable. This leads to the conclusion that imposing dereferencable as a requirement
|
|
for the expressions <tt>++r</tt> is wrong: We only need the iterator to be incrementable. A
|
|
similar conclusion applies to the expression <tt>--r</tt> of bidirectional iterators.</p>
|
|
|
|
<p><i>[
|
|
2011 Bloomington
|
|
]</i></p>
|
|
|
|
|
|
<p>
|
|
Consensus this is the correct direction, but there are (potentially) missing <i>incrementable</i>
|
|
preconditions on some table rows, and the Remarks on when an output iterator becomes dereferencable
|
|
are probably better handled outside the table, in a manner similar to the way we word for input
|
|
iterators.
|
|
</p>
|
|
|
|
<p>
|
|
There was some concern about redundant pre-conditions when the operational semantic is defined in
|
|
terms of operations that have preconditions, and a similar level of concern over dropping such
|
|
redundancies vs. applying a consistent level of redundant specification in all the iterator tables.
|
|
Wording clean-up in either direction would be welcome.
|
|
</p>
|
|
|
|
<p><i>[2011-08-18: Daniel adapts the proposed resolution to honor the Bloomington request]</i></p>
|
|
|
|
|
|
<p>
|
|
There is only a small number of further changes suggested to get rid of superfluous
|
|
requirements and essentially non-normative assertions. Operations should not have extra
|
|
pre-conditions, if defined by "in-terms-of" semantics, see e.g. <tt>a != b</tt> or <tt>a->m</tt>
|
|
for Table 107. Further, some remarks, that do not impose anything or say nothing new have been removed,
|
|
because I could not find anything helpful they provide.
|
|
E.g. consider the remarks for Table 108 for the operations dereference-assignment and
|
|
preincrement: They don't provide additional information say nothing surprising. With the
|
|
new pre-conditions <em>and</em> post-conditions it is implied what the remarks intend to say.
|
|
</p>
|
|
|
|
<p><i>[
|
|
2011-11-03: Some observations from Alexander Stepanov via c++std-lib-31405
|
|
]</i></p>
|
|
|
|
|
|
<p>
|
|
The following sentence is dropped from the standard section on OutputIterators:
|
|
<p/>
|
|
"In particular, the following two conditions should hold: first, any
|
|
iterator value should be assigned through before it is incremented
|
|
(this is, for an output iterator <tt>i, i++; i++;</tt> is not a valid code
|
|
sequence); second, any value of an output iterator may have at most
|
|
one active copy at any given time (for example, <tt>i = j; *++i = a; *j = b;</tt>
|
|
is not a valid code sequence)."
|
|
</p>
|
|
|
|
<p><i>[
|
|
2011-11-04: Daniel comments and improves the wording
|
|
]</i></p>
|
|
|
|
|
|
<p>
|
|
In regard to the first part of the comment, the intention of the newly proposed wording
|
|
was to make clear that for the expression
|
|
</p>
|
|
<blockquote><pre>
|
|
*r = o
|
|
</pre></blockquote>
|
|
<p>
|
|
we have the precondition dereferenceable and the post-condition
|
|
incrementable. And for the expression
|
|
</p>
|
|
<blockquote><pre>
|
|
++r
|
|
</pre></blockquote>
|
|
<p>
|
|
we have the precondition incrementable and the post-condition dereferenceable
|
|
or past-the-end. This <em>should not</em> allow for a sequence like <tt>i++; i++;</tt>
|
|
but I agree that it doesn't exactly say that.
|
|
<p/>
|
|
In regard to the second point: To make this point clearer, I suggest to
|
|
add a similar additional wording as we already have for input iterator to the
|
|
"Assertion/note" column of the expression <tt>++r</tt>:
|
|
<p/>
|
|
"Post: any copies of the previous value of <tt>r</tt> are no longer
|
|
required to be dereferenceable or incrementable."
|
|
<p/>
|
|
The proposed has been updated to honor the observations of Alexander Stepanov.
|
|
</p>
|
|
|
|
<p><i>[2015-02 Cologne]</i></p>
|
|
|
|
<p>
|
|
The matter is complicated, Daniel volunteers to write a paper.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<ol>
|
|
<li><p>Add a reference to 24.2.1 [iterator.requirements.general] to the following parts of the
|
|
library preceding Clause 24 Iterators library: (I stopped from 23.2.5 [unord.req] on, because
|
|
the remaining references are the concrete containers)</p>
|
|
<ol>
|
|
<li><p>17.6.3.2 [swappable.requirements] p5:</p>
|
|
|
|
<blockquote><p>
|
|
-5- A type <tt>X</tt> satisfying any of the iterator requirements (24.2) is <tt><i>ValueSwappable</i></tt> if,
|
|
for any dereferenceable <ins>(24.2.1 [iterator.requirements.general])</ins> object <tt>x</tt> of type
|
|
<tt>X</tt>, <tt>*x</tt> is swappable.
|
|
</p></blockquote>
|
|
</li>
|
|
|
|
<li><p>17.6.3.5 [allocator.requirements], Table 27 — "Descriptive variable definitions",
|
|
row with the expression <tt>c</tt>:</p>
|
|
|
|
<blockquote><p>
|
|
a dereferenceable <ins>(24.2.1 [iterator.requirements.general])</ins> pointer of type <tt>C*</tt>
|
|
</p></blockquote>
|
|
|
|
</li>
|
|
|
|
<li><p>20.7.3.2 [pointer.traits.functions]:</p>
|
|
<blockquote><p>
|
|
<i>Returns</i>: The first template function returns a dereferenceable <ins>(24.2.1 [iterator.requirements.general])</ins>
|
|
pointer to <tt>r</tt> obtained by calling <tt>Ptr::pointer_to(r)</tt>; […]
|
|
</p></blockquote>
|
|
</li>
|
|
|
|
<li><p>21.4.3 [string.iterators] p. 2:</p>
|
|
<blockquote><p>
|
|
<i>Returns</i>: An iterator which is the past-the-end value <ins>(24.2.1 [iterator.requirements.general])</ins>.
|
|
</p></blockquote>
|
|
</li>
|
|
|
|
<li><p>22.4.5.1.2 [locale.time.get.virtuals] p. 11:</p>
|
|
<blockquote><pre>
|
|
iter_type do_get(iter_type s, iter_type end, ios_base& f,
|
|
ios_base::iostate& err, tm *t, char format, char modifier) const;
|
|
</pre><blockquote><p>
|
|
<i>Requires</i>: <tt>t</tt> shall be dereferenceable <ins>(24.2.1 [iterator.requirements.general])</ins>.
|
|
</p></blockquote></blockquote>
|
|
</li>
|
|
|
|
<li><p>23.2.1 [container.requirements.general] p. 6:</p>
|
|
|
|
<blockquote><p>
|
|
[…] <tt>end()</tt> returns an iterator which is the past-the-end <ins>(24.2.1 [iterator.requirements.general])</ins>
|
|
value for the container. […]
|
|
</p></blockquote>
|
|
</li>
|
|
|
|
<li><p>23.2.3 [sequence.reqmts] p. 3:</p>
|
|
|
|
<blockquote><p>
|
|
[…] <tt>q</tt> denotes a valid dereferenceable <ins>(24.2.1 [iterator.requirements.general])</ins>
|
|
const iterator to <tt>a</tt>, […]
|
|
</p></blockquote>
|
|
</li>
|
|
|
|
<li><p>23.2.4 [associative.reqmts] p. 8 (I omit intentionally one further reference in the same sub-clause):</p>
|
|
|
|
<blockquote><p>
|
|
[…] <tt>q</tt> denotes a valid dereferenceable <ins>(24.2.1 [iterator.requirements.general])</ins>
|
|
const iterator to <tt>a</tt>, […]
|
|
</p></blockquote>
|
|
</li>
|
|
|
|
<li><p>23.2.5 [unord.req] p. 10 (I omit intentionally one further reference in the same sub-clause):</p>
|
|
|
|
<blockquote><p>
|
|
[…] <tt>q</tt> and <tt>q1</tt> are valid dereferenceable <ins>(24.2.1 [iterator.requirements.general])</ins>
|
|
const iterators to <tt>a</tt>, […]
|
|
</p></blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
</li>
|
|
<li><p>Edit 24.2.1 [iterator.requirements.general] p. 5 as indicated (The intent is to properly define
|
|
<i>incrementable</i> and to ensure some further library guarantee related to past-the-end iterator values):</p>
|
|
|
|
<blockquote><p>
|
|
-5- Just as a regular pointer to an array guarantees that there is a pointer value pointing past the last element
|
|
of the array, so for any iterator type there is an iterator value that points past the last element of a
|
|
corresponding sequence. These values are called <i>past-the-end values</i>. Values of an iterator <tt>i</tt> for which the
|
|
expression <tt>*i</tt> is defined are called <i>dereferenceable</i>. <ins>Values of an iterator <tt>i</tt> for which the
|
|
expression <tt>++i</tt> is defined are called <i>incrementable</i>. </ins> The library never assumes that
|
|
past-the-end values are dereferenceable <ins>or incrementable</ins>. Iterators can also have singular values
|
|
that are not associated with any sequence. […]
|
|
</p></blockquote>
|
|
</li>
|
|
|
|
<li><p>Modify the column contents of Table 106 — "Iterator requirements",
|
|
24.2.2 [iterator.iterators], as indicated:</p>
|
|
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 106 — Iterator requirements</caption>
|
|
|
|
<tr>
|
|
<th>Expression</th>
|
|
<th>Return type</th>
|
|
<th>Operational semantics</th>
|
|
<th>Assertion/note<br/>pre-/post-condition</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>*r</tt></td>
|
|
<td><tt>reference</tt></td>
|
|
<td><tt> </tt></td>
|
|
<td>pre: <tt>r</tt> is dereferenceable.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>++r</tt></td>
|
|
<td><tt>X&</tt></td>
|
|
<td><tt> </tt></td>
|
|
<td><ins>pre: <tt>r</tt> is incrementable.</ins></td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Modify the column contents of Table 107 — "Input iterator requirements",
|
|
24.2.3 [input.iterators], as indicated [<i>Rationale</i>: The wording changes attempt
|
|
to define a minimal "independent" set of operations, namely <tt>*a</tt> and <tt>++r</tt>, and
|
|
to specify the semantics of the remaining ones. This approach seems to be in agreement with the
|
|
original <a href="http://www.sgi.com/tech/stl/InputIterator.html">SGI specification</a>
|
|
— <i>end rationale</i>]:</p>
|
|
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 107 — Input iterator requirements (in addition to Iterator)</caption>
|
|
|
|
<tr>
|
|
<th>Expression</th>
|
|
<th>Return type</th>
|
|
<th>Operational semantics</th>
|
|
<th>Assertion/note<br/>pre-/post-condition</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>a != b</tt></td>
|
|
<td>contextually<br/>
|
|
convertible to <tt>bool</tt></td>
|
|
<td><tt>!(a == b)</tt></td>
|
|
<td><del>pre: <tt>(a, b)</tt> is in the domain<br/>
|
|
of <tt>==</tt>.</del>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>*a</tt></td>
|
|
<td>convertible to <tt>T</tt></td>
|
|
<td><tt> </tt></td>
|
|
<td>pre: <tt>a</tt> is dereferenceable.<br/>
|
|
The expression<br/>
|
|
<tt>(void)*a, *a</tt> is equivalent<br/>
|
|
to <tt>*a</tt>.<br/>
|
|
If <tt>a == b</tt> and <tt>(a,b)</tt> is in<br/>
|
|
the domain of <tt>==</tt> then <tt>*a</tt> is<br/>
|
|
equivalent to <tt>*b</tt>.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>a->m</tt></td>
|
|
<td><tt> </tt></td>
|
|
<td><tt>(*a).m</tt></td>
|
|
<td><del>pre: <tt>a</tt> is dereferenceable.</del></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>++r</tt></td>
|
|
<td><tt>X&</tt></td>
|
|
<td><tt> </tt></td>
|
|
<td>pre: <tt>r</tt> is <del>dereferenceable</del><ins>incrementable</ins>.<br/>
|
|
post: <tt>r</tt> is dereferenceable or<br/>
|
|
<tt>r</tt> is past-the-end.<br/>
|
|
post: any copies of the<br/>
|
|
previous value of <tt>r</tt> are no<br/>
|
|
longer required either to be<br/>
|
|
dereferenceable<ins>, incrementable,</ins><br/>
|
|
or to be in the domain of <tt>==</tt>.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>(void)r++</tt></td>
|
|
<td><tt> </tt></td>
|
|
<td><ins><tt>(void)++r</tt></ins></td>
|
|
<td><del>equivalent to <tt>(void)++r</tt></del></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>*r++</tt></td>
|
|
<td>convertible to <tt>T</tt></td>
|
|
<td><tt>{ T tmp = *r;<br/>
|
|
++r;<br/>
|
|
return tmp; }
|
|
</tt></td>
|
|
<td><tt> </tt></td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Modify the column contents of Table 108 — "Output iterator requirements",
|
|
24.2.4 [output.iterators], as indicated [<i>Rationale</i>: The wording changes attempt
|
|
to define a minimal "independent" set of operations, namely <tt>*r = o</tt> and <tt>++r</tt>,
|
|
and to specify the semantics of the remaining ones. This approach seems to be in agreement with
|
|
the original <a href="http://www.sgi.com/tech/stl/OutputIterator.html">SGI specification</a>
|
|
— <i>end rationale</i>]:</p>
|
|
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 108 — Output iterator requirements (in addition to Iterator)</caption>
|
|
|
|
<tr>
|
|
<th>Expression</th>
|
|
<th>Return type</th>
|
|
<th>Operational semantics</th>
|
|
<th>Assertion/note<br/>pre-/post-condition</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>*r = o</tt></td>
|
|
<td>result is not used</td>
|
|
<td><tt> </tt></td>
|
|
<td><ins>pre: <tt>r</tt> is dereferenceable.</ins><br/>
|
|
<i>Remark</i>: After this operation<br/>
|
|
<tt>r</tt> is not required to be<br/>
|
|
dereferenceable <ins>and any copies of<br/>
|
|
the previous value of <tt>r</tt> are no<br/>
|
|
longer required to be dereferenceable<br/>
|
|
or incrementable.</ins><br/>
|
|
post: <tt>r</tt> is incrementable.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>++r</tt></td>
|
|
<td><tt>X&</tt></td>
|
|
<td><tt> </tt></td>
|
|
<td><ins>pre: <tt>r</tt> is incrementable.</ins><br/>
|
|
<tt>&r == &++r</tt>.<br/>
|
|
<del><i>Remark</i>: After this operation<br/>
|
|
<tt>r</tt> is not required to be<br/>
|
|
dereferenceable.<br/></del>
|
|
<ins><i>Remark</i>: After this operation<br/>
|
|
<tt>r</tt> is not required to be<br/>
|
|
incrementable and any copies of<br/>
|
|
the previous value of <tt>r</tt> are no<br/>
|
|
longer required to be dereferenceable<br/>
|
|
or incrementable.</ins><br/>
|
|
post: <tt>r</tt> is <ins>dereferenceable<br/>
|
|
or <tt>r</tt> is past-the-end</ins><del>incrementable</del>.<br/>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>r++</tt></td>
|
|
<td>convertible to <tt>const X&</tt></td>
|
|
<td><tt>{ X tmp = r;<br/>
|
|
++r;<br/>
|
|
return tmp; }</tt>
|
|
</td>
|
|
<td><del><i>Remark</i>: After this operation<br/>
|
|
<tt>r</tt> is not required to be<br/>
|
|
dereferenceable.<br/>
|
|
post: <tt>r</tt> is incrementable.</del>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>*r++ = o</tt></td>
|
|
<td>result is not used</td>
|
|
<td><ins><tt>{ *r = o; ++r; }</tt></ins></td>
|
|
<td><del><i>Remark</i>: After this operation<br/>
|
|
<tt>r</tt> is not required to be<br/>
|
|
dereferenceable.<br/>
|
|
post: <tt>r</tt> is incrementable.</del>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Modify the column contents of Table 109 — "Forward iterator requirements",
|
|
24.2.5 [forward.iterators], as indicated [<i>Rationale</i>: Since the return type of the
|
|
expression <tt>*r++</tt> is now guaranteed to be type <tt>reference</tt>, the implied operational
|
|
semantics from input iterator based on value copies is wrong — <i>end rationale</i>]</p>
|
|
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 109 — Forward iterator requirements (in addition to input iterator)</caption>
|
|
|
|
<tr>
|
|
<th>Expression</th>
|
|
<th>Return type</th>
|
|
<th>Operational semantics</th>
|
|
<th>Assertion/note<br/>pre-/post-condition</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>r++</tt></td>
|
|
<td>convertible to <tt>const X&</tt></td>
|
|
<td><tt>{ X tmp = r;<br/>
|
|
++r;<br/>
|
|
return tmp; }</tt>
|
|
</td>
|
|
<td><tt> </tt></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>*r++</tt></td>
|
|
<td>reference</td>
|
|
<td><ins><tt>{ reference tmp = *r;<br/>
|
|
++r;<br/>
|
|
return tmp; }</tt></ins></td>
|
|
<td><tt> </tt></td>
|
|
</tr>
|
|
</table>
|
|
</blockquote>
|
|
|
|
</li>
|
|
|
|
<li><p>Modify the column contents of Table 110 — "Bidirectional iterator requirements",
|
|
24.2.6 [bidirectional.iterators], as indicated:</p>
|
|
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 110 — Bidirectional iterator requirements (in addition to forward iterator)</caption>
|
|
|
|
<tr>
|
|
<th>Expression</th>
|
|
<th>Return type</th>
|
|
<th>Operational semantics</th>
|
|
<th>Assertion/note<br/>pre-/post-condition</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>--r</tt></td>
|
|
<td><tt>X&</tt></td>
|
|
<td><tt> </tt></td>
|
|
<td>pre: there exists <tt>s</tt> such that<br/>
|
|
<tt>r == ++s</tt>.<br/>
|
|
post: <tt>r</tt> is <del>dereferenceable</del><ins>incrementable</ins>.<br/>
|
|
<tt>--(++r) == r</tt>.<br/>
|
|
<tt>--r == --s</tt> implies <tt>r == s</tt>.<br/>
|
|
<tt>&r == &--r</tt>.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>r--</tt></td>
|
|
<td>convertible to <tt>const X&</tt></td>
|
|
<td><tt>{ X tmp = r;<br/>
|
|
--r;<br/>
|
|
return tmp; }</tt>
|
|
</td>
|
|
<td><tt> </tt></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>*r--</tt></td>
|
|
<td>reference</td>
|
|
<td><ins><tt>{ reference tmp = *r;<br/>
|
|
--r;<br/>
|
|
return tmp; }</tt></ins></td>
|
|
<td><tt> </tt></td>
|
|
</tr>
|
|
</table>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2038"></a>2038. Missing definition for <tt>incrementable</tt> iterator</h3>
|
|
<p><b>Section:</b> 24.2.4 [output.iterators] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Pete Becker <b>Opened:</b> 2011-02-27 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#output.iterators">active issues</a> in [output.iterators].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#output.iterators">issues</a> in [output.iterators].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>In comp.lang.c++, Vicente Botet raises the following questions:</p>
|
|
|
|
<blockquote><p>
|
|
"In "24.2.4 Output iterators" there are 3 uses of incrementable. I've
|
|
not found the definition. Could some one point me where it is defined?
|
|
<p/>
|
|
Something similar occurs with dereferenceable. While the definition is
|
|
given in "24.2.1 In general" it is used several times before.
|
|
<p/>
|
|
Shouldn't these definitions be moved to some previous section?"
|
|
</p></blockquote>
|
|
|
|
<p>He's right: both terms are used without being properly defined.
|
|
<p/>
|
|
There is no definition of "incrementable".
|
|
<p/>
|
|
While there is a definition of "dereferenceable", it is, in fact, a definition of
|
|
"dereferenceable iterator". "dereferenceable" is used throughout Clause 23 (Containers)
|
|
before its definition in Clause 24. In almost all cases it's referring to iterators,
|
|
but in 17.6.3.2 [swappable.requirements] there is a mention of "dereferenceable object"; in
|
|
17.6.3.5 [allocator.requirements] the table of Descriptive variable definitions refers to a
|
|
"dereferenceable pointer"; 20.7.3.2 [pointer.traits.functions] refers to a
|
|
"dereferenceable pointer"; in 22.4.5.1.2 [locale.time.get.virtuals]/11 (<tt>do_get</tt>)
|
|
there is a requirement that a pointer "shall be dereferenceable". In those specific cases
|
|
it is not defined.
|
|
</p>
|
|
|
|
<p><i>[2011-03-02: Daniel comments:]</i></p>
|
|
|
|
|
|
<p>I believe that the currently proposed resolution of issue <a href="lwg-active.html#2035">2035</a> solves this
|
|
issue as well.</p>
|
|
|
|
<p><i>[
|
|
2011 Bloomington
|
|
]</i></p>
|
|
|
|
|
|
<p>
|
|
Agree with Daniel, this will be handled by the resolution of <a href="lwg-active.html#2035">2035</a>.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2040"></a>2040. Missing type traits related to <tt>is_convertible</tt></h3>
|
|
<p><b>Section:</b> 20.10 [meta] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2011-03-03 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#meta">active issues</a> in [meta].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#meta">issues</a> in [meta].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>When <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html">n3142</a>
|
|
was suggested, it concentrated on constructions, assignments, and destructions, but overlooked
|
|
to complement the single remaining compiler-support trait</p>
|
|
|
|
<blockquote><pre>
|
|
template <class From, class To> struct is_convertible;
|
|
</pre></blockquote>
|
|
|
|
<p>with the no-throw and triviality related aspects as it had been done with the other
|
|
expression-based traits. Specifically, the current specification misses to add the
|
|
following traits:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
template <class From, class To> struct is_nothrow_convertible;
|
|
template <class From, class To> struct is_trivially_convertible;
|
|
</pre></blockquote>
|
|
|
|
<p>In particular the lack of <tt>is_nothrow_convertible</tt> is severly restricting. This
|
|
was recently recognized when the proposal for <tt>decay_copy</tt> was prepared by
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3255.html">n3255</a>.
|
|
There does not exist a portable means to define the correct conditional <tt>noexcept</tt>
|
|
specification for the <tt>decay_copy</tt> function template, which is declared as:</p>
|
|
|
|
<blockquote><pre>
|
|
template <class T>
|
|
typename decay<T>::type decay_copy(T&& v) noexcept(<i>???</i>);
|
|
</pre></blockquote>
|
|
|
|
<p>The semantics of <tt>decay_copy</tt> bases on an implicit conversion which again
|
|
influences the overload set of functions that are viable here. In most circumstances
|
|
this will have the same effect as comparing against the trait
|
|
<tt>std::is_nothrow_move_constructible</tt>, but there is no guarantee for that being
|
|
the right answer. It is possible to construct examples, where this would lead
|
|
to the false result, e.g.</p>
|
|
|
|
<blockquote><pre>
|
|
struct S {
|
|
S(const S&) noexcept(false);
|
|
|
|
template<class T>
|
|
explicit S(T&&) noexcept(true);
|
|
};
|
|
</pre></blockquote>
|
|
|
|
<p><tt>std::is_nothrow_move_constructible</tt> will properly honor the explicit template
|
|
constructor because of the direct-initialization context which is part of the
|
|
<tt>std::is_constructible</tt> definition and will in this case select it, such that
|
|
<tt>std::is_nothrow_move_constructible<S>::value == true</tt>, but if we had
|
|
the traits <tt>is_nothrow_convertible</tt>, <tt>is_nothrow_convertible<S, S>::value</tt>
|
|
would evaluate to <tt>false</tt>, because it would use the copy-initialization context
|
|
that is part of the <tt>is_convertible</tt> definition, excluding any explicit
|
|
constructors and giving the opposite result.</p>
|
|
|
|
<p>The <tt>decay_copy</tt> example is surely not one of the most convincing examples, but
|
|
<tt>is_nothrow_convertible</tt> has several use-cases, and can e.g. be used to express
|
|
whether calling the following implicit conversion function could throw an exception or not:</p>
|
|
|
|
<blockquote><pre>
|
|
template<class T, class U>
|
|
T implicit_cast(U&& u) noexcept(is_nothrow_convertible<U, T>::value)
|
|
{
|
|
return std::forward<U>(u);
|
|
}
|
|
</pre></blockquote>
|
|
|
|
<p>Therefore I suggest to add the missing trait <tt>is_nothrow_convertible</tt> and for
|
|
completeness also the missing trait <tt>is_trivially_convertible</tt> to 20.10 [meta].</p>
|
|
|
|
<p><i>[2011-03-24 Madrid meeting]</i></p>
|
|
|
|
|
|
<p>
|
|
Daniel K: This is a new feature so out of scope.
|
|
<p/>
|
|
Pablo: Any objections to moving 2040 to Open?
|
|
<p/>
|
|
No objections.
|
|
</p>
|
|
|
|
<p><i>[Bloomington, 2011]</i></p>
|
|
|
|
<p>
|
|
Move to NAD Future, this would be an extension to existing functionality.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<ol>
|
|
<li><p>Ammend the following declarations to the header <tt><type_traits></tt> synopsis
|
|
in 20.10.2 [meta.type.synop]:</p>
|
|
|
|
<blockquote><pre>
|
|
namespace std {
|
|
…
|
|
// 20.9.6, type relations:
|
|
template <class T, class U> struct is_same;
|
|
template <class Base, class Derived> struct is_base_of;
|
|
template <class From, class To> struct is_convertible;
|
|
<ins>template <class From, class To> struct is_trivially_convertible;</ins>
|
|
<ins>template <class From, class To> struct is_nothrow_convertible;</ins>
|
|
|
|
…
|
|
}
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li><p>Modify Table 51 — "Type relationship predicates" as indicated. The removal of the
|
|
remaining traces of the trait <tt>is_explicitly_convertible</tt> is an editorial
|
|
step, it was removed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3047.html">n3047</a>:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 51 — Type relationship predicates</caption>
|
|
|
|
<tr>
|
|
<th>Template</th>
|
|
<th>Condition</th>
|
|
<th>Comments</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="3" style="text-align:center;">…</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>template <class From, class To><br/>
|
|
struct is_convertible;</tt></td>
|
|
<td><i>see below</i></td>
|
|
<td><tt>From</tt> and <tt>To</tt> shall be complete<br/>
|
|
types, arrays of unknown bound, or<br/>
|
|
(possibly cv-qualified) <tt>void</tt><br/>
|
|
types.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><del><tt>template <class From, class To><br/>
|
|
struct is_explicitly_convertible;</tt></del></td>
|
|
<td><del><tt>is_constructible<To, From>::value</tt></del></td>
|
|
<td><del>a synonym for a two-argument<br/>
|
|
version of <tt>is_constructible</tt>.<br/>
|
|
An implementation may define it<br/>
|
|
as an alias template.</del></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><ins><tt>template <class From, class To><br/>
|
|
struct is_trivially_convertible;</tt></ins></td>
|
|
<td><ins><tt>is_convertible<From,<br/>
|
|
To>::value</tt> is <tt>true</tt> and the<br/>
|
|
conversion, as defined by<br/>
|
|
<tt>is_convertible</tt>, is known<br/>
|
|
to call no operation that is<br/>
|
|
not trivial ([basic.types], [special]).</ins></td>
|
|
<td><ins><tt>From</tt> and <tt>To</tt> shall be complete<br/>
|
|
types, arrays of unknown bound,<br/>
|
|
or (possibly cv-qualified) <tt>void</tt><br/>
|
|
types.</ins></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><ins><tt>template <class From, class To><br/>
|
|
struct is_nothrow_convertible;</tt></ins></td>
|
|
<td><ins><tt>is_convertible<From,<br/>
|
|
To>::value</tt> is <tt>true</tt> and the<br/>
|
|
conversion, as defined by<br/>
|
|
<tt>is_convertible</tt>, is known<br/>
|
|
not to throw any<br/>
|
|
exceptions ([expr.unary.noexcept]).</ins></td>
|
|
<td><ins><tt>From</tt> and <tt>To</tt> shall be complete<br/>
|
|
types, arrays of unknown bound,<br/>
|
|
or (possibly cv-qualified) <tt>void</tt><br/>
|
|
types.</ins></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="3" style="text-align:center;">…</td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote>
|
|
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2051"></a>2051. Explicit <tt>tuple</tt> constructors for more than one parameter</h3>
|
|
<p><b>Section:</b> 20.4.2 [tuple.tuple], 20.4.2.1 [tuple.cnstr] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Ville Voutilainen <b>Opened:</b> 2011-05-01 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#tuple.tuple">issues</a> in [tuple.tuple].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
One of my constituents wrote the following:
|
|
<p/>
|
|
-------snip------------
|
|
<p/>
|
|
So far the only use I've found for <tt>std::tuple</tt> is as an ad-hoc type to emulate
|
|
multiple return values. If the tuple ctor was made non-explicit one could
|
|
almost think C++ supported multiple return values especially when combined
|
|
with <tt>std::tie()</tt>.
|
|
</p>
|
|
<blockquote><pre>
|
|
// assume types line_segment and point
|
|
// assume function double distance(point const&, point const&)
|
|
|
|
std::tuple<point, point>
|
|
closest_points(line_segment const& a, line_segment const& b) {
|
|
point ax;
|
|
point bx;
|
|
/* some math */
|
|
|
|
return {ax, bx};
|
|
}
|
|
|
|
|
|
double
|
|
distance(line_segment const& a, line_segment const& b) {
|
|
point ax;
|
|
point bx;
|
|
std::tie(ax, bx) = closest_points(a, b);
|
|
|
|
return distance(ax, bx);
|
|
}
|
|
</pre></blockquote>
|
|
<p>
|
|
-------snap----------
|
|
<p/>
|
|
See also the messages starting from lib-29330.
|
|
<p/>
|
|
Some notes:
|
|
</p>
|
|
<ol>
|
|
<li><tt>pair</tt> allows such a return</li>
|
|
<li>a lambda with a deduced return type doesn't allow it for any type</li>
|
|
<li><tt>decltype</tt> refuses <tt>{1, 2}</tt></li>
|
|
</ol>
|
|
<p>
|
|
I would recommend making non-unary <tt>tuple</tt> constructors non-explicit.
|
|
</p>
|
|
|
|
<p><i>[Bloomington, 2011]</i></p>
|
|
|
|
<p>
|
|
Move to NAD Future, this would be an extension to existing functionality.
|
|
</p>
|
|
|
|
<p><i>[Portland, 2012]</i></p>
|
|
|
|
<p>
|
|
Move to Open at the request of the Evolution Working Group.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2055"></a>2055. <tt>std::move</tt> in <tt>std::accumulate</tt> and other algorithms</h3>
|
|
<p><b>Section:</b> 26.7 [numeric.ops] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2011-01-01 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#numeric.ops">issues</a> in [numeric.ops].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The C++0x draft says <tt>std::accumulate</tt> uses: <tt>acc = binary_op(acc, *i)</tt>.
|
|
<p/>
|
|
Eelis van der Weegen has pointed out, on the libstdc++ mailing list, that using
|
|
<tt>acc = binary_op(std::move(acc), *i)</tt> can lead to massive improvements (particularly,
|
|
it means accumulating strings is linear rather than quadratic).
|
|
<p/>
|
|
Consider the simple case, accumulating a bunch of strings of length 1 (the same argument holds for other length buffers).
|
|
For strings <tt>s</tt> and <tt>t</tt>, <tt>s+t</tt> takes time <tt>length(s)+length(t)</tt>, as you have to copy
|
|
both <tt>s</tt> and <tt>t</tt> into a new buffer.
|
|
<p/>
|
|
So in accumulating <tt>n</tt> strings, step <tt>i</tt> adds a string of length <tt>i-1</tt> to a string of length
|
|
1, so takes time <tt>i</tt>.
|
|
<p/>
|
|
Therefore the total time taken is: <tt>1+2+3+...+n</tt> = O(<tt>n<sup>2</sup></tt>)
|
|
<p/>
|
|
<tt>std::move(s)+t</tt>, for a "good" implementation, is amortized time <tt>length(t)</tt>, like <tt>vector</tt>,
|
|
just copy <tt>t</tt> onto the end of the buffer. So the total time taken is:
|
|
<p/>
|
|
<tt>1+1+1+...+1</tt> (<tt>n</tt> times) = O(<tt>n</tt>). This is the same as <tt>push_back</tt> on a <tt>vector</tt>.
|
|
<p/>
|
|
I'm trying to decide if this implementation might already be allowed. I suspect it might not
|
|
be (although I can't imagine any sensible code it would break). There are other algorithms
|
|
which could benefit similarly (<tt>inner_product</tt>, <tt>partial_sum</tt> and
|
|
<tt>adjacent_difference</tt> are the most obvious).
|
|
<p/>
|
|
Is there any general wording for "you can use rvalues of temporaries"?
|
|
<p/>
|
|
The reflector discussion starting with message c++std-lib-29763 came to the conclusion
|
|
that above example is not covered by the "as-if" rules and that enabling this behaviour
|
|
would seem quite useful.
|
|
</p>
|
|
|
|
<p><i>[
|
|
2011 Bloomington
|
|
]</i></p>
|
|
|
|
|
|
<p>
|
|
Moved to NAD Future. This would be a larger change than we would consider for a simple TC.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2062"></a>2062. Effect contradictions w/o no-throw guarantee of <tt>std::function</tt> swaps</h3>
|
|
<p><b>Section:</b> 20.9.12.2 [func.wrap.func], 20.9.12.2.2 [func.wrap.func.mod] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2011-05-28 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Howard Hinnant observed in reflector message c++std-lib-30841 that 20.9.12.2 [func.wrap.func]
|
|
makes the member swap <tt>noexcept</tt>, even though the non-member swap is not <tt>noexcept</tt>.
|
|
<p/>
|
|
The latter was an outcome of the discussions during the Batavia meeting and the Madrid meeting
|
|
involving LWG <a href="lwg-defects.html#1349">1349</a>, which seems to indicate that the remaining <tt>noexcept</tt>
|
|
specifier at the member swap is incorrect and should be removed.
|
|
<p/>
|
|
But if we allow for a potentially throwing member swap of <tt>std::function</tt>, this causes
|
|
another conflict with the exception specification for the following member function:
|
|
</p>
|
|
<blockquote><pre>
|
|
template<class F> function& operator=(reference_wrapper<F> f) <span style="color:#C80000;font-weight:bolder">noexcept</span>;
|
|
</pre><blockquote><p>
|
|
<i>Effects</i>: <tt>function(f).<span style="color:#C80000;font-weight:bolder">swap</span>(*this);</tt>
|
|
</p>
|
|
</blockquote></blockquote>
|
|
<p>
|
|
Note that in this example the sub-expression <tt>function(f)</tt> does not cause any problems,
|
|
because of the nothrow-guarantee given in 20.9.12.2.1 [func.wrap.func.con] p. 10. The problem
|
|
is located in the usage of the swap which could potentially throw given the general latitude.
|
|
<p/>
|
|
So, either the Madrid meeting decision need to be revised (and both member and free swap of
|
|
<tt>std::function</tt> should be noexcept), or this function needs to be adapted as well,
|
|
e.g. by taking the exception-specification away or by changing the semantics.
|
|
<p/>
|
|
One argument for "swap-may-throw" would be to allow for small-object optimization techniques
|
|
where the copy of the target may throw. But given the fact that the swap function has been guaranteed
|
|
to be "Throws: Nothing" from TR1 on, it seems to me that that there would still be opportunities to
|
|
perform small-object optimizations just restricted to the set of target copies that cannot throw.
|
|
<p/>
|
|
In my opinion member swap of <tt>std::function</tt> has always been intended to be no-throw, because
|
|
otherwise there would be no good technical reason to specify the effects of several member
|
|
functions in terms of the "construct-swap" idiom (There are three functions that are defined
|
|
this way), which provides the strong exception safety in this case. I suggest to enforce that both
|
|
member swap and non-member swap of <tt>std::function</tt> are nothrow functions as it had been guaranteed
|
|
since TR1 on.
|
|
</p>
|
|
|
|
<p><i>[
|
|
2011 Bloomington
|
|
]</i></p>
|
|
|
|
<p>
|
|
Dietmar: May not be swappable in the first place.
|
|
</p>
|
|
<p>
|
|
Alisdair: This is wide contact. Then we should be taking noexcept off instead of putting it on. This is preferred resolution.
|
|
</p>
|
|
<p>
|
|
Pablo: This is bigger issue. Specification of assignment in terms of swap is suspect to begin with. It is over specification.
|
|
How this was applied to string is a better example to work from.
|
|
</p>
|
|
<p>
|
|
Pablo: Two problems: inconsistency that should be fixed (neither should have noexcept), the other issues is that assignment
|
|
should not be specified in terms of swap. There are cases where assignment should succeed where swap would fail. This is easier
|
|
with string as it should follow container rules.
|
|
</p>
|
|
<p>
|
|
<b>Action Item</b> (Alisdair): There are a few more issues found to file.
|
|
</p>
|
|
<p>
|
|
Dave: This is because of allocators? The allocator makes this not work.
|
|
</p>
|
|
<p>
|
|
Howard: There is a type erased allocator in shared_ptr. There is a noexcept allocator in shared_ptr.
|
|
</p>
|
|
<p>
|
|
Pablo: shared_ptr is a different case. There are shared semantics and the allocator does move around.
|
|
A function does not have shared semantics.
|
|
</p>
|
|
<p>
|
|
Alisdair: Function objects think they have unique ownership.
|
|
</p>
|
|
<p>
|
|
Howard: In function we specify semantics with copy construction and swap.
|
|
</p>
|
|
<p>
|
|
<b>Action Item</b> (Pablo): Write this up better (why assignment should not be defined in terms of swap)
|
|
</p>
|
|
<p>
|
|
Howard: Not having trouble making function constructor no throw.
|
|
</p>
|
|
<p>
|
|
Dietmar: Function must allocate memory.
|
|
</p>
|
|
<p>
|
|
Howard: Does not put stuff that will throw on copy or swap in small object optimization. Put those on heap.
|
|
Storing allocator, but has to be no throw copy constructable.
|
|
</p>
|
|
<p>
|
|
Pablo: Are you allowed to or required to swap or move allocators in case or swap or move.
|
|
</p>
|
|
<p>
|
|
Dave: An allocator that is type erased should be different...
|
|
</p>
|
|
<p>
|
|
Pablo: it is
|
|
</p>
|
|
<p>
|
|
Dave: Do you need to know something about allocator types? But only at construction time.
|
|
</p>
|
|
<p>
|
|
Pablo: You could have allocators that are different types.
|
|
</p>
|
|
<p>
|
|
Dave: Swap is two ended operation.
|
|
</p>
|
|
<p>
|
|
Pablo: Opinion is that both have to say propagate on swap for them to swap.
|
|
</p>
|
|
<p>
|
|
John: It is not arbitrary. If one person says no. No is no.
|
|
</p>
|
|
<p>
|
|
Howard: Find noexcept swap to be very useful. Would like to move in that direction and bring container design along.
|
|
</p>
|
|
<p>
|
|
Dave: If you have something were allocator must not propagate you can detect that at construction time.
|
|
</p>
|
|
<p>
|
|
...
|
|
</p>
|
|
<p>
|
|
Pablo: Need to leave this open and discuss in smaller group.
|
|
</p>
|
|
<p>
|
|
Alisdair: Tried to add boost::any as TR2 proposal and ran into this issue. Only the first place where we run into
|
|
issues with type erased allocators. Suggest we move it to open.
|
|
</p>
|
|
<p>
|
|
<b>Action Item</b>: Move to open.
|
|
</p>
|
|
<p>
|
|
<b>Action Item</b> (Pablo works with Howard and Daniel): Address the more fundamental issue
|
|
(which may be multiple issues) and write up findings.
|
|
</p>
|
|
|
|
<p><i>[
|
|
<b>Original resolution</b>:
|
|
]</i></p>
|
|
|
|
<p>This wording is relative to the FDIS.</p>
|
|
<ol>
|
|
<li><p>Modify the header <tt><functional></tt> synopsis in 20.9 [function.objects] as indicated:</p>
|
|
<blockquote><pre>
|
|
namespace std {
|
|
[…]
|
|
|
|
template<class R, class... ArgTypes>
|
|
void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&) <ins>noexcept</ins>;
|
|
|
|
[…]
|
|
}
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li><p>Modify the class template <tt>function</tt> synopsis in 20.9.12.2 [func.wrap.func] as indicated:</p>
|
|
<blockquote><pre>
|
|
namespace std {
|
|
[…]
|
|
|
|
<i>// [func.wrap.func.alg], specialized algorithms:</i>
|
|
template<class R, class... ArgTypes>
|
|
void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&) <ins>noexcept</ins>;
|
|
|
|
[…]
|
|
}
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li><p>Modify 20.9.12.2.7 [func.wrap.func.alg] as indicated:</p>
|
|
<blockquote><pre>
|
|
template<class R, class... ArgTypes>
|
|
void swap(function<R(ArgTypes...)>& f1, function<R(ArgTypes...)>& f2) <ins>noexcept</ins>;
|
|
</pre><blockquote><p>
|
|
-1- <i>Effects</i>: <tt>f1.swap(f2);</tt>
|
|
</p></blockquote></blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
<p><i>[2014-02-28 (Post Issaquah), Pablo provides more information]</i></p>
|
|
|
|
|
|
<p>
|
|
For cross-referencing purposes: The resolution of this issue should be
|
|
harmonized with any resolution to LWG <a href="lwg-active.html#2370">2370</a>, which addresses
|
|
inappropriate <tt>noexcept</tt>s in some function constructors.
|
|
</p>
|
|
|
|
<p>We have the following choices:</p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p><tt>swap()</tt> does not throw</p>
|
|
|
|
<blockquote><p>
|
|
<i>Discussion</i>: This definition is desirable, and allows assignment
|
|
to be implemented with the strong exception guarantee, but it does have
|
|
consequences: The implementation cannot use the small-object optimization
|
|
for a function-object <tt>F</tt> unless <tt>F</tt> is <tt>NothrowMovable</tt>
|
|
(nothrow-swappable is unimportant because <tt>F</tt> is not swapped with another <tt>F</tt>).
|
|
Note that many functors written before C++11 will not have move constructors decorated
|
|
with <tt>noexcept</tt>, so this limitation could affect a lot of code.
|
|
</p>
|
|
<p>
|
|
It is not clear what other implementation restrictions might be
|
|
needed. Allocators are required not to throw on move or copy. Is that
|
|
sufficient?
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li>
|
|
<p><tt>swap()</tt> can throw</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<i>Discussion</i>: This definition gives maximum latitude to implementation to
|
|
use small-object optimization. However, the strong guarantee on assignment
|
|
is difficult to achieve. Should we consider giving up on the strong
|
|
guarantee? How much are we willing to pessimize code for exceptions?
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
<li>
|
|
<p><tt>swap()</tt> will not throw if both functions have <tt>NoThrowMoveable</tt> functors</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<i>Discussion</i>: This definition is similar to option 2, but gives slightly
|
|
stronger guarantees. Here, <tt>swap()</tt> can throw, but the programmer can
|
|
theoretically prevent that from happening. This should be straight-forward
|
|
to implement and gives the implementation a lot of latitude for
|
|
optimization. However, because this is a dynamic decision, the program is
|
|
not as easy to reason about. Also, the strong guarantee for assignment is
|
|
compromized as in option 2.
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2070"></a>2070. <tt>allocate_shared</tt> should use <tt>allocator_traits<A>::construct</tt></h3>
|
|
<p><b>Section:</b> 20.8.2.2.6 [util.smartptr.shared.create] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2011-07-11 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
20.8.2.2.6 [util.smartptr.shared.create] says:
|
|
</p>
|
|
<blockquote><p>
|
|
-2- <i>Effects</i>: Allocates memory suitable for an object of type <tt>T</tt> and constructs an object in that memory
|
|
via the placement new expression <tt>::new (pv) T(std::forward<Args>(args)...)</tt>. The template
|
|
<tt>allocate_shared</tt> uses a copy of a to allocate memory. If an exception is thrown, the functions have
|
|
no effect.
|
|
</p></blockquote>
|
|
<p>
|
|
This explicitly requires placement new rather than using
|
|
<tt>allocator_traits<A>::construct(a, (T*)pv, std::forward<Args>(args)...)</tt>
|
|
In most cases that would result in the same placement new expression,
|
|
but would allow more control over how the object is constructed e.g.
|
|
using <tt>scoped_allocator_adaptor</tt> to do uses-allocator construction, or
|
|
using an allocator declared as a friend to construct objects with no
|
|
public constructors.
|
|
</p>
|
|
|
|
<p><i>[
|
|
2011-08-16 Bloomington:
|
|
]</i></p>
|
|
|
|
<p>
|
|
Agreed to fix in principle, but believe that <tt>make_shared</tt> and
|
|
<tt>allocate_shared</tt> have now diverged enough that their descriptions
|
|
should be separated. Pablo and Stefanus to provide revised wording.
|
|
</p>
|
|
|
|
<p><strong>Daniel's (old) proposed resolution:</strong></p>
|
|
<blockquote class="note">
|
|
<p>This wording is relative to the FDIS.</p>
|
|
|
|
<ol>
|
|
<li><p>Change the following paragraphs of 20.8.2.2.6 [util.smartptr.shared.create] as indicated (The suggested
|
|
removal of the last sentence of p1 is not strictly required to resolve this issue, but is still recommended,
|
|
because it does not say anything new but may give the impression that it says something new):
|
|
</p><blockquote><pre>
|
|
template<class T, class... Args> shared_ptr<T> make_shared(Args&&... args);
|
|
template<class T, class A, class... Args>
|
|
shared_ptr<T> allocate_shared(const A& a, Args&&... args);
|
|
</pre><blockquote>
|
|
<p>
|
|
-1- <i>Requires</i>: <ins>For the template <tt>make_shared</tt>, t</ins><del>T</del>he expression
|
|
<tt>::new (pv) T(std::forward<Args>(args)...)</tt>, where <tt>pv</tt>
|
|
has type <tt>void*</tt> and points to storage suitable to hold an object of type <tt>T</tt>, shall be well
|
|
formed. <ins>For the template <tt>allocate_shared</tt>, the expression
|
|
<tt>allocator_traits<A>::construct(a, pt, std::forward<Args>(args)...)</tt>,
|
|
where <tt>pt</tt> has type <tt>T*</tt> and points to storage suitable to hold an object
|
|
of type <tt>T</tt>, shall be well formed.</ins> <tt>A</tt> shall be an allocator ([allocator.requirements]).
|
|
<del>The copy constructor and destructor of <tt>A</tt> shall not throw exceptions.</del>
|
|
<p/>
|
|
-2- <i>Effects</i>: Allocates memory suitable for an object of type <tt>T</tt> and constructs an object in
|
|
that memory<ins>. The template <tt>make_shared</tt> constructs the object</ins> via the placement new expression
|
|
<tt>::new (pv) T(std::forward<Args>(args)...)</tt>. The template <tt>allocate_shared</tt> uses a copy
|
|
of <tt>a</tt> to allocate memory<ins> and constructs the object by calling <tt>allocator_traits<A>::construct(a, pt,
|
|
std::forward<Args>(args)...)</tt></ins>. If an exception is thrown, the functions have no effect.
|
|
<p/>
|
|
-3- <i>Returns</i>: A <tt>shared_ptr</tt> instance that stores and owns the address of the newly constructed
|
|
object of type <tt>T</tt>.
|
|
<p/>
|
|
-4- <i>Postconditions</i>: <tt>get() != 0 && use_count() == 1</tt>
|
|
<p/>
|
|
-5- <i>Throws</i>: <tt>bad_alloc</tt>, or<ins>, for the template <tt>make_shared</tt>, an exception thrown from
|
|
the constructor of <tt>T</tt>, or, for the template <tt>allocate_shared</tt>,</ins> an exception thrown from
|
|
<tt>A::allocate</tt> or <ins>from <tt>allocator_traits<A>::construct</tt></ins><del>from the constructor of
|
|
<tt>T</tt></del>.
|
|
<p/>
|
|
-6- <i>Remarks</i>: Implementations are encouraged, but not required, to perform no more than one memory
|
|
allocation. [ <i>Note</i>: This provides efficiency equivalent to an intrusive smart pointer. — <i>end note</i> ]
|
|
<p/>
|
|
-7- [ <i>Note</i>: These functions will typically allocate more memory than <tt>sizeof(T)</tt> to allow for internal
|
|
bookkeeping structures such as the reference counts. — <i>end note</i> ]
|
|
</p>
|
|
</blockquote></blockquote>
|
|
</li>
|
|
</ol>
|
|
</blockquote>
|
|
|
|
<p><i>[2011-12-04: Jonathan and Daniel improve wording]</i></p>
|
|
|
|
|
|
<p>See also c++std-lib-31796</p>
|
|
|
|
|
|
|
|
|
|
<p><i>[2013-10-13, Ville]</i></p>
|
|
|
|
<p>
|
|
This issue is related to <a href="lwg-active.html#2089">2089</a>.
|
|
</p>
|
|
|
|
|
|
<p><i>[2014-02-15 post-Issaquah session : move to Tentatively NAD]</i></p>
|
|
|
|
<p>
|
|
STL: This takes an allocator, but then ignores its construct. That's squirrely.
|
|
</p>
|
|
<p>
|
|
Alisdair: The convention is when you take an allocator, you use its construct.
|
|
</p>
|
|
<p>
|
|
STL: 23.2.1 [container.requirements.general]/3, argh! This fills me with despair, but I understand it now.
|
|
</p>
|
|
<p>
|
|
STL: Ok, this is some cleanup.
|
|
</p>
|
|
<p>
|
|
STL: You're requiring <tt>b</tt> to be of type <tt>A</tt> and not being rebound, is that an overspecification?
|
|
</p>
|
|
<p>
|
|
Pablo: Good point. Hmm, that's only a requirement on what must be well-formed.
|
|
</p>
|
|
<p>
|
|
STL: If it's just a well-formed requirement, then why not just use a directly?
|
|
</p>
|
|
<p>
|
|
Pablo: Yeah, the well-formed requirement is overly complex. It's not a real call, we could just use a directly. It makes it harder to read.
|
|
</p>
|
|
<p>
|
|
Alisdair: <tt>b</tt> should be an allocator in the same family as <tt>a</tt>.
|
|
</p>
|
|
<p>
|
|
Pablo: This is a well-formed requirement, I wonder if it's the capital A that's the problem here. It doesn't matter here, this is way too much wording.
|
|
</p>
|
|
<p>
|
|
Alisdair: It's trying to tie the constructor arguments into the allocator requirements.
|
|
</p>
|
|
<p>
|
|
Pablo: <tt>b</tt> could be struck, that's a runtime quality. The construct will work with anything that's in the family of <tt>A</tt>.
|
|
</p>
|
|
<p>
|
|
Alisdair: The important part is the <tt>forward</tt> of <tt>Args</tt>.
|
|
</p>
|
|
<p>
|
|
Pablo: <tt>A</tt> must be an allocator, and <tt>forward</tt> <tt>Args</tt> must work with that.
|
|
</p>
|
|
<p>
|
|
Alisdair: First let's nail down <tt>A</tt>.
|
|
</p>
|
|
<p>
|
|
Pablo: Then replace <tt>b</tt> with <tt>a</tt>, and strike the rest.
|
|
</p>
|
|
<p>
|
|
STL: You need <tt>pt</tt>'s type, at least.
|
|
</p>
|
|
<p>
|
|
Pablo: There's nothing to be said about runtime constraints here, this function doesn't even take a <tt>pt</tt>.
|
|
</p>
|
|
<p>
|
|
STL: Looking at the Effects, I believe <tt>b</tt> is similarly messed up, we can use <tt>a2</tt> to construct an object.
|
|
</p>
|
|
<p>
|
|
Alisdair: Or any allocator in the family of <tt>a</tt>.
|
|
</p>
|
|
<p>
|
|
STL: We say this stuff for the deallocate too, it should be lifted up.
|
|
</p>
|
|
<p>
|
|
STL: "owns the address" is weird.
|
|
</p>
|
|
<p>
|
|
Alisdair: shared_ptr owns pointers, although it does sound funky.
|
|
</p>
|
|
<p>
|
|
Walter: "to destruct" is ungrammatical.
|
|
</p>
|
|
<p>
|
|
STL: "When ownership is given up" is not what we usually say.
|
|
</p>
|
|
<p>
|
|
Alisdair: I think the Returns clause is the right place to say this.
|
|
</p>
|
|
<p>
|
|
STL: The right place to say this is <tt>shared_ptr</tt>'s dtor, we don't want to use Core's "come from" convention.
|
|
</p>
|
|
<p>
|
|
Alisdair: I'm on the hook to draft cleaner wording.
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to the FDIS.</p>
|
|
|
|
<ol>
|
|
<li><p>Change the following paragraphs of 20.8.2.2.6 [util.smartptr.shared.create] as indicated:
|
|
</p>
|
|
<blockquote><pre>
|
|
template<class T, class... Args> shared_ptr<T> make_shared(Args&&... args);
|
|
<del>template<class T, class A, class... Args>
|
|
shared_ptr<T> allocate_shared(const A& a, Args&&... args);</del>
|
|
</pre></blockquote>
|
|
<p>
|
|
<del>-1- <i>Requires</i>: The expression <tt>::new (pv) T(std::forward<Args>(args)...)</tt>, where <tt>pv</tt>
|
|
has type <tt>void*</tt> and points to storage suitable to hold an object of type <tt>T</tt>, shall be well
|
|
formed. <tt>A</tt> shall be an allocator (17.6.3.5 [allocator.requirements]). The copy constructor
|
|
and destructor of <tt>A</tt> shall not throw exceptions.</del>
|
|
<p/>
|
|
-2- <i>Effects</i>: <ins>Equivalent to</ins>
|
|
</p>
|
|
<blockquote><pre>
|
|
<ins>return allocate_shared<T>(allocator<T>(), std::forward<Args>(args)...);</ins>
|
|
</pre></blockquote>
|
|
<p>
|
|
<del>Allocates memory suitable for an object of type <tt>T</tt>
|
|
and constructs an object in that memory via the placement new expression
|
|
<tt>::new (pv) T(std::forward<Args>(args)...)</tt>. The template <tt>allocate_shared</tt> uses a copy
|
|
of <tt>a</tt> to allocate memory. If an exception is thrown, the functions have no effect.</del>
|
|
<p/>
|
|
<ins>-?- <i>Remarks</i>: An implementation may meet the effects (and the implied guarantees) without
|
|
creating the allocator object [<i>Note</i>: That is, user-provided specializations of <tt>std::allocator</tt>
|
|
may not be instantiated, the expressions <tt>::new (pv) T(std::forward<Args>(args)...)</tt> and
|
|
<tt>pv->~T()</tt> may be evaluated directly — <i>end note</i>].</ins>
|
|
<p/>
|
|
<del>-3- <i>Returns</i>: A <tt>shared_ptr</tt> instance that stores and owns the address of the newly constructed
|
|
object of type <tt>T</tt>.</del>
|
|
<p/>
|
|
<del>-4- <i>Postconditions</i>: <tt>get() != 0 && use_count() == 1</tt></del>
|
|
<p/>
|
|
<del>-5- <i>Throws</i>: <tt>bad_alloc</tt>, or an exception thrown from <tt>A::allocate</tt> or from the
|
|
constructor of <tt>T</tt>.</del>
|
|
<p/>
|
|
<del>-6- <i>Remarks</i>: Implementations are encouraged, but not required, to perform no more than one memory
|
|
allocation. [<i>Note</i>: This provides efficiency equivalent to an intrusive smart pointer. — <i>end note</i>]</del>
|
|
<p/>
|
|
<del>-7- [<i>Note</i>: These functions will typically allocate more memory than <tt>sizeof(T)</tt> to allow
|
|
for internal bookkeeping structures such as the reference counts. — <i>end note</i>]</del>
|
|
</p>
|
|
</li>
|
|
<li><p>
|
|
Add the following set of <ins>new paragraphs</ins> immediately following the previous paragraph 7 of
|
|
20.8.2.2.6 [util.smartptr.shared.create]:
|
|
</p>
|
|
<blockquote><pre>
|
|
template<class T, class A, class... Args>
|
|
shared_ptr<T> allocate_shared(const A& a, Args&&... args);
|
|
</pre></blockquote>
|
|
<p>
|
|
-?- <i>Requires</i>: The expressions
|
|
<tt>allocator_traits<A>::construct(b, pt, std::forward<Args>(args)...)</tt> and
|
|
<tt>allocator_traits<A>::destroy(b, pt)</tt> shall be well-formed and well-defined,
|
|
where <tt>b</tt> has type <tt>A</tt> and is a copy of <tt>a</tt> and where <tt>pt</tt>
|
|
has type <tt>T*</tt> and points to storage suitable to hold an object of type <tt>T</tt>.
|
|
<tt>A</tt> shall meet the allocator requirements (17.6.3.5 [allocator.requirements]).
|
|
<p/>
|
|
-?- <i>Effects</i>: Uses an object <tt>a2</tt>
|
|
of type <tt>allocator_traits<A>::rebind_alloc<<i>unspecified</i>></tt> that compares equal to
|
|
<tt>a</tt> to allocate memory suitable for an object of type <tt>T</tt>.
|
|
Uses a copy <tt>b</tt> of type <tt>A</tt> from <tt>a</tt> to construct an object of type <tt>T</tt> in
|
|
that memory by calling <tt>allocator_traits<A>::construct(b, pt, std::forward<Args>(args)...)</tt>.
|
|
If an exception is thrown, the function has no effect.
|
|
<p/>
|
|
-?- <i>Returns</i>: A <tt>shared_ptr</tt> instance that stores and owns the address of the newly constructed
|
|
object of type <tt>T</tt>. When ownership is given up, the effects are as follows: Uses a copy <tt>b2</tt>
|
|
of type <tt>A</tt> from <tt>a</tt> to destruct an object of type <tt>T</tt> by calling
|
|
<tt>allocator_traits<A>::destroy(b2, pt2)</tt> where <tt>pt2</tt> has type <tt>T*</tt>
|
|
and refers to the newly constructed object. Then uses an object of type
|
|
<tt>allocator_traits<A>::rebind_alloc<<i>unspecified</i>></tt> that compares equal to
|
|
<tt>a</tt> to deallocate the allocated memory.
|
|
<p/>
|
|
-?- <i>Postconditions</i>: <tt>get() != 0 && use_count() == 1</tt>
|
|
<p/>
|
|
-?- <i>Throws</i>: Nothing unless memory allocation or <tt>allocator_traits<A>::construct</tt>
|
|
throws an exception.
|
|
<p/>
|
|
-?- <i>Remarks</i>: Implementations are encouraged, but not required, to perform no more than one memory
|
|
allocation. [<i>Note</i>: Such an implementation provides efficiency equivalent to an intrusive smart
|
|
pointer. — <i>end note</i>]
|
|
<p/>
|
|
-?- [<i>Note</i>: This function will typically allocate more memory than <tt>sizeof(T)</tt> to allow for internal
|
|
bookkeeping structures such as the reference counts. — <i>end note</i>]
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2072"></a>2072. Unclear wording about capacity of temporary buffers</h3>
|
|
<p><b>Section:</b> 20.7.11 [temporary.buffer] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Kazutoshi Satoda <b>Opened:</b> 2011-08-10 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#temporary.buffer">issues</a> in [temporary.buffer].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
According to 20.7.11 [temporary.buffer] p1+2:
|
|
|
|
</p><blockquote><pre>
|
|
template <class T>
|
|
pair<T*, ptrdiff_t> get_temporary_buffer(ptrdiff_t n) noexcept;
|
|
</pre><blockquote><p>
|
|
-1- <i>Effects</i>: Obtains a pointer to storage sufficient to store up to <tt>n</tt> adjacent <tt>T</tt>
|
|
objects. It is implementation-defined whether over-aligned types are supported (3.11).
|
|
<p/>
|
|
-2- <i>Returns</i>: A pair containing the buffer's address and capacity (in the units of <tt>sizeof(T)</tt>),
|
|
or a pair of 0 values if no storage can be obtained or if <tt>n <= 0</tt>.
|
|
</p></blockquote></blockquote>
|
|
<p>
|
|
I read this as prohibiting to return a buffer of which capacity is less than <tt>n</tt>, because
|
|
such a buffer is not sufficient to store <tt>n</tt> objects.
|
|
<p/>
|
|
The corresponding description in <a href="http://www.sgi.com/tech/stl/get_temporary_buffer.html">SGI STL</a>
|
|
is clear on this point, but I think it is a bit too verbose:
|
|
</p>
|
|
|
|
<blockquote class="note"><p>
|
|
(for the return value, a pair <tt>P</tt>) [...] the buffer pointed to by <tt>P.first</tt> is large enough
|
|
to hold <tt>P.second</tt> objects of type <tt>T</tt>. <tt>P.second</tt> is greater than or equal to 0,
|
|
and less than or equal to <tt>len</tt>.
|
|
</p></blockquote>
|
|
|
|
<p>
|
|
There seems to be two different targets of the "up to n" modification:
|
|
The capacity of obtained buffer, and the actual number that the caller
|
|
will store into the buffer.
|
|
<p/>
|
|
First I read as the latter, and got surprised seeing that libstdc++
|
|
implementation can return a smaller buffer. I started searching about
|
|
<tt>get_temporary_buffer()</tt>. After reading a quote from TC++PL at
|
|
<a href="http://stackoverflow.com/questions/3264299/why-do-i-need-stdget-temporary-buffer">stackoverflow</a>,
|
|
I realized that the former is intended.
|
|
<p/>
|
|
Such misinterpretation seems common:
|
|
</p>
|
|
<ul>
|
|
<li>The above question is likely started from same misinterpretation.</li>
|
|
<li><p>JIS standard (Japanese translation of ISO/IEC standard) says nothing
|
|
like "up to". I think the editor misinterpreted the original wording,
|
|
and omitted words for "up to" as it is redundant. (If a buffer is
|
|
sufficient to store <tt>n</tt> objects, it is also sufficient to store
|
|
up to <tt>n</tt> objects.)</p></li>
|
|
<li><p>Rogue Wave implementation doesn't return smaller buffer, instead, it
|
|
can return larger buffer on some circumstances. Apache
|
|
<a href="http://stdcxx.apache.org/">STDCXX</a> is a derived version of that
|
|
implementation, and <a href="https://stdcxx.apache.org/doc/stdlibref/get-temporary-buffer.html">publicly accessible</a>:
|
|
</p>
|
|
<blockquote class="note"><p>
|
|
Specializations of the <tt>get_temporary_buffer()</tt> function template
|
|
attempt to allocate a region of storage sufficiently large to store at
|
|
least <tt>n</tt> adjacent objects of type <tt>T</tt>.
|
|
</p></blockquote>
|
|
<p>
|
|
I know one commercial compiler package based on Rogue Wave implementation,
|
|
and its implementation is essentially same as the above.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p><i>[2014-05-18, Daniel comments and suggests concrete wording]</i></p>
|
|
|
|
|
|
<p>
|
|
The provided wording attempts to clarify the discussed capacity freedom, but it also makes it clearer that the returned
|
|
memory is just "raw memory", which is currently not really clear. In addition the wording clarifies that the deallocating
|
|
<tt>return_temporary_buffer</tt> function does not throw exceptions, which I believe is the intention when the preconditions
|
|
of the functions are satisfied. Then, my understanding is that we can provide to <tt>return_temporary_buffer</tt> a
|
|
null pointer value if that was the value, <tt>get_temporary_buffer()</tt> had returned. Furthermore, as STL noticed, the current
|
|
wording seemingly allows multiple invocations of <tt>return_temporary_buffer</tt> with the same value returned by
|
|
<tt>get_temporary_buffer</tt>; this should be constrained similar to the wording we have for <tt>operator delete</tt> (unfortunately
|
|
we miss such wording for allocators).
|
|
</p>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
MC: move to ready? in favor: 14, opposed: 0, abstain: 0
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol><li><p>Change 20.7.11 [temporary.buffer] as indicated:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
template <class T>
|
|
pair<T*, ptrdiff_t> get_temporary_buffer(ptrdiff_t n) noexcept;
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-1- <i>Effects</i>: <ins>Obtains a pointer to uninitialized, contiguous storage for <tt><i>N</i></tt> adjacent objects of type
|
|
<tt>T</tt>, for some non-negative number <tt><i>N</i></tt>.</ins><del>Obtains a pointer to storage sufficient
|
|
to store up to <tt>n</tt> adjacent <tt>T</tt> objects.</del> It is implementation-defined whether over-aligned types are supported (3.11).
|
|
<p/>
|
|
<ins>-?- <i>Remarks</i>: Calling <tt>get_temporary_buffer</tt> with a positive number <tt>n</tt> is a non-binding request to return
|
|
storage for <tt>n</tt> objects of type <tt>T</tt>. In this case, an implementation is permitted to return instead storage for a
|
|
non-negative number <tt><i>N</i></tt> of such objects, where <tt><i>N</i> != n</tt> (including <tt><i>N</i> == 0</tt>). [<i>Note</i>: The
|
|
request is non-binding to allow latitude for implementation-specific optimizations of its memory management. — <i>end note</i>].</ins>
|
|
<p/>
|
|
-2- <i>Returns</i>: <ins>If <tt>n <= 0</tt> or if no storage could be obtained, returns a pair <tt>P</tt> such that <tt>P.first</tt>
|
|
is a null pointer value and <tt>P.second == 0</tt>; otherwise returns a pair <tt>P</tt> such that <tt>P.first</tt> refers to the
|
|
address of the uninitialized storage and <tt>P.second</tt> refers to its capacity <tt><i>N</i></tt> (in the units of
|
|
<tt>sizeof(T)</tt>).</ins><del>A <tt>pair</tt> containing the buffer's address and capacity (in the units of <tt>sizeof(T)</tt>), or a
|
|
pair of 0 values if no storage can be obtained or if <tt>n <= 0</tt>.</del>
|
|
</p>
|
|
</blockquote>
|
|
|
|
<pre>
|
|
template <class T> void return_temporary_buffer(T* p);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-3- <i>Effects</i>: Deallocates the <del>buffer to which <tt>p</tt> points</del><ins>storage referenced by <tt>p</tt></ins>.
|
|
<p/>
|
|
-4- <i>Requires</i>: <del>The buffer shall have been previously allocated by</del><ins><tt>p</tt> shall be a pointer value
|
|
returned by an earlier call to</ins> <tt>get_temporary_buffer</tt> <ins>which has not been invalidated by an intervening call to
|
|
<tt>return_temporary_buffer(T*)</tt></ins>.
|
|
<p/>
|
|
<ins>-?- <i>Throws</i>: Nothing.</ins>
|
|
</p>
|
|
</blockquote>
|
|
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2077"></a>2077. Further incomplete constraints for type traits</h3>
|
|
<p><b>Section:</b> 20.10.4.3 [meta.unary.prop] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2011-08-20 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
The currently agreed on proposed wording for <a href="lwg-defects.html#2015">2015</a> using
|
|
<tt>remove_all_extents<T>::type</tt> instead of the "an array of
|
|
unknown bound" terminology in the precondition should be extended to
|
|
some further entries especially in Table 49, notably the
|
|
<tt>is_*constructible</tt>, <tt>is_*assignable</tt>, and
|
|
<tt>is_*destructible</tt> entries. To prevent ODR violations, incomplete
|
|
element types of arrays must be excluded for value-initialization and
|
|
destruction for example. Construction and assignment has to be honored,
|
|
when we have array-to-pointer conversions or pointer conversions of
|
|
incomplete pointees in effect.
|
|
</p>
|
|
|
|
<p><i>[2012, Kona]</i></p>
|
|
|
|
<p>
|
|
The issue is that in three type traits, we are accidentally saying that in certain
|
|
circumstances the type must give a specified answer when given an incomplete type.
|
|
(Specifically: an array of unknown bound of incomplete type.) The issue asserts
|
|
that there's an ODR violation, since the trait returns false in that case but might
|
|
return a different version when the trait is completed.
|
|
</p>
|
|
<p>
|
|
Howard argues: no, there is no risk of an ODR violation.
|
|
<tt>is_constructible<A[]></tt> must return <tt>false</tt> regardless of whether
|
|
<tt>A</tt> is complete, so there's no reason to forbid an array of unknown bound of
|
|
incomplete types. Same argument applies to <tt>is_assignable</tt>. General agreement
|
|
with Howard's reasoning.
|
|
</p>
|
|
<p>
|
|
There may be a real issue for <tt>is_destructible</tt>. None of us are sure what
|
|
<tt>is_destructible</tt> is supposed to mean for an array of unknown bound
|
|
(regardless of whether its type is complete), and the standard doesn't make it clear.
|
|
The middle column doesn't say what it's supposed to do for incomplete types.
|
|
</p>
|
|
<p>
|
|
In at least one implementation, <tt>is_destructible<A[]></tt> does return <tt>true</tt>
|
|
if <tt>A</tt> is complete, which would result in ODR violation unless we forbid it for
|
|
incomplete types.
|
|
</p>
|
|
<p>
|
|
Move to open. We believe there is no issue for <tt>is_constructible</tt> or
|
|
<tt>is_assignable</tt>, but that there is a real issue for <tt>is_destructible</tt>.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2088"></a>2088. <tt>std::terminate</tt> problem</h3>
|
|
<p><b>Section:</b> 18.8.3 [exception.terminate] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2011-09-25 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
Andrzej Krzemienski reported the following on comp.std.c++:
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
In N3290, which is to become the official standard, in 18.8.3.4 [terminate],
|
|
paragraph 1 reads
|
|
</p>
|
|
<blockquote><p>
|
|
<i>Remarks</i>: Called by the implementation when exception handling must
|
|
be abandoned for any of several reasons (15.5.1), in effect immediately after
|
|
evaluating the <em>throw-expression</em> (18.8.3.1). May also be called directly by the
|
|
program.
|
|
</p></blockquote>
|
|
<p>It is not clear what is "in effect". It was clear in previous drafts where paragraphs
|
|
1 and 2 read:
|
|
</p>
|
|
<blockquote><p>
|
|
Called by the implementation when exception handling must be
|
|
abandoned for any of several reasons (15.5.1). May also be called directly
|
|
by the program.
|
|
<p/>
|
|
<i>Effects</i>: Calls the <tt>terminate_handler</tt> function in effect
|
|
immediately after evaluating the <em>throw-expression</em> (18.8.3.1), if called by the
|
|
implementation, or calls the current <tt>terminate_handler</tt> function,
|
|
if called by the program.
|
|
</p>
|
|
</blockquote>
|
|
<p>
|
|
It was changed by N3189. The same applies to function unexpected (D. 11.4, paragraph 1).
|
|
<p/>
|
|
Assuming the previous wording is still intended, the wording can be read
|
|
"unless <tt>std::terminate</tt> is called by the program, we will use the handler
|
|
that was in effect immediately after evaluating the throw-expression".
|
|
<p/>
|
|
This assumes that there is some throw-expression connected to every
|
|
situation that triggers the call to <tt>std::terminate</tt>. But this is not
|
|
the case:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
In case <tt>std::thread</tt> is assigned to or destroyed while being joinable
|
|
there is no throw-expression involved.
|
|
</li>
|
|
<li>
|
|
In case <tt>std::unexpected</tt> is called by the program, <tt>std::terminate</tt> is
|
|
triggered by the implementation - no throw-expression involved.
|
|
</li>
|
|
<li>
|
|
In case a destructor throws during stack unwinding we have two throw-expressions
|
|
involved.
|
|
</li>
|
|
</ul>
|
|
<p>
|
|
Which one is referred to?
|
|
<p/>
|
|
In case <tt>std::nested_exception::rethrow_nested</tt> is called for an object that has
|
|
captured no exception, there is no throw-expression involved directly (and may no throw
|
|
be involved even indirectly).
|
|
<p/>
|
|
Next, 18.8.3.1 [terminate.handler], paragraph 2 says
|
|
</p>
|
|
<blockquote><p>
|
|
<i>Required behavior</i>: A <tt>terminate_handler</tt> shall terminate execution
|
|
of the program without returning to the caller.
|
|
</p></blockquote>
|
|
<p>
|
|
This seems to allow that the function may exit by throwing an
|
|
exception (because word "return" implies a normal return).
|
|
<p/>
|
|
One could argue that words "terminate execution of the program" are sufficient,
|
|
but then why "without returning to the caller" would be mentioned. In
|
|
case such handler throws, noexcept specification in function <tt>std::terminate</tt>
|
|
is violated, and <tt>std::terminate</tt> would be called recursively - should
|
|
<tt>std::abort</tt> not be called in case of recursive <tt>std::terminate</tt>
|
|
call? On the other hand some controlled recursion could be useful, like in the
|
|
<a href="http://cplusplus.co.il/2010/03/21/catching-uncaught-exceptions-within-terminate/">following technique</a>.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p>
|
|
The here mentioned wording changes by N3189 in regard to 18.8.3.4 [terminate] p1
|
|
were done for a better separation of effects (Effects element) and additional normative
|
|
wording explanations (Remarks element), there was no meaning change intended. Further,
|
|
there was already a defect existing in the previous wording, which was not updated when
|
|
further situations where defined, when <tt>std::terminate</tt> where supposed to be
|
|
called by the implementation.
|
|
<p/>
|
|
The part
|
|
<p/>
|
|
"in effect immediately after evaluating the throw-expression"
|
|
<p/>
|
|
should be removed and the quoted reference to 18.8.3.1 [terminate.handler]
|
|
need to be part of the effects element where it refers to the current <tt>terminate_handler</tt>
|
|
function, so should be moved just after
|
|
<p/>
|
|
"Effects: Calls the current <tt>terminate_handler</tt> function."
|
|
<p/>
|
|
It seems ok to allow a termination handler to exit via an exception, but the
|
|
suggested idiom should better be replaced by a more simpler one based on
|
|
evaluating the current exception pointer in the terminate handler, e.g.
|
|
</p>
|
|
<blockquote><pre>
|
|
void our_terminate (void) {
|
|
std::exception_ptr p = std::current_exception();
|
|
if (p) {
|
|
... // OK to rethrow and to determine it's nature
|
|
} else {
|
|
... // Do something else
|
|
}
|
|
}
|
|
</pre></blockquote>
|
|
|
|
<p><i>[2011-12-09: Daniel comments]</i></p>
|
|
|
|
|
|
<p>
|
|
A related issue is <a href="lwg-active.html#2111">2111</a>.
|
|
</p>
|
|
|
|
|
|
<p><i>[2012, Kona]</i></p>
|
|
|
|
<p>
|
|
Move to Open.
|
|
</p>
|
|
<p>
|
|
There is an interaction with Core issues in this area that Jens is already supplying wording
|
|
for. Review this issue again once Jens wording is available.
|
|
</p>
|
|
<p>
|
|
Alisdair to review clause 15.5 (per Jens suggestion) and recommend any changes, then integrate
|
|
Jens wording into this issue.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2089"></a>2089. <tt>std::allocator::construct</tt> should use uniform initialization</h3>
|
|
<p><b>Section:</b> 20.7.9.1 [allocator.members] <b>Status:</b> <a href="lwg-active.html#EWG">EWG</a>
|
|
<b>Submitter:</b> David Krauss <b>Opened:</b> 2011-10-07 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#EWG">EWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
When the <tt>EmplaceConstructible</tt> (23.2.1 [container.requirements.general]/13) requirement is used
|
|
to initialize an object, direct-initialization occurs. Initializing an aggregate or using a <tt>std::initializer_list</tt>
|
|
constructor with emplace requires naming the initialized type and moving a temporary. This is a result of
|
|
<tt>std::allocator::construct</tt> using direct-initialization, not list-initialization (sometimes called "uniform
|
|
initialization") syntax.
|
|
<p/>
|
|
Altering <tt>std::allocator<T>::construct</tt> to use list-initialization would, among other things, give
|
|
preference to <tt>std::initializer_list</tt> constructor overloads, breaking valid code in an unintuitive and
|
|
unfixable way — there would be no way for <tt>emplace_back</tt> to access a constructor preempted by
|
|
<tt>std::initializer_list</tt> without essentially reimplementing <tt>push_back</tt>.
|
|
</p>
|
|
<blockquote><pre>
|
|
std::vector<std::vector<int>> v;
|
|
v.emplace_back(3, 4); // v[0] == {4, 4, 4}, not {3, 4} as in list-initialization
|
|
</pre></blockquote>
|
|
<p>
|
|
The proposed compromise is to use SFINAE with <tt>std::is_constructible</tt>, which tests whether direct-initialization
|
|
is well formed. If <tt>is_constructible</tt> is false, then an alternative <tt>std::allocator::construct</tt> overload
|
|
is chosen which uses list-initialization. Since list-initialization always falls back on direct-initialization, the
|
|
user will see diagnostic messages as if list-initialization (uniform-initialization) were always being used, because
|
|
the direct-initialization overload cannot fail.
|
|
<p/>
|
|
I can see two corner cases that expose gaps in this scheme. One occurs when arguments intended for
|
|
<tt>std::initializer_list</tt> satisfy a constructor, such as trying to emplace-insert a value of <tt>{3, 4}</tt> in
|
|
the above example. The workaround is to explicitly specify the <tt>std::initializer_list</tt> type, as in
|
|
<tt>v.emplace_back(std::initializer_list<int>(3, 4))</tt>. Since this matches the semantics as if
|
|
<tt>std::initializer_list</tt> were deduced, there seems to be no real problem here.
|
|
<p/>
|
|
The other case is when arguments intended for aggregate initialization satisfy a constructor. Since aggregates cannot
|
|
have user-defined constructors, this requires that the first nonstatic data member of the aggregate be implicitly
|
|
convertible from the aggregate type, and that the initializer list have one element. The workaround is to supply an
|
|
initializer for the second member. It remains impossible to in-place construct an aggregate with only one nonstatic
|
|
data member by conversion from a type convertible to the aggregate's own type. This seems like an acceptably small
|
|
hole.
|
|
<p/>
|
|
The change is quite small because <tt>EmplaceConstructible</tt> is defined in terms of whatever allocator is specified,
|
|
and there is no need to explicitly mention SFINAE in the normative text.
|
|
</p>
|
|
|
|
<p><i>[2012, Kona]</i></p>
|
|
|
|
<p>
|
|
Move to Open.
|
|
</p>
|
|
<p>
|
|
There appears to be a real concern with initializing aggregates, that can be performed only
|
|
using brace-initialization. There is little interest in the rest of the issue, given the existence
|
|
of 'emplace' methods in C++11.
|
|
</p>
|
|
<p>
|
|
Move to Open, to find an acceptable solution for intializing aggregates. There is the potential
|
|
that EWG may have an interest in this area of language consistency as well.
|
|
</p>
|
|
|
|
<p><i>[2013-10-13, Ville]</i></p>
|
|
|
|
<p>
|
|
This issue is related to <a href="lwg-active.html#2070">2070</a>.
|
|
</p>
|
|
|
|
<p><i>[2015-02 Cologne]</i></p>
|
|
|
|
<p>
|
|
Move to EWG, Ville to write a paper.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to the FDIS.</p>
|
|
|
|
<p>Change 20.7.9.1 [allocator.members] p12 as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
template <class U, class... Args>
|
|
void construct(U* p, Args&&... args);
|
|
</pre><blockquote>
|
|
<p>
|
|
12 <i>Effects</i>: <tt>::new((void *)p) U(std::forward<Args>(args)...)</tt> <ins>if <tt>is_constructible<U, Args...>::value</tt>
|
|
is <tt>true</tt>, else <tt>::new((void *)p) U{std::forward<Args>(args)...}</tt></ins>
|
|
</p>
|
|
</blockquote></blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2095"></a>2095. <tt>promise</tt> and <tt>packaged_task</tt> missing constructors needed for uses-allocator construction</h3>
|
|
<p><b>Section:</b> 30.6.5 [futures.promise], 30.6.9 [futures.task] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2011-11-01 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
This example is ill-formed according to C++11 because <tt>uses_allocator<promise<R>, A>::value</tt> is true, but
|
|
<tt>is_constructible<promise<R>, A, promise<R>&&>::value</tt> is false. Similarly for <tt>packaged_task</tt>.
|
|
</p>
|
|
<blockquote><pre>
|
|
#include <future>
|
|
#include <memory>
|
|
#include <tuple>
|
|
|
|
using namespace std;
|
|
|
|
typedef packaged_task<void()> task;
|
|
typedef promise<void> prom;
|
|
allocator<task> a;
|
|
|
|
tuple<task, prom> t1{ allocator_arg, a };
|
|
tuple<task, prom> t2{ allocator_arg, a, task{}, prom{} };
|
|
</pre></blockquote>
|
|
|
|
<p><i>[2012, Portland]</i></p>
|
|
|
|
<p>
|
|
This is an allocator issue, and should be dealt with directly by LWG.
|
|
</p>
|
|
|
|
<p><i>[2013-03-06]</i></p>
|
|
|
|
|
|
<p>
|
|
Jonathan suggests to make the new constructors non-explicit and makes some representational improvements.
|
|
</p>
|
|
|
|
|
|
<p><i>[2013-09 Chicago]</i></p>
|
|
|
|
<p>
|
|
Move to deferred.
|
|
</p>
|
|
<p>
|
|
This issue has much in common with similar problems with <tt>std::function</tt> that are being addressed
|
|
by the polymorphic allocators proposal currently under evaluation in LEWG. Defer further discussion on
|
|
this topic until the final outcome of that paper and its proposed resolution is known.
|
|
</p>
|
|
|
|
<p><i>[2014-02-20 Re-open Deferred issues as Priority 4]</i></p>
|
|
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p><i>[This wording is relative to the FDIS.]</i></p>
|
|
|
|
|
|
<ol>
|
|
<li><p>Add to 30.6.5 [futures.promise], class template <tt>promise</tt> synopsis,
|
|
as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
namespace std {
|
|
template <class R>
|
|
class promise {
|
|
public:
|
|
promise();
|
|
template <class Allocator>
|
|
promise(allocator_arg_t, const Allocator& a);
|
|
<ins>template <class Allocator>
|
|
promise(allocator_arg_t, const Allocator& a, promise&& rhs) noexcept;</ins>
|
|
promise(promise&& rhs) noexcept;
|
|
promise(const promise& rhs) = delete;
|
|
~promise();
|
|
[…]
|
|
};
|
|
[…]
|
|
}
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 30.6.5 [futures.promise] as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
promise(promise&& rhs) noexcept;
|
|
<ins>template <class Allocator>
|
|
promise(allocator_arg_t, const Allocator& a, promise&& rhs) noexcept;</ins>
|
|
</pre><blockquote>
|
|
<p>
|
|
-5- <i>Effects</i>: constructs a new <tt>promise</tt> object and transfers ownership of
|
|
the shared state of <tt>rhs</tt> (if any) to the newly-constructed object.
|
|
<p/>
|
|
-6- <i>Postcondition</i>: <tt>rhs</tt> has no shared state.
|
|
<p/>
|
|
<ins>-?- [<i>Note</i>: <tt>a</tt> is not used — <i>end note</i>]</ins>
|
|
</p>
|
|
</blockquote></blockquote>
|
|
|
|
</li>
|
|
|
|
<li><p>Add to 30.6.9 [futures.task], class template <tt>packaged_task</tt> synopsis,
|
|
as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
namespace std {
|
|
template<class> class packaged_task; // <i>undefined</i>
|
|
|
|
template<class R, class... ArgTypes>
|
|
class packaged_task<R(ArgTypes...)> {
|
|
public:
|
|
// construction and destruction
|
|
packaged_task() noexcept;
|
|
<ins>template <class Allocator>
|
|
packaged_task(allocator_arg_t, const Allocator& a) noexcept;</ins>
|
|
template <class F>
|
|
explicit packaged_task(F&& f);
|
|
template <class F, class Allocator>
|
|
explicit packaged_task(allocator_arg_t, const Allocator& a, F&& f);
|
|
~packaged_task();
|
|
|
|
// no copy
|
|
packaged_task(const packaged_task&) = delete;
|
|
<ins>template<class Allocator>
|
|
packaged_task(allocator_arg_t, const Allocator& a, const packaged_task&) = delete;</ins>
|
|
packaged_task& operator=(const packaged_task&) = delete;
|
|
|
|
// move support
|
|
packaged_task(packaged_task&& rhs) noexcept;
|
|
<ins>template <class Allocator>
|
|
packaged_task(allocator_arg_t, const Allocator& a, packaged_task&& rhs) noexcept;</ins>
|
|
packaged_task& operator=(packaged_task&& rhs) noexcept;
|
|
void swap(packaged_task& other) noexcept;
|
|
[…]
|
|
};
|
|
[…]
|
|
}
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 30.6.9.1 [futures.task.members] as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
packaged_task() noexcept;
|
|
<ins>template <class Allocator>
|
|
packaged_task(allocator_arg_t, const Allocator& a) noexcept;</ins>
|
|
</pre><blockquote>
|
|
<p>
|
|
-1- <i>Effects</i>: constructs a <tt>packaged_task</tt> object with no shared state and no stored task.
|
|
<p/>
|
|
<ins>-?- [<i>Note</i>: <tt>a</tt> is not used — <i>end note</i>]</ins>
|
|
</p>
|
|
</blockquote></blockquote>
|
|
<p>[…]</p>
|
|
<blockquote><pre>
|
|
packaged_task(packaged_task&& rhs) noexcept;
|
|
<ins>template <class Allocator>
|
|
packaged_task(allocator_arg_t, const Allocator& a, packaged_task&& rhs) noexcept;</ins>
|
|
</pre><blockquote>
|
|
<p>
|
|
-5- <i>Effects</i>: constructs a new <tt>packaged_task</tt> object and transfers ownership of <tt>rhs</tt>'s
|
|
shared state to <tt>*this</tt>, leaving <tt>rhs</tt> with no shared state. Moves the stored task from <tt>rhs</tt>
|
|
to <tt>*this</tt>.
|
|
<p/>
|
|
-6- <i>Postcondition</i>: <tt>rhs</tt> has no shared state.
|
|
<p/>
|
|
<ins>-?- [<i>Note</i>: <tt>a</tt> is not used — <i>end note</i>]</ins>
|
|
</p>
|
|
</blockquote></blockquote>
|
|
|
|
</li>
|
|
</ol>
|
|
|
|
<blockquote><pre>
|
|
</pre><blockquote>
|
|
<p>
|
|
</p></blockquote></blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2101"></a>2101. Some transformation types can produce impossible types</h3>
|
|
<p><b>Section:</b> 20.10.7 [meta.trans] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2011-11-18 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
Table 53 — "Reference modifications" says in regard to the type trait
|
|
<tt>add_lvalue_reference</tt> (emphasize mine)
|
|
</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
If <tt>T</tt> names an object or <strong>function</strong> type then the member typedef type
|
|
shall name <tt>T&</tt>;
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p>
|
|
The problem with this specification is that function types with <i>cv</i>-qualifier or <i>ref</i>-qualifier,
|
|
like
|
|
</p>
|
|
<blockquote><pre>
|
|
void() const
|
|
void() &
|
|
</pre></blockquote>
|
|
<p>
|
|
are also affected by the first part of the rule, but this would essentially mean, that
|
|
instantiating <tt>add_lvalue_reference</tt> with such a type would attempt to form
|
|
a type that is not defined in the C++ type system, namely
|
|
</p>
|
|
<blockquote><pre>
|
|
void(&)() const
|
|
void(&)() &
|
|
</pre></blockquote>
|
|
<p>
|
|
The general policy for <i>TransformationTrait</i>s is to define always some meaningful
|
|
mapping type, but this does not hold for <tt>add_lvalue_reference</tt>, <tt>add_rvalue_reference</tt>,
|
|
and in addition to these two for <tt>add_pointer</tt> as well. The latter one would
|
|
attempt to form the invalid types
|
|
</p>
|
|
<blockquote><pre>
|
|
void(*)() const
|
|
void(*)() &
|
|
</pre></blockquote>
|
|
<p>
|
|
A possible reason why those traits were specified in this way is that in C++03 (and that means
|
|
for TR1), <i>cv</i>-qualifier were underspecified in the core language and several compilers
|
|
just ignored them during template instantiations. This situation became fixed by adopting
|
|
CWG issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#295">295</a> and
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#547">547</a>.
|
|
<p/>
|
|
While there is possibly some core language clarification needed (see reflector messages
|
|
starting from c++std-core-20740), it seems also clear that the library should fix the
|
|
specification. The suggested resolution follows the style of the specification of the
|
|
support concepts <tt>PointeeType</tt> and <tt>ReferentType</tt> defined in
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>.
|
|
</p>
|
|
|
|
|
|
<p><i>[2012-02-10, Kona]</i></p>
|
|
|
|
<p>
|
|
Move to NAD.
|
|
</p>
|
|
<p>
|
|
These cv- and ref-qualified function types are aberrations in the type system, and do
|
|
not represent any actual entity defined by the language. The notion of cv- and ref-
|
|
qualification applies only to the implicit <tt>*this</tt> reference in a member function.
|
|
</p>
|
|
<p>
|
|
However, these types can be produced by quirks of template metaprogramming, the question
|
|
remains what the library should do about it. For example, <tt>add_reference</tt> returns
|
|
the original type if passed a reference type, or a <tt>void</tt> type. Conversely,
|
|
<tt>add_pointer</tt> will return a pointer to the referenced type when passed a reference.
|
|
</p>
|
|
<p>
|
|
It is most likely that the 'right' answer in any case will depend on the context that the
|
|
question is being asked, in terms of forming these obscure types. The best the LWG can
|
|
do is allow an error to propagate back to the user, so they can provide their own meaningful
|
|
answer in their context - with additional metaprogramming on their part. The consensus is
|
|
that if anyone is dangerous enough with templates to get themselves into this problem, they
|
|
will also have the skills to resolve the problem themselves. This is not going to trip up
|
|
the non-expert developer.
|
|
</p>
|
|
<p>
|
|
Lastly, it was noted that this problem arises only because the language is inconsistent in
|
|
providing us these nonsense types that do no really represent anything in the language.
|
|
There may be some way Core or Evolution could give us a more consistent type system so that
|
|
the LWG does not need to invent an answer at all, should this question need resolving. This
|
|
is another reason to not specify anything at the LWG trait level at this time, leaving the
|
|
other working groups free to produce the 'right' answer that we can then follow without
|
|
changing the meaning of existing, well-defined programs.
|
|
</p>
|
|
|
|
<p><i>[2012-02-10, post-Kona]</i></p>
|
|
|
|
<p>
|
|
Move back to Open. Daniel is concerned that this is not an issue we can simply ignore,
|
|
further details to follow.
|
|
</p>
|
|
|
|
<p><i>[2012-10-06, Daniel comments]</i></p>
|
|
|
|
<p>
|
|
This issue really should be resolved as a defect: First, the argument that "forming these obscure types"
|
|
should "allow an error to propagate" is inconsistent with the exact same "obscure type" that would be formed
|
|
when <tt>std::add_lvalue_reference<void></tt> wouldn't have an extra rules for <tt>void</tt> types, which
|
|
also cannot form references. The originally proposed resolution attempts to apply the same solution for the same
|
|
common property of <tt>void</tt> types and function types with <em>cv</em>-qualifiers or <em>ref</em>-qualifier.
|
|
These functions had the property of <tt>ReferentType</tt> during concept time (see
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#749">CWG 749</a> bullet three for the final
|
|
wording).
|
|
<p/>
|
|
Core issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1417">CWG 1417</a> has clarified
|
|
that any attempt to form a reference of a pointer to a function type with <em>cv</em>-qualifiers or
|
|
<em>ref</em>-qualifier is ill-formed. Unfortunately, many compilers don't implement this yet.
|
|
<p/>
|
|
I also would like to warn about so-called "obscure" types: The problem is that these can occur as the side effect
|
|
of finding a best match overload of function templates, where this type is exactly correct for one of these
|
|
overloads, but causes a deep (not-sfinae-friendly) error for others where one of these traits are part of the
|
|
signature.
|
|
<p/>
|
|
Existing experience with <tt>void</tt> types shows, that this extra rule is not so unexpected. Further, any usage
|
|
of the result types of these traits as argument types or return types of functions would make these ill-formed
|
|
(and in a template context would be sfinaed away), so the expected effects are rarely unnoticed. Checking
|
|
all existing explicit usages of the traits <tt>add_rvalue_reference</tt>, <tt>add_lvalue_reference</tt>, and
|
|
<tt>add_pointer</tt> didn't show any example where the error would be silent: <tt>add_rvalue_reference</tt>
|
|
is used to specify the return value of <tt>declval()</tt> and the instantiation of <tt>declval<void() const>()</tt>
|
|
would be invalid, because of the attempt to return a function type. Similarly, <tt>add_lvalue_reference</tt>
|
|
is used to specify the return type of <tt>unique_ptr<T>::operator*()</tt>. Again, any instantiation with
|
|
<tt>void() const</tt> wouldn't remain unnoticed. The trait <tt>add_pointer</tt> is used to specify the trait
|
|
<tt>std::decay</tt> and this is an interesting example, because it is well-formed when instantiated with <tt>void</tt>
|
|
types, too, and is heavily used throughout the library specification. All use-cases would not be negatively affected
|
|
by the suggested acceptance of function types with <em>cv</em>-qualifiers or <em>ref</em>-qualifier, because they involve
|
|
types that are either function arguments, function parameters or types were references are formed from.
|
|
<p/>
|
|
The alternative would be to add an additional extra rule that doesn't define a type member 'type' when
|
|
we have a function type with <em>cv</em>-qualifiers or <em>ref</em>-qualifier. This is better than the
|
|
current state but it is not superior than the proposal to specify the result as the original type, because
|
|
both variants are sfinae-friendly. A further disadvantage of the "non-type" approach here would be that any
|
|
usage of <tt>std::decay</tt> would require special protection against these function types, because
|
|
instantiating <tt>std::decay<void() const></tt> again would lead to a deep, sfinae-unfriendly error.
|
|
<p/>
|
|
The following example demonstrates the problem: Even though the second <tt>f</tt> template is the best final
|
|
match here, the first one will be instantiated. During that process <tt>std::decay<T>::type</tt>
|
|
becomes instantiated as well and will raise a deep error, because as part of the implementation the trait
|
|
<tt>std::add_pointer<void() const></tt> becomes instantiated:
|
|
</p>
|
|
<blockquote><pre>
|
|
#include <type_traits>
|
|
|
|
template<class T>
|
|
typename std::decay<T>::type f(T&& t);
|
|
|
|
template<class T, class U>
|
|
U f(U u);
|
|
|
|
int main() {
|
|
f<void() const>(0);
|
|
}
|
|
</pre></blockquote>
|
|
<p>
|
|
When the here proposed resolution would be applied this program would be well-formed and selects the expected function.
|
|
</p>
|
|
|
|
<p>
|
|
<strong>Previous resolution from Daniel [SUPERSEDED]:</strong>
|
|
</p>
|
|
<blockquote class="note">
|
|
<ol>
|
|
<li><p>Change Table 53 — "Reference modifications" in 20.10.7.2 [meta.trans.ref] as indicated:</p>
|
|
|
|
<table border="1">
|
|
<caption>Table 53 — Reference modifications</caption>
|
|
<tr>
|
|
<th>Template</th>
|
|
<th>Comments</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="2" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>template <class T><br/>
|
|
struct<br/>
|
|
add_lvalue_reference;</tt>
|
|
</td>
|
|
<td>
|
|
If <tt>T</tt> names an object <tt>type</tt> or <ins>if <tt>T</tt> names a</ins> function type <ins>that does not have<br/>
|
|
<i>cv</i>-qualifiers or a <i>ref</i>-qualifier</ins> then the member typedef <tt>type</tt><br/>
|
|
shall name <tt>T&</tt>; otherwise, if <tt>T</tt> names a type "rvalue reference to <tt>T1</tt>" then<br/>
|
|
the member typedef <tt>type</tt> shall name <tt>T1&</tt>; otherwise, <tt>type</tt> shall name <tt>T</tt>.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>template <class T><br/>
|
|
struct<br/>
|
|
add_rvalue_reference;</tt>
|
|
</td>
|
|
<td>
|
|
If <tt>T</tt> names an object <tt>type</tt> or <ins>if <tt>T</tt> names a</ins> function type <ins>that does not have<br/>
|
|
<i>cv</i>-qualifiers or a <i>ref</i>-qualifier</ins> then the member typedef <tt>type</tt><br/>
|
|
shall name <tt>T&&</tt>; otherwise, <tt>type</tt> shall name <tt>T</tt>. [<i>Note</i>: This rule reflects<br/>
|
|
the semantics of reference collapsing (8.3.2 [dcl.ref]). For example, when a type <tt>T</tt><br/>
|
|
names a type <tt>T1&</tt>, the type <tt>add_rvalue_reference<T>::type</tt> is not an<br/>
|
|
rvalue reference. — <i>end note</i>]
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
</li>
|
|
|
|
<li><p>Change Table 56 — "Pointer modifications" in 20.10.7.5 [meta.trans.ptr] as indicated:</p>
|
|
|
|
<table border="1">
|
|
<caption>Table 56 — Pointer modifications</caption>
|
|
<tr>
|
|
<th>Template</th>
|
|
<th>Comments</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="2" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>template <class T><br/>
|
|
struct add_pointer;</tt>
|
|
</td>
|
|
<td>
|
|
<del>The member typedef <tt>type</tt> shall name the same type as</del><br/>
|
|
<ins>If <tt>T</tt> names a function type that has <i>cv</i>-qualifiers or a <i>ref</i>-qualifier<br/>
|
|
then the member typedef <tt>type</tt> shall name <tt>T</tt>; otherwise, it<br/>
|
|
shall name the same type as</ins> <tt>remove_reference<T>::type*</tt>.
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
|
|
</li>
|
|
</ol>
|
|
</blockquote>
|
|
|
|
<p>
|
|
The following revised proposed resolution defines - in the absence of a proper core language definition - a new
|
|
term <em>referenceable type</em> as also suggested by the resolution for LWG <a href="lwg-defects.html#2196">2196</a> as an
|
|
umbrella of the negation of <tt>void</tt> types and function types with <em>cv</em>-qualifiers or <em>ref</em>-qualifier.
|
|
This simplifies and minimizes the requires wording changes.
|
|
</p>
|
|
|
|
<p><i>[
|
|
2013-09-26, Daniel synchronizes wording with recent draft
|
|
]</i></p>
|
|
|
|
|
|
<p><i>[
|
|
2014-05-18, Daniel synchronizes wording with recent draft and comments
|
|
]</i></p>
|
|
|
|
|
|
<p>
|
|
My impression is that this urgency of action this issue attempts to point out is partly caused by the fact that even for
|
|
the most recent C++14 compilers the implementations have just recently changed to adopt the core wording. Examples for these
|
|
are bug reports to <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61182">gcc</a> or
|
|
<a href="http://llvm.org/bugs/show_bug.cgi?id=19742">clang</a>.
|
|
<p/>
|
|
Occasionally the argument has been presented to me that the suggested changes to the traits affected by this issue would
|
|
lead to irregularities compared to other traits, especially the lack of guarantee that <tt>add_pointer</tt> might not return
|
|
a pointer or that <tt>add_(l/r)value_reference</tt> might not return a reference type. I would like to point out that this
|
|
kind of divergence is actually already present in most <tt>add/remove</tt> traits: For example, we have no guarantee that
|
|
<tt>add_const</tt> returns a const type (Reference types or function types get special treatments), or that <tt>add_rvalue_reference</tt>
|
|
returns an rvalue-reference (e.g. when applied to an lvalue-reference type).
|
|
<p/>
|
|
Zhihao Yuan brought to my attention, that the originally proposing paper
|
|
<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2002/n1345.html">N1345</a> carefully discussed these design choices.
|
|
</p>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
MC: move to Ready: in favor: 16, opposed: 0, abstain: 1<br/>
|
|
STL: have libstdc++, libc++ implemented this? we would need to change your implementation<br/>
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Change Table 53 — "Reference modifications" in 20.10.7.2 [meta.trans.ref] as indicated:</p>
|
|
|
|
<table border="1">
|
|
<caption>Table 53 — Reference modifications</caption>
|
|
<tr>
|
|
<th>Template</th>
|
|
<th>Comments</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="2" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>template <class T><br/>
|
|
struct<br/>
|
|
add_lvalue_reference;</tt>
|
|
</td>
|
|
<td>
|
|
If <tt>T</tt> names <del>an object or function type</del><ins>a referenceable type</ins><br/>
|
|
then the member typedef <tt>type</tt><br/>
|
|
shall name <tt>T&</tt>; otherwise, <del>if <tt>T</tt> names a type "rvalue reference to <tt>T1</tt>" then<br/>
|
|
the member typedef <tt>type</tt> shall name <tt>T1&</tt>; otherwise,</del> <tt>type</tt> shall name <tt>T</tt>.<br/>
|
|
<ins>[<i>Note</i>: This rule reflects the semantics of reference collapsing (8.3.2 [dcl.ref]). — <i>end note</i>]</ins>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>template <class T><br/>
|
|
struct<br/>
|
|
add_rvalue_reference;</tt>
|
|
</td>
|
|
<td>
|
|
If <tt>T</tt> names <del>an object or function type</del><ins>a referenceable type</ins><br/>
|
|
then the member typedef <tt>type</tt><br/>
|
|
shall name <tt>T&&</tt>; otherwise, <tt>type</tt> shall name <tt>T</tt>. [<i>Note</i>: This rule reflects<br/>
|
|
the semantics of reference collapsing (8.3.2 [dcl.ref]). For example, when a type <tt>T</tt><br/>
|
|
names a type <tt>T1&</tt>, the type <tt>add_rvalue_reference_t<T></tt> is not an<br/>
|
|
rvalue reference. — <i>end note</i>]
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
</li>
|
|
|
|
<li><p>Change Table 56 — "Pointer modifications" in 20.10.7.5 [meta.trans.ptr] as indicated:</p>
|
|
|
|
<table border="1">
|
|
<caption>Table 56 — Pointer modifications</caption>
|
|
<tr>
|
|
<th>Template</th>
|
|
<th>Comments</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="2" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>template <class T><br/>
|
|
struct add_pointer;</tt>
|
|
</td>
|
|
<td>
|
|
<ins>If <tt>T</tt> names a referenceable type or a (possibly <i>cv</i>-qualified) <tt>void</tt> type then<br/></ins>
|
|
<del>T</del><ins>t</ins>he member typedef <tt>type</tt> shall name the same type as<br/>
|
|
<tt>remove_reference_t<T>*</tt><ins>; otherwise, <tt>type</tt> shall name <tt>T</tt></ins>.
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2111"></a>2111. Which <tt>unexpected</tt>/<tt>terminate</tt> handler is called from the exception handling runtime?</h3>
|
|
<p><b>Section:</b> 18.8.3.4 [terminate], D.8.4 [unexpected] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2011-12-06 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#terminate">issues</a> in [terminate].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
Prior to N3242, modified by N3189, we said this about <tt>unexpected()</tt>:
|
|
</p>
|
|
|
|
<blockquote><p>
|
|
<i>Effects</i>: Calls the <tt>unexpected_handler</tt> function in effect immediately after evaluating the throw-expression
|
|
(D.13.1), if called by the implementation, or calls the current <tt>unexpected_handler</tt>, if called by the program.
|
|
</p></blockquote>
|
|
|
|
<p>
|
|
and this about <tt>terminate()</tt>:
|
|
</p>
|
|
|
|
<blockquote><p>
|
|
<i>Effects</i>: Calls the <tt>terminate_handler</tt> function in effect immediately after evaluating the throw-expression (18.8.3.1),
|
|
if called by the implementation, or calls the current <tt>terminate_handler</tt> function, if called by the program.
|
|
</p></blockquote>
|
|
|
|
<p>
|
|
But now in both places we say:
|
|
</p>
|
|
|
|
<blockquote><p>
|
|
Calls the current <tt>unexpected_handler</tt> function.
|
|
</p></blockquote>
|
|
|
|
<p>
|
|
and:
|
|
</p>
|
|
|
|
<blockquote><p>
|
|
Calls the current <tt>terminate</tt> function.
|
|
</p></blockquote>
|
|
|
|
<p>
|
|
The difference is that in C++98/03 if a destructor reset a handler during stack unwinding, that new handler was
|
|
not called if the unwinding later led to <tt>unexpected()</tt> or <tt>terminate()</tt> being called. But these new
|
|
words say that this new handler <em>is</em> called. This is an ABI-breaking change in the way exceptions are handled.
|
|
Was this change intentional?
|
|
<p/>
|
|
N3189 was mainly about introducing exception safety and getters for the handlers. I don't recall the issue of
|
|
<em>which</em> handler gets called being part of the discussion.
|
|
<p/>
|
|
I propose that we revert to the C++98/03 behavior in this regard, lest ABI's such as the Itanium ABI are invalidated.
|
|
A mechanical way to do this is to revert bullets 9 and 12 of N3189.
|
|
</p>
|
|
|
|
<p><i>[2011-12-09: Daniel comments]</i></p>
|
|
|
|
|
|
<p>
|
|
There was no such semantic change intended. It was an unfortunate side effect when trying to better separate different
|
|
responsibilities in the previous wording.
|
|
<p/>
|
|
A related issue is <a href="lwg-active.html#2088">2088</a>.
|
|
</p>
|
|
|
|
<p><i>[2012-01-30: Howard comments]</i></p>
|
|
|
|
|
|
<p>
|
|
The C++98/03 wording is somewhat ambiguous:
|
|
</p>
|
|
<blockquote><p>
|
|
Calls the terminate_handler function in effect immediately after evaluating the throw-expression...
|
|
</p></blockquote>
|
|
<p>
|
|
There are potentially two throw-expressions being referred to here, and it is not clear if this sentence is referring to just the first or both:
|
|
</p>
|
|
<ol>
|
|
<li><tt>throw <i>assignment-expression</i>;</tt></li>
|
|
<li><tt>throw;</tt></li>
|
|
</ol>
|
|
<p>
|
|
There is ample evidence in current implementations that it is understood that <i>only</i>
|
|
1. was meant. But clearly both 1 and 2 could have been meant. We need a clarification. Does an execution
|
|
of a rethrow (throw;) update which handlers can potentially be called?
|
|
</p>
|
|
<ol>
|
|
<li value="2"><tt>throw;</tt> // update handlers to get_xxx()?</li>
|
|
</ol>
|
|
<p>
|
|
My opinion: Go with existing practice, and clarify what that practice is, if surveys find that everyone
|
|
does the same thing. Gcc 4.2 and Apple do 1. only, and do not reset the handlers to the current handlers
|
|
on throw;.
|
|
<p/>
|
|
If current practice is not unanimously one way or the other, I have no strong opinion. I have not found
|
|
a motivating use case for the use of any particular handler. Most applications set the handlers once at
|
|
the beginning of the program and then do not change them, and so will not be impacted by whatever decision
|
|
is made here.
|
|
</p>
|
|
|
|
<p><i>[2014-02-15 Issaquah: Move to Review]</i></p>
|
|
|
|
|
|
<p>
|
|
STL: Original change in N3242 came from trying to make set/get exception handler thread safe.
|
|
The issue requests we revert to 98/03, which Howard notes was already ambiguous.
|
|
</p>
|
|
|
|
<p>
|
|
Alisdair: Issue author thinks we made this change in C++11 without taking into account Itanium ABI,
|
|
which cannot implement the new semantic (without breaking compatibility).
|
|
</p>
|
|
|
|
<p>
|
|
Alisdair: original change in N3242 was trying to solve the problem of which handler is called when
|
|
the handler is changing in another thread, but this turns out to be an issue in even the
|
|
single-threaded case.
|
|
</p>
|
|
|
|
<p>
|
|
Pablo: despite wanting to make it thread safe, you are still changing a global
|
|
</p>
|
|
|
|
<p>
|
|
STL and Marshall confirm that there is real implementation divergance on the question, so
|
|
we cannot pick just one behavior if we want to avoid breaking exisitng practice.
|
|
</p>
|
|
|
|
<p>
|
|
Alisdair: not sure who to talk to across all library vendors to fix, need more information
|
|
for progress (IBM and Sun)
|
|
</p>
|
|
|
|
<p>
|
|
STL: Howard did identify a problem with the wording as well: <tt>throw;</tt> is a throw expression,
|
|
but we typically want to re-activate the in-flight exception, not throw a new copy.
|
|
</p>
|
|
|
|
<p>
|
|
Pablo: wondering why all of this wording is here (N3189)? It looks like we were trying to handle another thread
|
|
changing handler between a <tt>throw</tt> and <tt>terminate</tt> in current thread.
|
|
</p>
|
|
|
|
<p>
|
|
Alisdair: Anything working with exception handling should have used only thread-local resources, but that ship has sailed.
|
|
We must account for the same exception object being re-thrown in multiple threads simultaneously, with no happens-before
|
|
relationships.
|
|
</p>
|
|
|
|
<p>
|
|
Room: Why on earth would we care about exactly which way the program dies when the terminate calls are racing?!
|
|
</p>
|
|
|
|
<p>
|
|
Pablo: Reasonable to set the handler once (in <tt>main</tt>) and never change it.
|
|
</p>
|
|
|
|
<p>
|
|
Pablo: If willing to put lots of work into this, you could say at point of a <tt>throw</tt> these handlers become
|
|
thread local but that is overkill. We want destructors to be able to change these handlers (if only for backwards
|
|
compatibility).
|
|
</p>
|
|
|
|
<p>
|
|
Alisdair: the <i>"do it right"</i> is to do something per thread, but that is more work than vendors will want to do.
|
|
Want to say setting handler while running multiple threads is unspecified.
|
|
</p>
|
|
|
|
<p>
|
|
Pablo: possible all we need to do is say it is always the current handler
|
|
</p>
|
|
|
|
<p>
|
|
STL: That prevents an implementation or single threaded program from calling a new handler after a <tt>throw</tt>,
|
|
probably should say if <tt>terminate</tt> is called <i>by the implementation</i> (during EH), any handler that was
|
|
current can be called. Leaves it up in the air as to when the handler is captured, supporting the diverging
|
|
existing practices.
|
|
</p>
|
|
|
|
<p>
|
|
Jeffrey: use <i>happens before</i> terminology to avoid introducing races
|
|
</p>
|
|
|
|
<p>
|
|
STL: Give this to concurrency?
|
|
</p>
|
|
|
|
<p>
|
|
Jeffrey: It is in clause 18, generally LWG and not SG1 territory.
|
|
</p>
|
|
|
|
<p>
|
|
Alisdair: Concerned about introducing <i>happens before</i> into fundamental exception handling since it would affect
|
|
single threaded performance as well. Want to give to concurrency or LEWG/EWG, we are into language design here.
|
|
</p>
|
|
|
|
<p>
|
|
Jeffrey: suspect LEWG won't have a strong opinion. I don't want it to be ours!!!
|
|
</p>
|
|
|
|
<p>
|
|
Pablo: Might be a case for core>
|
|
</p>
|
|
|
|
<p>
|
|
Alisdair: Would be happier if at least one core person were in the discussion.
|
|
</p>
|
|
|
|
<p>
|
|
STL: No sympathy for code that tries to guard the terminate handler.
|
|
</p>
|
|
|
|
<p>
|
|
Alisdair: We are back to set it once, globally. Want to be clear that if <tt>set_terminate</tt> is called just once,
|
|
when EH is not active, and never changed again, then the user should get the handler from that specific call.
|
|
</p>
|
|
|
|
<p>
|
|
AlisdairM: "unspecified which handler is called if an exception is active when <tt>set_terminate</tt> is called."
|
|
This supports existing behaviors, and guarantees which handler is called in non-conentious situations. Implicit
|
|
assumption that a funtion becomes a handler only after a successful call to <tt>set_handler</tt>, so we are not
|
|
leaving a door open to the implementation inventing entirely new handlers of its own.
|
|
</p>
|
|
|
|
<p>
|
|
<i>Consensus.</i>
|
|
</p>
|
|
|
|
<p>
|
|
Poll to confirm status as P1: new consensus is P3
|
|
</p>
|
|
|
|
<p>
|
|
<i>Action:</i> Alisdair provides new wording. Drop from P1 to P3, and move to Review.
|
|
</p>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
HH: we accidentally changed semantics of which handler gets called during exception unwinding. This was attempt to put it back.
|
|
Discovered implementations don't really do anything. […] Fine with unspecified behavior to move this week.<br/>
|
|
STL/MC: observed different behavior<br/>
|
|
STL: legitimizes all implementations and tells users to not do this<br/>
|
|
Move to ready? 9/0/1
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<p>
|
|
Amend 18.8.3.4 [terminate] as indicated:
|
|
</p>
|
|
|
|
<tt>[[noreturn]] void terminate() noexcept;</tt>
|
|
<blockquote><p>
|
|
<i>Remarks:</i> Called by the implementation when exception handling must be abandoned for any of several reasons (15.5.1)
|
|
<del>, in effect immediately after throwing the exception</del>. May also be called directly by the program.
|
|
</p></blockquote>
|
|
|
|
<blockquote><p>
|
|
<i>Effects:</i> <ins>Calls a <tt>terminate_handler</tt> function. It is unspecified which <tt>terminate_handler</tt> function will
|
|
be called if an exception is active during a call to <tt>set_terminate</tt>. Otherwise c</ins><del>C</del>alls the current
|
|
<tt>terminate_handler</tt> function. [<i>Note:</i> A default <tt>terminate_handler</tt> is always considered a callable handler in
|
|
this context. — <i>end note</i>]
|
|
</p></blockquote>
|
|
|
|
<p>
|
|
Amend D.8.4 [unexpected] as indicated:
|
|
</p>
|
|
|
|
<tt>[[noreturn]] void unexpected();</tt>
|
|
<blockquote><p>
|
|
Remarks: Called by the implementation when a function exits via an exception not allowed by its <i>exception-specification</i>
|
|
(15.5.2)<del>, in effect after evaluating the throw-expression (D.11.1)</del>. May also be called directly by the program.
|
|
</p></blockquote>
|
|
|
|
<blockquote><p>
|
|
<i>Effects:</i> <ins>Calls an <tt>unexpected_handler</tt> function. It is unspecified which <tt>unexpected_handler</tt>
|
|
function will be called if an exception is active during a call to <tt>set_unexpected</tt>. Otherwise c</ins><del>C</del>alls the current
|
|
<tt>unexpected_handler</tt> function. [<i>Note:</i> A default <tt>unexpected_handler</tt> is always considered a callable handler in
|
|
this context. — <i>end note</i>]
|
|
</p></blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2114"></a>2114. Incorrect "<em>contextually</em> convertible to <tt>bool</tt>" requirements</h3>
|
|
<p><b>Section:</b> 17.6.3.3 [nullablepointer.requirements], 24.2.3 [input.iterators], 24.2.7 [random.access.iterators], 25.1 [algorithms.general], 25.4 [alg.sorting], 30.2.1 [thread.req.paramname] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2011-12-09 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
As of 17.6.3.1 [utility.arg.requirements] Table 17/18, the return types of the expressions
|
|
</p>
|
|
<blockquote><pre>
|
|
a == b
|
|
</pre></blockquote>
|
|
<p>
|
|
or
|
|
</p>
|
|
<blockquote><pre>
|
|
a < b
|
|
</pre></blockquote>
|
|
<p>
|
|
for types satisfying the <tt>EqualityComparable</tt> or <tt>LessThanComparable</tt>
|
|
types, respectively, are required to be "convertible to <tt>bool</tt>" which corresponds to
|
|
a copy-initialization context. But several newer parts of the library that refer to
|
|
such contexts have lowered the requirements taking advantage of the new terminology of
|
|
"<em>contextually</em> convertible to <tt>bool</tt>" instead, which corresponds to a
|
|
direct-initialization context (In addition to "normal" direct-initialization constructions,
|
|
operands of logical operations as well as <tt>if</tt> or <tt>switch</tt> conditions also
|
|
belong to this special context).
|
|
<p/>
|
|
One example for these new requirements are input iterators which satisfy <tt>EqualityComparable</tt>
|
|
but also specify that the expression
|
|
</p>
|
|
<blockquote><pre>
|
|
a != b
|
|
</pre></blockquote>
|
|
<p>
|
|
shall be just "<strong>contextually</strong> convertible to <tt>bool</tt>". The same discrepancy
|
|
exists for requirement set <tt>NullablePointer</tt> in regard to several equality-related expressions.
|
|
<p/>
|
|
For random access iterators we have
|
|
</p>
|
|
<blockquote><p>
|
|
<tt>a < b</tt> contextually convertible to <tt>bool</tt>
|
|
</p></blockquote>
|
|
<p>
|
|
as well as for all derived comparison functions, so strictly speaking we could have a random access
|
|
iterator that does not satisfy the <tt>LessThanComparable</tt> requirements, which looks like an
|
|
artifact to me.
|
|
<p/>
|
|
Even if we keep with the existing requirements based on <tt>LessThanComparable</tt> or
|
|
<tt>EqualityComparable</tt> we still would have the problem that some current specifications
|
|
are actually based on the assumption of implicit convertibility instead of "explicit convertibility", e.g.
|
|
20.8.1.5 [unique.ptr.special] p3:
|
|
</p>
|
|
<blockquote><pre>
|
|
template <class T1, class D1, class T2, class D2>
|
|
bool operator!=(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-3- <i>Returns</i>: <tt>x.get() != y.get()</tt>.
|
|
</p>
|
|
</blockquote></blockquote>
|
|
<p>
|
|
Similar examples exist in 20.8.1.2.2 [unique.ptr.single.dtor] p2, 20.8.1.2.3 [unique.ptr.single.asgn] p9,
|
|
20.8.1.2.4 [unique.ptr.single.observers] p1+3+8, etc.
|
|
<p/>
|
|
In all these places the expressions involving comparison functions (but <em>not</em> those of the conversion
|
|
of a <tt>NullablePointer</tt> to <tt>bool</tt>!) assume to be "convertible to <tt>bool</tt>". I think this
|
|
is a very natural assumption and all delegations of the comparison functions of some type <tt>X</tt> to some
|
|
other API type <tt>Y</tt> in third-party code does so assuming that copy-initialization semantics will
|
|
just work.
|
|
<p/>
|
|
The actual reason for using the newer terminology can be rooted back to LWG <a href="lwg-defects.html#556">556</a>. My hypotheses
|
|
is that the resolution of that issue also needs a slight correction. Why so?
|
|
<p/>
|
|
The reason for opening that issue were worries based on the previous "convertible to <tt>bool</tt>"
|
|
wording. An expressions like "<tt>!pred(a, b)</tt>" might not be well-formed in those situations, because
|
|
<tt>operator!</tt> might not be accessible or might have an unusual semantics (and similarly for other logical
|
|
operations). This can indeed happen with unusual proxy return types, so the idea was that the evaluation of
|
|
<tt>Predicate</tt>, <tt>BinaryPredicate</tt> (25.1 [algorithms.general] p8+9), and <tt>Compare</tt>
|
|
(25.4 [alg.sorting] p2) should be defined based on contextual conversion to <tt>bool</tt>.
|
|
Unfortunately this <em>alone</em> is not sufficient: In addition, I think, we <em>also</em> want the predicates
|
|
to be (implicitly) convertible to <tt>bool</tt>! Without this wording, several conditions are plain wrong,
|
|
e.g. 25.2.5 [alg.find] p2, which talks about "<tt>pred(*i) != false</tt>" (<tt>find_if</tt>) and
|
|
"<tt>pred(*i) == false</tt>" (<tt>find_if_not</tt>). These expressions are not within a boolean context!
|
|
<p/>
|
|
While we could simply fix all these places by proper wording to be considered in a "contextual conversion to
|
|
<tt>bool</tt>", I think that this is not the correct solution: Many third-party libraries already refer to
|
|
the previous C++03 <tt>Predicate</tt> definition — it actually predates C++98 and is as old as the
|
|
<a href="http://www.sgi.com/tech/stl/Predicate.html">SGI specification</a>. It seems to be a high price to
|
|
pay to switch to direct initialization here instead of fixing a completely different specification problem.
|
|
<p/>
|
|
A final observation is that we have another definition for a <tt>Predicate</tt> in 30.2.1 [thread.req.paramname] p2:
|
|
</p>
|
|
<blockquote><p>
|
|
If a parameter is <tt>Predicate</tt>, <tt>operator()</tt> applied to the actual template argument shall return a value that
|
|
is convertible to <tt>bool</tt>.
|
|
</p></blockquote>
|
|
<p>
|
|
The problem here is not that we have two different definitions of <tt>Predicate</tt> in the standard — this
|
|
is confusing, but this fact alone is not a defect. The first (minor) problem is that this definition does not properly
|
|
apply to function objects that are function pointers, because <tt>operator()</tt> is not defined in a strict sense.
|
|
But the actually worse second problem is that this wording has the very <tt>same</tt> problem that has originally lead to
|
|
LWG <a href="lwg-defects.html#556">556</a>! We only need to look at 30.5.1 [thread.condition.condvar] p15 to recognice this:
|
|
</p>
|
|
<blockquote><pre>
|
|
while (!pred())
|
|
wait(lock);
|
|
</pre></blockquote>
|
|
<p>
|
|
The negation expression here looks very familiar to the example provided in LWG <a href="lwg-defects.html#556">556</a> and is sensitive
|
|
to the same "unusual proxy" problem. Changing the 30.2.1 [thread.req.paramname] wording to a corresponding
|
|
"contextual conversion to <tt>bool</tt>" wouldn't work either, because existing specifications rely on "convertible
|
|
to <tt>bool</tt>", e.g. 30.5.1 [thread.condition.condvar] p32+33+42 or 30.5.2 [thread.condition.condvarany]
|
|
p25+26+32+33.
|
|
<p/>
|
|
To summarize: I believe that LWG <a href="lwg-defects.html#556">556</a> was not completely resolved. A pessimistic interpretation is,
|
|
that even with the current wording based on "contextually convertible to <tt>bool</tt>" the actual problem of that
|
|
issue has <em>not</em> been fixed. What actually needs to be required here is some normative wording that basically
|
|
expresses something along the lines of:
|
|
</p>
|
|
<blockquote><p>
|
|
The semantics of <em>any</em> contextual conversion to <tt>bool</tt> shall be equivalent to the semantics of
|
|
any implicit conversion to <tt>bool</tt>.
|
|
</p></blockquote>
|
|
<p>
|
|
This is still not complete without having concepts, but it seems to be a better approximation. Another way of solving
|
|
this issue would be to define a minimum requirements table with equivalent semantics. The proposed wording is a bit
|
|
simpler but attempts to express the same thing.
|
|
</p>
|
|
|
|
<p><i>[2012, Kona]</i></p>
|
|
|
|
<p>
|
|
Agree with Daniel that we potentially broke some C++03 user code, accept the changes striking
|
|
"contextually" from tables. Stefan to provide revised wording for section 25, and figure out
|
|
changes to section 30.
|
|
</p>
|
|
<p>
|
|
Move to open, and then to Review when updated wording from Stefan is available.
|
|
</p>
|
|
|
|
<p><i>[2012-10-12, STL comments]</i></p>
|
|
|
|
|
|
<ol>
|
|
<li>
|
|
<p>
|
|
The current proposed resolution still isn't completely satisfying. It would certainly be possible for the Standard to
|
|
require these various expressions to be implicitly and contextually convertible to <tt>bool</tt>, but that would have
|
|
a subtle consequence (which, I will argue, is undesirable - regardless of the fact that it dates all the way back to
|
|
C++98/03). It would allow users to provide really wacky types to the Standard Library, with one of two effects:
|
|
</p>
|
|
<ol style="list-style-type:upper-alpha">
|
|
<li>
|
|
<p>Standard Library implementations would have to go to great lengths to respect such wacky types, essentially using
|
|
<tt>static_cast<bool></tt> when invoking any predicates or comparators.
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
Otherwise, such wacky types would be de facto nonportable, because they would make Standard Library implementations
|
|
explode.
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>
|
|
Effect B is the status quo we're living with today. What Standard Library implementations want to do with <tt>pred(args)</tt>
|
|
goes beyond "<tt>if (pred(args))</tt>" (C++03), contextually converting <tt>pred(args)</tt> to <tt>bool</tt> (C++11), or
|
|
implicitly and contextually converting <tt>pred(args)</tt> to <tt>bool</tt> (the current proposed resolution).
|
|
Implementations want to say things like:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
if (pred(args))
|
|
if (!pred(args))
|
|
if (cond && pred(args))
|
|
if (cond && !pred(args))
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
These are real examples taken from Dinkumware's implementation. There are others that would be realistic
|
|
("<tt>pred(args) && cond</tt>", "<tt>cond || pred(args)</tt>", etc.)
|
|
<p/>
|
|
Although negation was mentioned in this issue's Discussion section, and in LWG <a href="lwg-defects.html#556">556</a>'s, the current proposed
|
|
resolution doesn't fix this problem. Requiring <tt>pred(args)</tt> to be implicitly and contextually convertible to <tt>bool</tt>
|
|
doesn't prevent <tt>operator!()</tt> from being overloaded and returning <tt>std::string</tt> (as a wacky example). More
|
|
ominously, it doesn't prevent <tt>operator&&()</tt> and <tt>operator||()</tt> from being overloaded and destroying
|
|
short-circuiting.
|
|
</p>
|
|
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
I would like LWG input before working on Standardese for a new proposed resolution. Here's an outline of what I'd like to
|
|
do:
|
|
</p>
|
|
<ol style="list-style-type:upper-alpha">
|
|
<li>
|
|
<p>
|
|
Introduce a new "concept" in 17.6.3 [utility.requirements], which I would call <tt>BooleanTestable</tt> in the
|
|
absence of better ideas.
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
Centralize things and reduce verbosity by having everything simply refer to <tt>BooleanTestable</tt> when necessary.
|
|
I believe that the tables could say "Return type: <tt>BooleanTestable</tt>", while Predicate/BinaryPredicate/Compare
|
|
would need the incantation "shall satisfy the requirements of BooleanTestable".
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
Resolve the tug-of-war between users (who occasionally want to do weird things) and implementers (who don't want to have
|
|
to contort their code) by requiring that:
|
|
</p>
|
|
<ol style="list-style-type:upper-roman">
|
|
<li>
|
|
<p>
|
|
Given a <tt>BooleanTestable x</tt>, <tt>x</tt> is both implicitly and contextually convertible to <tt>bool</tt>.
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
Given a <tt>BooleanTestable x</tt>, <tt>!x</tt> is <tt>BooleanTestable</tt>. (This is intentionally "recursive".)
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
Given a <tt>BooleanTestable x</tt>, <tt>bool t = x, t2(x), f = !x;</tt> has the postcondition <tt>t == t2 && t != f</tt>.
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
Given a <tt>BooleanTestable x</tt> and a <tt>BooleanTestable y</tt> of possibly different types, "<tt>x && y</tt>"
|
|
and "<tt>x || y</tt>" invoke the built-in <tt>operator&&()</tt> and <tt>operator||()</tt>, triggering short-circuiting.
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
<tt>bool</tt> is <tt>BooleanTestable</tt>.
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
<p>
|
|
I believe that this simultaneously gives users great latitude to use types other than <tt>bool</tt>, while allowing
|
|
implementers to write reasonable code in order to get their jobs done. (If I'm forgetting anything that implementers
|
|
would want to say, please let me know.)
|
|
</p>
|
|
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
About requirement (I): As Daniel patiently explained to me, we need to talk about both implicit conversions and
|
|
contextual conversions, because it's possible for a devious type to have both "<tt>explicit operator bool()</tt>"
|
|
and "<tt>operator int()</tt>", which might behave differently (or be deleted, etc.).
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
About requirement (IV): This is kind of tricky. What we'd like to say is, "<tt>BooleanTestable</tt> can't ever trigger
|
|
an overloaded logical operator". However, given a perfectly reasonable type <tt>Nice</tt> - perhaps even <tt>bool</tt> itself! -
|
|
other code (perhaps a third-party library) could overload <tt>operator&&(Nice, Evil)</tt>. Therefore, I believe
|
|
that the requirement should be "no first use" - the Standard Library will ask for various <tt>BooleanTestable</tt> types
|
|
from users (for example, the result of "<tt>first != last</tt>" and the result of "<tt>pred(args)</tt>"), and as long
|
|
as they don't trigger overloaded logical operators with each other, everything is awesome.
|
|
</p>
|
|
</li>
|
|
|
|
|
|
<li>
|
|
<p>
|
|
About requirement (V): This is possibly redundant, but it's trivial to specify, makes it easier for users to understand
|
|
what they need to do ("oh, I can always achieve this with <tt>bool</tt>"), and provides a "base case" for requirement
|
|
(IV) that may or may not be necessary. Since <tt>bool</tt> is <tt>BooleanTestable</tt>, overloading
|
|
<tt>operator&&(bool, Other)</tt> (etc.) clearly makes the <tt>Other</tt> type non-<tt>BooleanTestable</tt>.
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<strong>Previous resolution from Daniel [SUPERSEDED]:</strong>
|
|
<p/>
|
|
<blockquote class="note">
|
|
<p>This wording is relative to the FDIS.</p>
|
|
|
|
<ol>
|
|
<li><p>Change Table 25 — "<tt>NullablePointer</tt> requirements" in 17.6.3.3 [nullablepointer.requirements]
|
|
as indicated:</p>
|
|
|
|
<table border="1">
|
|
<caption>Table 25 — <tt>NullablePointer</tt> requirements</caption>
|
|
<tr align="center">
|
|
<th>Expression</th>
|
|
<th>Return type</th>
|
|
<th>Operational semantics</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="3" align="center">
|
|
<tt>[…]</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a != b</tt>
|
|
</td>
|
|
<td>
|
|
<del>contextually</del> convertible to <tt>bool</tt>
|
|
</td>
|
|
<td>
|
|
<tt>!(a == b)</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a == np<br/>
|
|
np == a</tt>
|
|
</td>
|
|
<td>
|
|
<del>contextually</del> convertible to <tt>bool</tt>
|
|
</td>
|
|
<td>
|
|
<tt>a == P()</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a != np<br/>
|
|
np != a</tt>
|
|
</td>
|
|
<td>
|
|
<del>contextually</del> convertible to <tt>bool</tt>
|
|
</td>
|
|
<td>
|
|
<tt>!(a == np)</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
|
|
</li>
|
|
|
|
<li><p>Change Table 107 — "Input iterator requirements" in 24.2.3 [input.iterators]
|
|
as indicated:</p>
|
|
|
|
<table border="1">
|
|
<caption>Table 107 — Input iterator requirements (in addition to Iterator)</caption>
|
|
<tr align="center">
|
|
<th>Expression</th>
|
|
<th>Return type</th>
|
|
<th>Operational semantics</th>
|
|
<th>Assertion/note<br/>pre-/post-condition</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a != b</tt>
|
|
</td>
|
|
<td>
|
|
<del>contextually</del> convertible to <tt>bool</tt>
|
|
</td>
|
|
<td>
|
|
<tt>!(a == b)</tt>
|
|
</td>
|
|
<td>
|
|
pre: <tt>(a, b)</tt> is in the domain of <tt>==</tt>.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="4" align="center">
|
|
<tt>[…]</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
|
|
</li>
|
|
|
|
<li><p>Change Table 111 — "Random access iterator requirements" in 24.2.7 [random.access.iterators]
|
|
as indicated:</p>
|
|
|
|
<table border="1">
|
|
<caption>Table 111 — Random access iterator requirements (in addition to bidirectional iterator)</caption>
|
|
<tr align="center">
|
|
<th>Expression</th>
|
|
<th>Return type</th>
|
|
<th>Operational semantics</th>
|
|
<th>Assertion/note<br/>pre-/post-condition</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="4" align="center">
|
|
<tt>[…]</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a < b</tt>
|
|
</td>
|
|
<td>
|
|
<del>contextually</del> convertible to <tt>bool</tt>
|
|
</td>
|
|
<td>
|
|
<tt>b - a > 0</tt>
|
|
</td>
|
|
<td>
|
|
<tt><</tt> is a total ordering relation
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a > b</tt>
|
|
</td>
|
|
<td>
|
|
<del>contextually</del> convertible to <tt>bool</tt>
|
|
</td>
|
|
<td>
|
|
<tt>b < a</tt>
|
|
</td>
|
|
<td>
|
|
<tt>></tt> is a total ordering relation opposite to <tt><</tt>.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a >= b</tt>
|
|
</td>
|
|
<td>
|
|
<del>contextually</del> convertible to <tt>bool</tt>
|
|
</td>
|
|
<td>
|
|
<tt>!(a < b)</tt>
|
|
</td>
|
|
<td>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a <= b</tt>
|
|
</td>
|
|
<td>
|
|
<del>contextually</del> convertible to <tt>bool</tt>
|
|
</td>
|
|
<td>
|
|
<tt>!(a > b)</tt>
|
|
</td>
|
|
<td>
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
|
|
</li>
|
|
|
|
<li><p>Change 25.1 [algorithms.general] p8+9 as indicated:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-8- The <tt>Predicate</tt> parameter is used whenever an algorithm expects a function object
|
|
(20.9 [function.objects]) that, when applied to the result of dereferencing the corresponding iterator,
|
|
returns a value testable as <tt>true</tt>. In other words, if an algorithm takes <tt>Predicate pred</tt>
|
|
as its argument and first as its iterator argument, it should work correctly in the construct
|
|
<tt>pred(*first)</tt> <ins>implicitly or</ins> contextually converted to <tt>bool</tt> (Clause 4 [conv]).
|
|
The function object <tt>pred</tt> shall not apply any non-constant function through the dereferenced iterator.
|
|
<p/>
|
|
-9- The <tt>BinaryPredicate</tt> parameter is used whenever an algorithm expects a function object that when applied
|
|
to the result of dereferencing two corresponding iterators or to dereferencing an iterator and type
|
|
<tt>T</tt> when <tt>T</tt> is part of the signature returns a value testable as <tt>true</tt>. In other words, if an algorithm takes
|
|
<tt>BinaryPredicate binary_pred</tt> as its argument and <tt>first1</tt> and <tt>first2</tt> as its iterator arguments, it should
|
|
work correctly in the construct <tt>binary_pred(*first1, *first2)</tt> <ins>implicitly or</ins> contextually converted to
|
|
<tt>bool</tt> (Clause 4 [conv]).
|
|
<tt>BinaryPredicate</tt> always takes the first iterator's <tt>value_type</tt> as its first argument, that is, in those cases
|
|
when <tt>T</tt> value is part of the signature, it should work correctly in the construct <tt>binary_pred(*first1, value)</tt>
|
|
<ins>implicitly or</ins> contextually converted to <tt>bool</tt> (Clause 4 [conv]). <tt>binary_pred</tt> shall
|
|
not apply any non-constant function through the dereferenced iterators.
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 25.4 [alg.sorting] p2 as indicated:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-2- <tt>Compare</tt> is a function object type (20.9 [function.objects]). The return value of the function
|
|
call operation applied to an object of type <tt>Compare</tt>, when <ins>implicitly or</ins> contextually converted
|
|
to <tt>bool</tt> (4 [conv]), yields <tt>true</tt> if the first argument of the call is less than the second, and
|
|
<tt>false</tt> otherwise. <tt>Compare comp</tt> is used throughout for algorithms assuming an ordering relation. It is assumed
|
|
that <tt>comp</tt> will not apply any non-constant function through the dereferenced iterator.
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 30.2.1 [thread.req.paramname] p2 as indicated:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-2- <del>If a parameter is <tt>Predicate</tt>, operator() applied to the actual template argument shall return a value that
|
|
is convertible to <tt>bool</tt></del><ins><tt>Predicate</tt> is a function object type (20.9 [function.objects]).
|
|
The return value of the function call operation applied to an object of type <tt>Predicate</tt>, when implicitly or
|
|
contextually converted to <tt>bool</tt> (4 [conv]), yields <tt>true</tt> if the corresponding test condition is
|
|
satisfied, and <tt>false</tt> otherwise</ins>.
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
</blockquote>
|
|
|
|
<p><i>[2014-05-20, Daniel suggests concrete wording based on STL's proposal]</i></p>
|
|
|
|
<p>
|
|
The presented wording follows relatively closely STL's outline with the following notable exceptions:
|
|
</p>
|
|
<ol style="list-style-type:upper-alpha">
|
|
<li><p>
|
|
A reference to <tt>BooleanTestable</tt> in table "Return Type" specifications seemed very unusual to me and
|
|
I found no "prior art" for this in the Standard. Instead I decided to follow the usual style to add a symbol
|
|
with a specific meaning to a specific paragraph that specifies symbols and their meanings.
|
|
</p></li>
|
|
<li><p>
|
|
STL's requirement IV suggested to directly refer to built-in operators <tt>&&</tt> and <tt>||</tt>. In my
|
|
opinion this concrete requirement isn't needed if we simply require that two <tt>BooleanTestable</tt> operands behave
|
|
equivalently to two those operands after conversion to <tt>bool</tt> (each of them).
|
|
</p></li>
|
|
<li><p>
|
|
I couldn't find a good reason to require normatively that type <tt>bool</tt> meets the requirements of <tt>BooleanTestable</tt>: My
|
|
assertion is that after having defined them, the result simply falls out of this. But to make this a bit clearer, I added
|
|
also a non-normative note to these effects.
|
|
</p></li>
|
|
</ol>
|
|
|
|
<p><i>[2014-06-10, STL comments]</i></p>
|
|
|
|
<p>
|
|
In the current wording I would like to see changed the suggested changes described by bullet #6:
|
|
</p>
|
|
<ol style="list-style-type:upper-alpha">
|
|
<li><p>In 23.2.1 [container.requirements.general] p4 undo the suggested change</p></li>
|
|
<li><p>Then change the 7 occurrences of "convertible to <tt>bool</tt>" in the denoted tables to "<tt>bool</tt>".</p></li>
|
|
</ol>
|
|
|
|
<p><i>[2015-05-05 Lenexa]</i></p>
|
|
|
|
<p>STL: Alisdair wanted to do something here, but Daniel gave us updated wording.</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 17.6.3.1 [utility.arg.requirements] p1, Table 17 — "EqualityComparable requirements", and
|
|
Table 18 — "LessThanComparable requirements" as indicated:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-1- […] In these tables, <tt>T</tt> is an object or reference type to be supplied by a C++ program
|
|
instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are values of type (possibly <tt>const</tt>) <tt>T</tt>;
|
|
<tt>s</tt> and <tt>t</tt> are modifiable lvalues of type <tt>T</tt>; <tt>u</tt> denotes an identifier; <tt>rv</tt>
|
|
is an rvalue of type <tt>T</tt>; <del>and</del> <tt>v</tt> is an lvalue of type (possibly <tt>const</tt>) <tt>T</tt> or an
|
|
rvalue of type <tt>const T</tt><ins>; and <tt>BT</tt> denotes a type that meets the <tt>BooleanTestable</tt>
|
|
requirements ([booleantestable.requirements])</ins>.
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 17 — <tt>EqualityComparable</tt> requirements [equalitycomparable]</caption>
|
|
<tr>
|
|
<th align="center">Expression</th>
|
|
<th align="center">Return type</th>
|
|
<th align="center">Requirement</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a == b</tt>
|
|
</td>
|
|
<td>
|
|
<del>convertible to<br/>
|
|
<tt>bool</tt></del><ins><tt>BT</tt></ins>
|
|
</td>
|
|
<td>
|
|
<tt>==</tt> is an equivalence relation, that is, it has the
|
|
following properties: […]
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote>
|
|
<p>
|
|
[…]
|
|
</p>
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 18 — <tt>LessThanComparable</tt> requirements [lessthancomparable]</caption>
|
|
<tr>
|
|
<th align="center">Expression</th>
|
|
<th align="center">Return type</th>
|
|
<th align="center">Requirement</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a < b</tt>
|
|
</td>
|
|
<td>
|
|
<del>convertible to<br/>
|
|
<tt>bool</tt></del><ins><tt>BT</tt></ins>
|
|
</td>
|
|
<td>
|
|
<tt><</tt> is a strict weak ordering relation (25.4 [alg.sorting])
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote>
|
|
|
|
</blockquote>
|
|
|
|
</li>
|
|
|
|
<li><p>Between 17.6.3.2 [swappable.requirements] and 17.6.3.3 [nullablepointer.requirements] insert a new sub-clause
|
|
as indicated:</p>
|
|
|
|
<blockquote>
|
|
?.?.?.? <b><tt>BooleanTestable</tt> requirements [booleantestable.requirements]</b>
|
|
<blockquote>
|
|
<p>
|
|
-?- A <tt>BooleanTestable</tt> type is a boolean-like type that also supports conversions to <tt>bool</tt>.
|
|
A type <tt>B</tt> meets the <tt>BooleanTestable</tt> requirements if the expressions described in Table ?? are valid
|
|
and have the indicated semantics, and if <tt>B</tt> also satisfies all the other requirements of this sub-clause
|
|
[booleantestable.requirements].
|
|
<p/>
|
|
An object <tt>b</tt> of type <tt>B</tt> can be implicitly converted to <tt>bool</tt> and can be contextually converted
|
|
to <tt>bool</tt> (Clause 4). The result values of both kinds of conversions shall be equivalent.
|
|
<p/>
|
|
[<i>Example</i>: The types <tt>bool</tt>, <tt>std::true_type</tt>, and <tt>std::bitset<>::reference</tt> are
|
|
<tt>BooleanTestable</tt> types. — <i>end example</i>]
|
|
<p/>
|
|
In Table ??, <tt>B2</tt> and <tt>Bn</tt> denote types (possibly equal to <tt>B</tt> or to each other) that meet the
|
|
<tt>BooleanTestable</tt> requirements, <tt>b1</tt> denotes a (possibly <tt>const</tt>) value of <tt>B</tt>, <tt>b2</tt>
|
|
denotes a (possibly <tt>const</tt>) value of <tt>B2</tt>, and <tt>t1</tt> denotes a value of type <tt>bool</tt>.
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Somewhere within the new sub-clause [booleantestable.requirements] insert the following new Table (?? denotes
|
|
the assigned table number):</p>
|
|
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table ?? — <tt>BooleanTestable</tt> requirements [booleantestable]</caption>
|
|
<tr>
|
|
<th align="center">Expression</th>
|
|
<th align="center">Return type</th>
|
|
<th align="center">Operational semantics</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>bool(b1)</tt>
|
|
</td>
|
|
<td>
|
|
<tt>bool</tt>
|
|
</td>
|
|
<td>
|
|
<i>Remarks</i>: <tt>bool(b1) == t1</tt> for every value<br/>
|
|
<tt>b1</tt> implicitly converted to <tt>t1</tt>.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>!b1</tt>
|
|
</td>
|
|
<td>
|
|
<tt>Bn</tt>
|
|
</td>
|
|
<td>
|
|
<i>Remarks</i>: <tt>bool(b1) == !bool(!b1)</tt> for<br/>
|
|
every value <tt>b1</tt>.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>b1 && b2</tt>
|
|
</td>
|
|
<td>
|
|
<tt>bool</tt>
|
|
</td>
|
|
<td>
|
|
<tt>bool(b1) && bool(b2)</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>b1 || b2</tt>
|
|
</td>
|
|
<td>
|
|
<tt>bool</tt>
|
|
</td>
|
|
<td>
|
|
<tt>bool(b1) || bool(b2)</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote>
|
|
|
|
</li>
|
|
|
|
<li><p>Change 17.6.3.3 [nullablepointer.requirements] p5 and Table 25 — "NullablePointer requirements" as indicated:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
[…]
|
|
<p/>
|
|
-5- In Table 25, <tt>u</tt> denotes an identifier, <tt>t</tt> denotes a non-<tt>const</tt> lvalue of type <tt>P</tt>, <tt>a</tt>
|
|
and <tt>b</tt> denote values of type (possibly <tt>const</tt>) <tt>P</tt>, <del>and</del> <tt>np</tt> denotes a value of type
|
|
(possibly <tt>const</tt>) <tt>std::nullptr_t</tt><ins>, and <tt>BT</tt> denotes a type that meets the <tt>BooleanTestable</tt>
|
|
requirements ([booleantestable.requirements])</ins>.
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 25 — <tt>NullablePointer</tt> requirements [nullablepointer]</caption>
|
|
<tr>
|
|
<th align="center">Expression</th>
|
|
<th align="center">Return type</th>
|
|
<th align="center">Operational semantics</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="3" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a != b</tt>
|
|
</td>
|
|
<td>
|
|
<del>contextually convertible to <tt>bool</tt></del><ins><tt>BT</tt></ins>
|
|
</td>
|
|
<td>
|
|
[…]
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a == np</tt><br/>
|
|
<tt>np == a</tt>
|
|
</td>
|
|
<td>
|
|
<del>contextually convertible to <tt>bool</tt></del><ins><tt>BT</tt></ins>
|
|
</td>
|
|
<td>
|
|
[…]
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a != np</tt><br/>
|
|
<tt>np != a</tt>
|
|
</td>
|
|
<td>
|
|
<del>contextually convertible to <tt>bool</tt></del><ins><tt>BT</tt></ins>
|
|
</td>
|
|
<td>
|
|
[…]
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 20.4.2.7 [tuple.rel] as indicated;</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
template<class... TTypes, class... UTypes>
|
|
constexpr bool operator==(const tuple<TTypes...>& t, const tuple<UTypes...>& u);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-1- <i>Requires</i>: For all <tt>i</tt>, where <tt>0 <= i</tt> and <tt>i < sizeof...(TTypes)</tt>,
|
|
<tt>get<i>(t) == get<i>(u)</tt> is a valid expression returning a type that <del>is convertible to
|
|
<tt>bool</tt></del><ins>meets the <tt>BooleanTestable</tt> requirements ([booleantestable.requirements])</ins>.
|
|
<tt>sizeof...(TTypes) == sizeof...(UTypes)</tt>.
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
</blockquote>
|
|
<pre>
|
|
template<class... TTypes, class... UTypes>
|
|
constexpr bool operator<(const tuple<TTypes...>& t, const tuple<UTypes...>& u);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-4- <i>Requires</i>: For all <tt>i</tt>, where <tt>0 <= i</tt> and <tt>i < sizeof...(TTypes)</tt>,
|
|
<tt>get<i>(t) < get<i>(u)</tt> and <tt>get<i>(u) < get<i>(t)</tt> are valid
|
|
expressions returning types that <del>are convertible to
|
|
<tt>bool</tt></del><ins>meet the <tt>BooleanTestable</tt> requirements ([booleantestable.requirements])</ins>.
|
|
<tt>sizeof...(TTypes) == sizeof...(UTypes)</tt>.
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 23.2.1 [container.requirements.general], Table 96 — "Container requirements", and
|
|
Table 98 — "Optional container operations" as indicated:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-4- In Tables 96, 97, and 98 <tt>X</tt> denotes a container class containing objects of type <tt>T</tt>, <tt>a</tt> and
|
|
<tt>b</tt> denote values of type <tt>X</tt>, <tt>u</tt> denotes an identifier, <tt>r</tt> denotes a non-<tt>const</tt> value
|
|
of type <tt>X</tt>, <del>and</del> <tt>rv</tt> denotes a non-<tt>const</tt> rvalue of type <tt>X</tt><ins>, and <tt>BT</tt>
|
|
denotes a type that meets the <tt>BooleanTestable</tt> requirements ([booleantestable.requirements])</ins>.
|
|
</p>
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 96 — Container requirements</caption>
|
|
<tr>
|
|
<th align="center">Expression</th>
|
|
<th align="center">Return type</th>
|
|
<th align="center">[…]</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="3" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a == b</tt>
|
|
</td>
|
|
<td>
|
|
<del>convertible to<br/>
|
|
<tt>bool</tt></del><ins><tt>BT</tt></ins>
|
|
</td>
|
|
<td>
|
|
[…]
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a != b</tt>
|
|
</td>
|
|
<td>
|
|
<del>convertible to<br/>
|
|
<tt>bool</tt></del><ins><tt>BT</tt></ins>
|
|
</td>
|
|
<td>
|
|
[…]
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="3" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a.empty()</tt>
|
|
</td>
|
|
<td>
|
|
<del>convertible to<br/>
|
|
<tt>bool</tt></del><ins><tt>BT</tt></ins>
|
|
</td>
|
|
<td>
|
|
[…]
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote>
|
|
<p>
|
|
[…]
|
|
</p>
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 98 — Optional container requirements</caption>
|
|
<tr>
|
|
<th align="center">Expression</th>
|
|
<th align="center">Return type</th>
|
|
<th align="center">[…]</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="3" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a < b</tt>
|
|
</td>
|
|
<td>
|
|
<del>convertible to<br/>
|
|
<tt>bool</tt></del><ins><tt>BT</tt></ins>
|
|
</td>
|
|
<td>
|
|
[…]
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a > b</tt>
|
|
</td>
|
|
<td>
|
|
<del>convertible to<br/>
|
|
<tt>bool</tt></del><ins><tt>BT</tt></ins>
|
|
</td>
|
|
<td>
|
|
[…]
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a <= b</tt>
|
|
</td>
|
|
<td>
|
|
<del>convertible to<br/>
|
|
<tt>bool</tt></del><ins><tt>BT</tt></ins>
|
|
</td>
|
|
<td>
|
|
[…]
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a >= b</tt>
|
|
</td>
|
|
<td>
|
|
<del>convertible to<br/>
|
|
<tt>bool</tt></del><ins><tt>BT</tt></ins>
|
|
</td>
|
|
<td>
|
|
[…]
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 24.2.1 [iterator.requirements.general], Table 107 — "Input iterator requirements", and
|
|
Table 111 — "Random access iterator requirements" as indicated:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-11- In the following sections, <tt>a</tt> and <tt>b</tt> denote values of type <tt>X</tt> or <tt>const X</tt>,
|
|
<tt>difference_type</tt> and <tt>reference</tt> refer to the types <tt>iterator_traits<X>::difference_type</tt> and
|
|
<tt>iterator_traits<X>::reference</tt>, respectively, <tt>n</tt> denotes a value of <tt>difference_type</tt>, <tt>u</tt>,
|
|
<tt>tmp</tt>, and <tt>m</tt> denote identifiers, <tt>r</tt> denotes a value of <tt>X&</tt>, <tt>t</tt> denotes
|
|
a value of value type <tt>T</tt>, <tt>o</tt> denotes a value of some type that is writable to the output iterator<ins>, and <tt>BT</tt>
|
|
denotes a type that meets the <tt>BooleanTestable</tt> requirements ([booleantestable.requirements])</ins>.
|
|
</p>
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 107 — Input iterator requirements</caption>
|
|
<tr>
|
|
<th align="center">Expression</th>
|
|
<th align="center">Return type</th>
|
|
<th align="center">[…]</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a != b</tt>
|
|
</td>
|
|
<td>
|
|
<del>contextually convertible to<br/>
|
|
<tt>bool</tt></del><ins><tt>BT</tt></ins>
|
|
</td>
|
|
<td>
|
|
[…]
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
</blockquote>
|
|
<p>
|
|
[…]
|
|
</p>
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 111 — Random access iterator requirements</caption>
|
|
<tr>
|
|
<th align="center">Expression</th>
|
|
<th align="center">Return type</th>
|
|
<th align="center">[…]</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="3" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a < b</tt>
|
|
</td>
|
|
<td>
|
|
<del>contextually convertible to<br/>
|
|
<tt>bool</tt></del><ins><tt>BT</tt></ins>
|
|
</td>
|
|
<td>
|
|
[…]
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a > b</tt>
|
|
</td>
|
|
<td>
|
|
<del>contextually convertible to<br/>
|
|
<tt>bool</tt></del><ins><tt>BT</tt></ins>
|
|
</td>
|
|
<td>
|
|
[…]
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a >= b</tt>
|
|
</td>
|
|
<td>
|
|
<del>contextually convertible to<br/>
|
|
<tt>bool</tt></del><ins><tt>BT</tt></ins>
|
|
</td>
|
|
<td>
|
|
[…]
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a <= b</tt>
|
|
</td>
|
|
<td>
|
|
<del>contextually convertible to<br/>
|
|
<tt>bool</tt></del><ins><tt>BT</tt></ins>
|
|
</td>
|
|
<td>
|
|
[…]
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 25.1 [algorithms.general] p8+p9 as indicated: [<i>Drafting note</i>: The wording change also fixes
|
|
(a) unusual wording forms used ("should work") which are unclear in which sense they are imposing normative requirements and
|
|
(b) the problem, that the current wording seems to allow that the predicate may mutate a call argument, if that is not a
|
|
dereferenced iterator.
|
|
Upon applying the new wording it became obvious that the wording has the effect that currently algorithms such as
|
|
<tt>adjacent_find</tt>, <tt>search_n</tt>, <tt>unique</tt>, and <tt>unique_copy</tt> are not correctly described
|
|
(because they have no iterator argument named <tt>first1</tt>), which could give raise to a new library issue.
|
|
— <i>end drafting note</i>]</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-8- The <tt>Predicate</tt> parameter is used whenever an algorithm expects a function object (20.9) that, when applied
|
|
to the result of dereferencing the corresponding iterator, returns a value testable as <tt>true</tt>. <del>In other words,
|
|
i</del><ins>I</ins>f an algorithm takes <tt>Predicate pred</tt> as its argument and <tt>first</tt> as its iterator argument,
|
|
<del>it should work correctly in the construct <tt>pred(*first)</tt> contextually converted to
|
|
<tt>bool</tt> (Clause 4)</del><ins>the expression <tt>pred(*first)</tt> shall have a type that meets the <tt>BooleanTestable</tt>
|
|
requirements ( [booleantestable.requirements])</ins>.
|
|
The function object <tt>pred</tt> shall not apply any non-constant function through <del>the dereferenced
|
|
iterator</del><ins>its argument</ins>.
|
|
<p/>
|
|
-9- The <tt>BinaryPredicate</tt> parameter is used whenever an algorithm expects a function object that when applied
|
|
to the result of dereferencing two corresponding iterators or to dereferencing an iterator and type
|
|
<tt>T</tt> when <tt>T</tt> is part of the signature returns a value testable as <tt>true</tt>. <del>In other words,
|
|
i</del><ins>I</ins>f an algorithm takes <tt>BinaryPredicate binary_pred</tt> as its argument and <tt>first1</tt> and
|
|
<tt>first2</tt> as its iterator arguments, <del>it should work correctly in the construct <tt>binary_pred(*first1, *first2)</tt>
|
|
contextually converted to <tt>bool</tt> (Clause 4)</del><ins>the expression <tt>binary_pred(*first1, *first2)</tt> shall
|
|
have a type that meets the <tt>BooleanTestable</tt> requirements ( [booleantestable.requirements])</ins>.
|
|
<tt>BinaryPredicate</tt> always takes the first iterator's <tt>value_type</tt> as its first argument, that is, in those cases
|
|
when <tt>T</tt> value is part of the signature, <del>it should work correctly in the construct <tt>binary_pred(*first1, value)</tt>
|
|
contextually converted to <tt>bool</tt> (Clause 4)</del><ins>the expression <tt>binary_pred(*first1, value)</tt> shall have a
|
|
type that meets the <tt>BooleanTestable</tt> requirements ( [booleantestable.requirements])</ins>. <tt>binary_pred</tt>
|
|
shall not apply any non-constant function through <del>the dereferenced iterators</del><ins>any of its arguments</ins>.
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 25.4 [alg.sorting] p2 as indicated:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
[…]
|
|
<p/>
|
|
-2- <tt>Compare</tt> is a function object type (20.9). <del>The return value of the function call
|
|
operation applied to an object of type <tt>Compare</tt>, when contextually converted
|
|
to <tt>bool</tt>(Clause 4), yields <tt>true</tt> if the first argument of the call is less than the second,
|
|
and <tt>false</tt> otherwise.</del> <tt>Compare comp</tt> is used throughout for algorithms assuming an ordering relation.
|
|
<ins>Let <tt>a</tt> and <tt>b</tt> denote two argument values whose types depend on the corresponding algorithm. Then the expression
|
|
<tt>comp(a, b)</tt> shall have a type that meets the <tt>BooleanTestable</tt> requirements ( [booleantestable.requirements]).
|
|
The return value of <tt>comp(a, b)</tt>, converted to <tt>bool</tt>, yields <tt>true</tt> if the
|
|
first argument <tt>a</tt> is less than the second argument <tt>b</tt>, and <tt>false</tt> otherwise.</ins> It is assumed that
|
|
<tt>comp</tt> will not apply any non-constant function through <del>the dereferenced iterator</del><ins>any of its arguments</ins>.
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 27.5.4.2 [fpos.operations] and Table 127 — "Position type requirements" as indicated:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-1- Operations specified in Table 127 are permitted. In that table,
|
|
</p>
|
|
<ul>
|
|
<li><p><tt>P</tt> refers to an instance of <tt>fpos</tt>,</p></li>
|
|
<li><p>[…]</p></li>
|
|
<li><p><tt>o</tt> refers to a value of type <tt>streamoff</tt>,</p></li>
|
|
<li><p><ins><tt>BT</tt> refers to a type that meets the <tt>BooleanTestable</tt> requirements ([booleantestable.requirements]),</ins></p></li>
|
|
<li><p>[…]</p></li>
|
|
</ul>
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 127 — Position type requirements</caption>
|
|
<tr>
|
|
<th align="center">Expression</th>
|
|
<th align="center">Return type</th>
|
|
<th align="center">[…]</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="3" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>p == q</tt>
|
|
</td>
|
|
<td>
|
|
<del>convertible to <tt>bool</tt></del><ins><tt>BT</tt></ins>
|
|
</td>
|
|
<td>
|
|
[…]
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>p != q</tt>
|
|
</td>
|
|
<td>
|
|
<del>convertible to <tt>bool</tt></del><ins><tt>BT</tt></ins>
|
|
</td>
|
|
<td>
|
|
[…]
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote>
|
|
</blockquote>
|
|
<blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 30.2.1 [thread.req.paramname] p2 as indicated:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-2- <del>If a parameter is <tt>Predicate</tt>, <tt>operator()</tt> applied to the actual template argument shall return a value that
|
|
is convertible to <tt>bool</tt></del><ins><tt>Predicate</tt> is a function object type (20.9 [function.objects]).
|
|
Let <tt>pred</tt> denote an lvalue of type <tt>Predicate</tt>. Then the expression <tt>pred()</tt> shall have a type that meets the
|
|
<tt>BooleanTestable</tt> requirements ( [booleantestable.requirements]). The return value of <tt>pred()</tt>,
|
|
converted to <tt>bool</tt>, yields <tt>true</tt> if the corresponding test condition is satisfied, and <tt>false</tt> otherwise</ins>.
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2115"></a>2115. Undefined behaviour for <tt>valarray</tt> assignments with <tt>mask_array</tt> index?</h3>
|
|
<p><b>Section:</b> 26.6.8 [template.mask.array] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Thomas Plum <b>Opened:</b> 2011-12-10 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
Recently I received a Service Request (SR) alleging that one of our testcases causes an
|
|
undefined behavior. The complaint is that 26.6.8 [template.mask.array] in C++11
|
|
(and the corresponding subclause in C++03) are interpreted by some people to require that
|
|
in an assignment "<tt>a[mask] = b</tt>", the subscript <tt>mask</tt> and the rhs <tt>b</tt>
|
|
must have the same number of elements.
|
|
<p/>
|
|
IMHO, if that is the intended requirement, it should be stated explicitly.
|
|
<p/>
|
|
In any event, there is a tiny editorial cleanup that could be made:
|
|
<p/>
|
|
In C++11, 26.6.8.1 [template.mask.array.overview] para 2 mentions
|
|
</p>
|
|
<blockquote><p>
|
|
"the expression <tt>a[mask] = b;</tt>"
|
|
</p></blockquote>
|
|
<p>
|
|
but the semicolon cannot be part of an expression. The correction could omit the
|
|
semicolon, or change the word "expression" to "assignment" or "statement".
|
|
<p/>
|
|
Here is the text of the SR, slightly modified for publication:
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
Subject: SR01174 LVS _26322Y31 has undefined behavior [open]
|
|
<p/>
|
|
[Client:]<br/>
|
|
The test case t263.dir/_26322Y31.cpp seems to be illegal as it has an undefined
|
|
behaviour. I searched into the SRs but found SRs were not related to the topic
|
|
explained in this mail (SR00324, SR00595, SR00838).
|
|
</p>
|
|
<blockquote><pre>
|
|
const char vl[] = {"abcdefghijklmnopqrstuvwxyz"};
|
|
const char vu[] = {"ABCDEFGHIJKLMNOPQRSTUVWXYZ"};
|
|
const std::valarray<char> v0(vl, 27), vm5(vu, 5), vm6(vu, 6);
|
|
std::valarray<char> x = v0;
|
|
[…]
|
|
const bool vb[] = {false, false, true, true, false, true};
|
|
const std::valarray<bool> vmask(vb, 6);
|
|
x = v0;
|
|
x[vmask] = vm5; // ***** HERE....
|
|
steq(&x[0], "abABeCghijklmnopqrstuvwxyz");
|
|
x2 = x[vmask]; // ***** ....AND HERE
|
|
[…]
|
|
</pre></blockquote>
|
|
<p>
|
|
This problem has already been discussed between [experts]:
|
|
See thread <a href="http://gcc.gnu.org/ml/libstdc++/2009-11/threads.html#00051">http://gcc.gnu.org/ml/libstdc++/2009-11/threads.html#00051</a>
|
|
Conclusion <a href="http://gcc.gnu.org/ml/libstdc++/2009-11/msg00099.html">http://gcc.gnu.org/ml/libstdc++/2009-11/msg00099.html</a>
|
|
<p/>
|
|
[Plum Hall:]<br/>
|
|
Before I log this as an SR, I need to check one detail with you.
|
|
<p/>
|
|
I did read the email thread you mentioned, and I did find a citation (see INCITS ISO/IEC 14882-2003
|
|
Section 26.3.2.6 on valarray computed assignments):
|
|
<p/>
|
|
Quote: "If the array and the argument array do not have the same length, the behavior is undefined",
|
|
<p/>
|
|
But this applies to computed assignment (<tt>*=</tt>, <tt>+=</tt>, etc), not to simple assignment. Here is the C++03 citation
|
|
re simple assignment:
|
|
<p/>
|
|
26.3.2.2 valarray assignment [lib.valarray.assign]
|
|
</p>
|
|
<blockquote><pre>
|
|
valarray<T>& operator=(const valarray<T>&);
|
|
</pre><blockquote>
|
|
<p>
|
|
1 Each element of the <tt>*this</tt> array is assigned the value of the corresponding element of the argument array.
|
|
The resulting behavior is undefined if the length of the argument array is not equal to the length of the
|
|
<tt>*this</tt> array.
|
|
</p>
|
|
</blockquote></blockquote>
|
|
<p>
|
|
In the new C++11 (N3291), we find ...
|
|
<p/>
|
|
26.6.2.3 valarray assignment [valarray.assign]
|
|
</p>
|
|
<blockquote><pre>
|
|
valarray<T>& operator=(const valarray<T>& v);
|
|
</pre><blockquote>
|
|
<p>
|
|
1 Each element of the <tt>*this</tt> array is assigned the value of the corresponding element of the argument
|
|
array. If the length of <tt>v</tt> is not equal to the length of <tt>*this</tt>, resizes <tt>*this</tt> to make
|
|
the two arrays the same length, as if by calling <tt>resize(v.size())</tt>, before performing the assignment.
|
|
</p>
|
|
</blockquote></blockquote>
|
|
<p>
|
|
So it looks like the testcase might be valid for C++11 but not for C++03; what do you think?
|
|
<p/>
|
|
[Client:]<br/>
|
|
I quite agree with you but the two problems I mentioned:
|
|
</p>
|
|
<blockquote><pre>
|
|
x[vmask] = vm5; // ***** HERE....
|
|
[…]
|
|
x2 = x[vmask]; // ***** ....AND HERE
|
|
</pre></blockquote>
|
|
<p>
|
|
refer to <tt>mask_array</tt> assignment hence target the C++03 26.3.8 paragraph. Correct?
|
|
<p/>
|
|
[Plum Hall:]<br/>
|
|
I mentioned the contrast between C++03 26.3.2.2 para 1 versus C++11 26.6.2.3 para 1.
|
|
<p/>
|
|
But in C++03 26.3.8, I don't find any corresponding restriction. Could you quote the specific
|
|
requirement you're writing about?
|
|
<p/>
|
|
[Client:]<br/>
|
|
I do notice the difference between c++03 26.3.2.2 and c++11 26.6.2.3 about assignments between
|
|
different sized <tt>valarray</tt> and I perfectly agree with you.
|
|
<p/>
|
|
But, as already stated, this is not a simple <tt>valarray</tt> assignment but a
|
|
<tt>mask_array</tt> assignment (c++03 26.3.8 / c++11 26.6.8). See c++11 quote below:
|
|
<p/>
|
|
26.6.8 Class template mask_array<br/>
|
|
26.6.8.1 Class template mask_array overview<br/>
|
|
[....]
|
|
</p>
|
|
<ol>
|
|
<li><p>This template is a helper template used by the mask subscript operator:
|
|
<tt>mask_array<T> valarray<T>::operator[](const valarray<bool>&)</tt>.
|
|
</p></li>
|
|
<li><p>It has reference semantics to a subset of an array specified by a boolean mask. Thus,
|
|
the expression <tt>a[mask] = b;</tt> has the effect of assigning <em>the elements of <tt>b</tt></em>
|
|
to the masked elements in <tt>a</tt> (those for which the corresponding element in <tt>mask</tt> is true.)
|
|
</p></li>
|
|
</ol>
|
|
<p>
|
|
26.6.8.2 mask_array assignment
|
|
</p>
|
|
<blockquote><pre>
|
|
void operator=(const valarray<T>&) const;
|
|
const mask_array& operator=(const mask_array&) const;
|
|
</pre><blockquote>
|
|
<p>
|
|
1 These assignment operators have reference semantics, assigning the values of the argument array
|
|
elements to selected elements of the <tt>valarray<T></tt> object to which it refers.
|
|
</p>
|
|
</blockquote></blockquote>
|
|
<p>
|
|
In particular, [one of the WG21 experts] insisted on the piece "the elements of <tt>b</tt>".
|
|
<p/>
|
|
That is why I reported the test t263.dir/_26322Y31.cpp having an undefined behaviour.
|
|
<p/>
|
|
[Plum Hall:]<br/>
|
|
OK, I can see that I will have to ask WG21; I will file an appropriate issue
|
|
with the Library subgroup. In the meantime, I will mark this testcase as "DISPUTED"
|
|
so that it is not required for conformance testing, until we get a definitive opinion.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p><i>[2012, Kona]</i></p>
|
|
|
|
<p>
|
|
Moved to Open.
|
|
</p>
|
|
<p>
|
|
There appears to be a real need for clarification in the standard, and
|
|
implementations differ in their current interpretation. This will need
|
|
some research by implementers and a proposed resolution before further
|
|
discussion is likely to be fruitful.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2116"></a>2116. <tt>std::swap noexcept(what?)</tt></h3>
|
|
<p><b>Section:</b> 20.10.4.3 [meta.unary.prop] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2011-12-09 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
IMO if we specified <tt>is_[nothrow_]constructible</tt> in terms of a variable
|
|
declaration whose validity requires destructibility, it is clearly a bug
|
|
in our specification and a failure to realize the actual original
|
|
intent. The specification should have been in terms of placement-new.
|
|
<p/>
|
|
Daniel:<br/>
|
|
At the time of the specification this was intended and the solution is
|
|
<em>not</em> done by removing the destruction semantics of <tt>is_constructible</tt>.
|
|
<p/>
|
|
The design of <tt>is_constructible</tt> was also impacted by the previous
|
|
<tt>Constructible</tt> concept that <em>explicitly</em> contained destruction semantics,
|
|
because during conceptification of the library it turned out to simplify
|
|
the constraints in the library because you did not need to add
|
|
<tt>Destructible</tt> all the time. It often was implied but never spoken out
|
|
in C++03.
|
|
<p/>
|
|
Pure construction semantics was considered as useful as well, so <tt>HasConstructor</tt>
|
|
did also exist and would surely be useful as trait as well.
|
|
<p/>
|
|
Another example that is often overlooked: This also affects wrapper types like <tt>pair</tt>,
|
|
<tt>tuple</tt>, <tt>array</tt> that contain potentially more than one type:
|
|
This is easy to understand if you think of <tt>T1</tt> having a deleted destructor
|
|
and <tt>T2</tt> having a constructor that may throw: Obviously the compiler has
|
|
potentially need to use the <tt>destructor</tt> of <tt>T1</tt> in the <em>constructor</em>
|
|
of <tt>std::pair<T1, T2></tt> to ensure that the core language requirements
|
|
are satisfied (All previous fully constructed sub-objects must be destructed).
|
|
<p/>
|
|
The core language also honors this fact in 12.8 [class.copy] p11:
|
|
</p>
|
|
<blockquote><p>
|
|
A defaulted copy/move constructor for a class <tt>X</tt> is defined as deleted (8.4.3 [dcl.fct.def.delete])
|
|
if <tt>X</tt> has:<br/>
|
|
[…]<br/>
|
|
— any direct or virtual base class or non-static data member of a type with a destructor that is deleted
|
|
or inaccessible from the defaulted constructor,<br/>
|
|
[…]
|
|
</p></blockquote>
|
|
<p>
|
|
Dave:<br/>
|
|
This is about <tt>is_nothrow_constructible</tt> in particular. The fact that it is
|
|
foiled by not having a <tt>noexcept</tt> dtor is a defect.
|
|
</p>
|
|
|
|
<p><i>[2012, Kona]</i></p>
|
|
|
|
<p>
|
|
Move to Open.
|
|
</p>
|
|
<p>
|
|
<tt>is_nothrow_constructible</tt> is defined in terms of <tt>is_constructible</tt>, which is defined
|
|
by looking at a hypothetical variable and asking whether the variable definition is known not to
|
|
throw exceptions. The issue claims that this also examines the type's destructor, given the context,
|
|
and thus will return <tt>false</tt> if the destructor can potentially throw. At least one
|
|
implementation (Howard's) does return <tt>false</tt> if the constructor is <tt>noexcept(true)</tt>
|
|
and the destructor is <tt>noexcept(false)</tt>. So that's not a strained interpretation.
|
|
The issue is asking for this to be defined in terms of placement <tt>new</tt>, instead of in terms
|
|
of a temporary object, to make it clearer that <tt>is_nothrow_constructible</tt> looks at the
|
|
<tt>noexcept</tt> status of only the constructor, and not the destructor.
|
|
</p>
|
|
<p>
|
|
Sketch of what the wording would look like:
|
|
</p>
|
|
<p>
|
|
require <tt>is_constructible</tt>, and then also require that a placement <tt>new</tt> operation
|
|
does not throw. (Remembering the title of this issue... What does this imply for <tt>swap</tt>?
|
|
</p>
|
|
<p>
|
|
If we accept this resolution, do we need any changes to <tt>swap</tt>?
|
|
</p>
|
|
<p> STL argues: no, because you are already forbidden from passing anything with a throwing
|
|
desturctor to <tt>swap</tt>.
|
|
</p>
|
|
<p>
|
|
Dietmar argues: no, not true. Maybe statically the destructor can conceivably throw for some
|
|
values, but maybe there are some values known not to throw. In that case, it's correct to
|
|
pass those values to <tt>swap</tt>.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2117"></a>2117. <tt>ios_base</tt> manipulators should have <tt>showgrouping/noshowgrouping</tt></h3>
|
|
<p><b>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals], 27.5.3.1.2 [ios::fmtflags], 27.5.6.1 [fmtflags.manip] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Benjamin Kosnik <b>Opened:</b> 2011-12-15 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#facet.num.put.virtuals">issues</a> in [facet.num.put.virtuals].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
Iostreams should include a manipulator to toggle grouping on/off for
|
|
locales that support grouped digits. This has come up repeatedly and
|
|
been deferred. See LWG <a href="lwg-closed.html#826">826</a> for the previous attempt.
|
|
<p/>
|
|
If one is using a locale that supports grouped digits, then output
|
|
will always include the generated grouping characters. However, very
|
|
plausible scenarios exist where one might want to output the number,
|
|
un-grouped. This is similar to existing manipulators that toggle
|
|
on/off the decimal point, numeric base, or positive sign.
|
|
<p/>
|
|
See some user commentary <a href="http://www.tablix.org/~avian/blog/archives/2008/01/c_streams_suck/">here</a>.
|
|
</p>
|
|
|
|
|
|
<p><i>[21012, Kona]</i></p>
|
|
|
|
<p>
|
|
Move to Open.
|
|
</p>
|
|
<p>
|
|
This is a feature request.
|
|
</p>
|
|
<p>
|
|
Walter is slightly uncomfortable with processing feature requests through the issues lists.
|
|
</p>
|
|
<p>
|
|
Alisdair says this is far from the first feature request that has come in from the issues list.
|
|
</p>
|
|
<p>
|
|
STL: The fact that you can turn off grouping on hex output is compelling.
|
|
</p>
|
|
<p>
|
|
Marshall: if we add this flag, we'll need to update tables 87-91 as well.
|
|
</p>
|
|
<p>
|
|
STL: If it has been implemented somewhere, and it works, we'd be glad to add it.
|
|
</p>
|
|
<p>
|
|
Howard: We need to say what the default is.
|
|
</p>
|
|
<p>
|
|
Alisdair sumarizes:
|
|
</p>
|
|
<p>
|
|
(1) We want clear wording that says what the effect is of turning the flag off;
|
|
</p>
|
|
<p>
|
|
(2) what the default values are, and
|
|
</p>
|
|
<p>
|
|
(3) how this fits into tables 87-90. (and 128)
|
|
</p>
|
|
|
|
<p><i>[Issaquah 2014-02-10-12: Move to LEWG]</i></p>
|
|
|
|
<p>
|
|
Since this issue was filed, we have grown a new working group that is better placed to handle feature requests.
|
|
</p>
|
|
<p>
|
|
We will track such issues with an LEWG status until we get feedback from the Library Evolution Working Group.
|
|
</p>
|
|
|
|
<p><i>[Issaquah 2014-02-12: LEWG discussion]</i></p>
|
|
|
|
|
|
<table>
|
|
<caption>Do we think this feature should exist?</caption>
|
|
<tr><td>SF</td><td>F</td><td>N</td><td>A</td><td>SA</td></tr>
|
|
<tr><td>2</td> <td>4</td><td>1</td><td>0</td><td>0</td></tr>
|
|
</table>
|
|
|
|
<p>Think about the ABI break for adding a flag. But this could be
|
|
mitigated by putting the data into an iword instead of a flag.</p>
|
|
|
|
<p>This needs to change Stage 2 in [facet.num.put.virtuals].</p>
|
|
|
|
<p>Previous resolution, which needs the above corrections:</p>
|
|
<blockquote class="note">
|
|
<p>This wording is relative to the FDIS.</p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>Insert in 22.4.2.2.2 [facet.num.put.virtuals] paragraph 5:</p>
|
|
|
|
<blockquote><p>
|
|
<strong>Stage 1</strong>: The first action of stage 1 is to determine a conversion specifier. The tables that describe
|
|
this determination use the following local variables
|
|
</p>
|
|
<pre>
|
|
fmtflags flags = str.flags() ;
|
|
fmtflags basefield = (flags & (ios_base::basefield));
|
|
fmtflags uppercase = (flags & (ios_base::uppercase));
|
|
fmtflags floatfield = (flags & (ios_base::floatfield));
|
|
fmtflags showpos = (flags & (ios_base::showpos));
|
|
fmtflags showbase = (flags & (ios_base::showbase));
|
|
<ins>fmtflags showgrouping = (flags & (ios_base::showgrouping));</ins>
|
|
</pre>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change header <tt><ios></tt> synopsis, 27.5.1 [iostreams.base.overview] as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
#include <iosfwd>
|
|
|
|
namespace std {
|
|
[…]
|
|
<i>// 27.5.6, manipulators:</i>
|
|
[…]
|
|
ios_base& showpoint (ios_base& str);
|
|
ios_base& noshowpoint (ios_base& str);
|
|
<ins>ios_base& showgrouping (ios_base& str);</ins>
|
|
<ins>ios_base& noshowgrouping(ios_base& str);</ins>
|
|
ios_base& showpos (ios_base& str);
|
|
ios_base& noshowpos (ios_base& str);
|
|
[…]
|
|
}
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li><p>Change class <tt>ios_base</tt> synopsis, 27.5.3 [ios.base] as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
namespace std {
|
|
class ios_base {
|
|
public:
|
|
class failure;
|
|
<i>// 27.5.3.1.2 fmtflags</i>
|
|
typedef <i>T1</i> fmtflags;
|
|
[…]
|
|
static constexpr fmtflags showpoint = <i>unspecified</i> ;
|
|
<ins>static constexpr fmtflags showgrouping = <i>unspecified</i> ;</ins>
|
|
static constexpr fmtflags showpos = <i>unspecified</i> ;
|
|
[…]
|
|
};
|
|
}
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li><p>Add a new entry to Table 122 — "<tt>fmtflags</tt> effects" as indicated:</p>
|
|
|
|
<table border="1">
|
|
<caption>Table 122 — <tt>fmtflags</tt> effects</caption>
|
|
<tr align="center">
|
|
<th>Element</th>
|
|
<th>Effect(s) if set</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="2" align="center">
|
|
<tt>[…]</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>showpoint</tt>
|
|
</td>
|
|
<td>
|
|
generates a decimal-point character unconditionally in generated floatingpoint output
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<ins><tt>showgrouping</tt></ins>
|
|
</td>
|
|
<td>
|
|
<ins>generates grouping characters unconditionally in generated output</ins>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="2" align="center">
|
|
<tt>[…]</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
|
|
</li>
|
|
|
|
<li><p>After 27.5.3.1.2 [ios::fmtflags] p12 insert the following:</p>
|
|
<blockquote><pre>
|
|
<ins>ios_base& showgrouping(ios_base& str);</ins>
|
|
</pre><blockquote>
|
|
<p>
|
|
<ins>-?- <i>Effects</i>: Calls <tt>str.setf(ios_base::showgrouping)</tt>.</ins>
|
|
<p/>
|
|
<ins>-?- <i>Returns</i>: <tt>str</tt>.</ins>
|
|
</p>
|
|
</blockquote>
|
|
<pre>
|
|
<ins>ios_base& noshowgrouping(ios_base& str);</ins>
|
|
</pre><blockquote>
|
|
<p>
|
|
<ins>-?- <i>Effects</i>: Calls <tt>str.unsetf(ios_base::showgrouping)</tt>.</ins>
|
|
<p/>
|
|
<ins>-?- <i>Returns</i>: <tt>str</tt>.</ins>
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
</blockquote>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2119"></a>2119. Missing <tt>hash</tt> specializations for extended integer types</h3>
|
|
<p><b>Section:</b> 20.9.13 [unord.hash] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2011-12-16 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#unord.hash">active issues</a> in [unord.hash].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#unord.hash">issues</a> in [unord.hash].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
According to the header <tt><functional></tt> synopsis 20.9 [function.objects]
|
|
and to the explicit description in 20.9.13 [unord.hash] class template
|
|
<tt>hash</tt> specializations shall be provided for all arithmetic types that are
|
|
not extended integer types. This is not explicitly mentioned, but neither the list
|
|
nor any normative wording does include them, so it follows by implication.
|
|
<p/>
|
|
What are the reasons that extended integer types are excluded? E.g. for
|
|
<tt>numeric_limits</tt> corresponding specializations are required. I would
|
|
expect that an <tt>unordered_map</tt> with key type <tt>std::uintmax_t</tt> would
|
|
just work, but that depends now on whether this type is an extended integer type
|
|
or not.
|
|
<p/>
|
|
This issue is <em>not</em> asking for also providing specializations for the
|
|
<i>cv</i>-qualified arithmetic types. While this is surely a nice-to-have feature,
|
|
I consider that restriction as a more secondary problem in practice.
|
|
<p/>
|
|
The proposed resolution also fixes a problem mentioned in <a href="lwg-defects.html#2109">2109</a> in regard
|
|
to confusing requirements on user-defined types and those on implementations.
|
|
</p>
|
|
|
|
<p><i>[2012, Kona]</i></p>
|
|
|
|
<p>
|
|
Move to Open.
|
|
</p>
|
|
<p>
|
|
Agreed that it's a real issue and that the proposed wording fixes it. However, the wording
|
|
change is not minimal and isn't consistent with the way we fixed hash wording elsewhere.
|
|
</p>
|
|
<p>Alisdair will provide updated wording.
|
|
</p>
|
|
|
|
<p><i>[2014-05-06 Geoffrey Romer suggests alternative wording]</i></p>
|
|
|
|
|
|
<p>
|
|
<strong>Previous resolution from Daniel [SUPERSEDED]:</strong>
|
|
</p>
|
|
<blockquote class="note">
|
|
<p>This wording is relative to the FDIS.</p>
|
|
|
|
<p>Change 20.9.13 [unord.hash] p2 as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
template <> struct hash<bool>;
|
|
template <> struct hash<char>;
|
|
[…]
|
|
template <> struct hash<long double>;
|
|
template <class T> struct hash<T*>;
|
|
</pre><blockquote>
|
|
<p>
|
|
-2- <del><i>Requires</i>: the template specializations shall meet the requirements
|
|
of class template <tt>hash</tt> (20.9.13 [unord.hash])</del><ins>The header
|
|
<tt><functional></tt> provides definitions for specializations of the
|
|
<tt>hash</tt> class template for each <i>cv</i>-unqualified arithmetic type. This
|
|
header also provides a definition for a partial specialization of the <tt>hash</tt>
|
|
class template for any pointer type. The requirements for the members of these
|
|
specializations are given in sub-clause 20.9.13 [unord.hash]</ins>.
|
|
</p>
|
|
</blockquote></blockquote>
|
|
</blockquote>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
STL: the new PR is very simple and could resolve that nicely<br/>
|
|
MC: the older PR is rather longish
|
|
</p>
|
|
<ul>
|
|
<li><p>anybody have any objections to this approach?</p></li>
|
|
<li><p>what people want to have as a status?</p></li>
|
|
</ul>
|
|
<p>
|
|
STL: I want to have Ready<br/>
|
|
MC: move to ready: in favor: 13, opposed: 0, abstain: 4
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<p>Change 20.9.13 [unord.hash] p1 as indicated:</p>
|
|
|
|
<blockquote><p>
|
|
The unordered associative containers defined in 23.5 use specializations of the class template <tt>hash</tt> as the
|
|
default hash function. For all object types <tt>Key</tt> for which there exists a specialization <tt>hash<Key></tt>,
|
|
and for all <ins>integral and</ins> enumeration types (7.2) <tt>Key</tt>, the instantiation <tt>hash<Key></tt> shall: […]
|
|
</p></blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2121"></a>2121. <tt>app</tt> for string streams</h3>
|
|
<p><b>Section:</b> 27.8.5.1 [stringstream.cons] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Nicolai Josuttis <b>Opened:</b> 2012-01-15 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
This issue was raised while discussing issue <a href="lwg-defects.html#1448">1448</a>.
|
|
<p/>
|
|
Note the following program:
|
|
</p>
|
|
<blockquote><pre>
|
|
string s("s1: 123456789");
|
|
ostringstream s1(s, ios_base::out|ios_base::app);
|
|
s1 << "hello";
|
|
cout << s1.str() << endl;
|
|
</pre></blockquote>
|
|
<p>
|
|
With g++4.x it prints:
|
|
</p>
|
|
<blockquote><pre>
|
|
s1: 123456789hello
|
|
</pre></blockquote>
|
|
<p>
|
|
With VisualC++10 it prints:
|
|
</p>
|
|
<blockquote><pre>
|
|
hello23456789
|
|
</pre></blockquote>
|
|
<p>
|
|
From my intuitive understanding the flag "app" should result in the output of g++4.x.
|
|
I also would read that from 27.5.3.1.4 [ios::openmode] claiming:
|
|
</p>
|
|
<blockquote><p>
|
|
<tt>app</tt> seek to end before each write
|
|
</p></blockquote>
|
|
<p>
|
|
However in issue <a href="lwg-defects.html#1448">1448</a> P.J.Plauger comments:
|
|
</p>
|
|
<blockquote><p>
|
|
I think we should say nothing special about <tt>app</tt> at construction time (thus leaving the write pointer at the beginning of the buffer).
|
|
Leave implementers wiggle room to ensure subsequent append writes as they see fit, but don't change existing rules for initial seek
|
|
position.
|
|
</p></blockquote>
|
|
<p>
|
|
Note that the flag <tt>ate</tt> on both platforms appends "hello" to <tt>s</tt>.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2127"></a>2127. Move-construction with <tt>raw_storage_iterator</tt></h3>
|
|
<p><b>Section:</b> 20.7.10 [storage.iterator] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2012-01-23 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#storage.iterator">issues</a> in [storage.iterator].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
Aliaksandr Valialkin pointed out that <tt>raw_storage_iterator</tt> only supports constructing
|
|
a new object from lvalues so cannot be used to construct move-only types:
|
|
</p>
|
|
<blockquote><pre>
|
|
template <typename InputIterator, typename T>
|
|
void move_to_raw_buffer(InputIterator first, InputIterator last, T *raw_buffer)
|
|
{
|
|
std::move(first, last, std::raw_storage_iterator<T *, T>(raw_buffer));
|
|
}
|
|
</pre></blockquote>
|
|
<p>
|
|
This could easily be solved by overloading <tt>operator=</tt> for rvalues.
|
|
<p/>
|
|
Dave Abrahams:
|
|
<p/>
|
|
<tt>raw_storage_iterator</tt> causes exception-safety problems when used with any
|
|
generic algorithm. I suggest leaving it alone and not encouraging its use.
|
|
</p>
|
|
|
|
<p><i>[2014-11-11, Jonathan provides improved wording]</i></p>
|
|
|
|
<p>
|
|
In Urbana LWG decided to explicitly say the value is constructed from an rvalue.
|
|
</p>
|
|
|
|
<strong>Previous resolution from Jonathan [SUPERSEDED]:</strong>
|
|
<p/>
|
|
<blockquote class="note">
|
|
<p>This wording is relative to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf">N3337</a>.</p>
|
|
|
|
<ol>
|
|
<li><p>Add a new signature to the synopsis in 20.7.10 [storage.iterator] p1:</p>
|
|
|
|
<blockquote><pre>
|
|
namespace std {
|
|
template <class OutputIterator, class T>
|
|
class raw_storage_iterator
|
|
: public iterator<output_iterator_tag,void,void,void,void> {
|
|
public:
|
|
explicit raw_storage_iterator(OutputIterator x);
|
|
|
|
raw_storage_iterator<OutputIterator,T>& operator*();
|
|
raw_storage_iterator<OutputIterator,T>& operator=(const T& element);
|
|
<ins>raw_storage_iterator<OutputIterator,T>& operator=(T&& element);</ins>
|
|
raw_storage_iterator<OutputIterator,T>& operator++();
|
|
raw_storage_iterator<OutputIterator,T> operator++(int);
|
|
};
|
|
}
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li><p>Insert the new signature and a new paragraph before p4:</p>
|
|
|
|
<blockquote><pre>
|
|
raw_storage_iterator<OutputIterator,T>& operator=(const T& element);
|
|
<ins>raw_storage_iterator<OutputIterator,T>& operator=(T&& element);</ins>
|
|
</pre><blockquote>
|
|
<p>
|
|
<ins>-?- <i>Requires</i>: For the first signature <tt>T</tt> shall be <tt>CopyConstructible</tt>. For
|
|
the second signature <tt>T</tt> shall be <tt>MoveConstructible</tt>.</ins>
|
|
<p/>
|
|
-4- <i>Effects</i>: Constructs a value from <tt>element</tt> at the location to which the iterator points.
|
|
<p/>
|
|
-5- <i>Returns</i>: A reference to the iterator.
|
|
</p>
|
|
</blockquote></blockquote>
|
|
</li>
|
|
</ol>
|
|
</blockquote>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
MC: Suggestion to move it to Ready for incorporation on Friday<br/>
|
|
MC: move to ready: in favor: 12, opposed: 0, abstain: 3
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to <a href="http://www.open-std.org/jtc1/sc22/wg21/prot/14882fdis/n4140.pdf">N4140</a>.</p>
|
|
|
|
<ol>
|
|
<li><p>Add a new signature to the synopsis in 20.7.10 [storage.iterator] p1:</p>
|
|
|
|
<blockquote><pre>
|
|
namespace std {
|
|
template <class OutputIterator, class T>
|
|
class raw_storage_iterator
|
|
: public iterator<output_iterator_tag,void,void,void,void> {
|
|
public:
|
|
explicit raw_storage_iterator(OutputIterator x);
|
|
|
|
raw_storage_iterator<OutputIterator,T>& operator*();
|
|
raw_storage_iterator<OutputIterator,T>& operator=(const T& element);
|
|
<ins>raw_storage_iterator<OutputIterator,T>& operator=(T&& element);</ins>
|
|
raw_storage_iterator<OutputIterator,T>& operator++();
|
|
raw_storage_iterator<OutputIterator,T> operator++(int);
|
|
};
|
|
}
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li><p>Insert a new paragraph before p4:</p>
|
|
|
|
<blockquote><pre>
|
|
raw_storage_iterator<OutputIterator,T>& operator=(const T& element);
|
|
</pre><blockquote>
|
|
<p>
|
|
<ins>-?- <i>Requires</i>: <tt>T</tt> shall be <tt>CopyConstructible</tt>.</ins>
|
|
<p/>
|
|
-4- <i>Effects</i>: Constructs a value from <tt>element</tt> at the location to which the iterator points.
|
|
<p/>
|
|
-5- <i>Returns</i>: A reference to the iterator.
|
|
</p>
|
|
</blockquote></blockquote>
|
|
</li>
|
|
|
|
<li><p>Insert the new signature and a new paragraph after p5:</p>
|
|
|
|
<blockquote><pre>
|
|
<ins>raw_storage_iterator<OutputIterator,T>& operator=(T&& element);</ins>
|
|
</pre><blockquote>
|
|
<p>
|
|
<ins>-?- <i>Requires</i>: <tt>T</tt> shall be <tt>MoveConstructible</tt>.</ins>
|
|
<p/>
|
|
<ins>-?- <i>Effects</i>: Constructs a value from <tt>std::move(element)</tt> at the
|
|
location to which the iterator points.</ins>
|
|
<p/>
|
|
<ins>-?- <i>Returns</i>: A reference to the iterator.</ins>
|
|
</p>
|
|
</blockquote></blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2133"></a>2133. Attitude to overloaded comma for iterators</h3>
|
|
<p><b>Section:</b> 17.6.5.4 [global.functions] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Yakov Galka <b>Opened:</b> 2012-01-25 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#global.functions">issues</a> in [global.functions].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
17.6.5.4 [global.functions] says
|
|
</p>
|
|
<blockquote><p>
|
|
Unless otherwise specified, global and non-member functions in the standard library
|
|
shall not use functions from another namespace which are found through argument-dependent
|
|
name lookup (3.4.2).
|
|
</p></blockquote>
|
|
<p>
|
|
This sounds clear enough. There are just two problems:
|
|
</p>
|
|
<ol>
|
|
<li><p>
|
|
Both implementations I tested (VS2005 and GCC 3.4.3) do unqualified
|
|
calls to the comma operator in some parts of the library with operands
|
|
of user-defined types.
|
|
</p></li>
|
|
<li>
|
|
<p>
|
|
The standard itself does this in the description of some algorithms. E.g. <tt>uninitialized_copy</tt>
|
|
is defined as:
|
|
</p>
|
|
<blockquote><p>
|
|
<i>Effects</i>:
|
|
</p><blockquote>
|
|
<pre>
|
|
for (; first != last; <span style="color:#C80000;font-weight:bold">++result, ++first</span>)
|
|
::new (static_cast<void*>(&*result))
|
|
typename iterator_traits<ForwardIterator>::value_type(*first);
|
|
</pre>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
<p>
|
|
If understood literally, it is required to call <tt>operator,(ForwardIterator, InputIterator)</tt>.
|
|
<p/>
|
|
For detailed discussion with code samples see
|
|
<a href="http://stackoverflow.com/questions/8719829/should-the-implementation-guard-itself-against-comma-overloading">here</a>.
|
|
<p/>
|
|
Proposal:
|
|
</p>
|
|
<ol>
|
|
<li>
|
|
Add an exception to the rule in 17.6.5.4 [global.functions] by permitting
|
|
the implementation to call the comma operator as much as it wants to. I doubt we want this. or
|
|
</li>
|
|
<li>
|
|
Fix the description of the said algorithms and perhaps add a note to 17.6.5.4 [global.functions]
|
|
that brings attention of the implementers to avoid this pitfall.
|
|
</li>
|
|
</ol>
|
|
|
|
<p><i>[2013-03-15 Issues Teleconference]</i></p>
|
|
|
|
<p>
|
|
Moved to Open.
|
|
</p>
|
|
<p>
|
|
There are real questions here, that may require a paper to explore and answer properly.
|
|
</p>
|
|
|
|
<p><i>[2014-05-18, Daniel comments and suggests concrete wording]</i></p>
|
|
|
|
|
|
<p>
|
|
Other issues, such as <a href="lwg-active.html#2114">2114</a> already follow a similar spirit as the one suggested by bullet 2 of the
|
|
issue submitter. I assert that consideration of possible user-provided overloads of the comma-operator were not intended
|
|
by the original wording and doing so afterwards would unnecessarily complicate a future conceptualization of the library
|
|
and would needlessly restrict implementations.
|
|
<p/>
|
|
I don't think that a paper is needed to solve this issue, there is a simply way to ensure that the code-semantics
|
|
excludes consideration of user-provided comma operators. The provided wording below clarifies this by explicitly
|
|
casting the first argument of the operator to <tt>void</tt>.
|
|
</p>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
DK: is putting it in the middle the right place for it?<br/>
|
|
STL: either works, but visually putting it in the middle is clearer, and for "++it1, ++i2, ++it3" it needs to be
|
|
done after the second comma, so "++it1, (void) ++i2, (void) ++it3" is better than "(void) ++it1, ++i2, (void) ++it3"<br/>
|
|
ZY: for <tt><i>INVOKE</i></tt> yesterday we used <tt>static_cast<void></tt> but here we're using C-style cast, why?<br/>
|
|
STL: for <tt><i>INVOKE</i></tt> I want to draw attention that there's an intentional coercion to <tt>void</tt> because that's
|
|
the desired type. Here we only do it because that's the best way to prevent the problem, not because we specifically want a
|
|
<tt>void</tt> type.<br/>
|
|
Move to Ready: 9 in favor, none opposed, 1 abstention
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 20.7.12.2 [uninitialized.copy] as indicated:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
template <class InputIterator, class ForwardIterator>
|
|
ForwardIterator uninitialized_copy(InputIterator first, InputIterator last,
|
|
ForwardIterator result);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-1- <i>Effects</i>:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
for (; first != last; ++result, <ins>(void)</ins> ++first)
|
|
::new (static_cast<void*>(&*result))
|
|
typename iterator_traits<ForwardIterator>::value_type(*first);
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
[…]
|
|
</p>
|
|
</blockquote>
|
|
|
|
<pre>
|
|
template <class InputIterator, class Size,class ForwardIterator>
|
|
ForwardIterator uninitialized_copy_n(InputIterator first, Size n,
|
|
ForwardIterator result);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-3- <i>Effects</i>:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
for (; n > 0; ++result, <ins>(void)</ins> ++first, --n)
|
|
::new (static_cast<void*>(&*result))
|
|
typename iterator_traits<ForwardIterator>::value_type(*first);
|
|
</pre>
|
|
</blockquote>
|
|
</blockquote>
|
|
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 25.4.8 [alg.lex.comparison] p3 as indicated:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
template<class InputIterator1, class InputIterator2>
|
|
bool
|
|
lexicographical_compare(InputIterator1 first1, InputIterator1 last1,
|
|
InputIterator2 first2, InputIterator2 last2);
|
|
template<class InputIterator1, class InputIterator2, class Compare>
|
|
bool
|
|
lexicographical_compare(InputIterator1 first1, InputIterator1 last1,
|
|
InputIterator2 first2, InputIterator2 last2,
|
|
Compare comp);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-3- <i>Remarks</i>: […]
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
for ( ; first1 != last1 && first2 != last2 ; ++first1, <ins>(void)</ins> ++first2) {
|
|
if (*first1 < *first2) return true;
|
|
if (*first2 < *first1) return false;
|
|
}
|
|
return first1 == last1 && first2 != last2;
|
|
</pre>
|
|
</blockquote>
|
|
</blockquote>
|
|
</blockquote>
|
|
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2136"></a>2136. Postconditions vs. exceptions</h3>
|
|
<p><b>Section:</b> 17.5.1 [structure] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Jens Maurer <b>Opened:</b> 2012-03-08 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
The front matter in clause 17 should clarify that postconditions will not hold if a
|
|
standard library function exits via an exception. Postconditions or guarantees that
|
|
apply when an exception is thrown (beyond the basic guarantee) are described in an
|
|
"Exception safety" section.
|
|
</p>
|
|
|
|
<p><i>[
|
|
2012-10 Portland: Move to Open
|
|
]</i></p>
|
|
|
|
|
|
<p>
|
|
Consensus that we do not clearly say this, and that we probably should. A likely
|
|
location to describe the guarantees of <i>postconditions</i> could well be a new
|
|
sub-clause following 17.6.4.11 [res.on.required] which serves the same purpose
|
|
for <i>requires</i> clauses. However, we need such wording before we can make
|
|
progress.
|
|
</p>
|
|
|
|
<p>
|
|
Also, see <a href="lwg-active.html#2137">2137</a> for a suggestion that we want to see a paper resolving
|
|
both issues together.
|
|
</p>
|
|
|
|
<p><i>[2015-05-06 Lenexa: EirkWF to write paper addressing 2136 and 2137]</i></p>
|
|
|
|
<p>MC: Idea is to replace all such "If no exception" postconditions with "Exception safety" sections.</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2137"></a>2137. Misleadingly constrained post-condition in the presence of exceptions</h3>
|
|
<p><b>Section:</b> 28.8.3 [re.regex.assign] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2012-03-08 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#re.regex.assign">issues</a> in [re.regex.assign].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
The post-conditions of <tt>basic_regex<>::assign</tt> 28.8.3 [re.regex.assign] p16 say:
|
|
</p>
|
|
<blockquote><p>
|
|
<span style="color:#C80000;font-weight:bold">If no exception is thrown,</span> <tt>flags()</tt> returns
|
|
<tt>f</tt> and <tt>mark_count()</tt> returns the number of marked sub-expressions within the expression.
|
|
</p></blockquote>
|
|
<p>
|
|
The default expectation in the library is that post-conditions only hold, if there is no failure
|
|
(see also <a href="lwg-active.html#2136">2136</a>), therefore the initial condition should be removed to prevent any
|
|
misunderstanding.
|
|
</p>
|
|
|
|
<p><i>[
|
|
2012-10 Portland: Move to Open
|
|
]</i></p>
|
|
|
|
|
|
<p>
|
|
A favorable resolution clearly depends on a favorable resolution to <a href="lwg-active.html#2136">2136</a>.
|
|
There is also a concern that this is just one example of where we would want to apply
|
|
such a wording clean-up, and which is really needed to resolve both this issue and
|
|
<a href="lwg-active.html#2136">2136</a> is a paper providing the clause 17 wording that gives the guarantee
|
|
for <i>postcondition</i> paragaraphs, and then reviews clauses 18-30 to apply that
|
|
guarantee consistently. We do not want to pick up these issues piecemeal, as we risk
|
|
openning many issues in an ongoing process.
|
|
</p>
|
|
|
|
<p><i>[2015-05-06 Lenexa: EirkWF to write paper addressing 2136 and 2137]</i></p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3376.</p>
|
|
|
|
<blockquote><pre>
|
|
template <class string_traits, class A>
|
|
basic_regex& assign(const basic_string<charT, string_traits, A>& s,
|
|
flag_type f = regex_constants::ECMAScript);
|
|
</pre><blockquote>
|
|
<p>
|
|
[…]
|
|
<p/>
|
|
-15- <i>Effects</i>: Assigns the regular expression contained in the string <tt>s</tt>, interpreted according
|
|
the flags specified in <tt>f</tt>. If an exception is thrown, <tt>*this</tt> is unchanged.
|
|
<p/>
|
|
-16- <i>Postconditions</i>: <del>If no exception is thrown,</del> <tt>flags()</tt> returns <tt>f</tt> and
|
|
<tt>mark_count()</tt> returns the number of marked sub-expressions within the expression.
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2139"></a>2139. What is a <em>user-defined</em> type?</h3>
|
|
<p><b>Section:</b> 17.6.4.2.1 [namespace.std], 19.5 [syserr], 20.7.7.1 [allocator.uses.trait], 20.9.10.1 [func.bind.isbind], 20.9.10.2 [func.bind.isplace], 20.9.13 [unord.hash], 20.10.7.6 [meta.trans.other], 22.3.1 [locale], 22.4.1.4 [locale.codecvt], 28.12.1.4 [re.regiter.incr] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Loïc Joly <b>Opened:</b> 2012-03-08 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#namespace.std">issues</a> in [namespace.std].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
The expression "user-defined type" is used in several places in the standard, but I'm not sure what
|
|
it means. More specifically, is a type defined in the standard library a user-defined type?
|
|
<p/>
|
|
From my understanding of English, it is not. From most of the uses of this term in the standard, it
|
|
seem to be considered as user defined. In some places, I'm hesitant, e.g. 17.6.4.2.1 [namespace.std] p1:
|
|
</p>
|
|
<blockquote><p>
|
|
A program may add a template specialization for any standard library template to namespace <tt>std</tt>
|
|
only if the declaration depends on a user-defined type and the specialization meets the standard library
|
|
requirements for the original template and is not explicitly prohibited.
|
|
</p></blockquote>
|
|
<p>
|
|
Does it mean we are allowed to add in the namespace <tt>std</tt> a specialization for
|
|
<tt>std::vector<std::pair<T, U>></tt>, for instance?
|
|
<p/>
|
|
Additional remarks from the reflector discussion: The traditional meaning of user-defined types refers
|
|
to class types and enum types, but the library actually means here user-defined types that are not
|
|
(purely) library-provided. Presumably a new term - like <em>user-provided type</em> - should be introduced
|
|
and properly defined.
|
|
</p>
|
|
|
|
<p><i>[
|
|
2012-10 Portland: Move to Deferred
|
|
]</i></p>
|
|
|
|
|
|
<p>
|
|
The issue is real, in that we never define this term and rely on a "know it when I see it"
|
|
intuition. However, there is a fear that any attempt to pin down a definition is more
|
|
likely to introduce bugs than solve them - getting the wording for this precisely correct
|
|
is likely far more work than we are able to give it.
|
|
</p>
|
|
|
|
<p>
|
|
There is unease at simple closing as NAD, but not real enthusiasm to provide wording either.
|
|
Move to Deferred as we are not opposed to some motivated individual coming back with full
|
|
wording to review, but do not want to go out of our way to encourage someone to work on this
|
|
in preference to other issues.
|
|
</p>
|
|
|
|
<p><i>[2014-02-20 Re-open Deferred issues as Priority 4]</i></p>
|
|
|
|
|
|
<p><i>[2015-03-05 Jonathan suggests wording]</i></p>
|
|
|
|
<p>
|
|
I dislike the suggestion to change to "user-provided" type because I already find the
|
|
difference between user-declared / user-provided confusing for special member functions,
|
|
so I think it would be better to use a completely different term. The core language
|
|
uses "user-defined conversion sequence" and "user-defined literal" and
|
|
similar terms for things which the library provides, so I think we
|
|
should not refer to "user" at all to distinguish entities defined
|
|
outside the implementation from things provided by the implementation.
|
|
<p/>
|
|
I propose "program-defined type" (and "program-defined specialization"), defined below.
|
|
The P/R below demonstrates the scope of the changes required, even if this name isn't adopted.
|
|
I haven't proposed a change for "User-defined facets" in [locale].
|
|
</p>
|
|
|
|
<p><i>[Lenexa 2015-05-06]</i></p>
|
|
|
|
<p>RS, HT: The core language uses "user-defined" in a specific way, including library things but excluding core language things, let's use a different term.</p>
|
|
<p>MC: Agree.</p>
|
|
<p>RS: "which" should be "that", x2</p>
|
|
<p>RS: Is std::vector<MyType> a "program-defined type"?</p>
|
|
<p>MC: I think it should be.</p>
|
|
<p>TK: std::vector<int> seems to take the same path.</p>
|
|
<p>JW: std::vector<MyType> isn't program-defined, we don't need it to be, anything that depends on that also depends on =MyType.</p>
|
|
<p>TK: The type defined by an "explicit template specialization" should be a program-defined type.</p>
|
|
<p>RS: An implicit instantiation of a "program-defined partial specialization" should also be a program-defined type.</p>
|
|
<p>JY: This definition formatting is horrible and ugly, can we do better?</p>
|
|
<p>RS: Checking ISO directives.</p>
|
|
<p>RS: Define "program-defined type" and "program-defined specialization" instead, to get rid of the angle brackets.</p>
|
|
<p>JW redrafting.</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N4296.</p>
|
|
|
|
<ol>
|
|
<li><p>Add a new sub-clause to 17.3 [definitions]:</p>
|
|
|
|
<p><ins><b>17.3.? [defns.program.defined]</b></ins></p>
|
|
<p>
|
|
<ins><b>program-defined</b></ins>
|
|
<p/>
|
|
<ins><type> a class type or enumeration type which is not part of the C++
|
|
standard library and not defined by the implementation. [<i>Note</i>: Types
|
|
defined by the implementation include extensions (1.4 [intro.compliance])
|
|
and internal types used by the library. — <i>end note</i>]</ins>
|
|
</p>
|
|
<p>
|
|
<ins><b>program-defined</b></ins>
|
|
<p/>
|
|
<ins><specialization> an explicit template specialization or partial
|
|
specialization which is not part of the C++ standard library and not
|
|
defined by the implementation.</ins>
|
|
</p>
|
|
</li>
|
|
|
|
<li><p>Change 17.6.4.2.1 [namespace.std] paragraph 1+2:</p>
|
|
|
|
<p>
|
|
-1- The behavior of a C++ program is undefined if it adds declarations or definitions to namespace <tt>std</tt> or to a
|
|
namespace within namespace <tt>std</tt> unless otherwise specified. A program may add a template specialization
|
|
for any standard library template to namespace <tt>std</tt> only if the declaration depends on a
|
|
<del>user</del><ins>program</ins>-defined type and the specialization meets the standard library requirements for the
|
|
original template and is not explicitly prohibited.
|
|
<p/>
|
|
-2- The behavior of a C++ program is undefined if it declares
|
|
<p/>
|
|
[…]
|
|
<p/>
|
|
A program may explicitly instantiate a template defined in the standard library only if the declaration
|
|
depends on the name of a <del>user</del><ins>program</ins>-defined type and the instantiation meets the standard
|
|
library requirements for the original template.
|
|
</p>
|
|
</li>
|
|
|
|
<li><p>Change 19.5 [syserr] paragraph 4:</p>
|
|
|
|
<p>
|
|
-4- The <tt>is_error_code_enum</tt> and <tt>is_error_condition_enum</tt> may be specialized for
|
|
<del>user</del><ins>program</ins>-defined types to indicate that such types are eligible for class <tt>error_code</tt>
|
|
and class <tt>error_condition</tt> automatic conversions, respectively.
|
|
</p>
|
|
</li>
|
|
|
|
<li><p>Change 20.7.7.1 [allocator.uses.trait] paragraph 1:</p>
|
|
|
|
<p>
|
|
-1- <i>Remarks</i>: automatically detects […]. A program may specialize this template to derive from
|
|
<tt>true_type</tt> for a <del>user</del><ins>program</ins>-defined type <tt>T</tt> that does not have a nested
|
|
<tt>allocator_type</tt> but nonetheless can be constructed with an allocator where either: […]
|
|
</p>
|
|
</li>
|
|
|
|
<li><p>Change 20.9.10.1 [func.bind.isbind] paragraph 2:</p>
|
|
|
|
<p>
|
|
-2- Instantiations of the <tt>is_bind_expression</tt> template […]. A program may specialize
|
|
this template for a <del>user</del><ins>program</ins>-defined type <tt>T</tt> to have a <tt>BaseCharacteristic</tt>
|
|
of <tt>true_type</tt> to indicate that <tt>T</tt> should be treated as a subexpression in a <tt>bind</tt> call.
|
|
</p>
|
|
</li>
|
|
|
|
<li><p>Change 20.9.10.2 [func.bind.isplace] paragraph 2:</p>
|
|
|
|
<p>
|
|
-2- Instantiations of the <tt>is_placeholder</tt> template […]. A program may specialize this template for a
|
|
<del>user</del><ins>program</ins>-defined type <tt>T</tt> to have a <tt>BaseCharacteristic</tt> of
|
|
<tt>integral_constant<int, <i>N</i>></tt> with <tt><i>N</i> > 0</tt> to indicate that <tt>T</tt> should be
|
|
treated as a placeholder type.
|
|
</p>
|
|
</li>
|
|
|
|
<li><p>Change 20.9.13 [unord.hash] paragraph 1:</p>
|
|
|
|
<p>
|
|
The unordered associative containers defined in 23.5 use specializations of the class template <tt>hash</tt> […],
|
|
the instantiation <tt>hash<Key></tt> shall:
|
|
</p>
|
|
<ul>
|
|
<li><p>[…]</p></li>
|
|
<li><p>[…]</p></li>
|
|
<li><p>[…]</p></li>
|
|
<li><p>[…]</p></li>
|
|
<li><p>satisfy the requirement that the expression <tt>h(k)</tt>, where <tt>h</tt> is an object of type
|
|
<tt>hash<Key></tt> and <tt>k</tt> is an object of type <tt>Key</tt>, shall not throw an exception unless
|
|
<tt>hash<Key></tt> is a <del>user</del><ins>program</ins>-defined specialization that depends on at least one
|
|
<del>user</del><ins>program</ins>-defined type.</p></li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li><p>Change 20.10.7.5 [meta.trans.ptr] Table 57 (<tt>common_type</tt> row):</p>
|
|
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 57 — Other transformations</caption>
|
|
<tr>
|
|
<th align="center">Template</th>
|
|
<th align="center">Condition</th>
|
|
<th align="center">Comments</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="3" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>template <class... T><br/>
|
|
struct common_type;</tt>
|
|
</td>
|
|
|
|
<td align="center">
|
|
|
|
</td>
|
|
|
|
<td>
|
|
The member typedef <tt>type</tt> shall be<br/>
|
|
defined or omitted as specified below.<br/>
|
|
[…]. A program may<br/>
|
|
specialize this trait if at least one<br/>
|
|
template parameter in the<br/>
|
|
specialization is a <del>user</del><ins>program</ins>-defined type.<br/>
|
|
[…]
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="3" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote>
|
|
|
|
</li>
|
|
|
|
<li><p>Change 22.4.1.4 [locale.codecvt] paragraph 3:</p>
|
|
|
|
<p>
|
|
-3- The specializations required in Table 81 (22.3.1.1.1) […]. Other encodings can be converted
|
|
by specializing on a <del>user</del><ins>program</ins>-defined <tt>stateT</tt> type.[…]
|
|
</p>
|
|
</li>
|
|
|
|
<li><p>Change 28.12.1.4 [re.regiter.incr] paragraph 8:</p>
|
|
|
|
<p>
|
|
-8- [<i>Note</i>: This means that a compiler may call an implementation-specific search function, in which case
|
|
a <del>user</del><ins>program</ins>-defined specialization of <tt>regex_search</tt> will not be called. —
|
|
<i>end note</i>]
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2146"></a>2146. Are reference types <tt>Copy</tt>/<tt>Move-Constructible</tt>/<tt>Assignable</tt> or <tt>Destructible</tt>?</h3>
|
|
<p><b>Section:</b> 17.6.3.1 [utility.arg.requirements] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Nikolay Ivchenkov <b>Opened:</b> 2012-03-23 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
According to 17.6.3.1 [utility.arg.requirements] p1
|
|
</p>
|
|
<blockquote><p>
|
|
The template definitions in the C++ standard library refer to various named requirements whose details are set out in
|
|
tables 17-24. In these tables, <tt>T</tt> is an object or reference type to be supplied by a C++ program instantiating
|
|
a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are values of type (possibly <tt>const</tt>) <tt>T</tt>; <tt>s</tt>
|
|
and <tt>t</tt> are modifiable lvalues of type <tt>T</tt>; <tt>u</tt> denotes an identifier; <tt>rv</tt> is an rvalue of
|
|
type <tt>T</tt>; and <tt>v</tt> is an lvalue of type (possibly <tt>const</tt>) <tt>T</tt> or an rvalue of type <tt>const T</tt>.
|
|
</p></blockquote>
|
|
<p>
|
|
Is it really intended that <tt>T</tt> may be a reference type? If so, what should <tt>a</tt>, <tt>b</tt>, <tt>c</tt>,
|
|
<tt>s</tt>, <tt>t</tt>, <tt>u</tt>, <tt>rv</tt>, and <tt>v</tt> mean? For example, are "<tt>int &</tt>" and
|
|
"<tt>int &&</tt>" <tt>MoveConstructible</tt>?
|
|
<p/>
|
|
As far as I understand, we can explicitly specify template arguments for <tt>std::swap</tt> and <tt>std::for_each</tt>.
|
|
Can we use reference types there?
|
|
</p>
|
|
<ol>
|
|
<li>
|
|
<blockquote><pre>
|
|
#include <iostream>
|
|
#include <utility>
|
|
|
|
int main()
|
|
{
|
|
int x = 1;
|
|
int y = 2;
|
|
std::swap<<span style="color:#C80000;font-weight:bold">int &&</span>>(x, y); // <em>undefined?</em>
|
|
std::cout << x << " " << y << std::endl;
|
|
}
|
|
</pre></blockquote>
|
|
</li>
|
|
<li>
|
|
<blockquote><pre>
|
|
#include <algorithm>
|
|
#include <iostream>
|
|
#include <iterator>
|
|
#include <utility>
|
|
|
|
struct F
|
|
{
|
|
void operator()(int n)
|
|
{
|
|
std::cout << n << std::endl;
|
|
++count;
|
|
}
|
|
int count;
|
|
} f;
|
|
|
|
int main()
|
|
{
|
|
int arr[] = { 1, 2, 3 };
|
|
auto&& result = std::for_each<int *, <span style="color:#C80000;font-weight:bold">F &&</span>>( // <em>undefined?</em>
|
|
std::begin(arr),
|
|
std::end(arr),
|
|
std::move(f));
|
|
std::cout << "count: " << result.count << std::endl;
|
|
}
|
|
</pre></blockquote>
|
|
</li>
|
|
</ol>
|
|
<p>
|
|
Are these forms of usage well-defined?
|
|
<p/>
|
|
Let's also consider the following constructor of <tt>std::thread</tt>:
|
|
</p>
|
|
<blockquote><pre>
|
|
template <class F, class ...Args>
|
|
explicit thread(F&& f, Args&&... args);
|
|
</pre><blockquote>
|
|
<p>
|
|
<i>Requires</i>: <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt> shall satisfy the <tt>MoveConstructible</tt> requirements.
|
|
</p>
|
|
</blockquote></blockquote>
|
|
<p>
|
|
When the first argument of this constructor is an lvalue (e.g. a name of a global function), template argument for <tt>F</tt>
|
|
is deduced to be lvalue reference type. What should "<tt>MoveConstructible</tt>" mean with regard to an lvalue reference
|
|
type? Maybe the wording should say that <tt>std::decay<F>::type</tt> and each <tt>std::decay<Ti>::type</tt> (where
|
|
<tt>Ti</tt> is an arbitrary item in <tt>Args</tt>) shall satisfy the <tt>MoveConstructible</tt> requirements?
|
|
</p>
|
|
|
|
<p><i>[2013-03-15 Issues Teleconference]</i></p>
|
|
|
|
<p>
|
|
Moved to Open.
|
|
</p>
|
|
<p>
|
|
The questions raised by the issue are real, and should have a clear answer.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2151"></a>2151. <tt>basic_string<>::swap</tt> semantics ignore allocators</h3>
|
|
<p><b>Section:</b> 21.4.1 [string.require] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Robert Shearer <b>Opened:</b> 2012-04-13 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#string.require">issues</a> in [string.require].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
In C++11, <tt>basic_string</tt> is not described as a "container", and is not governed by the allocator-aware
|
|
container semantics described in sub-clause 23.2 [container.requirements]; as a result, and
|
|
requirements or contracts for the <tt>basic_string</tt> interface must be documented in Clause
|
|
21 [strings].
|
|
<p/>
|
|
Sub-clause 21.4.6.8 [string::swap] defines the <tt>swap</tt> member function with no requirements, and
|
|
with guarantees to execute in constant time without throwing. Fulfilling such a contract is not reasonable
|
|
in the presence of unequal non-propagating allocators.
|
|
<p/>
|
|
In contrast, 23.2.1 [container.requirements.general] p7 declares the behavior of member <tt>swap</tt>
|
|
for containers with unequal non-propagating allocators to be undefined.
|
|
<p/>
|
|
Resolution proposal:
|
|
<p/>
|
|
Additional language from Clause 23 [containers] should probably be copied to Clause
|
|
21 [strings]. I will refrain from an exactly recommendation, however, as I am raising further
|
|
issues related to the language in Clause 23 [containers].
|
|
</p>
|
|
|
|
<p><i>[2013-03-15 Issues Teleconference]</i></p>
|
|
|
|
<p>
|
|
Moved to Open.
|
|
</p>
|
|
<p>
|
|
Alisdair has offered to provide wording.
|
|
</p>
|
|
<p>
|
|
Telecon notes that 23.2.1 [container.requirements.general]p13 says that <tt>string</tt> is an
|
|
allocator-aware container.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2152"></a>2152. Instances of standard container types are not swappable</h3>
|
|
<p><b>Section:</b> 17.6.3.2 [swappable.requirements], 23.2.1 [container.requirements.general] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Robert Shearer <b>Opened:</b> 2012-04-13 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#swappable.requirements">issues</a> in [swappable.requirements].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
Sub-clause 17.6.3.2 [swappable.requirements] defines two notions of swappability: a binary version defining
|
|
when two objects are <em>swappable with</em> one another, and a unary notion defining whether an object is
|
|
<em>swappable</em> (without qualification), with the latter definition requiring that the object satisfy the
|
|
former with respect to all values of the same type.
|
|
<p/>
|
|
Let <tt>T</tt> be a container type based on a non-propagating allocator whose instances do not necessarily
|
|
compare equal. Then sub-clause 23.2.1 [container.requirements.general] p7 implies that no object <tt>t</tt>
|
|
of type <tt>T</tt> is swappable (by the unary definition).
|
|
<p/>
|
|
Throughout the standard it is the unary definition of "swappable" that is listed as a requirement (with the
|
|
exceptions of 20.2.2 [utility.swap] p4, 20.3.2 [pairs.pair] p31, 20.4.2.3 [tuple.swap] p2,
|
|
25.3.3 [alg.swap] p2, and 25.3.3 [alg.swap] p6, which use the binary definition). This renders
|
|
many of the mutating sequence algorithms of sub-clause 25.3 [alg.modifying.operations], for example,
|
|
inapplicable to sequences of standard container types, even where every element of the sequence is swappable
|
|
with every other.
|
|
<p/>
|
|
Note that this concern extends beyond standard containers to all future allocator-based types.
|
|
<p/>
|
|
Resolution proposal:
|
|
<p/>
|
|
I see two distinct straightforward solutions:
|
|
</p>
|
|
<ol style="list-style-type:lower-roman">
|
|
<li>Modify the requirements of algorithms from sub-clause 25.3 [alg.modifying.operations], and all other
|
|
places that reference the unary "swappable" definition, to instead use the binary "swappable with" definition
|
|
(over a domain appropriate to the context). The unary definition of "swappable" could then be removed from the
|
|
standard.
|
|
</li>
|
|
<li>Modify sub-clause 23.2.1 [container.requirements.general] such that objects of standard container types
|
|
are "swappable" by the unary definition.
|
|
</li>
|
|
</ol>
|
|
<p>
|
|
I favor the latter solution, for reasons detailed in the following issue.
|
|
</p>
|
|
|
|
<p><i>[
|
|
2012-10 Portland: Move to Open
|
|
]</i></p>
|
|
|
|
|
|
<p>
|
|
The issue is broader than containers with stateful allocotors, although they are the most obvious
|
|
example contained within the standard itself. The basic problem is that once you have a stateful
|
|
allocator, that does not <tt>propagate_on_swap</tt>, then whether two objects of this type can be
|
|
swapped with well defined behavior is a run-time property (the allocators compare equal) rather
|
|
than a simple compile-time property that can be deduced from the type. Strictly speaking, any
|
|
type where the nature of swap is a runtime property does not meet the <tt>swappable</tt>
|
|
requirements of C++11, although typical sequences of such types are going to have elements that
|
|
are all <tt>swappable with</tt> any other element in the sequence (using our other term of art
|
|
for specifying requirements) as the common case is a container of elements who all share the
|
|
same allocator.
|
|
</p>
|
|
|
|
<p>
|
|
The heart of the problem is that the <tt>swappable</tt> requirments demand that any two objects
|
|
of the same type be <tt>swappable with</tt> each other, so if any two such objects would not
|
|
be <tt>swappable with</tt> each other, then the whole type is never <tt>swappable</tt>. Many
|
|
algorithms in clause 25 are specified in terms of <tt>swappable</tt> which is essentially an
|
|
overspecification as all they actually need is that any element in the sequence is <tt>swappable
|
|
with</tt> any other element in the sequence.
|
|
</p>
|
|
|
|
<p>
|
|
At this point Howard joins the discussion and points out that the intent of introducing the
|
|
two swap-related terms was to support <tt>vector<bool>::reference</tt> types, and we are
|
|
reading something into the wording that was never intended. Consuses is that regardless of
|
|
the intent, that is what the words today say.
|
|
</p>
|
|
|
|
<p>
|
|
There is some support to see a paper reviewing the whole of clause 25 for this issue, and
|
|
other select clauses as may be necessary.
|
|
</p>
|
|
|
|
<p>
|
|
There was some consideration to introducing a note into the front of clause 25 to indicate
|
|
<tt>swappable</tt> requirements in the clause should be interpreted to allow such awkward
|
|
types, but ultimately no real enthusiasm for introducing a <tt>swappable for clause 25</tt>
|
|
requirement term, especially if it confusingly had the same name as a term used with a
|
|
subtly different meaning through the rest of the standard.
|
|
</p>
|
|
|
|
<p>
|
|
There was no enthusiasm for the alternate resolution of requiring containers with unequal
|
|
allocators that do not propagate provide a well-defined swap behavior, as it is not
|
|
believed to be possible without giving <tt>swap</tt> linear complexity for such values,
|
|
and even then would require adding the constraint that the container element types are
|
|
CopyConstructible.
|
|
</p>
|
|
|
|
<p>
|
|
Final conclusion: move to open pending a paper from a party with a strong interest in
|
|
stateful allocators.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2153"></a>2153. Narrowing of the non-member <tt>swap</tt> contract</h3>
|
|
<p><b>Section:</b> 20.2.2 [utility.swap], 17.6.3.2 [swappable.requirements], 23.2.1 [container.requirements.general] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Robert Shearer <b>Opened:</b> 2012-04-13 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
Sub-clause 20.2.2 [utility.swap] defines a non-member 'swap' function with defined behavior for
|
|
all <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt> types. It does not guarantee
|
|
constant-time complexity or <tt>noexcept</tt> in general, however this definition does
|
|
render all objects of <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt> type swappable
|
|
(by the unary definition of sub-clause 17.6.3.2 [swappable.requirements]) in the absence of
|
|
specializations or overloads.
|
|
<p/>
|
|
The overload of the non-member <tt>swap</tt> function defined in Table 96, however,
|
|
defines semantics incompatible with the generic non-member <tt>swap</tt> function,
|
|
since it is defined to call a member <tt>swap</tt> function whose semantics are
|
|
undefined for some values of <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt> types.
|
|
<p/>
|
|
The obvious (perhaps naive) interpretation of sub-clause 17.6.3.2 [swappable.requirements] is as a guide to
|
|
the "right" semantics to provide for a non-member <tt>swap</tt> function (called in
|
|
the context defined by 17.6.3.2 [swappable.requirements] p3) in order to provide interoperable
|
|
user-defined types for generic programming. The standard container types don't follow these guidelines.
|
|
<p/>
|
|
More generally, the design in the standard represents a classic example of "contract narrowing". It
|
|
is entirely reasonable for the contract of a particular <tt>swap</tt> overload to provide <em>more</em>
|
|
guarantees, such as constant-time execution and <tt>noexcept</tt>, than are provided by the <tt>swap</tt>
|
|
that is provided for any <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt> types, but it is <em>not</em>
|
|
reasonable for such an overload to fail to live up to the guarantees it provides for general types when
|
|
it is applied to more specific types. Such an overload or specialization in generic programming is akin
|
|
to an override of an inherited virtual function in OO programming: violating a superclass contract in a
|
|
subclass may be legal from the point of view of the language, but it is poor design and can easily lead
|
|
to errors. While we cannot prevent user code from providing overloads that violate the more general
|
|
<tt>swap</tt> contract, we can avoid doing so within the library itself.
|
|
<p/>
|
|
My proposed resolution is to draw a sharp distinction between member <tt>swap</tt> functions, which provide
|
|
optimal performance but idiosyncratic contracts, and non-member <tt>swap</tt> functions, which should always
|
|
fulfill at least the contract of 20.2.2 [utility.swap] and thus render objects swappable. The member
|
|
<tt>swap</tt> for containers with non-propagating allocators, for example, would offer constant-time
|
|
guarantees and <tt>noexcept</tt> but would only offer defined behavior for values with allocators that compare
|
|
equal; non-member <tt>swap</tt> would test allocator equality and then dispatch to either member <tt>swap</tt> or
|
|
<tt>std::swap</tt> depending on the result, providing defined behavior for all values (and rendering the type
|
|
"swappable"), but offering neither the constant-time nor the <tt>noexcept</tt> guarantees.
|
|
</p>
|
|
|
|
<p><i>[2013-03-15 Issues Teleconference]</i></p>
|
|
|
|
<p>
|
|
Moved to Open.
|
|
</p>
|
|
<p>
|
|
This topic deserves more attention than can be given in the telocon, and there is no proposed resolution.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2154"></a>2154. What exactly does compile-time complexity imply?</h3>
|
|
<p><b>Section:</b> 26.5.1.3 [rand.req.urng] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> John Salmon <b>Opened:</b> 2012-04-26 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#rand.req.urng">issues</a> in [rand.req.urng].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
The expressions <tt>G::min()</tt> and <tt>G::max()</tt> in Table 116 in 26.5.1.3 [rand.req.urng] are specified
|
|
as having "compile-time" complexity.
|
|
<p/>
|
|
It is not clear what, exactly, this requirement implies. If a URNG has a method:
|
|
</p>
|
|
<blockquote><pre>
|
|
static int min();
|
|
</pre></blockquote>
|
|
<p>
|
|
then is the method required to have a <tt>constexpr</tt> qualifier? I believe the standard would benefit from
|
|
clarification of this point.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2155"></a>2155. Macro <tt>__bool_true_false_are_defined</tt> should be removed</h3>
|
|
<p><b>Section:</b> 18.10 [support.runtime] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Thomas Plum <b>Opened:</b> 2012-04-30 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#support.runtime">active issues</a> in [support.runtime].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#support.runtime">issues</a> in [support.runtime].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
Since C99, the C standard describes a macro named <tt>__bool_true_false_are_defined</tt>.
|
|
<p/>
|
|
In the process of harmonizing C++11 with C99, this name became part of the C++ standard.
|
|
<p/>
|
|
I propose that all mention of this name should be removed from the C and C++ standards.
|
|
<p/>
|
|
Here's the problem: The name was originally proposed as a transition tool, so that the headers for a
|
|
project could contain lines like the following.
|
|
</p>
|
|
<blockquote><pre>
|
|
#if !defined(__bool_true_false_are_defined)
|
|
#define bool int /* or whatever */
|
|
#define true 1
|
|
#define false 0
|
|
#endif
|
|
</pre></blockquote>
|
|
<p>
|
|
Then when the project was compiled by a "new" compiler that implemented <tt>bool</tt> as defined by the
|
|
evolving C++98 or C99 standards, those lines would be skipped; but when compiled by an "old" compiler that
|
|
didn't yet provide <tt>bool</tt>, <tt>true</tt>, and <tt>false</tt>, then the <tt>#define</tt>'s would provide a
|
|
simulation that worked for most purposes.
|
|
<p/>
|
|
It turns out that there is an unfortunate ambiguity in the name. One interpretation is as shown above, but
|
|
a different reading says "bool, true, and false are #define'd", i.e. that the meaning of the macro is to
|
|
assert that these names are macros (not built-in) ... which is true in C, but not in C++.
|
|
<p/>
|
|
In C++11, the name appears in parentheses followed by a stray period, so
|
|
some editorial change is needed in any event:
|
|
<p/>
|
|
18.10 [support.runtime] para 1:
|
|
</p>
|
|
<blockquote><p>
|
|
Headers <tt><csetjmp></tt> (nonlocal jumps), <tt><csignal></tt> (signal handling), <tt><cstdalign></tt>
|
|
(alignment), <tt><cstdarg></tt> (variable arguments), <tt><cstdbool></tt> (<tt>__bool_true_false_are_defined</tt>).
|
|
<tt><cstdlib></tt> (runtime environment <tt>getenv()</tt>, <tt>system()</tt>), and <tt><ctime></tt>
|
|
(system clock <tt>clock()</tt>, <tt>time()</tt>) provide further compatibility with C code.
|
|
</p></blockquote>
|
|
<p>
|
|
However, para 2 says
|
|
</p>
|
|
<blockquote><p>
|
|
"The contents of these headers are the same as the Standard C library headers <tt><setjmp.h></tt>,
|
|
<tt><signal.h></tt>, <tt><stdalign.h></tt>, <tt><stdarg.h></tt>, <tt><stdbool.h></tt>,
|
|
<tt><stdlib.h></tt>, and <tt><time.h></tt>, respectively, with the following
|
|
changes:",
|
|
</p></blockquote>
|
|
<p>
|
|
and para 8 says
|
|
</p>
|
|
<blockquote><p>
|
|
"The header <tt><cstdbool></tt> and the header <tt><stdbool.h></tt> shall
|
|
not define macros named <tt>bool</tt>, <tt>true</tt>, or <tt>false</tt>."
|
|
</p></blockquote>
|
|
<p>
|
|
Thus para 8 doesn't exempt the C++ implementation from the arguably clear requirement of the C standard, to
|
|
provide a macro named <tt>__bool_true_false_are_defined</tt> defined to be 1.
|
|
<p/>
|
|
Real implementations of the C++ library differ, so the user cannot count upon any consistency; furthermore, the
|
|
usefulness of the transition tool has faded long ago.
|
|
<p/>
|
|
That's why my suggestion is that both C and C++ standards should eliminate any mention of
|
|
<tt>__bool_true_false_are_defined</tt>. In that case, the name belongs to implementers to provide, or not, as
|
|
they choose.
|
|
</p>
|
|
|
|
<p><i>[2013-03-15 Issues Teleconference]</i></p>
|
|
|
|
<p>
|
|
Moved to Open.
|
|
</p>
|
|
<p>
|
|
While not strictly necessary, the clean-up look good.
|
|
</p>
|
|
<p>
|
|
We would like to hear from our C liaison before moving on this issue though.
|
|
</p>
|
|
|
|
<p><i>[2015-05 Lenexa]</i></p>
|
|
|
|
<p>
|
|
LWG agrees. Jonathan provides wording.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N4296.</p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>Edit the footnote on 17.6.1.2 [headers] p7:</p>
|
|
<blockquote>
|
|
<p>
|
|
176) In particular, including <ins>any of</ins> the standard header<ins>s <tt><stdbool.h></tt>, <tt><cstdbool></tt>,</ins> <tt><iso646.h></tt> or <tt><ciso646></tt> has no effect.
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Edit 18.10 [support.runtime] p1 as indicated (and remove the index entry for <tt>__bool_true_false_are_defined</tt>):</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-1- Headers <tt><csetjmp></tt> (nonlocal jumps), <tt><csignal></tt> (signal handling), <tt><cstdalign></tt> (alignment), <tt><cstdarg></tt> (variable arguments), <tt><cstdbool></tt><ins>,</ins><del> (<tt>__bool_true_false_are_defined</tt>).</del> <tt><cstdlib></tt> (runtime environment <tt>getenv()</tt>, <tt>system()</tt>), and <tt><ctime></tt> (system clock <tt>clock()</tt>, <tt>time()</tt>) provide further compatibility with C code.
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Remove Table 38 — Header <tt><cstdbool></tt> synopsis [tab:support.hdr.cstdbool] from 18.10 [support.runtime] </p>
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption> Table 38 — Header <tt><cstdbool></tt> synopsis </caption>
|
|
<tr><td><b>Type</b></td><td><b>Name(s)</b></td></tr>
|
|
<tr><td><b>Macro:</b></td><td><tt>__bool_true_false_are_defined</tt></td></tr>
|
|
</table>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2156"></a>2156. Unordered containers' <tt>reserve(n)</tt> reserves for <tt>n-1</tt> elements</h3>
|
|
<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Daniel James <b>Opened:</b> 2012-05-07 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#unord.req">issues</a> in [unord.req].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
I think that unordered containers' <tt>reserve</tt> doesn't quite do what it should. I'd expect after calling
|
|
<tt>x.reserve(n)</tt> to be able to insert <tt>n</tt> elements without invalidating iterators. But as
|
|
the standard is written (I'm looking at n3376), I think the guarantee only holds for <tt>n-1</tt> elements.
|
|
<p/>
|
|
For a container with <tt>max_load_factor</tt> of <tt>1</tt>, <tt>reserve(n)</tt> is equivalent to
|
|
<tt>rehash(ceil(n/1))</tt>, ie. <tt>rehash(n)</tt>. <tt>rehash(n)</tt> requires that the bucket
|
|
count is <tt>>= n</tt>, so it can be <tt>n</tt> (Table 103). The rule is that <tt>insert</tt>
|
|
shall not affect the validity of iterators if <tt>(N + n) < z * B</tt> (23.2.5 [unord.req] p15).
|
|
But for this case the two sides of the equation are equal, so <tt>insert</tt> can affect the validity of iterators.
|
|
</p>
|
|
|
|
<p><i>[2013-03-16 Howard comments and provides wording]</i></p>
|
|
|
|
|
|
<p>
|
|
Given the following:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
LF := load_factor()
|
|
MLF := max_load_factor()
|
|
S := size()
|
|
B := bucket_count()
|
|
|
|
LF == S/B
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
The container has an invariant:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
LF <= MLF
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
Therefore:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
MLF >= S/B
|
|
S <= MLF * B
|
|
B >= S/MLF
|
|
</pre></blockquote>
|
|
|
|
<p><i>[2013-03-15 Issues Teleconference]</i></p>
|
|
|
|
<p>
|
|
Moved to Open.
|
|
</p>
|
|
<p>
|
|
Howard to provide rationale and potentally revised wording.
|
|
</p>
|
|
|
|
|
|
<p><i>[2012-02-12 Issaquah : recategorize as P3]</i></p>
|
|
|
|
<p>
|
|
Jonathon Wakely: submitter is Boost.Hash maintainer. Think it's right.
|
|
</p>
|
|
|
|
<p>
|
|
Marshall Clow: even if wrong it's more right than what we have now
|
|
</p>
|
|
|
|
<p>
|
|
Geoffrey Romer: issue is saying rehash should not leave container in such a state that a notional insertion of zero elements should not trigger a rehash
|
|
</p>
|
|
|
|
<p>
|
|
AJM: e.g. if you do a range insert from an empty range
|
|
</p>
|
|
|
|
<p>
|
|
AJM: we don't have enough brainpower to do this now, so not priority zero
|
|
</p>
|
|
|
|
<p>
|
|
Recategorised as P3
|
|
</p>
|
|
|
|
<p><i>[Lenexa 2015-05-06: Move to Ready]</i></p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3485.</p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>
|
|
In 23.2.5 [unord.req] Table 103 — Unordered associative container requirements, change the post-condition
|
|
in the row for <code>a.rehash(n)</code> to:
|
|
</p>
|
|
<blockquote>
|
|
Post: <code>a.bucket_count() ><ins>=</ins> a.size() / a.max_load_factor()</code> and <code>a.bucket_count() >= n</code>.
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
In 23.2.5 [unord.req]/p15 change
|
|
</p>
|
|
<blockquote>
|
|
The <code>insert</code> and <code>emplace</code> members shall not affect the validity of iterators if
|
|
<code>(N+n) <<ins>=</ins> z * B</code>, where <code>N</code> is the number of elements in the container
|
|
prior to the insert operation, <code>n</code> is the number of elements inserted, <code>B</code> is the container's
|
|
bucket count, and <code>z</code> is the container's maximum load factor.
|
|
</blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2157"></a>2157. How does <tt>std::array<T,0></tt> initialization work when <tt>T</tt> is not default-constructible?</h3>
|
|
<p><b>Section:</b> 23.3.2.8 [array.zero] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Daryle Walker <b>Opened:</b> 2012-05-08 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#array.zero">issues</a> in [array.zero].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
Objects of <tt>std::array<T,N></tt> are supposed to be initialized with aggregate initialization (when
|
|
not the destination of a copy or move). This clearly works when <tt>N</tt> is positive. What happens when <tt>N</tt>
|
|
is zero? To continue using an (inner) set of braces for initialization, a <tt>std::array<T,0></tt> implementation
|
|
must have an array member of at least one element, and let default initialization take care of those secret elements.
|
|
This cannot work when <tt>T</tt> has a set of constructors and the default constructor is deleted from that set.
|
|
Solution: Add a new paragraph in 23.3.2.8 [array.zero]:
|
|
</p>
|
|
<blockquote><p>
|
|
The unspecified internal structure of array for this case shall allow initializations like:
|
|
</p>
|
|
<blockquote><pre>
|
|
array<T, 0> a = { };
|
|
</pre></blockquote>
|
|
<p>
|
|
and said initializations must be valid even when <tt>T</tt> is not default-constructible.
|
|
</p></blockquote>
|
|
|
|
<p><i>[2012, Portland: Move to Open]</i></p>
|
|
|
|
<p>
|
|
Some discussion to understand the issue, which is that implementations currently have freedom to implement
|
|
an empty <tt>array</tt> by holding a dummy element, and so might not support value initialization, which is
|
|
surprising when trying to construct an empty container. However, this is not mandated, it is an unspecified
|
|
implementation detail.
|
|
</p>
|
|
|
|
<p>
|
|
Jeffrey points out that the implication of 23.3.2.1 [array.overview] is that this initialization syntax
|
|
must be supported by empty <tt>array</tt> objects already. This is a surprising inference that was not
|
|
obvious to the room, but consensus is that the reading is accurate, so the proposed resolution is not necessary,
|
|
although the increased clarity may be useful.
|
|
</p>
|
|
|
|
<p>
|
|
Further observation is that the same clause effectively implies that <tt>T</tt> must always be DefaultConstructible,
|
|
regardless of <tt>N</tt> for the same reasons - as an <i>initializer-list</i> may not supply enough values, and the
|
|
remaining elements must all be value initialized.
|
|
</p>
|
|
|
|
<p>
|
|
Concern that we are dancing angels on the head of pin, and that relying on such subtle implications in wording is
|
|
not helpful. We need a clarification of the text in this area, and await wording.
|
|
</p>
|
|
|
|
<p><i>[2015-02 Cologne]</i></p>
|
|
|
|
<p>
|
|
DK: What was the outcome of Portland? AM: Initially we thought we already had the intended behaviour.
|
|
We concluded that <tt>T</tt> must always be <tt>DefaultConstructible</tt>, but I'm not sure why. GR: It's p2 in
|
|
<tt>std::array</tt>, "up to <tt>N</tt>". AM: That wording already implies that "<tt>{}</tt>" has to work when <tt>N</tt>
|
|
is zero. But the wording of p2 needs to be fixed to make clear that it does <em>not</em> imply that <tt>T</tt> must be
|
|
<tt>DefaultConstructible</tt>.
|
|
<p/>
|
|
Conclusion: Update wording, revisit later.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3376.</p>
|
|
|
|
<p>Add the following new paragraph between the current 23.3.2.8 [array.zero] p1 and p2:</p>
|
|
|
|
<blockquote><p>
|
|
-1- <tt>array</tt> shall provide support for the special case <tt>N == 0</tt>.
|
|
<p/>
|
|
<ins>-?- The unspecified internal structure of <tt>array</tt> for this case shall allow initializations like:</ins>
|
|
</p>
|
|
<blockquote><pre>
|
|
<ins>array<T, 0> a = { };</ins>
|
|
</pre></blockquote>
|
|
<p>
|
|
<ins>and said initializations must be valid even when <tt>T</tt> is not default-constructible.</ins>
|
|
<p/>
|
|
-2- In the case that <tt>N == 0</tt>, <tt>begin() == end() ==</tt> unique value. The return value of
|
|
<tt>data()</tt> is unspecified.
|
|
<p/>
|
|
-3- The effect of calling <tt>front()</tt> or <tt>back()</tt> for a zero-sized array is undefined.
|
|
<p/>
|
|
-4- Member function <tt>swap()</tt> shall have a <em>noexcept-specification</em> which is equivalent to
|
|
<tt>noexcept(true)</tt>.
|
|
</p></blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2158"></a>2158. Conditional copy/move in <tt>std::vector</tt></h3>
|
|
<p><b>Section:</b> 23.3.6.3 [vector.capacity] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Nikolay Ivchenkov <b>Opened:</b> 2012-05-08 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#vector.capacity">active issues</a> in [vector.capacity].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
There are various operations on <tt>std::vector</tt> that can cause elements of the vector to be
|
|
moved from one location to another. A move operation can use either rvalue or const lvalue as
|
|
argument; the choice depends on the value of <tt>!is_nothrow_move_constructible<T>::value &&
|
|
is_copy_constructible<T>::value</tt>, where <tt>T</tt> is the element type. Thus, some operations
|
|
on <tt>std::vector</tt> (e.g. 'resize' with single parameter, 'reserve', 'emplace_back') should have
|
|
conditional requirements. For example, let's consider the requirement for 'reserve' in N3376 –
|
|
23.3.6.3 [vector.capacity]/2:
|
|
</p>
|
|
<blockquote><p>
|
|
<i>Requires</i>: <tt>T</tt> shall be <tt>MoveInsertable</tt> into <tt>*this</tt>.
|
|
</p></blockquote>
|
|
<p>
|
|
This requirement is not sufficient if an implementation is free to select copy constructor when
|
|
<tt>!is_nothrow_move_constructible<T>::value && is_copy_constructible<T>::value</tt>
|
|
evaluates to true. Unfortunately, <tt>is_copy_constructible</tt> cannot reliably determine whether
|
|
<tt>T</tt> is really copy-constructible. A class may contain public non-deleted copy constructor whose
|
|
definition does not exist or cannot be instantiated successfully (e.g.,
|
|
<tt>std::vector<std::unique_ptr<int>></tt> has copy constructor, but this type is not
|
|
copy-constructible). Thus, the actual requirements should be:
|
|
</p>
|
|
<ul>
|
|
<li><p>
|
|
if <tt>!is_nothrow_move_constructible<T>::value && is_copy_constructible<T>::value</tt>
|
|
then <tt>T</tt> shall be <tt>CopyInsertable</tt> into <tt>*this</tt>;
|
|
</p></li>
|
|
<li><p>
|
|
otherwise <tt>T</tt> shall be <tt>MoveInsertable</tt> into <tt>*this</tt>.
|
|
</p></li>
|
|
</ul>
|
|
<p>
|
|
Maybe it would be useful to introduce a new name for such conditional requirement (in addition to
|
|
"<tt>CopyInsertable</tt>" and "<tt>MoveInsertable</tt>").
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2161"></a>2161. <tt>const</tt> equivalence of <tt>std::map</tt></h3>
|
|
<p><b>Section:</b> 23.4 [associative], 23.5 [unord] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Bjarne Stroustrup <b>Opened:</b> 2012-06-18 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#associative">active issues</a> in [associative].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#associative">issues</a> in [associative].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
As described in the reflector discussion c++std-core-21860 consider the following example:
|
|
</p>
|
|
<blockquote><pre>
|
|
map<const int, int> mci{};
|
|
map<int, int> mi = mci; // ??
|
|
mci[1] = 2;
|
|
mi[1] = 2;
|
|
</pre></blockquote>
|
|
<p>
|
|
Should it be required that the marked initialization is well-formed? As a possible solution
|
|
this could be realized by an alias template:
|
|
</p>
|
|
<blockquote><pre>
|
|
template <class K, class T>
|
|
struct OriginalMap { […] };
|
|
|
|
template <class K, class T>
|
|
using ImprovedMap = OriginalMap<const K, T>;
|
|
</pre></blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2164"></a>2164. What are the semantics of <tt>vector.emplace(vector.begin(), vector.back())</tt>?</h3>
|
|
<p><b>Section:</b> 23.3.6.5 [vector.modifiers], 23.2 [container.requirements] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2012-07-07 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#vector.modifiers">active issues</a> in [vector.modifiers].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#vector.modifiers">issues</a> in [vector.modifiers].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
Nikolay Ivchenkov recently brought the following example on the
|
|
<a href="https://groups.google.com/a/isocpp.org/d/topic/std-discussion/dhy23mDFXj4/discussion">std-discussion</a>
|
|
newsgroup, asking whether the following program well-defined:
|
|
</p>
|
|
<blockquote><pre>
|
|
#include <iostream>
|
|
#include <vector>
|
|
|
|
int main()
|
|
{
|
|
std::vector<int> v;
|
|
v.reserve(4);
|
|
v = { 1, 2, 3 };
|
|
v.emplace(v.begin(), v.back());
|
|
for (int x : v)
|
|
std::cout << x << std::endl;
|
|
}
|
|
</pre></blockquote>
|
|
<p>
|
|
Nikolay Ivchenkov:
|
|
<p/>
|
|
I think that an implementation of <tt>vector</tt>'s 'emplace' should initialize an intermediate object with
|
|
<tt>v.back()</tt> before any shifts take place, then perform all necessary shifts and finally replace the
|
|
value pointed to by <tt>v.begin()</tt> with the value of the intermediate object. So, I would expect the
|
|
following output:
|
|
</p>
|
|
<blockquote><pre>
|
|
3
|
|
1
|
|
2
|
|
3
|
|
</pre></blockquote>
|
|
<p>
|
|
GNU C++ 4.7.1 and GNU C++ 4.8.0 produce other results:
|
|
</p>
|
|
<blockquote><pre>
|
|
2
|
|
1
|
|
2
|
|
3
|
|
</pre></blockquote>
|
|
<p>
|
|
Howard Hinnant:
|
|
<p/>
|
|
I believe Nikolay is correct that vector should initialize an intermediate object with <tt>v.back()</tt>
|
|
before any shifts take place. As Nikolay pointed out in another email, this appears to be the only way to
|
|
satisfy the strong exception guarantee when an exception is not thrown by <tt>T</tt>'s copy constructor,
|
|
move constructor, copy assignment operator, or move assignment operator as specified by
|
|
23.3.6.5 [vector.modifiers]/p1. I.e. if the emplace construction throws, the vector must remain unaltered.
|
|
<p/>
|
|
That leads to an implementation that tolerates objects bound to the function parameter pack of the <tt>emplace</tt>
|
|
member function may be elements or sub-objects of elements of the container.
|
|
<p/>
|
|
My position is that the standard is correct as written, but needs a clarification in this area. Self-referencing
|
|
<tt>emplace</tt> should be legal and give the result Nikolay expects. The proposed resolution of LWG <a href="lwg-active.html#760">760</a>
|
|
is not correct.
|
|
</p>
|
|
|
|
<p><i>[2015-02 Cologne]</i></p>
|
|
|
|
<p>
|
|
LWG agrees with the analysis including the assessment of LWG <a href="lwg-active.html#760">760</a> and would appreciate a concrete wording proposal.
|
|
</p>
|
|
|
|
<p><i>[2015-04-07 dyp comments]</i></p>
|
|
|
|
<p>
|
|
The Standard currently does not require that creation of such
|
|
intermediate objects is legal. 23.2.3 [sequence.reqmts] Table 100
|
|
— "Sequence container requirements" currently specifies:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 100 — Sequence container requirements</caption>
|
|
<tr>
|
|
<th>Expression</th>
|
|
<th>Return type</th>
|
|
<th>Assertion/note<br/>pre-/post-condition</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="3" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a.emplace(p, args);</tt>
|
|
</td>
|
|
<td>
|
|
<tt>iterator</tt>
|
|
</td>
|
|
<td>
|
|
<i>Requires</i>: <tt>T</tt> is <tt>EmplaceConstructible</tt> into
|
|
<tt>X</tt> from <tt>args</tt>. For <tt>vector</tt> and <tt>deque</tt>,
|
|
<tt>T</tt> is also <tt>MoveInsertable</tt> into <tt>X</tt> and
|
|
<tt>MoveAssignable</tt>. […]
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="3" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote>
|
|
|
|
<p>
|
|
The <tt>EmplaceConstructible</tt> concept is defined via
|
|
<tt>allocator_traits<A>::construct</tt> in 23.2.1 [container.requirements.general] p15.5 That's surprising to me
|
|
since the related concepts use the suffix <tt>Insertable</tt> if they
|
|
refer to the allocator. An additional requirement such as
|
|
<tt>std::is_constructible<T, Args...></tt> is necessary to allow
|
|
creation of intermediate objects.
|
|
</p>
|
|
|
|
<p>
|
|
The creation of intermediate objects also affects other functions, such
|
|
as <tt>vector.insert</tt>. Since aliasing the vector is only allowed for
|
|
the single-element forms of <tt>insert</tt> and <tt>emplace</tt> (see
|
|
<a href="lwg-closed.html#526">526</a>), the range-forms are not affected. Similarly,
|
|
aliasing is not allowed for the rvalue-reference overload. See also LWG
|
|
<a href="lwg-defects.html#2266">2266</a>.
|
|
</p>
|
|
|
|
<p>
|
|
There might be a problem with a requirement of
|
|
<tt>std::is_constructible<T, Args...></tt> related to the issues
|
|
described in LWG <a href="lwg-active.html#2461">2461</a>. For example, a scoped allocator
|
|
adapter passes additional arguments to the constructor of the value
|
|
type. This is currently not done in recent implementations of libstdc++
|
|
and libc++ when creating the intermediate objects, they simply create
|
|
the intermediate object by perfectly forwarding the arguments. If such
|
|
an intermediate object is then moved to its final destination in the
|
|
vector, a change of the allocator instance might be required —
|
|
potentially leading to an expensive copy. One can also imagine worse
|
|
problems, such as run-time errors (allocators not comparing equal at
|
|
run-time) or compile-time errors (if the value type cannot be created
|
|
without the additional arguments). I have not looked in detail into this
|
|
issue, but I'd be reluctant adding a requirement such as
|
|
<tt>std::is_constructible<T, Args...></tt> without further
|
|
investigation.
|
|
</p>
|
|
|
|
<p>
|
|
It should be noted that the creation of intermediate objects currently
|
|
is inconsistent in libstdc++ vs libc++. For example, libstdc++ creates
|
|
an intermediate object for <tt>vector.insert</tt>, but not
|
|
<tt>vector.emplace</tt>, whereas libc++ does the exact opposite in this
|
|
respect.
|
|
</p>
|
|
|
|
<p>
|
|
A live demo of the inconsistent creation of intermediate objects can be
|
|
found <a href="http://coliru.stacked-crooked.com/a/449253d3d329ef4c">here</a>.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2165"></a>2165. <tt>std::atomic<X></tt> requires <tt>X</tt> to be nothrow default constructible</h3>
|
|
<p><b>Section:</b> 29.5 [atomics.types.generic], 29.6 [atomics.types.operations] <b>Status:</b> <a href="lwg-active.html#Core">Core</a>
|
|
<b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2012-07-19 <b>Last modified:</b> 2015-04-09</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#atomics.types.generic">active issues</a> in [atomics.types.generic].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#atomics.types.generic">issues</a> in [atomics.types.generic].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Core">Core</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
As raised in c++std-lib-32781, this fails to compile even though the default constructor is not used:
|
|
</p>
|
|
<blockquote><pre>
|
|
#include <atomic>
|
|
|
|
struct X {
|
|
X() noexcept(false) {}
|
|
X(int) { }
|
|
};
|
|
|
|
std::atomic<X> x(3);
|
|
</pre></blockquote>
|
|
<p>This is because <tt>atomic<T></tt>'s default constructor is declared to be non-throwing and
|
|
is explicitly-defaulted on its first declaration:
|
|
</p>
|
|
<blockquote><pre>
|
|
atomic() noexcept = default;
|
|
</pre></blockquote>
|
|
<p>
|
|
This is ill-formed if the implicitly-declared default constructor would not be non-throwing.
|
|
<p/>
|
|
Possible solutions:
|
|
</p>
|
|
<ol>
|
|
<li>
|
|
Add nothrow default constructible to requirements for template argument of the generic <tt>atomic<T></tt>
|
|
</li>
|
|
<li>
|
|
Remove <tt>atomic<T>::atomic()</tt> from the overload set if <tt>T</tt> is not nothrow default constructible.
|
|
</li>
|
|
<li>
|
|
Remove <tt>noexcept</tt> from <tt>atomic<T>::atomic()</tt>, allowing it to be
|
|
deduced (but the default constructor is intended to be always noexcept)
|
|
</li>
|
|
<li>
|
|
Do not default <tt>atomic<T>::atomic()</tt> on its first declaration (but makes the default constructor
|
|
user-provided and so prevents <tt>atomic<T></tt> being trivial)
|
|
</li>
|
|
<li>
|
|
A core change to allow the mismatched exception specification if the default constructor isn't used
|
|
(see c++std-core-21990)
|
|
</li>
|
|
</ol>
|
|
|
|
<p><i>[2012, Portland: move to Core]</i></p>
|
|
|
|
<p>
|
|
Recommend referring to core to see if the constructor <tt>noexcept</tt> mismatch
|
|
can be resolved there. The issue is not specific to concurrency.
|
|
</p>
|
|
|
|
<p><i>[2015-04-09 Daniel comments]</i></p>
|
|
|
|
<p>
|
|
CWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1778">1778</a>, which had
|
|
been created in behalf of this LWG issue, has been resolved as a defect.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2166"></a>2166. Heap property underspecified?</h3>
|
|
<p><b>Section:</b> 25.4.6 [alg.heap.operations] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Peter Sommerlad <b>Opened:</b> 2012-07-09 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#alg.heap.operations">issues</a> in [alg.heap.operations].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
Another similar issue to the <tt>operator<</tt> vs greater in <tt>nth_element</tt> but not as direct occurs
|
|
in 25.4.6 [alg.heap.operations]:
|
|
</p>
|
|
<blockquote><p>
|
|
-1- A <em>heap</em> is a particular organization of elements in a range between two random access iterators
|
|
<tt>[a,b)</tt>. Its two key properties are:
|
|
</p>
|
|
<ol>
|
|
<li>There is no element greater than <tt>*a</tt> in the range and
|
|
</li>
|
|
<li><tt>*a</tt> may be removed by <tt>pop_heap()</tt>, or a new element added by <tt>push_heap()</tt>, in
|
|
O(log(<tt>N</tt>)) time.
|
|
</li>
|
|
</ol>
|
|
</blockquote>
|
|
<p>
|
|
As noted by Richard Smith, it seems that the first bullet should read:
|
|
</p>
|
|
<blockquote><p>
|
|
<tt>*a</tt> is not less than any element in the range
|
|
</p></blockquote>
|
|
<p>
|
|
Even better the heap condition could be stated here directly, instead of leaving it unspecified, i.e.,
|
|
</p>
|
|
<blockquote><p>
|
|
Each element at <tt>(a+2*i+1)</tt> and <tt>(a+2*i+2)</tt> is less than the element at <tt>(a+i)</tt>,
|
|
if those elements exist, for <tt>i>=0</tt>.
|
|
</p></blockquote>
|
|
<p>
|
|
But may be that was may be intentional to allow other heap organizations?
|
|
<p/>
|
|
See also follow-up discussion of c++std-lib-32780.
|
|
<p/>
|
|
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2173"></a>2173. The meaning of operator + in the description of the algorithms</h3>
|
|
<p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Nikolay Ivchenkov <b>Opened:</b> 2012-08-01 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#algorithms">active issues</a> in [algorithms].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#algorithms">issues</a> in [algorithms].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
According to 25.1 [algorithms.general]/12,
|
|
</p>
|
|
<blockquote><p>
|
|
In the description of the algorithms operators <tt>+</tt> and <tt>-</tt> are used for some of the iterator categories
|
|
for which they do not have to be defined. In these cases the semantics of <tt>a+n</tt> is the same as that of
|
|
</p>
|
|
<blockquote><pre>
|
|
X tmp = a;
|
|
advance(tmp, n);
|
|
return tmp;
|
|
</pre></blockquote>
|
|
</blockquote>
|
|
<p>
|
|
There are several places where such operator <tt>+</tt> is applied to an output iterator — for example, see the
|
|
description of <tt>std::copy</tt>:
|
|
</p>
|
|
<blockquote><pre>
|
|
template<class InputIterator, class OutputIterator>
|
|
OutputIterator copy(InputIterator first, InputIterator last,
|
|
OutputIterator result);
|
|
</pre>
|
|
<blockquote><p>
|
|
-1- <i>Effects</i>: Copies elements in the range <tt>[first,last)</tt> into the range <tt>[result,result + (last -
|
|
first))</tt> starting from <tt>first</tt> and proceeding to <tt>last</tt>. For each non-negative integer
|
|
<tt>n < (last - first)</tt>, performs <tt>*(result + n) = *(first + n)</tt>.
|
|
</p></blockquote></blockquote>
|
|
<p>
|
|
<tt>std::advance</tt> is not supposed to be applicable to output iterators, so we need a different method of description.
|
|
<p/>
|
|
See also message <a href="http://accu.org/cgi-bin/wg21/message?wg=lib&msg=32908">c++std-lib-32908</a>.
|
|
</p>
|
|
|
|
<p><i>[2014-06-07 Daniel comments and provides wording]</i></p>
|
|
|
|
<p>
|
|
The specification for output iterators is somewhat tricky, because here a sequence of increments is required to
|
|
be combined with intervening <em>assignments</em> to the dereferenced iterator. I tried to respect this
|
|
fact by using a conceptual assignment operation as part of the specification.
|
|
<p/>
|
|
Another problem in the provided as-if-code is the question which requirements are imposed on <tt>n</tt>. Unfortunately,
|
|
the corresponding function <tt>advance</tt> is completely underspecified in this regard, so I couldn't borrow wording
|
|
from it. We cannot even assume here that <tt>n</tt> is the difference type of the iterator, because for output iterators there is
|
|
no requirements for this associated type to be defined. The presented wording attempts to minimize assumptions, but still
|
|
can be considered as controversial.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 25.1 [algorithms.general] around p12 as indicated:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-12- In the description of the algorithms operators <tt>+</tt> and <tt>-</tt> are used for some of the iterator categories for which
|
|
they do not have to be defined. In these cases the semantics of <tt>a+n</tt> is the same as that of
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
X tmp = a;
|
|
advance(tmp, n);
|
|
return tmp;
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
<ins>when <tt>X</tt> meets the input iterator requirements (24.2.3 [input.iterators]), otherwise it is the same as that of</ins>
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
<ins>X tmp = a;
|
|
for (auto i = n; i; ++tmp, (void) --i)
|
|
*tmp = <i>Expr</i>(i);
|
|
return tmp;</ins>
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
<ins>where <tt><i>Expr</i>(i)</tt> denotes the <tt>n-i</tt>-th expression that is assigned to for the corresponding algorithm;</ins>
|
|
and that of <tt>b-a</tt> is the same as of
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
return distance(a, b);
|
|
</pre>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2178"></a>2178. <tt>Allocator</tt> requirement changes not mentioned Annex C</h3>
|
|
<p><b>Section:</b> 17.6.3.5 [allocator.requirements], C.5 [diff.library] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Nevin Liber <b>Opened:</b> 2012-08-14 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
Given that a number of things were removed from the allocator requirements (<tt>reference</tt>, <tt>const_reference</tt>,
|
|
<tt>address()</tt> in 17.6.3.5 [allocator.requirements]), it seems that these incompatible changes should be
|
|
mentioned in Annex C.5 [diff.library], more specifically in [diff.cpp03].
|
|
</p>
|
|
|
|
<p><i>[
|
|
2012-10 Portland: Move to Open
|
|
]</i></p>
|
|
|
|
|
|
<p>
|
|
It was clearly pointed out by Bill during the C++11 process that our change to allocator requirements
|
|
potentially broke 3rd party user containers written to expect C++03 allocators, or rather, an
|
|
allocator written to the minimal requirements of C++11 might not be guaranteed to work with a container
|
|
written to the previous rules. This was a trade-off in making allocaters easier to write by use of
|
|
the <tt>allocator_traits</tt> framework.
|
|
</p>
|
|
|
|
<p>
|
|
This probably does merit a write-up in Annex C, and we look forward to seeing wording. Until then,
|
|
the best we can do is move the issue to Open.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2179"></a>2179. <tt>enable_shared_from_this</tt> and construction from raw pointers</h3>
|
|
<p><b>Section:</b> 20.8.2.5 [util.smartptr.enab], 20.8.2.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2012-08-16 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
On reflector message <a href="http://accu.org/cgi-bin/wg21/message?wg=lib&msg=32927">c++std-lib-32927</a>,
|
|
Matt Austern asked whether the following example should be well-defined or not
|
|
</p>
|
|
<blockquote><pre>
|
|
struct X : public enable_shared_from_this<X> { };
|
|
auto xraw = new X;
|
|
shared_ptr<X> xp1(xraw);
|
|
shared_ptr<X> xp2(xraw);
|
|
</pre></blockquote>
|
|
<p>
|
|
pointing out that 20.8.2.2.1 [util.smartptr.shared.const] does not seem to allow it, since
|
|
<tt>xp1</tt> and <tt>xp2</tt> aren't allowed to share ownership, because each of them is required to have
|
|
<tt>use_count() == 1</tt>. Despite this wording it might be reasonable (and technical possible)
|
|
to implement that request.
|
|
<p/>
|
|
On the other hand, there is the non-normative note in 20.8.2.5 [util.smartptr.enab] p11 (already part of TR1):
|
|
</p>
|
|
<blockquote><p>
|
|
The <tt>shared_ptr</tt> constructors that <span style="color:#C80000;font-weight:bold">create unique pointers</span>
|
|
can detect the presence of an <tt>enable_shared_from_this</tt> base and assign the newly created <tt>shared_ptr</tt>
|
|
to its <tt>__weak_this member</tt>.
|
|
</p></blockquote>
|
|
<p>
|
|
Now according to the specification in 20.8.2.2.1 [util.smartptr.shared.const] p3-7:
|
|
</p>
|
|
<blockquote><pre>
|
|
template<class Y> explicit shared_ptr(Y* p);
|
|
</pre></blockquote>
|
|
<p>
|
|
the notion of <em>creating unique pointers</em> can be read to be included by this note, because the post-condition
|
|
of this constructor is <tt>unique() == true</tt>. Evidence for this interpretation seems to be weak, though.
|
|
<p/>
|
|
Howard Hinnant presented the counter argument, that actually the following is an "anti-idiom" and it seems questionable
|
|
to teach it to be well-defined in any case:
|
|
</p>
|
|
<blockquote><pre>
|
|
auto xraw = new X;
|
|
shared_ptr<X> xp1(xraw);
|
|
shared_ptr<X> xp2(xraw);
|
|
</pre></blockquote>
|
|
<p>
|
|
He also pointed out that the current post-conditions of the affected <tt>shared_ptr</tt> constructor
|
|
would need to be reworded.
|
|
<p/>
|
|
It needs to be decided, which direction to follow. If this idiom seems too much broken to be supported,
|
|
the note could be improved. If it should be supported, the constructors in
|
|
20.8.2.2.1 [util.smartptr.shared.const] need a careful analysis to ensure that post-conditions
|
|
are correct.
|
|
<p/>
|
|
Several library implementations currently do not support this example, instead they typically
|
|
cause a crash. Matt points out that there are currently no explicit requirements imposed on
|
|
<tt>shared_ptr</tt> objects to prevent them from owning the same underlying object without sharing the
|
|
ownership. It might be useful to add such a requirement.
|
|
</p>
|
|
|
|
<p><i>[2013-03-15 Issues Teleconference]</i></p>
|
|
|
|
<p>
|
|
Moved to Open.
|
|
</p>
|
|
<p>
|
|
More discussion is needed to pick a direction to guide a proposed resolution.
|
|
</p>
|
|
|
|
<p><i>[2013-05-09 Jonathan comments]</i></p>
|
|
|
|
<p>
|
|
The note says the newly created <tt>shared_ptr</tt> is assigned to the <tt>weak_ptr</tt> member. It doesn't
|
|
say before doing that the <tt>shared_ptr</tt> should check if the <tt>weak_ptr</tt> is non-empty and possibly
|
|
share ownership with some other pre-existing <tt>shared_ptr</tt>.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2181"></a>2181. Exceptions from <em>seed sequence</em> operations</h3>
|
|
<p><b>Section:</b> 26.5.1.2 [rand.req.seedseq], 26.5.3 [rand.eng], 26.5.4 [rand.adapt] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2012-08-18 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#rand.req.seedseq">issues</a> in [rand.req.seedseq].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
LWG issue <a href="lwg-defects.html#2180">2180</a> points out some deficiences in regard to the specification of the library-provided
|
|
type <tt>std::seed_seq</tt> regarding exceptions, but there is another specification problem
|
|
in regard to general types satisfying the <em>seed sequence</em> constraints (named <tt>SSeq</tt>) as described in
|
|
26.5.1.2 [rand.req.seedseq].
|
|
<p/>
|
|
26.5.3 [rand.eng] p3 and 26.5.4.1 [rand.adapt.general] p3 say upfront:
|
|
</p>
|
|
<blockquote><p>
|
|
Except where specified otherwise, no function described in this section
|
|
26.5.3 [rand.eng]/26.5.4 [rand.adapt] throws an exception.
|
|
</p></blockquote>
|
|
<p>
|
|
This constraint causes problems, because the described templates in these sub-clauses depend on operations of
|
|
<tt>SSeq::generate()</tt> which is a function template, that depends both on operations provided by the
|
|
implementor of <tt>SSeq</tt> (e.g. of <tt>std::seed_seq</tt>), and those of the random access iterator type
|
|
provided by the caller. With class template <tt>linear_congruential_engine</tt> we have just one example for a user
|
|
of <tt>SSeq::generate()</tt> via:
|
|
</p>
|
|
<blockquote><pre>
|
|
template<class Sseq>
|
|
linear_congruential_engine<>::linear_congruential_engine(Sseq& q);
|
|
|
|
template<class Sseq>
|
|
void linear_congruential_engine<>::seed(Sseq& q);
|
|
</pre></blockquote>
|
|
<p>
|
|
None of these operations has an exclusion rule for exceptions.
|
|
<p/>
|
|
As described in <a href="lwg-defects.html#2180">2180</a> the wording for <tt>std::seed_seq</tt> should and can be fixed to ensure that
|
|
operations of <tt>seed_seq::generate()</tt> won't throw except from operations of the provided iterator range,
|
|
but there is no corresponding "safety belt" for user-provided <tt>SSeq</tt> types, since 26.5.1.2 [rand.req.seedseq]
|
|
does not impose no-throw requirements onto operations of <em>seed sequences</em>.
|
|
</p>
|
|
|
|
<ol style="list-style-type:upper-roman">
|
|
|
|
<li><p>
|
|
A quite radical step to fix this problem would be to impose general no-throw requirements on the expression
|
|
<tt>q.generate(rb,re)</tt> from Table 115, but this is not as simple as it looks initially, because this
|
|
function again depends on general types that are mutable random access iterators. Typically, we do not
|
|
impose no-throw requirements on iterator operations and this would restrict general seed sequences where
|
|
exceptions are not a problem. Furthermore, we do not impose comparable constraints for other expressions,
|
|
like that of the expression <tt>g()</tt> in Table 116 for good reasons, e.g. <tt>random_device::operator()</tt>
|
|
explicitly states when it throws exceptions.
|
|
</p></li>
|
|
|
|
<li><p>
|
|
A less radical variant of the previous suggestion would be to add a normative requirement on the expression
|
|
<tt>q.generate(rb,re)</tt> from Table 115 that says: "Throws nothing if operations of <tt>rb</tt> and <tt>re</tt>
|
|
do not throw exceptions". Nevertheless we typically do not describe <em>conditional</em> Throws elements in proper
|
|
requirement sets elsewhere (Container requirements excluded, they just describe the containers from Clause 23)
|
|
and this may exclude resonable implementations of seed sequences that could throw exceptions under rare
|
|
situations.
|
|
</p></li>
|
|
|
|
<li><p>
|
|
The iterator arguments provided to <tt>SSeq::generate()</tt> for operations in templates of 26.5.3 [rand.eng] and
|
|
26.5.4 [rand.adapt] are under control of implementations, so we could impose stricter exceptions requirements
|
|
on <tt>SSeq::generate()</tt> for <tt>SSeq</tt> types that are used to instantiate member templates in 26.5.3 [rand.eng]
|
|
and 26.5.4 [rand.adapt] solely.
|
|
</p></li>
|
|
|
|
<li><p>
|
|
We simply add extra wording to the introductive parts of 26.5.3 [rand.eng] and 26.5.4 [rand.adapt]
|
|
that specify that operations of the engine (adaptor) templates that depend on a template parameter <tt>SSeq</tt>
|
|
throw no exception unless <tt>SSeq::generate()</tt> throws an exception.
|
|
</p></li>
|
|
</ol>
|
|
|
|
<p>
|
|
Given these options I would suggest to apply the variant described in the fourth bullet.
|
|
<p/>
|
|
The proposed resolution attempts to reduce a lot of the redundancies of requirements in the introductory paragraphs of
|
|
26.5.3 [rand.eng] and 26.5.4 [rand.adapt] by introducing a new intermediate sub-clause
|
|
"Engine and engine adaptor class templates" following sub-clause 26.5.2 [rand.synopsis]. This approach also
|
|
solves the problem that currently 26.5.3 [rand.eng] also describes requirements that apply for
|
|
26.5.4 [rand.adapt] (Constrained templates involving the <tt>Sseq</tt> parameters).
|
|
</p>
|
|
|
|
<p><i>[2013-04-20, Bristol]</i></p>
|
|
|
|
|
|
<p>
|
|
Remove the first bullet point:
|
|
</p>
|
|
<blockquote><p>
|
|
?- Throughout this sub-clause general requirements and conventions are described that apply to every class
|
|
template specified in sub-clause 26.5.3 [rand.eng] and 26.5.4 [rand.adapt]. Phrases of the form "in those
|
|
sub-clauses" shall be interpreted as equivalent to "in sub-clauses 26.5.3 [rand.eng] and 26.5.4 [rand.adapt]".
|
|
</p></blockquote>
|
|
<p>
|
|
Replace "in those sub-clauses" with "in sub-clauses 26.5.3 [rand.eng] and 26.5.4 [rand.adapt]".
|
|
<p/>
|
|
Find another place for the wording.
|
|
<p/>
|
|
Daniel: These are requirements on the implementation not on the types. I'm not comfortable in moving it to another place
|
|
without double checking.
|
|
<p/>
|
|
Improve the text (there are 4 "for"s): <em>for</em> copy constructors, <em>for</em> copy assignment operators,
|
|
<em>for</em> streaming operators, and <em>for</em> equality and inequality operators are not shown in the synopses.
|
|
<p/>
|
|
Move the information of this paragraph to the paragraphs it refers to:
|
|
</p>
|
|
<blockquote><p>
|
|
"-?- Descriptions are provided in those sub-clauses only for engine operations that are not described in
|
|
26.5.1.4 [rand.req.eng], for adaptor operations that are not described in 26.5.1.5 [rand.req.adapt], or for
|
|
operations where there is additional semantic information. In particular, declarations for copy constructors, for
|
|
copy assignment operators, for streaming operators, and for equality and inequality operators are not shown in the synopses."
|
|
</p></blockquote>
|
|
<p>
|
|
Alisdair: I prefer duplication here than consolidation/reference to these paragraphs.
|
|
<p/>
|
|
The room showed weakly favjust or for duplication.
|
|
</p>
|
|
|
|
<p>
|
|
<strong>Previous resolution from Daniel [SUPERSEDED]:</strong>
|
|
</p>
|
|
<blockquote class="note">
|
|
<ol>
|
|
<li><p>Add a new sub-clause titled "Engine and engine adaptor class templates" following sub-clause
|
|
26.5.2 [rand.synopsis] (but at the same level) and add one further sub-clause "General" as
|
|
child of the new sub-clause as follows:
|
|
<p/>
|
|
<ins>Engine and engine adaptor class templates [rand.engadapt]</ins>
|
|
<p/>
|
|
<ins>General [rand.engadapt.general]</ins>
|
|
</p>
|
|
<blockquote><p>
|
|
<ins>-?- Throughout this sub-clause general requirements and conventions are described that apply to every class
|
|
template specified in sub-clause 26.5.3 [rand.eng] and 26.5.4 [rand.adapt]. Phrases of the
|
|
form "in those sub-clauses" shall be interpreted as equivalent to "in sub-clauses 26.5.3 [rand.eng] and
|
|
26.5.4 [rand.adapt]".
|
|
</ins>
|
|
<p/>
|
|
<ins>-?- Except where specified otherwise, the complexity of each function specified in those sub-clauses is constant.</ins>
|
|
<p/>
|
|
<ins>-?- Except where specified otherwise, no function described in those sub-clauses throws an exception.</ins>
|
|
<p/>
|
|
<ins>-?- Every function described in those sub-clauses that has a function parameter <tt>q</tt> of type
|
|
<tt>SSeq&</tt> for a template type parameter named <tt>SSeq</tt> that is different from type <tt>std::seed_seq</tt>
|
|
throws what and when the invocation of <tt>q.generate</tt> throws.</ins>
|
|
<p/>
|
|
<ins>-?- Descriptions are provided in those sub-clauses only for engine operations that are not described in
|
|
26.5.1.4 [rand.req.eng], for adaptor operations that are not described in 26.5.1.5 [rand.req.adapt],
|
|
or for operations where there is additional semantic information. In particular, declarations for copy constructors,
|
|
for copy assignment operators, for streaming operators, and for equality and inequality operators
|
|
are not shown in the synopses.</ins>
|
|
<p/>
|
|
<ins>-?- Each template specified in those sub-clauses requires one or more relationships, involving the value(s) of
|
|
its non-type template parameter(s), to hold. A program instantiating any of these templates is ill-formed if
|
|
any such required relationship fails to hold.</ins>
|
|
<p/>
|
|
<ins>-?- For every random number engine and for every random number engine adaptor <tt>X</tt> defined in those
|
|
sub-clauses:</ins>
|
|
</p>
|
|
<ul>
|
|
<li><p>
|
|
<ins>if the constructor</ins>
|
|
</p>
|
|
<blockquote><pre>
|
|
<ins>template <class Sseq> explicit X(Sseq& q);</ins>
|
|
</pre></blockquote>
|
|
<p>
|
|
<ins>is called with a type <tt>Sseq</tt> that does not qualify as a seed sequence, then this constructor shall not
|
|
participate in overload resolution;</ins>
|
|
</p>
|
|
</li>
|
|
|
|
<li><p>
|
|
<ins>if the member function</ins>
|
|
</p>
|
|
<blockquote><pre>
|
|
<ins>template <class Sseq> void seed(Sseq& q);</ins>
|
|
</pre></blockquote>
|
|
<p>
|
|
<ins>is called with a type <tt>Sseq</tt> that does not qualify as a seed sequence, then this function shall not
|
|
participate in overload resolution;</ins>
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<p>
|
|
<ins>The extent to which an implementation determines that a type cannot be a seed sequence is unspecified,
|
|
except that as a minimum a type shall not qualify as a seed sequence if it is implicitly convertible to
|
|
<tt>X::result_type</tt>.</ins>
|
|
</p>
|
|
</blockquote>
|
|
|
|
</li>
|
|
|
|
<li><p>Edit the contents of sub-clause 26.5.3 [rand.eng] as indicated:</p>
|
|
|
|
<blockquote><p>
|
|
-1- Each type instantiated from a class template specified in this section 26.5.3 [rand.eng] satisfies the
|
|
requirements of a random number engine (26.5.1.4 [rand.req.eng]) type <ins>and the general implementation
|
|
requirements specified in sub-clause [rand.engadapt.general]</ins>.
|
|
<p/>
|
|
<del>-2- Except where specified otherwise, the complexity of each function specified in this section 26.5.3 [rand.eng]
|
|
is constant.</del>
|
|
<p/>
|
|
<del>-3- Except where specified otherwise, no function described in this section 26.5.3 [rand.eng] throws an exception.</del>
|
|
<p/>
|
|
<del>-4- Descriptions are provided in this section 26.5.3 [rand.eng] only for engine operations that are not
|
|
described in 26.5.1.4 [rand.req.eng] […]</del>
|
|
<p/>
|
|
<del>-5- Each template specified in this section 26.5.3 [rand.eng] requires one or more relationships,
|
|
involving the value(s) of its non-type template parameter(s), to hold. […]</del>
|
|
<p/>
|
|
<del>-6- For every random number engine and for every random number engine adaptor <tt>X</tt> defined in this subclause
|
|
(26.5.3 [rand.eng]) and in sub-clause 26.5.3 [rand.eng]: […]</del>
|
|
</p></blockquote>
|
|
|
|
</li>
|
|
|
|
<li><p>Edit the contents of sub-clause 26.5.4.1 [rand.adapt.general] as indicated:</p>
|
|
|
|
<blockquote><p>
|
|
-1- Each type instantiated from a class template specified in this section <del>26.5.3 [rand.eng]</del><ins>26.5.4 [rand.adapt]</ins> satisfies the
|
|
requirements of a random number engine adaptor (26.5.1.5 [rand.req.adapt]) type <ins>and the general
|
|
implementation requirements specified in sub-clause [rand.engadapt.general]</ins>.
|
|
<p/>
|
|
<del>-2- Except where specified otherwise, the complexity of each function specified in this section 26.5.4 [rand.adapt]
|
|
is constant.</del>
|
|
<p/>
|
|
<del>-3- Except where specified otherwise, no function described in this section 26.5.4 [rand.adapt] throws an exception.</del>
|
|
<p/>
|
|
<del>-4- Descriptions are provided in this section 26.5.4 [rand.adapt] only for engine operations that are not
|
|
described in 26.5.1.5 [rand.req.adapt] […]</del>
|
|
<p/>
|
|
<del>-5- Each template specified in this section 26.5.4 [rand.adapt] requires one or more relationships, involving
|
|
the value(s) of its non-type template parameter(s), to hold. […]</del>
|
|
</p></blockquote>
|
|
|
|
</li>
|
|
|
|
</ol>
|
|
</blockquote>
|
|
|
|
<p><i>[2014-02-09, Daniel provides alternative resolution]</i></p>
|
|
|
|
|
|
<p><i>[Lenexa 2015-05-07: Move to Ready]</i></p>
|
|
|
|
<p>LWG 2181 exceptions from seed sequence operations</p>
|
|
<p>STL: Daniel explained that I was confused. I said, oh, seed_seq says it can throw if the RanIt throws. Daniel says the RanIts are provided by the engine. Therefore if you give a seed_seq to an engine, it cannot throw, as implied by the current normative text. So what Daniel has in the PR is correct, if slightly unnecessary. It's okay to have explicitly non-overlapping Standardese even if overlapping would be okay.</p>
|
|
<p>Marshall: And this is a case where the std:: on seed_seq is a good thing.</p>
|
|
<p>STL: Meh.</p>
|
|
<p>STL: And that was my only concern with this PR. I like the latest PR much better than the previous.</p>
|
|
<p>Marshall: Yes. There's a drive-by fix for referencing the wrong section. Other than that, the two are the same.</p>
|
|
<p>STL: Alisdair wanted the repetition instead of centralization, and I agree.</p>
|
|
<p>Marshall: Any other opinions?</p>
|
|
<p>Jonathan: I'll buy it.</p>
|
|
<p>STL: For a dollar?</p>
|
|
<p>Hwrd: I'll buy that for a nickel.</p>
|
|
<p>Marshall: Any objections to Ready? I don't see a point in Immediate.</p>
|
|
<p>Jonathan: Absolutely agree.</p>
|
|
<p>Marshall: 7 for ready, 0 opposed, 0 abstain.</p>
|
|
|
|
<p><i>[2014-05-22, Daniel syncs with recent WP]</i></p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Edit the contents of sub-clause 26.5.3 [rand.eng] as indicated:</p>
|
|
|
|
<blockquote><p>
|
|
-1- Each type instantiated from a class template specified in this section 26.5.3 [rand.eng] satisfies the
|
|
requirements of a random number engine (26.5.1.4 [rand.req.eng]) type.
|
|
<p/>
|
|
-2- Except where specified otherwise, the complexity of each function specified in this section 26.5.3 [rand.eng]
|
|
is constant.
|
|
<p/>
|
|
-3- Except where specified otherwise, no function described in this section 26.5.3 [rand.eng] throws an exception.
|
|
<p/>
|
|
<ins>-?- Every function described in this section 26.5.3 [rand.eng] that has a function parameter <tt>q</tt> of
|
|
type <tt>Sseq&</tt> for a template type parameter named <tt>Sseq</tt> that is different from type <tt>std::seed_seq</tt>
|
|
throws what and when the invocation of <tt>q.generate</tt> throws.</ins>
|
|
<p/>
|
|
-4- Descriptions are provided in this section 26.5.3 [rand.eng] only for engine operations that are not
|
|
described in 26.5.1.4 [rand.req.eng] or for operations where there is additional semantic information. In particular,
|
|
declarations for copy constructors, <del>for</del> copy assignment operators, <del>for</del> streaming operators, <del>and
|
|
for</del> equality <ins>operators,</ins> and inequality operators are not shown in the synopses.
|
|
<p/>
|
|
-5- Each template specified in this section 26.5.3 [rand.eng] requires one or more relationships,
|
|
involving the value(s) of its non-type template parameter(s), to hold. A program instantiating any of these templates is
|
|
ill-formed if any such required relationship fails to hold.
|
|
<p/>
|
|
-6- For every random number engine and for every random number engine adaptor <tt>X</tt> defined in this subclause
|
|
(26.5.3 [rand.eng]) and in sub-clause 26.5.4 [rand.adapt]:
|
|
</p>
|
|
<ul>
|
|
<li><p>
|
|
if the constructor
|
|
</p>
|
|
<blockquote><pre>
|
|
template <class Sseq> explicit X(Sseq& q);
|
|
</pre></blockquote>
|
|
<p>
|
|
is called with a type <tt>Sseq</tt> that does not qualify as a seed sequence, then this constructor shall not
|
|
participate in overload resolution;
|
|
</p>
|
|
</li>
|
|
<li><p>
|
|
if the member function
|
|
</p>
|
|
<blockquote><pre>
|
|
template <class Sseq> void seed(Sseq& q);
|
|
</pre></blockquote>
|
|
<p>
|
|
is called with a type <tt>Sseq</tt> that does not qualify as a seed sequence, then this function shall not
|
|
participate in overload resolution;
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<p>
|
|
The extent to which an implementation determines that a type cannot be a seed sequence is unspecified,
|
|
except that as a minimum a type shall not qualify as a seed sequence if it is implicitly convertible to
|
|
<tt>X::result_type</tt>.
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Edit the contents of sub-clause 26.5.4.1 [rand.adapt.general] as indicated:</p>
|
|
|
|
<blockquote><p>
|
|
-1- Each type instantiated from a class template specified in this section
|
|
<del>26.5.3 [rand.eng]</del><ins>26.5.4 [rand.adapt]</ins> satisfies the requirements of a
|
|
random number engine adaptor (26.5.1.5 [rand.req.adapt]) type.
|
|
<p/>
|
|
-2- Except where specified otherwise, the complexity of each function specified in this section 26.5.4 [rand.adapt]
|
|
is constant.
|
|
<p/>
|
|
-3- Except where specified otherwise, no function described in this section 26.5.4 [rand.adapt] throws an exception.
|
|
<p/>
|
|
<ins>-?- Every function described in this section 26.5.4 [rand.adapt] that has a function parameter <tt>q</tt> of
|
|
type <tt>Sseq&</tt> for a template type parameter named <tt>Sseq</tt> that is different from type <tt>std::seed_seq</tt>
|
|
throws what and when the invocation of <tt>q.generate</tt> throws.</ins>
|
|
<p/>
|
|
-4- Descriptions are provided in this section 26.5.4 [rand.adapt] only for adaptor operations that are not
|
|
described in section 26.5.1.5 [rand.req.adapt] or for operations where there is additional semantic information. In particular,
|
|
declarations for copy constructors, <del>for</del> copy assignment operators, <del>for</del> streaming operators, <del>and for</del>
|
|
equality <ins>operators,</ins> and inequality operators are not shown in the synopses.
|
|
<p/>
|
|
-5- Each template specified in this section 26.5.4 [rand.adapt] requires one or more relationships, involving
|
|
the value(s) of its non-type template parameter(s), to hold. A program instantiating any of these templates is ill-formed if
|
|
any such required relationship fails to hold.
|
|
</p></blockquote>
|
|
</li>
|
|
|
|
<li><p>Edit the contents of sub-clause 26.5.8.1 [rand.dist.general] p2 as indicated: [<i>Drafting note</i>: These
|
|
editorial changes are just for consistency with those applied to 26.5.3 [rand.eng] and
|
|
26.5.4.1 [rand.adapt.general] — <i>end drafting note</i>]</p>
|
|
|
|
<blockquote><p>
|
|
-2- Descriptions are provided in this section 26.5.8 [rand.dist] only for distribution operations that are not
|
|
described in 26.5.1.6 [rand.req.dist] or for operations where there is additional semantic information. In particular,
|
|
declarations for copy constructors, <del>for</del> copy assignment operators, <del>for</del> streaming operators, <del>and for</del>
|
|
equality <ins>operators,</ins> and inequality operators are not shown in the synopses.
|
|
</p></blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2183"></a>2183. Muddled allocator requirements for <tt>match_results</tt> constructors</h3>
|
|
<p><b>Section:</b> 28.10.1 [re.results.const], 28.10.6 [re.results.all] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Pete Becker <b>Opened:</b> 2012-08-29 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#re.results.const">active issues</a> in [re.results.const].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#re.results.const">issues</a> in [re.results.const].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
28.10.1 [re.results.const] p1 says:
|
|
</p>
|
|
<blockquote><p>
|
|
In all <tt>match_results</tt> constructors, a copy of the <tt>Allocator</tt> argument shall be used for any memory
|
|
allocation performed by the constructor or member functions during the lifetime of the object.
|
|
</p></blockquote>
|
|
<p>
|
|
There are three constructors:
|
|
</p>
|
|
<blockquote><pre>
|
|
match_results(const Allocator& = Allocator());
|
|
match_results(const match_results& m);
|
|
match_results(match_results&& m) noexcept;
|
|
</pre></blockquote>
|
|
<p>
|
|
The second and third constructors do no have an <tt>Allocator</tt> argument, so despite the "all <tt>match_results</tt>
|
|
constructors", it is not possible to use "the <tt>Allocator</tt> argument" for the second and third constructors.
|
|
<p/>
|
|
The requirements for those two constructors also does not give any guidance. The second constructor has no language
|
|
about allocators, and the third states that the stored <tt>Allocator</tt> value is move constructed from
|
|
<tt>m.get_allocator()</tt>, but doesn't require using that allocator to allocate memory.
|
|
<p/>
|
|
The same basic problem recurs in 28.10.6 [re.results.all], which gives the required return value for
|
|
<tt>get_allocator()</tt>:
|
|
</p>
|
|
<blockquote><p>
|
|
<i>Returns</i>: A copy of the <tt>Allocator</tt> that was passed to the object's constructor or, if that allocator
|
|
has been replaced, a copy of the most recent replacement.
|
|
</p></blockquote>
|
|
<p>
|
|
Again, the second and third constructors do not take an <tt>Allocator</tt>, so there is nothing that meets this
|
|
requirement when those constructors are used.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2184"></a>2184. Muddled allocator requirements for <tt>match_results</tt> assignments</h3>
|
|
<p><b>Section:</b> 28.10.1 [re.results.const], 28.10.6 [re.results.all] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Pete Becker <b>Opened:</b> 2012-08-29 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#re.results.const">active issues</a> in [re.results.const].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#re.results.const">issues</a> in [re.results.const].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
The effects of the two assignment operators are specified in Table 141. Table 141 makes no mention of allocators,
|
|
so, presumably, they don't touch the target object's allocator. That's okay, but it leaves the question:
|
|
<tt>match_results::get_allocator()</tt> is supposed to return "A copy of the Allocator that was passed to the
|
|
object's constructor or, if that allocator has been replaced, a copy of the most recent replacement"; if assignment
|
|
doesn't replace the allocator, how can the allocator be replaced?
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2189"></a>2189. Throwing <tt>swap</tt> breaks unordered containers' state</h3>
|
|
<p><b>Section:</b> 23.2.5.1 [unord.req.except] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2012-09-23 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
The hash functor and key-comparison functor of unordered containers are allowed to throw on <tt>swap</tt>.
|
|
</p>
|
|
<p>
|
|
23.2.5.1 [unord.req.except]p3 "For unordered associative containers, no <tt>swap</tt> function throws
|
|
an exception unless that exception is thrown by the swap of the container's Hash or Pred object (if any)."
|
|
</p>
|
|
<p>
|
|
In such a case we must offer the basic exception safety guarantee, where both objects are left in valid
|
|
but unspecified states, and no resources are leaked. This yields a corrupt, un-usable container if the
|
|
first <tt>swap</tt> succeeds, but the second fails by throwing, as the functors form a matched pair.
|
|
</p>
|
|
<p>
|
|
So our basic scenario is first, swap the allocators if the allocators propagate on swap, according to
|
|
<tt>allocator_traits</tt>. Next we swap the pointers to our internal hash table data structures, so that
|
|
they match the allocators that allocated them. (Typically, this operation cannot throw). Now our containers
|
|
are back in a safely destructible state if an exception follows.
|
|
</p>
|
|
<p>
|
|
Next, let's say we swap the hash functor, and that throws. We have a corrupt data structure, in that the
|
|
buckets are not correctly indexed by the correct functors, lookups will give unpredicatable results etc.
|
|
We can safely restore a usable state by forcibly clearing each container - which does not leak resources
|
|
and leaves us with two (empty but) usable containers.
|
|
</p>
|
|
<p>
|
|
Now let us assume that the hasher swap succeeds. Next we swap the equality comparator functor, and this
|
|
too could throw. The important point to bear in mind is that these two functors form an important pairing
|
|
- two objects that compare equal by the equality functor must also hash to the same value. If we swap
|
|
one without the other, we most likely leave the container in an unusable state, even if we clear out all
|
|
elements.
|
|
</p>
|
|
<p>
|
|
1. A colleague pointed out that the solution for this is to dynamically allocate the two functors, and then
|
|
we need only swap pointers, which is not a throwing operation. And if we don't want to allocate on default
|
|
construction (a common QoI request), we might consider moving to a dynamically allocated functors whenever
|
|
<tt>swap</tt> is called, or on first insertion. Of course, allocating memory in <tt>swap</tt> is a whole
|
|
new can of worms, but this does not really sound like the design we had intended.
|
|
</p>
|
|
|
|
<p>
|
|
2. The simplest option is to say that we do not support hasher or equality functors that throw on ADL
|
|
<tt>swap</tt>. Note that the requirement is simply to not throw, rather than to be explicitly
|
|
marked as <tt>noexcept</tt>. Throwing functors are allowed, so long as we never use values that
|
|
would actually manifest a throw when used in an unordered container.
|
|
</p>
|
|
|
|
<p>
|
|
Pablo went on to give me several more options, to be sure we have a full set to consider:
|
|
</p>
|
|
<p>
|
|
3. Disallow one or the other functor from throwing. In that case, the
|
|
possibly-throwing functor must be swapped first, then the other functor,
|
|
the allocator, and the data pointer(s) afterwards (in any order -- there
|
|
was a TC that allocator assignment and swap may not throw if the
|
|
corresponding propagation trait is true.). Of course, the question
|
|
becomes: which functor is allowed to throw and which one is not?
|
|
</p>
|
|
<p>
|
|
4. Require that any successful functor <tt>swap</tt> be reliably reversible.
|
|
This is very inventive. I know of no other place in the standard where
|
|
such a requirement is stated, though I have occasionally wanted such a
|
|
guarantee.
|
|
</p>
|
|
<p>
|
|
5. Allow a failed swap to leave the containers in a state where future
|
|
insertions may fail for reasons other than is currently allowed.
|
|
Specifically, if the hash and equality functors are out of sync, all
|
|
insertions will fail. Presumably some "incompletely swapped" exception
|
|
would be thrown. This is "slightly" inventive, although people have been
|
|
discussing "radioactive" states for a while.
|
|
</p>
|
|
|
|
<p><i>[2013-03-15 Issues Teleconference]</i></p>
|
|
|
|
<p>
|
|
Moved to Open.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2191"></a>2191. Incorrect specification of <tt>match_results(match_results&&)</tt></h3>
|
|
<p><b>Section:</b> 28.10.1 [re.results.const] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Pete Becker <b>Opened:</b> 2012-10-02 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#re.results.const">active issues</a> in [re.results.const].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#re.results.const">issues</a> in [re.results.const].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
28.10.1 [re.results.const]/3: "Move-constructs an object of class <tt>match_results</tt> satisfying the same
|
|
postconditions as Table 141."
|
|
</p>
|
|
<p>
|
|
Table 141 lists various member functions and says that their results should be the results of the corresponding member
|
|
function calls on <tt>m</tt>. But <tt>m</tt> has been moved from, so the actual requirement ought to be based on the
|
|
value that <tt>m</tt> had <em>before</em> the move construction, not on <tt>m</tt> itself.
|
|
</p>
|
|
<p>
|
|
In addition to that, the requirements for the copy constructor should refer to Table 141.
|
|
<p/>
|
|
<u>Ganesh</u>:
|
|
<p/>
|
|
Also, the requirements for move-assignment should refer to Table 141. Further it seems as if in Table 141 all phrases of
|
|
"for all integers <tt>n < m.size()</tt>" should be replaced by "for all <em>unsigned</em> integers
|
|
<tt>n < m.size()</tt>".
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2192"></a>2192. Validity and return type of <tt>std::abs(0u)</tt> is unclear</h3>
|
|
<p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2012-10-02 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#c.math">issues</a> in [c.math].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
In C++03 the following two programs are invalid:
|
|
</p>
|
|
<ol style="list-style-type:upper-alpha"><li>
|
|
<blockquote><pre>
|
|
#include <cmath>
|
|
|
|
int main() {
|
|
std::abs(0u);
|
|
}
|
|
</pre></blockquote>
|
|
</li>
|
|
<li>
|
|
<blockquote><pre>
|
|
#include <cstdlib>
|
|
|
|
int main() {
|
|
std::abs(0u);
|
|
}
|
|
</pre></blockquote>
|
|
</li>
|
|
</ol>
|
|
<p>
|
|
because none of the <tt>std::abs()</tt> overloads is a best match.
|
|
</p>
|
|
<p>
|
|
In C++11 the additional "sufficient overload" rule from 26.8 [c.math] p11 (see also LWG
|
|
<a href="lwg-defects.html#2086">2086</a>) can be read to be applicable to the <tt>std::abs()</tt> overloads as well, which
|
|
can lead to the following possible conclusions:
|
|
<p/>
|
|
<ol>
|
|
<li><p>The program</p>
|
|
<blockquote><pre>
|
|
#include <type_traits>
|
|
#include <cmath>
|
|
|
|
static_assert(std::is_same<decltype(std::abs(0u)), double>(), "Oops");
|
|
|
|
int main() {
|
|
std::abs(0u); // Calls std::abs(double)
|
|
}
|
|
</pre></blockquote>
|
|
<p>
|
|
is required to be well-formed, because of sub-bullet 2 ("[..] or an integer type [..]") of
|
|
26.8 [c.math] p11 (Note that the current resolution of LWG <a href="lwg-defects.html#2086">2086</a> doesn't
|
|
fix this problem).
|
|
</p>
|
|
</li>
|
|
<li><p>Any translation unit including both <tt><cmath></tt> and <tt><cstdlib></tt>
|
|
might be ill-formed because of two conflicting requirements for the return type of the overload
|
|
<tt>std::abs(int)</tt>.
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
</p>
|
|
|
|
<p>
|
|
It seems to me that at least the second outcome is not intended, personally I think that both
|
|
are unfortunate: In contrast to all other floating-point functions explicitly listed in sub-clause
|
|
26.8 [c.math], the <tt>abs</tt> overloads have a special and well-defined meaning for
|
|
signed integers and thus have explicit overloads returning a signed integral type. I also believe that
|
|
there is no problem accepting that <tt>std::fabs(0u)</tt> is well-defined with return type <tt>double</tt>,
|
|
because the leading 'f' clearly signals that we have a floating point function here. But the expected
|
|
return type of <tt>std::abs(0u)</tt> seems less than clear to me. A very reasonable answer could be that
|
|
this has the same type as its argument type, alternatively it could be a reasonably chosen signed
|
|
integer type, or a floating point type. It should also be noted, that the corresponding
|
|
"generic type function" rule set from C99/C1x in 7.25 p2+3 is restricted to the floating-point functions
|
|
from <tt><math.h></tt> and <tt><complex.h></tt>, so cannot be applied to the <tt>abs</tt>
|
|
functions (but to the <tt>fabs</tt> functions!).
|
|
<p/>
|
|
Selecting a signed integer return type for unsigned input values can also problematic: The directly
|
|
corresponding signed integer type would give half of the possible argument values an implementation-defined
|
|
result value. Choosing the first signed integer value that can represent all positive values would solve this
|
|
problem for <tt>unsigned int</tt>, but there would be no clear answer for the input type <tt>std::uintmax_t</tt>.
|
|
</p>
|
|
<p>
|
|
Based on this it seems to me that the C++03 state in regard to unsigned integer values was the better
|
|
situation, alerting the user that this code is ambigious at the moment (This might be change with different core-language
|
|
rules as described in N3387).
|
|
</p>
|
|
|
|
<p><i>[2013-04-20, Bristol]</i></p>
|
|
|
|
|
|
<p>
|
|
Resolution: leave as new and bring it back in Chicago.
|
|
</p>
|
|
|
|
<p><i>[2013-09 Chicago]</i></p>
|
|
|
|
<p>
|
|
This issue also relates to LWG <a href="lwg-active.html#2294">2294</a>
|
|
<p/>
|
|
STL: these two issues should be bundled
|
|
<p/>
|
|
Stefanus: do what Pete says, and add overloads for unsigned to return directly
|
|
<p/>
|
|
STL: agree Consensus that this is an issue
|
|
<p/>
|
|
Walter: motion to move to Open
|
|
<p/>
|
|
STL: no wording for <a href="lwg-active.html#2294">2294</a>
|
|
<p/>
|
|
Stefanus: move to open and note the 2 issues are related and should be moved together
|
|
<p/>
|
|
Stefanus: add and define unsigned versions of <tt>abs()</tt>
|
|
</p>
|
|
|
|
<p><i>[2014-02-03 Howard comments]</i></p>
|
|
|
|
<p>
|
|
Defining <tt>abs()</tt> for unsigned integers is a bad idea. Doing so would turn compile time errors into run time errors,
|
|
especially in C++ where we have templates, and the types involved are not always apparent to the programmer at design time.
|
|
For example, consider:
|
|
</p>
|
|
<blockquote><pre>
|
|
template <class Int>
|
|
Int
|
|
analyze(Int x, Int y)
|
|
{
|
|
// ...
|
|
if (std::abs(<span style="color:#C80000;font-weight:bolder">x - y</span>) < threshold)
|
|
{
|
|
// ...
|
|
}
|
|
// ...
|
|
}
|
|
</pre></blockquote>
|
|
<p>
|
|
<tt>std::abs(<i>expr</i>)</tt> is often used to ask: Are these two numbers sufficiently close? When the assumption is that
|
|
the two numbers are signed (either signed integral, or floating point), the logic is sound. But when the same logic is
|
|
accidentally used with an arithmetic type not capable of representing negative numbers, and especially if unsigned overflow
|
|
will silently happen, then the logic is no longer correct:
|
|
</p>
|
|
<blockquote><pre>
|
|
auto i = analyze(20u, 21u); // Today a compile time error
|
|
// But with <tt>abs(unsigned)</tt> becomes a run time error
|
|
</pre></blockquote>
|
|
<p>
|
|
This is not idle speculation. Search the net for "<tt>abs unsigned</tt>"
|
|
<a href="http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=35514&start=0">here</a> or
|
|
<a href="http://fischerlaender.de/mysql/surprising-mysql-behaviour-using-unsigned-int">here</a>.
|
|
<p/>
|
|
In C++11, <tt>chrono</tt> <tt>duration</tt>s and <tt>time_point</tt>s are allowed to be based on unsigned integers. Taking the
|
|
absolute value of the difference of two such <tt>time_point</tt>s would be easy to accidentally do (say in code templated on
|
|
<tt>time_point</tt>s), and would certainly be a logic bug, caught at compile time unless we provide the error prone <tt>abs(unsigned)</tt>.
|
|
</p>
|
|
|
|
<p><i>[2015-02, Cologne]</i></p>
|
|
|
|
<p>
|
|
GR: Do we want to make the changes to both <tt><cmath></tt> and <tt><cstdlib></tt>?<br/>
|
|
AM: I think so; we should provide consistent overloads.<br/>
|
|
GR: Then we're imposing restrictions on what users put in the global namespace.<br/>
|
|
AM: I'm not so worried about that. Users already know not to use C library names.<br/>
|
|
VV: So what are we going to do about unsigned integers? AM: We will say that they are ill-formed.<br/>
|
|
AM: Does anyone volunteer to send updated wording to Daniel? GR, can you do it? GR: Sure.<br/>
|
|
GR: To clarify: we want to make unsigned types ill-formed?<br/>
|
|
AM: With promotion rank at least <tt>unsigned int</tt>.<br/>
|
|
GR: And NL suggests to just list those types.
|
|
<p/>
|
|
Conclusion: Merge the resolution into a single issue.
|
|
</p>
|
|
|
|
<strong>Previous resolution from Daniel [SUPERSEDED]:</strong>
|
|
<blockquote class = "note">
|
|
<p>This wording is relative to N3376.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 26.8 [c.math] p11 as indicated:</p>
|
|
<blockquote><p>
|
|
-11- Moreover<ins>, except for the <tt>abs</tt> functions</ins>, there shall be additional overloads sufficient to ensure:
|
|
<p/>
|
|
[…]
|
|
</p></blockquote>
|
|
</li>
|
|
</ol>
|
|
</blockquote>
|
|
|
|
<p><i>[2015-03-03, Geoffrey Romer provides improved wording]</i></p>
|
|
|
|
<p>
|
|
In the following I've drafted combined wording to resolve LWG <a href="lwg-active.html#2192">2192</a> and <a href="lwg-active.html#2294">2294</a>. Note that the first
|
|
two paragraphs are taken verbatim from the P/R of LWG <a href="lwg-active.html#2294">2294</a>, but the third is newly drafted:
|
|
</p>
|
|
|
|
<p><i>[2015-05-05 Lenexa: Howard to draft updated wording]</i></p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N4296.</p>
|
|
|
|
<ol>
|
|
<li><p>Insert the following new paragraphs after 26.8 [c.math] p7:</p>
|
|
<blockquote>
|
|
<p>
|
|
-6- In addition to the <tt>int</tt> versions of certain math functions in <tt><cstdlib></tt>, C++ adds <tt>long</tt>
|
|
and <tt>long long</tt> overloaded versions of these functions, with the same semantics.
|
|
<p/>
|
|
-7- The added signatures are:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
long abs(long); <i>// labs()</i>
|
|
long long abs(long long); <i>// llabs()</i>
|
|
ldiv_t div(long, long); <i>// ldiv()</i>
|
|
lldiv_t div(long long, long long); <i>// lldiv()</i>
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
<ins>-?- To avoid ambiguities, C++ also adds the following overloads of <tt>abs()</tt> to <tt><cstdlib></tt>,
|
|
with the semantics defined in <tt><cmath></tt>:</ins>
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
<ins>float abs(float);
|
|
double abs(double);
|
|
long double abs(long double);</ins>
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
<ins>-?- To avoid ambiguities, C++ also adds the following overloads of <tt>abs()</tt> to <tt><cmath></tt>,
|
|
with the semantics defined in <tt><cstdlib></tt>:</ins>
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
<ins>int abs(int);
|
|
long abs(long);
|
|
long long abs(long long);</ins>
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
<ins>-?- If <tt>abs()</tt> is called with an argument of unsigned integral type that cannot be converted to <tt>int</tt>
|
|
by integral promotion (4.5 [conv.prom]), the program is ill-formed. [<i>Note</i>: arguments that can be promoted
|
|
to <tt>int</tt> are permitted for compatibility with C. — <i>end note</i>]</ins>
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2195"></a>2195. Missing constructors for <tt>match_results</tt></h3>
|
|
<p><b>Section:</b> 28.10 [re.results] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2012-10-06 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#re.results">issues</a> in [re.results].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
The requirement expressed in 28.10 [re.results] p2
|
|
</p>
|
|
<blockquote><p>
|
|
The class template <tt>match_results</tt> shall satisfy the requirements of an allocator-aware container and of a
|
|
sequence container, as specified in 23.2.3 [sequence.reqmts], except that only operations defined for
|
|
const-qualified sequence containers are supported.
|
|
</p></blockquote>
|
|
<p>
|
|
can be read to require the existence of the described constructors from as well, but they do not exist in the
|
|
synopsis.
|
|
<p/>
|
|
The missing sequence constructors are:
|
|
</p>
|
|
<blockquote><pre>
|
|
match_results(initializer_list<value_type>);
|
|
match_results(size_type, const value_type&);
|
|
template<class InputIterator> match_results(InputIterator, InputIterator);
|
|
</pre></blockquote>
|
|
<p>
|
|
The missing allocator-aware container constructors are:
|
|
</p>
|
|
<blockquote><pre>
|
|
match_results(const match_results&, const Allocator&);
|
|
match_results(match_results&&, const Allocator&);
|
|
</pre></blockquote>
|
|
<p>
|
|
It should be clarified, whether (a) constructors are an exception of above mentioned operations or (b) whether
|
|
at least some of them (like those accepting a <tt>match_results</tt> value and an allocator) should be added.
|
|
<p/>
|
|
As visible in several places of the standard (including the core language), constructors seem usually to be considered
|
|
as "operations" and they certainly can be invoked for const-qualified objects.
|
|
<p/>
|
|
The below given proposed resolution applies only the minimum necessary fix, i.e. it excludes constructors from
|
|
above requirement.
|
|
</p>
|
|
|
|
<p><i>[2013-04-20, Bristol]</i></p>
|
|
|
|
|
|
<p>
|
|
Check current implementations to see what they do and, possibly, write a paper.
|
|
</p>
|
|
|
|
<p><i>[2013-09 Chicago]</i></p>
|
|
|
|
<p>
|
|
Ask Daniel to update the proposed wording to include the allocator copy and move constructors.
|
|
</p>
|
|
|
|
<p><i>[2014-01-18 Daniel changes proposed resolution]</i></p>
|
|
|
|
<p>
|
|
<strong>Previous resolution from Daniel [SUPERSEDED]:</strong>
|
|
</p>
|
|
|
|
<blockquote class="note">
|
|
<ol>
|
|
<li><p>Change 28.10 [re.results] p2 as indicated:</p>
|
|
<blockquote><p>
|
|
The class template <tt>match_results</tt> shall satisfy the requirements of an allocator-aware container and of a
|
|
sequence container, as specified in 23.2.3 [sequence.reqmts], except that only operations defined for
|
|
const-qualified sequence containers <ins>that are not constructors</ins> are supported.
|
|
</p></blockquote>
|
|
</li>
|
|
</ol>
|
|
</blockquote>
|
|
|
|
<p><i>[2015-05-06 Lenexa]</i></p>
|
|
|
|
<p>MC passes important knowledge to EF.</p>
|
|
<p>VV, RP: Looks good.</p>
|
|
<p>TK: Second form should be conditionally noexcept</p>
|
|
<p>JY: Sequence constructors are not here, but mentioned in the issue writeup. Why?</p>
|
|
<p>TK: That would have been fixed by the superseded wording.</p>
|
|
<p>JW: How does this interact with Mike Spertus' allocator-aware regexes? [...] Perhaps it doesn't.</p>
|
|
<p>JW: Can't create match_results, want both old and new resolution.</p>
|
|
<p>JY: It's problematic that users can't create these, but not this issue.</p>
|
|
<p>VV: Why conditional noexcept?</p>
|
|
<p>MC: Allocator move might throw.</p>
|
|
<p>JW: Update superseded wording to "only non-constructor operations that are"?</p>
|
|
<p>MC: Only keep superseded, but append "and the means of constructing match_results are limited to [...]"?</p>
|
|
<p>JY: Bullet 4 paragraph 2 needs to address the allocator constructor.</p>
|
|
<p>Assigned to JW for drafting.</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 28.10 [re.results] p4, class template <tt>match_results</tt> synopsis, as indicated:</p>
|
|
<blockquote><pre>
|
|
[…]
|
|
// 28.10.1, construct/copy/destroy:
|
|
explicit match_results(const Allocator& a = Allocator());
|
|
match_results(const match_results& m);
|
|
<ins>match_results(const match_results& m, const Allocator& a);</ins>
|
|
match_results(match_results&& m) noexcept;
|
|
<ins>match_results(match_results&& m, const Allocator& a) noexcept;</ins>
|
|
[…]
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 28.10.1 [re.results.const] as indicated: [<i>Drafting note:</i> Paragraph 6 as currently written,
|
|
makes not much sense, because the <tt>noexcept</tt> does not allow any exception to propagate. Further-on, the allocator requirements
|
|
do not allow for throwing move constructors. Deleting it seems to be near to editorial — <i>end drafting note</i>]</p>
|
|
<blockquote>
|
|
|
|
<pre>
|
|
match_results(const match_results& m);
|
|
<ins>match_results(const match_results& m, const Allocator& a);</ins>
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-4- <i>Effects:</i> Constructs an object of class <tt>match_results</tt>, as a copy of <tt>m</tt>.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<pre>
|
|
match_results(match_results&& m) noexcept;
|
|
<ins>match_results(match_results&& m, const Allocator& a) noexcept;</ins>
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-5- <i>Effects:</i> Move-constructs an object of class <tt>match_results</tt> from <tt>m</tt> satisfying the same postconditions
|
|
as Table 142. <del>Additionally</del><ins>For the first form</ins>, the stored <tt>Allocator</tt> value is move constructed
|
|
from <tt>m.get_allocator()</tt>.
|
|
<p/>
|
|
<del>-6- <i>Throws:</i> Nothing if the allocator's move constructor throws nothing.</del>
|
|
</p>
|
|
</blockquote>
|
|
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2198"></a>2198. <tt>max_load_factor(z)</tt> makes no strong guarantees, but bans useful behavior</h3>
|
|
<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2012-10-09 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#unord.req">issues</a> in [unord.req].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
The user cannot specify a <tt>max_load_factor</tt> for their unordered container
|
|
at construction, it must be supplied after the event, when the container is
|
|
potentially not empty. The contract for this method is deliberately vague, not
|
|
guaranteeing to use the value supplied by the user, and any value actually used
|
|
will be used as a ceiling that the container will <i>attempt</i> to respect.
|
|
</p>
|
|
<p>
|
|
The only guarantee we have is that, if user requests a <tt>max_load_factor</tt>
|
|
that is less than the current <tt>load_factor</tt>, then the operation will take
|
|
constant time, thus outlawing an implementation that chooses to rehash and so
|
|
preserve as a class invariant that <tt>load_factor < max_load_factor</tt>.
|
|
</p>
|
|
<p>
|
|
Reasonable options conforming to the standard include ignoring the user's request
|
|
if the requested value is too low, or deferring the rehash to the next <tt>insert</tt>
|
|
operation and allowing the container to have a strange state (wrt <tt>max_load_factor</tt>)
|
|
until then - and there is still the question of rehashing if the next <tt>insert</tt>
|
|
is for a duplicate key in a unique container.
|
|
</p>
|
|
<p>
|
|
Given the deliberate vagueness of the current wording, to support a range of reasonable
|
|
(but not <i>perfect</i>) behaviors, it is not clear why the equally reasonable rehash
|
|
to restore the constraint should be outlawed. It is not thought that this is a performance
|
|
critical operation, where users will be repeatedly setting low load factors on populated
|
|
containers, in a tight or (less unlikely) an instant response scenario.
|
|
</p>
|
|
|
|
<p><i>[2013-03-15 Issues Teleconference]</i></p>
|
|
|
|
<p>
|
|
Moved to Open.
|
|
</p>
|
|
<p>
|
|
Alisdair to provide wording.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2199"></a>2199. unordered containers are required to have an initial max load factor of 1.0</h3>
|
|
<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2012-10-09 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#unord.req">issues</a> in [unord.req].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
The default constructor, allocator-aware constructor, and range-based constructors
|
|
for the unordered containers do not offer a means to control the initial
|
|
<tt>max_load_factor</tt>, so the standard mandates the value 1.0. This seems overly
|
|
restrictive, as there is plenty of research suggesting a value between 0.5 and 1.0
|
|
is more often optimal for unique-key containers, and perhaps a slightly higher
|
|
value might be appropriate for multi-containers.
|
|
</p>
|
|
<p>
|
|
Rather than guess at the appropriate <tt>max_load_factor</tt>, it seems reasonable
|
|
that the standard should allow vendors to pick a value at their discretion, with
|
|
perhaps a note of advice. It is less clear whether the default value should be
|
|
implementation-defined or unspecified, given the ease of a user determining this
|
|
by querying this attribute immediately after construction.
|
|
</p>
|
|
|
|
<p><i>[2013-03-15 Issues Teleconference]</i></p>
|
|
|
|
<p>
|
|
Moved to Open.
|
|
</p>
|
|
<p>
|
|
Alisdair to provide wording.
|
|
</p>
|
|
<p>
|
|
Marshall: It seems to me that what you really want is to be able to pass a max load factor in the
|
|
constructor, but that's a different issue.
|
|
</p>
|
|
<p>
|
|
Alisdair agrees in principle, but concerned with adding yet more constructors to these classes.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2201"></a>2201. Missing macro entries from C standard library</h3>
|
|
<p><b>Section:</b> C.5 [diff.library] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Kevin McCarty <b>Opened:</b> 2012-02-03 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#diff.library">issues</a> in [diff.library].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
It seems that in C.5 [diff.library], Table 150 the following macros from 18.3.3 [c.limits], Table 31
|
|
are missing:
|
|
</p>
|
|
<blockquote><pre>
|
|
LLONG_MIN
|
|
LLONG_MAX
|
|
ULLONG_MAX
|
|
</pre></blockquote>
|
|
<p>
|
|
In addition in C.5 [diff.library], Table 150 the following macros from 18.3.3 [c.limits], Table 32
|
|
are missing:
|
|
</p>
|
|
<blockquote><pre>
|
|
DECIMAL_DIG
|
|
FLT_EVAL_METHOD
|
|
</pre></blockquote>
|
|
<p>
|
|
Furtheron it seems that in C.5 [diff.library], Table 149/150 further macros are missing as well, e.g.
|
|
<tt>HUGE_VALF</tt>, <tt>INFINITY</tt>, etc.
|
|
</p>
|
|
|
|
<p><i>[2014-02 Issaquah:]</i></p>
|
|
|
|
<p>
|
|
This is an issue, all of C has not been updated for C99, C99 functions are missing, whole section needs to be overhauled.
|
|
<p/>
|
|
The issue needs to be updated for functions and other missing items and when that happens the issue title is wrong and
|
|
needs to be adapted.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2202"></a>2202. Missing allocator support by <tt>async</tt></h3>
|
|
<p><b>Section:</b> 30.6.8 [futures.async] <b>Status:</b> <a href="lwg-active.html#Deferred">Deferred</a>
|
|
<b>Submitter:</b> Detlef Vollmann <b>Opened:</b> 2012-10-19 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#futures.async">issues</a> in [futures.async].</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
<tt>promise</tt>, <tt>packaged_task</tt>, and <tt>async</tt> are the only
|
|
places where a shared state is actually supposed to be allocated. Accordingly,
|
|
<tt>promise</tt> and <tt>packaged_task</tt> are "allocator-aware". But
|
|
function template <tt>async</tt> provides no way to provide an allocator.
|
|
</p>
|
|
|
|
<p><i>[2013-09 Chicago]</i></p>
|
|
|
|
<p>
|
|
Matt: deprecate async
|
|
<p/>
|
|
Nico: read my paper
|
|
<p/>
|
|
Alisdair: defer issues to wait for polymorphic allocators
|
|
<p/>
|
|
Alisdair: defer, active topic of research Deferred
|
|
</p>
|
|
|
|
<p><i>[2014-02-20 Re-open Deferred issues as Priority 4]</i></p>
|
|
|
|
|
|
<p><i>[2015-05 Lenexa, SG1 response]</i></p>
|
|
|
|
<p>
|
|
We want whatever status approximates: "will not fix; we're working on a replacement facility and don't want to add features to a broken one"
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2206"></a>2206. Inaccuracy in <tt>initializer_list</tt> constructor requirements</h3>
|
|
<p><b>Section:</b> 23.2.3 [sequence.reqmts], 23.2.4 [associative.reqmts], 23.2.5 [unord.req], 26.5.1.2 [rand.req.seedseq] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2012-10-21 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
In 23.2.3 [sequence.reqmts] p3, we have "<tt>il</tt> designates an object of type
|
|
<tt>initializer_list<value_type></tt>", and then several functions that take
|
|
'<tt>il</tt>' as an argument. However, an expression like <tt>{1, 2, 'a'}</tt> is <em>not</em>
|
|
an object of type <tt>initializer_list<int></tt> unless it's used to initialize
|
|
an explicitly-typed variable of that type. I believe we want:
|
|
</p>
|
|
<blockquote><pre>
|
|
std::vector<int> v;
|
|
v = {1, 2, 'a'};
|
|
</pre></blockquote>
|
|
<p>
|
|
to compile portably, so we should say something different when defining '<tt>il</tt>'. The
|
|
same phrasing happens in 23.2.4 [associative.reqmts], 23.2.5 [unord.req], and
|
|
26.5.1.2 [rand.req.seedseq].
|
|
<p/>
|
|
This may just be an editorial issue because the actual class synopses declare the functions
|
|
to take <tt>initializer_list<exact_type></tt>.
|
|
</p>
|
|
|
|
<p><i>[2013-03-15 Issues Teleconference]</i></p>
|
|
|
|
<p>
|
|
Moved to Open.
|
|
</p>
|
|
<p>
|
|
This is definitely not NAD
|
|
</p>
|
|
<p>
|
|
Should copy the suggested wording as the proposed resolution.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2208"></a>2208. <tt>std::reverse_iterator</tt> should be a literal type</h3>
|
|
<p><b>Section:</b> 24.5.1 [reverse.iterators] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2012-10-30 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#reverse.iterators">issues</a> in [reverse.iterators].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
<tt>std::reverse_iterator::reverse_iterator(Iterator)</tt> should be constexpr
|
|
so that other constexpr functions can return <tt>reverse_iterator</tt>s. Of the
|
|
other methods, the other constructors, <tt>base()</tt>, <tt>operator+</tt>, <tt>operator-</tt>,
|
|
<tt>operator[]</tt>, and the non-member operators can probably also be
|
|
<tt>constexpr</tt>.
|
|
<p/>
|
|
<tt>operator*</tt> cannot be constexpr because it involves an assignment to a
|
|
member variable. Discussion starting with c++std-lib-33282 indicated
|
|
that it would be useful to make reverse_iterator a literal type
|
|
despite this restriction on its use at compile time.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2214"></a>2214. Clarify <tt>basic_ios::init</tt> call restrictions</h3>
|
|
<p><b>Section:</b> 27.5.5.2 [basic.ios.cons] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Andrey Semashev <b>Opened:</b> 2012-11-09 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#basic.ios.cons">issues</a> in [basic.ios.cons].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
There is an ambiguity in how <tt>std::basic_ios::init</tt> method (27.5.5.2 [basic.ios.cons])
|
|
can be used in the derived class. The Standard only specify the state of the <tt>basic_ios</tt>
|
|
object after the call completes. However, in <tt>basic_ios</tt> default constructor description
|
|
(27.5.5.2 [basic.ios.cons]) there is this sentence:
|
|
</p>
|
|
<blockquote><p>
|
|
<i>Effects</i>: Constructs an object of class <tt>basic_ios</tt> (27.5.3.7 [ios.base.cons])
|
|
leaving its member objects uninitialized. The object shall be initialized by calling <tt>basic_ios::init</tt>
|
|
before its first use or before it is destroyed, whichever comes first; otherwise the behavior is undefined.
|
|
</p></blockquote>
|
|
<p>
|
|
This restriction hints that <tt>basic_ios::init</tt> should be called exactly
|
|
once before the object can be used or destroyed, because <tt>basic_ios::init</tt>
|
|
may not know whether it was called before or not (i.e. whether its members are actually
|
|
uninitialized or are initialized by the previous call to <tt>basic_ios::init</tt>). There
|
|
is no such restriction in the <tt>basic_ios::init</tt> preconditions so it is not clear whether it is
|
|
allowed to call <tt>basic_ios::init</tt> multiple times or not.
|
|
<p/>
|
|
This problem has already affected publicly available implementations.
|
|
For example, Microsoft Visual C++ STL introduces a memory leak if
|
|
<tt>basic_ios::init</tt> is called multiple times, while GCC 4.7 and STLPort
|
|
reinitialize the <tt>basic_ios</tt> object correctly without memory leak or any
|
|
other undesired effects. There was a discussion of this issue on Boost
|
|
<a href="http://article.gmane.org/gmane.comp.lib.boost.devel/235659">developers mailing list</a>,
|
|
and there is a <a href="https://sourceforge.net/apps/trac/boost-log/ticket/2#comment:4">test case
|
|
that reproduces the problem</a>. The test case is actually a bug report for my Boost.Log library,
|
|
which attempts to cache <tt>basic_ostream</tt>-derived objects internally to avoid expensive construction
|
|
and destruction. My stream objects allowed resetting the stream buffer pointers the stream
|
|
is attached to, without requiring to destroy and construct the stream.
|
|
<p/>
|
|
My personal view of the problem and proposed resolution follows.
|
|
<p/>
|
|
While apparently the intent of <tt>basic_ios::init</tt> is to provide a way to
|
|
initialize <tt>basic_ios</tt> after default construction, I see no reason to
|
|
forbid it from being called multiple times to reinitialize the stream.
|
|
Furthermore, it is possible to implement a conforming <tt>basic_ios</tt> that
|
|
does not have this restriction.
|
|
<p/>
|
|
The quoted above section of the Standard that describes the effects of
|
|
the default constructor is misleading. The Standard does not mandate
|
|
any data members of <tt>basic_ios</tt> or <tt>ios_base</tt> (27.5.3 [ios.base]), which
|
|
it derives from. This means that the implementation is allowed to use
|
|
non-POD data members with default constructors that initialize the
|
|
members with particular default values. For example, in the case of
|
|
Microsoft Visual C++ STL the leaked memory is an <tt>std::locale</tt> instance
|
|
that is dynamically allocated during <tt>basic_ios::init</tt>, a raw pointer to
|
|
which is stored within ios_base. It is possible to store e.g. an
|
|
<tt>unique_ptr</tt> instead of a raw pointer as a member of <tt>ios_base</tt>, the smart
|
|
pointer will default initialize the underlying raw pointer on default
|
|
construction and automatically destroy the allocated object upon being
|
|
reset or destroyed, which would eliminate the leak and allow
|
|
<tt>basic_ios::init</tt> to be called multiple times. This leads to conclusion
|
|
that the default constructor of <tt>basic_ios</tt> cannot leave "its member
|
|
objects uninitialized" but instead performs default initialization of
|
|
the member objects, which would mean the same thing in case of POD types.
|
|
<p/>
|
|
However, I feel that restricting <tt>ios_base</tt> and <tt>basic_ios</tt> members to
|
|
non-POD types is not acceptable. Since multiple calls to <tt>basic_ios::init</tt> are
|
|
not forbidden by the Standard, I propose to correct the <tt>basic_ios</tt> default
|
|
constructor description so that it is allowed to destroy <tt>basic_ios</tt> object
|
|
without calling <tt>basic_ios::init</tt>. This would imply that any raw members of
|
|
<tt>basic_ios</tt> and <tt>ios_base</tt> should be initialized to values suitable for
|
|
destruction (essentially, this means only initializing raw pointers to NULL). The new
|
|
wording could look like this:
|
|
</p>
|
|
<blockquote><p>
|
|
<i>Effects</i>: Constructs an object of class <tt>basic_ios</tt> (27.5.3.7 [ios.base.cons])
|
|
initializing its member objects to unspecified state, only suitable for <tt>basic_ios</tt> destruction.
|
|
The object shall be initialized by calling <tt>basic_ios::init</tt> before its first use; otherwise
|
|
the behavior is undefined.
|
|
</p></blockquote>
|
|
<p>
|
|
This would remove the hint that <tt>basic_ios::init</tt> must be called exactly
|
|
once. Also, this would remove the requirement for <tt>basic_ios::init</tt> to
|
|
be called at all before the destruction. This is also an important issue because
|
|
the derived stream constructor may throw an exception before it manages to call
|
|
<tt>basic_ios::init</tt> (for example, if the streambuf constructor throws), and
|
|
in this case the <tt>basic_ios</tt> destructor has undefined behavior.
|
|
<p/>
|
|
To my mind, the described modification is sufficient to resolve the issue. But to
|
|
emphasize the possibility to call <tt>basic_ios::init</tt> multiple times, a remark
|
|
or a footnote for <tt>basic_ios::init</tt> postconditions could be added to explicitly
|
|
state the semantics of calling it multiple times. The note could read as follows:
|
|
</p>
|
|
<blockquote><p>
|
|
The function can be called multiple times during the object lifetime. Each subsequent
|
|
call reinitializes the object to the described in postconditions initial state.
|
|
</p></blockquote>
|
|
|
|
<p><i>[2013-04-20, Bristol]</i></p>
|
|
|
|
|
|
<p>
|
|
Alisdair: The current wording is unclear but the proposed resolution is wrong
|
|
<p/>
|
|
Solution: Clarify that <tt>init</tt> must be called once and only once. Move then to review.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3485.</p>
|
|
|
|
<ol>
|
|
<li><p>Edit 27.5.5.2 [basic.ios.cons] as indicated:</p>
|
|
<blockquote><pre>
|
|
basic_ios();
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-2- <i>Effects</i>: Constructs an object of class <tt>basic_ios</tt> (27.5.3.7 [ios.base.cons])
|
|
<del>leaving its member objects uninitialized</del><ins>initializing its member objects to unspecified state,
|
|
only suitable for <tt>basic_ios</tt> destruction</ins>. The object shall be initialized by calling
|
|
<tt>basic_ios::init</tt> before its first use <del>or before it is destroyed, whichever comes first</del>;
|
|
otherwise the behavior is undefined.
|
|
</p>
|
|
</blockquote>
|
|
<pre>
|
|
void init(basic_streambuf<charT,traits>* sb);
|
|
</pre><blockquote>
|
|
<p>
|
|
<i>Postconditions</i>: The postconditions of this function are indicated in Table 128.
|
|
<p/>
|
|
<ins>-?- <i>Remarks</i>: The function can be called multiple times during the object lifetime. Each subsequent
|
|
call reinitializes the object to the described in postconditions initial state.</ins>
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2215"></a>2215. (unordered) associative container functors should be <tt>CopyConstructible</tt></h3>
|
|
<p><b>Section:</b> 23.2.4 [associative.reqmts], 23.2.5 [unord.req] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2012-11-14 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The requirements on the functors used to arrange elements in the various associative and
|
|
unordered containers are given by a set of expressions in tables 102 — Associative container
|
|
requirements, and 103 — Unordered associative container requirements. In keeping with Library
|
|
convention these expressions make the minimal requirements necessary on their types. For
|
|
example, we have the following 3 row extracts for the unordered containers:
|
|
</p>
|
|
<table>
|
|
<tr>
|
|
<td>
|
|
<b>Expression</b>
|
|
</td>
|
|
<td>
|
|
<b>Assertion/note pre-/post-condition</b>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<pre>
|
|
<tt>X(n, hf, eq)</tt>
|
|
<tt>X a(n, hf, eq)</tt>
|
|
</pre>
|
|
</td>
|
|
<td>
|
|
<i>Requires:</i> <tt>hasher</tt> and <tt>key_equal</tt> are <tt>CopyConstructible</tt>.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<pre>
|
|
<tt>X(n, hf)</tt>
|
|
<tt>X a(n, hf)</tt>
|
|
</pre>
|
|
</td>
|
|
<td>
|
|
<i>Requires:</i> <tt>hasher</tt> is <tt>CopyConstructible</tt> and
|
|
<tt>key_equal</tt> is <tt>DefaultConstructible</tt>.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<pre>
|
|
<tt>X(n)</tt>
|
|
<tt>X a(n)</tt>
|
|
</pre>
|
|
</td>
|
|
<td>
|
|
<i>Requires:</i> <tt>hasher</tt> and <tt>key_equal</tt> are <tt>DefaultConstructible</tt>.
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<p>
|
|
However, the signature for each class template requires that the functors must effectively be
|
|
<tt>CopyConstructible</tt> for each of these expressions:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
template <class Key,
|
|
class T,
|
|
class Hash = hash<Key>,
|
|
class Pred = std::equal_to<Key>,
|
|
class Allocator = std::allocator<std::pair<const Key, T> > >
|
|
class unordered_map
|
|
{
|
|
<i>...</i>
|
|
|
|
<i>// construct/destroy/copy</i>
|
|
explicit unordered_map(size_type n = <i>see below</i>,
|
|
const hasher& hf = hasher(),
|
|
const key_equal& eql = key_equal(),
|
|
const allocator_type& a = allocator_type());
|
|
|
|
<i>...</i>
|
|
}
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
The letter of the standard can be honored as long as implementors recognize
|
|
their freedom to split this one signature into multiple overloads, so that
|
|
the documented default arguments (requiring a <tt>CopyConstructible</tt> functor)
|
|
are not actually passed as default arguments.
|
|
</p>
|
|
<p>
|
|
As we look into the requirements for the copy constructor and copy-assignment
|
|
operator, the requirements are even more vague, as the explicit requirements on
|
|
the functors are not called out, other than saying that the functors are copied.
|
|
</p>
|
|
<p>
|
|
Must the functors be <tt>CopyAssignable</tt>? Or is <tt>CopyConstructible</tt>
|
|
sufficient in this case? Do we require that the functors be <tt>Swappable</tt>
|
|
so that the copy-swap idiom can be deployed here? Note that a type that is both
|
|
<tt>CopyConstructible</tt> and <tt>CopyAssignable</tt> is still not guaranteed to
|
|
be <tt>Swappable</tt> as the user may delete the <tt>swap</tt> function for their
|
|
type in their own namespace, which would be found via ADL.
|
|
</p>
|
|
<p>
|
|
Some clean-up of the requirements table looks necessary, to at least document the
|
|
assignment behavior. In addition, we should have clear guidance on whether these
|
|
functors should always be <tt>CopyConstructible</tt>, as suggested by the class
|
|
template definitions, or if the requirement tables are correct and we should
|
|
explicitly split up the constructors in the (unordered) associative containers
|
|
to no longer use default (function) arguments to obtain their defaulted functors.
|
|
</p>
|
|
<p>
|
|
I recommend the simplest solution would be to always require that the functors
|
|
for (unordered) associative containers be <tt>CopyConstructible</tt>, above the
|
|
requirements tables themselves, so that the issue need not be addressed within
|
|
the tables. I suggest that the assignment operators for these containers add
|
|
the requirement that the functors be <tt>Swappable</tt>, rather than forwarding
|
|
the corresponding <tt>Assignable</tt> requirement.
|
|
</p>
|
|
|
|
<p><i>[2013-03-15 Issues Teleconference]</i></p>
|
|
|
|
<p>
|
|
Moved to Open.
|
|
</p>
|
|
<p>
|
|
Alisdair to propose wording.
|
|
</p>
|
|
|
|
<p><i>[2014-06-08, Daniel comments]</i></p>
|
|
|
|
<p>
|
|
The area of this issue partially overlaps what LWG <a href="lwg-active.html#2227">2227</a> addresses.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2216"></a>2216. <tt>regex_replace(basic_string)</tt> allocator handling</h3>
|
|
<p><b>Section:</b> 28.11.4 [re.alg.replace] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2012-11-26 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#re.alg.replace">issues</a> in [re.alg.replace].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<blockquote><pre>
|
|
template <class traits, class charT, class ST, class SA>
|
|
basic_string<charT, ST, SA>
|
|
regex_replace(const basic_string<charT, ST, SA>& s,
|
|
const basic_regex<charT, traits>& e,
|
|
const charT* fmt,
|
|
regex_constants::match_flag_type flags =
|
|
regex_constants::match_default);
|
|
</pre></blockquote>
|
|
<p>
|
|
and friends are documented as
|
|
</p>
|
|
<blockquote><p>
|
|
Constructs an empty string result of type <tt>basic_string<charT, ST, SA></tt>
|
|
and calls <tt>regex_replace(back_inserter(result), s.begin(), s.end(), e, fmt, flags)</tt>.
|
|
</p></blockquote>
|
|
<p>
|
|
This appears to require the result to have a default-constructed
|
|
allocator, which isn't even possible for all allocator types. I
|
|
suspect the allocator should be copied from 's' instead. Possibly
|
|
there should be an additional defaulted argument to override the
|
|
allocator of the result.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2218"></a>2218. Unclear how containers use <tt>allocator_traits::construct()</tt></h3>
|
|
<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2012-11-27 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
Firstly, 23.2.1 [container.requirements.general]/7 says a container's
|
|
allocator is used to obtain memory, but it isn't stated explicitly that the same
|
|
allocator is used to construct and destroy elements, as opposed to a value-initialized
|
|
allocator of the same type.
|
|
</p>
|
|
<p>
|
|
Secondly, 23.2.1 [container.requirements.general]/3 says elements "shall be
|
|
constructed using the <tt>allocator_traits<allocator_type>::construct</tt>
|
|
function and destroyed using the <tt>allocator_traits<allocator_type>::destroy</tt> function" and
|
|
23.2.1 [container.requirements.general]/13 defines <tt>CopyInsertable</tt> etc. in
|
|
terms of an allocator <tt>A</tt> which is identical to the container's <tt>allocator_type</tt>.
|
|
</p>
|
|
<p>
|
|
The intent of making <tt>construct()</tt> and <tt>destroy()</tt> function templates was
|
|
that containers would be permitted to use <tt>allocator_traits<A>::construct()</tt> instead of
|
|
<tt>allocator_traits<allocator_type>::construct()</tt>, where <tt>A</tt> is
|
|
<tt>allocator_traits<allocator_type>::rebind_alloc<U></tt> for some other type
|
|
<tt>U</tt>. This allows node-based containers to store an allocator of the right type for
|
|
allocating nodes and to use the same object to construct elements in aligned storage within
|
|
those nodes, avoiding rebinding and copying the stored allocator every time an element needs
|
|
to be constructed.
|
|
<p/>
|
|
It should be made clear that a possibly-rebound copy of the container's allocator is used for object
|
|
construction.
|
|
</p>
|
|
|
|
<p><i>[2013-03-15 Issues Teleconference]</i></p>
|
|
|
|
<p>
|
|
Moved to Open.
|
|
</p>
|
|
<p>
|
|
Jonathan: point 2 in the proposed resolution is definitely needed.
|
|
</p>
|
|
|
|
<p><i>[2014-11-28, Jonathan improves wording]</i></p>
|
|
|
|
<p>
|
|
In the first set of edits to paragraph 3 both pieces inserting "<tt>rebind_alloc<U>::</tt>"
|
|
should be replaced by "<tt>rebind_traits<U>::</tt>"
|
|
<p/>
|
|
Otherwise it implies using the allocator's functions directly, but they might not exist and
|
|
it should be through the rebound traits type.
|
|
</p>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
STL: You want to permit but not require rebinding?<br/>
|
|
Wakely: The current wording forces me to use the original allocator, not the rebound one.<br/>
|
|
STL: Oh, I see. Yeah, we immediately rebind.<br/>
|
|
Wakely: The edits clarify that we don't use some other allocator. The third diff is because the definitions of
|
|
EmplaceConstructible/etc. happen with the same types. The diff to the note is because it doesn't require the value
|
|
of the allocator was the one passed in.<br/>
|
|
STL: After looking at this, I think I'm comfortable with the edits. The previous Standardese was nonsense so it's
|
|
pretty easy to improve upon.<br/>
|
|
Marshall: Any other opinions?<br/>
|
|
Marshall: Any objections to moving it to Ready? Review? Ready in Kona?<br/>
|
|
Wakely: My preference would be Ready. We all know this is what we're doing anyways.<br/>
|
|
Nevin: The intent won't change.<br/>
|
|
STL: I think this is the right fix.<br/>
|
|
Hwrd: I third Ready. Even if Jonathan retracts his.<br/>
|
|
Marshall: Ready!
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3485.</p>
|
|
|
|
<ol>
|
|
<li><p>Edit 23.2.1 [container.requirements.general] paragraph 3:</p>
|
|
<blockquote><p>
|
|
For the components affected by this subclause that declare an <tt>allocator_type</tt>, objects stored in these
|
|
components shall be constructed using the <tt>allocator_traits<allocator_type>::<ins>rebind_traits<U>::</ins>construct</tt>
|
|
function and destroyed using the <tt>allocator_traits<allocator_type>::<ins>rebind_traits<U>::</ins>destroy</tt>
|
|
function (20.7.8.2 [allocator.traits.members])<ins>, where <tt>U</tt> is either <tt>allocator_type::value_type</tt>
|
|
or an internal type used by the container</ins>. These functions are called only for the container's element type,
|
|
not for internal types used by the container. [ <i>Note</i>: This means, for example, that a node-based container
|
|
might need to construct nodes containing aligned buffers and call construct to place the element into the buffer.
|
|
— <i>end note</i> ]
|
|
</p></blockquote>
|
|
</li>
|
|
|
|
<li><p>Edit 23.2.1 [container.requirements.general] paragraph 7:</p>
|
|
<blockquote><p>
|
|
[…] A copy of this allocator is used for any memory allocation <ins>and element construction</ins> performed,
|
|
by these constructors and by all member functions, during the lifetime of each container object or until the allocator
|
|
is replaced. […]
|
|
</p></blockquote>
|
|
</li>
|
|
|
|
<li><p>Edit 23.2.1 [container.requirements.general] paragraph 13:</p>
|
|
<blockquote><p>
|
|
[…] Given <ins>an allocator type <tt>A</tt> and given</ins> a container type <tt>X</tt> having <del>an
|
|
<tt>allocator_type</tt> identical to <tt>A</tt> and</del> a <tt>value_type</tt> identical to <tt>T</tt>
|
|
<ins>and an <tt>allocator_type</tt> identical to <tt>allocator_traits<A>::rebind_alloc<T></tt></ins>
|
|
and given an lvalue <tt>m</tt> of type <tt>A</tt>, a pointer <tt>p</tt>
|
|
of type <tt>T*</tt>, an expression <tt>v</tt> of type (possibly <tt>const</tt>) <tt>T</tt>, and an rvalue <tt>rv</tt>
|
|
of type <tt>T</tt>, the following terms are defined.
|
|
<p/>
|
|
[…]
|
|
<p/>
|
|
[ <i>Note</i>: A container calls <tt>allocator_traits<A>::construct(m, p, args)</tt> to construct an element
|
|
at <tt>p</tt> using <tt>args</tt><ins>, with <tt>m == get_allocator()</tt></ins>. The default <tt>construct</tt> in
|
|
<tt>std::allocator</tt> will call <tt>::new((void*)p) T(args)</tt>, but specialized allocators may choose a
|
|
different definition. — <i>end note</i> ]
|
|
</p></blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2219"></a>2219. <tt><i>INVOKE</i></tt>-ing a pointer to member with a <tt>reference_wrapper</tt> as the object expression</h3>
|
|
<p><b>Section:</b> 20.9.2 [func.require] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2012-11-28 <b>Last modified:</b> 2015-05-06</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#func.require">active issues</a> in [func.require].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#func.require">issues</a> in [func.require].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
The standard currently requires this to be invalid:
|
|
</p>
|
|
<blockquote><pre>
|
|
#include <functional>
|
|
|
|
struct X { int i; } x;
|
|
auto f = &X::i;
|
|
auto t1 = std::ref(x);
|
|
int i = std::mem_fn(f)(t1);
|
|
</pre></blockquote>
|
|
<p>
|
|
The call expression on the last line is equivalent to <tt><i>INVOKE</i>(f, std::ref(x))</tt>
|
|
which according to 20.9.2 [func.require]p1 results in the invalid expression <tt>(*t1).*f</tt>
|
|
because <tt>reference_wrapper<X></tt> is neither an object of type <tt>X</tt> nor a reference
|
|
to an object of type <tt>X</tt> nor a reference to an object of a type derived from <tt>X</tt>.
|
|
</p>
|
|
<p>
|
|
The same argument applies to pointers to member functions, and if they don't work with <tt>INVOKE</tt>
|
|
it becomes harder to do all sorts of things such as:
|
|
</p>
|
|
<blockquote><p>
|
|
<tt>call_once(o, &std::thread::join, std::ref(thr))</tt>
|
|
</p></blockquote>
|
|
<p>
|
|
or
|
|
</p>
|
|
<blockquote><p>
|
|
<tt>async(&std::list<int>::sort, std::ref(list));</tt>
|
|
</p></blockquote>
|
|
<p>
|
|
The definition of <tt><i>INVOKE</i></tt> should be extended to handle reference wrappers.
|
|
</p>
|
|
|
|
<p><i>[2013-03-15 Issues Teleconference]</i></p>
|
|
|
|
<p>
|
|
Moved to Review.
|
|
</p>
|
|
<p>
|
|
The wording seems accurate, but verbose. If possible, we would like to define the kind of thing being
|
|
specified so carefully as one of a number of potential language constructs in a single place. It is
|
|
also possible that this clause <i>is</i> that single place.
|
|
</p>
|
|
|
|
<p><i>[2013-04-18, Bristol]</i></p>
|
|
|
|
|
|
<p>Jonathan comments:</p>
|
|
|
|
<p>In the proposed resolution in the first bullet <tt>(t1.*f)</tt> is not valid if <tt>t1</tt> is a
|
|
<tt>reference_wrapper</tt>, so we probably need a separate bullet to handle the
|
|
<tt>reference_wrapper</tt> case.</p>
|
|
|
|
<p><i>[2014-02-14, Issaquah, Mike Spertus supplies wording]</i></p>
|
|
|
|
|
|
<p><strong>Previous resolution from Jonathan [SUPERSEDED]:</strong></p>
|
|
|
|
<blockquote class="note">
|
|
|
|
<p>This wording is relative to N3485.</p>
|
|
|
|
<ol>
|
|
<li><p>Edit 20.9.2 [func.require]:</p>
|
|
<blockquote><p>
|
|
Define <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> as follows:
|
|
</p>
|
|
<ul>
|
|
<li><p>
|
|
<tt>(t1.*f)(t2, ..., tN)</tt> when <tt>f</tt> is a pointer to a member function of a class <tt>T</tt> and
|
|
<tt>t1</tt> is an object of type <tt>T</tt> or a reference to an object of type <del><tt>T</tt> or a reference
|
|
to an object of a type derived from <tt>T</tt></del> <ins><tt>U</tt> or an object of type <tt>reference_wrapper<U></tt>
|
|
or a reference to an object of type <tt>reference_wrapper<U></tt> where <tt>U</tt> is either the type
|
|
<tt>T</tt> or a type derived from <tt>T</tt></ins>;
|
|
</p>
|
|
</li>
|
|
|
|
<li><p>
|
|
<tt>((*t1).*f)(t2, ..., tN)</tt> when <tt>f</tt> is a pointer to a member function of a class <tt>T</tt> and
|
|
<tt>t1</tt> is not one of the types described in the previous item;
|
|
</p></li>
|
|
|
|
<li><p>
|
|
<tt>t1.*f</tt> when <tt>N == 1</tt> and <tt>f</tt> is a pointer to member data of a class <tt>T</tt> and <tt>t1</tt>
|
|
is an object of type <tt>T</tt> or a reference to an object of type <del><tt>T</tt> or a reference to an object of a
|
|
type derived from <tt>T</tt></del> <ins><tt>U</tt> or an object of type <tt>reference_wrapper<U></tt>
|
|
or a reference to an object of type <tt>reference_wrapper<U></tt> where <tt>U</tt> is either the type
|
|
<tt>T</tt> or a type derived from <tt>T</tt></ins>;
|
|
</p></li>
|
|
|
|
<li><p>
|
|
<tt>(*t1).*f</tt> when <tt>N == 1</tt> and <tt>f</tt> is a pointer to member data of a class <tt>T</tt> and <tt>t1</tt>
|
|
is not one of the types described in the previous item;
|
|
</p></li>
|
|
|
|
<li><p>
|
|
<tt>f(t1, t2, ..., tN)</tt> in all other cases.
|
|
</p></li>
|
|
</ul>
|
|
|
|
</blockquote>
|
|
|
|
</li>
|
|
</ol>
|
|
|
|
</blockquote>
|
|
|
|
<p><i>[2014-10-01, STL adds discussion and provides an improved resolution]</i></p>
|
|
|
|
<p>
|
|
Because neither <tt>t1.*f</tt> nor <tt>(*t1).*f</tt> will compile when <tt>t1</tt> is <tt>reference_wrapper<U></tt>
|
|
for any <tt>U</tt>, we don't need to inspect <tt>U</tt> carefully. We can bluntly detect all <tt>reference_wrapper</tt>s
|
|
and use <tt>get()</tt> for them.
|
|
<p/>
|
|
We would have to be more careful if we had to deal with pointers to members of <tt>reference_wrapper</tt> itself.
|
|
Fortunately, we don't. First, it doesn't have user-visible data members. Second, users technically can't take the
|
|
addresses of its member functions (this is a consequence of 17.6.5.5 [member.functions], the Implementer's Best Friend).
|
|
<p/>
|
|
While we're in the neighborhood, I recommend simplifying and clarifying the wording used to detect base/derived objects.
|
|
</p>
|
|
|
|
<p><strong>Previous resolution from Mike Spertus [SUPERSEDED]:</strong></p>
|
|
|
|
<blockquote class="note">
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Edit 20.9.2 [func.require]:</p>
|
|
<blockquote><p>
|
|
Define <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> as follows:
|
|
</p>
|
|
<ul>
|
|
<li><p>
|
|
<tt>(t1.*f)(t2, ..., tN)</tt> when <tt>f</tt> is a pointer to a member function of a class <tt>T</tt> and
|
|
<tt>t1</tt> is an object of type <tt>T</tt> or a reference to an object of type <tt>T</tt> or a reference
|
|
to an object of a type derived from <tt>T</tt>;
|
|
</p>
|
|
</li>
|
|
|
|
<li><p>
|
|
<ins>
|
|
<tt>(t1.get().*f)(t2, ..., tN)</tt> when <tt>f</tt> is a pointer to a member function
|
|
of class <tt>T</tt>
|
|
and <tt>t1</tt> is an object of type <tt>reference_wrapper<U></tt> where <tt>U</tt>
|
|
is either the type <tt>T</tt> or a type derived from <tt>T</tt>.
|
|
</ins>
|
|
</p>
|
|
</li>
|
|
|
|
<li><p>
|
|
<tt>((*t1).*f)(t2, ..., tN)</tt> when <tt>f</tt> is a pointer to a member function of a class <tt>T</tt> and
|
|
<tt>t1</tt> is not one of the types described in the previous item;
|
|
</p></li>
|
|
|
|
|
|
|
|
<li><p>
|
|
<tt>t1.*f</tt> when <tt>N == 1</tt> and <tt>f</tt> is a pointer to member data of a class <tt>T</tt> and <tt>t1</tt>
|
|
is an object of type <tt>T</tt> or a reference to an object of type <tt>T</tt> or a reference to an object of a
|
|
type derived from <tt>T</tt>;
|
|
</p></li>
|
|
|
|
<li><p>
|
|
<ins>
|
|
<tt>t1.get().*f</tt> when <tt>N == 1</tt> and <tt>f</tt> is a pointer to member data of a
|
|
class <tt>T</tt> and <tt>t1</tt> is an object of type <tt>reference_wrapper<U></tt>
|
|
where <tt>U</tt> is either the type <tt>T</tt> or a type derived from <tt>T</tt>.
|
|
</ins>
|
|
</p></li>
|
|
|
|
<li><p>
|
|
<tt>(*t1).*f</tt> when <tt>N == 1</tt> and <tt>f</tt> is a pointer to member data of a class <tt>T</tt> and <tt>t1</tt>
|
|
is not one of the types described in the previous item;
|
|
</p></li>
|
|
|
|
<li><p>
|
|
<tt>f(t1, t2, ..., tN)</tt> in all other cases.
|
|
</p></li>
|
|
</ul>
|
|
|
|
</blockquote>
|
|
|
|
</li>
|
|
</ol>
|
|
</blockquote>
|
|
|
|
<p><i>[2015-02, Cologne]</i></p>
|
|
|
|
<p>
|
|
Waiting for implementation experience.
|
|
</p>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
STL: latest note from Cologne, waiting for implementation experience<br/>
|
|
STL: don't think this is harder than anything else we do<br/>
|
|
MC: it does involve <tt>mem_fn</tt> and invoke<br/>
|
|
STL: my simplication was not to attempt fine-grained<br/>
|
|
STL: can ignore pmf<br/>
|
|
STL: can't invoke pmf to reference wrapper<br/>
|
|
STL: wording dated back to TR1 when there was no <tt>decltype</tt><br/>
|
|
MC: should <tt>decay_t<decltype(t1)></tt> be pulled out since it is in multiple places<br/>
|
|
STL: it could be handled editorially<br/>
|
|
STL: we fix function, bind, invoke<br/>
|
|
STL: have not implemented this but believe it is fine<br/>
|
|
MC: Eric F, you have worked in invoke<br/>
|
|
EF: yes, looks ok<br/>
|
|
MC: consensus move to ready
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 20.9.2 [func.require] p1 as depicted:</p>
|
|
<blockquote><p>
|
|
Define <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> as follows:
|
|
</p>
|
|
<ul>
|
|
<li><p>
|
|
<tt>(t1.*f)(t2, ..., tN)</tt> when <tt>f</tt> is a pointer to a member function of a class <tt>T</tt> and
|
|
<del><tt>t1</tt> is an object of type <tt>T</tt> or a reference to an object of type <tt>T</tt> or a reference
|
|
to an object of a type derived from <tt>T</tt></del><ins><tt>is_base_of<T, decay_t<decltype(t1)>>::value</tt>
|
|
is true</ins>;
|
|
</p>
|
|
</li>
|
|
|
|
<li><p>
|
|
<ins><tt>(t1.get().*f)(t2, ..., tN)</tt> when <tt>f</tt> is a pointer to a member function of a class <tt>T</tt> and
|
|
<tt>decay_t<decltype(t1)></tt> is a specialization of <tt>reference_wrapper</tt>;</ins>
|
|
</p></li>
|
|
|
|
<li><p>
|
|
<tt>((*t1).*f)(t2, ..., tN)</tt> when <tt>f</tt> is a pointer to a member function of a class <tt>T</tt> and
|
|
<tt>t1</tt> <del>is not one of the types described in the previous item</del><ins>does not satisfy the previous two
|
|
items</ins>;
|
|
</p></li>
|
|
|
|
<li><p>
|
|
<tt>t1.*f</tt> when <tt>N == 1</tt> and <tt>f</tt> is a pointer to member data of a class <tt>T</tt> and <del><tt>t1</tt>
|
|
is an object of type <tt>T</tt> or a reference to an object of type <tt>T</tt> or a reference to an object of a
|
|
type derived from <tt>T</tt></del><ins><tt>is_base_of<T, decay_t<decltype(t1)>>::value</tt>
|
|
is true</ins>;
|
|
</p></li>
|
|
|
|
<li><p>
|
|
<ins><tt>t1.get().*f</tt> when <tt>N == 1</tt> and <tt>f</tt> is a pointer to member data of a class <tt>T</tt> and
|
|
<tt>decay_t<decltype(t1)></tt> is a specialization of <tt>reference_wrapper</tt>;</ins>
|
|
</p></li>
|
|
|
|
<li><p>
|
|
<tt>(*t1).*f</tt> when <tt>N == 1</tt> and <tt>f</tt> is a pointer to member data of a class <tt>T</tt> and <tt>t1</tt>
|
|
<del>is not one of the types described in the previous item</del><ins>does not satisfy the previous two items</ins>;
|
|
</p></li>
|
|
|
|
<li><p>
|
|
<tt>f(t1, t2, ..., tN)</tt> in all other cases.
|
|
</p></li>
|
|
</ul>
|
|
|
|
</blockquote>
|
|
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2220"></a>2220. Under-specification of <tt>operator==</tt> for <tt>regex_token_iterator</tt></h3>
|
|
<p><b>Section:</b> 28.12.2.2 [re.tokiter.comp] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Pete Becker <b>Opened:</b> 2012-11-21 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
Consider the following example:
|
|
</p>
|
|
<blockquote><pre>
|
|
std::string str0("x");
|
|
std::regex rg0("a");
|
|
std::regex_token_iterator it0(str0.begin(), str0.end(), rg0, -1); // points at "x" in str0
|
|
std::string str1("x");
|
|
std::regex rg1("b");
|
|
std::regex_token_iterator it1(str1.begin(), str1.end(), rg1, -1); // points at "x" in str1
|
|
</pre></blockquote>
|
|
<p>
|
|
28.12.2.2 [re.tokiter.comp] p1 says that <tt>it0.operator==(it1)</tt> returns true "if
|
|
<tt>*this</tt> and <tt>right</tt> are both suffix iterators and <tt>suffix == right.suffix</tt>"; both
|
|
conditions are satisfied in this example. It does not say that they must both be iterators
|
|
into the same sequence, nor does it say (as general iterator requirements do) that they must
|
|
both be in the domain of <tt>==</tt> in order for the comparison to be meaningful. It's a
|
|
simple statement: they're equal if the strings they point at compare equal. Given this being
|
|
a valid comparison, the obtained result of "true" looks odd.
|
|
<p/>
|
|
The problem is that for iterator values prior to the suffix iterator, equality means the same
|
|
regular expression and the same matched sequence (both uses of "same" refer to identity, not equality);
|
|
for the suffix iterator, equality means that the matched sequences compare equal.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2221"></a>2221. No formatted output operator for <tt>nullptr</tt></h3>
|
|
<p><b>Section:</b> 27.7.3 [output.streams] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Matt Austern <b>Opened:</b> 2012-12-07 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
When I write
|
|
</p>
|
|
<blockquote><pre>
|
|
std::cout << nullptr << std::endl;
|
|
</pre></blockquote>
|
|
<p>
|
|
I get a compilation error, "ambiguous overload for '<tt>operator<<</tt>' in '<tt>std::cout << nullptr</tt>'".
|
|
As far as I can tell, the compiler is right to issue that error. There are inserters for <tt>const void*</tt>,
|
|
<tt>const char*</tt>, <tt>const signed char*</tt>, and <tt>const unsigned char*</tt>, and none for
|
|
<tt>nullptr_t</tt>, so the expression really is ambiguous.
|
|
<p/>
|
|
<em>Proposed wording</em>:
|
|
<p/>
|
|
The obvious library solution is to add a <tt>nullptr_t</tt> overload, which would be defined something like
|
|
</p>
|
|
<blockquote><pre>
|
|
template<class C, class T>
|
|
basic_ostream<C, T>& operator<<(basic_ostream<C, T>& os, nullptr_t)
|
|
{
|
|
return os << (void*) nullptr;
|
|
}
|
|
</pre></blockquote>
|
|
<p>
|
|
We might also consider addressing this at a core level: add a special-case language rule that addresses all
|
|
cases where you write <tt>f(nullptr)</tt> and <tt>f</tt> is overloaded on multiple pointer types. (Perhaps
|
|
a tiebreaker saying that <tt>void*</tt> is preferred in such cases.)
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2223"></a>2223. <tt>shrink_to_fit</tt> effect on iterator validity</h3>
|
|
<p><b>Section:</b> 23.3.6.3 [vector.capacity] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Juan Soulie <b>Opened:</b> 2012-12-17 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#vector.capacity">active issues</a> in [vector.capacity].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
After the additions by <a href="lwg-defects.html#2033">2033</a>, it appears clear that the intended effect includes a reallocation and
|
|
thus the potential effect on iterators should be explicitly added to the text in order to not contradict
|
|
23.2.1 [container.requirements.general]/11, or at the very least, explicitly state that a reallocation may
|
|
happen.
|
|
<p/>
|
|
Taking consistency with "reserve" into consideration, I propose:
|
|
</p>
|
|
<ul>
|
|
<li><p>
|
|
that the current "Remarks" are made its "Effect" instead, inserting "Reallocation happens at this point if and only
|
|
if the function effectively reduces the capacity." after the note on non-bindingness.
|
|
</p>
|
|
</li>
|
|
<li><p>
|
|
adding a "Remarks" paragraph, similar to that of reserve: "Reallocation invalidates all the references, pointers,
|
|
and iterators referring to the elements in the sequence."
|
|
</p></li>
|
|
</ul>
|
|
<p>
|
|
BTW, while we are at it, I believe the effect on iterators should also be explicitly stated in the other instance
|
|
a reallocation may happen: 23.3.6.5 [vector.modifiers]/1 — even if obvious, it only contradicts
|
|
23.2.1 [container.requirements.general]/11 implicitly.
|
|
<p/>
|
|
I propose to also insert "Reallocation invalidates all the references, pointers, and iterators referring to the
|
|
elements in the sequence." at the appropriate location in its "Remarks".
|
|
</p>
|
|
|
|
<p><i>[2012-12-19: Jonathan Wakely comments]</i></p>
|
|
|
|
|
|
<p>
|
|
The described problem also affects <tt>std::basic_string</tt> and <tt>std::deque</tt>.
|
|
</p>
|
|
|
|
<p><i>[2013-03-15 Issues Teleconference]</i></p>
|
|
|
|
<p>
|
|
Moved to Review.
|
|
</p>
|
|
|
|
<p><i>[2013-04-18, Bristol]</i></p>
|
|
|
|
|
|
<p>Daniel extends the P/R.</p>
|
|
|
|
<p>Rationale:</p>
|
|
|
|
<p>The wording in 21.4.4 [string.capacity] combined with 21.4.1 [string.require]
|
|
seems to say the necessary things. We cannot impose all requirements as we do for <tt>vector</tt>, because
|
|
we want to allow the short-string-optimization.</p>
|
|
|
|
|
|
<p><i>[2014-02-15 post-Issaquah session]</i></p>
|
|
|
|
<p>
|
|
STL: I think that <tt>shrink_to_fit</tt> should be a no-op when called twice.
|
|
</p>
|
|
<p>
|
|
STL: Do we ever define reallocation for <tt>deque</tt>? Nope, all mentions of "reallocation" are in <tt>vector</tt>.
|
|
We define what it means in <tt>vector::reserve()</tt>, but not for <tt>deque</tt>.
|
|
</p>
|
|
<p>
|
|
STL: Oh duh, they define reallocate in the PR. But I think we can do better here.
|
|
</p>
|
|
<p>
|
|
STL: Optimally, deque shrinking just allocates a new map of pointers, and drops empty blocks, but preserves pointers/references to elements.
|
|
</p>
|
|
<p>
|
|
Alisdair: That's like unordered containers, invalidating only iterators.
|
|
</p>
|
|
<p>
|
|
Pablo: It doesn't make sense to reduce <tt>capacity()</tt> to <tt>size()</tt>, because <tt>deque</tt> doesn't have capacity!
|
|
</p>
|
|
<p>
|
|
STL: For <tt>vector</tt>, "effectively reduces the capacity" is unnecessary, the capacity there is observable.
|
|
</p>
|
|
<p>
|
|
STL: There is a strong reason to provide an optimal shrink to fit for <tt>deque</tt>, since only the library implementer can do this.
|
|
</p>
|
|
<p>
|
|
STL: The other thing I don't like the repeated definition of reallocation for <tt>vector</tt>, we define it once and use it in a bunch of places.
|
|
At most we can lift it up to the <tt>vector</tt> synopsis.
|
|
</p>
|
|
<p>
|
|
STL: I'll write new wording.
|
|
</p>
|
|
|
|
<p><i>[2014-10-01, STL adds discussion and provides new wording]</i></p>
|
|
|
|
<p>
|
|
Compared to the previous proposed resolution:
|
|
</p>
|
|
<ul>
|
|
<li><p>
|
|
I'm changing <tt>basic_string</tt>'s wording because (1) we should guarantee that capacity won't increase, (2) we should mention
|
|
that it's linear complexity, and (3) we can provide a better invalidation guarantee than 21.4.1 [string.require]/5.
|
|
(As previously noted, we already have the strong exception guarantee.) This introduces the term "reallocation" into
|
|
<tt>basic_string</tt>, but immediately explains what it means for iterator validity. As far as I can tell, the Small String
|
|
Optimization doesn't complicate the wording here; it's a reason why an implementation might not honor the request, but if
|
|
the capacity is reduced, we are definitely reallocating buffers and will invalidate everything (including when the destination
|
|
is the small buffer).
|
|
</p></li>
|
|
<li><p>
|
|
Between N3485 and N3936, <tt>deque</tt>'s wording was updated to avoid talking about <tt>capacity()</tt> which it doesn't have.
|
|
Since the container's capacity is unobservable, I'm saying that invalidation is unconditional.
|
|
</p></li>
|
|
<li><p>
|
|
In <tt>vector</tt>'s wording, I'm also guaranteeing that capacity won't increase, and that iterators/etc. remain valid if the
|
|
capacity is unchanged.
|
|
</p></li>
|
|
</ul>
|
|
<p>
|
|
My wording doesn't directly say that <tt>shrink_to_fit()</tt> should be a no-op when called twice in a row. (Indirectly,
|
|
if the first call reduces <tt>capacity()</tt> to <tt>size()</tt>, the second call must preserve iterators/etc.) I considered
|
|
rewording the complexity to say "linear if reallocation happens", but that's potentially problematic (what if we copy almost
|
|
all <tt>N</tt> elements, then one throws and we have to unwind? There are no effects, so reallocation didn't happen, yet we
|
|
took longer than constant time). Implementers can always do better than the stated complexity bounds.
|
|
<p/>
|
|
I chose not to modify <tt>deque</tt>'s requirements, so implementations remain free to reallocate the elements themselves.
|
|
<p/>
|
|
I didn't attempt to centralize vector's reallocation wording. That can be done editorially, if someone is sufficiently motivated.
|
|
</p>
|
|
|
|
<p><strong>Previous resolution from Juan Soulie/Daniel [SUPERSEDED]:</strong></p>
|
|
|
|
<blockquote class="note">
|
|
<p>This wording is relative to N3485.</p>
|
|
|
|
<ol>
|
|
<li><p>Keep 21.4.4 [string.capacity] around p14 <em>unchanged</em>, because we don't speak about
|
|
reallocations and we give the strong exception guarantee in 21.4.1 [string.require] (Invalidation
|
|
specification also at that place):</p>
|
|
<blockquote><pre>
|
|
void shrink_to_fit();
|
|
</pre>
|
|
<p>
|
|
-14- <i>Remarks</i>: <tt>shrink_to_fit</tt> is a non-binding request to reduce <tt>capacity()</tt> to
|
|
<tt>size()</tt>. [<i>Note</i>: The request is non-binding to allow latitude for implementation-specific
|
|
optimizations. — <i>end note</i> ].
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Edit 23.3.3.3 [deque.capacity] around p7 as indicated:</p>
|
|
<blockquote><pre>
|
|
void shrink_to_fit();
|
|
</pre>
|
|
<p>
|
|
-5- <i>Requires</i>: <tt>T</tt> shall be <tt>MoveInsertable</tt> into <tt>*this</tt>.
|
|
<p/>
|
|
<ins>-?- <i>Effects</i>: <tt>shrink_to_fit</tt> is a non-binding request to reduce <tt>capacity()</tt> to
|
|
<tt>size()</tt>. [<i>Note</i>: The request is non-binding to allow latitude for implementation-specific
|
|
optimizations. — <i>end note</i> ] Reallocation happens at this point if and only
|
|
if the function effectively reduces the capacity. If an exception is thrown other than by the move constructor
|
|
of a non-<tt>CopyInsertable</tt> <tt>T</tt> there are no effects.</ins>
|
|
<p/>
|
|
-6- <i>Complexity</i>: Linear in the size of the sequence.
|
|
<p/>
|
|
-7- <i>Remarks</i>: <del><tt>shrink_to_fit</tt> is a non-binding request to reduce <tt>capacity()</tt> to
|
|
<tt>size()</tt>. [<i>Note</i>: The request is non-binding to allow latitude for implementation-specific
|
|
optimizations. — <i>end note</i> ] If an exception is thrown other than by the move constructor
|
|
of a non-<tt>CopyInsertable</tt> <tt>T</tt> there are no effects.</del><ins>Reallocation invalidates all
|
|
the references, pointers, and iterators referring to the elements in the sequence.</ins>
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Edit 23.3.6.3 [vector.capacity] around p7 as indicated:</p>
|
|
<blockquote><pre>
|
|
void shrink_to_fit();
|
|
</pre>
|
|
<p>
|
|
-7- <i>Requires</i>: <tt>T</tt> shall be <tt>MoveInsertable</tt> into <tt>*this</tt>.
|
|
<p/>
|
|
<ins>-?- <i>Effects</i>: <tt>shrink_to_fit</tt> is a non-binding request to reduce <tt>capacity()</tt> to
|
|
<tt>size()</tt>. [<i>Note</i>: The request is non-binding to allow latitude for implementation-specific
|
|
optimizations. — <i>end note</i> ] Reallocation happens at this point if and only
|
|
if the function effectively reduces the capacity. If an exception is thrown other than by the move constructor
|
|
of a non-<tt>CopyInsertable</tt> <tt>T</tt> there are no effects.</ins>
|
|
<p/>
|
|
-8- <i>Complexity</i>: Linear in the size of the sequence.
|
|
<p/>
|
|
-9- <i>Remarks</i>: <del><tt>shrink_to_fit</tt> is a non-binding request to reduce <tt>capacity()</tt> to
|
|
<tt>size()</tt>. [<i>Note</i>: The request is non-binding to allow latitude for implementation-specific
|
|
optimizations. — <i>end note</i> ] If an exception is thrown other than by the move constructor
|
|
of a non-<tt>CopyInsertable</tt> <tt>T</tt> there are no effects.</del><ins>Reallocation invalidates all
|
|
the references, pointers, and iterators referring to the elements in the sequence.</ins>
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Edit 23.3.6.5 [vector.modifiers] p1 as indicated:</p>
|
|
<blockquote><pre>
|
|
iterator insert(const_iterator position, const T& x);
|
|
iterator insert(const_iterator position, T&& x);
|
|
iterator insert(const_iterator position, size_type n, const T& x);
|
|
template <class InputIterator>
|
|
iterator insert(const_iterator position, InputIterator first, InputIterator last);
|
|
iterator insert(const_iterator position, initializer_list<T>);
|
|
template <class... Args> void emplace_back(Args&&... args);
|
|
template <class... Args> iterator emplace(const_iterator position, Args&&... args);
|
|
void push_back(const T& x);
|
|
void push_back(T&& x);
|
|
</pre>
|
|
<p>
|
|
-1- <i>Remarks</i>: Causes reallocation if the new size is greater than the old capacity. <ins>Reallocation
|
|
invalidates all the references, pointers, and iterators referring to the elements in the sequence.</ins> If
|
|
no reallocation happens, all the iterators and references before the insertion point remain valid. If an
|
|
exception is thrown other than by the copy constructor, move constructor, assignment operator, or move
|
|
assignment operator of <tt>T</tt> or by any <tt>InputIterator</tt> operation there are no effects. If an
|
|
exception is thrown by the move constructor of a non-<tt>CopyInsertable</tt> <tt>T</tt>, the effects are unspecified.
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
</blockquote>
|
|
|
|
<p><i>[2015-02, Cologne]</i></p>
|
|
|
|
<p>
|
|
GR: I'm concerned that <tt>shrink_to_fit</tt> may cause reallocation without changing the capacity. […]
|
|
It's about correctness. The statement about invalidation is useless if I cannot detect whether reallocation has happened?
|
|
<p/>
|
|
AM: It seems like the logic goes the other way round: It's the capacity change that causes reallocation, so if
|
|
there's no capacity change, there's no reallocation. But that's not quite how I'd like to say it... maybe this, :
|
|
"If capacity does not change, no reallocation occurs."
|
|
<p/>
|
|
GR: Where does it actually say that <tt>reserve()</tt> invalidates? AM: It should say that in the container requirements.
|
|
VV: vector specifies in <tt>reserve</tt> that there's reallocation if and only if the capacity changes. GR: I can't find
|
|
anything in the container requirements about <tt>reserve</tt>. DK: No, it's specified for every container separately.
|
|
GR: It isn't specified for string.
|
|
<p/>
|
|
GR: I'm noticing that the issue touches on <tt>shrink_to_fit</tt> for a bunch of containers. Anyway, I think the
|
|
reserve issue [re string] is in scope for this issue. This change is touching on a lot of members.
|
|
<p/>
|
|
AM: Landing this change will provide clarity for what we should do with <tt>basic_string</tt>. GR: We're already asking
|
|
for changes; we should fix string as well. AM: If one of the changes is ready before the other, I'd like to land the
|
|
finished part first, but if both are ready for Lenexa, I'm equally happy to fix them in one go.
|
|
<p/>
|
|
DK will reword this.
|
|
<p/>
|
|
<b>Conclusion</b>: Update wording, revisit in Lenexa.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
This wording is relative to N3936.
|
|
</p>
|
|
|
|
<ol>
|
|
<li><p>Change 21.4.4 [string.capacity] p14 as depicted:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
void shrink_to_fit();
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-14- <i><del>Remarks</del><ins>Effects</ins></i>: <tt>shrink_to_fit</tt> is a non-binding request to reduce
|
|
<tt>capacity()</tt> to <tt>size()</tt>. [<i>Note</i>: The request is non-binding to allow latitude for
|
|
implementation-specific optimizations. — <i>end note</i>] <ins>It does not increase <tt>capacity()</tt>,
|
|
but may reduce <tt>capacity()</tt> by causing reallocation.</ins>
|
|
<p/>
|
|
<ins>-?- <i>Complexity</i>: Linear in the size of the sequence.</ins>
|
|
<p/>
|
|
<ins>-?- <i>Remarks</i>: Reallocation invalidates all the references, pointers, and iterators referring to the
|
|
elements in the sequence. If no reallocation happens, they remain valid.</ins>
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 23.3.3.3 [deque.capacity] p5-p7 as depicted:</p>
|
|
<blockquote>
|
|
<pre>
|
|
void shrink_to_fit();
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-5- <i>Requires</i>: <tt>T</tt> shall be <tt>MoveInsertable</tt> into <tt>*this</tt>.
|
|
<p/>
|
|
<ins>-?- <i>Effects</i>: <tt>shrink_to_fit</tt> is a non-binding request to reduce memory use but does not change
|
|
the size of the sequence. [<i>Note</i>: The request is non-binding to allow latitude for implementation-specific
|
|
optimizations. — <i>end note</i>] If an exception is thrown other than by the move constructor of a
|
|
non-<tt>CopyInsertable</tt> <tt>T</tt> there are no effects.</ins>
|
|
<p/>
|
|
-6- <i>Complexity</i>: Linear in the size of the sequence.
|
|
<p/>
|
|
-7- <i>Remarks</i>: <del><tt>shrink_to_fit</tt> is a non-binding request to reduce memory use but does not change the
|
|
size of the sequence. [<i>Note</i>: The request is non-binding to allow latitude for implementation-specific
|
|
optimizations. — <i>end note</i>]</del><ins><tt>shrink_to_fit</tt> invalidates all the references, pointers,
|
|
and iterators referring to the elements in the sequence.</ins>
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 23.3.6.3 [vector.capacity] p7-p9 as depicted:</p>
|
|
<blockquote>
|
|
<pre>
|
|
void shrink_to_fit();
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-7- <i>Requires</i>: <tt>T</tt> shall be <tt>MoveInsertable</tt> into <tt>*this</tt>.
|
|
<p/>
|
|
<ins>-?- <i>Effects</i>: <tt>shrink_to_fit</tt> is a non-binding request to reduce <tt>capacity()</tt> to <tt>size()</tt>.
|
|
[<i>Note</i>: The request is non-binding to allow latitude for implementation-specific optimizations. — <i>end note</i>]
|
|
It does not increase <tt>capacity()</tt>, but may reduce <tt>capacity()</tt> by causing reallocation. If an exception is
|
|
thrown other than by the move constructor of a non-<tt>CopyInsertable</tt> <tt>T</tt> there are no effects.</ins>
|
|
<p/>
|
|
-8- <i>Complexity</i>: Linear in the size of the sequence.
|
|
<p/>
|
|
-9- <i>Remarks</i>: <del><tt>shrink_to_fit</tt> is a non-binding request to reduce <tt>capacity()</tt> to <tt>size()</tt>.
|
|
[<i>Note</i>: The request is non-binding to allow latitude for implementation-specific optimizations. — <i>end
|
|
note</i>] If an exception is thrown other than by the move constructor of a non-<tt>CopyInsertable</tt> <tt>T</tt> there
|
|
are no effects.</del><ins>Reallocation invalidates all the references, pointers, and iterators referring to the elements
|
|
in the sequence. If no reallocation happens, they remain valid.</ins>
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 23.3.6.5 [vector.modifiers] p1 as depicted:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-1- <i>Remarks</i>: Causes reallocation if the new size is greater than the old capacity. <ins>Reallocation invalidates all
|
|
the references, pointers, and iterators referring to the elements in the sequence.</ins> If no reallocation happens,
|
|
all the iterators and references before the insertion point remain valid. […]
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2224"></a>2224. Ambiguous status of access to non-live objects</h3>
|
|
<p><b>Section:</b> 17.6.4.10 [res.on.objects] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
|
|
<b>Submitter:</b> Geoffrey Romer <b>Opened:</b> 2012-12-17 <b>Last modified:</b> 2015-05-05</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#res.on.objects">issues</a> in [res.on.objects].</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
The standard currently does not discuss when library objects may be accessed, except in a non-normative
|
|
note pertaining to synchronization in [res.on.objects], leaving it ambiguous whether single-threaded
|
|
code can access a library object during its construction or destruction. For example, there is a
|
|
reasonable question as to what happens if the deleter supplied to a <tt>unique_ptr</tt> transitively
|
|
accesses the <tt>unique_ptr</tt> itself during <tt>unique_ptr</tt>'s destruction; a straightforward
|
|
reading suggests that this is permitted, and that the deleter will see the <tt>unique_ptr</tt> still
|
|
holding the originally stored pointer, but consensus on the LWG reflector indicates this was not the
|
|
intent (see discussion beginning with
|
|
<a href="http://accu.org/cgi-bin/wg21/message?wg=lib&msg=33362">c++std-lib-33362</a>).
|
|
</p>
|
|
|
|
<p><i>[2013-03-15 Issues Teleconference]</i></p>
|
|
|
|
<p>
|
|
Moved to Open.
|
|
</p>
|
|
<p>
|
|
Geoffrey will provide an example that clearly highlights the issue.
|
|
</p>
|
|
|
|
<p><i>[2013-03-19 Geoffrey provides revised resolution and an example]</i></p>
|
|
|
|
|
|
<p>
|
|
I contend that the most straightforward reading of the current standard requires the following example code to print
|
|
"good" (because <tt>~unique_ptr</tt> is not specified to modify the state of the internal pointer), but the consensus
|
|
on the reflector was that its behavior should be undefined.
|
|
<p/>
|
|
This example also shows that, contrary to a comment in the telecon, the PR is not tautological. 12.7 [class.cdtor]/p4
|
|
explicitly permits member function calls during destruction, so the behavior of this code is well-defined as far as
|
|
the core language is concerned, despite the fact that it accesses a library object after the end of the object's
|
|
lifetime. If we want this code to have undefined behavior, we need to specify that at the library level.
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
#include <memory>
|
|
#include <iostream>
|
|
|
|
class A;
|
|
|
|
struct B {
|
|
std::unique_ptr<A> a;
|
|
};
|
|
|
|
struct A {
|
|
B* b;
|
|
~A() {
|
|
if (b->a.get() == this) {
|
|
std::cout << "good" << std::endl;
|
|
}
|
|
}
|
|
};
|
|
|
|
int main() {
|
|
B b;
|
|
b.a.reset(new A);
|
|
b.a->b = &b;
|
|
}
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
Previous resolution:
|
|
</p>
|
|
<blockquote class="note">
|
|
<ol>
|
|
<li><p>Change the title of sub-clause 17.6.4.10 [res.on.objects] as indicated:</p>
|
|
<p><del>Shared objects and the library</del><ins>Library object access</ins> [res.on.objects]</p>
|
|
</li>
|
|
|
|
<li><p>Edit 17.6.4.10 [res.on.objects] p2 as indicated:</p>
|
|
<p>-2- <del>[<i>Note</i>: In particular, the program is required to ensure that completion of the constructor
|
|
of any object of a class type defined in the standard library happens before any other member function
|
|
invocation on that object and, unless otherwise specified, to ensure that completion of any member function
|
|
invocation other than destruction on such an object happens before destruction of that object. This applies
|
|
even to objects such as mutexes intended for thread synchronization. — <i>end note</i>]</del>
|
|
<ins>If an object of a standard library type is accessed outside of the object's lifetime (3.8 [basic.life]),
|
|
the behavior is undefined unless otherwise specified.</ins></p>
|
|
</li>
|
|
</ol>
|
|
</blockquote>
|
|
|
|
<p><i>[2014 Urbana]</i></p>
|
|
|
|
<p>
|
|
STL: is this resolved by our change to the reeentrancy rules? [LWG <a href="lwg-active.html#2414">2414</a>]<br/>
|
|
GR: don't think that solves the multi-threaded case<br/>
|
|
MC: I like changing the note to normative text<br/>
|
|
GR: uses the magic "happens before" words, and "access" is magic too<br/>
|
|
JW: I like this. strict improvement, uses the right wording we have to say this properly<br/>
|
|
STL: I like the last sentence of the note, could we add that as a new note at the end?<br/>
|
|
So add "[Note: This applies even to objects such as mutexes intended for thread synchronization.]" to the end and move to Ready
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3485.</p>
|
|
|
|
<ol>
|
|
<li><p>Change the title of sub-clause 17.6.4.10 [res.on.objects] as indicated:</p>
|
|
<p><del>Shared objects and the library</del><ins>Library object access</ins> [res.on.objects]</p>
|
|
</li>
|
|
|
|
<li><p>Edit 17.6.4.10 [res.on.objects] p2 as indicated: <em>[<i>Editorial remark:</i> The motivation, is to
|
|
be more precise about the meaning of "outside the object's lifetime" in the presence of threads — <i>end editorial
|
|
remark</i>]</em></p>
|
|
<p>-2- <del>[<i>Note</i>: In particular, the program is required to ensure that completion of the constructor
|
|
of any object of a class type defined in the standard library happens before any other member function
|
|
invocation on that object and, unless otherwise specified, to ensure that completion of any member function
|
|
invocation other than destruction on such an object happens before destruction of that object. This applies
|
|
even to objects such as mutexes intended for thread synchronization. — <i>end note</i>]</del>
|
|
<ins>If an object of a standard library type is accessed, and the beginning of the object's lifetime
|
|
(3.8 [basic.life]) does not happen before the access, or the access does not happen before the end
|
|
of the object's lifetime, the behavior is undefined unless otherwise specified. [<i>Note</i>: This applies even to
|
|
objects such as mutexes intended for thread synchronization. — <i>end note</i>]</ins></p>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2226"></a>2226. <tt>wstring_convert</tt> methods do not take allocator instance</h3>
|
|
<p><b>Section:</b> 22.3.3.2.2 [conversions.string] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Glen Fernandes <b>Opened:</b> 2012-12-14 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#conversions.string">active issues</a> in [conversions.string].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#conversions.string">issues</a> in [conversions.string].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
The <tt>wstring_convert</tt> class template, described in 22.3.3.2.2 [conversions.string], does not
|
|
support custom stateful allocators. It only supports custom stateless allocators.
|
|
<p/>
|
|
The <tt>to_bytes</tt> member function returns <tt>basic_string<char, char_traits<char>, Byte_alloc></tt>
|
|
but it does not take an instance of <tt>Byte_alloc</tt> to pass to the constructor of the <tt>basic_string</tt>.
|
|
<p/>
|
|
Similarly the <tt>from_bytes</tt> member function returns <tt>basic_string<Elem, char_traits<Elem>, Wide_alloc></tt>
|
|
but it does not take an instance of <tt>Wide_alloc</tt> to pass to the constructor of the <tt>basic_string</tt>.
|
|
<p/>
|
|
This makes these two member functions and the <tt>wstring_convert</tt> class template not usable when <tt>Wide_alloc</tt>
|
|
or <tt>Byte_alloc</tt> are stateful allocators.
|
|
</p>
|
|
|
|
<p><i>[2013-01-22, Glen provides wording]</i></p>
|
|
|
|
|
|
<p><i>[2013-03-15 Issues Teleconference]</i></p>
|
|
|
|
<p>
|
|
Moved to NAD Future.
|
|
</p>
|
|
<p>
|
|
This is clearly an extension that the LEWG may want to take a look at, once we have more experience
|
|
with appropriate use of allocators with the C++11 model.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3485.</p>
|
|
|
|
<ol>
|
|
<li><p>In 22.3.3.2.2 [conversions.string]/2 and /6 "Class template <tt>wstring_convert</tt> synopsis" change the overloads
|
|
of the member function <tt>from_bytes()</tt> so that all four overloads take an additional parameter
|
|
which is an instance of <tt>Wide_alloc</tt>:</p>
|
|
|
|
<blockquote><pre>
|
|
wide_string from_bytes(char byte<ins>, const Wide_alloc& alloc = Wide_alloc()</ins>);
|
|
wide_string from_bytes(const char *ptr<ins>, const Wide_alloc& alloc = Wide_alloc()</ins>);
|
|
wide_string from_bytes(const byte_string& str<ins>, const Wide_alloc& alloc = Wide_alloc()</ins>);
|
|
wide_string from_bytes(const char *first, const char *last<ins>, const Wide_alloc& alloc = Wide_alloc()</ins>);
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li><p>In 22.3.3.2.2 [conversions.string] /8 specify that this <tt>Wide_alloc</tt> allocator parameter is used to
|
|
construct the <tt>wide_string</tt> object returned from the function:</p>
|
|
|
|
<p>
|
|
-7- <i>Effects</i>: The first member function shall convert the single-element sequence <tt>byte</tt> to a wide string.
|
|
The second member function shall convert the null-terminated sequence beginning at <tt>ptr</tt> to a wide
|
|
string. The third member function shall convert the sequence stored in <tt>str</tt> to a wide string. The fourth
|
|
member function shall convert the sequence defined by the range <tt>[first, last)</tt> to a wide string.
|
|
<p/>
|
|
-8- In all cases:
|
|
</p>
|
|
<ul>
|
|
<li><p>If the <tt>cvtstate</tt> object was not constructed with an explicit value, it shall be set to its default value
|
|
(the initial conversion state) before the conversion begins. Otherwise it shall be left unchanged.</p></li>
|
|
|
|
<li><p>The number of input elements successfully converted shall be stored in <tt>cvtcount</tt>.</p></li>
|
|
|
|
<li><p><ins>The <tt>Wide_alloc</tt> allocator parameter is used to construct the <tt>wide_string</tt> object returned
|
|
from the function.</ins></p></li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li><p>In 22.3.3.2.2 [conversions.string]/2 and /12 "Class template <tt>wstring_convert</tt> synopsis" change the overloads
|
|
of the member function <tt>to_bytes()</tt> so that all four overloads take an additional parameter
|
|
which is an instance of <tt>Byte_alloc</tt>:</p>
|
|
|
|
<blockquote><pre>
|
|
byte_string to_bytes(Elem wchar<ins>, const Byte_alloc& alloc = Byte_alloc()</ins>);
|
|
byte_string to_bytes(const Elem *wptr<ins>, const Byte_alloc& alloc = Byte_alloc()</ins>);
|
|
byte_string to_bytes(const wide_string& wstr<ins>, const Byte_alloc& alloc = Byte_alloc()</ins>);
|
|
byte_string to_bytes(const Elem *first, const Elem *last<ins>, const Byte_alloc& alloc = Byte_alloc()</ins>);
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li><p>In 22.3.3.2.2 [conversions.string] /13 specify that this <tt>Byte_alloc</tt> allocator parameter is used to
|
|
construct the <tt>byte_string</tt> object returned from the function:</p>
|
|
|
|
<p>
|
|
-12- <i>Effects</i>: The first member function shall convert the single-element sequence <tt>wchar</tt> to a byte string.
|
|
The second member function shall convert the null-terminated sequence beginning at <tt>wptr</tt> to a byte
|
|
string. The third member function shall convert the sequence stored in <tt>wstr</tt> to a byte string. The
|
|
fourth member function shall convert the sequence defined by the range <tt>[first, last)</tt> to a byte string.
|
|
<p/>
|
|
-13- In all cases:
|
|
</p>
|
|
<ul>
|
|
<li><p>If the <tt>cvtstate</tt> object was not constructed with an explicit value, it shall be set to its default value
|
|
(the initial conversion state) before the conversion begins. Otherwise it shall be left unchanged.</p></li>
|
|
|
|
<li><p>The number of input elements successfully converted shall be stored in <tt>cvtcount</tt>.</p></li>
|
|
|
|
<li><p><ins>The <tt>Byte_alloc</tt> allocator parameter is used to construct the <tt>byte_string</tt> object returned
|
|
from the function.</ins></p></li>
|
|
</ul>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2227"></a>2227. Stateful comparison objects in associative containers</h3>
|
|
<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Juan Soulie <b>Opened:</b> 2012-12-19 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
Table 102 in 23.2.4 [associative.reqmts]/8 states on expression <tt>a.key_comp()</tt> that it
|
|
"returns the comparison object out of which a was constructed". At the same time,
|
|
23.2.1 [container.requirements.general]/8 states (starting in the third line) that
|
|
"...Any <tt>Compare</tt>, <tt>Pred</tt>, or <tt>Hash</tt> objects belonging to <tt>a</tt> and <tt>b</tt>
|
|
shall be swappable and <em>shall be exchanged</em> by unqualified calls to non-member swap...". This is
|
|
problematic for any compliant implementation, since once swapped the container cannot return the comparison
|
|
object out of which it was constructed unless incurring in storing an otherwise needless object.
|
|
<p/>
|
|
The simple solution is to correct that statement in Table 102, but I believe this is part of a larger problem
|
|
of underspecified behavior: The new standard has made an effort in regards to allocators and now fully
|
|
specifies what happens to stateful allocator objects. It has even specified what happens to stateful <tt>hasher</tt>
|
|
and <tt>key_equal</tt> members of unordered containers (they propagate), but it says nothing about stateful
|
|
comparison objects of (ordered) associative containers, except for the statement in
|
|
23.2.1 [container.requirements.general]/8 referred above and only related to <tt>swap</tt>.
|
|
<p/>
|
|
For example, it is unclear to me what is specified to happen on an assignment: should the comparison object
|
|
be copied/moved along with the elements, or should the left-hand side object keep its own?
|
|
Maybe this has been intentionally left unspecified with the purpose of compatibility with C++98, which I
|
|
understand it specified that comparison objects were kept for the entire life of the container (like allocators)
|
|
— an unfortunate choice. But anyway, the segment of 23.2.1 [container.requirements.general] quoted
|
|
above seems to break any possible backwards compatibility with C++98 in this regard.
|
|
<p/>
|
|
Therefore, taking into consideration consistency with how this is dealed with for unordered associative
|
|
containers, I propose that Table 102 is modified as follows:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
The row for expression <tt>a.key_comp()</tt> is changed so that its "assertion/note pre-/post-condition" reads
|
|
"Returns <tt>a</tt>'s comparison object."
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
A new row is added at the appropriate location (which I believe would be after "X(il)" row), with:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 102 — Associative container requirements (in addition to container)</caption>
|
|
<tr>
|
|
<th>Expression</th>
|
|
<th>Return type</th>
|
|
<th>Assertion/note pre-/post-condition</th>
|
|
<th>Complexity</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>X(b)<br/>
|
|
X a(b)</tt>
|
|
</td>
|
|
<td>
|
|
<tt>X</tt>
|
|
</td>
|
|
<td>
|
|
Copy constructor. In addition to<br/>
|
|
the requirements of Table 96, copies<br/>
|
|
the comparison object.
|
|
</td>
|
|
<td>
|
|
Linear in <tt>b.size()</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a = b</tt>
|
|
</td>
|
|
<td>
|
|
<tt>X&</tt>
|
|
</td>
|
|
<td>
|
|
Copy assignment operator. In addition to<br/>
|
|
the requirements of Table 96, copies the<br/>
|
|
comparison object.
|
|
</td>
|
|
<td>
|
|
Linear in <tt>a.size()</tt> and <tt>b.size()</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote>
|
|
|
|
</li>
|
|
</ul>
|
|
|
|
<p><i>[2013-03-15 Issues Teleconference]</i></p>
|
|
|
|
<p>
|
|
Moved to Review.
|
|
</p>
|
|
|
|
<p><i>[2013-04-18, Bristol]</i></p>
|
|
|
|
<p>
|
|
STL: can't believe we don't specify this already. this is totally necessary
|
|
<p/>
|
|
Alisdair: how does it do this? copy construction? assignment?
|
|
<p/>
|
|
Also need it for move.
|
|
<p/>
|
|
STL: we already specify this for constructing from a comparator, not during copy construction though.
|
|
<p/>
|
|
Jonathan: don't like wording, should say "<tt>key_compare</tt> is <tt>CopyConstructible</tt>. Uses <tt>b.key_comp()</tt>
|
|
as a comparison object."
|
|
<p/>
|
|
STL: we get it right for unordered!
|
|
<p/>
|
|
Jonathan: can't wordsmith this now, but I think implementations do the right thing.
|
|
<p/>
|
|
Alisdair: not sure what right thing is for moves. Also we say nothing about propagating allocators to functors.
|
|
</p>
|
|
<p>
|
|
Moved to Open.
|
|
</p>
|
|
|
|
<p><i>[2015-02 Cologne]</i></p>
|
|
|
|
<p>
|
|
TK: There's no need for fine-grained propagate/not-propagate control. If you don't want to propagate the predicate, you can
|
|
simply construct or insert from an iterator range.
|
|
<p/>
|
|
VV: libstdc++ already implements the resolution of this issue.
|
|
<p/>
|
|
GR: There are a couple of other problems. We don't specify move constructor and move assignment for maps. Those are just general.
|
|
<p/>
|
|
TK: General container requirements already describe the semantics for {copy,move}-{construction,assignment}, so it doesn't
|
|
seem that there's room for choice in <tt>std::map</tt> assignments. <tt>unordered_map</tt> is different, though.
|
|
<p/>
|
|
[Note: Check what general container requirements say about container equality.]
|
|
<p/>
|
|
DK will draft wording. The decision is to unambiguously make all {copy,move}-{construction,assignment} operations endow the
|
|
LHS with the exact state of the RHS, including all predicates and hash function states.
|
|
<p/>
|
|
Conclusion: Update wording, revisit later.
|
|
</p>
|
|
|
|
<p><i>[2015-05-06 Lenexa: Waiting for updated wording]</i></p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3485.</p>
|
|
|
|
<ol>
|
|
<li><p>Change Table 102 as indicated:</p>
|
|
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 102 — Associative container requirements (in addition to container)</caption>
|
|
<tr>
|
|
<th>Expression</th>
|
|
<th>Return type</th>
|
|
<th>Assertion/note pre-/post-condition</th>
|
|
<th>Complexity</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="4" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>X(il)</tt>
|
|
</td>
|
|
<td>
|
|
<tt></tt>
|
|
</td>
|
|
<td>
|
|
Same as <tt>X(il.begin(), il.end())</tt>.
|
|
</td>
|
|
<td>
|
|
same as <tt>X(il.begin(), il.end())</tt>.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<ins><tt>X(b)<br/>
|
|
X a(b)</tt></ins>
|
|
</td>
|
|
<td>
|
|
<tt></tt>
|
|
</td>
|
|
<td>
|
|
<ins>Copy constructor. In addition to<br/>
|
|
the requirements of Table 96, copies<br/>
|
|
the comparison object.</ins>
|
|
</td>
|
|
<td>
|
|
<ins>Linear in <tt>b.size()</tt></ins>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<ins><tt>a = b</tt></ins>
|
|
</td>
|
|
<td>
|
|
<ins><tt>X&</tt></ins>
|
|
</td>
|
|
<td>
|
|
<ins>Copy assignment operator. In addition to<br/>
|
|
the requirements of Table 96, copies the<br/>
|
|
comparison object.</ins>
|
|
</td>
|
|
<td>
|
|
<ins>Linear in <tt>a.size()</tt> and <tt>b.size()</tt></ins>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="4" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a.key_comp()</tt>
|
|
</td>
|
|
<td>
|
|
<tt>X::key_compare</tt>
|
|
</td>
|
|
<td>
|
|
<del>r</del><ins>R</ins>eturns <del>the</del><ins><tt>a</tt>'s</ins> comparison object<br/>
|
|
<del>out of which a was constructed.</del>
|
|
</td>
|
|
<td>
|
|
constant
|
|
</td>
|
|
</tr>
|
|
|
|
|
|
</table>
|
|
</blockquote>
|
|
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2232"></a>2232. [CD] The <tt>char_traits</tt> specializations should declare their <tt>length()</tt>, <tt>compare()</tt>, and
|
|
<tt>find()</tt> members constexpr</h3>
|
|
<p><b>Section:</b> 21.2.3 [char.traits.specializations] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2012-12-24 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#char.traits.specializations">issues</a> in [char.traits.specializations].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p><b>Addresses ES 14, US 19</b></p>
|
|
|
|
<p>
|
|
These functions have easy recursive constexpr implementations that, unfortunately, aren't efficient at runtime.
|
|
EWG is still figuring out how to solve this problem in general (e.g.,
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3444.html">N3444</a> isn't sufficient to avoid
|
|
stack overflows in debug builds or to get the optimal assembly-based implementations at runtime), so users can't
|
|
portably solve this problem for themselves, but implementations can use compiler-specific techniques to choose
|
|
the right implementation inside their standard libraries.
|
|
</p>
|
|
|
|
<p>
|
|
The LWG is still undecided about whether individual implementations can add constexpr to these functions, so we
|
|
need to add <tt>constexpr</tt> to the standard here for implementations to be able to improve this.
|
|
</p>
|
|
|
|
<p><i>[2013-03-15 Issues Teleconference]</i></p>
|
|
|
|
<p>
|
|
Moved to Open.
|
|
</p>
|
|
<p>
|
|
There are a number of people who have a strong interest in this issue not available for the telecon.
|
|
</p>
|
|
<p>
|
|
It also plays at the heart of a discussion about library freedoms for <tt>constexpr</tt> and specifying
|
|
a library that may depend on unspecified compiler intrinsics to be implementable.
|
|
</p>
|
|
|
|
<p><i>[2013-09 Chicago]</i></p>
|
|
|
|
<p>
|
|
Moved to NAD Future.
|
|
</p>
|
|
<p>
|
|
While it is clear that this feature can be implemented using only C++14 <tt>constexpr</tt> features,
|
|
there is real concern that we cannot call the efficient, highly optimized, C implementations of these
|
|
functions under a C++14 <tt>constexpr</tt> implementation, nor implement similar ourselves as this
|
|
typically involves use of inline <tt>asm</tt> instructions.
|
|
</p>
|
|
<p>
|
|
Clang and libc++ have some experience of using intrinsics to try to address the performance issue, but
|
|
the current intrinsics are not general enough to support <tt>char_traits</tt>. The intrinsics support
|
|
only operations on character string literals, and the string literal is no longer visible <i>as</i> a
|
|
literal after passing as a <tt>const char *</tt> to the <tt>char_traits</tt> functions.
|
|
</p>
|
|
<p>
|
|
Additional concern was raised that these operations are unlikely to be useful anyway, as the only client
|
|
is <tt>basic_string</tt> which relies on dynamic memory allocation, and so cannot effectively be made a
|
|
literal type. Jeffrey then pointed out the pending <tt>string_view</tt> library that will also use
|
|
<tt>char_traits</tt> and would most certainly benefit from being a literal type.
|
|
</p>
|
|
|
|
<p>
|
|
Given the choice of giving up performance on a critical library component, or requiring a compiler
|
|
intrinsic with only unsuccessful implementation experience, the consensus is to not reject this, unless
|
|
compelling implementation experience is demonstrated. NAD Future seems the appropriate resolution.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3691.</p>
|
|
|
|
<ol>
|
|
<li><p>In 21.2.3.1 [char.traits.specializations.char], 21.2.3.2 [char.traits.specializations.char16_t],
|
|
21.2.3.3 [char.traits.specializations.char32_t], and 21.2.3.4 [char.traits.specializations.wchar.t]:</p>
|
|
<blockquote><pre>
|
|
static <ins>constexpr</ins> int compare(const char_type* s1, const char_type* s2, size_t n);
|
|
static <ins>constexpr</ins> size_t length(const char_type* s);
|
|
static <ins>constexpr</ins> const char_type* find(const char_type* s, size_t n, const char_type& a);
|
|
</pre></blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2234"></a>2234. <tt>assert()</tt> should allow usage in constant expressions</h3>
|
|
<p><b>Section:</b> 19.3 [assertions] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2013-01-12 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#assertions">active issues</a> in [assertions].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#assertions">issues</a> in [assertions].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
It is unclear from the current specification whether <tt>assert()</tt> expressions can be used in
|
|
(potential) constant expressions. As an example consider the implementation of a <tt>constexpr</tt>
|
|
function:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
#include <cassert>
|
|
|
|
template<class T, unsigned N>
|
|
struct array {
|
|
T data[N];
|
|
constexpr const T& operator[](unsigned i) const {
|
|
return assert(i < N), data[i];
|
|
}
|
|
};
|
|
|
|
int main() {
|
|
constexpr array<int, 3> ai = {1, 2, 3};
|
|
constexpr int i = ai[0];
|
|
int j = ai[0];
|
|
// constexpr int k = ai[5];
|
|
}
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
The first question is whether this program is guaranteed well-formed? A second question is whether is would guaranteed to be
|
|
ill-formed, if we uncomment the last code line in <tt>main()</tt>?
|
|
</p>
|
|
|
|
<p>
|
|
The wording in 19.3 [assertions] doesn't add anything significant to the C99 wording. From the C99 specification
|
|
(7.2 p1 and 7.2.1.1 p2) we get already some valuable guarantees:
|
|
</p>
|
|
|
|
<ul>
|
|
<li><p>
|
|
The expression <tt>assert(e)</tt> is a <tt>void</tt> expression for all expressions <tt>e</tt> independent of
|
|
the definition of <tt>NDEBUG</tt>.
|
|
</p></li>
|
|
<li><p>
|
|
If <tt>NDEBUG</tt> is defined, <tt>assert(e)</tt> is equivalent to the expression <tt>void()</tt>
|
|
(or anything that cannot be distinguished from that).
|
|
</p></li>
|
|
</ul>
|
|
|
|
<p>
|
|
The current wording does not yet <em>guarantee</em> that <tt>assert</tt> expressions can be used in constant expressions,
|
|
but all tested implementations (gcc, MSVC) would already support this use-case. It seems to me that this should be possible
|
|
without giving <tt>assert</tt> a special meaning for the core language.
|
|
<p/>
|
|
As a related comment it should be added, that there is a core language
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3444.html">proposal</a>
|
|
that intents to relax some current constraints for <tt>constexpr</tt> functions and <tt>literal</tt> types. The most
|
|
interesting one (making <tt>void</tt> a literal types and allowing for expression-statements) would simplify the motivating
|
|
example implementation of <tt>operator[]</tt> to:
|
|
</p>
|
|
<blockquote><pre>
|
|
constexpr const T& operator[](unsigned i) const {
|
|
assert(i < N);
|
|
return data[i];
|
|
};
|
|
</pre></blockquote>
|
|
|
|
<p><i>[2013-03-15 Issues Teleconference]</i></p>
|
|
|
|
<p>
|
|
Moved to Open.
|
|
</p>
|
|
<p>
|
|
We are still gaining experience with <tt>constexpr</tt> as a language feature, and there may
|
|
be work in Evolution that would help address some of these concerns. Defer discussion until
|
|
we have a group familiar with any evolutionary direction.
|
|
</p>
|
|
|
|
<p><i>[2014-06-08, Daniel comments and suggests wording]</i></p>
|
|
|
|
<p>
|
|
After approval of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3652.html"/>N3652<a/>,
|
|
<tt>void</tt> is now a literal type and <tt>constexpr</tt> functions can contain multiple statements, so
|
|
this makes the guarantee that <tt>assert</tt> expressions are per-se <tt>constexpr</tt>-friendly even more
|
|
relevant. A possible wording form could be along the lines of:
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
For every core constant expression <em>e</em> of scalar type that evaluates to <tt>true</tt> after being contextually
|
|
converted to <tt>bool</tt>, the expression <tt>assert(<em>e</em>)</tt> shall be a prvalue core constant expression of type
|
|
<tt>void</tt>.
|
|
</p>
|
|
</blockquote>
|
|
<p>
|
|
Richard Smith pointed out some weaknesses of this wording form, for example it would not guarantee to require
|
|
the following example to work:
|
|
</p>
|
|
<blockquote><pre>
|
|
constexpr void check(bool b) { assert(b); }
|
|
</pre></blockquote>
|
|
<p>
|
|
because <tt>b</tt> is not a core constant expression in this context.
|
|
<p/>
|
|
He suggested improvements that lead to the wording form presented below (any defects mine).
|
|
</p>
|
|
|
|
<p><i>[Lenexa 2015-05-05]</i></p>
|
|
|
|
<p>MC : ran into this</p>
|
|
<p>Z : Is it guaranteed to be an expression?</p>
|
|
<p>MC : clarifies that assert runs at runtime, not sure what it does at compile time</p>
|
|
<p>STL : c standard guarantees its an expression and not a whole statement, so comma chaining it is ok</p>
|
|
<p>HH : Some implementations work as author wants it to</p>
|
|
<p>STL : also doing this as constexpr</p>
|
|
<p>DK/STL : discussing how this can actually work</p>
|
|
<p>HH : GCC 5 also implements it. We have implementor convergence</p>
|
|
<p>MC : Wants to do this without giving assert a special meaning</p>
|
|
<p>STL : NDEBUG being defined where assert appears is not how assert works. This is bug in wording. Should be "when assert is defined" or something like that. ... is a constant subexpression if NDEBUG is defined at the point where assert is last defined or redefined."</p>
|
|
<p>Would like to strike the "either" because ok if both debug or assertion is true. We want inclusive-or here</p>
|
|
<p>MC : is redefined needed?</p>
|
|
<p>STL : my mental model is its defined once and then redefined</p>
|
|
<p>HH : wants to up to P2</p>
|
|
<p>Z/STL : discussing how wording takes care of how/when assert is defined/redefefined</p>
|
|
<p>STL/WB : discussing whether to move to ready or review. -> Want to move it to ready.</p>
|
|
<p>ask for updated wording</p>
|
|
<p>p3 -> p2</p>
|
|
<p>plan to go to ready after checking wording</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Introduce the following new definition to the existing list in 17.3 [definitions]: [<i>Drafting note</i>:
|
|
If LWG <a href="lwg-active.html#2296">2296</a> is accepted before this issue, the accepted wording for the new definition should be used instead
|
|
— <i>end drafting note</i>]</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<strong>constant subexpression</strong> [defns.const.subexpr]
|
|
<p/>
|
|
an expression whose evaluation as subexpression of a <em>conditional-expression</em> <em>CE</em> (5.16 [expr.cond])
|
|
would not prevent <em>CE</em> from being a core constant expression (5.20 [expr.const]).
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Insert a new paragraph following 19.3 [assertions] p1 as indicated:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<ins>-?- An expression <tt>assert(<em>E</em>)</tt> is a constant subexpression ( [defns.const.subexpr]), if either</ins>
|
|
</p>
|
|
<ul>
|
|
<li><p><ins><tt>NDEBUG</tt> is defined at the point where <tt>assert(<em>E</em>)</tt> appears, or</ins></p></li>
|
|
<li><p><ins><tt><em>E</em></tt> contextually converted to <tt>bool</tt> (4 [conv]), is a constant subexpression
|
|
that evaluates to the value <tt>true</tt>.</ins></p></li>
|
|
</ul>
|
|
</blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2236"></a>2236. <tt>kill_dependency</tt> unconditionally noexcept</h3>
|
|
<p><b>Section:</b> 29.2 [atomics.syn], 29.3 [atomics.order] <b>Status:</b> <a href="lwg-active.html#SG1">SG1</a>
|
|
<b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2013-01-19 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#atomics.syn">issues</a> in [atomics.syn].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#SG1">SG1</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The "magic" <tt>kill_dependency</tt> function is a function without any constraints on the template parameter <tt>T</tt>
|
|
and is specified as
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
template <class T>
|
|
T kill_dependency(T y) noexcept;
|
|
</pre><blockquote>
|
|
<p>
|
|
-14- <i>Effects</i>: The argument does not carry a dependency to the return value (1.10).
|
|
<p/>
|
|
-15- <i>Returns</i>: <tt>y</tt>.
|
|
</p>
|
|
</blockquote></blockquote>
|
|
|
|
<p>
|
|
I wonder whether the unconditional <tt>noexcept</tt> is really intended here:
|
|
Assume we have some type <tt>U</tt> that has a potentially throwing move
|
|
constructor (or it has a potentially throwing copy constructor and no
|
|
move constructor), for any "normal" function template with the same
|
|
signature and the same effects (modulo the dependency magic) this
|
|
would mean that it cannot safely be declared <tt>noexcept</tt> because of the
|
|
return statement being part of the complete function call affected by
|
|
<tt>noexcept</tt> (The by-value function argument is irrelevant in this
|
|
context). In other words it seems that a function call such as
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
struct S {
|
|
...
|
|
S(const S& r) { if(<em>some condition</em>) throw Something(); }
|
|
...
|
|
};
|
|
|
|
int main() {
|
|
S s1 = ...;
|
|
S s2 = std::kill_dependency(s1);
|
|
}
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
would be required to call <tt>std::terminate</tt> if the copy constructor of <tt>S</tt> throws during the return
|
|
of <tt>std::kill_dependency</tt>.
|
|
<p/>
|
|
To require copy elision for this already magic function would look like a low-hanging fruit to solve this problem,
|
|
but this case is not covered by current copy elision rules see 12.8 p31 b1:
|
|
<p/>
|
|
"— in a return statement in a function with a class return type, when the expression is the name of a non-volatile
|
|
automatic object (other than a function or catch-clause parameter) with the same <em>cv</em>-unqualified type as the
|
|
function return type, the copy/move operation can be omitted by constructing the automatic object directly into the
|
|
function's return value".
|
|
<p/>
|
|
Some options come into my mind:
|
|
</p>
|
|
<ol>
|
|
<li><p>
|
|
Make the exception-specification a constrained one in regard via <tt>std::is_nothrow_move_constructible</tt>:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
template <class T>
|
|
T kill_dependency(T y) noexcept(<em>see below</em>);
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
This is similar to the approach taken for function templates such as <tt>std::swap</tt>.
|
|
</p>
|
|
</li>
|
|
|
|
<li><p>
|
|
Use perfect forwarding (This needs further wording to correct the effects):
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
template <class T>
|
|
T&& kill_dependency(T&& y) noexcept;
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li><p>
|
|
Impose constraints on the template arguments in regard to throwing exceptions while copying/moving.
|
|
</p></li>
|
|
|
|
<li><p>
|
|
Keep the state as it is but possibly add a note about a call of <tt>std::terminate</tt> in above scenario.
|
|
</p></li>
|
|
</ol>
|
|
|
|
<p>
|
|
A second problem is that the current wording is not clear whether it is well-defined to call the function with
|
|
types that are reference types, such as in the following example:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
#include <atomic>
|
|
|
|
int main()
|
|
{
|
|
int a = 12;
|
|
int& b = std::kill_dependency<int&>(a);
|
|
}
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
It is unclear what kind of dependency is killed here. This is presumably a core language problem, but could
|
|
affect the possible resolutions of the problem.
|
|
</p>
|
|
|
|
<p><i>[2014-11 Urbana]</i></p>
|
|
|
|
<p>
|
|
Recommend using a revised example:
|
|
</p>
|
|
<blockquote><pre>
|
|
int lookup(class D* p)
|
|
{
|
|
class E* q = p->a.load(memory_order_consume);
|
|
int y = std::kill_dependency(q->y);
|
|
}
|
|
</pre></blockquote>
|
|
|
|
<p><i>[2015-02 Cologne]</i></p>
|
|
|
|
<p>
|
|
Handed over to SG1.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2237"></a>2237. <tt><cuchar></tt> macros</h3>
|
|
<p><b>Section:</b> 21.8 [c.strings] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Jason Merrill <b>Opened:</b> 2013-01-29 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#c.strings">active issues</a> in [c.strings].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#c.strings">issues</a> in [c.strings].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Apparently C1X changes <tt>__STDC_UTF_16__</tt> and <tt>__STDC_UTF_32__</tt> from macros
|
|
defined in <tt>uchar.h</tt> (and reflected in C++ by Table 79) to be predefined by the compiler.
|
|
Do we want to do the same?
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2238"></a>2238. Problematic iterator-pair constructor of containers</h3>
|
|
<p><b>Section:</b> 21.8 [c.strings] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Johannes Schaub <b>Opened:</b> 2013-02-02 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#c.strings">active issues</a> in [c.strings].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#c.strings">issues</a> in [c.strings].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The non-explicit nature of the iterator-pair constructor of containers, such a
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
template <class InputIterator>
|
|
vector(InputIterator first, InputIterator last, const Allocator& = Allocator());
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
can be selected in unexpected situations, leading to a hard runtime error, as demonstrated by the following example:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
#include <vector>
|
|
|
|
void f(std::vector<char> v){ /* ... */}
|
|
|
|
int main() {
|
|
f({"A", "B"});
|
|
}
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
The actually intended initializer-list constructor isn't feasible here, so the best match is the constructor template
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
template <class InputIterator>
|
|
vector(InputIterator first, InputIterator last, const Allocator& = Allocator());
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
This compiles, but will result in code running amok. The potential trap (that cannot be easily detected by the
|
|
library implementation) could be reduced by making this constructor explicit. It would still have the effect to
|
|
be selected here, but the code would be ill-formed, so the programmer gets a clear meassage here.
|
|
</p>
|
|
|
|
<p><i>[2014-06 Rapperswil]</i></p>
|
|
|
|
<p>
|
|
JW: can't fix this, don't want to touch this, Do The Right Thing clause has been a source of tricky issues.
|
|
only really happens with string literals, that's the only way to create an array that isn't obviously an array
|
|
<p/>
|
|
GR: want to see paper
|
|
<p/>
|
|
AM: is it only string literals, or also UDLs?
|
|
<p/>
|
|
STL: maybe, but we don't need to deal with that. This is only a problem in a very specific case
|
|
<p/>
|
|
Leave as Open.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2241"></a>2241. <tt><cstdalign></tt> and <tt>#define</tt> of <tt>alignof</tt></h3>
|
|
<p><b>Section:</b> 18.10 [support.runtime] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Richard Smith <b>Opened:</b> 2013-02-14 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#support.runtime">active issues</a> in [support.runtime].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#support.runtime">issues</a> in [support.runtime].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
According to 18.10 [support.runtime] p2:
|
|
</p>
|
|
|
|
<blockquote><p>
|
|
The contents of these headers are the same as the Standard C library headers [..], <tt><stdalign.h></tt>, [..]
|
|
</p></blockquote>
|
|
|
|
<p>
|
|
Since our base C standard is C99, which doesn't have a <tt><stdalign.h></tt>, the reference to a non-existing
|
|
C header is irritating (In this context <tt><stdalign.h></tt> doesn't refer to the deprecated C++ header
|
|
<tt><stdalign.h></tt> described in D.5 [depr.c.headers]).
|
|
<p/>
|
|
Furthermore, it would be also important that it doesn not define a macro named <tt>alignof</tt>, which C11 also defines
|
|
in this header.
|
|
<p/>
|
|
Currently we only have the following guarantee as part of 18.10 [support.runtime] p7:
|
|
</p>
|
|
|
|
<blockquote><p>
|
|
The header <tt><cstdalign></tt> and the header <tt><stdalign.h></tt> shall not define a macro named
|
|
<tt>alignas</tt>.
|
|
</p></blockquote>
|
|
|
|
<p>
|
|
It is unclear what the better strategy is: Striking the reference to <tt><stdalign.h></tt> in
|
|
18.10 [support.runtime] p2 or upgrading to C11 as new base C standard.
|
|
</p>
|
|
|
|
<p><i>[2014-02-15 Issaquah]</i></p>
|
|
|
|
<p>
|
|
STL: related to earlier issue on C4, <a href="lwg-active.html#2201">2201</a>, and now we get a C11 header
|
|
</p>
|
|
<p>
|
|
JY: find _Alignof as keyword C11 FDIS has four defines in stdalign.h
|
|
</p>
|
|
<p>
|
|
AM: need paper for C11 as base library we should really do that
|
|
</p>
|
|
<p>
|
|
STL: really need vendor input
|
|
</p>
|
|
<p>
|
|
STL: don't think we need to do anything right now not P1
|
|
</p>
|
|
<p>
|
|
AM: any objections to downscale to P2 (no objections)
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2242"></a>2242. <tt>[uninitialized_]copy_n()</tt> defect</h3>
|
|
<p><b>Section:</b> 25.3.1 [alg.copy], 20.7.12.2 [uninitialized.copy] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Sean Parent <b>Opened:</b> 2013-02-14 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#alg.copy">active issues</a> in [alg.copy].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#alg.copy">issues</a> in [alg.copy].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
<tt>copy_n()</tt> and <tt>uninitialized_copy_n()</tt> only return the output iterator, and not the input iterator.
|
|
Likely the interface was simply copied from the original STL. Unfortunately the interface in the original STL contains a bug.
|
|
<p/>
|
|
<tt>copy_n()</tt> and <tt>uninitialized_copy_n()</tt> must return the resulting input iterator as well as the output
|
|
iterator (I would suggest returning a pair). Without this, there is no way to continue reading from an actual input
|
|
iterator — and if it is really a forward iterator, it will cost <tt>n</tt> increments to get back to where you were.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2243"></a>2243. <tt>istream::putback</tt> problem</h3>
|
|
<p><b>Section:</b> 27.7.2.3 [istream.unformatted] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Juan Soulie <b>Opened:</b> 2013-03-01 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#istream.unformatted">active issues</a> in [istream.unformatted].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
In 27.7.2.3 [istream.unformatted] / 34, when describing <tt>putback</tt>, it says that "<tt>rdbuf->sputbackc()</tt>"
|
|
is called. The problem are not the obvious typos in the expression, but the fact that it may lead to different
|
|
interpretations, since nowhere is specified what the required argument to <tt>sputbackc</tt> is.
|
|
<p/>
|
|
It can be guessed to be "<tt>rdbuf()->sputbackc(c)</tt>", but "<tt>rdbuf()->sputbackc(char_type())</tt>" or
|
|
just anything would be as conforming (or non-confoming) as the first guess.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2244"></a>2244. Issue on <tt>basic_istream::seekg</tt></h3>
|
|
<p><b>Section:</b> 27.7.2.3 [istream.unformatted] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Juan Soulie <b>Opened:</b> 2013-03-04 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#istream.unformatted">active issues</a> in [istream.unformatted].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
When issue <a href="lwg-defects.html#1445">1445</a> was resolved by adopting
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3168.htm">N3168</a>, it exposed the need to
|
|
modify both overloads of <tt>basic_istream::seekg</tt> (by inserting "the function clears eofbit," after "except that"),
|
|
but the fix applied to the text apparently forgets the second overload at 27.7.2.3 [istream.unformatted] p43.
|
|
</p>
|
|
|
|
<p><i>[2013-10-17: Daniel provides concrete wording]</i></p>
|
|
|
|
|
|
<p>
|
|
It seems that the tiny sentence "SIMILARLY for 27.7.1.3/43 (<tt>seekg</tt>)." had been overlooked. I agree that the wording needs to be
|
|
applied here as well.
|
|
</p>
|
|
|
|
<p><i>[2015-05-06 Lenexa: Move to Ready]</i></p>
|
|
|
|
<p>MC: This was just missed when we added "the function first clears eofbit" to the other overload, Daniel agrees. Editing mistake.</p>
|
|
<p>Move to Ready, consensus.</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3691.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 27.7.2.3 [istream.unformatted] p43 as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
basic_istream<charT,traits>& seekg(off_type off, ios_base::seekdir dir);
|
|
</pre><blockquote>
|
|
<p>
|
|
-43- <i>Effects:</i> Behaves as an unformatted input function (as described in 27.7.2.3, paragraph 1), except
|
|
that <ins>the function first clears <tt>eofbit</tt>,</ins> it does not count the number of characters extracted<ins>,</ins>
|
|
and does not affect the value returned by subsequent calls to <tt>gcount()</tt>. […]
|
|
</p>
|
|
</blockquote></blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2245"></a>2245. <tt>packaged_task::reset()</tt> memory allocation</h3>
|
|
<p><b>Section:</b> 30.6.9.1 [futures.task.members] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2013-03-05 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#futures.task.members">issues</a> in [futures.task.members].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
The effects of <tt>packaged_task::reset()</tt> result in memory allocation, but
|
|
don't allow a user to provide an allocator.
|
|
<p/>
|
|
<tt>packaged_task::reset()</tt> needs to be overloaded like so:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
template<class Alloc>
|
|
void reset(const Alloc&);
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
Alternatively, the effects of <tt>reset()</tt> need to require the same allocator is used
|
|
as at construction, which would require the constructor to store the allocator for later use.
|
|
<p/>
|
|
I like to remark that GCC at the moment uses the second option, i.e. the allocator passed to the constructor
|
|
(if any) is used to create the new shared state, because this didn't require any change to the
|
|
interface.
|
|
</p>
|
|
|
|
<p><i>[2015-02 Cologne]</i></p>
|
|
|
|
<p>
|
|
Handed over to SG1.
|
|
</p>
|
|
|
|
<p><i>[2015-05 Lenexa, SG1 response]</i></p>
|
|
|
|
<p>
|
|
No strong opinions in SG1, and this is really an LWG issue. Back to you.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2248"></a>2248. <tt>numeric_limits::is_iec559</tt> misnamed</h3>
|
|
<p><b>Section:</b> 18.3.2 [limits] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Pete Becker <b>Opened:</b> 2013-03-08 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#limits">issues</a> in [limits].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
This member should probably be named "is_ieee754". Or at least the standard should explain that IEC-559 no longer exists,
|
|
and that it's been superseded by IEEE-754.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2250"></a>2250. Follow-up On Library Issue 2207</h3>
|
|
<p><b>Section:</b> 20.6.1 [bitset.cons], 20.6.2 [bitset.members], 21.4.2 [string.cons], 21.4.6 [string.modifiers], 21.4.7 [string.ops] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Frank Birbacher <b>Opened:</b> 2013-04-18 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#bitset.cons">issues</a> in [bitset.cons].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
Similar to LWG <a href="lwg-defects.html#2207">2207</a> there are several other places where the "Requires" clause precludes the "Throws" condition.
|
|
Searching for the <tt>out_of_range</tt> exception to be thrown, the following have been found (based on the working draft
|
|
N3485):
|
|
</p>
|
|
|
|
<ol>
|
|
<li><p>20.6.1 [bitset.cons] p3+4</p></li>
|
|
<li><p>20.6.2 [bitset.members] p13+14 (<tt>set</tt>)</p></li>
|
|
<li><p>20.6.2 [bitset.members] p19+20 (<tt>reset</tt>)</p></li>
|
|
<li><p>20.6.2 [bitset.members] p27+28 (<tt>flip</tt>)</p></li>
|
|
<li><p>20.6.2 [bitset.members] p41+42 (<tt>test</tt>)</p></li>
|
|
<li><p>21.4.2 [string.cons] p3+4</p></li>
|
|
<li><p>21.4.6.2 [string::append] p3+4</p></li>
|
|
<li><p>21.4.6.3 [string::assign] p4+5</p></li>
|
|
<li><p>21.4.6.4 [string::insert] p1+2, p5+6, p9+10 (partially)</p></li>
|
|
<li><p>21.4.6.5 [string::erase] p1+2</p></li>
|
|
<li><p>21.4.6.6 [string::replace] p1+2, p5+6, p9+10 (partially)</p></li>
|
|
<li><p>21.4.6.7 [string::copy] p1+2</p></li>
|
|
<li><p>21.4.7.8 [string::substr] p1+2</p></li>
|
|
</ol>
|
|
|
|
<p><i>[2013-10-15: Daniel provides wording]</i></p>
|
|
|
|
|
|
<p>
|
|
In addition to the examples mentioned in the discussion, a similar defect exists for <tt>thread</tt>'s <tt>join()</tt>
|
|
and <tt>detach</tt> functions (see 30.3.1.5 [thread.thread.member]). The suggested wording applies a similar fix for these
|
|
as well.
|
|
</p>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
STL : likes it<br/>
|
|
DK : does it change behavior?<br/>
|
|
Multiple : no<br/>
|
|
Move to ready? Unanimous
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Modify 20.6.1 [bitset.cons] as indicated: <em>[Editorial comment: The wording form used to ammend the
|
|
<i>Throws</i> element is borrowed from a similar style used in 21.4.6.6 [string::replace] p10]</em></p>
|
|
|
|
<blockquote><pre>
|
|
template <class charT, class traits, class Allocator>
|
|
explicit
|
|
bitset(const basic_string<charT, traits, Allocator>& str,
|
|
typename basic_string<charT, traits, Allocator>::size_type pos = 0,
|
|
typename basic_string<charT, traits, Allocator>::size_type n =
|
|
basic_string<charT, traits, Allocator>::npos,
|
|
charT zero = charT('0'), charT one = charT('1'));
|
|
</pre><blockquote>
|
|
<p>
|
|
<del>-3- <i>Requires:</i> <tt>pos <= str.size()</tt>.</del>
|
|
<p/>
|
|
-4- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos > str.size()</tt> <ins>or <tt>invalid_argument</tt> if an
|
|
invalid character is found (see below)</ins>.
|
|
<p/>
|
|
-5- <i>Effects:</i> Determines the effective length <tt>rlen</tt> of the initializing string as the smaller of <tt>n</tt> and
|
|
<tt>str.size() - pos</tt>.
|
|
<p/>
|
|
The function then throws <tt>invalid_argument</tt> if any of the <tt>rlen</tt> characters in <tt>str</tt> beginning at position
|
|
<tt>pos</tt> is other than <tt>zero</tt> or <tt>one</tt>. The function uses <tt>traits::eq()</tt> to compare the character values.
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
</blockquote></blockquote>
|
|
</li>
|
|
|
|
<li><p>Modify 20.6.2 [bitset.members] as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
bitset<N>& set(size_t pos, bool val = true);
|
|
</pre><blockquote>
|
|
<p>
|
|
<del>-13- <i>Requires:</i> <tt>pos</tt> is valid</del>
|
|
<p/>
|
|
-14- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos</tt> does not correspond to a valid bit position.
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
</blockquote></blockquote>
|
|
|
|
<blockquote><pre>
|
|
bitset<N>& reset(size_t pos);
|
|
</pre><blockquote>
|
|
<p>
|
|
<del>-19- <i>Requires:</i> <tt>pos</tt> is valid</del>
|
|
<p/>
|
|
-20- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos</tt> does not correspond to a valid bit position.
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
</blockquote></blockquote>
|
|
|
|
<blockquote><pre>
|
|
bitset<N>& flip(size_t pos);
|
|
</pre><blockquote>
|
|
<p>
|
|
<del>-27- <i>Requires:</i> <tt>pos</tt> is valid</del>
|
|
<p/>
|
|
-28- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos</tt> does not correspond to a valid bit position.
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
</blockquote></blockquote>
|
|
|
|
<blockquote><pre>
|
|
bool test(size_t pos) const;
|
|
</pre><blockquote>
|
|
<p>
|
|
<del>-41- <i>Requires:</i> <tt>pos</tt> is valid</del>
|
|
<p/>
|
|
-42- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos</tt> does not correspond to a valid bit position.
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
</blockquote></blockquote>
|
|
|
|
</li>
|
|
|
|
<li><p>Modify 21.4.2 [string.cons] as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
basic_string(const basic_string& str,
|
|
size_type pos, size_type n = npos,
|
|
const Allocator& a = Allocator());
|
|
</pre><blockquote>
|
|
<p>
|
|
<del>-3- <i>Requires:</i> <tt>pos <= str.size()</tt></del>
|
|
<p/>
|
|
-4- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos > str.size()</tt>.
|
|
</p>
|
|
</blockquote></blockquote>
|
|
</li>
|
|
|
|
<li><p>Modify 21.4.4 [string.capacity] as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
void resize(size_type n, charT c);
|
|
</pre><blockquote>
|
|
<p>
|
|
<del>-6- <i>Requires:</i> <tt>n <= max_size()</tt></del>
|
|
<p/>
|
|
-7- <i>Throws:</i> <tt>length_error</tt> if <tt>n > max_size()</tt>.
|
|
</p>
|
|
</blockquote></blockquote>
|
|
</li>
|
|
|
|
<li><p>Modify 21.4.6.2 [string::append] as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
basic_string&
|
|
append(const basic_string& str, size_type pos, size_type n = npos);
|
|
</pre><blockquote>
|
|
<p>
|
|
<del>-3- <i>Requires:</i> <tt>pos <= str.size()</tt></del>
|
|
<p/>
|
|
-4- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos > str.size()</tt>.
|
|
</p>
|
|
</blockquote></blockquote>
|
|
</li>
|
|
|
|
<li><p>Modify 21.4.6.3 [string::assign] as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
basic_string&
|
|
assign(const basic_string& str, size_type pos,
|
|
size_type n = npos);
|
|
</pre><blockquote>
|
|
<p>
|
|
<del>-5- <i>Requires:</i> <tt>pos <= str.size()</tt></del>
|
|
<p/>
|
|
-6- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos > str.size()</tt>.
|
|
</p>
|
|
</blockquote></blockquote>
|
|
</li>
|
|
|
|
<li><p>Modify 21.4.6.4 [string::insert] as indicated: <em>[Editorial note: The first change suggestion is also a bug fix
|
|
of the current wording, because (a) the function has parameter <tt>pos1</tt> but the semantics refers to <tt>pos</tt> and (b)
|
|
it is possible that this function can throw <tt>length_error</tt>, see p10]</em></p>
|
|
|
|
<blockquote><pre>
|
|
basic_string&
|
|
insert(size_type pos<del>1</del>, const basic_string& str);
|
|
</pre><blockquote>
|
|
<p>
|
|
<del>-1- <i>Requires:</i> <tt>pos <= size()</tt>.</del>
|
|
<p/>
|
|
<del>-2- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos > size()</tt>.</del>
|
|
<p/>
|
|
-3- <i>Effects:</i> <del>Calls</del><ins>Equivalent to:</ins> <tt><ins>return</ins> insert(pos, str.data(), str.size())<ins>;</ins></tt><del>.</del>
|
|
<p/>
|
|
<del>-4- <i>Returns:</i> <tt>*this</tt>.</del>
|
|
</p>
|
|
</blockquote></blockquote>
|
|
|
|
<blockquote><pre>
|
|
basic_string&
|
|
insert(size_type pos1, const basic_string& str,
|
|
size_type pos2, size_type n = npos);
|
|
</pre><blockquote>
|
|
<p>
|
|
<del>-5- <i>Requires:</i> <tt>pos1 <= size()</tt> and <tt>pos2 <= str.size()</tt>.</del>
|
|
<p/>
|
|
-6- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos1 > size()</tt> or <tt>pos2 > str.size()</tt>.
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
</blockquote></blockquote>
|
|
|
|
<blockquote><pre>
|
|
basic_string&
|
|
insert(size_type pos, const charT* s, size_type n);
|
|
</pre><blockquote>
|
|
<p>
|
|
-9- <i>Requires:</i> <tt>s</tt> points to an array of at least <tt>n</tt> elements of <tt>charT</tt> <del>and
|
|
<tt>pos <= size()</tt></del>.
|
|
<p/>
|
|
-10- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos > size()</tt> or <tt>length_error</tt> if <tt>size() + n > max_size()</tt>.
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
</blockquote></blockquote>
|
|
|
|
<blockquote><pre>
|
|
basic_string&
|
|
insert(size_type pos, const charT* s);
|
|
</pre><blockquote>
|
|
<p>
|
|
-13- <i>Requires:</i> <del><tt>pos <= size()</tt> and</del> <tt>s</tt> points to an array of at least
|
|
<tt>traits::length(s) + 1</tt> elements of <tt>charT</tt>.
|
|
<p/>
|
|
-14- <i>Effects:</i> Equivalent to <tt><ins>return</ins> insert(pos, s, traits::length(s))<ins>;</ins></tt><del>.</del>
|
|
<p/>
|
|
<del>-15- <i>Returns:</i> <tt>*this</tt>.</del>
|
|
</p>
|
|
</blockquote></blockquote>
|
|
</li>
|
|
|
|
<li><p>Modify 21.4.6.5 [string::erase] as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
basic_string& erase(size_type pos = 0, size_type n = npos);
|
|
</pre><blockquote>
|
|
<p>
|
|
<del>-1- <i>Requires:</i> <tt>pos <= size()</tt></del>
|
|
<p/>
|
|
-2- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos > size()</tt>.
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
</blockquote></blockquote>
|
|
</li>
|
|
|
|
<li><p>Modify 21.4.6.6 [string::replace] as indicated: <em>[Editorial note: The first change suggestion is also a bug fix
|
|
of the current wording, because it is possible that this function can throw <tt>length_error</tt>, see p10]</em></p>
|
|
|
|
<blockquote><pre>
|
|
basic_string&
|
|
replace(size_type pos1, size_type n1,
|
|
const basic_string& str);
|
|
</pre><blockquote>
|
|
<p>
|
|
<del>-1- <i>Requires:</i> <tt>pos1 <= size()</tt>.</del>
|
|
<p/>
|
|
<del>-2- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos1 > size()</tt>.</del>
|
|
<p/>
|
|
-3- <i>Effects:</i> <del>Calls</del><ins>Equivalent to</ins> <tt><ins>return</ins> replace(pos1, n1, str.data(), str.size())<ins>;</ins></tt><del>.</del>
|
|
<p/>
|
|
<del>-4- <i>Returns:</i> <tt>*this</tt>.</del>
|
|
</p>
|
|
</blockquote></blockquote>
|
|
|
|
<blockquote><pre>
|
|
basic_string&
|
|
replace(size_type pos1, size_type n1,
|
|
const basic_string& str,
|
|
size_type pos2, size_type n = npos);
|
|
</pre><blockquote>
|
|
<p>
|
|
<del>-5- <i>Requires:</i> <tt>pos1 <= size()</tt> and <tt>pos2 <= str.size()</tt>.</del>
|
|
<p/>
|
|
-6- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos1 > size()</tt> or <tt>pos2 > str.size()</tt>.
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
</blockquote></blockquote>
|
|
|
|
<blockquote><pre>
|
|
basic_string&
|
|
replace(size_type pos1, size_type n1, const charT* s, size_type n2);
|
|
</pre><blockquote>
|
|
<p>
|
|
-9- <i>Requires:</i> <del><tt>pos1 <= size()</tt> and</del> <tt>s</tt> points to an array of at least <tt>n2</tt> elements
|
|
of <tt>charT</tt>.
|
|
<p/>
|
|
-10- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos1 > size()</tt> or <tt>length_error</tt> if the length of the resulting
|
|
string would exceed <tt>max_size()</tt> (see below).
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
</blockquote></blockquote>
|
|
|
|
<blockquote><pre>
|
|
basic_string&
|
|
replace(size_type pos, size_type n, const charT* s);
|
|
</pre><blockquote>
|
|
<p>
|
|
-13- <i>Requires:</i> <del><tt>pos <= size()</tt> and</del> <tt>s</tt> points to an array of at least
|
|
<tt>traits::length(s) + 1</tt> elements of <tt>charT</tt>.
|
|
<p/>
|
|
-14- <i>Effects:</i> Equivalent to <tt><ins>return</ins> replace(pos, n, s, traits::length(s))<ins>;</ins></tt><del>.</del>
|
|
<p/>
|
|
<del>-15- <i>Returns:</i> <tt>*this</tt>.</del>
|
|
</p>
|
|
</blockquote></blockquote>
|
|
|
|
</li>
|
|
|
|
<li><p>Modify 21.4.6.7 [string::copy] as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
size_type copy(charT* s, size_type n, size_type pos = 0) const;
|
|
</pre><blockquote>
|
|
<p>
|
|
<del>-1- <i>Requires:</i> <tt>pos <= size()</tt></del>
|
|
<p/>
|
|
-2- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos > size()</tt>.
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
</blockquote></blockquote>
|
|
</li>
|
|
|
|
<li><p>Modify 21.4.7.8 [string::substr] as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
basic_string substr(size_type pos = 0, size_type n = npos) const;
|
|
</pre><blockquote>
|
|
<p>
|
|
<del>-1- <i>Requires:</i> <tt>pos <= size()</tt></del>
|
|
<p/>
|
|
-2- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos > size()</tt>.
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
</blockquote></blockquote>
|
|
</li>
|
|
|
|
<li><p>Modify 30.3.1.5 [thread.thread.member] as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
void join();
|
|
</pre><blockquote>
|
|
<p>
|
|
<del>-3- <i>Requires:</i> <tt>joinable()</tt> is true.</del>
|
|
<p/>
|
|
[…]
|
|
<p/>
|
|
-7- <i>Throws:</i> <tt>system_error</tt> when an exception is required (30.2.2).
|
|
<p/>
|
|
-8- <i>Error conditions:</i>
|
|
</p>
|
|
<ul>
|
|
<li><p>[…]</p></li>
|
|
<li><p><tt>invalid_argument</tt> — if the thread is not joinable.</p></li>
|
|
</ul>
|
|
</blockquote></blockquote>
|
|
|
|
<blockquote><pre>
|
|
void detach();
|
|
</pre><blockquote>
|
|
<p>
|
|
<del>-9- <i>Requires:</i> <tt>joinable()</tt> is true.</del>
|
|
<p/>
|
|
[…]
|
|
<p/>
|
|
-12- <i>Throws:</i> <tt>system_error</tt> when an exception is required (30.2.2).
|
|
<p/>
|
|
-13- <i>Error conditions:</i>
|
|
</p>
|
|
<ul>
|
|
<li><p>[…]</p></li>
|
|
<li><p><tt>invalid_argument</tt> — if the thread is not joinable.</p></li>
|
|
</ul>
|
|
</blockquote></blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2253"></a>2253. [arrays.ts] <tt>dynarray</tt> should state which container requirements aren't met</h3>
|
|
<p><b>Section:</b> X [dynarray.overview] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2013-04-23 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p><b>Addresses: arrays.ts</b></p>
|
|
|
|
<p>
|
|
X [dynarray.overview] p2 says:
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
"Unless otherwise specified, all <tt>dynarray</tt> operations have the same requirements and semantics as specified in
|
|
23.2 [container.requirements]."
|
|
</p>
|
|
</blockquote>
|
|
<p>
|
|
Some differences from 23.2 [container.requirements] are not explicitly specified, including at
|
|
least the lack of a default constructor, copy assignment and <tt>swap</tt> member.
|
|
<p/>
|
|
The wording could be similar to 23.3.2.1 [array.overview] which says "An array satisfies all of the requirements
|
|
of a container and of a reversible container (23.2 [container.requirements]), except that a default constructed
|
|
array object is not empty and that <tt>swap</tt> does not have constant complexity."
|
|
</p>
|
|
|
|
<p><i>[2013-09 Chicago:]</i></p>
|
|
|
|
<p>
|
|
Move to Deferred. This feature will ship after C++14 and should be revisited then.
|
|
</p>
|
|
|
|
<p><i>[2014-06-06 pre-Rapperswil]</i></p>
|
|
|
|
<p>
|
|
This issue has been reopened as arrays-ts.
|
|
</p>
|
|
|
|
<p><i>[2014-06-16 Rapperswil]</i></p>
|
|
|
|
<p>
|
|
Move to Ready
|
|
</p>
|
|
|
|
<p><i>[2014/11 Urbana]</i></p>
|
|
|
|
<p>
|
|
Held at Ready status, pending clarification of Arrays TS
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<ol>
|
|
<li><p>Add to X [dynarray.overview] p2:</p>
|
|
<p>
|
|
-2- <ins>A <tt>dynarray</tt> satisfies all of the requirements of a container and of a reversible container
|
|
(23.2 [container.requirements]), except for default construction, assignment and <tt>swap</tt>.</ins> Unless
|
|
otherwise specified, all <tt>dynarray</tt> operations have the same requirements and semantics as specified in
|
|
23.2 [container.requirements].
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2254"></a>2254. [arrays.ts] Is <tt>dynarray</tt> an allocator-aware container?</h3>
|
|
<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2013-04-23 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p><b>Addresses: arrays.ts</b></p>
|
|
|
|
<p>
|
|
23.2.1 [container.requirements.general] p3 says:
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
"All of the containers defined in this Clause and in (21.4) except <tt>array</tt> meet the additional requirements
|
|
of an allocator-aware container, as described in Table 99."
|
|
</p>
|
|
</blockquote>
|
|
<p>
|
|
Is this true of <tt>dynarray</tt>? I believe the answer must be no because <tt>dynarray</tt> has no <tt>allocator_type</tt>,
|
|
and morally should be no, so that operations are defined in terms of <tt>std::allocator<T></tt>, which p13 says
|
|
doesn't actually need to be used (which allows the elements to be default-initialized as is intended, rather than
|
|
"default-inserted into the container" using an allocator.)
|
|
<p/>
|
|
The requirement that "each element is constructed with uses-allocator construction" provides roughly equivalent behaviour
|
|
to the "<em>CopyInsertable into <tt>X</tt></em>" requirements for allocator-aware containers, allowing an allocator to
|
|
control construction of the <tt>dynarray</tt> elements.
|
|
</p>
|
|
|
|
<p><i>[2013-09 Chicago]</i></p>
|
|
|
|
<p>
|
|
Move to Deferred. This feature will ship after C++14 and should be revisited then.
|
|
</p>
|
|
|
|
<p><i>[2014-06-06 pre-Rapperswill]</i></p>
|
|
|
|
<p>
|
|
This issue has been reopened as arrays-ts.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<ol>
|
|
<li><p>Change to 23.2.1 [container.requirements.general] p13:</p>
|
|
<p>
|
|
-13- All of the containers defined in this Clause and in (21.4) except <tt>array</tt> <ins>and <tt>dynarray</tt></ins>
|
|
meet the additional requirements of an allocator-aware container, as described in Table 99.
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2255"></a>2255. [arrays.ts] <tt>dynarray</tt> constructor ambiguity</h3>
|
|
<p><b>Section:</b> X [dynarray.cons] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2013-04-23 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p><b>Addresses: arrays.ts</b></p>
|
|
|
|
<p>
|
|
These constructors can interact badly::
|
|
</p>
|
|
<blockquote><pre>
|
|
template<class Alloc>
|
|
dynarray(size_type c, const Alloc& alloc);
|
|
dynarray(size_type c, const T& v);
|
|
</pre></blockquote>
|
|
<p>
|
|
Unless the second argument is a value of exactly the type <tt>T</tt> you will get the first constructor, i.e.
|
|
all of these will fail to compile:
|
|
</p>
|
|
<blockquote><pre>
|
|
dynarray<long> dlong(1, 1); // 1 is not long
|
|
dynarray<float> dflt(1, 1.0); // 1.0 is not float
|
|
dynarray<int*> dptr(1, nullptr); // nullptr is not int*
|
|
dynarray<void*> doh(1, 0); // 0 is not void*
|
|
</pre></blockquote>
|
|
<p>
|
|
The <tt>nullptr</tt> case is particularly annoying, a user trying to do the right thing by saying <tt>nullptr</tt>
|
|
instead of <tt>NULL</tt> still gets the wrong result.
|
|
<p/>
|
|
The constructor taking an allocator requires that "<tt>Alloc</tt> shall meet the requirements for an Allocator"
|
|
but doesn't actually say "shall not participate in overload resolution unless ..."
|
|
<p/>
|
|
I believe we have no precedent for using SFINAE to check "the requirements for an Allocator" because it's
|
|
a pretty complicated set of requirements. We could say it shall not participate in overload resolution if <tt>Alloc</tt>
|
|
is implicitly convertible to <tt>value_type</tt>.
|
|
<p/>
|
|
Alternatively, we could follow the same approach used by other types that can be constructed with an unconstrained
|
|
allocator type and use <tt>std::allocator_arg_t</tt> as the first argument instead of adding an allocator after the
|
|
other arguments.
|
|
</p>
|
|
|
|
<p><i>[2013-09 Chicago:]</i></p>
|
|
|
|
<p>
|
|
Move to Deferred. This feature will ship after C++14 and should be revisited then.
|
|
</p>
|
|
|
|
<p><i>[2014-06-06 pre-Rapperswil]</i></p>
|
|
|
|
<p>
|
|
This issue has been reopened as arrays-ts.
|
|
</p>
|
|
|
|
<p><i>[2014-06-16 Rapperswil]</i></p>
|
|
|
|
<p>
|
|
Move to Ready for alternative A
|
|
</p>
|
|
|
|
<strong>Previous resolution [SUPERSEDED]:</strong>
|
|
<p/>
|
|
<blockquote class="note">
|
|
<ol style="list-style-type:upper-alpha">
|
|
<li>
|
|
<p>
|
|
<em>Either</em> use the correct way to unambiguously call a constructor taking any type of allocator, i.e. change the
|
|
constructors to take <tt>dynarray(std::allocator_arg_t, const Alloc&, ...)</tt> by modifying both the synopsis
|
|
X [dynarray.overview] p2 and X [dynarray.cons] before p9 like so:</p>
|
|
|
|
<blockquote><pre>
|
|
template <class Alloc>
|
|
dynarray(<ins>allocator_arg_t, const Alloc& a, </ins>size_type c<del>, const Alloc& alloc</del>);
|
|
template <class Alloc>
|
|
dynarray(<ins>allocator_arg_t, const Alloc& a, </ins>size_type c, const T& v<del>, const Alloc& alloc</del>);
|
|
template <class Alloc>
|
|
dynarray(<ins>allocator_arg_t, const Alloc& a, </ins>const dynarray& d<del>, const Alloc& alloc</del>);
|
|
template <class Alloc>
|
|
dynarray(<ins>allocator_arg_t, const Alloc& a, </ins>initializer_list<T><del>, const Alloc& alloc</del>);
|
|
</pre></blockquote>
|
|
|
|
</li>
|
|
|
|
<li><p><em>or</em> constrain the problematic constructor by adding a new paragraph to X [dynarray.cons]:</p>
|
|
<blockquote><pre>
|
|
template <class Alloc>
|
|
dynarray(size_type c, const Alloc& alloc);
|
|
template <class Alloc>
|
|
dynarray(size_type c, const T& v, const Alloc& alloc);
|
|
template <class Alloc>
|
|
dynarray(const dynarray& d, const Alloc& alloc);
|
|
template <class Alloc>
|
|
dynarray(initializer_list<T>, const Alloc& alloc);
|
|
</pre><blockquote>
|
|
<p>
|
|
-9- <i>Requires</i>: <tt>Alloc</tt> shall meet the requirements for an Allocator (17.6.3.5 [allocator.requirements]).
|
|
<p/>
|
|
-10- <i>Effects</i>: Equivalent to the preceding constructors except that each element is constructed with uses-allocator
|
|
construction (20.7.7.2 [allocator.uses.construction]).
|
|
<p/>
|
|
<ins>-?- <i>Remarks</i>: The first constructor shall not participate in overload resolution unless <tt>Alloc</tt> is not
|
|
implicitly convertible to <tt>T</tt>.</ins>
|
|
</p>
|
|
</blockquote></blockquote>
|
|
</li>
|
|
</ol>
|
|
</blockquote>
|
|
|
|
<p><i>[2014/11 Urbana]</i></p>
|
|
|
|
<p>
|
|
Held at Ready status, pending clarification of Arrays TS
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>
|
|
Use the correct way to unambiguously call a constructor taking any type of allocator, i.e. change the
|
|
constructors to take <tt>dynarray(std::allocator_arg_t, const Alloc&, ...)</tt> by modifying both the synopsis
|
|
X [dynarray.overview] p2 and X [dynarray.cons] before p9 like so:</p>
|
|
|
|
<blockquote><pre>
|
|
template <class Alloc>
|
|
dynarray(<ins>allocator_arg_t, const Alloc& a, </ins>size_type c<del>, const Alloc& alloc</del>);
|
|
template <class Alloc>
|
|
dynarray(<ins>allocator_arg_t, const Alloc& a, </ins>size_type c, const T& v<del>, const Alloc& alloc</del>);
|
|
template <class Alloc>
|
|
dynarray(<ins>allocator_arg_t, const Alloc& a, </ins>const dynarray& d<del>, const Alloc& alloc</del>);
|
|
template <class Alloc>
|
|
dynarray(<ins>allocator_arg_t, const Alloc& a, </ins>initializer_list<T><del>, const Alloc& alloc</del>);
|
|
</pre></blockquote>
|
|
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2256"></a>2256. On <tt>vector</tt> iterator invalidation</h3>
|
|
<p><b>Section:</b> 23.3.6.5 [vector.modifiers] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2013-04-29 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#vector.modifiers">active issues</a> in [vector.modifiers].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#vector.modifiers">issues</a> in [vector.modifiers].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
|
|
<p>
|
|
23.3.6.5 [vector.modifiers]/p3 says:
|
|
</p>
|
|
<blockquote><pre>
|
|
iterator erase(const_iterator position);
|
|
iterator erase(const_iterator first, const_iterator last);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
<i>Effects</i>: Invalidates iterators and references at or after the point of the erase.
|
|
</p>
|
|
</blockquote></blockquote>
|
|
<p>
|
|
Consider this example:
|
|
</p>
|
|
<blockquote><pre>
|
|
#include <vector>
|
|
#include <cassert>
|
|
|
|
int main()
|
|
{
|
|
typedef std::vector<int> C;
|
|
C c = {1, 2, 3, 4};
|
|
C::iterator i = c.begin() + 1;
|
|
C::iterator j = c.end() - 1;
|
|
assert(*i == 2);
|
|
assert(*j == 4);
|
|
c.erase(c.begin());
|
|
<span style="color:#C80000;font-weight:bold">assert(*i == 3); // Why is this not perfectly fine?!</span>
|
|
}
|
|
</pre></blockquote>
|
|
<p>
|
|
Why has the iterator <tt>i</tt> been invalidated? It still refers to a perfectly reasonable, fully constructed object.
|
|
If <tt>vector::iterator</tt> were to be implemented as a pointer (which is legal), it is not possible for that last
|
|
line to do anything but run fine.
|
|
<p/>
|
|
The iterator <tt>j</tt> on the other hand now points at end, and any iterators that may now point beyond <tt>end()</tt>,
|
|
into uninitialized memory, are clearly invalid.
|
|
<p/>
|
|
But why do we say that an iterator that <em>must</em> point to a valid object is invalid? This looks to me like we
|
|
simply got sloppy in our specification.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2259"></a>2259. Issues in 17.6.5.5 rules for member functions</h3>
|
|
<p><b>Section:</b> 17.6.5.5 [member.functions] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Richard Smith <b>Opened:</b> 2013-05-12 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#member.functions">issues</a> in [member.functions].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
17.6.5.5 [member.functions] p2 says:
|
|
</p>
|
|
|
|
<blockquote><p>
|
|
"An implementation may declare additional non-virtual member function signatures within a class:
|
|
</p>
|
|
<ul>
|
|
<p>by adding arguments with default values to a member function signature; [Footnote: Hence, the address of a member
|
|
function of a class in the C++ standard library has an unspecified type.] [<i>Note</i>: An implementation
|
|
may not add arguments with default values to virtual, global, or non-member functions. — <i>end note</i>]</p>
|
|
<p>by replacing a member function signature with default values by two or more member function signatures
|
|
with equivalent behavior; and</p>
|
|
<p>by adding a member function signature for a member function name."</p>
|
|
</ul>
|
|
</blockquote>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>
|
|
This wording is not using the correct terminology. "by adding arguments with default values" presumably means
|
|
"by adding parameters with default arguments", and likewise throughout.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
This paragraph only allows an implementation to declare "additional" signatures, but the first bullet is talking
|
|
about replacing a standard signature with one with additional parameters.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
None of these bullets allows a member function with no <i>ref</i>-qualifier to be replaced by signatures with <i>ref</i>-qualifiers
|
|
(a situation which was just discussed on std-proposals), and likewise for <i>cv</i>-qualifiers. Presumably that is
|
|
not intentional, and such changes should be permissible.
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>
|
|
I think the first two items are probably editorial, since the intent is clear.
|
|
</p>
|
|
|
|
<p><i>[2013-12-11 Richard provides concrete wording]</i></p>
|
|
|
|
<p>
|
|
</p>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
JW: I don't like that this loses the footnote about the address of member functions having an unspecified type,
|
|
the footnote is good to be able to point to as an explicit clarification of one consequence of the normative wording.<br/>
|
|
MC: so we want to keep the footnote<br/>
|
|
STL: doesn't need to be a footnote, can be an inline Note<br/>
|
|
JW: does this have any impact on our ability to add totally different functions with unrelated names, not described in
|
|
the standard?<br/>
|
|
MC: no, the old wording didn't refer to such functions anyway<br/>
|
|
Move to Ready and include in motion on Friday?<br/>
|
|
9 in favor, 0 opposed, 2 abstention
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3797.</p>
|
|
|
|
<ol>
|
|
<li><p>Merge 17.6.5.5 [member.functions]p2+3 as indicated:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-2- <del>An implementation may declare additional non-virtual member function signatures within a class:</del>
|
|
</p>
|
|
<ul>
|
|
<li><p>
|
|
<del>by adding arguments with default values to a member function signature;188 [<i>Note:</i> An implementation
|
|
may not add arguments with default values to virtual, global, or non-member functions. — <i>end note</i>]</del>
|
|
</p></li>
|
|
<li><p>
|
|
<del>by replacing a member function signature with default values by two or more member function signatures
|
|
with equivalent behavior; and</del>
|
|
</p></li>
|
|
<li><p>
|
|
<del>by adding a member function signature for a member function name.</del>
|
|
</p></li>
|
|
</ul>
|
|
<p>
|
|
<del>-3- A call to a member function signature described in the C++ standard library behaves as if the implementation
|
|
declares no additional member function signatures.[Footnote: A valid C++ program always calls the expected library
|
|
member function, or one with equivalent behavior. An implementation may also define additional member functions
|
|
that would otherwise not be called by a valid C++ program.]</del> <ins>For a non-virtual member function described
|
|
in the C++ standard library, an implementation may declare a different set of member function signatures, provided
|
|
that any call to the member function that would select an overload from the set of declarations described in this
|
|
standard behaves as if that overload were selected. [<i>Note:</i> For instance, an implementation may add parameters
|
|
with default values, or replace a member function with default arguments with two or more member functions with
|
|
equivalent behavior, or add additional signatures for a member function name. — <i>end note</i>]</ins>
|
|
</p>
|
|
|
|
</blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2260"></a>2260. Missing requirement for <tt>Allocator::pointer</tt></h3>
|
|
<p><b>Section:</b> 17.6.3.5 [allocator.requirements] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2013-05-14 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
For an allocator <tt>A<T></tt> which defines <tt>A<T>::pointer</tt> to a class type,
|
|
i.e. not <tt>T*</tt>, I see no requirement that <tt>A<T>::pointer</tt> is convertible to
|
|
<tt>A<U>::pointer</tt>, even if <tt>T*</tt> is convertible to <tt>U*</tt>. Such conversions are
|
|
needed in containers to convert from e.g. <tt>ListNodeBase*</tt> to <tt>ListNode<T>*</tt>.
|
|
</p>
|
|
|
|
<p>The obvious way to do such conversions appears to be
|
|
<tt>pointer_traits::pointer_to()</tt>, but that's ill-formed if the static
|
|
member function <tt>A<T>::pointer::pointer_to()</tt> doesn't exist and the
|
|
allocator requirements don't mention that function, so you need to
|
|
cast <tt>A<T>::pointer</tt> to <tt>A<T>::void_pointer</tt> then cast that to
|
|
<tt>A<U>::pointer</tt>.
|
|
</p>
|
|
|
|
<p>
|
|
Is converting via <tt>void_pointer</tt> really intended, or are we missing a requirement that
|
|
<tt>pointer_traits<A<T>::pointer>::pointer_to()</tt> be well-formed?
|
|
</p>
|
|
|
|
<p>Proposed resolution:</p>
|
|
|
|
<p>Add to the Allocator requirements table the following requirement:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
The expression <tt>pointer_traits<XX::pointer>::pointer_to(r)</tt> is well-defined.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p><i>[2013-09 Chicago]</i></p>
|
|
|
|
<p>
|
|
Pablo to come back with Proposed Wording
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<ol>
|
|
<li><p>
|
|
Edit Table 28 as indicated:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 28 — Allocator requirements (continued)</caption>
|
|
<tr>
|
|
<th>Expression</th>
|
|
<th>Return type</th>
|
|
<th>Assertion/note pre-/post-condition</th>
|
|
<th>Default</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="4" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>static_cast<X::const_pointer>(z)</tt>
|
|
</td>
|
|
<td>
|
|
<tt>X::const_pointer</tt>
|
|
</td>
|
|
<td>
|
|
<tt>static_cast<X::const_pointer>(z) == q</tt>
|
|
</td>
|
|
<td>
|
|
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<ins><tt>pointer_traits<X::pointer>::pointer_to(r)</tt></ins>
|
|
</td>
|
|
<td>
|
|
<ins><tt>X::pointer</tt></ins>
|
|
</td>
|
|
<td>
|
|
|
|
</td>
|
|
<td>
|
|
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="4" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote>
|
|
|
|
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2261"></a>2261. Are containers required to use their '<tt>pointer</tt>' type internally?</h3>
|
|
<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2013-05-14 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Is a container <tt>C</tt> only supposed to refer to allocated memory (blocks of
|
|
contiguous storage, nodes, etc.) through objects of type <tt>C::pointer</tt>
|
|
rather than <tt>C::value_type*</tt>?
|
|
</p>
|
|
|
|
<p>
|
|
I don't see anything explicitly requiring this, so a container could
|
|
immediately convert the result of <tt>get_allocator().allocate(1)</tt> to a
|
|
built-in pointer of type <tt>value_type*</tt> and only deal with the built-in
|
|
pointer until it needs to deallocate it again, but that removes most
|
|
of the benefit of allowing allocators to use custom pointer types.
|
|
</p>
|
|
|
|
<p><i>[2014-06-12, Jonathan comments]</i></p>
|
|
|
|
<p>
|
|
This issue is basically the same issue as LWG <a href="lwg-active.html#1521">1521</a>, which agrees it's an issue,
|
|
to be dealt with in the future, so I request that <a href="lwg-active.html#2261">2261</a> not be closed as a dup
|
|
unless we reopen <a href="lwg-active.html#1521">1521</a>.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2262"></a>2262. Requirement for <tt>unique_ptr<T>::get_deleter()(p)</tt> to be able to destroy the <tt>unique_ptr</tt></h3>
|
|
<p><b>Section:</b> 20.8.1.2 [unique.ptr.single] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Rob Desbois <b>Opened:</b> 2013-05-15 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#unique.ptr.single">issues</a> in [unique.ptr.single].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
N3337 20.8.1.2.5 [unique.ptr.single.modifiers] contains 2 non-normative notes stating:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
[para 4]: "The order of these operations is significant because the call to <tt>get_deleter()</tt>
|
|
may destroy <tt>*this</tt>."
|
|
</p>
|
|
<p>
|
|
[para 5]: "The postcondition does not hold if the call to <tt>get_deleter()</tt> destroys <tt>*this</tt> since
|
|
<tt>this->get()</tt> is no longer a valid expression."
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p>
|
|
It seems this wording was created to resolve <a href="lwg-defects.html#998">998</a> due to the possibility that a <tt>unique_ptr</tt> may be
|
|
destroyed through deletion of its stored pointer where that directly or indirectly refers to the same <tt>unique_ptr</tt>.
|
|
If <tt>unique_ptr</tt> is required to support circular references then it seems this must be normative text: an implementation
|
|
is currently allowed to operate on <tt>*this</tt> after the assignment and deletion specified in para 4, since this is only
|
|
'disallowed' by the non-normative note.
|
|
</p>
|
|
|
|
<p>I propose the following draft rewording:</p>
|
|
|
|
<p>
|
|
[para 4]: <i>Effects</i>: assigns <tt>p</tt> to the stored pointer, and then if the old value of the stored pointer, <tt>old_p</tt>, was not
|
|
equal to <tt>nullptr</tt>, calls <tt>get_deleter()(old_p)</tt>. <ins>No operation shall be performed after the call to
|
|
<tt>get_deleter()(old_p)</tt> that requires <tt>*this</tt> to be valid, because the deletion may destroy <tt>*this</tt> if it is
|
|
referred to directly or indirectly by the stored pointer.</ins> <del>[<i>Note:</i> The order of these operations is significant
|
|
because the call to <tt>get_deleter()</tt> may destroy <tt>*this</tt>. — <i>end note</i>]</del>
|
|
<p/>
|
|
[para 5]: <i>Postconditions</i>: <ins>If the call <tt>get_deleter()(old_p)</tt> destroyed <tt>*this</tt>, none. Otherwise,</ins>
|
|
<tt>get() == p</tt>. <del>[<i>Note:</i> The postcondition does not hold if the call to <tt>get_deleter()</tt>
|
|
destroys <tt>*this</tt> since <tt>this->get()</tt> is no longer a valid expression. — <i>end note</i>]</del>
|
|
</p>
|
|
|
|
<p>
|
|
I expect it will also be necessary to amend the requirements for a deleter, so in addition:
|
|
</p>
|
|
|
|
<p>
|
|
20.8.1.2 [unique.ptr.single] [para 1]: The default type for the template parameter <tt>D</tt> is <tt>default_delete</tt>.
|
|
A client-supplied template argument <tt>D</tt> shall be a function object type (20.10), lvalue-reference to function, or
|
|
lvalue-reference to function object type for which, given a value <tt>d</tt> of type <tt>D</tt> and a value <tt>ptr</tt> of type
|
|
<tt>unique_ptr<T, D>::pointer</tt>, the expression <tt>d(ptr)</tt> is valid and has the effect of disposing of the pointer
|
|
as appropriate for that deleter. <ins>Where <tt>D</tt> is not an lvalue reference type, <tt>d(ptr)</tt> shall be valid if <tt>ptr</tt>
|
|
refers directly or indirectly to the invoking <tt>unique_ptr</tt> object.</ins>
|
|
</p>
|
|
|
|
<p><i>[2013-10-05, Stephan T. Lavavej comments and provides alternative wording]</i></p>
|
|
|
|
<p>
|
|
In Chicago, we determined that the original proposed change to 20.8.1.2 [unique.ptr.single]/1 was insufficient, because
|
|
<tt>d</tt> might be a reference to a deleter functor that's destroyed during self-destruction.
|
|
<p/>
|
|
We believed that 20.8.1.2.5 [unique.ptr.single.modifiers]/4 was already sufficiently clear. The Standard occasionally prevents
|
|
implementations of <tt>X</tt> from doing various things, through the principle of "nothing allows <tt>X</tt> to fail in that situation".
|
|
For example, <tt>v.push_back(v[0])</tt> is required to work for non-empty vectors because nothing allows that to fail. In this case,
|
|
the intent to allow self-destruction is already clear.
|
|
<p/>
|
|
Additionally, we did not believe that 20.8.1.2.5 [unique.ptr.single.modifiers]/5 had to be changed. The current note is slightly
|
|
squirrely but it does not lead to confusion for implementers or users.
|
|
</p>
|
|
|
|
<p>
|
|
Previous resolution from Rob Desbois:
|
|
</p>
|
|
<blockquote class="note">
|
|
<ol>
|
|
<li>
|
|
<p>
|
|
Edit 20.8.1.2 [unique.ptr.single] p1 as indicated:
|
|
</p>
|
|
<blockquote><p>
|
|
The default type for the template parameter <tt>D</tt> is <tt>default_delete</tt>.
|
|
A client-supplied template argument <tt>D</tt> shall be a function object type (20.10), lvalue-reference to function, or
|
|
lvalue-reference to function object type for which, given a value <tt>d</tt> of type <tt>D</tt> and a value <tt>ptr</tt> of type
|
|
<tt>unique_ptr<T, D>::pointer</tt>, the expression <tt>d(ptr)</tt> is valid and has the effect of disposing of the pointer
|
|
as appropriate for that deleter. <ins>Where <tt>D</tt> is not an lvalue reference type, <tt>d(ptr)</tt> shall be valid if <tt>ptr</tt>
|
|
refers directly or indirectly to the invoking <tt>unique_ptr</tt> object.</ins>
|
|
</p></blockquote>
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
Edit 20.8.1.2.5 [unique.ptr.single.modifiers] p4+5 as indicated:
|
|
</p>
|
|
<blockquote><pre>
|
|
void reset(pointer p = pointer()) noexcept;
|
|
</pre><blockquote>
|
|
<p>
|
|
-3- <i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well formed, shall have well-defined behavior,
|
|
and shall not throw exceptions.
|
|
<p/>
|
|
-4- <i>Effects:</i> assigns <tt>p</tt> to the stored pointer, and then if the old value of the stored pointer, <tt>old_p</tt>, was not
|
|
equal to <tt>nullptr</tt>, calls <tt>get_deleter()(old_p)</tt>. <ins>No operation shall be performed after the call to
|
|
<tt>get_deleter()(old_p)</tt> that requires <tt>*this</tt> to be valid, because the deletion may destroy <tt>*this</tt> if it is
|
|
referred to directly or indirectly by the stored pointer.</ins> <del>[<i>Note:</i> The order of these operations is significant
|
|
because the call to <tt>get_deleter()</tt> may destroy <tt>*this</tt>. — <i>end note</i>]</del>
|
|
<p/>
|
|
-5- <i>Postconditions:</i> <ins>If the call <tt>get_deleter()(old_p)</tt> destroyed <tt>*this</tt>, none. Otherwise,</ins>
|
|
<tt>get() == p</tt>. <del>[<i>Note:</i> The postcondition does not hold if the call to <tt>get_deleter()</tt>
|
|
destroys <tt>*this</tt> since <tt>this->get()</tt> is no longer a valid expression. — <i>end note</i>]</del>
|
|
</p>
|
|
</blockquote></blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
</blockquote>
|
|
|
|
<p>
|
|
<strong>Previous resolution [SUPERSEDED]:</strong>
|
|
</p>
|
|
<blockquote class="note">
|
|
<p>This wording is relative to N3691.</p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>
|
|
Edit 20.8.1.2 [unique.ptr.single] p1 as indicated:
|
|
</p>
|
|
<blockquote><p>
|
|
The default type for the template parameter <tt>D</tt> is <tt>default_delete</tt>.
|
|
A client-supplied template argument <tt>D</tt> shall be a function object type (20.10), lvalue-reference to function, or
|
|
lvalue-reference to function object type for which, given a value <tt>d</tt> of type <tt>D</tt> and a value <tt>ptr</tt> of type
|
|
<tt>unique_ptr<T, D>::pointer</tt>, the expression <tt>d(ptr)</tt> is valid and has the effect of disposing of the pointer
|
|
as appropriate for that deleter. <ins><tt>d(ptr)</tt> shall be valid even if it triggers the destruction of <tt>d</tt> or (if
|
|
<tt>D</tt> is an lvalue reference to function object type) the function object that <tt>d</tt> refers to.</ins>
|
|
</p></blockquote>
|
|
</li>
|
|
</ol>
|
|
</blockquote>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
After some discussion in Lenexa there was some wavering on if the added sentence is necessary. Here is example code that
|
|
demonstrates why the extra sentence is necessary. In this example the call to <tt>d(ptr)</tt> is valid, however the deleter
|
|
references <tt>*this</tt> after destructing its element:
|
|
</p>
|
|
<blockquote><pre>
|
|
#include <cassert>
|
|
#include <memory>
|
|
#include <iostream>
|
|
|
|
class Deleter
|
|
{
|
|
int state_ = 0;
|
|
|
|
enum
|
|
{
|
|
destructed = -4,
|
|
self_move_assigned = -3,
|
|
move_assigned_from = -2,
|
|
move_constructed_from = -1
|
|
};
|
|
public:
|
|
~Deleter() {state_ = destructed;}
|
|
|
|
Deleter() = default;
|
|
Deleter(Deleter const&) = default;
|
|
Deleter& operator=(Deleter const&) = default;
|
|
|
|
Deleter(Deleter&& a) noexcept
|
|
: state_(a.state_)
|
|
{a.state_ = move_constructed_from;}
|
|
|
|
Deleter& operator=(Deleter&& a) noexcept
|
|
{
|
|
if (this == &a)
|
|
state_ = self_move_assigned;
|
|
else
|
|
{
|
|
state_ = a.state_;
|
|
a.state_ = move_assigned_from;
|
|
}
|
|
return *this;
|
|
}
|
|
|
|
Deleter(int state)
|
|
: state_(state)
|
|
{
|
|
assert(state >= 0);
|
|
}
|
|
|
|
template <class T>
|
|
void
|
|
operator()(T* t) const
|
|
{
|
|
std::cout << "Deleter beginning operator()(T*)\n";
|
|
std::cout << "The deleter = " << *this << '\n';
|
|
std::cout << "Deleter about to destruct the X.\n";
|
|
delete t;
|
|
std::cout << "Deleter has destructed the X.\n";
|
|
std::cout << "The deleter = " << *this << '\n';
|
|
std::cout << "Deleter ending operator()(T*)\n";
|
|
}
|
|
|
|
friend
|
|
std::ostream&
|
|
operator<<(std::ostream& os, const Deleter& a)
|
|
{
|
|
switch (a.state_)
|
|
{
|
|
case destructed:
|
|
os << "**destructed**";
|
|
break;
|
|
case self_move_assigned:
|
|
os << "self_move_assigned";
|
|
break;
|
|
case move_assigned_from:
|
|
os << "move_assigned_from";
|
|
break;
|
|
case move_constructed_from:
|
|
os << "move_constructed_from";
|
|
break;
|
|
default:
|
|
os << a.state_;
|
|
break;
|
|
}
|
|
return os;
|
|
}
|
|
};
|
|
|
|
struct X
|
|
{
|
|
Deleter deleter_{1};
|
|
};
|
|
|
|
int main()
|
|
{
|
|
auto xp = new X;
|
|
{
|
|
std::unique_ptr<X, Deleter&> p(xp, xp->deleter_);
|
|
std::cout << "unique_ptr is constructed.\n";
|
|
std::cout << "The deleter = " << p.get_deleter() << '\n';
|
|
std::cout << "Destructing unique_ptr...\n";
|
|
}
|
|
std::cout << "unique_ptr is destructed.\n";
|
|
}
|
|
</pre></blockquote>
|
|
<p>
|
|
Which outputs:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
unique_ptr is constructed.
|
|
The deleter = 1
|
|
Destructing unique_ptr...
|
|
Deleter beginning operator()(T*)
|
|
The deleter = 1
|
|
Deleter about to destruct the X.
|
|
Deleter has destructed the X.
|
|
The deleter = **destructed**
|
|
Deleter ending operator()(T*)
|
|
unique_ptr is destructed.
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
The line "<tt>The deleter = **destructed**</tt>" represents the deleter referencing itself after it has been destructed by the
|
|
<tt>d(ptr)</tt> expression, but prior to that call returning.
|
|
<p/>
|
|
Suggested alternative to the current proposed wording:
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
The expression <tt>d(ptr)</tt> shall not refer to the object <tt>d</tt> after it executes <tt>ptr->~T()</tt>.
|
|
</p>
|
|
</blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N4431.</p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>
|
|
Edit 20.8.1.2 [unique.ptr.single] p1 as indicated:
|
|
</p>
|
|
<blockquote><p>
|
|
The default type for the template parameter <tt>D</tt> is <tt>default_delete</tt>.
|
|
A client-supplied template argument <tt>D</tt> shall be a function object type (20.9), lvalue-reference to function, or
|
|
lvalue-reference to function object type for which, given a value <tt>d</tt> of type <tt>D</tt> and a value <tt>ptr</tt> of type
|
|
<tt>unique_ptr<T, D>::pointer</tt>, the expression <tt>d(ptr)</tt> is valid and has the effect of disposing of the pointer
|
|
as appropriate for that deleter. <ins>The expression <tt>d(ptr)</tt> shall not refer to the object <tt>d</tt> after it executes
|
|
<tt>ptr->~T()</tt>.</ins>
|
|
</p></blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2264"></a>2264. [arrays.ts] <tt>std::dynarray</tt> defines its initializer-list constructor in terms of a non-existent constructor</h3>
|
|
<p><b>Section:</b> X [dynarray], 23.2 [container.requirements] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Povilas Kanapickas <b>Opened:</b> 2013-05-22 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p><b>Addresses: arrays.ts</b></p>
|
|
|
|
<p>
|
|
<tt>std::dynarray</tt> member listing at X [dynarray.overview] includes this constructor:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
dynarray(initializer_list<T>);
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
Also, X [dynarray.overview] p. 2 says:
|
|
</p>
|
|
|
|
<blockquote><p>
|
|
Unless otherwise specified, all <tt>dynarray</tt> operations have the same requirements and semantics as specified in 23.2.
|
|
</p></blockquote>
|
|
|
|
<p>
|
|
The constructor in question isn't mentioned in X [dynarray.cons] or anywhere else. This means requirements from
|
|
23.2 [container.requirements] apply. However, Table 100 in 23.2.3 [sequence.reqmts] says:
|
|
</p>
|
|
|
|
<blockquote><p>
|
|
<tt>X(il)</tt> Equivalent to <tt>X(il.begin(), il.end())</tt>
|
|
</p></blockquote>
|
|
|
|
<p>
|
|
<tt>std::dynarray</tt> does not provide this constructor.
|
|
</p>
|
|
|
|
<p>
|
|
The proposed resolution below adds the missing constructor and a complementary constructor with an allocator parameter.
|
|
The new constructors, differently from the rest of containers, accept iterators that have forward iterator category. This
|
|
is needed because the size requirements must be known in order to allocate appropriately-sized storage.
|
|
<p/>
|
|
An alternative resolution could be to properly specify the initializer-list constructor.
|
|
</p>
|
|
|
|
<p><i>[2013-09 Chicago:]</i></p>
|
|
|
|
<p>
|
|
Move to Deferred. This feature will ship after C++14 and should be revisited then.
|
|
</p>
|
|
|
|
<p><i>[2014-06-06 pre-Rapperswill]</i></p>
|
|
|
|
<p>
|
|
This issue has been reopened as arrays-ts.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<ol>
|
|
<li><p>Add the following to the <tt>std::dynarray</tt> synopsis at X [dynarray.overview]:</p>
|
|
|
|
<blockquote><pre>
|
|
namespace std {
|
|
template <class T>
|
|
class dynarray {
|
|
[…]
|
|
<i>// 23.3.4.2 construct/copy/destroy:</i>
|
|
[…]
|
|
<ins>template <class ForwardIterator></ins>
|
|
<ins>dynarray(ForwardIterator first, ForwardIterator last);</ins>
|
|
<ins>template <class ForwardIterator, class Alloc></ins>
|
|
<ins>dynarray(ForwardIterator first, ForwardIterator last, const Alloc& alloc);</ins>
|
|
[…]
|
|
};
|
|
}
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li><p>Add the following to X [dynarray.cons] after p. 8:</p>
|
|
|
|
<blockquote><pre>
|
|
<ins>template <class ForwardIterator>
|
|
dynarray(ForwardIterator first, ForwardIterator last);</ins>
|
|
</pre><blockquote>
|
|
<p>
|
|
<ins>-?- <i>Requires:</i> <tt>T</tt> shall meet the <tt>CopyConstructible</tt> requirements.</ins>
|
|
<p/>
|
|
<ins>-?- <i>Effects:</i> Allocates storage for <tt>distance(first, last)</tt> elements.
|
|
The <tt>distance(first, last)</tt> elements of the dynarray are direct-initialized (8.5 [dcl.init]) with the
|
|
corresponding elements from the range <tt>[first,last)</tt>. May or may not invoke the global <tt>operator new</tt>.</ins>
|
|
<p/>
|
|
<ins>-?- <i>Complexity:</i> <tt>distance(first, last)</tt>.</ins>
|
|
<p/>
|
|
<ins>-?- <i>Throws:</i> <tt>std::bad_array_length</tt> when the size requested is larger than implementable, <tt>std::bad_alloc</tt>
|
|
when there is insufficient memory.</ins>
|
|
</p>
|
|
</blockquote></blockquote>
|
|
</li>
|
|
|
|
<li><p>Add the following to the list of constructors at X [dynarray.cons] before p. 9:</p>
|
|
</li>
|
|
|
|
<blockquote><pre>
|
|
template <class Alloc>
|
|
dynarray(size_type c, const Alloc& alloc);
|
|
template <class Alloc>
|
|
dynarray(size_type c, const T& v, const Alloc& alloc);
|
|
template <class Alloc>
|
|
dynarray(const dynarray& d, const Alloc& alloc);
|
|
template <class Alloc>
|
|
dynarray(initializer_list<T>, const Alloc& alloc);
|
|
<ins>template <class ForwardIterator, class Alloc>
|
|
dynarray(ForwardIterator first, ForwardIterator last, const Alloc& alloc);</ins>
|
|
</pre></blockquote>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2265"></a>2265. 29.3p9 appears to rule out some acceptable executions</h3>
|
|
<p><b>Section:</b> 29.3 [atomics.order] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Brian Demsky <b>Opened:</b> 2013-06-17 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#atomics.order">active issues</a> in [atomics.order].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#atomics.order">issues</a> in [atomics.order].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
I believe that the following variation on IRIW should admit executions in
|
|
which <tt>c1 = d1 = 5</tt> and <tt>c2 = d2 = 0</tt>. If this is allowed, then what is sequence of
|
|
program evaluations for 29.3 [atomics.order] p9 that justifies the store to <tt>z</tt>? It seems that
|
|
29.3 [atomics.order] p9 should not allow this execution because one of the stores to <tt>x</tt> or <tt>y</tt> has
|
|
to appear earlier in the sequence, each of the <tt>fetch_adds</tt> reads the previous load in the thread (and thus must
|
|
appear later in the sequence), and 29.3 [atomics.order] p9 states that each load must read from the last prior
|
|
assignment in the sequence.
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
atomic_int x;
|
|
atomic_int y;
|
|
atomic_int z;
|
|
int c1, c2, d1, d2;
|
|
|
|
static void a(void* obj)
|
|
{
|
|
atomic_store_explicit(&x, 5, memory_order_relaxed);
|
|
}
|
|
|
|
static void b(void* obj)
|
|
{
|
|
atomic_store_explicit(&y, 5, memory_order_relaxed);
|
|
}
|
|
|
|
static void c(void* obj)
|
|
{
|
|
c1 = atomic_load_explicit(&x, memory_order_relaxed);
|
|
// this could also be an atomic load if the address depends on c1:
|
|
c2 = atomic_fetch_add_explicit(&y, c1, memory_order_relaxed);
|
|
}
|
|
|
|
static void d(void* obj)
|
|
{
|
|
d1 = atomic_load_explicit(&y, memory_order_relaxed);
|
|
d2 = atomic_fetch_add_explicit(&x, d1, memory_order_relaxed);
|
|
}
|
|
|
|
int user_main(int argc, char** argv)
|
|
{
|
|
thrd_t t1, t2, t3, t4;
|
|
|
|
atomic_init(&x, 0);
|
|
atomic_init(&y, 0);
|
|
|
|
printf("Main thread: creating 4 threads\n");
|
|
thrd_create(&t1, (thrd_start_t)&a, NULL);
|
|
thrd_create(&t2, (thrd_start_t)&b, NULL);
|
|
thrd_create(&t3, (thrd_start_t)&c, NULL);
|
|
thrd_create(&t4, (thrd_start_t)&d, NULL);
|
|
|
|
thrd_join(t1);
|
|
thrd_join(t2);
|
|
thrd_join(t3);
|
|
thrd_join(t4);
|
|
printf("c1=%d c2=%d\n",c1,c2);
|
|
printf("d1=%d d2=%d\n",d1,d2);
|
|
|
|
// Can this store write 1000 (i.e., c1=d1=5, c2=d2=0)?
|
|
atomic_store(&z, (c1+d1)*100+c2+d2);
|
|
|
|
printf("Main thread is finished\n");
|
|
|
|
return 0;
|
|
}
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
It seems that the easiest fix is to allow a load in 29.3 [atomics.order] p9 to read from any prior
|
|
store in the evaluation order.
|
|
<p/>
|
|
That said, I would personally advocate the following:
|
|
It seems to me that C/C++ atomics are in a bit of different situation than Java
|
|
because:
|
|
</p>
|
|
<ol>
|
|
<li><p>People are expected to use relaxed C++ atomics in potentially racy
|
|
situations, so it isn't clear that semantics as complicated as the JMM's
|
|
causality would be sane.
|
|
</p></li>
|
|
<li><p>People who use C/C++ atomics are likely to be experts and use them in a
|
|
very controlled fashion. I would be really surprised if compilers would find
|
|
any real wins by optimizing the use of atomics.
|
|
</p></li>
|
|
</ol>
|
|
<p>
|
|
Why not do something like:
|
|
<p/>
|
|
There is satisfaction DAG of all program evaluations. Each evaluation
|
|
observes the values of variables as computed by some prior assignment in
|
|
the DAG.
|
|
<p/>
|
|
There is an edge <tt>x->y</tt> between two evaluations <tt>x</tt> and <tt>y</tt> if:
|
|
</p>
|
|
<ol>
|
|
<li><p>the evaluation <tt>y</tt> observes a value computed by the evaluation <tt>x</tt> or
|
|
</p></li>
|
|
<li><p>the evaluation <tt>y</tt> is an atomic store, the evaluation <tt>x</tt> is an atomic load, and
|
|
there is a condition branch c that may depend (intrathread dependence) on <tt>x</tt>
|
|
and <tt>x-sb->c</tt> and <tt>c-sb->y</tt>.
|
|
</p></li>
|
|
</ol>
|
|
<p>
|
|
This seems to allow reordering of relaxed atomics that processors do without
|
|
extra fence instructions, allows most reorderings by the compiler, and gets
|
|
rid of satisfaction cycles.
|
|
</p>
|
|
|
|
<p><i>[2015-02 Cologne]</i></p>
|
|
|
|
<p>
|
|
Handed over to SG1.
|
|
</p>
|
|
|
|
|
|
<p><i>[2015-05 Lenexa, SG1 response]</i></p>
|
|
|
|
<p>
|
|
This was partially addressed (weasel-worded) in C++14 (See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3786.htm">N3786</a>).
|
|
The remainder is an open research problem. <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3710.html">N3710</a> outlines a "solution" that doesn't have a consensus behind it because it costs performance. We have no better solution at the moment.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2267"></a>2267. <tt>partial_sort_copy</tt> underspecified for ranges of two different types</h3>
|
|
<p><b>Section:</b> 25.4.1.4 [partial.sort.copy] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Matt Austern <b>Opened:</b> 2013-06-26 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The signature of this function is:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
template<class InputIterator, class RandomAccessIterator>
|
|
RandomAccessIterator
|
|
partial_sort_copy(InputIterator first, InputIterator last,
|
|
RandomAccessIterator result_first,
|
|
RandomAccessIterator result_last);
|
|
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
(and the usual overload for an explicitly provided comparison function). The standard says nothing about requirements
|
|
in the case where the input type (<tt>iterator_traits<InputIterator>::value_type</tt>) and the output type
|
|
(<tt>iterator_traits<RandomAccessIterator>::value_type</tt>) are different.
|
|
<p/>
|
|
Presumably the input type must be convertible to the output type. What's less clear is what the requirements are on
|
|
the comparison operator. Does the algorithm only perform comparisons on two values of the output type, or does it also
|
|
perform comparisons on values of the input type, or might it even perform heterogeneous comparisons?
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2269"></a>2269. Container iterators and argument-dependent lookup</h3>
|
|
<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Matt Austern <b>Opened:</b> 2013-06-26 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Consider the following code snippet:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
#include <vector>
|
|
#include <algorithm>
|
|
|
|
int main() {
|
|
std::vector<int> v1(100, 3);
|
|
std::vector<int> v2(100);
|
|
copy(v1.begin(), v1.end(), v2.begin());
|
|
}
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
It compiles without error on my desktop. Is it required to? I can't find evidence from the standard that it is.
|
|
In my test <tt>std::copy</tt> was found by argument-dependent lookup because the implementation I used made
|
|
<tt>std::vector<int>::iterator</tt> a user-defined type defined in namespace <tt>std</tt>. But the standard
|
|
only requires <tt>std::vector<int>::iterator</tt> to be an implementation specified random access iterator
|
|
type. I can't find anything requiring it to be a user-defined type at all (and in fact there are reasonable implementation
|
|
where it isn't), let alone a user defined type defined in a specific namespace.
|
|
</p>
|
|
|
|
<p>
|
|
Since the defining namespace of container iterators is visible to users, should the standard say anything about what
|
|
that namespace is?
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2273"></a>2273. <tt>regex_match</tt> ambiguity</h3>
|
|
<p><b>Section:</b> 28.11.2 [re.alg.match] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2013-07-14 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#re.alg.match">issues</a> in [re.alg.match].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
28.11.2 [re.alg.match] p2 in describing regex_match says:
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
-2- <i>Effects:</i> Determines whether there is a match between the regular expression <tt>e</tt>, and all of
|
|
the character sequence <tt>[first,last)</tt>. The parameter <tt>flags</tt> is used to control how the expression
|
|
is matched against the character sequence. Returns true if such a match exists, false otherwise.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p>
|
|
It has come to my attention that different people are interpreting the first sentence of p2 in different ways:
|
|
</p>
|
|
|
|
<ol>
|
|
<li><p>
|
|
If a search of the input string using the regular expression <tt>e</tt> matches the entire input string,
|
|
<tt>regex_match</tt> should return true.
|
|
</p></li>
|
|
<li><p>
|
|
Search the input string using the regular expression <tt>e</tt>. Reject all matches that do not match the
|
|
entire input string. If a such a match is found, return true.
|
|
</p></li>
|
|
</ol>
|
|
|
|
<p>
|
|
The difference between these two subtly different interpretations is found using the following ECMAScript example:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
std::regex re("Get|GetValue");
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
Using <tt>regex_search</tt>, this <tt>re</tt> can never match the input string <tt>"GetValue"</tt>, because ECMA
|
|
specifies that alternations are ordered, not greedy. As soon as <tt>"Get"</tt> is matched in the left alternation,
|
|
the matching algorithm stops.
|
|
<p/>
|
|
Using definition 1, <tt>regex_match</tt> would return false for an input string of <tt>"GetValue"</tt>.
|
|
<p/>
|
|
However definition 2 alters the grammar and appears equivalent to augmenting the regex with a trailing <tt>'$'</tt>,
|
|
which is an anchor that specifies, reject any matches which do not come at the end of the input sequence.
|
|
So, using definition 2, <tt>regex_match</tt> would return true for an input string of <tt>"GetValue"</tt>.
|
|
<p/>
|
|
My opinion is that it would be strange to have <tt>regex_match</tt> return true for a <tt>string/regex</tt>
|
|
pair that <tt>regex_search</tt> could never find. I.e. I favor definition 1.
|
|
<p/>
|
|
John Maddock writes:
|
|
<p/>
|
|
The intention was always that <tt>regex_match</tt> would reject any match candidate which didn't match the entire
|
|
input string. So it would find <tt>GetValue</tt> in this case because the <tt>"Get"</tt> alternative had already
|
|
been rejected as not matching. Note that the comparison with ECMA script is somewhat moot, as ECMAScript defines
|
|
the regex grammar (the bit we've imported), it does not define anything like <tt>regex_match</tt>, nor do we import
|
|
from ECMAScript the behaviour of that function. So IMO the function should behave consistently regardless of the
|
|
regex dialect chosen. Saying "use awk regexes" doesn't cut it, because that changes the grammar in other ways.
|
|
<p/>
|
|
(John favors definition 2).
|
|
<p/>
|
|
We need to clarify 28.11.2 [re.alg.match]/p2 in one of these two directions.
|
|
</p>
|
|
|
|
<p><i>[2014-06-21, Rapperswil]</i></p>
|
|
|
|
<p>
|
|
AM: I think there's a clear direction and consensus we agree with John Maddock's position, and if noone else
|
|
thinks we need the other function I won't ask for it.
|
|
<p/>
|
|
Marshall Clow and STL to draft.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2276"></a>2276. Missing requirement on <tt>std::promise::set_exception</tt></h3>
|
|
<p><b>Section:</b> 30.6 [futures] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2013-07-30 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#futures">issues</a> in [futures].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The standard does not specify the behaviour of this program:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
#include <future>
|
|
#include <cassert>
|
|
|
|
struct NonTrivial
|
|
{
|
|
NonTrivial() : init(true) { }
|
|
~NonTrivial() { assert(init); }
|
|
bool init;
|
|
};
|
|
|
|
int main()
|
|
{
|
|
std::promise<NonTrivial> p;
|
|
auto f = p.get_future();
|
|
p.set_exception(std::exception_ptr());
|
|
f.get();
|
|
}
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
The standard doesn't forbid making the state ready with a null
|
|
<tt>exception_ptr</tt>, so what should <tt>get()</tt> return? There's no stored
|
|
exception to throw, but it can't return a value because none was initialized.
|
|
<p/>
|
|
A careful reading of the standard shows 30.6.4 [futures.state] p8 says
|
|
"A shared state is <em>ready</em> only if it holds a value or an exception
|
|
ready for retrieval." One can infer from the fact that <tt>set_exception()</tt>
|
|
makes the state ready that it must store a value or exception, so
|
|
cannot store "nothing", but that isn't explicit.
|
|
<p/>
|
|
The <tt>promise::set_exception()</tt> and <tt>promise::set_exception_at_thread_exit()</tt>
|
|
members should require <tt>p != nullptr</tt> or should state the type of exception thrown
|
|
if <tt>p</tt> is null.
|
|
</p>
|
|
|
|
<p><i>[2015-02 Cologne]</i></p>
|
|
|
|
<p>
|
|
Handed over to SG1.
|
|
</p>
|
|
|
|
<p><i>[2015-05 Lenexa, SG1 response]</i></p>
|
|
|
|
<p>
|
|
SG1 provides P/R and requests move to SG1-OK status: Add Requires clauses for promise (30.6.5 [futures.promise]) set_exception (before p18) and set_exception_at_thread_exit (before p24): Requires: p is not null.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
This wording is relative to N4431.
|
|
</p>
|
|
Add Requires clauses for promise (30.6.5 [futures.promise]) <tt>set_exception</tt> (before p18) and
|
|
<tt>set_exception_at_thread_exit</tt> (before p24): <i>Requires</i>: <tt>p</tt> is not null.
|
|
|
|
<ol>
|
|
<li><p>Change 30.6.5 [futures.promise] as depicted:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
void set_exception(exception_ptr p);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
<ins>-??- <i>Requires:</i> <tt>p</tt> is not null. </ins>
|
|
</p>
|
|
<p>
|
|
-18- <i>Effects:</i> atomically stores the exception pointer <tt>p</tt> in the shared state and makes that state ready (30.6.4).
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
void set_exception_at_thread_exit(exception_ptr p);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
<ins>-??- <i>Requires:</i> <tt>p</tt> is not null. </ins>
|
|
</p>
|
|
<p>
|
|
-24- <i>Effects:</i> Stores the exception pointer <tt>p</tt> in the shared state without making that state ready immediately. […]
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li></ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2277"></a>2277. [arrays.ts] <tt><dynarray></tt> is missing in 24.7/1</h3>
|
|
<p><b>Section:</b> 24.7 [iterator.range] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Cassio Neri <b>Opened:</b> 2013-07-31 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#iterator.range">active issues</a> in [iterator.range].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#iterator.range">issues</a> in [iterator.range].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p><b>Addresses: arrays.ts</b></p>
|
|
|
|
<p>
|
|
Section 24.7 [iterator.range] p1 specifies header files that, in addition to
|
|
<tt><iterator></tt>, make available the function templates in 24.7
|
|
(<tt>begin</tt>, <tt>end</tt>, etc.) but it fails to mention
|
|
<tt><dynarray></tt>. This seems to be just an oversight.
|
|
</p>
|
|
|
|
<p><i>[2013-09 Chicago:]</i></p>
|
|
|
|
<p>
|
|
Move to Deferred. This feature will ship after C++14 and should be revisited then.
|
|
</p>
|
|
|
|
<p><i>[2014-06-06 pre-Rapperswill]</i></p>
|
|
|
|
<p>
|
|
This issue has been reopened as arrays-ts.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<p>This wording is relative to N3691.</p>
|
|
|
|
<ol>
|
|
<li><p>Modify 24.7 [iterator.range] p1 as indicated:</p>
|
|
|
|
<blockquote><p>
|
|
-1- In addition to being available via inclusion of the <tt><iterator></tt> header, the function templates in 24.7 are
|
|
available when any of the following headers are included: <tt><array></tt>, <tt><deque></tt>,
|
|
<ins><tt><dynarray></tt>,</ins>
|
|
<tt><forward_list></tt>, <tt><list></tt>, <tt><map></tt>, <tt><regex></tt>,
|
|
<tt><set></tt>, <tt><string></tt>, <tt><unordered_map></tt>, <tt><unordered_set></tt>,
|
|
and <tt><vector></tt>.
|
|
</p></blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2286"></a>2286. <tt>stringbuf::underflow()</tt> underspecified</h3>
|
|
<p><b>Section:</b> 27.8.2.4 [stringbuf.virtuals] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Sergey Zubkov <b>Opened:</b> 2013-08-29 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
In 27.8.2.4 [stringbuf.virtuals]/1, <tt>basic_stringbuf::underflow()</tt> is specified to unconditionally
|
|
return <tt>traits::eof()</tt> when a read position is not available.
|
|
<p/>
|
|
The semantics of <tt>basic_stringbuf</tt> require, and existing libraries implement it so that this function makes
|
|
a read position available if possible to do so, e.g. if some characters were inserted into the stream since the
|
|
last call to <tt>overflow()</tt>, resulting in <tt>pptr() > egptr()</tt>. Compare to the conceptually similar
|
|
D.7.1.3 [depr.strstreambuf.virtuals]/15.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3691.</p>
|
|
|
|
<ol>
|
|
|
|
<li><p>Change 27.8.2.4 [stringbuf.virtuals] as indicated:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
int_type underflow();
|
|
</pre><blockquote>
|
|
<p>
|
|
-1- <i>Returns:</i> If the input sequence has a read position available <ins>or the function makes a read position available
|
|
(as described below)</ins>, returns <tt>traits::to_int_type(*gptr())</tt>. Otherwise, returns <tt>traits::eof()</tt>. Any
|
|
character in the underlying buffer which has been initialized is considered to be part of the input sequence.
|
|
<p/>
|
|
<ins>-?- The function can make a read position available only if <tt>(mode & ios_base::in) != 0</tt> and if the write
|
|
next pointer <tt>pptr()</tt> is not null and is greater than the current read end pointer <tt>egptr()</tt>. To make a read
|
|
position available, the function alters the read end pointer <tt>egptr()</tt> to equal <tt>pptr()</tt>.</ins>
|
|
</p>
|
|
</blockquote></blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2289"></a>2289. <tt>constexpr</tt> guarantees of defaulted functions still insufficient</h3>
|
|
<p><b>Section:</b> 20.3.2 [pairs.pair], 20.4.2.1 [tuple.cnstr], 20.12.5 [time.duration] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2013-09-09 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#pairs.pair">issues</a> in [pairs.pair].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
During the acceptance of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3471.html">N3471</a> and
|
|
some similar <tt>constexpr</tt> papers, specific wording was added to <tt>pair</tt>, <tt>tuple</tt>, and other templates
|
|
that were intended to impose implementation constraints that ensure that the observable <tt>constexpr</tt> "character"
|
|
of a defaulted function template is solely determined by the required expressions of the user-provided types when instantiated,
|
|
for example:
|
|
</p>
|
|
|
|
<blockquote><p>
|
|
The defaulted move and copy constructor, respectively, of pair shall be a <tt>constexpr</tt> function if and only if
|
|
all required element-wise initializations for copy and move, respectively, would satisfy the requirements for
|
|
a <tt>constexpr</tt> function.
|
|
</p></blockquote>
|
|
|
|
<p>
|
|
This wording doesn't require enough, especially since the core language via CWG 1358 does now support <tt>constexpr</tt>
|
|
function template instantiations, even if such function cannot appear in a constant expression (as specified in 5.20 [expr.const])
|
|
or as a constant initializer of that object (as specified in 3.6.2 [basic.start.init]). The wording should be
|
|
improved and should require valid uses in constant expressions and as constant initializers instead.
|
|
</p>
|
|
|
|
<p><i>[Lenexa 2015-05-05]</i></p>
|
|
|
|
<p>STL : notice order of move/copy and copy/move with "respectively".</p>
|
|
<p>General word-smithing; ask for updated wording</p>
|
|
<p>Are we happy with this with changes we are suggesting?</p>
|
|
<p>unanimous</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3691.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 20.3.2 [pairs.pair] p2 as indicated:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-2- <del>The defaulted move and copy constructor, respectively, of pair shall be a <tt>constexpr</tt> function if and only if
|
|
all required element-wise initializations for copy and move, respectively, would satisfy the requirements for
|
|
a <tt>constexpr</tt> function</del><ins>An invocation of the move or copy constructor of <tt>pair</tt> shall be a constant expression
|
|
(5.20 [expr.const]) if all required element-wise initializations would be constant expressions. An invocation of the
|
|
move or copy constructor of <tt>pair</tt> shall be a constant initializer for that <tt>pair</tt> object (3.6.2 [basic.start.init])
|
|
if all required element-wise initializations would be constant initializers for the respective subobjects</ins>.
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 20.4.2.1 [tuple.cnstr] p2 as indicated:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-2- <del>The defaulted move and copy constructor, respectively, of <tt>tuple</tt> shall be a <tt>constexpr</tt> function if
|
|
and only if all required element-wise initializations for copy and move, respectively, would satisfy the requirements for
|
|
a <tt>constexpr</tt> function. The defaulted move and copy constructor of <tt>tuple<></tt> shall be <tt>constexpr</tt>
|
|
functions</del><ins>An invocation of the move or copy constructor of <tt>tuple</tt> shall be a constant expression (5.20 [expr.const])
|
|
if all required element-wise initializations would be constant expressions. An invocation of the move or copy constructor of
|
|
<tt>tuple</tt> shall be a constant initializer for that <tt>tuple</tt> object (3.6.2 [basic.start.init]) if all
|
|
required element-wise initializations would be constant initializers for the respective subobjects. An invocation of the
|
|
move or copy constructor of <tt>tuple<></tt> shall be a constant expression, or a constant initializer for that
|
|
<tt>tuple<></tt> object, respectively, if the function argument would be constant expression</ins>.
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 20.12.5 [time.duration] p7 as indicated:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-7- <i>Remarks:</i> <del>The defaulted copy constructor of duration shall be a <tt>constexpr</tt> function if and only if
|
|
the required initialization of the member <tt>rep_</tt> for copy and move, respectively, would satisfy the
|
|
requirements for a <tt>constexpr</tt> function.</del><ins>An invocation of the copy constructor of <tt>duration</tt> shall
|
|
be a constant expression (5.20 [expr.const]) if the required initialization of the member <tt>rep_</tt> would be a constant expression.
|
|
An invocation of the copy constructor of <tt>duration</tt> shall be a constant initializer for that <tt>duration</tt> object
|
|
(3.6.2 [basic.start.init]) if the required initialization of the member <tt>rep_</tt> would be constant initializers
|
|
for this subobject</ins>.
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2290"></a>2290. Top-level "SFINAE"-based constraints should get a separate definition in Clause 17</h3>
|
|
<p><b>Section:</b> 20.10 [meta] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2013-09-02 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#meta">active issues</a> in [meta].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#meta">issues</a> in [meta].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The current library specification uses at several places wording that is intended to refer to
|
|
core language template deduction failure at the top-level of expressions (aka "SFINAE"), for example:
|
|
</p>
|
|
|
|
<blockquote><p>
|
|
The expression <tt>declval<T>() = declval<U>()</tt> is well-formed when treated as an unevaluated operand (Clause 5).
|
|
Access checking is performed as if in a context unrelated to <tt>T</tt> and <tt>U</tt>. Only the validity of the immediate context
|
|
of the assignment expression is considered. [<i>Note:</i> The compilation of the expression can result in side effects
|
|
such as the instantiation of class template specializations and function template specializations, the generation of
|
|
implicitly-defined functions, and so on. Such side effects are not in the "immediate context" and can result in the program
|
|
being ill-formed. — <i>end note</i>]
|
|
</p></blockquote>
|
|
|
|
<p>
|
|
Similar wording can be found in the specification of <tt>result_of</tt>, <tt>is_constructible</tt>, and <tt>is_convertible</tt>,
|
|
being added to resolve an NB comment by LWG <a href="lwg-defects.html#1390">1390</a> and <a href="lwg-defects.html#1391">1391</a> through
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html">N3142</a>.
|
|
<p/>
|
|
This wording is necessary to limit speculative compilations needed to implement these traits, but it is also lengthy and repetitive.
|
|
</p>
|
|
|
|
<p><i>[2014-05-19, Daniel suggests a descriptive term]</i></p>
|
|
|
|
<p>
|
|
<b>constrictedly well-formed expression</b>:
|
|
<p/>
|
|
An expression <em>e</em> depending on a set of types <tt>A1</tt>, ..., <tt>An</tt> which is well-formed when treated as
|
|
an unevaluated operand (Clause 5). Access checking is performed as if in a context unrelated to <tt>A1</tt>, ...,
|
|
<tt>An</tt>. Only the validity of the immediate context of <em>e</em> is considered. [<i>Note:</i> The compilation of
|
|
the expression can result in side effects such as the instantiation of class template specializations and function
|
|
template specializations, the generation of implicitly-defined functions, and so on. Such side effects are not in the
|
|
"immediate context" and can result in the program being ill-formed. — <i>end note</i>]
|
|
</p>
|
|
|
|
<p><i>[2014-05-20, Richard and Jonathan suggest better terms]</i></p>
|
|
|
|
<p>
|
|
Richard suggested "locally well-formed"
|
|
<p/>
|
|
Jonathan suggested "contextually well-formed" and then "The expression ... is valid in a contrived argument
|
|
deduction context"
|
|
</p>
|
|
|
|
<p><i>[2014-06-07, Daniel comments and improves wording]</i></p>
|
|
|
|
<p>
|
|
The 2014-05-19 suggestion did only apply to expressions, but there are two important examples that are not expressions, but instead
|
|
are involving an <em>object definition</em> (<tt>std::is_constructible</tt>) and a <em>function definition</em>
|
|
(<tt>std::is_convertible</tt>), respectively, instead. Therefore I suggest to rephrase the usage of "expression" into "program
|
|
construct" in the definition of Jonathan's suggestion of "valid in a contrived argument deduction context".
|
|
<p/>
|
|
I would like to point out that given the new definition of "valid in a contrived argument deduction context", there are several other
|
|
places of the Library specification that could take advantage of this wording to improve the existing specification, such as
|
|
20.9.12.2 [func.wrap.func] p2, most functions in 20.7.8.2 [allocator.traits.members], and the <tt>**Insertable</tt>,
|
|
<tt>EmplaceConstructible</tt>, and <tt>Erasable</tt> definitions in 23.2.1 [container.requirements.general], but given that
|
|
these are not fully described in terms of the aforementioned wording <em>yet</em>, I would recommend to fix them by a separate issue
|
|
once the committee has agreed on following the suggestion presented by this issue.
|
|
</p>
|
|
|
|
<p><i>[2015-05-05 Lenexa: Move to Open]</i></p>
|
|
|
|
<p>...</p>
|
|
<p>MC: I think we like the direction but it isn't quite right: it needs some work</p>
|
|
<p>JW: I'm prepared to volunteer to move that further, hopefully with the help of Daniel</p>
|
|
<p>Roger Orr: should this be Core wording because it doesn't really have anything to do with libraries - the term could then just be used here</p>
|
|
<p>AM: Core has nothing to deal with that, though</p>
|
|
<p>HT: it seems there is nothing to imply that allows dropping out with an error - maybe that's a separate issue</p>
|
|
<p>MC: I'm not getting what you are getting at: could you write an issue? - any objection to move to Open?</p>
|
|
<p>...</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Add the following new definition to 17.3 [definitions] as indicated:</p>
|
|
|
|
<p>
|
|
<ins><b>valid in a contrived argument deduction context</b> [defns.valid.contr.context]</ins>
|
|
<p/>
|
|
<ins>A program construct <em>c</em> depending on a set of types <tt>A1</tt>, ..., <tt>An</tt>, and treated as
|
|
an unevaluated operand (Clause 5) when <em>c</em> is an expression, which is well-formed.
|
|
Access checking is performed as if in a context unrelated to <tt>A1</tt>, ..., <tt>An</tt>.
|
|
Only the validity of the immediate context (14.8.2 [temp.deduct]) of <em>c</em> is considered.
|
|
[<i>Note:</i> The compilation of <em>c</em> can result in side effects such as the instantiation of class template
|
|
specializations and function template specializations, the generation of implicitly-defined functions, and so on.
|
|
Such side effects are not in the "immediate context" and can result in the program being ill-formed. —
|
|
<i>end note</i>].</ins>
|
|
</p>
|
|
</li>
|
|
|
|
<li><p>Change Table 49 ("Type property predicates") as indicated:</p>
|
|
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 49 — Type property predicates</caption>
|
|
<tr>
|
|
<th align="center">Template</th>
|
|
<th align="center">Condition</th>
|
|
<th align="center">Preconditions</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="3" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>template <class T, class U><br/>
|
|
struct is_assignable;</tt>
|
|
</td>
|
|
|
|
<td>
|
|
The expression
|
|
<tt>declval<T>() =<br/>
|
|
declval<U>()</tt> is <ins>valid in a<br/>
|
|
contrived argument deduction context<br/>
|
|
([defns.valid.contr.context]) for types<br/>
|
|
<tt>T</tt> and <tt>U</tt>.</ins>
|
|
<del>well-formed when treated<br/>
|
|
as an unevaluated operand<br/>
|
|
(Clause 5). Access<br/>
|
|
checking is performed as if<br/>
|
|
in a context unrelated to <tt>T</tt><br/>
|
|
and <tt>U</tt>. Only the validity of<br/>
|
|
the immediate context of<br/>
|
|
the assignment expression<br/>
|
|
is considered. [<i>Note</i>: The<br/>
|
|
compilation of the<br/>
|
|
expression can result in<br/>
|
|
side effects such as the<br/>
|
|
instantiation of class<br/>
|
|
template specializations<br/>
|
|
and function template<br/>
|
|
specializations, the<br/>
|
|
generation of<br/>
|
|
implicitly-defined<br/>
|
|
functions, and so on. Such<br/>
|
|
side effects are not in the<br/>
|
|
"immediate context" and<br/>
|
|
can result in the program<br/>
|
|
being ill-formed. — end<br/>
|
|
note]</del>
|
|
</td>
|
|
|
|
<td align="center">
|
|
[…]
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="3" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote>
|
|
|
|
</li>
|
|
|
|
<li><p>Change 20.10.4.3 [meta.unary.prop] p7 as indicated:</p>
|
|
|
|
<blockquote><p>
|
|
-7- Given the following function prototype:
|
|
</p>
|
|
<blockquote><pre>
|
|
template <class T>
|
|
add_rvalue_reference_t<T> create() noexcept;
|
|
</pre></blockquote>
|
|
<p>
|
|
the predicate condition for a template specialization <tt>is_constructible<T, Args...></tt> shall be satisfied
|
|
if and only if the following variable definition <del>would be well-formed</del> for some invented
|
|
variable <tt>t</tt> <ins>would be valid in a contrived argument deduction context ([defns.valid.contr.context]) for
|
|
types <tt>T</tt> and <tt>Args...</tt></ins>:
|
|
</p>
|
|
<blockquote><pre>
|
|
T t(create<Args>()...);
|
|
</pre></blockquote>
|
|
<p>
|
|
[<i>Note</i>: These tokens are never interpreted as a function declaration. — <i>end note</i>] <del>Access checking is
|
|
performed as if in a context unrelated to <tt>T</tt> and any of the <tt>Args</tt>. Only the validity of the immediate context
|
|
of the variable initialization is considered. [<i>Note</i>: The evaluation of the initialization can result in side
|
|
effects such as the instantiation of class template specializations and function template specializations, the
|
|
generation of implicitly-defined functions, and so on. Such side effects are not in the "immediate context"
|
|
and can result in the program being ill-formed. — <i>end note</i>]</del>
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change Table 57 ("Other transformations") as indicated:</p>
|
|
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 57 — Other transformations</caption>
|
|
<tr>
|
|
<th align="center">Template</th>
|
|
<th align="center">Condition</th>
|
|
<th align="center">Comments</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="3" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>template <class Fn, class... ArgTypes><br/>
|
|
struct result_of<Fn(ArgTypes...)>;</tt>
|
|
</td>
|
|
|
|
<td align="center">
|
|
[…]
|
|
</td>
|
|
|
|
<td>
|
|
If the expression<br/>
|
|
<tt><i>INVOKE</i>(declval<Fn>(),<br/>
|
|
declval<ArgTypes>()...)</tt> is<br/>
|
|
<ins>valid in a contrived argument deduction<br/>
|
|
context ([defns.valid.contr.context]) for types<br/>
|
|
<tt>Fn</tt> and <tt>ArgTypes...</tt></ins>
|
|
<del>well<br/>
|
|
formed when treated as an<br/>
|
|
unevaluated operand (Clause 5)</del>, the<br/>
|
|
member typedef type shall name the<br/>
|
|
type<br/>
|
|
<tt>decltype(<i>INVOKE</i>(declval<Fn>(),<br/>
|
|
declval<ArgTypes>()...))</tt>;<br/>
|
|
otherwise, there shall be no member<br/>
|
|
type. <del>Access checking is performed as<br/>
|
|
if in a context unrelated to <tt>Fn</tt> and<br/>
|
|
<tt>ArgTypes</tt>. Only the validity of the<br/>
|
|
immediate context of the expression is<br/>
|
|
considered. [<i>Note</i>: The compilation of<br/>
|
|
the expression can result in side<br/>
|
|
effects such as the instantiation of<br/>
|
|
class template specializations and<br/>
|
|
function template specializations, the<br/>
|
|
generation of implicitly-defined<br/>
|
|
functions, and so on. Such side effects<br/>
|
|
are not in the "immediate context"<br/>
|
|
and can result in the program being<br/>
|
|
ill-formed. — <i>end note</i>]</del>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="3" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote>
|
|
|
|
</li>
|
|
|
|
<li><p>Change 20.10.6 [meta.rel] p4 as indicated:</p>
|
|
|
|
<blockquote><p>
|
|
-4- Given the following function prototype:
|
|
</p>
|
|
<blockquote><pre>
|
|
template <class T>
|
|
add_rvalue_reference_t<T> create() noexcept;
|
|
</pre></blockquote>
|
|
<p>
|
|
the predicate condition for a template specialization <tt>is_convertible<From, To></tt> shall be satisfied if and
|
|
only if the return expression in the following code would be <del>well-formed</del><ins>valid in a contrived argument
|
|
deduction context ([defns.valid.contr.context]) for types <tt>To</tt> and <tt>From</tt></ins>, including any implicit conversions
|
|
to the return type of the function:
|
|
</p>
|
|
<blockquote><pre>
|
|
To test() {
|
|
return create<From>();
|
|
}
|
|
</pre></blockquote>
|
|
<p>
|
|
[<i>Note</i>: This requirement gives well defined results for reference types, <tt>void</tt> types, array types, and
|
|
function types. — <i>end note</i>] <del>Access checking is performed as if in a context unrelated to <tt>To</tt>
|
|
and <tt>From</tt>. Only the validity of the immediate context of the expression of the return-statement (including conversions to
|
|
the return type) is considered. [<i>Note</i>: The evaluation of the conversion can result in side effects such as
|
|
the instantiation of class template specializations and function template specializations, the generation of
|
|
implicitly-defined functions, and so on. Such side effects are not in the "immediate context" and can result
|
|
in the program being ill-formed. — <i>end note</i>]</del>
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2292"></a>2292. Find a better phrasing for "shall not participate in overload resolution"</h3>
|
|
<p><b>Section:</b> 17.5.1.4 [structure.specifications] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2013-09-03 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#structure.specifications">issues</a> in [structure.specifications].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The C++14 CD has 25 sections including the phrase "X shall not
|
|
participate in overload resolution ...". Most of these uses are double
|
|
negatives, which are hard to interpret. "shall not ... unless" tends
|
|
to be the easiest to read, since the condition is true when the
|
|
function is available, but we also have a lot of "if X is not Y, then
|
|
Z shall not participate", which actually means "You can call Z if X is
|
|
Y." The current wording is also clumsy and long-winded. We should find
|
|
a better and more concise phrasing.
|
|
<p/>
|
|
As an initial proposal, I'd suggest using "X is enabled if and only if Y" in prose
|
|
and adding an "<i>Enabled If:</i> ..." element to 17.5.1.4 [structure.specifications].
|
|
<p/>
|
|
Daniel:
|
|
<p/>
|
|
I suggest to name this new specification element for 17.5.1.4 [structure.specifications]
|
|
as "<i>Template Constraints:</i>" instead, because the mentioned wording form was intentionally provided
|
|
starting with LWG <a href="lwg-defects.html#1237">1237</a> to give implementations more freedom to realize the
|
|
concrete constraints. Instead of the original <tt>std::enable_if</tt>-based specifications
|
|
we can use better forms of "SFINAE" constraints today and it eases the path to possible language-based
|
|
constraints in the future.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2294"></a>2294. <tt><cstdlib></tt> should declare <tt>abs(double)</tt></h3>
|
|
<p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Pete Becker <b>Opened:</b> 2013-09-04 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#c.math">issues</a> in [c.math].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
… and <tt>abs(float)</tt> and <tt>abs(long double)</tt>. And <tt><cmath></tt> should declare
|
|
<tt>abs(int)</tt>, <tt>abs(long)</tt>, and <tt>abs(long long)</tt>.
|
|
<p/>
|
|
As things currently stand, this program is illegal:
|
|
</p>
|
|
<blockquote><pre>
|
|
#include <cstdlib>
|
|
|
|
int main() {
|
|
double d = -1.23;
|
|
double dd = std::abs(d);
|
|
return 0;
|
|
}
|
|
</pre></blockquote>
|
|
<p>
|
|
The call is ambiguous because of the various integer overloads, that's because <tt><cstdlib></tt> provides
|
|
<tt>abs(int)</tt> but not <tt>abs(double)</tt>.
|
|
<p/>
|
|
This lead one commenter on Stackoverflow to state that <tt>abs</tt> is dangerous, and to recommend using <tt>fabs</tt> instead.
|
|
<p/>
|
|
In general, it makes sense to declare overloaded functions that take user-defined types in the same header as the
|
|
definition of the user-defined types; it isn't necessary to declare all of the overloads in the same place. But
|
|
here we're not dealing with any user-defined types; we're dealing with builtin types, which are always defined;
|
|
all of the overloads should be defined in the same place, to avoid mysterious problems like the one in the code above.
|
|
<p/>
|
|
The standard library has six overloads for <tt>abs</tt>:
|
|
</p>
|
|
<blockquote><pre>
|
|
int abs(int); // <cstdlib>
|
|
long abs(long); // <cstdlib>
|
|
long long abs(long long); // <cstdlib>
|
|
|
|
float abs(float); // <cmath>
|
|
double abs(double); // <cmath>
|
|
long double abs(long double); // <cmath>
|
|
</pre></blockquote>
|
|
<p>
|
|
These should all be declared in both headers.
|
|
<p/>
|
|
I have no opinion on <tt><stdlib.h></tt> and <tt><math.h></tt>.
|
|
</p>
|
|
|
|
<p><i>[2013-09 Chicago]</i></p>
|
|
|
|
<p>
|
|
This issue is related to LWG <a href="lwg-active.html#2192">2192</a>
|
|
<p/>
|
|
Move to open
|
|
</p>
|
|
|
|
<p><i>[2014-02-13 Issaquah — Nicolai Josuttis suggest wording]</i></p>
|
|
|
|
|
|
<p><i>[2015-03-03, Geoffrey Romer provides improved wording]</i></p>
|
|
|
|
<p>
|
|
See proposed resolution of LWG <a href="lwg-active.html#2192">2192</a>.
|
|
</p>
|
|
|
|
<strong>Previous resolution from Nicolai [SUPERSEDED]:</strong>
|
|
<blockquote class = "note">
|
|
<ol>
|
|
<li><p>Edit 26.8 [c.math] after p7 as indicated:</p>
|
|
|
|
<blockquote><p>
|
|
-6- In addition to the <tt>int</tt> versions of certain math functions in <tt><cstdlib></tt>, C++ adds <tt>long</tt> and <tt>long long</tt>
|
|
overloaded versions of these functions, with the same semantics.
|
|
<p/>
|
|
-7- The added signatures are:
|
|
</p>
|
|
<blockquote><pre>
|
|
long abs(long); <i>// labs()</i>
|
|
long long abs(long long); <i>// llabs()</i>
|
|
ldiv_t div(long, long); <i>// ldiv()</i>
|
|
lldiv_t div(long long, long long); <i>// lldiv()</i>
|
|
</pre></blockquote>
|
|
<p>
|
|
<ins>-?- To avoid ambiguities, C++ also adds the following overloads of <tt>abs()</tt> to <tt><cstdlib></tt>,
|
|
with the semantics defined in <tt><cmath></tt>:</ins>
|
|
</p>
|
|
<blockquote><pre>
|
|
<ins>float abs(float);
|
|
double abs(double);
|
|
long double abs(long double);</ins>
|
|
</pre></blockquote>
|
|
<p>
|
|
<ins>-?- To avoid ambiguities, C++ also adds the following overloads of <tt>abs()</tt> to <tt><cmath></tt>,
|
|
with the semantics defined in <tt><cstdlib></tt>:</ins>
|
|
</p>
|
|
<blockquote><pre>
|
|
<ins>int abs(int);
|
|
long abs(long);
|
|
long long abs(long long);</ins>
|
|
</pre></blockquote>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
</blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
See proposed resolution of LWG <a href="lwg-active.html#2192">2192</a>.
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2295"></a>2295. Locale name when the provided <tt>Facet</tt> is a <tt>nullptr</tt></h3>
|
|
<p><b>Section:</b> 22.3.1.2 [locale.cons] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Juan Soulie <b>Opened:</b> 2013-09-04 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
22.3.1.2 [locale.cons] p14 ends with:
|
|
</p>
|
|
<blockquote><p>
|
|
"[…] If <tt>f</tt> is null, the resulting object is a copy of <tt>other</tt>."
|
|
</p></blockquote>
|
|
<p>
|
|
but the next line p15 says:
|
|
</p>
|
|
<blockquote><p>
|
|
"<i>Remarks:</i> The resulting locale has no name."
|
|
</p></blockquote>
|
|
<p>
|
|
But both can't be true when <tt>other</tt> has a name and <tt>f</tt> is null.
|
|
<p/>
|
|
I've tried it on two implementations (MSVC,GCC) and they are inconsistent with each other on this.
|
|
</p>
|
|
<p>
|
|
Daniel Krügler:
|
|
<p/>
|
|
As currently written, the <i>Remarks</i> element applies unconditionally for all cases and thus should
|
|
"win". The question arises whether the introduction of this element by LWG <a href="lwg-closed.html#424">424</a> had actually intended
|
|
to change the previous <i>Note</i> to a <i>Remarks</i> element. In either case the wording should be improved
|
|
to clarify this special case.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2296"></a>2296. <tt>std::addressof</tt> should be <tt>constexpr</tt></h3>
|
|
<p><b>Section:</b> 20.7.12.1 [specialized.addressof] <b>Status:</b> <a href="lwg-active.html#Review">Review</a>
|
|
<b>Submitter:</b> Daryle Walker <b>Opened:</b> 2013-09-08 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#specialized.addressof">issues</a> in [specialized.addressof].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Review">Review</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
I'm writing a function that needs to be <tt>constexpr</tt> and I wanted to take the address of its input. I was
|
|
thinking of using <tt>std::addressof</tt> to be safe, but it isn't currently <tt>constexpr</tt>. A
|
|
<a href="http://en.cppreference.com/w/cpp/memory/addressof">sample implementation</a>
|
|
couldn't be <tt>constexpr</tt> under the C++11 rules, though.
|
|
<p/>
|
|
Daniel Krügler:
|
|
<p/>
|
|
Indeed the core language clarified by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1312">CWG 1312</a>
|
|
and by <a href="www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#1384">CWG 1384</a>, that such emulations of <tt>std::addressof</tt>
|
|
implementations are not valid in constant expressions, therefore it seems more like a defect than a feature request to ask for
|
|
the guarantee that <tt>std::addressof</tt> is a <tt>constexpr</tt> function. It should be added that a similar requirement
|
|
already exists for <tt>offsetof</tt> indirectly via the C99 standard as of 7.17 p3:
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
The macros are […]
|
|
</p>
|
|
<blockquote><pre>
|
|
offsetof(type, member-designator)
|
|
</pre></blockquote>
|
|
<p>
|
|
which expands to an integer constant expression that has type <tt>size_t</tt> […]
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p>
|
|
combined with the noted property in C++11 that:
|
|
</p>
|
|
|
|
<blockquote><p>
|
|
"<tt>offsetof</tt> is required to work as specified even if unary <tt>operator&</tt>
|
|
is overloaded for any of the types involved"
|
|
</p></blockquote>
|
|
|
|
<p>
|
|
Therefore implementations should already be able without heroic efforts to realize this functionality by
|
|
some intrinsic. The wording needs at least to ensure that for any lvalue core constant expression <tt><em>e</em></tt>
|
|
the expression <tt>std::addressof(<em>e</em>)</tt> is a core constant expression.
|
|
</p>
|
|
|
|
<p><i>[2013-09 Chicago]</i></p>
|
|
|
|
<p>
|
|
</p>
|
|
|
|
<p><i>[2014-06-08, Daniel improves wording]</i></p>
|
|
|
|
<p>
|
|
It has been ensured that the wording is in sync with the recent working paper and the usage of "any" has been
|
|
improved to say "every" instead (the fix is similar to that applied by LWG <a href="lwg-defects.html#2150">2150</a>).
|
|
</p>
|
|
|
|
<p>
|
|
<strong>Previous resolution from Daniel [SUPERSEDED]:</strong>
|
|
</p>
|
|
<blockquote class="note">
|
|
<ol>
|
|
<li><p>Change header <tt><memory></tt> synopsis, 20.7.2 [memory.syn] as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
namespace std {
|
|
[…]
|
|
<i>// 20.7.12 [specialized.algorithms], specialized algorithms:</i>
|
|
template <class T> <ins>constexpr</ins> T* addressof(T& r) noexcept;
|
|
[…]
|
|
}
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 20.7.12.1 [specialized.addressof] as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
template <class T> <ins>constexpr</ins> T* addressof(T& r) noexcept;
|
|
</pre><blockquote>
|
|
<p>
|
|
-1- <i>Returns:</i> The actual address of the object or function referenced by <tt>r</tt>, even in the presence of an
|
|
overloaded <tt>operator&</tt>.
|
|
<p/>
|
|
<ins>-?- <i>Remarks:</i> For every lvalue core constant expression <tt><em>e</em></tt> (5.20 [expr.const]), the expression
|
|
<tt>std::addressof(<em>e</em>)</tt> is a core constant expression.</ins>
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
|
|
</li>
|
|
</ol>
|
|
</blockquote>
|
|
|
|
<p><i>[2014-06-09, further improvements]</i></p>
|
|
|
|
<p>
|
|
A new wording form is now used similar to the approach used by LWG <a href="lwg-active.html#2234">2234</a>, which
|
|
is a stricter way to impose the necessary implementation requirements.
|
|
</p>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
STL: the intent of this change is good; I think the wording is good<br/>
|
|
- I'm a bit worried about asking for a compiler hook<br/>
|
|
- if every implementer says: yes they can do it we should be good<br/>
|
|
EB: there is missing the word "a" before "subexpression" (in multiple places)<br/>
|
|
MC: the editor should do - we rely on our editors<br/>
|
|
MC: move to Review with a note stating that we wait for implementation experience first<br/>
|
|
- in favor: 13, opposed: 0, abstain: 2
|
|
HB: N4430 will bring something which is addressing this issue<br/>
|
|
MC: good we didn't go to ready then
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Introduce the following new definition to the existing list in 17.3 [definitions]: [<i>Drafting note</i>:
|
|
If LWG <a href="lwg-active.html#2234">2234</a> is accepted before this issue, the accepted wording for the new definition should be used instead
|
|
— <i>end drafting note</i>]</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<strong>constant subexpression</strong> [defns.const.subexpr]
|
|
<p/>
|
|
an expression whose evaluation as subexpression of a <em>conditional-expression</em> <em>CE</em> (5.16 [expr.cond])
|
|
would not prevent <em>CE</em> from being a core constant expression (5.20 [expr.const]).
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change header <tt><memory></tt> synopsis, 20.7.2 [memory.syn] as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
namespace std {
|
|
[…]
|
|
<i>// 20.7.12 [specialized.algorithms], specialized algorithms:</i>
|
|
template <class T> <ins>constexpr</ins> T* addressof(T& r) noexcept;
|
|
[…]
|
|
}
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 20.7.12.1 [specialized.addressof] as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
template <class T> <ins>constexpr</ins> T* addressof(T& r) noexcept;
|
|
</pre><blockquote>
|
|
<p>
|
|
-1- <i>Returns:</i> The actual address of the object or function referenced by <tt>r</tt>, even in the presence of an
|
|
overloaded <tt>operator&</tt>.
|
|
<p/>
|
|
<ins>-?- <i>Remarks:</i> An expression <tt>std::addressof(<em>E</em>)</tt> is a constant subexpression ( [defns.const.subexpr]),
|
|
if <tt><em>E</em></tt> is an lvalue constant subexpression.</ins>
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2303"></a>2303. Explicit instantiation of <tt>std::vector<UserType></tt> broken?</h3>
|
|
<p><b>Section:</b> 18.6.1.3 [new.delete.placement] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2013-09-18 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#new.delete.placement">issues</a> in [new.delete.placement].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The library gives explicit permission in 17.6.4.2.1 [namespace.std] p2 that user code may explicitly instantiate
|
|
a library template provided that the instantiations depend on at least one user-defined type:
|
|
</p>
|
|
|
|
<blockquote><p>
|
|
A program may explicitly instantiate a template defined in the standard library only if the declaration
|
|
depends on the name of a user-defined type and the instantiation meets the standard library requirements
|
|
for the original template.
|
|
</p></blockquote>
|
|
|
|
<p>
|
|
But it seems that the C++11 library is not specified in a way that guarantees such an instantiation to be well-formed
|
|
if the minimum requirements of the library is not satisfied.
|
|
<p/>
|
|
For example, in general, the first template parameter of <tt>std::vector</tt> is not required to be
|
|
<tt>DefaultConstructible</tt> in general, but due to the split of the single C++03 member function
|
|
with default argument
|
|
</p>
|
|
<blockquote><pre>
|
|
void resize(size_type sz, T c = T());
|
|
</pre></blockquote>
|
|
<p>
|
|
into
|
|
</p>
|
|
<blockquote><pre>
|
|
void resize(size_type sz);
|
|
void resize(size_type sz, const T& c);
|
|
</pre></blockquote>
|
|
<p>
|
|
the effect is now that for a type <tt>ND</tt> that is not <tt>DefaultConstructible</tt>, such as
|
|
</p>
|
|
<blockquote><pre>
|
|
struct NP {
|
|
NP(int);
|
|
};
|
|
</pre></blockquote>
|
|
<p>
|
|
the explicit instantiation of <tt>std::vector<ND></tt> is no longer well-formed, because the attempt to
|
|
instantiate the single-argument overload of <tt>resize</tt> cannot not succeed, because this function imposes
|
|
the <tt>DefaultInsertable</tt> requirements and given the default allocator this effectively requires
|
|
<tt>DefaultConstructible</tt>.
|
|
</p>
|
|
<p>
|
|
But <tt>DefaultConstructible</tt> is not the only point, what about <tt>CopyConstructible</tt> versus
|
|
<tt>MoveConstructible</tt> alone? It turns out that currently the second <tt>resize</tt> overload
|
|
would fail during an explicit instantiation for a type like
|
|
</p>
|
|
<blockquote><pre>
|
|
struct MO {
|
|
MO() = default;
|
|
MO(MO&&) = default;
|
|
};
|
|
</pre></blockquote>
|
|
<p>
|
|
because it imposes <tt>CopyInsertable</tt> requirements that end up being equivalent to the <tt>CopyConstructible</tt>
|
|
requirements for the default allocator.
|
|
<p/>
|
|
Technically a library can solve these issues: For special member functions by defining them in some base class, for others
|
|
by transforming them effectively into a function template due to the great feature of default template arguments for
|
|
function templates (At the very moment the validity of the latter approach depends on a resolution of core language issue
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1635">CWG 1635</a>, though). E.g. the here mentioned
|
|
<tt>resize</tt> functions of <tt>std::vector</tt> could be prevented from instantiation by defining them like this
|
|
with an implementation:
|
|
</p>
|
|
<blockquote><pre>
|
|
template<class = void>
|
|
void resize(size_type sz) { […] }
|
|
template<class = void>
|
|
void resize(size_type sz, const T& c) { […] }
|
|
</pre></blockquote>
|
|
<p>
|
|
In this case, these functions could also be defined in a base class, but the latter approach won't work in all cases.
|
|
<p/>
|
|
Basically such an implementation is required to constrain all member functions that are not covered by the general
|
|
requirements imposed on the actual library template parameters. I tested three different C++11 library implementations
|
|
and but none could instantiate for example <tt>std::list</tt>, <tt>std::vector</tt>, or <tt>std::deque</tt> with
|
|
value types that are not <tt>DefaultConstructible</tt> or only <tt>MoveConstructible</tt>.
|
|
<p/>
|
|
|
|
<p/>
|
|
This issue is raised to clarify the current situation in regard to the actual requirements imposed on user-provided
|
|
types that are used to explicitly instantiate Library-provided templates. For example, the current Container requirements
|
|
impose very little requirements on the actual value type and it is unclear to which extend library implementations have
|
|
to respect that.
|
|
<p/>
|
|
The minimum solution of this issue should be to at least realize that there is no fundamental requirement on
|
|
<tt>DefaultConstructible</tt> for value types of library containers, because we have since C++03 the general
|
|
statement of 17.6.3.1 [utility.arg.requirements] ("In general, a default constructor is not required.").
|
|
It is unclear whether <tt>CopyConstructible</tt> should be required for an explicit instantiation request, but
|
|
given the careful introduction of move operations in the library it would seem astonishing that a
|
|
<tt>MoveConstructible</tt> type wouldn't suffice for value types of the container types.
|
|
<p/>
|
|
In any case I can envision at least two approaches to solve this issue:
|
|
</p>
|
|
<ol>
|
|
<li>
|
|
<p>
|
|
As indicated in LWG <a href="lwg-active.html#2292">2292</a>, those function could get an explicit "<i>Template Constraints:</i>"
|
|
element, albeit this promises more than needed to solve this issue.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
The library could introduce a completely new element form, such as "<i>Instantiation Constraints:</i>" that
|
|
would handle this situation for explicit instantiation situations. This would allow for simpler techniques
|
|
to solve the issue when explicit instantiation is required compared to the first bullet, because it would not
|
|
(necessarily) guarantee SFINAE-friendly expression-wellformedness, such as inspecting the expression
|
|
<tt>std::declval<std::vector<ND>&>.resize(0)</tt> in an unevaluated context.
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>
|
|
It should be noted that the 2013-08-27 comment to LWG <a href="lwg-defects.html#2193">2193</a> could be resolved by a similar solution
|
|
as indicated in this issue here.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2307"></a>2307. Should the Standard Library use <tt>explicit</tt> only when necessary?</h3>
|
|
<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Zhihao Yuan <b>Opened:</b> 2013-09-26 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#containers">active issues</a> in [containers].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#containers">issues</a> in [containers].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
LWG <a href="lwg-defects.html#2193">2193</a> yields <tt>explicit</tt> for default ctors to allow <tt>{}</tt>, but not for
|
|
all cases of uniform initialization. For example:
|
|
</p>
|
|
<blockquote><pre>
|
|
explicit vector(size_type count, const Allocator& alloc = Allocator());
|
|
</pre></blockquote>
|
|
<p>
|
|
This prevents <tt>{n, alloc()}</tt>. Although this use is relatively rare,
|
|
but the behavior is inconsistent with that of
|
|
</p>
|
|
<blockquote><pre>
|
|
vector(size_type count, const T& value, const Allocator& alloc = Allocator());
|
|
</pre></blockquote>
|
|
|
|
<p><i>[Urbana 2014-11-07: Move to Open]</i></p>
|
|
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2309"></a>2309. <tt>mutex::lock()</tt> should not throw <tt>device_or_resource_busy</tt></h3>
|
|
<p><b>Section:</b> 30.4.1.2 [thread.mutex.requirements.mutex] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Detlef Vollmann <b>Opened:</b> 2013-09-27 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#thread.mutex.requirements.mutex">issues</a> in [thread.mutex.requirements.mutex].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
As discussed during the Chicago meeting in
|
|
<a href="http://wiki.edg.com/twiki/bin/view/Wg21chicago2013/ThursdayMorningMinutes#LWG_2135_revisited">SG1</a>
|
|
the only reasonable reasons for throwing <tt>device_or_resource_busy</tt> seem to be:
|
|
</p>
|
|
<ul>
|
|
<li><p>
|
|
The thread currently already holds the mutex, the mutex is not recursive, and the implementation detects this.
|
|
In this case <tt>resource_deadlock_would_occur</tt> should be thrown.
|
|
</p></li>
|
|
<li><p>
|
|
Priority reasons. At least <tt>std::mutex</tt> (and possibly all standard mutex types)
|
|
should not be setup this way, otherwise we have real problems with <tt>condition_variable::wait()</tt>.
|
|
</p></li>
|
|
</ul>
|
|
|
|
<p><i>[2014-06-17 Rapperswil]</i></p>
|
|
|
|
<p>
|
|
Detlef provides wording
|
|
</p>
|
|
|
|
<p><i>[2015-02 Cologne]</i></p>
|
|
|
|
<p>
|
|
Handed over to SG1.
|
|
</p>
|
|
|
|
<p><i>[2015-05 Lenexa, SG1 response]</i></p>
|
|
|
|
<p>
|
|
We believe we were already done with it. Should be in SG1-OK status.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 30.4.1.2 [thread.mutex.requirements.mutex] as indicated:</p>
|
|
|
|
<blockquote><p>
|
|
-13- <i>Error conditions</i>:
|
|
</p>
|
|
<ul>
|
|
<li><p><tt>operation_not_permitted</tt> — if the thread does not have the privilege to perform the operation.</p></li>
|
|
<li><p><tt>resource_deadlock_would_occur</tt> — if the implementation detects that a deadlock would occur.</p></li>
|
|
<li><p><del><tt>device_or_resource_busy</tt> — if the mutex is already locked and blocking is not possible.</del></p></li>
|
|
</ul>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2310"></a>2310. Public <em>exposition only</em> member in <tt>std::array</tt></h3>
|
|
<p><b>Section:</b> 23.3.2.1 [array.overview] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2013-09-30 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
23.3.2.1 [array.overview] shows <tt>std::array</tt> with an "exposition only" data member, <tt>elems</tt>.
|
|
<p/>
|
|
The wording in 17.5.2.3 [objects.within.classes] that defines how
|
|
"exposition only" is used says it applies to private members, but
|
|
<tt>std::array::elems</tt> (or its equivalent) must be public in order for
|
|
<tt>std::array</tt> to be an aggregate.
|
|
<p/>
|
|
If the intention is that <tt>std::array::elems</tt> places requirements on the
|
|
implementation to provide "equivalent external behavior" to a public
|
|
array member, then 17.5.2.3 [objects.within.classes] needs to cover public
|
|
members too, or some other form should be used in 23.3.2.1 [array.overview].
|
|
</p>
|
|
|
|
<p><i>[Urbana 2014-11-07: Move to Open]</i></p>
|
|
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2312"></a>2312. <tt>tuple</tt>'s constructor constraints need to be phrased more precisely</h3>
|
|
<p><b>Section:</b> 20.4.2.1 [tuple.cnstr] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-09-21 <b>Last modified:</b> 2015-05-06</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#tuple.cnstr">active issues</a> in [tuple.cnstr].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#tuple.cnstr">issues</a> in [tuple.cnstr].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Consider the following code:
|
|
</p>
|
|
<blockquote><pre>
|
|
void meow(tuple<long, long>) { puts("Two"); }
|
|
|
|
void meow(tuple<long, long, long>) { puts("Three"); }
|
|
|
|
tuple<int, int, int> t(0, 0, 0);
|
|
|
|
meow(t);
|
|
</pre></blockquote>
|
|
<p>
|
|
This should compile and print "Three" because <tt>tuple<long, long></tt>'s constructor from
|
|
<tt>const tuple<int, int, int>&</tt> should remove itself from overload resolution.
|
|
Implementations sensibly do this, but the Standard doesn't actually say it!
|
|
<p/>
|
|
In this case, <tt>Types</tt> is "<tt>long, long</tt>" and <tt>UTypes</tt> is "<tt>int, int, int</tt>". 20.4.2.1 [tuple.cnstr]/3
|
|
says "let <tt>i</tt> be in the range <tt>[0,sizeof...(Types))</tt> in order", which is <tt>[0, 2)</tt>. Then /17 says
|
|
"<i>Remark:</i> This constructor shall not participate in overload resolution unless <tt>const Ui&</tt> is implicitly
|
|
convertible to <tt>Ti</tt> for all <tt>i</tt>." Interpreted literally, this is true! /15 says
|
|
"<i>Requires:</i> <tt>sizeof...(Types) == sizeof...(UTypes)</tt>." but requiring the sizes to be identical doesn't help.
|
|
Only the special phrase "shall not participate in overload resolution unless" mandates SFINAE/<tt>enable_if</tt> machinery.
|
|
<p/>
|
|
The wording that we need is almost available in the <i>Requires</i> paragraphs, except that the <i>Requires</i> paragraphs say
|
|
"<tt>is_constructible</tt>" while the Remark paragraphs say "is implicitly convertible", which is the correct thing for the SFINAE
|
|
constraints to check. My proposed resolution is to unify the <i>Requires</i> and <i>Remark</i> paragraphs, after which there
|
|
will be no need for <i>Requires</i> (when a constructor participates in overload resolution if and only if <tt>X</tt> is true,
|
|
then there's no need for it to <i>Require</i> that <tt>X</tt> is true).
|
|
<p/>
|
|
Note: 20.10.4.3 [meta.unary.prop]/6 specifies <tt>is_constructible<To, From></tt> and 20.10.6 [meta.rel]/4 specifies
|
|
<tt>is_convertible<From, To></tt>. Both are specified in terms of
|
|
"<tt>template <class T> typename add_rvalue_reference<T>::type create();</tt>".
|
|
Therefore, passing <tt>From</tt> and <tt>From&&</tt> is equivalent, regardless of whether <tt>From</tt> is an object type,
|
|
an lvalue reference, or an rvalue reference.
|
|
<p/>
|
|
Also note that 20.4.2.1 [tuple.cnstr]/3 defines <tt>T0</tt> and <tt>T1</tt> so we don't need to repeat their definitions.
|
|
</p>
|
|
|
|
<p><i>[2014-10-05, Daniel comments]</i></p>
|
|
|
|
<p>
|
|
This issue is closely related to LWG <a href="lwg-active.html#2419">2419</a>.
|
|
</p>
|
|
|
|
<p><i>[2015-02, Cologne]</i></p>
|
|
|
|
<p>
|
|
AM: Howard wants to do something in this space and I want to wait for him to get a paper in.
|
|
<p/>
|
|
Postponed.
|
|
</p>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
MC: handled by Daniel's tuple paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4387.html">N4387</a><br/>
|
|
STL: look at status after N4387 applied.
|
|
</p>
|
|
<p><i>[2015-05-05, Daniel comments]</i></p>
|
|
|
|
<p>
|
|
N4387 doesn't touch these area intentionally. I agree with Howard that a different option exists that would introduce
|
|
a TupleLike concept. Some implementations currently take advantage of this choice and this P/R would forbid them, which seems
|
|
unfortunate to me.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3691.</p>
|
|
|
|
<ol>
|
|
<li><p>Edit 20.4.2.1 [tuple.cnstr] as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
template <class... UTypes>
|
|
explicit constexpr tuple(UTypes&&... u);
|
|
</pre><blockquote>
|
|
<p>
|
|
<del>-8- <i>Requires:</i> <tt>sizeof...(Types) == sizeof...(UTypes)</tt>. <tt>is_constructible<Ti, Ui&&>::value</tt> is true
|
|
for all <i>i</i>.</del>
|
|
<p/>
|
|
[…]
|
|
<p/>
|
|
-10- <i>Remark:</i> This constructor shall not participate in overload resolution unless <del>each type in <tt>UTypes</tt> is
|
|
implicitly convertible to its corresponding type in <tt>Types</tt></del><ins><tt>sizeof...(Types) == sizeof...(UTypes)</tt> and
|
|
both <tt>is_constructible<Ti, Ui>::value</tt> and <tt>is_convertible<Ui, Ti>::value</tt> are true for all <i>i</i></ins>.
|
|
</p>
|
|
</blockquote>
|
|
<p>
|
|
[…]
|
|
</p>
|
|
</blockquote>
|
|
<blockquote><pre>
|
|
template <class... UTypes>
|
|
constexpr tuple(const tuple<UTypes...>& u);
|
|
</pre><blockquote>
|
|
<p>
|
|
<del>-15- <i>Requires:</i> <tt>sizeof...(Types) == sizeof...(UTypes)</tt>. <tt>is_constructible<Ti, const Ui&>::value</tt> is true
|
|
for all <i>i</i>.</del>
|
|
<p/>
|
|
[…]
|
|
<p/>
|
|
-17- <i>Remark:</i> This constructor shall not participate in overload resolution unless <del><tt>const Ui&</tt> is implicitly
|
|
convertible to <tt>Ti</tt></del><ins><tt>sizeof...(Types) == sizeof...(UTypes)</tt> and
|
|
both <tt>is_constructible<Ti, const Ui&>::value</tt> and <tt>is_convertible<const Ui&, Ti>::value</tt> are
|
|
true</ins> for all <i>i</i>.
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
<blockquote><pre>
|
|
template <class... UTypes>
|
|
constexpr tuple(tuple<UTypes...>&& u);
|
|
</pre><blockquote>
|
|
<p>
|
|
<del>-18- <i>Requires:</i> <tt>sizeof...(Types) == sizeof...(UTypes)</tt>. <tt>is_constructible<Ti, Ui&&>::value</tt> is true
|
|
for all <i>i</i>.</del>
|
|
<p/>
|
|
[…]
|
|
<p/>
|
|
-20- <i>Remark:</i> This constructor shall not participate in overload resolution unless <del>each type in <tt>UTypes</tt> is
|
|
implicitly convertible to its corresponding type in <tt>Types</tt></del><ins><tt>sizeof...(Types) == sizeof...(UTypes)</tt> and
|
|
both <tt>is_constructible<Ti, Ui>::value</tt> and <tt>is_convertible<Ui, Ti>::value</tt> are true for all <i>i</i></ins>.
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
<blockquote><pre>
|
|
template <class U1, class U2> constexpr tuple(const pair<U1, U2>& u);
|
|
</pre><blockquote>
|
|
<p>
|
|
<del>-21- <i>Requires:</i> <tt>sizeof...(Types) == 2</tt>. <tt>is_constructible<T0, const U1&>::value</tt> is true for the first
|
|
type <tt>T0</tt> in Types and <tt>is_constructible<T1, const U2&>::value</tt> is true for the second type <tt>T1</tt> in
|
|
<tt>Types</tt>.</del>
|
|
<p/>
|
|
[…]
|
|
<p/>
|
|
-23- <i>Remark:</i> This constructor shall not participate in overload resolution unless <del><tt>const U1&</tt> is implicitly
|
|
convertible to <tt>T0</tt> and <tt>const U2&</tt> is implicitly convertible to <tt>T1</tt></del><ins><tt>sizeof...(Types) == 2
|
|
&& is_constructible<T0, const U1&>::value && is_constructible<T1, const U2&>::value &&
|
|
is_convertible<const U1&, T0>::value && is_convertible<const U2&, T1>::value</tt> is true</ins>.
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
<blockquote><pre>
|
|
template <class U1, class U2> constexpr tuple(pair<U1, U2>&& u);
|
|
</pre><blockquote>
|
|
<p>
|
|
<del>-24- <i>Requires:</i> <tt>sizeof...(Types) == 2</tt>. <tt>is_constructible<T0, U1&&>::value</tt> is true for the first
|
|
type <tt>T0</tt> in Types and <tt>is_constructible<T1, U2&&>::value</tt> is true for the second type <tt>T1</tt> in
|
|
<tt>Types</tt>.</del>
|
|
<p/>
|
|
[…]
|
|
<p/>
|
|
-26- <i>Remark:</i> This constructor shall not participate in overload resolution unless <del><tt>U1</tt> is implicitly convertible
|
|
to <tt>T0</tt> and <tt>U2</tt> is implicitly convertible to <tt>T1</tt></del><ins><tt>sizeof...(Types) == 2
|
|
&& is_constructible<T0, U1>::value && is_constructible<T1, U2>::value &&
|
|
is_convertible<U1, T0>::value && is_convertible<U2, T1>::value</tt> is true</ins>.
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2318"></a>2318. <tt>basic_string</tt>'s wording has confusing relics from the copy-on-write era</h3>
|
|
<p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-09-21 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#basic.string">issues</a> in [basic.string].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
21.4.4 [string.capacity]/8 specifies <tt>basic_string::resize(n, c)</tt> with:
|
|
</p>
|
|
<blockquote><p>
|
|
<i>Effects:</i> Alters the length of the string designated by <tt>*this</tt> as follows:
|
|
</p>
|
|
<ul>
|
|
<li><p>
|
|
If <tt>n <= size()</tt>, the function replaces the string designated by <tt>*this</tt> with a string of length <tt>n</tt> whose
|
|
elements are a copy of the initial elements of the original string designated by <tt>*this</tt>.
|
|
</p>
|
|
</li>
|
|
<li><p>
|
|
If <tt>n > size()</tt>, the function replaces the string designated by <tt>*this</tt> with a string of length <tt>n</tt> whose
|
|
first <tt>size()</tt> elements are a copy of the original string designated by <tt>*this</tt>, and whose remaining elements are all
|
|
initialized to <tt>c</tt>.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
</blockquote>
|
|
<p>
|
|
This wording is a relic of the copy-on-write era. In addition to being extremely confusing, it has undesirable implications.
|
|
Saying "replaces the string designated by <tt>*this</tt> with a string of length <tt>n</tt> whose elements are a copy" suggests
|
|
that the trimming case can reallocate. Reallocation during trimming should be forbidden, like <tt>vector</tt>.
|
|
<p/>
|
|
At least 7 paragraphs are affected: 21.4.4 [string.capacity]/8, 21.4.6.2 [string::append]/9,
|
|
21.4.6.3 [string::assign]/3 and /10, 21.4.6.4 [string::insert]/11, 21.4.6.5 [string::erase]/4, and
|
|
21.4.6.6 [string::replace]/11 say "replaces the string [designated/controlled] by <tt>*this</tt>". (21.4.6.7 [string::copy]/3
|
|
is different — it "replaces the string designated by <tt>s</tt>".)
|
|
<p/>
|
|
Of the affected paragraphs, <tt>resize()</tt> and <tt>erase()</tt> are the most important to fix because they should forbid
|
|
reallocation during trimming.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2321"></a>2321. Moving containers should (usually) be required to preserve iterators</h3>
|
|
<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-09-21 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
23.2.1 [container.requirements.general]/10 says that unless otherwise specified, "no <tt>swap()</tt> function invalidates
|
|
any references, pointers, or iterators referring to the elements of the containers being swapped. [<i>Note:</i> The <tt>end()</tt>
|
|
iterator does not refer to any element, so it may be invalidated. — <i>end note</i>]". However, move constructors and move
|
|
assignment operators aren't given similar invalidation guarantees. The guarantees need several exceptions, so I do not believe
|
|
that blanket language like /11 "Unless otherwise specified (either explicitly or by defining a function in terms of other functions),
|
|
invoking a container member function or passing a container as an argument to a library function shall not invalidate iterators to,
|
|
or change the values of, objects within that container." is applicable.
|
|
</p>
|
|
|
|
<p><i>[2014-02-13 Issaquah]</i></p>
|
|
|
|
<p>
|
|
General agreeement on intent, several wording nits and additional paragraphs to hit.
|
|
</p>
|
|
<p>
|
|
STL to provide updated wording. Move to Open.
|
|
</p>
|
|
|
|
<p><i>[2015-02, Cologne]</i></p>
|
|
|
|
<p>
|
|
AM: in the proposed wording, I'd like to mention that the iterators now refer to elements of a different container.
|
|
I think we're saying something like this somewhere. JY: There's some wording like that for swap I think. TK: It's also in
|
|
<tt>list::splice()</tt>. DK to JY: 23.2.1p9.
|
|
<p/>
|
|
VV: The issue says that STL was going to propose new wording. Has he done that? AM: I believe we're looking at that.
|
|
GR: The request touches on multiple paragraphs, and this PR has only one new paragraph, so this looks like it's not up-to-date.
|
|
MC: This was last updated a year ago in Issaquah.
|
|
<p/>
|
|
<b>Conclusion</b>: Skip, not up to date.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3691.</p>
|
|
|
|
<ol>
|
|
<li><p>In 23.2.1 [container.requirements.general]/10 change as indicated:</p>
|
|
|
|
<blockquote><p>
|
|
-10- Unless otherwise specified (see 23.2.4.1, 23.2.5.1, 23.3.3.4, and 23.3.7.5) all container types defined in this
|
|
Clause meet the following additional requirements:
|
|
</p>
|
|
<ul>
|
|
<li><p>
|
|
[…]
|
|
</p></li>
|
|
<li><p>
|
|
no copy constructor or assignment operator of a returned iterator throws an exception.
|
|
</p></li>
|
|
<li><p>
|
|
<ins>no move constructor (or move assignment operator when
|
|
<tt>allocator_traits<allocator_type>::propagate_on_container_move_assignment::value</tt> is true) of a container
|
|
(except for <tt>array</tt>) invalidates any references, pointers, or iterators referring to the elements of the source container.
|
|
[<i>Note:</i> The <tt>end()</tt> iterator does not refer to any element, so it may be invalidated. — <i>end note</i>]</ins>
|
|
</p></li>
|
|
<li><p>
|
|
no <tt>swap()</tt> function throws an exception.
|
|
</p></li>
|
|
<li><p>
|
|
no <tt>swap()</tt> function invalidates any references, pointers, or iterators referring to the elements of the
|
|
containers being swapped. [<i>Note:</i> The <tt>end()</tt> iterator does not refer to any element, so it may be
|
|
invalidated. — <i>end note</i>]
|
|
</p></li>
|
|
</ul>
|
|
</blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2326"></a>2326. <tt>uniform_int_distribution<unsigned char></tt> should be permitted</h3>
|
|
<p><b>Section:</b> 26.5.1.1 [rand.req.genl] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-09-21 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
26.5.1.1 [rand.req.genl]/1 says: "Throughout this subclause 26.5, the effect of instantiating a template [...] that has a
|
|
template type parameter named <tt>IntType</tt> is undefined unless the corresponding template argument is <i>cv</i>-unqualified
|
|
and is one of <tt>short</tt>, <tt>int</tt>, <tt>long</tt>, <tt>long long</tt>, <tt>unsigned short</tt>, <tt>unsigned int</tt>,
|
|
<tt>unsigned long</tt>, or <tt>unsigned long long</tt>." 26.5.8.2.1 [rand.dist.uni.int] specifies
|
|
<tt>template<class IntType = int> class uniform_int_distribution</tt>, so this forbids
|
|
<tt>uniform_int_distribution<char/signed char/unsigned char></tt>.
|
|
<p/>
|
|
I am not aware of anything in <tt><random></tt> that works with 16-bit integers but fails with 8-bit integers, so I suspect
|
|
that <tt>IntType</tt> and <tt>UIntType</tt> could simply be extended to permit the <tt>char</tt> family. Alternatively, this
|
|
change could be limited to <tt>uniform_int_distribution</tt> alone, where it is definitely safe. A <tt><random></tt> expert
|
|
should decide which change is best.
|
|
</p>
|
|
|
|
<p><i>[2015-04-04 Geoffrey provides wording]</i></p>
|
|
|
|
<p>
|
|
I think it's time to call the question; it's just silly that we have a random number library with no natural way to generate
|
|
random bytes. However, I don't think it's sufficient to fix only <tt>uniform_int_distribution</tt>, or even all of <tt>IntType</tt>.
|
|
At a bare minimum we need to also fix <tt>independent_bits_engine</tt> (arguably the cleanest way of generating a random byte)
|
|
and that's specified in terms of <tt>UIntType</tt>.
|
|
<p/>
|
|
The wording provided below is equivalent to adding <tt>unsigned char</tt> to item "f" and adding <tt>signed char</tt> and
|
|
<tt>unsigned char</tt> to item "e". That means it still excludes <tt>char</tt>, but I'm OK with that. If you want to generate
|
|
a 1-byte number, you should probably pick a signedess, and if you want to generate a raw byte, the "true" raw byte type is
|
|
<tt>unsigned char</tt>. This also excludes extended integral types and wide char types, which seem like nice-to-haves at best.
|
|
I have no objection to supporting any of those types; I just picked this to simplify the wording and hopefully maximize consensus.
|
|
Note that if we want to broaden <tt>IntType</tt> to permit any integral type, we'll need to decide if we want to exclude <tt>bool</tt>.
|
|
<p/>
|
|
For reference, <tt>IntType</tt> is used as a parameter of the following templates:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
uniform_int_distribution
|
|
binomial_distribution
|
|
geometric_distribution
|
|
negative_binomial_distribution
|
|
poisson_distribution
|
|
discrete_distribution
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
and <tt>UIntType</tt> is used as a parameter of the following templates:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
linear_congruential_engine
|
|
mersenne_twister_engine
|
|
subtract_with_carry_engine
|
|
independent_bits_engine
|
|
</pre>
|
|
</blockquote>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N4296.</p>
|
|
|
|
<ol>
|
|
<li><p>Change in 26.5.1.1 [rand.req.genl] p1 as indicated:</p>
|
|
|
|
<p>
|
|
-1- Throughout this subclause 26.5, the effect of instantiating a template:
|
|
</p>
|
|
<ol style="list-style-type:lower-alpha;" start="4">
|
|
<li><p>[…]</p></li>
|
|
<li><p>that has a template type parameter named <tt>IntType</tt> is undefined unless the corresponding template
|
|
argument is cv-unqualified and is <ins>a standard integer type (3.9.1 [basic.fundamental])</ins><del>one of
|
|
<tt>short</tt>, <tt>int</tt>, <tt>long</tt>, <tt>long long</tt>, <tt>unsigned short</tt>, <tt>unsigned int</tt>,
|
|
<tt>unsigned long</tt>, or <tt>unsigned long long</tt></del>.</p></li>
|
|
<li><p>that has a template type parameter named <tt>UIntType</tt> is undefined unless the corresponding template
|
|
argument is cv-unqualified and is <ins>a standard unsigned integer type (3.9.1 [basic.fundamental])</ins><del>one
|
|
of <tt>unsigned short</tt>, <tt>unsigned int</tt>, <tt>unsigned long</tt>, or <tt>unsigned long long</tt></del>.</p></li>
|
|
</ol>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2328"></a>2328. Rvalue stream extraction should use perfect forwarding</h3>
|
|
<p><b>Section:</b> 27.7.2.6 [istream.rvalue] <b>Status:</b> <a href="lwg-active.html#Review">Review</a>
|
|
<b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-09-21 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#istream.rvalue">active issues</a> in [istream.rvalue].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#istream.rvalue">issues</a> in [istream.rvalue].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Review">Review</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
27.7.2.6 [istream.rvalue] declares <tt>operator>>(basic_istream<charT, traits>&& is, T& x)</tt>.
|
|
However, 27.7.2.2.3 [istream::extractors]/7 declares <tt>operator>>(basic_istream<charT,traits>& in, charT* s)</tt>,
|
|
plus additional overloads for <tt>unsigned char*</tt> and <tt>signed char*</tt>. This means that
|
|
"<tt>return_rvalue_istream() >> &arr[0]</tt>" won't compile, because <tt>T&</tt> won't bind to the rvalue <tt>&arr[0]</tt>.
|
|
</p>
|
|
|
|
<p><i>[2014-02-12 Issaquah : recategorize as P3]</i></p>
|
|
|
|
|
|
<p>
|
|
Jonathan Wakely: Bill was certain the change is right, I think so with less certainty
|
|
</p>
|
|
|
|
<p>
|
|
Jeffrey Yaskin: I think he's right, hate that we need this
|
|
</p>
|
|
|
|
<p>
|
|
Jonathan Wakely: is this the security issue Jeffrey raised on lib reflector?
|
|
</p>
|
|
|
|
<p>
|
|
Move to P3
|
|
</p>
|
|
|
|
<p><i>[2015-05-06 Lenexa: Move to Review]</i></p>
|
|
|
|
|
|
<p>WEB, MC: Proposed wording changes one signature (in two places) to take a forwarding reference.</p>
|
|
<p>TK: Should be consistent with an istream rvalue?</p>
|
|
<p>MC: This is the case where you pass the stream by rvalue reference.</p>
|
|
<p>RP: I would try it before standardizing.</p>
|
|
<p>TK: Does it break anything?</p>
|
|
<p>RP, TK: It will take all arguments, will be an exact match for everything.</p>
|
|
<p>RS, TK: This adapts streaming into an rvalue stream to make it act like streaming into an lvalue stream.</p>
|
|
<p>RS: Should this really return the stream by lvalue reference instead of by rvalue reference? => new LWG issue.</p>
|
|
<p>RP: Security issue?</p>
|
|
<p>MC: No. That's istream >> char*, C++ version of gets(). Remove it, as we did for gets()? => new LWG issue.</p>
|
|
<p>RS: Proposed resolution looks correct to me.</p>
|
|
<p>MC: Makes me (and Jonathan Wakely) feel uneasy.</p>
|
|
<p>Move to Review, consensus.</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3691.</p>
|
|
|
|
<ol>
|
|
<li><p>Edit 27.7.1 [iostream.format.overview], header <tt><istream></tt> synopsis, as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
namespace std {
|
|
[…]
|
|
template <class charT, class traits, class T>
|
|
basic_istream<charT, traits>&
|
|
operator>>(basic_istream<charT, traits>&& is, T&<ins>&</ins> x);
|
|
}
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li><p>Edit 27.7.2.6 [istream.rvalue] as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
template <class charT, class traits, class T>
|
|
basic_istream<charT, traits>&
|
|
operator>>(basic_istream<charT, traits>&& is, T&<ins>&</ins> x);
|
|
</pre><blockquote>
|
|
<p>
|
|
-1- <i>Effects:</i> <tt>is >><del>x</del> <ins>std::forward<T>(x)</ins></tt>
|
|
<p/>
|
|
-2- <i>Returns:</i> <tt>is</tt>
|
|
</p>
|
|
</blockquote></blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2331"></a>2331. <tt>regex_constants::collate</tt>'s effects are inaccurately summarized</h3>
|
|
<p><b>Section:</b> 28.5.1 [re.synopt] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-09-21 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#re.synopt">active issues</a> in [re.synopt].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#re.synopt">issues</a> in [re.synopt].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The table in 28.5.1 [re.synopt]/1 says that <tt>regex_constants::collate</tt> "Specifies that character ranges of the form
|
|
"<tt>[a-b]</tt>" shall be locale sensitive.", but 28.13 [re.grammar]/14 says that it affects individual character comparisons
|
|
too.
|
|
</p>
|
|
|
|
<p><i>[2012-02-12 Issaquah : recategorize as P3]</i></p>
|
|
|
|
|
|
<p>
|
|
Marshall Clow: 28.13/14 only applies to ECMAScript
|
|
</p>
|
|
|
|
<p>
|
|
All: we're unsure
|
|
</p>
|
|
|
|
<p>
|
|
Jonathan Wakely: we should ask John Maddock
|
|
</p>
|
|
|
|
<p>
|
|
Move to P3
|
|
</p>
|
|
|
|
<p><i>[2014-5-14, John Maddock response]</i></p>
|
|
|
|
<p>
|
|
The original intention was the original wording: namely that <tt>collate</tt> only made character ranges locale sensitive.
|
|
To be frank it's a feature that's probably hardly ever used (though I have no real hard data on that), and is a leftover
|
|
from early POSIX standards which <em>required</em> locale sensitive collation for character ranges, and then later changed
|
|
to implementation defined if I remember correctly (basically nobody implemented locale-dependent collation).
|
|
<p/>
|
|
So I guess the question is do we gain anything by requiring all character-comparisons to go through the locale when this bit
|
|
is set? Certainly it adds a great deal to the implementation effort (it's not what Boost.Regex has ever done). I guess the
|
|
question is are differing code-points that collate identically an important use case? I guess there might be a few Unicode
|
|
code points that do that, but I don't know how to go about verifying that.
|
|
<p/>
|
|
STL:
|
|
<p/>
|
|
If this was unintentional, then 28.5.1 [re.synopt]/1's table should be left alone, while 28.13 [re.grammar]/14
|
|
should be changed instead.
|
|
<p/>
|
|
Jeffrey Yasskin:
|
|
<p/>
|
|
<a href="http://www.unicode.org/reports/tr18/tr18-13.html#Tailored_Loose_Matches">This page</a>
|
|
mentions that [V] in Swedish should match "W" in a perfect world.
|
|
<p/>
|
|
However, the most recent version of <a href="http://www.unicode.org/reports/tr18/#Tailored_Loose_Matches">TR18</a> retracts
|
|
both language-specific loose matches <em>and</em> language-specific ranges
|
|
because "for most full-featured regular expression engines, it is
|
|
quite difficult to match under code point equivalences that are not
|
|
1:1" and "tailored ranges can be quite difficult to implement
|
|
properly, and can have very unexpected results in practice. For
|
|
example, languages may also vary whether they consider lowercase below
|
|
uppercase or the reverse. This can have some surprising results: [a-Z]
|
|
may not match anything if <tt>Z < a</tt> in that locale."
|
|
<p/>
|
|
<a href="http://www.ecma-international.org/ecma-262/5.1/#sec-15.10.2.15">ECMAScript</a> doesn't include collation at all.
|
|
<p/>
|
|
IMO, +1 to changing 28.13 instead of 28.5.1. It seems like we'd be on
|
|
fairly solid ground if we wanted to remove <tt>regex_constants::collate</tt>
|
|
entirely, in favor of named character classes, but of course that's
|
|
not for this issue.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3691.</p>
|
|
|
|
<ol>
|
|
<li><p>In 28.5.1 [re.synopt]/1, Table 138 — "<tt>syntax_option_type</tt> effects", change as indicated:</p>
|
|
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 138 — <tt>syntax_option_type</tt> effects</caption>
|
|
<tr>
|
|
<th align="center">Element</th>
|
|
<th align="center">Effect(s) if set</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="2" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>collate</tt>
|
|
</td>
|
|
<td>
|
|
Specifies that character <del>ranges of the form "<tt>[a-b]</tt>"</del><ins>comparisons and character range comparisons</ins>
|
|
shall be locale sensitive.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="2" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2334"></a>2334. <tt>atomic</tt>'s default constructor requires "uninitialized" state even for types with non-trivial default-constructor</h3>
|
|
<p><b>Section:</b> 29.6.5 [atomics.types.operations.req] <b>Status:</b> <a href="lwg-active.html#SG1">SG1</a>
|
|
<b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2013-10-03 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#atomics.types.operations.req">active issues</a> in [atomics.types.operations.req].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#atomics.types.operations.req">issues</a> in [atomics.types.operations.req].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#SG1">SG1</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
According to 29.6.5 [atomics.types.operations.req] p4,
|
|
</p>
|
|
<blockquote><pre>
|
|
A ::A () noexcept = default;
|
|
</pre><blockquote>
|
|
<p>
|
|
<i>Effects:</i> leaves the atomic object in an uninitialized state. [<i>Note:</i> These semantics ensure compatibility
|
|
with <tt>C</tt>. — <i>end note</i>]
|
|
</p>
|
|
</blockquote></blockquote>
|
|
<p>
|
|
This implementation requirement is OK for POD types, like <tt>int</tt>, but 29.5 [atomics.types.generic] p1
|
|
intentionally allows template arguments of <tt>atomic</tt> with a non-trivial default constructor ("The type of the template argument
|
|
<tt>T</tt> shall be trivially copyable (3.9)"), so this wording can be read in a way that makes the behaviour of the following code
|
|
undefined:
|
|
</p>
|
|
<blockquote><pre>
|
|
#include <atomic>
|
|
#include <iostream>
|
|
|
|
struct S {
|
|
S() noexcept : v(42) {}
|
|
int v;
|
|
};
|
|
|
|
int main() {
|
|
std::atomic<S> as; // Default-initialization
|
|
std::cout << as.load().v << std::endl; // ?
|
|
}
|
|
</pre></blockquote>
|
|
<p>
|
|
For a user-defined emulation of <tt>atomic</tt> the expected outcome would be defined and the program would output "42",
|
|
but existing implementations differ and the result value is a "random number" for at least one implementation. This seems
|
|
very surprising to me.
|
|
<p/>
|
|
To realize that seemingly existing requirement, an implementation is either required to violate normal language rules internally
|
|
or to perform specific bit-randomization-techniques after the normal default-initialization that called the default constructor
|
|
of <tt>S</tt>.
|
|
<p/>
|
|
According to my understanding, the non-normative note in 29.6.5 [atomics.types.operations.req] p4 is intended to
|
|
refer to types that are valid <tt>C</tt>-types, but the example type <tt>S</tt> is not such a type.
|
|
<p/>
|
|
To make the mental model of <tt>atomic</tt>'s default constructor more intuitive for user-code, I suggest to clarify the wording
|
|
to have the effects of default-initialization instead. The current state seems more like an unintended effect of imprecise
|
|
language used here and has some similarities to wording that was incorrectly used to specify <tt>atomic_flag</tt> initialization
|
|
as described by LWG <a href="lwg-defects.html#2159">2159</a>.
|
|
</p>
|
|
|
|
<p><i>[2014-05-17, Daniel comments and provides alternative wording]</i></p>
|
|
|
|
|
|
<p>
|
|
The current wording was considered controversial as expressed by reflector discussions. To me, the actual problem is not newly
|
|
introduced by that wording, but instead is already present in basically all paragraphs specifying semantics of atomic types,
|
|
since the wording never clearly distinguishes the value of the actual atomic type <i>A</i> and the value of the "underlying",
|
|
corresponding non-atomic type <i>C</i>. The revised proposed wording attempts to improve the current ambiguity of these two
|
|
kinds of values.
|
|
</p>
|
|
|
|
<strong>Previous resolution from Daniel [SUPERSEDED]:</strong>
|
|
<p/>
|
|
<blockquote class="note">
|
|
<p>This wording is relative to N3691.</p>
|
|
|
|
<ol>
|
|
<li><p>Modify 29.6.5 [atomics.types.operations.req] p4 as indicated: <em>[Editorial note: There is no exposition-only
|
|
member in <tt>atomic</tt>, which makes it a bit hard to specify what actually is initialized, but the usage of the term "value"
|
|
seems consistent with similar wording used to specify the effects of the atomic <tt>load</tt> functions]</em></p>
|
|
|
|
<blockquote><pre>
|
|
A ::A () noexcept = default;
|
|
</pre><blockquote>
|
|
<p>
|
|
-4- <i>Effects:</i> <del>leaves the atomic object in an uninitialized state</del><ins>The value of the atomic object
|
|
is default-initialized (8.5 [dcl.init])</ins>. [<i>Note:</i> These semantics ensure compatibility
|
|
with <tt>C</tt>. — <i>end note</i>]
|
|
</p>
|
|
</blockquote></blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
</blockquote>
|
|
|
|
<p><i>[2015-02 Cologne]</i></p>
|
|
|
|
<p>
|
|
Handed over to SG1.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Modify 29.6.5 [atomics.types.operations.req] p2 as indicated: <em>[Editorial note: This is a near-to editorial
|
|
change not directly affecting this issue, but <tt>atomic_address</tt> does no longer exist and the pointed to definition is
|
|
relevant in the context of this issue resolution.]</em>
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
-2- In the following operation definitions:
|
|
</p>
|
|
<ul>
|
|
<li><p>an <i>A</i> refers to one of the atomic types.</p></li>
|
|
<li><p>a <i>C</i> refers to its corresponding non-atomic type. <del>The <tt>atomic_address</tt> atomic type corresponds to the
|
|
<tt>void*</tt> non-atomic type.</del></p></li>
|
|
<li><p>[…]</p></li>
|
|
</ul>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Modify 29.6.5 [atomics.types.operations.req] p4 and the following as indicated: <em>[Editorial note: There
|
|
is no exposition-only member in <tt>atomic</tt>, which makes it a bit hard to specify what actually is initialized, but
|
|
the introductory wording of 29.6.5 [atomics.types.operations.req] p2 b2 defines: "a <i>C</i> refers to its
|
|
corresponding non-atomic type." which helps to specify the semantics in terms of "the <i>C</i> value referred to by the
|
|
atomic object"]</em></p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
<i>A</i>::<i>A</i>() noexcept = default;
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-4- <i>Effects:</i> <del>leaves the atomic object in an uninitialized state</del><ins>Default-initializes (8.5 [dcl.init])
|
|
the <i>C</i> value referred to by the atomic object</ins>. [<i>Note:</i> These semantics ensure compatibility with <tt>C</tt>.
|
|
— <i>end note</i>]
|
|
</p>
|
|
</blockquote>
|
|
|
|
<pre>
|
|
constexpr <i>A</i>::<i>A</i>(<i>C</i> desired) noexcept;
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-5- <i>Effects:</i> <ins>Direct-i</ins><del>I</del>nitializes the <ins><i>C</i> value referred to by the atomic</ins> object
|
|
with the value <tt>desired</tt>. Initialization is not an atomic operation (1.10). […]
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
</blockquote>
|
|
|
|
<pre>
|
|
void atomic_init(volatile <i>A</i>* object, <i>C</i> desired) noexcept;
|
|
void atomic_init(<i>A</i>* object, <i>C</i> desired) noexcept;
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-8- <i>Effects:</i> Non-atomically initializes <ins>the <i>C</i> value referred to by</ins> <tt>*object</tt> with value
|
|
<tt>desired</tt>. […]
|
|
</p>
|
|
</blockquote>
|
|
|
|
<pre>
|
|
void atomic_store(volatile <i>A</i>* object, <i>C</i> desired) noexcept;
|
|
[…]
|
|
void <i>A</i>::store(<i>C</i> desired, memory_order order = memory_order_seq_cst) noexcept;
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-9- […]
|
|
<p/>
|
|
-10- <i>Effects:</i> Atomically replaces the <ins><i>C</i></ins> value pointed to by
|
|
<tt>object</tt> or by <tt>this</tt> with the value of <tt>desired</tt>. […]
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
</blockquote>
|
|
|
|
<pre>
|
|
<i>C</i> atomic_load(const volatile <i>A</i>* object) noexcept;
|
|
[…]
|
|
<i>C</i> <i>A</i>::load(memory_order order = memory_order_seq_cst) const noexcept;
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-13- […]
|
|
<p/>
|
|
-14- […]
|
|
<p/>
|
|
-15- <i>Returns:</i> Atomically returns the <ins><i>C</i></ins> value pointed to by <tt>object</tt> or by <tt>this</tt>.
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
</blockquote>
|
|
|
|
<pre>
|
|
<i>C</i> atomic_exchange(volatile <i>A</i>* object, C desired) noexcept;
|
|
[…]
|
|
<i>C</i> <i>A</i>::exchange(C desired, memory_order order = memory_order_seq_cst) noexcept;
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-18- <i>Effects</i>: Atomically replaces the <ins><i>C</i></ins> value pointed to by <tt>object</tt> or by <tt>this</tt> with <tt>desired</tt>. […]
|
|
<p/>
|
|
-19- <i>Returns:</i> Atomically returns the <ins><i>C</i></ins> value pointed to by <tt>object</tt> or by <tt>this</tt>
|
|
immediately before the effects.
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
</blockquote>
|
|
|
|
<pre>
|
|
<i>C</i> atomic_fetch_key(volatile <i>A</i>* object, <i>M</i> operand) noexcept;
|
|
[…]
|
|
<i>C</i> <i>A</i>::fetch_key(<i>M</i> operand, memory_order order = memory_order_seq_cst) noexcept;
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-28- <i>Effects</i>: Atomically replaces the <ins><i>C</i></ins> value pointed to by <tt>object</tt> or by <tt>this</tt> with
|
|
the result of the computation applied to the <ins><i>C</i></ins> value pointed to by <tt>object</tt> or by <tt>this</tt> and
|
|
the given <tt>operand</tt>. […]
|
|
<p/>
|
|
-29- <i>Returns:</i> Atomically<del>,</del> <ins>returns</ins> the <ins><i>C</i></ins> value pointed to by <tt>object</tt>
|
|
or by <tt>this</tt> immediately before the effects.
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
</blockquote>
|
|
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Modify 29.7 [atomics.flag] p5 and the following as indicated:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
bool atomic_flag_test_and_set(volatile atomic_flag* object) noexcept;
|
|
[…]
|
|
bool atomic_flag::test_and_set(memory_order order = memory_order_seq_cst) noexcept;
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-5- <i>Effects</i>: Atomically sets the <ins>bool</ins> value pointed to by <tt>object</tt> or by <tt>this</tt> to <tt>true</tt>.
|
|
[…]
|
|
<p/>
|
|
-6- <i>Returns</i>: Atomically<del>,</del> <ins>returns</ins> the <ins>bool</ins> value <del>of the</del><ins>pointed
|
|
to by</ins> <tt>object</tt> <ins>or by <tt>this</tt></ins> immediately before the effects.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<pre>
|
|
void atomic_flag_clear(volatile atomic_flag* object) noexcept;
|
|
[…]
|
|
void atomic_flag::clear(memory_order order = memory_order_seq_cst) noexcept;
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-7- […]
|
|
<p/>
|
|
-8- <i>Effects</i>: Atomically sets the <ins>bool</ins> value pointed to by <tt>object</tt> or by <tt>this</tt> to <tt>false</tt>.
|
|
[…]
|
|
</p>
|
|
</blockquote>
|
|
|
|
</blockquote>
|
|
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2335"></a>2335. <tt>array<array<int, 3>, 4></tt> should be layout-compatible with <tt>int[4][3]</tt></h3>
|
|
<p><b>Section:</b> 23.3.2 [array] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2013-10-04 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#array">active issues</a> in [array].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#array">issues</a> in [array].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
In order to replace some uses of C arrays with <tt>std::array</tt>, we need it
|
|
to be possible to cast from a <tt>std::array<></tt> to an equivalent C array.
|
|
Core wording doesn't appear to be in quite the right state to allow
|
|
casting, but if we specify that appropriate types are
|
|
layout-compatible, we can at least write:
|
|
</p>
|
|
<blockquote><pre>
|
|
union {
|
|
array<array<array<int, 2>, 3>, 4> arr;
|
|
int carr[4][3][2];
|
|
};
|
|
</pre></blockquote>
|
|
<p>
|
|
to view memory as the other type: C++14 CD [class.mem]p18.
|
|
</p>
|
|
I believe it's sufficient to add "<tt>array<T, N></tt> shall be
|
|
layout-compatible (3.9 [basic.types]) with <tt>T[N]</tt>." to
|
|
23.3.2.1 [array.overview], but we might also need some extension to
|
|
9.2 [class.mem] to address the possibility of layout-compatibility
|
|
between struct and array types.
|
|
<p>
|
|
I checked that libc++ on MacOS already implements this, although it
|
|
would be good for someone else to double-check; I haven't checked any
|
|
other standard libraries.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2336"></a>2336. <tt>is_trivially_constructible/is_trivially_assignable</tt> traits are always false</h3>
|
|
<p><b>Section:</b> 20.10.4.3 [meta.unary.prop] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2013-10-01 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
In 20.10.4.3 [meta.unary.prop] we have traits to allow testing for triviality of specific operations, such as
|
|
<tt>is_trivially_constructible</tt> and <tt>is_trivially_assignable</tt> (and their derived forms), which are specified
|
|
in terms of the following initialization and assignment, respectively:
|
|
</p>
|
|
<blockquote><pre>
|
|
T t(create<Args>()...);
|
|
|
|
declval<T>() = declval<U>()
|
|
</pre></blockquote>
|
|
<p>
|
|
The wording that describes the way how triviality is deduced, is in both cases of the same form:
|
|
</p>
|
|
<blockquote><p>
|
|
[… ] and the variable definition/assignment, as defined by <tt>is_constructible/is_assignable</tt>, is known
|
|
to call no operation that is not trivial (3.9, 12).
|
|
</p></blockquote>
|
|
<p>
|
|
The problematic part of this wording is that both definitions are specified in terms of an "object construction" function
|
|
<tt>create</tt> or <tt>declval</tt>, respectively, (The former being a conceptual function, the latter being a library function),
|
|
but for none of these functions we can assume that they could be considered as trivial — only special member functions can
|
|
have this property and none of these is one. This problem became obvious, when the similar issue LWG <a href="lwg-defects.html#2298">2298</a>
|
|
in regard to <tt>is_nothrow_constructible</tt> was opened.
|
|
<p/>
|
|
A possible approach to solve this specification problem is to make a blanket statement for sub-clause 20.10.4.3 [meta.unary.prop]
|
|
that these helper functions are considered trivial for the purpose of defining these traits.
|
|
<p/>
|
|
Using this kind of wording technique can also be used to get rid of the additional helper function template <tt>create</tt>, which
|
|
is currently needed for the <tt>is_convertible</tt> and the <tt>is_constructible</tt> traits, because both traits are specified in
|
|
terms of contexts where technically the corresponding "object construction" function would be considered as odr-used. This is problematic,
|
|
because these traits are defined in terms of well-formed code and odr-using <tt>declval</tt> would make the program ill-formed (see
|
|
20.2.5 [declval]). So extending above blanket statement to consider <tt>std::declval<T>()</tt> as not odr-used
|
|
in the context of the corresponding trait definition would allow for replacing <tt>create</tt> by <tt>declval</tt>.
|
|
</p>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
STL: would you consider moving the change to 20.10 as editorial or are you uncomfortable with it?<br/>
|
|
JW: this sounds a viable editorial change<br/>
|
|
VV: I guarantee you that moving it doesn't change anything<br/>
|
|
MC: how about this: we move it to Ready as is and if we conclude moving it is editorial we can do it and if not open an issue<br/>
|
|
STL: I would like to guarantee that the lifting happens<br/>
|
|
JW: I do that! If it goes in I move it up<br/>
|
|
MC: move to Ready: in favor: 15, opposed: 0, abstain: 1
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Add a new paragraph after 20.10.4.3 [meta.unary.prop] p3 as indicated: <em>[Editorial note: The first change in
|
|
20.10.4.3 [meta.unary.prop] p3 is recommended, because technically a Clause is always a "main chapter" — such as
|
|
Clause 20 — but every child of a Clause or sub-clause is a sub-clause]</em></p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
[…]
|
|
<p/>
|
|
-3- For all of the class templates <tt>X</tt> declared in this <del>Clause</del><ins>sub-clause</ins>, instantiating that
|
|
template with a template-argument that is a class template specialization may result in the implicit instantiation of the
|
|
template argument if and only if the semantics of <tt>X</tt> require that the argument must be a complete type.
|
|
<p/>
|
|
<ins>-?- For the purpose of defining the templates in this sub-clause, a function call expression
|
|
<tt>declval<T>()</tt> for any type <tt>T</tt> is considered to be a trivial (3.9 [basic.types], 12 [special])
|
|
function call that is not an odr-use (3.2 [basic.def.odr]) of <tt>declval</tt> in the context of the corresponding definition
|
|
notwithstanding the restrictions of 20.2.5 [declval].</ins>
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Modify 20.10.4.3 [meta.unary.prop] p7 as indicated:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-7- <del>Given the following function prototype:</del>
|
|
</p>
|
|
<blockquote><pre>
|
|
<del>template <class T>
|
|
typename add_rvalue_reference<T>::type create();</del>
|
|
</pre></blockquote>
|
|
<p>
|
|
<del>t</del><ins>T</ins>he predicate condition for a template specialization <tt>is_constructible<T, Args...></tt>
|
|
shall be satisfied if and only if the following variable definition would be well-formed for some invented variable <tt>t</tt>:
|
|
</p>
|
|
<blockquote><pre>
|
|
T t(<del>create</del><ins>declval</ins><Args>()...);
|
|
</pre></blockquote>
|
|
<p>
|
|
[…]
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Add a new paragraph after 20.10.6 [meta.rel] p2 as indicated: <em>[Editorial note: Technically we don't need
|
|
the guarantee of "a trivial function call" for the type relationship predicates at the very moment, but it seems more robust and
|
|
consistent to have the exact same guarantee here as well]</em>
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
[…]
|
|
<p/>
|
|
-2- […]
|
|
<p/>
|
|
<ins>-?- For the purpose of defining the templates in this sub-clause, a function call expression
|
|
<tt>declval<T>()</tt> for any type <tt>T</tt> is considered to be a trivial (3.9 [basic.types], 12 [special])
|
|
function call that is not an odr-use (3.2 [basic.def.odr]) of <tt>declval</tt> in the context of the corresponding definition
|
|
notwithstanding the restrictions of 20.2.5 [declval].</ins>
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Modify 20.10.6 [meta.rel] p4 as indicated:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-4- <del>Given the following function prototype:</del>
|
|
</p>
|
|
<blockquote><pre>
|
|
<del>template <class T>
|
|
typename add_rvalue_reference<T>::type create();</del>
|
|
</pre></blockquote>
|
|
<p>
|
|
<del>t</del><ins>T</ins>he predicate condition for a template specialization <tt>is_convertible<From, To></tt>
|
|
shall be satisfied if and only if the return expression in the following code would be well-formed, including any implicit
|
|
conversions to the return type of the function:
|
|
</p>
|
|
<blockquote><pre>
|
|
To test() {
|
|
return <del>create</del><ins>declval</ins><From>();
|
|
}
|
|
</pre></blockquote>
|
|
<p>
|
|
[…]
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2337"></a>2337. <tt>shared_ptr operator*()</tt> should not be <tt>noexcept</tt></h3>
|
|
<p><b>Section:</b> 20.8.2.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="lwg-active.html#NAD">Tentatively NAD</a>
|
|
<b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-10-05 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#util.smartptr.shared.obs">issues</a> in [util.smartptr.shared.obs].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively NAD">Tentatively NAD</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
20.8.1.2.4 [unique.ptr.single.observers]/3: "<tt>pointer operator->() const noexcept;</tt> <i>Requires:</i> <tt>get() != nullptr</tt>."
|
|
<p/>
|
|
20.8.2.2.5 [util.smartptr.shared.obs]/2: "<tt>T& operator*() const noexcept;</tt> <i>Requires:</i> <tt>get() != 0</tt>."
|
|
<p/>
|
|
20.8.2.2.5 [util.smartptr.shared.obs]/5: "<tt>T* operator->() const noexcept;</tt> <i>Requires:</i> <tt>get() != 0</tt>."
|
|
<p/>
|
|
Narrow-contract functions should not be <tt>noexcept</tt>.
|
|
</p>
|
|
|
|
<p><i>[2014-02-15 Issaquah]</i></p>
|
|
|
|
<p>
|
|
Issue is contentious, raise to P2.
|
|
</p>
|
|
|
|
<p><i>[2015-02 Cologne]</i></p>
|
|
|
|
<p>
|
|
AM: This ship has sailed. JM: What's the issue? AM: <tt>operator-></tt> has narrow contract and should never have had
|
|
<tt>noexcept</tt>. DK: Not quite. We explicitly called out that for <tt>shared_ptr</tt> this is fine. You said so in your
|
|
"narrow contract" paper. GR: This would be a fairly major regression in the design of {<tt>unique</tt>,<tt>shared</tt>}<tt>_ptr</tt>
|
|
over raw pointers; raw pointer dereferencing is <tt>noexcept</tt>. It's not a performance regression but a usability regression.
|
|
AM: Do we expect users to query <tt>noexpect</tt> on dereference expressions? Room: Yes. VV: We don't just expect it, we have
|
|
seen it. JM: Yes, users may be querying something like <tt>noexcept(x->y)</tt> and expect to be checking <tt>y</tt>, but
|
|
silently end up checking <tt>x-></tt>.
|
|
<p/>
|
|
Close as NAD, with explanation from GR.
|
|
</p>
|
|
|
|
<strong>Previous resolution [SUPERSEDED]:</strong>
|
|
<blockquote class="note">
|
|
<p>This wording is relative to N3691.</p>
|
|
|
|
<ol>
|
|
<li><p>In 20.8.1.2 [unique.ptr.single]/1, class template <tt>unique_ptr</tt> synopsis for single objects, change as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
pointer operator->() const <del>noexcept</del>;
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li><p>In 20.8.1.2.4 [unique.ptr.single.observers] change as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
pointer operator->() const <del>noexcept</del>;
|
|
</pre><blockquote>
|
|
<p>
|
|
-3- <i>Requires:</i> <tt>get() != nullptr</tt>.
|
|
<p/>
|
|
-4- <i>Returns:</i> <tt>get()</tt>.
|
|
<p/>
|
|
<ins>-?- <i>Throws:</i> Nothing.</ins>
|
|
<p/>
|
|
-5- <i>Note:</i> use typically requires that <tt>T</tt> be a complete type.
|
|
</p>
|
|
</blockquote></blockquote>
|
|
</li>
|
|
|
|
<li><p>In 20.8.2.2 [util.smartptr.shared]/1, class template <tt>shared_ptr</tt> synopsis, change as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
T& operator*() const <del>noexcept</del>;
|
|
T* operator->() const <del>noexcept</del>;
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li><p>In 20.8.2.2.5 [util.smartptr.shared.obs] change as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
T& operator*() const <del>noexcept</del>;
|
|
</pre><blockquote>
|
|
<p>
|
|
-2- <i>Requires:</i> <tt>get() != 0</tt>.
|
|
<p/>
|
|
-3- <i>Returns:</i> <tt>*get()</tt>.
|
|
<p/>
|
|
<ins>-?- <i>Throws:</i> Nothing.</ins>
|
|
<p/>
|
|
-4- <i>Remarks:</i> When <tt>T</tt> is <tt>void</tt>, it is unspecified whether this member function is declared.
|
|
If it is declared, it is unspecified what its return type is, except that the declaration (although not necessarily the
|
|
definition) of the function shall be well formed.
|
|
</p>
|
|
</blockquote></blockquote>
|
|
|
|
<blockquote><pre>
|
|
T* operator->() const <del>noexcept</del>;
|
|
</pre><blockquote>
|
|
<p>
|
|
-5- <i>Requires:</i> <tt>get() != 0</tt>.
|
|
<p/>
|
|
-6- <i>Returns:</i> <tt>get()</tt>.
|
|
<p/>
|
|
<ins>-?- <i>Throws:</i> Nothing.</ins>
|
|
</p>
|
|
</blockquote></blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
</blockquote>
|
|
|
|
<p><i>[2015-03-03, Geoffrey provides rationale]</i></p>
|
|
|
|
<p>
|
|
<b>Rationale</b>:
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
It is by design that these members are <tt>noexcept</tt>, and changing that now would be a substantial regression in functionality.
|
|
These classes were designed to substitute for plain pointers as transparently as possible, so since those operations are effectively
|
|
<tt>noexcept</tt> on plain pointers, they should be <tt>noexcept</tt> on <tt>unique_ptr</tt> and <tt>shared_ptr</tt> as well.
|
|
This matters in practice because we expect these members to be used fairly often inside the <tt>noexcept</tt> operator, and such
|
|
code could be broken by this change. These design considerations override our general policy against <tt>noexcept</tt> for
|
|
narrow-contract functions.
|
|
<p/>
|
|
It is notable that N3279, which proposed this policy, did not propose striking <tt>noexcept</tt> from these operations. It's not
|
|
clear if the omission of <tt>operator*</tt> and <tt>operator-></tt> was an oversight, or an intentional reflection of the above
|
|
considerations. N3279 was based on N3248 by the same authors, which states that:
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
"Most applications of <tt>noexcept</tt> for <tt>unique_ptr</tt> and <tt>shared_ptr</tt> are on functions with wide contracts.
|
|
However, there are preconditions on the atomic access functions, so these should lose the specification."
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2338"></a>2338. [re.traits]/7 expects of locale facets something not guaranteed by [locale.facet]/4</h3>
|
|
<p><b>Section:</b> 28.7 [re.traits], 22.3.1.1.2 [locale.facet] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Sergey Zubkov <b>Opened:</b> 2013-10-15 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#re.traits">issues</a> in [re.traits].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
28.7 [re.traits]/7, begins with "if <tt>typeid(use_facet<collate<charT> >) == typeid(collate_byname<charT>)</tt>",
|
|
which appears to be pseudocode with the intention to convey that the collate facet has not been replaced by the user. Cf. the wording in
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1429.htm">N1429</a> "there is no portable way to implement
|
|
<tt>transform_primary</tt> in terms of <tt>std::locale</tt>, since even if the sort key format returned by
|
|
<tt>std::collate_byname<>::transform</tt> is known and can be converted into a primary sort key, the user can still
|
|
install their own custom <tt>std::collate</tt> implementation into the locale object used, and that can use any sort key
|
|
format they see fit.".
|
|
<p/>
|
|
Taken literally, 28.7 [re.traits]/7 appears to imply that named locales are required to hold their collate facets with
|
|
dynamic type <tt>std::collate_byname<charT></tt>, which is in fact true in some implementations (e.g libc++), but not others
|
|
(e.g. libstdc++). This does not follow from the description of <tt>_byname</tt> in 22.3.1.1.2 [locale.facet]/4, which is only
|
|
required to provide equivalent semantics, to the named locale's facet, not to actually be one.
|
|
</p>
|
|
|
|
|
|
<p><i>[2015-05-06 Lenexa: Move to Open]</i></p>
|
|
|
|
|
|
<p>MC, RP: Consequence of failing to follow the rule is UB.</p>
|
|
<p>MC: Tightening of requirements.</p>
|
|
<p>RP: It should be this way, we just didn't impose it before.</p>
|
|
<p>MC: Second change is a bug fix, original code didn't work.</p>
|
|
<p>TK: Doesn't seem to make things worse.</p>
|
|
<p>Bring up in larger group tomorrow.</p>
|
|
<p>JW arrives.</p>
|
|
<p>JW: libstdc++ violates this due to two std::string ABIs.</p>
|
|
<p>JW: This prevents installing a type derived from Facet_byname, constrains the implementor from using a smarter derived class version.</p>
|
|
<p>JW: Can't look at facet id to detect replacement, because replacements have the same id.</p>
|
|
<p>RP: Can you give it multiple ids through multiple inheritance?</p>
|
|
<p>JW: No, the facet mechanism wouldn't like that.</p>
|
|
<p>JW: We should also ask Martin Sebor, he's implemented this stuff recently.</p>
|
|
<p>MC: Sounds like this resolution doesn't work, need a better solution.</p>
|
|
<p>JW: Write in words "if the facet has not been replaced by the user", the implementation knows how to detect that, but not like this.</p>
|
|
<p>RP: User RE traits need to detect this too.</p>
|
|
<p>JW: =(</p>
|
|
<p>Move to Open, JW will invite Martin Sebor to join LWG for discussion.</p>
|
|
<p>Later ... </p>
|
|
<p>JW: This is not needed for user specializations after all.</p>
|
|
<p>MC: Agree, [re.traits]/7 only applies to the stdlib traits.</p>
|
|
<p>NM: Effects: doesn't make sense.</p>
|
|
<p>JW, NM, Martin Sebor to come up with new wording.</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3691.</p>
|
|
|
|
<ol>
|
|
<li><p>Modify 22.3.1.1.2 [locale.facet]/4 as indicated:</p>
|
|
|
|
<blockquote><p>
|
|
For some standard facets a standard "...<tt>_byname</tt>" class, derived from it, implements the virtual function
|
|
semantics <del>equivalent to</del><ins>provided by</ins> that facet of the locale constructed by <tt>locale(const char*)</tt>
|
|
with the same name.
|
|
Each such facet provides a constructor that takes a <tt>const char*</tt> argument, which names the locale, and a
|
|
<tt>refs</tt> argument, which is passed to the base class constructor. Each such facet also provides a constructor
|
|
that takes a string argument <tt>str</tt> and a <tt>refs</tt> argument, which has the same effect as calling the first
|
|
constructor with the two arguments <tt>str.c_str()</tt> and <tt>refs</tt>. If there is no "...<tt>_byname</tt>"
|
|
version of a facet, the base class implements named locale semantics itself by reference to other facets. <ins>For any
|
|
locale <tt>loc</tt> constructed by <tt>locale(const char*)</tt> and facet <tt>Facet</tt> that has a corresponding standard
|
|
<tt>Facet_byname</tt> class, <tt>typeid(use_facet<Facet>(loc)) == typeid(Facet_byname)</tt>.</ins>
|
|
</p></blockquote>
|
|
</li>
|
|
|
|
<li><p>Modify 28.7 [re.traits]/7 as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
template <class ForwardIterator>
|
|
string_type transform_primary(ForwardIterator first, ForwardIterator last) const;
|
|
</pre><blockquote>
|
|
<p>
|
|
-7- <i>Effects:</i> if <tt>typeid(use_facet<collate<charT> ><ins>(getloc())</ins>) == typeid(collate_byname<charT>)</tt>
|
|
and the form of the sort key returned by <tt>collate_byname<charT>::transform(first, last)</tt> is known and
|
|
can be converted into a primary sort key then returns that key, otherwise returns an empty string.
|
|
</p>
|
|
</blockquote></blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2342"></a>2342. User conversion to <tt>wchar_t const*</tt> or to <tt>wchar_t</tt> not invoked for <tt>operator<<</tt></h3>
|
|
<p><b>Section:</b> 27.7.3.1 [ostream] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Alf P. Steinbach <b>Opened:</b> 2013-10-29 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#ostream">issues</a> in [ostream].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
For wide streams argument types <tt>wchar_t const*</tt> and <tt>wchar_t</tt> are supported only as template parameters.
|
|
User defined conversions are not considered for template parameter matching. Hence inappropriate overloads of
|
|
<tt>operator<<</tt> are selected when an implicit conversion is required for the argument, which is inconsistent
|
|
with the behavior for <tt>char const*</tt> and <tt>char</tt>, is unexpected, and is a useless result.
|
|
<p/>
|
|
Demonstration:
|
|
</p>
|
|
<blockquote><pre>
|
|
#include <iostream>
|
|
|
|
struct Byte_string
|
|
{
|
|
operator char const*() const { return "Hurray, it works!"; }
|
|
};
|
|
|
|
struct Wide_string
|
|
{
|
|
operator wchar_t const*() const { return L"Hurray, it works!"; }
|
|
};
|
|
|
|
struct Byte_ch
|
|
{
|
|
operator char() const { return 'X'; }
|
|
};
|
|
|
|
struct Wide_ch
|
|
{
|
|
operator wchar_t() const { return L'X'; }
|
|
};
|
|
|
|
auto main() -> int
|
|
{
|
|
using namespace std;
|
|
wcout << "'X' as char value : " << Byte_ch() << endl;
|
|
wcout << "'X' as wchar_t value: " << Wide_ch() << endl;
|
|
wcout << "Byte string pointer : " << Byte_string() << endl;
|
|
wcout << "Wide string pointer : " << Wide_string() << endl;
|
|
}
|
|
</pre></blockquote>
|
|
<p>
|
|
Example output:
|
|
</p>
|
|
<blockquote><pre>
|
|
'X' as char value : X
|
|
'X' as wchar_t value: 88
|
|
Byte string pointer : Hurray, it works!
|
|
Wide string pointer : 000803C8
|
|
</pre></blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3797.</p>
|
|
|
|
<ol>
|
|
<li><p>Modify 27.7.3.1 [ostream], class template <tt>basic_ostream</tt> synopsis, as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
namespace std {
|
|
[…]
|
|
|
|
<i>// 27.7.3.6.4 character inserters</i>
|
|
template<class charT, class traits>
|
|
basic_ostream<charT,traits>& operator<<(basic_ostream<charT,traits>&,
|
|
charT);
|
|
template<class charT, class traits>
|
|
basic_ostream<charT,traits>& operator<<(basic_ostream<charT,traits>&,
|
|
char);
|
|
template<class traits>
|
|
basic_ostream<char,traits>& operator<<(basic_ostream<char,traits>&,
|
|
char);
|
|
<ins>template<class traits>
|
|
basic_ostream<wchar_t,traits>& operator<<(basic_ostream<wchar_t,traits>&,
|
|
wchar_t);</ins>
|
|
[…]
|
|
|
|
template<class charT, class traits>
|
|
basic_ostream<charT,traits>& operator<<(basic_ostream<charT,traits>&,
|
|
const charT*);
|
|
template<class charT, class traits>
|
|
basic_ostream<charT,traits>& operator<<(basic_ostream<charT,traits>&,
|
|
const char*);
|
|
template<class traits>
|
|
basic_ostream<char,traits>& operator<<(basic_ostream<char,traits>&,
|
|
const char*);
|
|
<ins>template<class traits>
|
|
basic_ostream<wchar_t,traits>& operator<<(basic_ostream<wchar_t,traits>&,
|
|
const wchar_t*);</ins>
|
|
[…]
|
|
}
|
|
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li><p>Modify 27.7.3.6.4 [ostream.inserters.character] as indicated: <em>[Drafting note:
|
|
The replacement of <tt>os</tt> by <tt>out</tt> in p1 and the insertion of "<tt>out.</tt>" in p4
|
|
just fix two obvious typos — end drafting note]</em></p>
|
|
|
|
<blockquote><pre>
|
|
template<class charT, class traits>
|
|
basic_ostream<charT,traits>& operator<<(basic_ostream<charT,traits>& out,
|
|
charT c);
|
|
template<class charT, class traits>
|
|
basic_ostream<charT,traits>& operator<<(basic_ostream<charT,traits>& out,
|
|
char c);
|
|
<i>// specialization</i>
|
|
template<class traits>
|
|
basic_ostream<char,traits>& operator<<(basic_ostream<char,traits>& out,
|
|
char c);
|
|
<ins>template<class traits>
|
|
basic_ostream<wchar_t,traits>& operator<<(basic_ostream<wchar_t,traits>& out,
|
|
wchar_t c);</ins>
|
|
|
|
<i>// signed and unsigned</i>
|
|
template<class traits>
|
|
basic_ostream<char,traits>& operator<<(basic_ostream<char,traits>& out,
|
|
signed char c);
|
|
template<class traits>
|
|
basic_ostream<char,traits>& operator<<(basic_ostream<char,traits>& out,
|
|
unsigned char c);
|
|
</pre><blockquote>
|
|
<p>
|
|
-1- <i>Effects:</i> Behaves as a formatted output function (27.7.3.6.1 [ostream.formatted.reqmts]) of <tt>out</tt>.
|
|
Constructs a character sequence <tt>seq</tt>. If <tt>c</tt> has type <tt>char</tt> and the character type of the stream
|
|
is not <tt>char</tt>, then <tt>seq</tt> consists of <tt>out.widen(c)</tt>; otherwise <tt>seq</tt> consists of <tt>c</tt>.
|
|
Determines padding for <tt>seq</tt> as described in 27.7.3.6.1 [ostream.formatted.reqmts]. Inserts <tt>seq</tt> into
|
|
<tt>out</tt>. Calls <tt><del>os</del><ins>out</ins>.width(0)</tt>.
|
|
<p/>
|
|
-2- <i>Returns:</i> <tt>out</tt>.
|
|
</p>
|
|
</blockquote>
|
|
<pre>
|
|
template<class charT, class traits>
|
|
basic_ostream<charT,traits>& operator<<(basic_ostream<charT,traits>& out,
|
|
const charT* s);
|
|
template<class charT, class traits>
|
|
basic_ostream<charT,traits>& operator<<(basic_ostream<charT,traits>& out,
|
|
const char* s);
|
|
template<class traits>
|
|
basic_ostream<char,traits>& operator<<(basic_ostream<char,traits>& out,
|
|
const char* s);
|
|
<ins>template<class traits>
|
|
basic_ostream<wchar_t,traits>& operator<<(basic_ostream<wchar_t,traits>& out,
|
|
const wchar_t* s);</ins>
|
|
|
|
template<class traits>
|
|
basic_ostream<char,traits>& operator<<(basic_ostream<char,traits>& out,
|
|
const signed char* s);
|
|
template<class traits>
|
|
basic_ostream<char,traits>& operator<<(basic_ostream<char,traits>& out,
|
|
const unsigned char* s);
|
|
</pre><blockquote>
|
|
<p>
|
|
-3- <i>Requires:</i> <tt>s</tt> shall not be a null pointer.
|
|
<p/>
|
|
-4- <i>Effects:</i> Behaves like a formatted inserter (as described in 27.7.3.6.1 [ostream.formatted.reqmts]) of <tt>out</tt>.
|
|
Creates a character sequence <tt>seq</tt> of <tt>n</tt> characters starting at <tt>s</tt>, each widened using <tt>out.widen()</tt>
|
|
(27.5.5.3), where <tt>n</tt> is the number that would be computed as if by:
|
|
</p>
|
|
<ul>
|
|
<li><p>
|
|
<tt>traits::length(s)</tt> for the <ins>following</ins> overload<ins>s:</ins>
|
|
<ul>
|
|
<li><p>
|
|
where the first argument is of type <tt>basic_ostream<charT, traits>&</tt>
|
|
and the second is of type <tt>const charT*</tt>,
|
|
</p></li>
|
|
<li><p>
|
|
<del>and also for the overload</del> where the first argument is of type
|
|
<tt>basic_ostream<char, traits>&</tt> and the second is of type <tt>const char*</tt>,
|
|
</p></li>
|
|
<li><p>
|
|
<ins>where the first argument is of type
|
|
<tt>basic_ostream<wchar_t, traits>&</tt> and the second is of type <tt>const wchar_t*</tt>,</ins>
|
|
</p></li>
|
|
</ul>
|
|
</p></li>
|
|
<li><p>
|
|
<tt>std::char_traits<char>::length(s)</tt> for the overload where the first argument is of type
|
|
<tt>basic_ostream<charT, traits>&</tt> and the second is of type <tt>const char*</tt>,
|
|
</p></li>
|
|
<li><p>
|
|
<tt>traits::length(reinterpret_cast<const char*>(s))</tt> for the other two overloads.
|
|
</p></li>
|
|
</ul>
|
|
<p>
|
|
Determines padding for <tt>seq</tt> as described in 27.7.3.6.1 [ostream.formatted.reqmts]. Inserts <tt>seq</tt> into
|
|
<tt>out</tt>. Calls <tt><ins>out.</ins>width(0)</tt>.
|
|
<p/>
|
|
-5- <i>Returns:</i> <tt>out</tt>.
|
|
</p>
|
|
</blockquote></blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2343"></a>2343. Is the value of the ECMA-262 RegExp object's multiline property really false?</h3>
|
|
<p><b>Section:</b> 28.13 [re.grammar] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Nayuta Taga <b>Opened:</b> 2013-10-30 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#re.grammar">issues</a> in [re.grammar].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
In the following "Multiline" is the value of the ECMA-262 RegExp object's multiline property.
|
|
<p/>
|
|
In <a href="http://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262,%203rd%20edition,%20December%201999.pdf">ECMA-262</a>,
|
|
there are some definitions that relate to Multiline:
|
|
</p>
|
|
<ul>
|
|
<li><p>
|
|
ECMA-262 15.10.2.6:
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
If Multiline is true, ^ matches just after LineTerminator.
|
|
<p/>
|
|
If Multiline is false, ^ does not match just after LineTerminator.
|
|
<p/>
|
|
If Multiline is true, $ matches just before LineTerminator.
|
|
<p/>
|
|
If Multiline is false, $ does not match just before LineTerminator.
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
ECMA-262 15.10.4.1, 15.10.7.4:
|
|
</p>
|
|
<blockquote><p>
|
|
By default, Multiline is false.
|
|
</p></blockquote>
|
|
</li>
|
|
</ul>
|
|
<p>
|
|
So, the C++11 standard says that Multiline is false. As it is false,
|
|
^ matches only the beginning of the string, and $ matches only the end
|
|
of the string.
|
|
<p/>
|
|
However, two flags are defined in 28.5.2 [re.matchflag] Table 139:
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
<tt>match_not_bol</tt>: the character ^ in the regular expression shall not match <tt>[first,first)</tt>.
|
|
<p/>
|
|
<tt>match_not_eol</tt>: the character "$" in the regular expression shall not match <tt>[last,last)</tt>.
|
|
</p>
|
|
</blockquote>
|
|
<p>
|
|
As Multiline is false, the <tt>match_not_bol</tt> and the <tt>match_not_eol</tt> are
|
|
meaningless because they only make ^ and $ match none.
|
|
<p/>
|
|
In my opinion, Multiline should be true.
|
|
<p/>
|
|
FYI, Multiline of the existing implementations are as follows:
|
|
<p/>
|
|
<em>Multiline=false:</em>
|
|
</p>
|
|
<ul>
|
|
<li><p>
|
|
libstdc++ r206594
|
|
</p></li>
|
|
<li><p>
|
|
libc++ r199174
|
|
</p></li>
|
|
</ul>
|
|
<p>
|
|
<em>Multiline=true:</em>
|
|
</p>
|
|
<ul>
|
|
<li><p>
|
|
Visual Studio Express 2013
|
|
</p></li>
|
|
<li><p>
|
|
boost 1.55
|
|
</p></li>
|
|
</ul>
|
|
|
|
<p><i>[2015-05-22, Daniel comments]</i></p>
|
|
|
|
<p>
|
|
This issue interacts with LWG <a href="lwg-active.html#2503">2503</a>.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2348"></a>2348. <tt>charT('1')</tt> is not the wide equivalent of <tt>'1'</tt></h3>
|
|
<p><b>Section:</b> 20.6 [template.bitset], 27.7.6 [quoted.manip] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Zhihao Yuan <b>Opened:</b> 2013-12-02 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Example: <tt>char16_t('1') != u'1'</tt> is possible.
|
|
<p/>
|
|
The numeric value of <tt>char16_t</tt> is defined to be Unicode
|
|
code point, which is same to the ASCII value and UTF-8 for
|
|
7-bit chars. However, <tt>char</tt> is not guaranteed to have an
|
|
encoding which is compatible with ASCII. For example, <tt>'1'</tt> in EBCDIC is 241.
|
|
<p/>
|
|
I found three places in the standard casting narrow char
|
|
literals: <tt>bitset::bitset</tt>, <tt>bitset::to_string</tt> and <tt>quoted</tt>.
|
|
<p/>
|
|
PJ confirmed this issue and says he has a solution used
|
|
in their <tt><filesystem></tt> implementation, and he may want to
|
|
propose it to the standard.
|
|
<p/>
|
|
The solution in my mind, for now, is to make those default
|
|
arguments magical, where the "magic" can be implemented
|
|
with a C11 <tt>_Generic</tt> selection (works in clang):
|
|
</p>
|
|
<blockquote><pre>
|
|
#define _G(T, literal) _Generic(T{}, \
|
|
char: literal, \
|
|
wchar_t: L ## literal, \
|
|
char16_t: u ## literal, \
|
|
char32_t: U ## literal)
|
|
|
|
_G(char16_t, '1') == u'1'
|
|
</pre></blockquote>
|
|
|
|
<p><i>[Lenexa 2015-05-05: Move to Open]</i></p>
|
|
|
|
<p>Ask for complete PR (need quoted, to string, et al.)</p>
|
|
<p>Will then take it up again</p>
|
|
<p>Expectation is that this is correct way to fix this</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3797.</p>
|
|
|
|
[<i>Drafting note:</i> This is a sample wording fixing only one case;
|
|
I'm just too lazy to copy-paste it before we discussed whether
|
|
the solution is worth and sufficient (for example, should the
|
|
other `charT`s like `unsigned char` just don't compile without
|
|
supplying those arguments? I hope so). — <i>end drafting note</i>]
|
|
|
|
<ol>
|
|
<li><p>Modify 20.6 [template.bitset] p1, class template <tt>bitset</tt> synopsis, as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
namespace std {
|
|
template <size_t N> class bitset {
|
|
public:
|
|
[…]
|
|
template<class charT, class traits, class Allocator>
|
|
explicit bitset(
|
|
const basic_string<charT,traits,Allocator>& str,
|
|
typename basic_string<charT,traits,Allocator>::size_type pos = 0,
|
|
typename basic_string<charT,traits,Allocator>::size_type n =
|
|
basic_string<charT,traits,Allocator>::npos,
|
|
charT zero = <del>charT('0')</del><ins><em>see below</em></ins>, charT one = <del>charT('1')</del><ins><em>see below</em></ins>);
|
|
[…]
|
|
};
|
|
[…]
|
|
}
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li><p>Modify 20.6.1 [bitset.cons] as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
template<class charT, class traits, class Allocator>
|
|
explicit
|
|
bitset(const basic_string<charT, traits, Allocator>& str,
|
|
typename basic_string<charT, traits, Allocator>::size_type pos = 0,
|
|
typename basic_string<charT, traits, Allocator>::size_type n =
|
|
basic_string<charT, traits, Allocator>::npos,
|
|
charT zero = <del>charT('0')</del><ins><em>see below</em></ins>, charT one = <del>charT('1')</del><ins><em>see below</em></ins>);
|
|
</pre><blockquote>
|
|
<p>
|
|
<ins>-?- The default values of <tt>zero</tt> and <tt>one</tt> compare equal to the
|
|
character literals <tt>0</tt> and <tt>1</tt> of type <tt>charT</tt>, respectively.</ins>
|
|
<p/>
|
|
-3- <i>Requires::</i> <tt>pos <= str.size()</tt>.
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
</blockquote></blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2349"></a>2349. Clarify input/output function rethrow behavior</h3>
|
|
<p><b>Section:</b> 27.7.2.2.1 [istream.formatted.reqmts] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Zhihao Yuan <b>Opened:</b> 2013-12-06 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#istream.formatted.reqmts">issues</a> in [istream.formatted.reqmts].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The formatted input function requirement says in 27.7.2.2.1 [istream.formatted.reqmts]:
|
|
</p>
|
|
<blockquote><p>
|
|
"If an exception is thrown during input then <tt>ios::badbit</tt> is turned on
|
|
in <tt>*this</tt>'s error state. If <tt>(exceptions()&badbit) != 0</tt> then the exception
|
|
is rethrown."
|
|
</p></blockquote>
|
|
<p>
|
|
while some formatted function may throw an exception from <tt>basic_ios::clear</tt>, for example
|
|
in 20.6.4 [bitset.operators] p6:
|
|
</p>
|
|
<blockquote><p>
|
|
"If no characters are stored in <tt>str</tt>, calls <tt>is.setstate(ios_base::failbit)</tt> (which may
|
|
throw <tt>ios_base::failure</tt>)"
|
|
</p></blockquote>
|
|
<p>
|
|
So should this exception be considered as "an exception [...] thrown
|
|
during input"? And here is an implementation divergence (or you
|
|
can read the following as "a bug libc++ only has" :)
|
|
</p>
|
|
<blockquote><pre>
|
|
cin.exceptions(ios_base::failbit);
|
|
bitset<N> b;
|
|
try {
|
|
cin >> b; // type 'a' and return
|
|
} catch (...)
|
|
{}
|
|
</pre></blockquote>
|
|
<p>
|
|
Now <tt>cin.rdstate()</tt> is just <tt>failbit</tt> in libstdc++ (and Dinkumware, by
|
|
PJ), but <tt>failbit & badbit</tt> libc++. Similar difference found in other
|
|
places, like <tt>eofbit & badbid</tt> after <tt>std::getline</tt>.
|
|
<p/>
|
|
PJ and Matt both agree that the intention (of <tt>badbit</tt> + rethrow) is
|
|
"to signify an exception arising in user code, not the iostreams package".
|
|
<p/>
|
|
In addition, I found the following words in unformatted input
|
|
function's requirements (27.7.2.3 [istream.unformatted]):
|
|
</p>
|
|
<blockquote><p>
|
|
If an exception is thrown during input then <tt>ios::badbit</tt> is turned on
|
|
in <tt>*this</tt>'s error state. (Exceptions thrown from <tt>basic_ios<>::clear()</tt>
|
|
are not caught or rethrown.) If <tt>(exceptions()&badbit) != 0</tt> then the
|
|
exception is rethrown.
|
|
</p></blockquote>
|
|
<p>
|
|
The content within the parenthesis is added by LWG defect <a href="lwg-defects.html#61">61</a>,
|
|
and does fix the ambiguity. However, it only fixed the 1 of 4
|
|
requirements, and it lost some context (the word "rethrown" is not
|
|
seen before this sentence within this section).
|
|
</p>
|
|
|
|
<p><i>[Lenexa 2015-05-07: Marshall to research and report]</i></p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3797.</p>
|
|
|
|
[<i>Drafting note:</i> The editor is kindly asked to introduce additional spaces at the following marked occurrences of
|
|
<tt>operator&</tt> — <i>end drafting note</i>]
|
|
|
|
<ol>
|
|
<li><p>Modify 27.7.2.2.1 [istream.formatted.reqmts] p1 as indicated:</p>
|
|
|
|
<blockquote><p>
|
|
-1- Each formatted input function begins execution by constructing an object of class <tt>sentry</tt> with the <tt>noskipws</tt>
|
|
(second) argument false. If the <tt>sentry</tt> object returns true, when converted to a value of type <tt>bool</tt>, the
|
|
function endeavors to obtain the requested input. If an exception<ins>, other than the ones thrown from <tt>clear()</tt>, if any,</ins>
|
|
is thrown during input then <tt>ios::badbit</tt>
|
|
is turned on[Footnote 314] in <tt>*this</tt>'s error state. If <tt>(exceptions()<ins> </ins>&<ins> </ins>badbit) != 0</tt>
|
|
then the exception is rethrown.
|
|
In any case, the formatted input function destroys the <tt>sentry</tt> object. If no exception has been thrown, it returns <tt>*this</tt>.
|
|
</p></blockquote>
|
|
</li>
|
|
|
|
<li><p>Modify 27.7.3.6.1 [ostream.formatted.reqmts] p1 as indicated:</p>
|
|
|
|
<blockquote><p>
|
|
-1- Each formatted output function begins execution by constructing an object of class <tt>sentry</tt>. If this object
|
|
returns true when converted to a value of type <tt>bool</tt>, the function endeavors to generate the requested
|
|
output. If the generation fails, then the formatted output function does <tt>setstate(ios_base::failbit)</tt>,
|
|
which might throw an exception. If an exception<ins>, other than the ones thrown from <tt>clear()</tt>, if any,</ins> is thrown
|
|
during output, then <tt>ios::badbit</tt> is turned on[Footnote 327]
|
|
in <tt>*this</tt>'s error state. If <tt>(exceptions()<ins> </ins>&<ins> </ins>badbit) != 0</tt> then the exception is rethrown.
|
|
Whether or not
|
|
an exception is thrown, the <tt>sentry</tt> object is destroyed before leaving the formatted output function. If no
|
|
exception is thrown, the result of the formatted output function is <tt>*this</tt>.
|
|
</p></blockquote>
|
|
</li>
|
|
|
|
<li><p>Modify 27.7.3.7 [ostream.unformatted] p1 as indicated:</p>
|
|
|
|
<blockquote><p>
|
|
-1- Each unformatted output function begins execution by constructing an object of class <tt>sentry</tt>. If this object
|
|
returns true, while converting to a value of type <tt>bool</tt>, the function endeavors to generate the requested
|
|
output. If an exception<ins>, other than the ones thrown from <tt>clear()</tt>, if any,</ins> is thrown during output,
|
|
then ios::badbit is turned on[Footnote 330] in <tt>*this</tt>'s error state.
|
|
If <tt>(exceptions() & badbit) != 0</tt> then the exception is rethrown. In any case, the unformatted output
|
|
function ends by destroying the <tt>sentry</tt> object, then, if no exception was thrown, returning the value specified
|
|
for the unformatted output function.
|
|
</p></blockquote>
|
|
</li>
|
|
|
|
<li><p>Modify 27.7.2.3 [istream.unformatted] p1 as indicated:</p>
|
|
|
|
<blockquote><p>
|
|
-1- Each unformatted input function begins execution by constructing an object of class <tt>sentry</tt> with the default
|
|
argument <tt>noskipws</tt> (second) argument true. If the <tt>sentry</tt> object returns true, when converted to a value
|
|
of type <tt>bool</tt>, the function endeavors to obtain the requested input. Otherwise, if the <tt>sentry</tt> constructor exits
|
|
by throwing an exception or if the sentry object returns false, when converted to a value of type <tt>bool</tt>, the
|
|
function returns without attempting to obtain any input. In either case the number of extracted characters
|
|
is set to <tt>0</tt>; unformatted input functions taking a character array of non-zero size as an argument shall also
|
|
store a null character (using <tt>charT()</tt>) in the first location of the array. If an exception<ins>, other than the
|
|
ones thrown from <tt>clear()</tt>, if any,</ins> is thrown during input
|
|
then <tt>ios::badbit</tt> is turned on[Footnote 317] in <tt>*this</tt>'s error state. <del>(Exceptions thrown from
|
|
<tt>basic_ios<>::clear()</tt> are not caught or rethrown.)</del> If <tt>(exceptions()<ins> </ins>&<ins> </ins>badbit) != 0</tt>
|
|
then the exception is rethrown. It also counts the number of characters extracted. If no exception has been thrown it ends
|
|
by storing the count in a member object and returning the value specified. In any event the <tt>sentry</tt> object is destroyed
|
|
before leaving the unformatted input function.
|
|
</p></blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2352"></a>2352. Is a default-constructed <tt>std::seed_seq</tt> intended to produce a predictable <tt>.generate()</tt>?</h3>
|
|
<p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Thomas Plum <b>Opened:</b> 2013-12-02 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
With respect to class <tt>seed_seq</tt> 26.5.7.1 [rand.util.seedseq], is a default-constructed
|
|
<tt>std::seed_seq</tt> intended to produce a predictable <tt>.generate()</tt> sequence?
|
|
<p/>
|
|
Implementations differ.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2353"></a>2353. <tt>std::next</tt> is over-constrained</h3>
|
|
<p><b>Section:</b> 24.4.4 [iterator.operations] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Eric Niebler <b>Opened:</b> 2013-12-24 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#iterator.operations">issues</a> in [iterator.operations].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
In LWG <a href="lwg-defects.html#1011">1011</a>, <tt>std::next</tt> and <tt>std::prev</tt> were changed
|
|
from accepting <tt>InputIterator</tt> to accepting
|
|
<tt>ForwardIterator</tt>. This needlessly excludes perfectly legitimate use
|
|
cases. Consider the following hypothetical range-based implementation of
|
|
drop, which creates a view of a range without the first <tt>n</tt> elements:
|
|
</p>
|
|
<blockquote><pre>
|
|
template<typename Distance, typename InputRange>
|
|
iterator_range<range_iterator_t<InputRange>>
|
|
drop(Distance n, InputRange& rng)
|
|
{
|
|
return make_iterator_range(
|
|
std::next(std::begin(rng), n),
|
|
std::end(rng)
|
|
);
|
|
}
|
|
</pre></blockquote>
|
|
<p>
|
|
I believe this to be a legitimate use case that is currently outlawed by
|
|
the standard without cause. See the discussion beginning at
|
|
<a href="http://accu.org/cgi-bin/wg21/message?wg=lib&msg=35313">c++std-lib-35313</a>
|
|
for an in-depth discussion of the issue, in which
|
|
Howard Hinnant agreed that it was a defect.
|
|
<p/>
|
|
(Some discussion then ensued about whether an overload should be added
|
|
that only accepts rvalue <tt>InputIterators</tt> to avoid the surprise that issue
|
|
<a href="lwg-defects.html#1011">1011</a> sought to address. I make no such attempt, nor do I believe it to
|
|
be necessary.)
|
|
<p/>
|
|
Suggested resolution:
|
|
<p/>
|
|
Back out the resolution of <a href="lwg-defects.html#1011">1011</a>.
|
|
</p>
|
|
|
|
<p><i>[Lenexa 2015-05-07: Move to Ready]</i></p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3797.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 24.3 [iterator.synopsis], header <tt><iterator></tt> synopsis, and 24.4.4 [iterator.operations]
|
|
before p.6 as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
template <class <del>Forward</del><ins>Input</ins>Iterator>
|
|
<del>Forward</del><ins>Input</ins>Iterator next(<del>Forward</del><ins>Input</ins>Iterator x,
|
|
typename std::iterator_traits<<del>Forward</del><ins>Input</ins>Iterator>::difference_type n = 1);
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2358"></a>2358. Apparently-bogus definition of <tt>is_empty</tt> type trait</h3>
|
|
<p><b>Section:</b> 20.10.4.3 [meta.unary.prop] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Richard Smith <b>Opened:</b> 2014-02-01 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The 'Condition' for <tt>std::is_empty</tt> is listed as:
|
|
</p>
|
|
<blockquote><p>
|
|
"<tt>T</tt> is a class type, but not a union type, with no non-static data members other than bit-fields of length 0,
|
|
no virtual member functions, no virtual base classes, and no base class <tt>B</tt> for which <tt>is_empty<B>::value</tt>
|
|
is false."
|
|
</p></blockquote>
|
|
<p>
|
|
This is incorrect: there is no such thing as a non-static data member that is a bit-field of length 0, since bit-fields of
|
|
length 0 must be unnamed, and unnamed bit-fields are not members (see 9.6 [class.bit] p2).
|
|
<p/>
|
|
It also means that classes such as:
|
|
</p>
|
|
<blockquote><pre>
|
|
struct S {
|
|
int : 3;
|
|
};
|
|
</pre></blockquote>
|
|
<p>
|
|
are empty (because they have no non-static data members). There's implementation divergence on the value of
|
|
<tt>is_empty<S>::value</tt>.
|
|
<p/>
|
|
I'm not sure what the purpose of <tt>is_empty</tt> is (or how it could be useful), but if it's desirable for the above type to
|
|
not be treated as empty, something like this could work:
|
|
</p>
|
|
<blockquote><p>
|
|
"<tt>T</tt> is a class type, but not a union type, with no non-static data members <del>other than</del><ins>, no unnamed</ins>
|
|
bit-fields of <ins>non-zero</ins> length <del>0</del>, no virtual member functions, no virtual base classes, and no base class
|
|
<tt>B</tt> for which <tt>is_empty<B>::value</tt> is false."
|
|
</p></blockquote>
|
|
<p>
|
|
and if the above type <em>should</em> be treated as empty, then this might be appropriate:
|
|
</p>
|
|
<blockquote><p>
|
|
"<tt>T</tt> is a class type, but not a union type, with no <ins>(named)</ins> non-static data members <del>other than bit-fields of
|
|
length 0</del>, no virtual member functions, no virtual base classes, and no base class <tt>B</tt> for which
|
|
<tt>is_empty<B>::value</tt> is false."
|
|
</p></blockquote>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2362"></a>2362. unique, associative <tt>emplace()</tt> should not move/copy the <tt>mapped_type</tt> constructor arguments when no insertion happens</h3>
|
|
<p><b>Section:</b> 23.2.4 [associative.reqmts], 23.2.5 [unord.req] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2014-02-15 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
<tt>a_uniq.emplace(args)</tt> is specified as:
|
|
</p>
|
|
|
|
<blockquote><p>
|
|
<i>Effects</i>: Inserts a value_type object <tt>t</tt> constructed with<br/>
|
|
<tt>std::forward<Args>(args)...</tt> if and only if there is no element in the<br/>
|
|
container with key equivalent to the key of <tt>t</tt>. The <tt>bool</tt> component of<br/>
|
|
the returned pair is true if and only if the insertion takes place,<br/>
|
|
and the iterator component of the pair points to the element with key<br/>
|
|
equivalent to the key of <tt>t</tt>.
|
|
</p></blockquote>
|
|
|
|
<p>
|
|
However, we occasionally find code of the form:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
std::unique_ptr<Foo> p(new Foo);
|
|
auto res = m.emplace("foo", std::move(p));
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
where we'd like to avoid destroying the <tt>Foo</tt> if the insertion doesn't
|
|
take place (if the container already had an element with the specified key).
|
|
<p/>
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3873">N3873</a> includes
|
|
a partial solution to this in the form of a new <tt>emplace_stable</tt> member function, but LEWG's
|
|
discussion strongly agreed that we'd rather have <tt>emplace()</tt> Just Work:
|
|
<p/>
|
|
Should <tt>map::emplace()</tt> be guaranteed not to move/copy its arguments if the insertion doesn't happen?
|
|
<p/>
|
|
SF: 8 F: 3 N: 0 A: 0 SA: 0
|
|
<p/>
|
|
This poll was marred by the fact that we didn't notice or call out
|
|
that <tt>emplace()</tt> must construct the key before doing the lookup, and it
|
|
must not then move the key after it determines whether an insert is
|
|
going to happen, and the <tt>mapped_type</tt> instance must live next to the key.
|
|
<p/>
|
|
The very similar issue <a href="lwg-closed.html#2006">2006</a> was previously marked NAD, with
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3178.htm">N3178</a> as
|
|
discussion. However, given LEWG's interest in the alternate behavior,
|
|
we should reopen the question in this issue.
|
|
<p/>
|
|
We will need a paper that describes how to implement this before we can make more progress.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2363"></a>2363. Defect in 30.4.1.4.1 [thread.sharedtimedmutex.class]</h3>
|
|
<p><b>Section:</b> 30.4.1.5.1 [thread.sharedtimedmutex.class] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Richard Smith <b>Opened:</b> 2014-02-16 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
30.4.1.5.1 [thread.sharedtimedmutex.class] paragraph 2:
|
|
</p>
|
|
<blockquote><p> The class <tt>shared_timed_mutex</tt> shall satisfy all of the
|
|
<tt>SharedTimedMutex</tt> requirements (30.4.1.4). It shall be a standard layout class (Clause 9).
|
|
</p></blockquote>
|
|
<p>
|
|
There's no <tt>SharedTimedMutex</tt> requirements; this name doesn't appear anywhere else in the standard. (Prior to N3891,
|
|
this was <tt>SharedMutex</tt>, which was equally undefined.)
|
|
<p/>
|
|
I assume this concept should be defined somewhere?
|
|
<p/>
|
|
Also, n3891 changes 30.4.1.5 [thread.sharedtimedmutex.requirements] from defining "shared mutex type" to defining
|
|
"shared timed mutex type", but its paragraph 2 still talks about "shared mutex type". Is that OK? I think you could argue
|
|
that it's clear enough what it means, but presumably it should use the term that paragraph 1 defined.
|
|
<p/>
|
|
30.4.2.3 [thread.lock.shared] paragraph 1 talks about the "shared mutex requirements", which again is a term that isn't
|
|
defined, and presumably means "the requirements on a shared timed mutex type" or similar (maybe if <tt>SharedMutex</tt> or
|
|
<tt>SharedTimedMutex</tt> were defined it could be reused here).
|
|
</p>
|
|
|
|
<p><i>[2014-05-22, Daniel comments]</i></p>
|
|
|
|
<p>
|
|
As for <tt>SharedTimedMutex</tt>, there exists a similar problem in regard to <tt>TimedMutex</tt> referred to in
|
|
30.4.1.3.1 [thread.timedmutex.class] p2 and in 30.4.1.3.2 [thread.timedmutex.recursive] p2, but nowhere defined.
|
|
<p/>
|
|
Another problem is, that according to 30.4.1.2.1 [thread.mutex.class] p3, "The class <tt>mutex</tt> shall satisfy all the
|
|
<tt>Mutex</tt> requirements (30.4.1 [thread.mutex.requirements]).", but there are no concrete <tt>Mutex</tt> requirements,
|
|
30.4.1 [thread.mutex.requirements] — titled as "Mutex requirements" — describes <em>mutex types</em>,
|
|
<em>timed mutex types</em>, and <em>shared timed mutex types</em>.
|
|
</p>
|
|
|
|
<p><i>[2014-06-08, Daniel comments and provides wording]</i></p>
|
|
|
|
<p>
|
|
The presented wording adds to the existing <em>mutex types</em>, <em>timed mutex types</em>, and <em>shared timed mutex types</em>
|
|
terms a new set of corresponding <tt>MutexType</tt>, <tt>TimedMutexType</tt>, and <tt>SharedTimedMutexType</tt> requirements.
|
|
<p/>
|
|
The reason for the change of requirement names is two-fold: First, the new name better matches the intention to have a concrete
|
|
name for the requirements imposed on the corresponding <em>mutex types</em> (This kind of requirement deviate from the more general
|
|
<tt>Lockable</tt> requirements, which are not restricted to a explicitly enumerated set of library types). Second, using
|
|
<tt>**MutexType</tt> over <tt>**Mutex</tt> provides the additional advantage that it reduces the chances of confusing named
|
|
requirements from template parameters named <tt>Mutex</tt> (such as for <tt>unique_lock</tt> or <tt>shared_lock</tt>).
|
|
<p/>
|
|
Nonetheless the here presented wording has one unfortunate side-effect: Once applied it would have the effect that types
|
|
used to instantiate <tt>std::shared_lock</tt> cannot be user-defined shared mutex types due to 30.4.2.3 [thread.lock.shared].
|
|
The reason is based on the currently lack of an existing <tt>SharedLockable</tt> requirement set, which would complete the
|
|
existing <tt>BasicLockable</tt> and <tt>Lockable</tt> requirements (which are "real" requirements). This restriction is not
|
|
actually a problem introduced by the provided resolution but instead one that existed before but becomes more obvious now.
|
|
</p>
|
|
|
|
<p><i>[2015-02 Cologne]</i></p>
|
|
|
|
<p>
|
|
Handed over to SG1.
|
|
</p>
|
|
|
|
<p><i>[2015-05 Lenexa, SG1 response]</i></p>
|
|
|
|
<p>
|
|
Thanks to Daniel, and please put it in SG1-OK status. Perhaps open another issue for the remaining problem Daniel points out?
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 30.4.1.2 [thread.mutex.requirements.mutex] as indicated:</p>
|
|
|
|
<blockquote><p>
|
|
-1- The <em>mutex types</em> are the standard library types <tt>std::mutex</tt>, <tt>std::recursive_mutex</tt>, <tt>std::timed_mutex</tt>,
|
|
<tt>std::recursive_timed_mutex</tt>, and <tt>std::shared_timed_mutex</tt>. They shall meet the <ins><tt><em>MutexType</em></tt></ins>
|
|
requirements set out in this section. In this description, <tt>m</tt> denotes an object of a mutex type.
|
|
</p></blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 30.4.1.2.1 [thread.mutex.class] as indicated:</p>
|
|
|
|
<blockquote><p>
|
|
-3- The class <tt>mutex</tt> shall satisfy all the <tt>Mutex<ins>Type</ins></tt> requirements
|
|
(<ins>30.4.1.2 [thread.mutex.requirements.mutex]</ins><del>30.4.1 [thread.mutex.requirements]</del>).
|
|
It shall be a standard-layout class (Clause 9).
|
|
</p></blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 30.4.1.2.2 [thread.mutex.recursive] as indicated:</p>
|
|
|
|
<blockquote><p>
|
|
-2- The class <tt>recursive_mutex</tt> shall satisfy all the <del>Mutex</del><ins><tt>MutexType</tt></ins> requirements
|
|
(<ins>30.4.1.2 [thread.mutex.requirements.mutex]</ins><del>30.4.1 [thread.mutex.requirements]</del>).
|
|
It shall be a standard-layout class (Clause 9).
|
|
</p></blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 30.4.1.3 [thread.timedmutex.requirements] as indicated:</p>
|
|
|
|
<blockquote><p>
|
|
-1- The <em>timed mutex types</em> are the standard library types <tt>std::timed_mutex</tt>, <tt>std::recursive_timed_mutex</tt>,
|
|
and <tt>std::shared_timed_mutex</tt>. They shall meet the <ins><tt><em>TimedMutexType</em></tt></ins> requirements set out below.
|
|
In this description, <tt>m</tt> denotes an object of a mutex type, <tt>rel_time</tt> denotes an object of an instantiation of
|
|
<tt>duration</tt> (20.12.5), and <tt>abs_time</tt> denotes an object of an instantiation of <tt>time_point</tt> (20.12.6).
|
|
</p></blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 30.4.1.3.1 [thread.timedmutex.class] as indicated:</p>
|
|
|
|
<blockquote><p>
|
|
-2- The class <tt>timed_mutex</tt> shall satisfy all of the <tt>TimedMutex<ins>Type</ins></tt> requirements
|
|
(30.4.1.3 [thread.timedmutex.requirements]). It shall be a standard-layout class (Clause 9).
|
|
</p></blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 30.4.1.3.2 [thread.timedmutex.recursive] as indicated:</p>
|
|
|
|
<blockquote><p>
|
|
-2- The class <tt>recursive_timed_mutex</tt> shall satisfy all of the <tt>TimedMutex<ins>Type</ins></tt> requirements
|
|
(30.4.1.3 [thread.timedmutex.requirements]). It shall be a standard-layout class (Clause 9).
|
|
</p></blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 30.4.1.5 [thread.sharedtimedmutex.requirements] as indicated: [<i>Drafting note</i>: The reference to the
|
|
timed mutex types requirements has been moved <em>after</em> introducing the new requirement set to ensure that
|
|
<tt>SharedTimedMutexType</tt> <em>refine</em> <tt>TimedMutexType</tt>.]</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-1- The standard library type <tt>std::shared_timed_mutex</tt> is a <em>shared timed mutex type</em>. Shared timed mutex
|
|
types shall meet the <ins><tt><em>SharedTimedMutexType</em></tt></ins> requirements <del>of timed mutex types
|
|
(30.4.1.3 [thread.timedmutex.requirements]), and additionally shall meet the requirements</del> set out below. In this
|
|
description, <tt>m</tt> denotes an object of a mutex type, <tt>rel_type</tt> denotes
|
|
an object of an instantiation of <tt>duration</tt> (20.12.5), and <tt>abs_time</tt> denotes an object of an instantiation of
|
|
<tt>time_point</tt> (20.12.6).
|
|
<p/>
|
|
<ins>-?- The shared timed mutex types shall meet the <tt>TimedMutexType</tt> requirements (30.4.1.3 [thread.timedmutex.requirements]).</ins>
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 30.4.1.5.1 [thread.sharedtimedmutex.class] as indicated:</p>
|
|
|
|
<blockquote><p>
|
|
-2- The class <tt>shared_timed_mutex</tt> shall satisfy all of the <tt>SharedTimedMutex<ins>Type</ins></tt> requirements
|
|
(30.4.1.5 [thread.sharedtimedmutex.requirements]). It shall be a standard-layout class (Clause 9).
|
|
</p></blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 30.4.2.3 [thread.lock.shared] as indicated: [<i>Drafting note</i>: Once
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3995.htm">N3995</a> has been applied, the following
|
|
reference should be changed to the new <tt>SharedMutexType</tt> requirements ([thread.sharedmutex.requirements]) or
|
|
even better to some new <tt>SharedLockable</tt> requirements (to be defined) — <i>end drafting note</i>]</p>
|
|
|
|
<blockquote><p>
|
|
-1- […] The supplied <tt>Mutex</tt> type shall meet the <del>shared mutex</del><ins><tt>SharedTimedMutexType</tt></ins> requirements
|
|
(30.4.1.5 [thread.sharedtimedmutex.requirements]).
|
|
<p/>
|
|
-2- [<i>Note</i>: <tt>shared_lock<Mutex></tt> meets the <tt>TimedLockable</tt> requirements
|
|
(30.2.5.4). — <i>end note</i>]
|
|
</p></blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2366"></a>2366. <tt>istreambuf_iterator</tt> end-of-stream equality</h3>
|
|
<p><b>Section:</b> 24.6.3 [istreambuf.iterator] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Hyman Rosen <b>Opened:</b> 2014-02-19 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#istreambuf.iterator">issues</a> in [istreambuf.iterator].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Given the following code,
|
|
</p>
|
|
<blockquote><pre>
|
|
#include <sstream>
|
|
|
|
std::stringbuf buf;
|
|
std::istreambuf_iterator<char> begin(&buf);
|
|
std::istreambuf_iterator<char> end;
|
|
</pre></blockquote>
|
|
<p>
|
|
it is not clear from the wording of the Standard whether <tt>begin.equal(end)</tt>
|
|
must be true. In at least one implementation it is not (CC: Sun C++ 5.10 SunOS_sparc Patch 128228-25 2013/02/20) and in at least
|
|
one implementation it is (gcc version 4.3.2 x86_64-unknown-linux-gnu).
|
|
<p/>
|
|
24.6.3 [istreambuf.iterator] says that <tt>end</tt> is an end-of-stream iterator since it was default
|
|
constructed. It also says that an iterator becomes equal to an end-of-stream
|
|
iterator when end of stream is reached by <tt>sgetc()</tt> having returned <tt>eof()</tt>.
|
|
24.6.3.5 [istreambuf.iterator::equal] says that <tt>equal()</tt> returns true iff both iterators are end of stream
|
|
or not end of stream. But there seems to be no requirement that <tt>equal</tt> check for end-of-stream by calling <tt>sgetc()</tt>.
|
|
<p/>
|
|
Jiahan Zi at BloombergLP discovered this issue through his code failing to
|
|
work correctly. Dietmar Kühl has opined in a private communication that
|
|
the iterators should compare equal.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2367"></a>2367. <tt>pair</tt> and <tt>tuple</tt> are not correctly implemented for <tt>is_constructible</tt> with no args</h3>
|
|
<p><b>Section:</b> 20.10.4.3 [meta.unary.prop] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2014-02-19 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Consider:
|
|
</p>
|
|
<blockquote><pre>
|
|
struct X
|
|
{
|
|
X() = delete;
|
|
};
|
|
|
|
int main()
|
|
{
|
|
typedef std::pair<int, X> P;
|
|
static_assert(!std::is_constructible<P>::value, "");
|
|
static_assert(!std::is_default_constructible<P>::value, "");
|
|
typedef std::tuple<int, X> T;
|
|
static_assert(!std::is_constructible<T>::value, "");
|
|
static_assert(!std::is_default_constructible<T>::value, "");
|
|
}
|
|
</pre></blockquote>
|
|
<p>
|
|
For me these <tt>static_asserts</tt> fail. And worse than that, even asking the question fails (as opposed to gets the wrong answer):
|
|
</p>
|
|
<blockquote><pre>
|
|
assert(!std::is_constructible<P>::value);
|
|
</pre></blockquote>
|
|
<p>
|
|
In file included from test.cpp:2:
|
|
</p>
|
|
<blockquote><pre>
|
|
error:
|
|
call to deleted constructor of 'X'
|
|
pair() : first(), second() {}
|
|
^
|
|
note: function has been explicitly marked deleted here
|
|
X() = delete;
|
|
^
|
|
1 error generated.
|
|
</pre></blockquote>
|
|
<p>
|
|
This can be solved by specializing <tt>is_constructible</tt> on <tt>pair</tt> and <tt>tuple</tt> for zero Args:
|
|
</p>
|
|
<blockquote><pre>
|
|
template <class T, class U>
|
|
struct is_constructible<pair<T, U>>
|
|
: integral_constant<bool, is_default_constructible<T>::value &&
|
|
is_default_constructible<U>::value>
|
|
{};
|
|
|
|
template <class ...T>
|
|
struct is_constructible<tuple<T...>>
|
|
: integral_constant<bool,
|
|
__all<is_default_constructible<T>::value...>::value>
|
|
{};
|
|
</pre></blockquote>
|
|
<p>
|
|
Now everything just works.
|
|
</p>
|
|
|
|
<p><i>[2014-05-14, Daniel comments]</i></p>
|
|
|
|
|
|
<p>
|
|
The proposed resolution is incomplete, because it wouldn't work for <i>cv</i>-qualified objects of
|
|
<tt>pair</tt> or for references of them during reference-initialization.
|
|
<p/>
|
|
I would like to point out that the approach suggested in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3739.html">N3739</a>
|
|
can be easily extended to solve the problem without need to muddle with specializing <tt>is_constructible</tt>:
|
|
</p>
|
|
<blockquote><pre>
|
|
template<class U1 = T1, class U2 = T2,
|
|
typename enable_if<
|
|
is_default_constructible<U1>::value && is_default_constructible<U2>::value
|
|
, bool>::type = false
|
|
>
|
|
constexpr pair();
|
|
</pre></blockquote>
|
|
<p>
|
|
The new wording proposal represents an alternative wording change that I would strongly prefer.
|
|
</p>
|
|
|
|
<strong>Previous resolution from Howard [SUPERSEDED]:</strong>
|
|
<p/>
|
|
<blockquote class="note">
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Add to 20.3.3 [pairs.spec]:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
<ins>template <class T, class U>
|
|
struct is_constructible<pair<T, U>>
|
|
: integral_constant<bool, is_default_constructible<T>::value &&
|
|
is_default_constructible<U>::value>
|
|
{};</ins>
|
|
</pre>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Add to 20.4.2.9 [tuple.special]:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
<ins>template <class ...T>
|
|
struct is_constructible<tuple<T...>>
|
|
: integral_constant<bool, <i>see below</i>>
|
|
{};</ins>
|
|
</pre>
|
|
<blockquote><p>
|
|
<ins>-?- The second argument to <tt>integral_constant</tt> shall be true if for each <tt>T</tt>,
|
|
<tt>is_default_constructible<T>::value</tt> is true.</ins>
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
</blockquote>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
STL: I object to this resolution due to British spelling of behavior<br/>
|
|
JW: we already have other places of this spelling<br/>
|
|
VV: the easy resolution is to remove the notes<br/>
|
|
MC: if that's all we want to change: put it in and make the editorial change of removing the note<br/>
|
|
VV: the other paper doesn't make any of these changes so it would be consistent<br/>
|
|
JW: this make me want even more the features of having constructors doing the Right Thing
|
|
- I haven't written up the request to do something like that<br/>
|
|
VV: so it would be an aggregate reflecting the properties of the constituting types<br/>
|
|
JW: I should write that up<br/>
|
|
MC: any objection to move to ready? in favor: 16, opposed: 0, abstain: 1
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 20.3.2 [pairs.pair] around p3 as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
constexpr pair();
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
<del>-3- <i>Requires</i>: <tt>is_default_constructible<first_type>::value</tt> is true and
|
|
<tt>is_default_constructible<second_type>::value</tt> is true.</del>
|
|
<p/>
|
|
-4- <i>Effects</i>: Value-initializes first and second.
|
|
<p/>
|
|
<ins>-?- <i>Remarks</i>: This constructor shall not participate in overload resolution unless
|
|
<tt>is_default_constructible<first_type>::value</tt> is true and
|
|
<tt>is_default_constructible<second_type>::value</tt> is true. [<i>Note</i>: This behaviour can be implemented
|
|
by a constructor template with default template arguments — <i>end note</i>].</ins>
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 20.4.2.1 [tuple.cnstr] around p4 as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
constexpr tuple();
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
<del>-4- <i>Requires</i>: <tt>is_default_constructible<<i>T<sub>i</sub></i>>::value</tt> is true for all <i>i</i>.</del>
|
|
<p/>
|
|
-5- <i>Effects</i>: Value initializes each element.
|
|
<p/>
|
|
<ins>-?- <i>Remarks</i>: This constructor shall not participate in overload resolution unless
|
|
<tt>is_default_constructible<<i>T<sub>i</sub></i>>::value</tt> is true for all <i>i</i>. [<i>Note</i>: This behaviour can
|
|
be implemented by a constructor template with default template arguments — <i>end note</i>].</ins>
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2368"></a>2368. Replacing global <tt>operator new</tt></h3>
|
|
<p><b>Section:</b> 18.6.1 [new.delete] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Stephen Clamage <b>Opened:</b> 2014-02-20 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#new.delete">issues</a> in [new.delete].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Section 18.6.1 [new.delete] and subsections shows:
|
|
</p>
|
|
<blockquote><pre>
|
|
void* operator new(std::size_t size);
|
|
void* operator new[](std::size_t size);
|
|
</pre></blockquote>
|
|
<p>
|
|
That is, without exception-specifications. (Recall that C++03 specified these functions with <tt>throw(std::bad_alloc)</tt>.)
|
|
<p/>
|
|
Section 17.6.5.12 [res.on.exception.handling] the end of paragraph 4 says:
|
|
</p>
|
|
<blockquote><p>
|
|
Any other functions defined in the C++ standard library that do not have an exception-specification may throw implementation-defined
|
|
exceptions unless otherwise specified. An implementation may strengthen this implicit exception-specification by adding an explicit one.
|
|
</p></blockquote>
|
|
<p>
|
|
For example, an implementation could provide C++03-compatible declarations of <tt>operator new</tt>.
|
|
<p/>
|
|
Programmers are allowed to replace these <tt>operator new</tt> functions. But how can you write the definition of these functions when
|
|
the exception specification can vary among implementations? For example, the declarations
|
|
</p>
|
|
<blockquote><pre>
|
|
void* operator new(std::size_t size) throw(std::bad_alloc);
|
|
void* operator new(std::size_t size);
|
|
</pre></blockquote>
|
|
<p>
|
|
are not compatible.
|
|
<p/>
|
|
From what I have been able to determine, gcc has a hack for the special case of <tt>operator new</tt> to ignore the differences in
|
|
(at least) the two cases I show above. But can users expect all compilers to quietly ignore the incompatibility?
|
|
<p/>
|
|
The blanket permission to add any explicit exception specification could cause a problem for any user-overridable function.
|
|
Different implementations could provide incompatible specifications, making portable code impossible to write.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2370"></a>2370. Operations involving type-erased allocators should not be <tt>noexcept</tt> in <tt>std::function</tt></h3>
|
|
<p><b>Section:</b> 20.9.12.2 [func.wrap.func] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2014-02-27 <b>Last modified:</b> 2015-05-05</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The following constructors in 20.9.12.2 [func.wrap.func] are declared <tt>noexcept</tt>, even
|
|
though it is not possible for an implementation to guarantee that they will not throw:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
template <class A> function(allocator_arg_t, const A&) noexcept;
|
|
template <class A> function(allocator_arg_t, const A&, nullptr_t) noexcept;
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
In addition, the following functions are guaranteed not to throw if the target
|
|
is a function pointer or a <tt>reference_wrapper</tt>:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
template <class A> function(allocator_arg_t, const A& a, const function& f);
|
|
template <class F, class A> function(allocator_arg_t, const A& a, F f);
|
|
</pre></blockquote>
|
|
|
|
<p>
|
|
In all of the above cases, the function object might need to allocate memory
|
|
(an operation that can throw) in order to hold a copy of the type-erased
|
|
allocator itself. The first two constructors produce an empty function
|
|
object, but the allocator is still needed in case the object is later assigned
|
|
to. In this case, we note that the propagation of allocators on assignment is
|
|
underspecified for <tt>std::function</tt>. There are three possibilities:
|
|
</p>
|
|
|
|
<ol>
|
|
<li><p>The allocator is never copied on copy-assignment, moved on move-assignment, or swapped on swap.</p>
|
|
</li>
|
|
|
|
<li><p>The allocator is always copied on copy-assignment, moved on move-assignment, and swapped on swap.</p>
|
|
</li>
|
|
|
|
<li><p>Whether or not the allocator is copied, moved, or swapped is determined at
|
|
run-time based on the <tt>propagate_on_container_copy_assignment</tt> and
|
|
<tt>propagate_on_container_move_assignment</tt> traits of the allocators at
|
|
construction of the source function, the target function, or both.</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>
|
|
Although the third option seems to be the most consistent with existing
|
|
wording in the containers section of the standard, it is problematic in a
|
|
number of respects. To begin with, the propagation behavior is determined at
|
|
run time based on a pair of type-erased allocators, instead of at compile
|
|
time. Such run-time logic is <em>not</em> consistent with the rest of the standard
|
|
and is hard to reason about. Additionally, there are two allocator types
|
|
involved, rather than one. Any set of rules that attempts to rationally
|
|
interpret the propagation traits of both allocators is likely to be arcane
|
|
at best, and subtly wrong for some set of codes at worst.
|
|
</p>
|
|
|
|
<p>
|
|
The second option is a non-starter. Historically, and in the vast majority of
|
|
existing code, an allocator does not change after an object is constructed.
|
|
The second option, if adopted, would undermine the programmer's ability to
|
|
construct, e.g., an array of function objects, all using the same allocator.
|
|
</p>
|
|
|
|
<p>
|
|
The first option is (in Pablo's opinion) the simplest and best. It is
|
|
consistent with historical use of allocators, is easy to understand, and
|
|
requires minimal wording. It is also consistent with the wording in N3916,
|
|
which formalizes type-erased allocators.
|
|
</p>
|
|
|
|
<p>
|
|
For cross-referencing purposes: The resolution of this issue should be
|
|
harmonized with any resolution to LWG <a href="lwg-active.html#2062">2062</a>, which questions the <tt>noexcept</tt>
|
|
specification on the following member functions of std::function:
|
|
</p>
|
|
|
|
<blockquote><pre>
|
|
template <class F> function& operator=(reference_wrapper<F>) noexcept;
|
|
void swap(function&) noexcept;
|
|
</pre></blockquote>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
MC: change to P3 and status to open.
|
|
<p/>
|
|
STL: note that <tt>noexcept</tt> is an issue and large chunks of allocator should be destroyed.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 20.9.12.2 [func.wrap.func], class template <tt>function</tt> synopsis, as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
template <class A> function(allocator_arg_t, const A&) <del>noexcept</del>;
|
|
template <class A> function(allocator_arg_t, const A&, nullptr_t) <del>noexcept</del>;
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 20.9.12.2.1 [func.wrap.func.con] as indicated:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-1- When any function constructor that takes a first argument of type <tt>allocator_arg_t</tt> is invoked, the second
|
|
argument shall have a type that conforms to the requirements for <tt>Allocator</tt> (Table 17.6.3.5). A copy of the
|
|
allocator argument is used to allocate memory, if necessary, for the internal data structures of the constructed
|
|
function object. <ins> For the remaining constructors, an instance of <tt>allocator<T></tt>, for some suitable type
|
|
<tt>T</tt>, is used to allocate memory, if necessary, for the internal data structures of the constructed function object.</ins>
|
|
</p>
|
|
|
|
<pre>
|
|
function() noexcept;
|
|
template <class A> function(allocator_arg_t, const A&) <del>noexcept</del>;
|
|
</pre>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-2- <i>Postconditions</i>: <tt>!*this</tt>.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<pre>
|
|
function(nullptr_t) noexcept;
|
|
template <class A> function(allocator_arg_t, const A&, nullptr_t) <del>noexcept</del>;
|
|
</pre>
|
|
|
|
<blockquote><p>
|
|
-3- <i>Postconditions</i>: <tt>!*this</tt>.
|
|
</p></blockquote>
|
|
|
|
<pre>
|
|
function(const function& f);
|
|
<del>template <class A> function(allocator_arg_t, const A& a, const function& f);</del>
|
|
</pre>
|
|
|
|
<blockquote><p>
|
|
-4- <i>Postconditions</i>: <tt>!*this</tt> if <tt>!f</tt>; otherwise, <tt>*this</tt> targets a copy of <tt>f.target()</tt>.
|
|
</p>
|
|
|
|
<p>
|
|
-5- <i>Throws</i>: shall not throw exceptions if <tt>f</tt>'s target is a callable object passed
|
|
via <tt>reference_wrapper</tt> or a function pointer. Otherwise, may throw <tt>bad_alloc</tt>
|
|
or any exception thrown by the copy constructor of the stored callable
|
|
object. [<i>Note</i>: Implementations are encouraged to avoid the use of
|
|
dynamically allocated memory for small callable objects, for example, where
|
|
<tt>f</tt>'s target is an object holding only a pointer or reference to an object and
|
|
a member function pointer. — <i>end note</i>]
|
|
</p></blockquote>
|
|
|
|
<pre>
|
|
<ins>template <class A> function(allocator_arg_t, const A& a, const function& f);</ins>
|
|
</pre>
|
|
|
|
<blockquote><p>
|
|
<ins>-?- <i>Postconditions</i>: <tt>!*this</tt> if <tt>!f</tt>; otherwise, <tt>*this</tt> targets a copy of <tt>f.target()</tt>.</ins>
|
|
</p></blockquote>
|
|
|
|
<pre>
|
|
function(function&& f);
|
|
template <class A> function(allocator_arg_t, const A& a, function&& f);
|
|
</pre>
|
|
|
|
<blockquote><p>
|
|
-6- <i>Effects</i>: If <tt>!f</tt>, <tt>*this</tt> has no target; otherwise, move-constructs the target
|
|
of <tt>f</tt> into the target of <tt>*this</tt>, leaving <tt>f</tt> in a valid state with an
|
|
unspecified value. <ins>If an allocator is not specified, the constructed function will use the same allocator as <tt>f</tt>.</ins>
|
|
</p></blockquote>
|
|
|
|
<pre>
|
|
template<class F> function(F f);
|
|
template <class F, class A> function(allocator_arg_t, const A& a, F f);
|
|
</pre>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-7- <i>Requires</i>: <tt>F</tt> shall be <tt>CopyConstructible</tt>.
|
|
<p/>
|
|
-8- <i>Remarks</i>: These constructors shall not participate in overload resolution unless <tt>f</tt> is Callable (20.9.11.2)
|
|
for argument types <tt>ArgTypes...</tt> and return type <tt>R</tt>.
|
|
</p>
|
|
|
|
<p>
|
|
-9- <i>Postconditions</i>: <tt>!*this</tt> if any of the following hold:
|
|
</p>
|
|
<ul>
|
|
<li><p><tt>f</tt> is a null function pointer value.</p></li>
|
|
<li><p><tt>f</tt> is a null member pointer value.</p></li>
|
|
<li><p><tt>F</tt> is an instance of the function class template, and <tt>!f</tt></p></li>
|
|
</ul>
|
|
|
|
<p>
|
|
-10- Otherwise, <tt>*this</tt> targets a copy of <tt>f</tt> initialized with <tt>std::move(f)</tt>.
|
|
[<i>Note</i>: Implementations are encouraged to avoid the use of dynamically
|
|
allocated memory for small callable objects, for example, where <tt>f</tt>'s target
|
|
is an object holding only a pointer or reference to an object and a member
|
|
function pointer. — <i>end note</i>]
|
|
</p>
|
|
|
|
<p>
|
|
-11- <i>Throws</i>: shall not throw exceptions when <ins>an allocator is not specified
|
|
and</ins> <tt>f</tt> is a function pointer or a <tt>reference_wrapper<T></tt> for some
|
|
<tt>T</tt>. Otherwise, may throw <tt>bad_alloc</tt> or any exception thrown by <tt>F</tt>'s copy or
|
|
move constructor<ins> or by <tt>A</tt>'s allocate function</ins>.
|
|
</p>
|
|
</blockquote>
|
|
|
|
</blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2372"></a>2372. Assignment from int to <tt>std::string</tt></h3>
|
|
<p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Andrzej Krzemieński <b>Opened:</b> 2014-03-13 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#basic.string">issues</a> in [basic.string].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The following code works in C++:
|
|
</p>
|
|
<blockquote><pre>
|
|
int i = 300;
|
|
std::string threeHundred;
|
|
threeHundred = i;
|
|
</pre></blockquote>
|
|
<p>
|
|
"Works" == "Compiles and doesn't have an undefined behavior". But it may not be obvious and in fact misleading what it does.
|
|
This assignment converts an <tt>int</tt> to <tt>char</tt> and then uses <tt>string</tt>'s assignment from <tt>char</tt>. While
|
|
the assignment from <tt>char</tt> can be considered a feature, being able to assign from an int looks like a safety gap. Someone
|
|
may believe C++ works like "dynamically typed" languages and expect a lexical conversion to take place.
|
|
<p/>
|
|
Ideally the assignment from <tt>char</tt> could be deprecated and later removed, but as a less intrusive alternative one could
|
|
consider adding a SFINAEd deleted function template:
|
|
</p>
|
|
<blockquote><pre>
|
|
template <typename IntT> // enable if is_integral<IntT>::value
|
|
basic_string& operator=(IntT) = delete;
|
|
</pre></blockquote>
|
|
|
|
<p><i>[Lenexa 2015-06-06: Move to LEWG]</i></p>
|
|
|
|
<p>RS: std::string x('0' + n); broken by this.</p>
|
|
<p>MC: This is an extension, move to LEWG.</p>
|
|
<p>Move to LEWG, consensus.</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>To 21.4 [basic.string], class template <tt>basic_string</tt> synopsis, add as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
basic_string& operator=(const basic_string& str);
|
|
basic_string& operator=(basic_string&& str) noexcept;
|
|
basic_string& operator=(const charT* s);
|
|
basic_string& operator=(charT c);
|
|
<ins>template <class IntT> basic_string& operator=(IntT i) = delete;</ins>
|
|
basic_string& operator=(initializer_list<charT>);
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li><p>Add after 21.4.2 [string.cons] p26 as indicated:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
basic_string& operator=(charT c);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-26- <i>Returns</i>: <tt>*this = basic_string(1,c)</tt>.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<pre>
|
|
<ins>template <class IntT> basic_string& operator=(IntT i) = delete;</ins>
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
<ins>-?- <i>Remarks</i>: This signature shall not participate in overload resolution unless <tt>is_integral<T>::value</tt> is
|
|
<tt>true</tt>.</ins>
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2375"></a>2375. Is [iterator.requirements.general]/9 too broadly applied?</h3>
|
|
<p><b>Section:</b> 24.2.1 [iterator.requirements.general] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Marshall Clow <b>Opened:</b> 2014-03-25 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
24.2.1 [iterator.requirements.general] p9 says:
|
|
</p>
|
|
<blockquote><p>
|
|
Destruction of an iterator may invalidate pointers and references previously obtained from that iterator.
|
|
</p></blockquote>
|
|
<p>
|
|
But the resolution of LWG issue <a href="lwg-defects.html#2360">2360</a> specifically advocates returning <tt>*--temp;</tt> where <tt>temp</tt> is a
|
|
local variable.
|
|
<p/>
|
|
And 24.2.5 [forward.iterators] p6 says:
|
|
</p>
|
|
<blockquote><p>
|
|
If <tt>a</tt> and <tt>b</tt> are both dereferenceable, then <tt>a == b</tt> if and only if <tt>*a</tt> and <tt>*b</tt> are bound
|
|
to the same object.
|
|
</p></blockquote>
|
|
<p>
|
|
which disallows "stashing" iterators (i.e, iterators that refer to data inside themselves).
|
|
<p/>
|
|
So, I suspect that the restriction in p9 should only apply to input iterators, and can probably be moved into
|
|
24.2.3 [input.iterators] instead of 24.2.1 [iterator.requirements.general].
|
|
</p>
|
|
|
|
<p><i>[2014-05-22, Daniel comments]</i></p>
|
|
|
|
|
|
<p>
|
|
Given that forward iterators (and beyond) are refinements of input iterator, moving this constraint to input iterators won't help
|
|
much because it would still hold for all refined forms.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2379"></a>2379. Obtaining native handle of the current thread</h3>
|
|
<p><b>Section:</b> 30.2.3 [thread.req.native], 30.3.2 [thread.thread.this] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Matt Austern <b>Opened:</b> 2014-03-31 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Class <tt>thread</tt> contains an implementation-defined type <tt>thread::native_handle_type</tt>, and an implementation-defined
|
|
function <tt>thread::native_handle()</tt> that returns a value of that type. The presence and semantics of those members is
|
|
implementation-defined; the intention is that they can be used for interoperability with libraries that rely on operating system
|
|
specific features. (Posix libraries that accept arguments of type <tt>pthread_t</tt>, for example.)
|
|
<p/>
|
|
Unfortunately, there appears to be no native handle support for the equivalent of <tt>pthread_self()</tt>. We can use
|
|
<tt>this_thread::get_id()</tt> to obtain the <tt>thread::id</tt> of the current thread, but there is no mechanism for converting
|
|
a <tt>thread::id</tt> to a <tt>thread::native_handle</tt>.
|
|
<p/>
|
|
<em>Proposed wording:</em>
|
|
<p/>
|
|
In 30.3.2 [thread.thread.this] add:
|
|
</p>
|
|
<blockquote><pre>
|
|
thread::native_handle_type native_handle(); <i>// See 30.2.3</i>
|
|
</pre></blockquote>
|
|
<p>
|
|
to the <tt>this_thread</tt> namespace synopsis.
|
|
<p/>
|
|
<em>Rationale:</em>
|
|
<p/>
|
|
Informally, we could address this issue either by adding a new function in <tt>this_thread</tt> or by providing a mechanism for converting
|
|
between <tt>thread::id</tt> and <tt>thread::native_handle</tt>. I propose the former because it seems more localized, and doesn't involve
|
|
saying anything more about implementation defined native functionality than we currently do.
|
|
<p/>
|
|
It's intentional that the proposed resolution adds a declaration of <tt>native_handle()</tt> without adding a paragraph explaining what
|
|
it does. This is because everything about <tt>native_handle()</tt> is implementation-defined. The standard does the same thing in
|
|
30.3.1.5 [thread.thread.member].
|
|
</p>
|
|
|
|
<p><i>[2015-02 Cologne]</i></p>
|
|
|
|
<p>
|
|
Handed over to SG1.
|
|
</p>
|
|
|
|
<p><i>[2015-05 Lenexa, SG1 response]</i></p>
|
|
|
|
<p>
|
|
Strong "don't care" reaction from SG1, after pointing out that this only matters in non-portable code, which can call pthread_self() or the like anyway, but the change also doesn't add any non-trivial implementation requirements. This defused initial strong opinions on both sides. Since this is essentially a feature request, we did not have sufficient consensus to proceed at this point. There was a feeling we should reconsider after making more sense out of the much more general TLS issues we have been discussing.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 30.2.3 [thread.req.native] p1 as indicated:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-1- <del>Several classes described in this Clause have members</del><ins>This Clause includes several members named</ins>
|
|
<tt>native_handle_type</tt> and <tt>native_handle</tt>. The presence of these members and their semantics is
|
|
implementation-defined. […]
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>In 30.3 [thread.threads], header <tt><thread></tt> synopsis, add:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
namespace std {
|
|
[…]
|
|
namespace this_thread {
|
|
thread::id get_id() noexcept;
|
|
<ins>thread::native_handle_type native_handle();</ins>
|
|
[…]
|
|
}
|
|
}
|
|
</pre>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>In 30.3.2 [thread.thread.this] add:</p>
|
|
<blockquote>
|
|
<pre>
|
|
namespace std {
|
|
namespace this_thread {
|
|
thread::id get_id() noexcept;
|
|
<ins>thread::native_handle_type native_handle(); <i>// See 30.2.3 [thread.req.native]</i></ins>
|
|
[…]
|
|
}
|
|
}
|
|
</pre>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2380"></a>2380. May <tt><cstdlib></tt> provide <tt>long ::abs(long)</tt> and <tt>long long ::abs(long long)</tt>?</h3>
|
|
<p><b>Section:</b> 17.6.1.2 [headers] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Richard Smith <b>Opened:</b> 2014-03-31 <b>Last modified:</b> 2015-05-05</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#headers">issues</a> in [headers].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
D.5 [depr.c.headers] p3 says:
|
|
</p>
|
|
<blockquote><p>
|
|
[<i>Example</i>: The header <tt><cstdlib></tt> assuredly provides its declarations and definitions within the namespace
|
|
<tt>std</tt>. It may also provide these names within the global namespace. The header <tt><stdlib.h></tt> assuredly
|
|
provides the same declarations and definitions within the global namespace, much as in the C Standard. It
|
|
may also provide these names within the namespace <tt>std</tt>. — <i>end example</i>]
|
|
</p></blockquote>
|
|
<p>
|
|
This suggests that <tt><cstdlib></tt> may provide <tt>::abs(long)</tt> and <tt>::abs(long long)</tt>. But this seems like
|
|
it might contradict the normative wording of 17.6.1.2 [headers] p4:
|
|
</p>
|
|
<blockquote><p>
|
|
Except as noted in Clauses 18 through 30 and Annex D, the contents of each header <tt>c<em>name</em></tt> shall be the same
|
|
as that of the corresponding header <tt><em>name</em>.h</tt>, as specified in the C standard library (1.2) or the C Unicode
|
|
TR, as appropriate, as if by inclusion. In the C++ standard library, however, the declarations (except for
|
|
names which are defined as macros in C) are within namespace scope (3.3.6) of the namespace <tt>std</tt>. It is
|
|
unspecified whether these names are first declared within the global namespace scope and are then injected
|
|
into namespace <tt>std</tt> by explicit using-declarations (7.3.3).
|
|
</p></blockquote>
|
|
<p>
|
|
Note that this allows <tt><cstdlib></tt> to provide <tt>::abs(int)</tt>, but does not obviously allow <tt>::abs(long)</tt>
|
|
nor <tt>::abs(long long)</tt>, since they are not part of the header <tt>stdlib.h</tt> as specified in the C standard library.
|
|
<p/>
|
|
26.8 [c.math] p7 adds signatures <tt>std::abs(long)</tt> and <tt>std::abs(long long)</tt>, but not in a way that seems
|
|
to allow <tt>::abs(long)</tt> and <tt>::abs(long long)</tt> to be provided.
|
|
<p/>
|
|
I think the right approach here would be to allow <tt><cstdlib></tt> to either provide no <tt>::abs</tt> declaration, or
|
|
to provide all three declarations from namespace <tt>std</tt>, but it should not be permitted to provide only <tt>int abs(int)</tt>.
|
|
Suggestion:
|
|
<p/>
|
|
Change in 17.6.1.2 [headers] p4:
|
|
</p>
|
|
<blockquote><p>
|
|
[…]. It is unspecified whether these names <ins>(including any overloads added in Clauses 18 through 30 and Annex D)</ins>
|
|
are first declared within the global namespace scope and are then injected into namespace <tt>std</tt> by explicit using-declarations
|
|
(7.3.3).
|
|
</p></blockquote>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
MC: do we need to defer this?<br/>
|
|
PJP: just need to get my mind around it, already playing dirty games here, my reaction is just do it as it will help C++<br/>
|
|
STL: this is safe<br/>
|
|
TP: would be surprising if using abs didn't bring in all of the overloads<br/>
|
|
MC: that's Richard's argument<br/>
|
|
MC: move to ready
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Modify 17.6.1.2 [headers] p4 as indicated:</p>
|
|
|
|
<blockquote><p>
|
|
Except as noted in Clauses 18 through 30 and Annex D, the contents of each header <tt>c<em>name</em></tt> shall be the same
|
|
as that of the corresponding header <tt><em>name</em>.h</tt>, as specified in the C standard library (1.2) or the C Unicode
|
|
TR, as appropriate, as if by inclusion. In the C++ standard library, however, the declarations (except for
|
|
names which are defined as macros in C) are within namespace scope (3.3.6) of the namespace <tt>std</tt>. It is
|
|
unspecified whether these names <ins>(including any overloads added in Clauses 18 through 30 and Annex D)</ins> are first
|
|
declared within the global namespace scope and are then injected into namespace <tt>std</tt> by explicit using-declarations (7.3.3).
|
|
</p></blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2381"></a>2381. Inconsistency in parsing floating point numbers</h3>
|
|
<p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Marshall Clow <b>Opened:</b> 2014-04-30 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
In 22.4.2.1.2 [facet.num.get.virtuals] we have:
|
|
</p>
|
|
<blockquote><p>
|
|
Stage 3: The sequence of chars accumulated in stage 2 (the field) is converted to a numeric value by the
|
|
rules of one of the functions declared in the header <tt><cstdlib></tt>:
|
|
</p>
|
|
<ul>
|
|
<li><p>For a signed integer value, the function <tt>strtoll</tt>.</p></li>
|
|
<li><p>For an unsigned integer value, the function <tt>strtoull</tt>.</p></li>
|
|
<li><p>For a floating-point value, the function <tt>strtold</tt>.</p></li>
|
|
</ul>
|
|
</blockquote>
|
|
<p>
|
|
This implies that for many cases, this routine should return true:
|
|
</p>
|
|
<blockquote><pre>
|
|
bool is_same(const char* p)
|
|
{
|
|
std::string str{p};
|
|
double val1 = std::strtod(str.c_str(), nullptr);
|
|
std::stringstream ss(str);
|
|
double val2;
|
|
ss >> val2;
|
|
return std::isinf(val1) == std::isinf(val2) && // either they're both infinity
|
|
std::isnan(val1) == std::isnan(val2) && // or they're both NaN
|
|
(std::isinf(val1) || std::isnan(val1) || val1 == val2); // or they're equal
|
|
}
|
|
</pre></blockquote>
|
|
<p>
|
|
and this is indeed true, for many strings:
|
|
</p>
|
|
<blockquote><pre>
|
|
assert(is_same("0"));
|
|
assert(is_same("1.0"));
|
|
assert(is_same("-1.0"));
|
|
assert(is_same("100.123"));
|
|
assert(is_same("1234.456e89"));
|
|
</pre></blockquote>
|
|
<p>
|
|
but not for others
|
|
</p>
|
|
<blockquote><pre>
|
|
assert(is_same("0xABp-4")); // hex float
|
|
assert(is_same("inf"));
|
|
assert(is_same("+inf"));
|
|
assert(is_same("-inf"));
|
|
assert(is_same("nan"));
|
|
assert(is_same("+nan"));
|
|
assert(is_same("-nan"));
|
|
|
|
assert(is_same("infinity"));
|
|
assert(is_same("+infinity"));
|
|
assert(is_same("-infinity"));
|
|
</pre></blockquote>
|
|
<p>
|
|
These are all strings that are correctly parsed by <tt>std::strtod</tt>, but not by the stream extraction operators.
|
|
They contain characters that are deemed invalid in stage 2 of parsing.
|
|
<p/>
|
|
If we're going to say that we're converting by the rules of <tt>strtold</tt>, then we should accept all the things that
|
|
<tt>strtold</tt> accepts.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2383"></a>2383. Overflow cannot be ill-formed for chrono::duration integer literals</h3>
|
|
<p><b>Section:</b> 20.12.5.8 [time.duration.literals] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2014-05-16 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
20.12.5.8 [time.duration.literals] p3 says:
|
|
</p>
|
|
<blockquote><p>
|
|
If any of these suffixes are applied to an integer literal and the
|
|
resulting <tt>chrono::duration</tt> value cannot be represented in the result
|
|
type because of overflow, the program is ill-formed.
|
|
</p></blockquote>
|
|
<p>
|
|
Ill-formed requires a diagnostic at compile-time, but there is no way
|
|
to detect the overflow from <tt>unsigned long long</tt> to the <tt>signed
|
|
duration<>::rep</tt> type.
|
|
<p/>
|
|
Overflow could be detected if the duration integer literals were
|
|
literal operator templates, otherwise overflow can either be undefined
|
|
or a run-time error, not ill-formed.
|
|
</p>
|
|
|
|
<p><i>[Urbana 2014-11-07: Move to Open]</i></p>
|
|
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2384"></a>2384. Allocator's <tt>deallocate</tt> function needs better specification</h3>
|
|
<p><b>Section:</b> 17.6.3.5 [allocator.requirements] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2014-05-19 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
According to Table 28, 17.6.3.5 [allocator.requirements], an <tt>Allocator</tt>'s <tt>deallocate</tt>
|
|
function is specified as follows:
|
|
</p>
|
|
<blockquote><p>
|
|
All <tt>n</tt> <tt>T</tt> objects in the area
|
|
pointed to by <tt>p</tt> shall be
|
|
destroyed prior to this call. <tt>n</tt>
|
|
shall match the value passed to
|
|
allocate to obtain this
|
|
memory. Does not throw
|
|
exceptions. [<i>Note</i>: <tt>p</tt> shall not be
|
|
singular. — <i>end note</i>]
|
|
</p></blockquote>
|
|
<p>
|
|
This wording is confusing in regard to the following points:
|
|
</p>
|
|
<ol>
|
|
<li><p>This specification does not make clear that the result of an <tt>allocate</tt>
|
|
call can only be returned once to the <tt>deallocate</tt> function. This is much
|
|
clearer expressed for <tt>operator delete</tt> (18.6.1.1 [new.delete.single] p12, emphasis mine):</p>
|
|
<blockquote><p>
|
|
<i>Requires</i>: <tt>ptr</tt> shall be a null pointer or <span style="color:#C80000;font-weight:bold">its value shall be a value returned
|
|
by an earlier call to</span> the (possibly replaced) <span style="color:#C80000;font-weight:bold"><tt>operator new(std::size_t)</tt> or
|
|
<tt>operator new(std::size_t,const std::nothrow_t&)</tt> which has not been invalidated
|
|
by an intervening call to <tt>operator delete(void*)</tt></span>.
|
|
</p></blockquote>
|
|
</li>
|
|
<li><p>The intended meaning of that wording was to say that <tt>deallocate</tt> shall accept <em>every</em> result value
|
|
that had been returned by a corresponding call to <tt>allocate</tt>, this includes also a possible result of a
|
|
null pointer value, which is possible ("[<i>Note</i>: If <tt>n == 0</tt>, the return value is unspecified.
|
|
— <i>end note</i>]"). Unfortunately the <tt>deallocate</tt> function uses a non-normative note ("<tt>p</tt> shall not be
|
|
singular.") which refers to the fuzzy term <tt>singular</tt>, that is one of the most unclear and misunderstood terms
|
|
of the library, as pointed out in <a href="lwg-active.html#1213">1213</a>. The occurrence of this term has lead to the possible understanding,
|
|
that this function would never allow null pointer values. Albeit for allocators the intention had not been to require the support
|
|
<em>in general</em> that a null pointer value can be provided to <tt>deallocate</tt> (as it is allowed for <tt>std::free</tt>
|
|
and <tt>operator delete</tt>), the mental model was that <em>every</em> returned value of <tt>allocate</tt> shall be an
|
|
acceptable argument type of the corresponding <tt>deallocate</tt> function.
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>
|
|
This issue is not intending to enforce a specific meaning of <em>singular</em> iterator values, but the assertion is
|
|
that this note does more harm than good. In addition to wording from <tt>operator delete</tt> there is no longer any need
|
|
to obfuscate the normative wording.
|
|
</p>
|
|
|
|
<p><i>[2014-05-24 Alisdair comments]</i></p>
|
|
|
|
|
|
<p>
|
|
Now that I am reading it very precisely, there is another mis-stated assumption
|
|
as a precondition for <tt>deallocate</tt>:
|
|
</p>
|
|
<blockquote><p>
|
|
All <tt>n T</tt> objects in the area pointed to by <tt>p</tt> shall be destroyed prior to this call.
|
|
</p></blockquote>
|
|
<p>
|
|
This makes a poor assumption that every possible object in the allocated buffer
|
|
was indeed constructed, but this is often not the case, e.g., a <tt>vector</tt> that is not
|
|
filled to capacity. We should require calling the destructor for only those objects
|
|
actually constructed in the buffer, which may be fewer than <tt>n</tt>, or even 0.
|
|
<p/>
|
|
I wonder if we really require all objects to be destroyed before calling <tt>deallocate</tt>
|
|
though. Are we really so concerned about leaking objects that might not manage
|
|
resources? Should this not be the proper concern of the library managing the
|
|
objects and memory?
|
|
</p>
|
|
|
|
<p><i>[2014-06-05 Daniel responds and improves wording]</i></p>
|
|
|
|
|
|
<p>
|
|
I fully agree with the last comment and I think that this requirement should be removed. We have no such
|
|
requirements for comparable functions such as <tt>operator delete</tt> or <tt>return_temporary_buffer()</tt>,
|
|
and this wording seems to be a wording rudiment that exists since C++98.
|
|
</p>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
Marshall: What do people think about this?<br/>
|
|
PJP: Sure.<br/>
|
|
Wakely: Love it.<br/>
|
|
Marshall: Ready?<br/>
|
|
Everyone agrees.<br/>
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Change Table 28 ("<tt>Allocator</tt> requirements") as indicated:</p>
|
|
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 28 — <tt>Allocator</tt> requirements</caption>
|
|
<tr>
|
|
<th align="center">Expression</th>
|
|
<th align="center">Return type</th>
|
|
<th align="center">Assertion/note<br/>pre-/post-condition</th>
|
|
<th align="center">Default</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="4" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a.deallocate(p,n)</tt>
|
|
</td>
|
|
<td>
|
|
(not used)
|
|
</td>
|
|
<td>
|
|
<ins><i>Pre</i>: <tt>p</tt> shall be a value returned by an earlier<br/>
|
|
call to <tt>allocate</tt> which has not been invalidated by<br/>
|
|
an intervening call to <tt>deallocate</tt>. <tt>n</tt> shall<br/>
|
|
match the value passed to <tt>allocate</tt> to obtain this<br/>
|
|
memory.</ins> <del>All <tt>n T</tt> objects in the area pointed to by<br/>
|
|
<tt>p</tt> shall be destroyed prior to this call.</del><br/>
|
|
<ins><i>Throws</i>: Nothing.</ins><del><tt>n</tt><br/>
|
|
shall match the value passed to<br/>
|
|
allocate to obtain this<br/>
|
|
memory. Does not throw<br/>
|
|
exceptions. [<i>Note</i>: <tt>p</tt> shall not<br/>
|
|
be singular. — <i>end note</i>]</del>
|
|
</td>
|
|
<td>
|
|
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="4" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote>
|
|
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2385"></a>2385. <tt>function::assign</tt> allocator argument doesn't make sense</h3>
|
|
<p><b>Section:</b> 20.9.12.2 [func.wrap.func] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2014-05-23 <b>Last modified:</b> 2015-05-07</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The definition of <tt>function::assign</tt> in N3936 is:
|
|
</p>
|
|
<blockquote><pre>
|
|
template<class F, class A>
|
|
void assign(F&& f, const A& a);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
<i>Effects</i>: <tt>function(allocator_arg, a, std::forward<F>(f)).swap(*this)</tt>
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
<p>
|
|
This definition is flawed in several respects:
|
|
</p>
|
|
<ol>
|
|
<li><p>The interface implies that the intent is to replace the allocator in <tt>*this</tt>
|
|
with the specified allocator, <tt>a</tt>. Such functionality is unique in the
|
|
standard and is problematic when creating, e.g. a container of function
|
|
objects, all using the same allocator.</p>
|
|
</li>
|
|
<li><p>The current definition of <tt>swap()</tt> makes it unclear whether the objects being
|
|
swapped can have different allocators. The general practice is that
|
|
allocators must be equal in order to support swap, and this practice is
|
|
reinforced by the proposed library TS. Thus, the definition of <tt>assign</tt> would
|
|
have undefined behavior unless the allocator matched the allocator already
|
|
within function.
|
|
</p>
|
|
</li>
|
|
<li><p>
|
|
The general rule for members of function is to supply the allocator before
|
|
the functor, using the <tt>allocator_arg</tt> prefix. Supplying the allocator as a
|
|
second argument, without the <tt>allocator_arg</tt> prefix is error prone and
|
|
confusing.
|
|
</p></li>
|
|
</ol>
|
|
|
|
<p>
|
|
I believe that this ill-conceived interface was introduced in the effort to
|
|
add allocators to parts of the standard where it had been missing, when we
|
|
were unpracticed in the right way to accomplish that. Allocators were added
|
|
to function at a time when the allocator model was in flux and it was the
|
|
first class in the standard after <tt>shared_ptr</tt> to use type-erased allocators, so
|
|
it is not surprising to see some errors in specification here. (<tt>shared_ptr</tt> is
|
|
a special case because of its shared semantics, and so is not a good model.)
|
|
<p/>
|
|
The main question is whether this member should be specified with better
|
|
precision or whether it should be deprecated/removed. The only way I can see to
|
|
give a "reasonable" meaning to the existing interface is to describe it in
|
|
terms of destroying and re-constructing <tt>*this</tt>:
|
|
</p>
|
|
<blockquote><pre>
|
|
function temp(allocator_arg, a, std::forward<F>(f));
|
|
this->~function();
|
|
::new(this) function(std::move(temp));
|
|
</pre></blockquote>
|
|
<p>
|
|
(The temp variable is needed for exception safety). The ugliness of this
|
|
specification underscores the ugliness of the concept. What is the purpose of
|
|
this member other than to reconstruct the object from scratch, a facility that
|
|
library classes do not generally provide? Programmers are always free to
|
|
destroy and re-construct objects — there is no reason why function should
|
|
make that especially easy.
|
|
<p/>
|
|
I propose, therefore, that we make no attempt at giving the current interface
|
|
a meaningful definition of questionable utility, but simply get rid of it
|
|
all together. This leaves us with only two questions:
|
|
</p>
|
|
<ol>
|
|
<li><p>Should we deprecate the interface or just remove it?</p></li>
|
|
<li><p>Should we replace it with an <tt>assign(f)</tt> member that doesn't take an
|
|
allocator?</p></li>
|
|
</ol>
|
|
<p>
|
|
Of these four combinations of binary answers to the above questions, I think
|
|
the ones that make the most sense are (remove, no) and (deprecate, yes). The
|
|
proposed new interface provides nothing that <tt>operator=</tt> does not already
|
|
provide. However, if the old (deprecated) interface remains, then having the
|
|
new interface will guide the programmer away from it.
|
|
<p/>
|
|
The proposed wording below assumes deprecation. If we choose removal, then
|
|
there is no wording needed; simply remove the offending declaration and
|
|
definition.
|
|
</p>
|
|
|
|
<p>
|
|
<strong>Previous resolution [SUPERSEDED]:</strong>
|
|
</p>
|
|
<blockquote class="note">
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Change class template <tt>function</tt> synopsis, 20.9.12.2 [func.wrap.func], as indicated:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
template<class R, class... ArgTypes>
|
|
class function<R(ArgTypes...)> {
|
|
[…]
|
|
<i>// 20.9.11.2.2, function modifiers:</i>
|
|
void swap(function&) noexcept;
|
|
template<class F<del>, class A</del>> void assign(F&&<del>, const A&</del>);
|
|
[…]
|
|
};
|
|
</pre>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 20.9.12.2.2 [func.wrap.func.mod] as indicated:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
template<class F<del>, class A</del>> void assign(F&& f<del>, const A& a</del>);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
<i>Effects</i>: <tt><ins>*this = forward<F>(f);</ins><del>function(allocator_arg, a, std::forward<F>(f)).swap(*this)</del></tt>
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>To deprecation section [depr.function.objects], add the following new sub-clause:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<b>Old <tt>assign</tt> member of polymorphic function wrappers [depr.function.objects.assign]</b>
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
namespace std{
|
|
template<class R, class... ArgTypes>
|
|
class function<R(ArgTypes...)> {
|
|
<i>// remainder unchanged</i>
|
|
template<class F, class A> void assign(F&& f, const A& a);
|
|
[…]
|
|
};
|
|
}
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
The two-argument form of <tt>assign</tt> is defined as follows:
|
|
</p>
|
|
<pre>
|
|
template<class F, class A> void assign(F&& f, const A& a);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
<i>Requires</i>: <tt>a</tt> shall be equivalent to the allocator used to construct <tt>*this</tt>.
|
|
<p/>
|
|
<i>Effects</i>: <tt>this->assign(forward<F>(f));</tt>
|
|
</p>
|
|
</blockquote>
|
|
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
</blockquote>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
STL: I would ask, does anybody oppose removing this outright?<br/>
|
|
Wakely: I don't even have this signature.<br/>
|
|
Hwrd: And I think this doesn't go far enough, even more should be removed. This is a step in the right direction.<br/>
|
|
PJP: I'm in favor of removal.<br/>
|
|
Wakely: We've already got TS1 that has a new function that does it right. We could wait for feedback on that.
|
|
I think this issue should be taken now.<br/>
|
|
Marshall: Then the goal will be to move to ready.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N4431.</p>
|
|
|
|
<ol>
|
|
<li><p>Change class template <tt>function</tt> synopsis, 20.9.12.2 [func.wrap.func], as indicated:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
template<class R, class... ArgTypes>
|
|
class function<R(ArgTypes...)> {
|
|
[…]
|
|
<i>// 20.9.12.2.2, function modifiers:</i>
|
|
void swap(function&) noexcept;
|
|
<del>template<class F, class A> void assign(F&&, const A&);</del>
|
|
[…]
|
|
};
|
|
</pre>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 20.9.12.2.2 [func.wrap.func.mod] as indicated:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
<del>template<class F, class A>
|
|
void assign(F&& f, const A& a);</del>
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
<del>-2- <i>Effects</i>: <tt>function(allocator_arg, a, std::forward<F>(f)).swap(*this)</tt></del>
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2391"></a>2391. <tt>basic_string</tt> is missing non-<tt>const</tt> <tt>data()</tt></h3>
|
|
<p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Michael Bradshaw <b>Opened:</b> 2014-05-27 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#basic.string">issues</a> in [basic.string].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Regarding 21.4 [basic.string], <tt>std::basic_string<charT>::data()</tt> returns a <tt>const charT*</tt>
|
|
21.4.7.1 [string.accessors]. While this method is convenient, it doesn't quite match <tt>std::array<T>::data()</tt>
|
|
23.3.2.5 [array.data] or <tt>std::vector<T>::data()</tt> 23.3.6.4 [vector.data], both of which provide two
|
|
versions (that return <tt>T*</tt> or <tt>const T*</tt>). An additional <tt>data()</tt> method can be added to
|
|
<tt>std::basic_string</tt> that returns a <tt>charT*</tt> so it can be used in similar situations that <tt>std::array</tt> and
|
|
<tt>std::vector</tt> can be used. Without a non-<tt>const</tt> <tt>data()</tt> method, <tt>std::basic_string</tt> has to be treated
|
|
specially in code that is otherwise oblivious to the container type being used.
|
|
<p/>
|
|
Adding a <tt>charT*</tt> return type to <tt>data()</tt> would be equivalent to doing <tt>&str[0]</tt> or <tt>&str.front()</tt>.
|
|
<p/>
|
|
Small discussion on the issue can be found <a href="http://stackoverflow.com/questions/7518732/why-are-stdvectordata-and-stdstringdata-different">here</a>
|
|
and in the <a href="https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/ll9HuEML6zo/discussion">std-discussion thread</a>
|
|
(which didn't get too much attention).
|
|
<p/>
|
|
This requires a small change to <tt>std::basic_string</tt>'s definition in 21.4 [basic.string] to add the method to
|
|
<tt>std::basic_string</tt>, and another small change in 21.4.7.1 [string.accessors] to define the new method.
|
|
</p>
|
|
|
|
<p><i>[2015-02 Cologne]</i></p>
|
|
|
|
<p>
|
|
Back to LEWG.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Change class template <tt>basic_string</tt> synopsis, 21.4 [basic.string], as indicated:</p>
|
|
<blockquote>
|
|
<pre>
|
|
namespace std {
|
|
template<class charT, class traits = char_traits<charT>,
|
|
class Allocator = allocator<charT> >
|
|
class basic_string {
|
|
public:
|
|
[…]
|
|
<i>// 21.4.7, string operations:</i>
|
|
const charT* c_str() const noexcept;
|
|
const charT* data() const noexcept;
|
|
<ins>charT* data() noexcept;</ins>
|
|
allocator_type get_allocator() const noexcept;
|
|
[…]
|
|
};
|
|
}
|
|
</pre>
|
|
</blockquote>
|
|
|
|
</li>
|
|
|
|
<li><p>Add the following sequence of paragraphs following 21.4.7.1 [string.accessors] p3, as indicated:</p>
|
|
<blockquote>
|
|
<pre>
|
|
<ins>charT* data() noexcept;</ins>
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
<ins>-?- <i>Returns</i>: A pointer <tt>p</tt> such that <tt>p + i == &operator[](i)</tt> for each <tt>i</tt> in <tt>[0,size()]</tt>.</ins>
|
|
<p/>
|
|
<ins>-?- <i>Complexity</i>: Constant time.</ins>
|
|
<p/>
|
|
<ins>-?- <i>Requires</i>: The program shall not alter the value stored at <tt>p + size()</tt>.</ins>
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2392"></a>2392. "character type" is used but not defined</h3>
|
|
<p><b>Section:</b> 17.3 [defns.ntcts], 22.3.1.1.1 [locale.category], 27.2.2 [iostreams.limits.pos], 27.7.3.6.1 [ostream.formatted.reqmts], 27.7.3.6.4 [ostream.inserters.character] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2014-06-01 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The term "character type" is used in 17.3 [defns.ntcts], 22.3.1.1.1 [locale.category],
|
|
27.2.2 [iostreams.limits.pos], 27.7.3.6.1 [ostream.formatted.reqmts], and
|
|
27.7.3.6.4 [ostream.inserters.character], but the core language only defines
|
|
"narrow character types" (3.9.1 [basic.fundamental]).
|
|
<p/>
|
|
"wide-character type" is used in 22.5 [locale.stdcvt], but the core
|
|
language only defines a "wide-character set" and "wide-character literal".
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2393"></a>2393. <tt>std::function</tt>'s <em>Callable</em> definition is broken</h3>
|
|
<p><b>Section:</b> 20.9.12.2 [func.wrap.func] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2014-06-03 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The existing definition of <tt>std::function</tt>'s <em>Callable</em> requirements provided in 20.9.12.2 [func.wrap.func]
|
|
p2,
|
|
</p>
|
|
<blockquote><p>
|
|
A callable object <tt>f</tt> of type <tt>F</tt> is <em>Callable</em> for argument types <tt>ArgTypes</tt> and return type
|
|
<tt>R</tt> if the expression <tt><i>INVOKE</i>(f, declval<ArgTypes>()..., R)</tt>, considered as an unevaluated operand
|
|
(Clause 5), is well formed (20.9.2).
|
|
</p></blockquote>
|
|
<p>
|
|
is defective in several aspects:
|
|
</p>
|
|
<ol style="list-style-type:upper-roman">
|
|
<li><p>The wording can be read to be defined in terms of callable objects, not of callable types.</p>
|
|
</li>
|
|
<li><p>Contrary to that, 20.9.12.2.5 [func.wrap.func.targ] p2 speaks of "<tt>T</tt> shall be a type that is <em>Callable</em>
|
|
(20.9.11.2) for parameter types <tt>ArgTypes</tt> and return type <tt>R</tt>."</p>
|
|
</li>
|
|
<li><p>
|
|
The required value category of the callable object during the call expression (lvalue or rvalue) strongly depends on
|
|
an interpretation of the expression <tt>f</tt> and therefore needs to be specified unambiguously.
|
|
</p></li>
|
|
</ol>
|
|
<p>
|
|
The intention of original <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1402.html">proposal</a>
|
|
(see IIIa. Relaxation of target requirements) was to refer to both types and values ("we say that the function object <tt>f</tt>
|
|
(and its type <tt>F</tt>) is <em>Callable</em> […]"), but that mental model is not really deducible from the
|
|
existing wording. An improved type-dependence wording would also make the sfinae-conditions specified in 20.9.12.2.1 [func.wrap.func.con]
|
|
p8 and p21 ("[…] shall not participate in overload resolution unless <tt>f</tt> is Callable (20.9.11.2)
|
|
for argument types <tt>ArgTypes...</tt> and return type <tt>R</tt>.") easier to interpret.
|
|
<p/>
|
|
My understanding always had been (see e.g. Howard's code example in the 2009-05-01 comment in LWG <a href="lwg-defects.html#815">815</a>), that
|
|
<tt>std::function</tt> invokes the call operator of its target via an <b>lvalue</b>. The required value-category is relevant,
|
|
because it allows to reflect upon whether an callable object such as
|
|
</p>
|
|
<blockquote><pre>
|
|
struct RVF
|
|
{
|
|
void operator()() const && {}
|
|
};
|
|
</pre></blockquote>
|
|
<p>
|
|
would be a feasible target object for <tt>std::function<void()></tt> or not.
|
|
<p/>
|
|
Clarifying the current <em>Callable</em> definition seems also wise to make a future transition to language-based concepts
|
|
easier. A local fix of the current wording is simple to achieve, e.g. by rewriting it as follows:
|
|
</p>
|
|
<blockquote><p>
|
|
A callable <del>object <tt>f</tt> of</del> type <ins>(20.9.1 [func.def])</ins> <tt>F</tt> is <em>Callable</em>
|
|
for argument types <tt>ArgTypes</tt> and return type <tt>R</tt> if the expression <tt><i>INVOKE</i>(<del>f</del><ins>declval<F&>()</ins>,
|
|
declval<ArgTypes>()..., R)</tt>, considered as an unevaluated operand (Clause 5), is well formed (20.9.2).
|
|
</p></blockquote>
|
|
<p>
|
|
It seems appealing to move such a general <em>Callable</em> definition to a more "fundamental" place (e.g. as another
|
|
paragraph of 20.9.1 [func.def]), but the question arises, whether such a more general concept should impose
|
|
the requirement that the call expression is invoked on an <b>lvalue</b> of the callable object — such a
|
|
special condition would also conflict with the more general definition of the <tt>result_of</tt> trait, which
|
|
is defined for either lvalues or rvalues of the callable type <tt>Fn</tt>. In this context I would like to point out that
|
|
"<em>Lvalue-Callable</em>" is not the one and only <em>Callable</em> requirement in the library. Counter examples are
|
|
<tt>std::thread</tt>, <tt>call_once</tt>, or <tt>async</tt>, which depend on "<em>Rvalue-Callable</em>", because they
|
|
all act on functor rvalues, see e.g. 30.3.1.2 [thread.thread.constr]:
|
|
</p>
|
|
<blockquote><p>
|
|
[…] The new thread of execution executes <tt><i>INVOKE</i>(<i>DECAY_COPY</i>(std::forward<F>(f)),
|
|
<i>DECAY_COPY</i>(std::forward<Args>(args))...)</tt> […]
|
|
</p></blockquote>
|
|
<p>
|
|
For every callable object <tt>F</tt>, the result of <tt><i>DECAY_COPY</i></tt> is an rvalue. These implied rvalue function calls are
|
|
no artifacts, but had been deliberately voted for by a Committee decision (see LWG <a href="lwg-defects.html#2021">2021</a>, 2011-06-13 comment)
|
|
and existing implementations respect these constraints correctly. Just to give an example,
|
|
</p>
|
|
<blockquote><pre>
|
|
#include <thread>
|
|
|
|
struct LVF
|
|
{
|
|
void operator()() & {}
|
|
};
|
|
|
|
int main()
|
|
{
|
|
LVF lf;
|
|
std::thread t(lf);
|
|
t.join();
|
|
}
|
|
</pre></blockquote>
|
|
<p>
|
|
is supposed to be rejected.
|
|
<p/>
|
|
The below presented wording changes are suggested to be minimal (still local to <tt>std::function</tt>), but the used approach
|
|
would simplify a future (second) conceptualization or any further generalization of <em>Callable</em> requirements of the Library.
|
|
</p>
|
|
|
|
<p><i>[2015-02 Cologne]</i></p>
|
|
|
|
<p>
|
|
Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4348.html">N4348</a>. Don't touch with a barge pole.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 20.9.12.2 [func.wrap.func] p2 as indicated:</p>
|
|
|
|
<blockquote><p>
|
|
-2- A callable <del>object <tt>f</tt> of</del> type <ins>(20.9.1 [func.def])</ins> <tt>F</tt> is <em><ins>Lvalue-</ins>Callable</em>
|
|
for argument types <tt>ArgTypes</tt> and return type <tt>R</tt> if the expression <tt><i>INVOKE</i>(<del>f</del><ins>declval<F&>()</ins>,
|
|
declval<ArgTypes>()..., R)</tt>, considered as an unevaluated operand (Clause 5), is well formed (20.9.2).
|
|
</p></blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 20.9.12.2.1 [func.wrap.func.con] p8+p21 as indicated:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
template<class F> function(F f);
|
|
template <class F, class A> function(allocator_arg_t, const A& a, F f);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
[…]
|
|
<p/>
|
|
-8- <i>Remarks</i>: These constructors shall not participate in overload resolution unless <tt><del>f</del><ins>F</ins></tt> is
|
|
<tt><ins>Lvalue-</ins>Callable</tt> (20.9.11.2) for argument types <tt>ArgTypes...</tt> and return type <tt>R</tt>.
|
|
</p>
|
|
</blockquote>
|
|
<p>
|
|
[…]
|
|
</p>
|
|
<pre>
|
|
template<class F> function& operator=(F&& f);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
[…]
|
|
<p/>
|
|
-21- <i>Remarks</i>: This assignment operator shall not participate in overload resolution unless
|
|
<tt><del>declval<typename decay<F>::type&>()</del><ins>decay_t<F></ins></tt> is
|
|
<tt><ins>Lvalue-</ins>Callable</tt> (20.9.11.2) for argument types <tt>ArgTypes...</tt> and return type <tt>R</tt>.
|
|
</p>
|
|
</blockquote>
|
|
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 20.9.12.2.5 [func.wrap.func.targ] p2 as indicated: [<i>Editorial comment</i>: Instead of adapting the preconditions
|
|
for the naming change I recommend to strike it completely, because the <tt>target()</tt> functions do not depend on it; the
|
|
corresponding wording exists since its <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1667.pdf">initial proposal</a>
|
|
and it seems without any advantage to me. Assume that some template argument <tt>T</tt> is provided, which does <em>not</em>
|
|
satisfy the requirements: The effect will be that the result is a null pointer value, but that case can happen in other (valid) situations
|
|
as well. — <i>end comment</i>]</p>
|
|
|
|
<blockquote><pre>
|
|
template<class T> T* target() noexcept;
|
|
template<class T> const T* target() const noexcept;
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
<del>-2- <i>Requires</i>: <tt>T</tt> shall be a type that is <tt>Callable</tt> (20.9.11.2) for parameter types
|
|
<tt>ArgTypes</tt> and return type <tt>R</tt>.</del>
|
|
<p/>
|
|
-3- <i>Returns</i>: If <tt>target_type() == typeid(T)</tt> a pointer to the stored function target; otherwise a null
|
|
pointer.
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2394"></a>2394. <tt>locale::name</tt> specification unclear — what is implementation-defined?</h3>
|
|
<p><b>Section:</b> 22.3.1.3 [locale.members] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Richard Smith <b>Opened:</b> 2014-06-09 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#locale.members">issues</a> in [locale.members].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
22.3.1.3 [locale.members] p5 says:
|
|
</p>
|
|
<blockquote><p>
|
|
<i>Returns</i>: The name of <tt>*this</tt>, if it has one; otherwise, the string <tt>"*"</tt>. If <tt>*this</tt> has a name, then
|
|
<tt>locale(name().c_str())</tt> is equivalent to <tt>*this</tt>. Details of the contents of the resulting string are
|
|
otherwise implementation-defined.
|
|
</p></blockquote>
|
|
<p>
|
|
So… what is implementation-defined here, exactly? The first sentence <em>completely</em> defines the behavior of this function
|
|
in all cases.
|
|
<p/>
|
|
Also, the second sentence says (effectively) that all locales with the same name are equivalent: given <tt>L1</tt> and <tt>L2</tt>
|
|
that have the same name <tt>N</tt>, they are both equivalent to <tt>locale(N)</tt>, and since there is no definition of
|
|
"equivalent" specific to <tt>locale</tt>, I assume it's the normal transitive equivalence property, which would imply that
|
|
<tt>L1</tt> is equivalent to <tt>L2</tt>. I'm not sure why this central fact is in the description of <tt>locale::name</tt>, nor
|
|
why it's written in this roundabout way.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2398"></a>2398. <tt>type_info</tt>'s destructor shouldn't be required to be virtual</h3>
|
|
<p><b>Section:</b> 18.7.1 [type.info] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2014-06-14 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#type.info">issues</a> in [type.info].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
<tt>type_info</tt>'s destructor is depicted as being <tt>virtual</tt>, which is nearly unobservable to users (since they can't construct
|
|
or copy this class, they can't usefully derive from it). However, it's technically observable (via <tt>is_polymorphic</tt> and
|
|
<tt>has_virtual_destructor</tt>). It also imposes real costs on implementations, requiring them to store one vptr per
|
|
<tt>type_info</tt> object, when RTTI space consumption is a significant concern.
|
|
<p/>
|
|
Making this implementation-defined wouldn't affect users (who can observe this only if they're specifically looking for it) and
|
|
wouldn't affect implementations who need <tt>virtual</tt> here, but it would allow other implementations to drop <tt>virtual</tt>
|
|
and improve their RTTI space consumption.
|
|
<p/>
|
|
Richard Smith:
|
|
<p/>
|
|
It's observable in a few other ways.
|
|
</p>
|
|
<blockquote><pre>
|
|
std::map<void*, something> m;
|
|
m[dynamic_cast<void*>(&typeid(blah))] = stuff;
|
|
</pre></blockquote>
|
|
<p>
|
|
... is broken by this change, because you can't <tt>dynamic_cast</tt> a non-polymorphic class type to <tt>void*</tt>.
|
|
</p>
|
|
<blockquote><pre>
|
|
type_info& f();
|
|
typeid(f());
|
|
</pre></blockquote>
|
|
<p>
|
|
... evaluates <tt>f()</tt> at runtime without this change, and might not do so with this change.
|
|
<p/>
|
|
These are probably rare things, but I can imagine at least some forms of the latter being used in SFINAE tricks.
|
|
</p>
|
|
|
|
<p><i>[Lenexa 2015-05-05: Move to Open]</i></p>
|
|
|
|
<p>Marshall to poll LEWG for their opinion</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 18.7.1 [type.info] as indicated:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
namespace std {
|
|
class type_info {
|
|
public:
|
|
<del>virtual</del><ins><i>see below</i></ins> ~type_info();
|
|
[…]
|
|
};
|
|
}
|
|
</pre>
|
|
<p>
|
|
-1- The class <tt>type_info</tt> describes type information generated by the implementation. Objects of this class
|
|
effectively store a pointer to a name for the type, and an encoded value suitable for comparing two types for
|
|
equality or collating order. The names, encoding rule, and collating sequence for types are all unspecified
|
|
and may differ between programs. <ins>Whether <tt>~type_info()</tt> is <tt>virtual</tt> is implementation-defined.</ins>
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2402"></a>2402. <tt>basic_string(const basic_string& str, size_type pos, size_type n = npos)</tt> shouldn't use <tt>Allocator()</tt></h3>
|
|
<p><b>Section:</b> 21.4.2 [string.cons] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2014-06-14 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#string.cons">issues</a> in [string.cons].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
21.4.2 [string.cons] p3 specifies:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
basic_string(const basic_string& str, size_type pos, size_type n = npos, const Allocator& a = Allocator());
|
|
</pre>
|
|
<p>
|
|
But this implies that <tt>basic_string(str, pos)</tt> and <tt>basic_string(str, pos, n)</tt> use <tt>Allocator()</tt>
|
|
instead of getting an allocator from <tt>str</tt>.
|
|
<p/>
|
|
21.4.1 [string.require] p3 says "The <tt>Allocator</tt> object used shall be obtained as described in 23.2.1."
|
|
23.2.1 [container.requirements.general] p8 says "Copy constructors for these container types obtain an allocator
|
|
by calling <tt>allocator_traits<allocator_type>::select_on_container_copy_construction</tt> on the allocator
|
|
belonging to the container being copied.", but this isn't exactly a copy constructor. Then it talks about move constructors
|
|
(which this definitely isn't), and finally says that "All other constructors for these container types take a
|
|
<tt>const allocator_type&</tt> argument. […] A copy of this allocator is used for any memory allocation performed".
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p><i>[2015-05-06 Lenexa: move to Open]</i></p>
|
|
|
|
<p>STL: there an allocator right there in str, why default-construct one</p>
|
|
<p>STL: my fix, which may not be right, splits out functions with and without allocators</p>
|
|
<p>JW: there are other ways to propagate the allocator from str to the new object</p>
|
|
<p>PJP: hard to get motivated about this one</p>
|
|
<p>JW: I think this is not a copy operation, this is init'ing a string from a range of characters which happens to originate in a string. It makes it inconsistent with the similar ctor taking a const char pointer, and if we had a std::string_view we wouldn't even have this ctor, and it wouldn't be possible to propagate the allocator.</p>
|
|
<p>STL: but people with stateful allocators want it to propagate</p>
|
|
<p>JW: I think the people using stateful allocators will alter the default behaviour of select_on_container_copy_construction so that it doesn't propagate, but will return a default-constructed one (to ensure a stateful allocator referring to a stack buffer doesn't leak to a region where the stack buffer has gone). So for those people, your proposed change does nothing, it changes one default-constructed allocator to a call to select_on_container_copy_construction which returns a default-constructed allocator. For other people who have different stateful allocators they can still provide the right allocator (whatever that may be) by passing it in.</p>
|
|
<p>STL: OK, that's convincing.</p>
|
|
<p>PJP: I agree with Jonathan</p>
|
|
<p>JW: would like to run both our arguments by Pablo in case I'm totally misrepresenting the expected users of allocator-traits stuff</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 21.4 [basic.string] p5, class template <tt>basic_string</tt> synopsis, as indicated:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
[…]
|
|
<i>// 21.4.2, construct/copy/destroy:</i>
|
|
[…]
|
|
basic_string(basic_string&& str) noexcept;
|
|
<ins>basic_string(const basic_string& str, size_type pos, size_type n = npos);</ins>
|
|
basic_string(const basic_string& str, size_type pos, size_type n<del> = npos</del>,
|
|
const Allocator& a<del> = Allocator()</del>);
|
|
[…]
|
|
</pre>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 21.4.2 [string.cons] around p3 as indicated:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
<ins>basic_string(const basic_string& str,
|
|
size_type pos, size_type n = npos);</ins>
|
|
basic_string(const basic_string& str,
|
|
size_type pos, size_type n<del> = npos</del>,
|
|
const Allocator& a<del> = Allocator()</del>);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
[…]
|
|
<p/>
|
|
-5- <i>Effects</i>: Constructs an object of class <tt>basic_string</tt> and determines the effective length <tt>rlen</tt> of the
|
|
initial string value as the smaller of <tt>n</tt> and <tt>str.size() - pos</tt>, as indicated in Table 65. <ins>The first constructor
|
|
obtains an allocator by calling <tt>allocator_traits<allocator_type>::select_on_container_copy_construction</tt> on the
|
|
allocator belonging to <tt>str</tt>.</ins>
|
|
<p/>
|
|
Table 65 — <ins><tt>basic_string(const basic_string&, size_type, size_type)</tt> and</ins>
|
|
<tt>basic_string(const basic_string&, size_type, size_type, const Allocator&)</tt> effects
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2412"></a>2412. <tt>promise::set_value()</tt> and <tt>promise::get_future()</tt> should not race</h3>
|
|
<p><b>Section:</b> 30.6.5 [futures.promise], 30.6.9.1 [futures.task.members] <b>Status:</b> <a href="lwg-active.html#SG1">SG1</a>
|
|
<b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2014-06-23 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#SG1">SG1</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The following code has a data race according to the standard:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
std::promise<void> p;
|
|
std::thread t{ []{
|
|
p.get_future().wait();
|
|
}};
|
|
p.set_value();
|
|
t.join();
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
The problem is that both <tt>promise::set_value()</tt> and
|
|
<tt>promise::get_future()</tt> are non-const member functions which modify the
|
|
same object, and we only have wording saying that the <tt>set_value()</tt> and
|
|
<tt>wait()</tt> calls (i.e. calls setting and reading the shared state) are
|
|
synchronized.
|
|
<p/>
|
|
The calls don't actually access the same memory locations, so the
|
|
standard should allow it. My suggestion is to state that calling
|
|
<tt>get_future()</tt> does not conflict with calling the various functions that
|
|
make the shared state ready, but clarify with a note that this does
|
|
not imply any synchronization or "happens before", only being free
|
|
from data races.
|
|
</p>
|
|
|
|
<p><i>[2015-02 Cologne]</i></p>
|
|
|
|
<p>
|
|
Handed over to SG1.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 30.6.5 [futures.promise] around p12 as indicated:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
future<R> get_future();
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-12- <i>Returns</i>: A <tt>future<R></tt> object with the same shared state as <tt>*this</tt>.
|
|
<p/>
|
|
<ins>-?- <i>Synchronization</i>: Calls to this function do not conflict (1.10 [intro.multithread])
|
|
with calls to <tt>set_value</tt>, <tt>set_exception</tt>, <tt>set_value_at_thread_exit</tt>, or
|
|
<tt>set_exception_at_thread_exit</tt>. [<i>Note</i>: Such calls need not be synchronized, but implementations
|
|
must ensure they do not introduce data races. — <i>end note</i>]</ins>
|
|
<p/>
|
|
-13- <i>Throws</i>: <tt>future_error</tt> if <tt>*this</tt> has no shared state or if <tt>get_future</tt> has already been called on a
|
|
<tt>promise</tt> with the same shared state as <tt>*this</tt>.
|
|
<p/>
|
|
-14- <i>Error conditions</i>: […]
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 30.6.9.1 [futures.task.members] around p13 as indicated:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
future<R> get_future();
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-13- <i>Returns</i>: A <tt>future<R></tt> object that shares the same shared state as <tt>*this</tt>.
|
|
<p/>
|
|
<ins>-?- <i>Synchronization</i>: Calls to this function do not conflict (1.10 [intro.multithread])
|
|
with calls to <tt>operator()</tt> or <tt>make_ready_at_thread_exit</tt>. [<i>Note</i>: Such calls need not be
|
|
synchronized, but implementations must ensure they do not introduce data races. — <i>end note</i>]</ins>
|
|
<p/>
|
|
-14- <i>Throws</i>: a <tt>future_error</tt> object if an error occurs.
|
|
<p/>
|
|
-15- <i>Error conditions</i>: […]
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2413"></a>2413. <tt>assert</tt> macro is overconstrained</h3>
|
|
<p><b>Section:</b> 19.3 [assertions] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> David Krauss <b>Opened:</b> 2014-06-25 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#assertions">active issues</a> in [assertions].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#assertions">issues</a> in [assertions].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
When <tt>NDEBUG</tt> is defined, <tt>assert</tt> must expand exactly to the token sequence <tt>((void)0)</tt>, with no
|
|
whitespace (C99 §7.2/1 and also C11 §7.2/1). This is a lost opportunity to pass the condition along to the optimizer.
|
|
<p/>
|
|
The user may observe the token sequence using the stringize operator or discriminate it by making a matching <tt>#define</tt>
|
|
directive. There is little chance of practical code doing such things. It's reasonable to allow any expansion that is a <tt>void</tt>
|
|
expression with no side effects or semantic requirements, for example, an extension keyword or an attribute-specifier finagled
|
|
into the context.
|
|
<p/>
|
|
Conforming optimizations would still be limited to treating the condition as hint, not a requirement. Nonconformance on this
|
|
point is quite reasonable though, given user preferences. Anyway, it shouldn't depend on preprocessor quirks.
|
|
<p/>
|
|
As for current practice, Darwin OS <tt><assert.h></tt> provides a GCC-style compiler hint <tt>__builtin_expect</tt> but only in
|
|
debug mode. Shouldn't release mode preserve hints?
|
|
<p/>
|
|
Daniel:
|
|
<p/>
|
|
The corresponding resolution should take care not to conflict with the intention behind LWG <a href="lwg-active.html#2234">2234</a>.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2414"></a>2414. Member function reentrancy should be implementation-defined</h3>
|
|
<p><b>Section:</b> 17.6.5.8 [reentrancy] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2014-07-01 <b>Last modified:</b> 2015-05-05</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#reentrancy">issues</a> in [reentrancy].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
N3936 17.6.5.8 [reentrancy]/1 talks about "functions", but that doesn't address the scenario of calling different member
|
|
functions of a single object. Member functions often have to violate and then re-establish invariants. For example, vectors
|
|
often have "holes" during insertion, and element constructors/destructors/etc. shouldn't be allowed to observe the vector
|
|
while it's in this invariant-violating state. The [reentrancy] Standardese should be extended to cover member functions,
|
|
so that implementers can either say that member function reentrancy is universally prohibited, or selectively allowed for
|
|
very specific scenarios.
|
|
<p/>
|
|
(For clarity, this issue has been split off from LWG <a href="lwg-closed.html#2382">2382</a>.)
|
|
</p>
|
|
|
|
<p><i>[2014-11-03 Urbana]</i></p>
|
|
|
|
<p>
|
|
AJM confirmed with SG1 that they had no special concerns with this issue, and LWG should retain ownership.
|
|
<p/>
|
|
AM: this is too overly broad as it also covers calling the exact same member function on a different object<br/>
|
|
STL: so you insert into a map, and copying the value triggers another insertion into a different map of the same type<br/>
|
|
GR: reentrancy seems to imply the single-threaded case, but needs to consider the multi-threaded case
|
|
<p/>
|
|
Needs more wording.
|
|
</p>
|
|
<p>
|
|
Move to Open
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N3936.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 17.6.5.8 [reentrancy] p1 as indicated:</p>
|
|
<blockquote>
|
|
<p>
|
|
-1- Except where explicitly specified in this standard, it is implementation-defined which functions <ins>(including different
|
|
member functions called on a single object)</ins> in the Standard C++ library may be recursively reentered.
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2417"></a>2417. [fund.ts] <tt>std::experimental::optional::operator<</tt> and <tt>LessThanComparable</tt> requirement</h3>
|
|
<p><b>Section:</b> X [optional.relops], X [optional.comp_with_t] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2014-06-20 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p><b>Addresses: fund.ts</b></p>
|
|
<p>
|
|
Currently, <tt>std::experimental::optional::operator==</tt> imposes the <tt>EqualityComparable</tt> requirement which provides
|
|
two guarantees: It ensures that <tt>operator!=</tt> can rely on the equivalence-relation property and more importantly, that
|
|
the <tt>BooleanTestable</tt> requirements suggested by issue <a href="lwg-active.html#2114">2114</a> are automatically implied.
|
|
<p/>
|
|
<tt>std::experimental::optional::operator<</tt> doesn't provide a <tt>LessThanComparable</tt> requirement, but there was quite
|
|
an historic set of changes involved with that family of types: As of
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3527.html">N3527</a>
|
|
this operator was defined in terms of <tt>operator<</tt> of the contained type <tt>T</tt> and imposed the <tt>LessThanComparable</tt>
|
|
requirement. In the final acceptance step of <tt>optional</tt> by the committee, the definition was expressed in terms of <tt>std::less</tt>
|
|
and the <tt>LessThanComparable</tt> requirement had been removed.
|
|
<p/>
|
|
The inconsistency between <tt>operator==</tt> and <tt>operator<</tt> should be removed. One possible course of action would be
|
|
to add the <tt>LessThanComparable</tt> to <tt>std::experimental::optional::operator<</tt>. The <tt>EqualityComparable</tt> requirement
|
|
of <tt>operator==</tt> could also be removed, but in that case both operators would at least need to require the <tt>BooleanTestable</tt>
|
|
requirements (see <a href="lwg-active.html#2114">2114</a>) for the result type of <tt>T</tt>'s <tt>operator==</tt> and <tt>operator<</tt>.
|
|
<p/>
|
|
Arguably, corresponding operators for <tt>pair</tt> and <tt>tuple</tt> do not impose <tt>LessThanComparable</tt> (nor
|
|
<tt>EqualityComparable</tt>), albeit the definition of the "derived" relation functions depend on properties ensured by
|
|
<tt>LessThanComparable</tt>. According to the <a href="https://www.sgi.com/tech/stl/pair.html">SGI definition</a>, the intention was
|
|
to imposed both <tt>EqualityComparable</tt> and <tt>LessThanComparable</tt>. If this is not intended, the standard should clarify
|
|
this position.
|
|
</p>
|
|
|
|
<p><i>[2015-02 Cologne]</i></p>
|
|
|
|
<p>
|
|
VV, DK, JY discuss why and when <tt>LessThanComparable</tt> was removed. AM: Move to LEWG. Please tell LWG when you look at it.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2419"></a>2419. Clang's libc++ extension to <tt>std::tuple</tt></h3>
|
|
<p><b>Section:</b> 20.4.2.1 [tuple.cnstr] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Akim Demaille <b>Opened:</b> 2014-07-11 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#tuple.cnstr">active issues</a> in [tuple.cnstr].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#tuple.cnstr">issues</a> in [tuple.cnstr].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The issue has been submitted after exchanges with the clang++ team
|
|
as a consequence of two PR I sent:
|
|
<p/>
|
|
<a href="http://llvm.org/bugs/show_bug.cgi?id=20174">Issue 20174</a>
|
|
<p/>
|
|
<a href="http://llvm.org/bugs/show_bug.cgi?id=20175">Issue 20175</a>
|
|
<p/>
|
|
The short version is shown in the program below:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
#include <iostream>
|
|
#include <tuple>
|
|
|
|
struct base
|
|
{
|
|
void out(const std::tuple<char, char>& w) const
|
|
{
|
|
std::cerr << "Tuple: " << std::get<0>(w) << std::get<1>(w) << '\n';
|
|
}
|
|
};
|
|
|
|
struct decorator
|
|
{
|
|
base b_;
|
|
|
|
template <typename... Args>
|
|
auto
|
|
out(Args&&... args)
|
|
-> decltype(b_.out(args...))
|
|
{
|
|
return b_.out(args...);
|
|
}
|
|
|
|
void out(const char& w)
|
|
{
|
|
std::cerr << "char: " << w << '\n';
|
|
}
|
|
};
|
|
|
|
int main()
|
|
{
|
|
decorator d{base{}};
|
|
char l = 'a';
|
|
d.out(l);
|
|
}
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
This is a stripped down version of a real world case where I
|
|
wrap objects in decorators. These decorators contributes some
|
|
functions, and forward all the rest of the API to the wrapped
|
|
object using perfect forwarding. There can be overloaded names.
|
|
<p/>
|
|
Here the inner object provides an
|
|
</p>
|
|
<blockquote><pre>
|
|
out(const std::tuple<char, char>&) -> void
|
|
</pre></blockquote>
|
|
<p>
|
|
function, and the wrappers, in addition to perfect forwarding,
|
|
provides
|
|
</p>
|
|
<blockquote><pre>
|
|
out(const char&) -> void
|
|
</pre></blockquote>
|
|
<p>
|
|
The main function then call <tt>out(l)</tt> where <tt>l</tt> is a <tt>char</tt> lvalue.
|
|
<p/>
|
|
With (GCC's) libstdc++ I get the expected result: the <tt>char</tt>
|
|
overload is run. With (clang++'s) libc++ it is the tuple
|
|
version which is run.
|
|
</p>
|
|
<blockquote><pre>
|
|
$ g++-mp-4.9 -std=c++11 bar.cc && ./a.out
|
|
char: a
|
|
$ clang++-mp-3.5 -std=c++11 bar.cc -Wall && ./a.out
|
|
Tuple: a
|
|
</pre></blockquote>
|
|
<p>
|
|
It turns out that this is the result of an extension of <tt>std::tuple</tt>
|
|
in libc++ where they accept constructors with fewer values that
|
|
tuple elements.
|
|
<p/>
|
|
The purpose of this issue is to ask the standard to forbid
|
|
that this extension be allowed to participate in overload resolution.
|
|
</p>
|
|
|
|
<p><i>[2014-10-05, Daniel comments]</i></p>
|
|
|
|
<p>
|
|
This issue is closely related to LWG <a href="lwg-active.html#2312">2312</a>.
|
|
</p>
|
|
|
|
<p><i>[2014-11 Urbana]</i></p>
|
|
|
|
<p>
|
|
Moved to LEWG.
|
|
</p>
|
|
<p>
|
|
Extensions to <tt>tuple</tt>'s design are initially a question for LEWG.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2421"></a>2421. Non-specification of handling zero size in <tt>std::align</tt> [ptr.align]</h3>
|
|
<p><b>Section:</b> 20.7.5 [ptr.align] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Melissa Mears <b>Opened:</b> 2014-08-06 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#ptr.align">issues</a> in [ptr.align].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The specification of <tt>std::align</tt> does not appear to specify what happens when the value of the <tt>size</tt>
|
|
parameter is 0. (The question of what happens when <tt>alignment</tt> is 0 is mentioned in another Defect Report, <a href="lwg-defects.html#2377">2377</a>;
|
|
it would change the behavior to be undefined rather than potentially implementation-defined.)
|
|
<p/>
|
|
The case of <tt>size</tt> being 0 is interesting because the result is ambiguous. Consider the following code's output:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
#include <cstdio>
|
|
#include <memory>
|
|
|
|
int main()
|
|
{
|
|
alignas(8) char buffer[8];
|
|
void *ptr = &buffer[1];
|
|
std::size_t space = sizeof(buffer) - sizeof(char[1]);
|
|
|
|
void *result = std::align(8, 0, ptr, space);
|
|
|
|
std::printf("%d %td\n", !!result, result ? (static_cast<char*>(result) - buffer) : std::ptrdiff_t(-1));
|
|
}
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
There are four straightforward answers as to what the behavior of <tt>std::align</tt> with size 0 should be:
|
|
</p>
|
|
<ol>
|
|
<li><p>The behavior is undefined because the size is invalid.</p></li>
|
|
<li><p>The behavior is implementation-defined. This seems to be the status quo, with current implementations using #3.</p></li>
|
|
<li><p>Act the same as <tt>size == 1</tt>, except that if <tt>size == 1</tt> would fail but would be defined and succeed
|
|
if space were exactly 1 larger, the result is a pointer to the byte past the end of the <tt>ptr</tt> buffer. That is, the
|
|
"aligned" version of a 0-byte object can be one past the end of an allocation. Such pointers are, of course, valid when not
|
|
dereferenced (and a "0-byte object" shouldn't be), but whether that is desired is not specified in the Standard's definition
|
|
of <tt>std::align</tt>, it appears. The output of the code sample is "<tt>1 8</tt>" in this case.</p></li>
|
|
<li><p>Act the same as <tt>size == 1</tt>; this means that returning "one past the end" is not a possible result. In this case,
|
|
the code sample's output is "<tt>0 -1</tt>".</p></li>
|
|
</ol>
|
|
<p>
|
|
The two compilers I could get working with <tt>std::align</tt>, Visual Studio 2013 and Clang 3.4, implement #3. (Change <tt>%td</tt> to
|
|
<tt>%Id</tt> on Visual Studio 2013 and earlier. 2014 and later will have <tt>%td</tt>.)
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2422"></a>2422. <tt>std::numeric_limits<T>::is_modulo</tt> description: "most machines" errata</h3>
|
|
<p><b>Section:</b> 18.3.2.4 [numeric.limits.members] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Melissa Mears <b>Opened:</b> 2014-08-06 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#numeric.limits.members">issues</a> in [numeric.limits.members].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The seemingly non-normative (?) paragraph 61 (referring to N3936) describing how "most machines" define
|
|
<tt>std::numeric_limits<T>::is_modulo</tt> in [numeric.limits.members] appears to have some issues, in my opinion.
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
-61- On most machines, this is <tt>false</tt> for floating types, <tt>true</tt> for unsigned integers, and <tt>true</tt>
|
|
for signed integers.
|
|
</p>
|
|
</blockquote>
|
|
<p>
|
|
Issues I see:
|
|
</p>
|
|
<ol>
|
|
<li><p>Very minor: change clause 2 to "this is <tt>false</tt> for floating <ins>point</ins> types". Other uses of the term
|
|
say "floating point types" rather than just "floating types" — see nearby <tt>is_iec559</tt>, <tt>tinyness_before</tt>,
|
|
etc.</p></li>
|
|
<li><p><tt>is_modulo</tt> <em>must</em> be <tt>true</tt> for unsigned integers in order to be compliant with the Standard;
|
|
this is not just for "most machines". For reference, this requirement is from [basic.fundamental] paragraph 4 with its
|
|
footnote 48.</p></li>
|
|
<li><p>Depending on the definition of "most machines", <tt>is_modulo</tt> could be <tt>false</tt> for most machines' signed
|
|
integer types. GCC, Clang and Visual Studio, the 3 most popular C++ compilers by far, by default treat signed integer overflow
|
|
as undefined.</p></li>
|
|
</ol>
|
|
<p>
|
|
As an additional note regarding the definition of <tt>is_modulo</tt>, it seems like it should be explicitly mentioned that
|
|
on an implementation for which signed integer overflow is undefined, <tt>is_modulo</tt> shall be <tt>false</tt> for signed
|
|
integer types. It took bugs filed for all three of these compilers before they finally changed (or planned to change)
|
|
<tt>is_modulo</tt> to <tt>false</tt> for signed types.
|
|
</p>
|
|
|
|
<p><i>[2014-12 telecon]</i></p>
|
|
|
|
<p>
|
|
HH: agree with the proposal, don't like the phrasing<br/>
|
|
AM: second note feels a bit wooly<br/>
|
|
WB: not even happy with the first note, notes shouldn't say "shall"<br/>
|
|
JW: the original isn't very prescriptive because "on most machines" is not something the standard controls.<br/>
|
|
AM: "On most machines" should become a note too?<br/>
|
|
AM: first note is repeating something defined in core, shouldn't say it normatively here. Change "shall" to "is"?<br/>
|
|
MC: don't like "signed integer overflow is left undefined" ... it's just plain undefined.<br/>
|
|
AM: implementations can define what they do in that case and provide guarantees.<br/>
|
|
WB: in paragraph 61, would like to see "this" replaced by "is_modulo"<br/>
|
|
AM: Move to Open
|
|
</p>
|
|
|
|
<p><i>[2015-05-05 Lenexa]</i></p>
|
|
|
|
<p>Marshall: I will contact the submitter to see if she can re-draft the Proposed Resolution</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<ol>
|
|
<li><p>Edit 18.3.2.4 [numeric.limits.members] around p60 as indicated:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
static constexpr bool is_modulo;
|
|
</pre>
|
|
<p>
|
|
-60- True if the type is modulo.(footnote) A type is modulo if, for any operation involving <tt>+</tt>, <tt>-</tt>, or <tt>*</tt>
|
|
on values of that type whose result would fall outside the range <tt>[min(),max()]</tt>, the value returned differs from
|
|
the true value by an integer multiple of <tt>max() - min() + 1</tt>.
|
|
<p/>
|
|
<ins>-??- [<i>Note</i>: <tt>is_modulo</tt> shall be <tt>true</tt> for unsigned integer types (3.9.1 [basic.fundamental]). —
|
|
<i>end note</i>]</ins>
|
|
<p/>
|
|
<ins>-??- [<i>Note</i>: <tt>is_modulo</tt> shall be <tt>false</tt> for types for which overflow is undefined on the implementation,
|
|
because such types cannot meet the modulo requirement. Often, signed integer overflow is left undefined on implementations. —
|
|
<i>end note</i>]</ins>
|
|
<p/>
|
|
-61- On most machines, this is <tt>false</tt> for floating <ins>point</ins> types<del>, <tt>true</tt> for unsigned integers,
|
|
and <tt>true</tt> for signed integers</del>.
|
|
<p/>
|
|
-62- Meaningful for all specializations.
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2423"></a>2423. Missing specification <tt>slice_array</tt>, <tt>gslice_array</tt>, <tt>mask_array</tt>, <tt>indirect_array</tt> copy constructor</h3>
|
|
<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="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Akira Takahashi <b>Opened:</b> 2014-08-12 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#template.slice.array">issues</a> in [template.slice.array].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
I found a missing specification of the copy constructor of the following class templates:
|
|
</p>
|
|
<ul>
|
|
<li><p><tt>slice_array</tt> (26.6.5 [template.slice.array])</p></li>
|
|
<li><p><tt>gslice_array</tt> (26.6.7 [template.gslice.array])</p></li>
|
|
<li><p><tt>mask_array</tt> (26.6.8 [template.mask.array])</p></li>
|
|
<li><p><tt>indirect_array</tt> (26.6.9 [template.indirect.array])</p></li>
|
|
</ul>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<ol>
|
|
<li><p>Before 26.6.5.2 [slice.arr.assign] insert a new sub-clause as indicated:</p>
|
|
|
|
<p>
|
|
<ins><b>-?- <tt>slice_array</tt> constructors [slice.arr.cons]</b></ins>
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
<ins>slice_array(const slice_array&);</ins>
|
|
</pre>
|
|
<p>
|
|
<ins>-?- <i>Effects</i>: The constructed slice refers to the same <tt>valarray<T></tt> object to which
|
|
the argument slice refers.</ins>
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Before 26.6.7.2 [gslice.array.assign] insert a new sub-clause as indicated:</p>
|
|
|
|
<p>
|
|
<ins><b>-?- <tt>gslice_array</tt> constructors [gslice.array.cons]</b></ins>
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
<ins>gslice_array(const gslice_array&);</ins>
|
|
</pre>
|
|
<p>
|
|
<ins>-?- <i>Effects</i>: The constructed slice refers to the same <tt>valarray<T></tt> object to which
|
|
the argument slice refers.</ins>
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Before 26.6.8.2 [mask.array.assign] insert a new sub-clause as indicated:</p>
|
|
|
|
<p>
|
|
<ins><b>-?- <tt>mask_array</tt> constructors [mask.array.cons]</b></ins>
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
<ins>mask_array(const mask_array&);</ins>
|
|
</pre>
|
|
<p>
|
|
<ins>-?- <i>Effects</i>: The constructed slice refers to the same <tt>valarray<T></tt> object to which
|
|
the argument slice refers.</ins>
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Before 26.6.9.2 [indirect.array.assign] insert a new sub-clause as indicated:</p>
|
|
|
|
<p>
|
|
<ins><b>-?- <tt>indirect_array</tt> constructors [indirect.array.cons]</b></ins>
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
<ins>indirect_array(const indirect_array&);</ins>
|
|
</pre>
|
|
<p>
|
|
<ins>-?- <i>Effects</i>: The constructed slice refers to the same <tt>valarray<T></tt> object to which
|
|
the argument slice refers.</ins>
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2424"></a>2424. 29.5 should state that atomic types are not trivially copyable</h3>
|
|
<p><b>Section:</b> 29.5 [atomics.types.generic] <b>Status:</b> <a href="lwg-active.html#Review">Review</a>
|
|
<b>Submitter:</b> Jens Maurer <b>Opened:</b> 2014-08-14 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#atomics.types.generic">active issues</a> in [atomics.types.generic].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#atomics.types.generic">issues</a> in [atomics.types.generic].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Review">Review</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Otherwise, one could use <tt>memcpy</tt> to save and restore the value according to 3.9p2.
|
|
<p/>
|
|
It seems the core language rules in 9 [class]p6 with 12.8 [class.copy]p12
|
|
(trivial copy constructor) etc. and 8.4.2 [dcl.fct.def.default]p5 (user-provided) say
|
|
that the atomic types are trivially copyable, which is bad. We shouldn't rely on future core
|
|
changes in that area and simply say in the library section 29.5 [atomics.types.generic]
|
|
that these very special types are not trivially copyable.
|
|
</p>
|
|
|
|
<p><i>[2014-11 Urbana]</i></p>
|
|
|
|
<p>
|
|
Lawrence:Definition of "trivially copyable" has been changing.
|
|
</p>
|
|
<p>
|
|
Doesn't hurt to add proposed change, even if the sentence is redundant
|
|
</p>
|
|
<p>
|
|
Move to Review.
|
|
</p>
|
|
|
|
<p><i>[2015-02 Cologne]</i></p>
|
|
|
|
<p>
|
|
GR has a minor problem with the style of the wording. VV has major issues with implementability.
|
|
</p>
|
|
|
|
<p><i>[2015-03-22, Jens Maurer responses to Cologne discussion]</i></p>
|
|
|
|
<p>
|
|
A library implementation could provide a partial specialization for <tt>is_trivially_copyable<atomic<T>></tt>,
|
|
to ensure that any such type query would return <tt>false</tt>.
|
|
<p/>
|
|
Assuming such a specialization would be provided, how could a conforming program observe that per
|
|
language rules an <tt>atomic</tt> specialization would actually be trivially copyable if there
|
|
is no way to call the (deleted) copy constructor or copy assignment operator?
|
|
<p/>
|
|
The sole effect of the suggested addition of the constraining sentence is that it would make a user program
|
|
non-conforming that attempts to invoke <tt>memcpy</tt> (and the like) on <tt>atomic</tt> types, since that
|
|
would invoke undefined behaviour.
|
|
</p>
|
|
|
|
<p><i>[2015-05 Lenexa, SG1 response]</i></p>
|
|
|
|
<p>
|
|
SG1 is fine with P/R (and agrees it's needed), but LWG may want to
|
|
check the details; it's not entirely an SG1 issue.
|
|
</p>
|
|
|
|
<p><i>[2015-05-05 Lenexa]</i></p>
|
|
|
|
<p>Marshall: This was discussed on the telecon. Alisdair was going to write something to Mike and send it to Core.</p>
|
|
<p>Hwrd: Core says that deleted copies are trivially copyable, which makes no sense to Library people.</p>
|
|
<p>STL: There doesn't appear to be a Core issue about it.</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<ol>
|
|
<li><p>Change 29.5 [atomics.types.generic]p3 as indicated:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
Specializations and instantiations of the <tt>atomic</tt> template shall have a deleted copy constructor, a deleted
|
|
copy assignment operator, and a constexpr value constructor. <ins>They are not trivially copyable
|
|
types (3.9 [basic.types]).</ins>
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2426"></a>2426. Issue about <tt>compare_exchange</tt></h3>
|
|
<p><b>Section:</b> 29.6.5 [atomics.types.operations.req] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Hans Boehm <b>Opened:</b> 2014-08-25 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#atomics.types.operations.req">active issues</a> in [atomics.types.operations.req].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#atomics.types.operations.req">issues</a> in [atomics.types.operations.req].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The standard is either ambiguous or misleading about the nature of accesses through the <tt>expected</tt> argument
|
|
to the <tt>compare_exchange_*</tt> functions in 29.6.5 [atomics.types.operations.req]p21.
|
|
<p/>
|
|
It is unclear whether the access to <tt>expected</tt> is itself atomic (intent clearly no) and exactly when the implementation
|
|
is allowed to read or write it. These affect the correctness of reasonable code.
|
|
<p/>
|
|
Herb Sutter, summarizing a complaint from Duncan Forster wrote:
|
|
</p>
|
|
<blockquote class="note">
|
|
<p>
|
|
Thanks Duncan,
|
|
<p/>
|
|
I think we have a bug in the standardese wording and the implementations are
|
|
legal, but let's check with the designers of the feature.
|
|
<p/>
|
|
Let me try to summarize the issue as I understand it:
|
|
</p>
|
|
<ol>
|
|
<li><p>
|
|
What I think was intended: Lawrence, I believe you championed having
|
|
<tt>compare_exchange_*</tt> take the <tt>expected</tt> value by reference, and update
|
|
<tt>expected</tt> on failure to expose the old value, but this was only for convenience
|
|
to simplify the calling loops which would otherwise always have to write an
|
|
extra "reload" line of code. Lawrence, did I summarize your intent correctly?
|
|
</p></li>
|
|
<li><p>
|
|
What I think Duncan is trying to do: However, it turns out that, now that
|
|
<tt>expected</tt> is an lvalue, it has misled(?) Duncan into trying to use the success of
|
|
<tt>compare_exchange_*</tt> to hand off ownership <em>of <tt>expected</tt> itself</em> to another
|
|
thread. For that to be safe, if the <tt>compare_exchange_*</tt> succeeds then the
|
|
thread that performed it must no longer read or write from <tt>expected</tt> else his
|
|
technique contains a race. Duncan, did I summarize your usage correctly? Is
|
|
that the only use that is broken?
|
|
</p></li>
|
|
<li><p>
|
|
What the standard says: I can see why Duncan thinks the standard supports
|
|
his use, but I don't think this was intended (I don't remember this being
|
|
discussed but I may have been away for that part) and unless you tell me this
|
|
was intended I think it's a defect in the standard. From 29.6.5 [atomics.types.operations.req]/21:
|
|
</p>
|
|
<blockquote><p>
|
|
-21- <i>Effects</i>: Atomically, compares the contents of the memory pointed to by
|
|
<tt>object</tt> or by <tt>this</tt> for equality with that in <tt>expected</tt>, and if true, replaces the
|
|
contents of the memory pointed to by <tt>object</tt> or by <tt>this</tt> with that in <tt>desired</tt>, and
|
|
if false, updates the contents of the memory in <tt>expected</tt> with the contents of
|
|
the memory pointed to by <tt>object</tt> or by <tt>this</tt>. […]
|
|
</p></blockquote>
|
|
<p>
|
|
I think we have a wording defect here in any case, because the "atomically"
|
|
should not apply to the entire sentence — I'm pretty sure we never intended the
|
|
atomicity to cover the write to <tt>expected</tt>.
|
|
<p/>
|
|
As a case in point, borrowing from Duncan's mail below, I think the following
|
|
implementation is intended to be legal:
|
|
</p>
|
|
<blockquote><pre>
|
|
inline int _Compare_exchange_seq_cst_4(volatile _Uint4_t *_Tgt, _Uint4_t *_Exp, _Uint4_t _Value)
|
|
{ /* compare and exchange values atomically with
|
|
sequentially consistent memory order */
|
|
int _Res;
|
|
_Uint4_t _Prev = _InterlockedCompareExchange((volatile long *)_Tgt, _Value, *_Exp);
|
|
<span style="color:#C80000">if (_Prev == *_Exp) //!!!!! Note the unconditional read from *_Exp here</span>
|
|
_Res = 1;
|
|
else
|
|
{ /* copy old value */
|
|
_Res = 0;
|
|
*_Exp = _Prev;
|
|
}
|
|
return (_Res);
|
|
}
|
|
</pre></blockquote>
|
|
<p>
|
|
I think this implementation is intended to be valid — I think the only code that
|
|
could be broken with the "!!!!!" read of <tt>*_Exp</tt> is Duncan's use of treating
|
|
<tt>a.compare_exchange_*(expected, desired) == true</tt> as implying <tt>expected</tt> got
|
|
handed off, because then another thread could validly be using <tt>*_Exp</tt> — but we
|
|
never intended this use, right?
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
</blockquote>
|
|
<p>
|
|
In a different thread Richard Smith wrote about the same problem:
|
|
</p>
|
|
<blockquote class="note">
|
|
<p>
|
|
The <tt>atomic_compare_exchange</tt> functions are described as follows:
|
|
</p>
|
|
<blockquote><p>
|
|
"Atomically, compares the contents of the memory pointed to by <tt>object</tt> or by <tt>this</tt>
|
|
for equality with that in <tt>expected</tt>, and if true, replaces the contents of the memory pointed to
|
|
by <tt>object</tt> or by <tt>this</tt> with that in <tt>desired</tt>, and if false, updates the contents
|
|
of the memory in <tt>expected</tt> with the contents of the memory pointed to by <tt>object</tt> or by
|
|
<tt>this</tt>. Further, if the comparison is true, memory is affected according to the value of <tt>success</tt>,
|
|
and if the comparison is false, memory is affected according to the value of <tt>failure</tt>."
|
|
</p></blockquote>
|
|
<p>
|
|
I think this is less clear than it could be about the effects of these operations on <tt>*expected</tt> in the failure case:
|
|
</p>
|
|
<ol>
|
|
<li><p>We have "Atomically, compares […] and updates the contents of the memory in <tt>expected</tt> […]".
|
|
The update to the memory in <tt>expected</tt> is clearly not atomic, and yet this wording parallels the success case,
|
|
in which the memory update is atomic.
|
|
</p></li>
|
|
<li><p>The wording suggests that memory (including <tt>*expected</tt>) is affected according to the value of <tt>failure</tt>.
|
|
In particular, the failure order could be <tt>memory_order_seq_cst</tt>, which might lead someone to incorrectly think they'd
|
|
published the value of <tt>*expected</tt>.</p></li>
|
|
</ol>
|
|
<p>
|
|
I think this can be clarified with no change in meaning by reordering the wording a little:
|
|
</p>
|
|
<blockquote><p>
|
|
"Atomically, compares the contents of the memory pointed to by <tt>object</tt> or by <tt>this</tt> for equality with that in
|
|
<tt>expected</tt>, and if true, replaces the contents of the memory pointed to by <tt>object</tt> or by <tt>this</tt> with
|
|
that in <tt>desired</tt><del>, and if</del><ins>. If the comparison is true, memory is affected according to the value of
|
|
<tt>success</tt>, and if the comparison is false, memory is affected according to the value of <tt>failure</tt>. Further,
|
|
if the comparison is</ins> false, <del>updates</del><ins>replaces</ins> the contents of the memory in <tt>expected</tt> with
|
|
the <del>contents of</del><ins>value that was atomically read from</ins> the memory pointed to by <tt>object</tt> or by
|
|
<tt>this</tt>. <del>Further, if the comparison is true, memory is affected according to the value of <tt>success</tt>, and
|
|
if the comparison is false, memory is affected according to the value of <tt>failure</tt>.</del>"
|
|
</p></blockquote>
|
|
</blockquote>
|
|
<p>
|
|
Jens Maurer add:
|
|
</p>
|
|
<blockquote class="note">
|
|
<p>
|
|
I believe this is an improvement.
|
|
<p/>
|
|
I like to see the following additional improvements:
|
|
</p>
|
|
<ul>
|
|
<li><p>
|
|
"contents of the memory" is strange phrasing, which doesn't say how large the
|
|
memory block is. Do we compare the values or the value representation of the lvalue
|
|
<tt>*object</tt> (or <tt>*this</tt>)?
|
|
</p></li>
|
|
<li><p>
|
|
29.3 [atomics.order] defines memory order based on the "affected memory location". It would be
|
|
better to say something like "If the comparison is true, the memory synchronization order for the
|
|
affected memory location <tt>*object</tt> is […]"
|
|
</p></li>
|
|
</ul>
|
|
</blockquote>
|
|
<p>
|
|
There was also a discussion thread involving Herb Sutter, Hans Boehm, and Lawrence Crowl, resulting in proposed
|
|
wording along the lines of:
|
|
</p>
|
|
<blockquote class="note">
|
|
<blockquote>
|
|
<p>
|
|
-21- <i>Effects</i>: Atomically with respect to <tt>expected</tt> and the memory pointed
|
|
to by <tt>object</tt> or by <tt>this</tt>, compares the contents of the memory pointed
|
|
to by <tt>object</tt> or by <tt>this</tt> for equality with that in <tt>expected</tt>, and if and
|
|
only if true, replaces the contents of the memory pointed to by <tt>object</tt>
|
|
or by <tt>this</tt> with that in desired, and if and only if false, updates the
|
|
contents of the memory in expected with the contents of the memory pointed to by
|
|
<tt>object</tt> or by <tt>this</tt>.
|
|
</p>
|
|
</blockquote>
|
|
<p>
|
|
At the end of paragraph 23, perhaps add
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
[<i>Example</i>: Because the <tt>expected</tt> value is updated only on failure,
|
|
code releasing the memory containing the <tt>expected</tt> value on success
|
|
will work. E.g. list head insertion will act atomically and not
|
|
have a data race in the following code.
|
|
</p>
|
|
<blockquote><pre>
|
|
do {
|
|
p->next = head; // make new list node point to the current head
|
|
} while(!head.compare_exchange_weak(p->next, p)); // try to insert
|
|
</pre></blockquote>
|
|
<p>
|
|
— <i>end example</i>]
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
<p>
|
|
Hans objected that this still gives the misimpression that the update to <tt>expected</tt> is atomic.
|
|
</p>
|
|
|
|
<p><i>[2014-11 Urbana]</i></p>
|
|
|
|
<p>
|
|
Proposed resolution was added after Redmond.
|
|
</p>
|
|
<p>
|
|
Recommendations from SG1:
|
|
</p>
|
|
<ol>
|
|
<li>Change wording to <del>if true</del><ins>if and only if true</ins>, and change <del>if false</del><ins>if and only if false</ins>.</li>
|
|
<li>If they want to add "respect to" clause, say "respect to object or this".</li>
|
|
<li>In example, load from head should be "head.load(memory_order_relaxed)", because people are going to use example as example of good code.</li>
|
|
</ol>
|
|
|
|
<p>
|
|
<i>(wording edits not yet applied)</i>
|
|
</p>
|
|
|
|
<p><i>[2015-02 Cologne]</i></p>
|
|
|
|
<p>
|
|
Handed over to SG1.
|
|
</p>
|
|
|
|
<p><i>[2015-05 Lenexa, SG1 response]</i></p>
|
|
|
|
<p>
|
|
We believed we were done with it, but it was kicked back to us, with the wording we suggested not yet applied. It may have been that our suggestions were unclear. Was that the concern?
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<ol>
|
|
<li><p>Edit 29.6.5 [atomics.types.operations.req] p21 as indicated:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-21- <i>Effects</i>: <ins>Retrieves the value in <tt>expected</tt>. It then a</ins><del>A</del>tomically<del>,</del>
|
|
compares the contents of the memory pointed to by <tt>object</tt> or by <tt>this</tt> for equality with that
|
|
<del>in</del><ins>previously retrieved from</ins> <tt>expected</tt>, and if true, replaces the contents of the
|
|
memory pointed to by <tt>object</tt> or by <tt>this</tt> with that in <tt>desired</tt><del>, and if false,
|
|
updates the contents of the memory in expected with the contents of the memory pointed to by <tt>object</tt>
|
|
or by <tt>this</tt>. Further, if</del><ins>. If and only if</ins> the comparison is true, memory is affected according to the value of
|
|
<tt>success</tt>, and if the comparison is false, memory is affected according to the value of <tt>failure</tt>.
|
|
When only one <tt>memory_order</tt> argument is supplied, the value of <tt>success</tt> is <tt>order</tt>,
|
|
and the value of <tt>failure</tt> is <tt>order</tt> except that a value of <tt>memory_order_acq_rel</tt>
|
|
shall be replaced by the value <tt>memory_order_acquire</tt> and a value of <tt>memory_order_release</tt> shall
|
|
be replaced by the value <tt>memory_order_relaxed</tt>. <ins>If the comparison is false then, after the atomic
|
|
operation, the contents of the memory in <tt>expected</tt> are replaced by the value read from <tt>object</tt> or
|
|
by <tt>this</tt> during the atomic comparison.</ins> If the operation returns true, these operations are
|
|
atomic read-modify-write operations (1.10) <ins>on the memory pointed to by <tt>this</tt> or
|
|
<tt>object</tt></ins>. Otherwise, these operations are atomic load operations <ins>on that memory</ins>.
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Add the following example to the end of 29.6.5 [atomics.types.operations.req] p23:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-23- [<i>Note</i>: […] — <i>end note</i>] [<i>Example</i>: […] — <i>end example</i>]
|
|
<p/>
|
|
<ins>[<i>Example</i>: Because the expected value is updated only on failure,
|
|
code releasing the memory containing the <tt>expected</tt> value
|
|
on success will work. E.g. list head insertion will act atomically
|
|
and would not introduce a data race in the following code:</ins>
|
|
</p>
|
|
<blockquote>
|
|
<pre><ins>
|
|
do {
|
|
p-i>next = head; // make new list node point to the current head
|
|
} while(!head.compare_exchange_weak(p->next, p)); // try to insert
|
|
</ins></pre>
|
|
</blockquote>
|
|
<p>
|
|
<ins>— <i>end example</i>]</ins>
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2430"></a>2430. Heterogeneous container lookup should be enabled using meta-function instead of nested type</h3>
|
|
<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Tomasz Kamiński <b>Opened:</b> 2014-07-14 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Currently the heterogeneous lookup in associative container are
|
|
enabled by presence of <tt>is_transparent</tt> nested type in the comparator
|
|
type (23.2.4 [associative.reqmts]). This complicates the definition
|
|
of call wrapper types that want to define <tt>is_transparent</tt> if they wrap
|
|
a callable type that defines <tt>is_transparent</tt>, and requires the target
|
|
to be a complete type in cases where an incomplete type would otherwise be ok.
|
|
<p/>
|
|
Another problem is that users cannot add the <tt>is_transparent</tt> member to
|
|
a third-party comparison type that they do not control, even if they
|
|
know it supports heterogeneous comparisons.
|
|
<p/>
|
|
If the associative containers used a trait instead of checking for an
|
|
<tt>is_transparent</tt> member type then it would avoid the requirement for
|
|
complete types, and would allow customization of the trait without
|
|
modifying the comparator type. This would also be consistent with the
|
|
traits <tt>is_placeholder</tt> and <tt>is_bind_expression</tt>.
|
|
<p/>
|
|
For backward compatibility with the existing design, the default
|
|
implementation of the <tt>is_transparent</tt> trait could depend on the
|
|
presence of the <tt>is_transparent</tt> nested type.
|
|
</p>
|
|
|
|
<p><i>[2014-11 Urbana]</i></p>
|
|
|
|
<p>Move to LEWG</p>
|
|
<p>
|
|
Request for a new metafunction should first be responded to by LEWG.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2431"></a>2431. Missing regular expression traits requirements</h3>
|
|
<p><b>Section:</b> 28.3 [re.req] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2014-09-30 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The requirements on the traits class in 28.3 [re.req] do not say whether a
|
|
regular expression traits class is required to be <tt>DefaultConstructible</tt>,
|
|
<tt>CopyConstructible</tt>, <tt>CopyAssignable</tt> etc.
|
|
<p/>
|
|
The <tt>std::regex_traits</tt> class appears to be all of the above, but can
|
|
<tt>basic_regex</tt> assume that for user-defined traits classes?
|
|
<p/>
|
|
Should the following statements all leave <tt>u</tt> in equivalent states?
|
|
</p>
|
|
<blockquote><pre>
|
|
X u{v};
|
|
X u; u = v;
|
|
X u; u.imbue(v.getloc();
|
|
</pre></blockquote>
|
|
<p>
|
|
Whether they are equivalent has implications for <tt>basic_regex</tt> copy construction and
|
|
assignment.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2432"></a>2432. <tt>initializer_list</tt> assignability</h3>
|
|
<p><b>Section:</b> 18.9 [support.initlist] <b>Status:</b> <a href="lwg-active.html#EWG">EWG</a>
|
|
<b>Submitter:</b> David Krauss <b>Opened:</b> 2014-09-30 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#support.initlist">active issues</a> in [support.initlist].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#support.initlist">issues</a> in [support.initlist].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#EWG">EWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
<tt>std::initializer_list::operator=</tt> 18.9 [support.initlist] is horribly broken and it needs deprecation:
|
|
</p>
|
|
<blockquote><pre>
|
|
std::initializer_list<foo> a = {{1}, {2}, {3}};
|
|
a = {{4}, {5}, {6}};
|
|
// New sequence is already destroyed.
|
|
</pre></blockquote>
|
|
<p>
|
|
Assignability of <tt>initializer_list</tt> isn't explicitly specified, but most implementations supply a default assignment
|
|
operator. I'm not sure what 17.5 [description] says, but it probably doesn't matter.
|
|
</p>
|
|
|
|
<p><i>[Lenexa 2015-05-05: Send to EWG as discussed in Telecon]</i></p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<ol>
|
|
<li><p>Edit 18.9 [support.initlist] p1, class template <tt>initializer_list</tt> synopsis, as indicated:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
namespace std {
|
|
template<class E> class initializer_list {
|
|
public:
|
|
[…]
|
|
constexpr initializer_list() noexcept;
|
|
|
|
<ins>initializer_list(const initializer_list&) = default;</ins>
|
|
<ins>initializer_list(initializer_list&&) = default;</ins>
|
|
<ins>initializer_list& operator=(const initializer_list&) = delete;</ins>
|
|
<ins>initializer_list& operator=(initializer_list&&) = delete;</ins>
|
|
|
|
constexpr size_t size() const noexcept;
|
|
[…]
|
|
};
|
|
[…]
|
|
}
|
|
</pre>
|
|
</blockquote>
|
|
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2435"></a>2435. <tt>reference_wrapper::operator()</tt>'s Remark should be deleted</h3>
|
|
<p><b>Section:</b> 20.9.4.4 [refwrap.invoke] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2014-10-01 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
20.9.4.4 [refwrap.invoke]/2 is no longer useful. (It was originally TR1 2.1.2.4 [tr.util.refwrp.invoke]/2.)
|
|
First, we already have the As If Rule (1.9 [intro.execution]/1) and the STL Implementers Can Be Sneaky Rule
|
|
(17.6.5.5 [member.functions]). Second, with variadic templates and other C++11/14 tech, this can be implemented
|
|
exactly as depicted.
|
|
</p>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
DK: I don't see a defect here<br/>
|
|
STL: the issue is that the standard is overly verbose, we don't need this sentence. It's redundant.<br/>
|
|
MC: does anyone think this paragraph has value?<br/>
|
|
JW: it has negative value. reading it makes me wonder if there's some reason I would want to provide a set of overloaded
|
|
functions, maybe there's some problem with doing it the obvious way that I'm not clever enough to see.<br/>
|
|
Move to Ready status: 8 in favor, none against.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
This wording is relative to N3936.
|
|
</p>
|
|
|
|
<ol>
|
|
<li><p>Change 20.9.4.4 [refwrap.invoke] p2 as depicted:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
template <class... ArgTypes>
|
|
result_of_t<T&(ArgTypes&&...)>
|
|
operator()(ArgTypes&&... args) const;
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-1- <i>Returns</i>: <tt>INVOKE(get(), std::forward<ArgTypes>(args)...)</tt>. (20.9.2)
|
|
<p/>
|
|
<del>-2- <i>Remark</i>: <tt>operator()</tt> is described for exposition only. Implementations are not required to provide an
|
|
actual <tt>reference_wrapper::operator()</tt>. Implementations are permitted to support <tt>reference_wrapper</tt> function
|
|
invocation through multiple overloaded operators or through other means.</del>
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2436"></a>2436. Comparators for associative containers should always be <tt>CopyConstructible</tt></h3>
|
|
<p><b>Section:</b> 23.2.4 [associative.reqmts], 23.2.5 [unord.req] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2014-10-01 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The associative container requirements attempt to permit comparators that are <tt>DefaultConstructible</tt>
|
|
but non-<tt>CopyConstructible</tt>. However, the Standard contradicts itself. 23.4.4.1 [map.overview] depicts
|
|
<tt>map() : map(Compare()) { }</tt> which requires both <tt>DefaultConstructible</tt> and <tt>CopyConstructible</tt>.
|
|
<p/>
|
|
Unlike fine-grained element requirements (which are burdensome for implementers, but valuable for users), such
|
|
fine-grained comparator requirements are both burdensome for implementers (as the Standard's self-contradiction
|
|
demonstrates) and worthless for users. We should unconditionally require <tt>CopyConstructible</tt> comparators.
|
|
(Note that <tt>DefaultConstructible</tt> should remain optional; this is not problematic for implementers, and
|
|
allows users to use lambdas.)
|
|
<p/>
|
|
Key equality predicates for unordered associative containers are also affected. However, 17.6.3.4 [hash.requirements]/1
|
|
already requires hashers to be <tt>CopyConstructible</tt>, so 23.2.5 [unord.req]'s redundant wording should
|
|
be removed.
|
|
</p>
|
|
|
|
<p><i>[2015-02, Cologne]</i></p>
|
|
|
|
<p>
|
|
GR: I prefer to say "<tt>Compare</tt>" rather than "<tt>X::key_compare</tt>", since the former is what the user supplies.
|
|
JY: It makes sense to use "<tt>Compare</tt>" when we talk about requirements but "<tt>key_compare</tt>" when we use it.
|
|
<p/>
|
|
AM: We're adding requirements here, which is a breaking change, even though nobody will ever have had a non-<tt>CopyConstructible</tt>
|
|
comparator. But the simplification is probably worth it.
|
|
<p/>
|
|
GR: I don't care about unmovable containers. But I do worry that people might want to move they comparators. MC: How do
|
|
you reconcile that with the function that says "give me the comparator"? GR: That one returns by value? JY: Yes. [To MC]
|
|
You make it a requirement of that function. [To GR] And it [the <tt>key_comp()</tt> function] is missing its requirements.
|
|
We need to add them everywhere. GR: map already has the right requirements.
|
|
<p/>
|
|
JM: I dispute this. If in C++98 a type wasn't copyable, it had some interesting internal state, but in C++98 you wouldn't
|
|
have been able to pass it into the container since you would have had to make a copy. JY: No, you could have
|
|
default-constructed it and never moved it, e.g. a mutex. AM: So, it's a design change, but one that we should make.
|
|
That's probably an LEWG issue. AM: There's a contradiction in the Standard here, and we need to fix it one way or another.
|
|
<p/>
|
|
<b>Conclusion</b>: Move to LEWG
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
This wording is relative to N3936.
|
|
</p>
|
|
|
|
<ol>
|
|
<li><p>Change 23.2.4 [associative.reqmts] Table 102 as indicated (Editorial note: For "expression" <tt>X::key_compare</tt>
|
|
"defaults to" is redundant with the class definitions for map/etc.):</p>
|
|
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 102 — Associative container requirements</caption>
|
|
<tr>
|
|
<th>Expression</th>
|
|
<th>Return type</th>
|
|
<th>Assertion/note pre-/post-condition</th>
|
|
<th>Complexity</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="4" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>X::key_compare</tt>
|
|
</td>
|
|
<td>
|
|
<tt>Compare</tt>
|
|
</td>
|
|
<td>
|
|
<del>defaults to <tt>less<key_type></tt></del><br/>
|
|
<ins><i>Requires</i>: <tt>key_compare</tt> is <tt>CopyConstructible</tt>.</ins>
|
|
</td>
|
|
<td>
|
|
compile time
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="4" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>X(c)<br/>
|
|
X a(c);</tt>
|
|
</td>
|
|
<td>
|
|
</td>
|
|
<td>
|
|
<del><i>Requires</i>: <tt>key_compare</tt> is <tt>CopyConstructible</tt>.</del><br/>
|
|
<i>Effects</i>: Constructs an empty
|
|
container. Uses a copy of <tt>c</tt> as
|
|
a comparison object.
|
|
</td>
|
|
<td>
|
|
constant
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="4" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>X(i,j,c)<br/>
|
|
X a(i,j,c);</tt>
|
|
</td>
|
|
<td>
|
|
</td>
|
|
<td>
|
|
<i>Requires</i>: <del><tt>key_compare</tt> is <tt>CopyConstructible</tt>.</del><br/>
|
|
<tt>value_type</tt> is <tt>EmplaceConstructible</tt> into <tt>X</tt> from <tt>*i</tt>.<br/>
|
|
<i>Effects</i>: Constructs […]
|
|
</td>
|
|
<td>
|
|
[…]
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="4" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote></li>
|
|
|
|
<li><p>Change 23.2.5 [unord.req] Table 103 as indicated:</p>
|
|
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 103 — Unordered associative container requirements (in addition to container)</caption>
|
|
<tr>
|
|
<th>Expression</th>
|
|
<th>Return type</th>
|
|
<th>Assertion/note pre-/post-condition</th>
|
|
<th>Complexity</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="4" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>X::key_equal</tt>
|
|
</td>
|
|
<td>
|
|
<tt>Pred</tt>
|
|
</td>
|
|
<td>
|
|
<ins><i>Requires</i>: <tt>Pred</tt> is <tt>CopyConstructible</tt>.</ins><br/>
|
|
<tt>Pred</tt> shall be a binary predicate that takes two arguments of type <tt>Key</tt>.<br/>
|
|
<tt>Pred</tt> is an equivalence relation.
|
|
</td>
|
|
<td>
|
|
compile time
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="4" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>X(n, hf, eq)<br/>
|
|
X a(n, hf, eq);</tt>
|
|
</td>
|
|
<td>
|
|
<tt>X</tt>
|
|
</td>
|
|
<td>
|
|
<del><i>Requires</i>: <tt>hasher</tt> and <tt>key_equal</tt> are <tt>CopyConstructible</tt>.</del><br/>
|
|
<i>Effects</i>: Constructs […]
|
|
</td>
|
|
<td>
|
|
[…]
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="4" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>X(n, hf)<br/>
|
|
X a(n, hf);</tt>
|
|
</td>
|
|
<td>
|
|
<tt>X</tt>
|
|
</td>
|
|
<td>
|
|
<i>Requires</i>: <del><tt>hasher</tt> is <tt>CopyConstructible</tt> and</del><br/>
|
|
<tt>key_equal</tt> is <tt>DefaultConstructible</tt><br/>
|
|
<i>Effects</i>: Constructs […]
|
|
</td>
|
|
<td>
|
|
[…]
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="4" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>X(i, j, n, hf, eq)<br/>
|
|
X a(i, j, n, hf, eq);</tt>
|
|
</td>
|
|
<td>
|
|
<tt>X</tt>
|
|
</td>
|
|
<td>
|
|
<i>Requires</i>: <del><tt>hasher</tt> and <tt>key_equal</tt> are <tt>CopyConstructible</tt>.</del><br/>
|
|
<tt>value_type</tt> is <tt>EmplaceConstructible</tt> into <tt>X</tt> from <tt>*i</tt>.<br/>
|
|
<i>Effects</i>: Constructs […]
|
|
</td>
|
|
<td>
|
|
[…]
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="4" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>X(i, j, n, hf)<br/>
|
|
X a(i, j, n, hf);</tt>
|
|
</td>
|
|
<td>
|
|
<tt>X</tt>
|
|
</td>
|
|
<td>
|
|
<i>Requires</i>: <del><tt>hasher</tt> is <tt>CopyConstructible</tt> and</del><br/>
|
|
<tt>key_equal</tt> is <tt>DefaultConstructible</tt><br/>
|
|
<tt>value_type</tt> is <tt>EmplaceConstructible</tt> into <tt>X</tt> from <tt>*i</tt>.<br/>
|
|
<i>Effects</i>: Constructs […]
|
|
</td>
|
|
<td>
|
|
[…]
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="4" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote></li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2441"></a>2441. Exact-width atomic typedefs should be provided</h3>
|
|
<p><b>Section:</b> 29.5 [atomics.types.generic] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2014-10-01 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#atomics.types.generic">active issues</a> in [atomics.types.generic].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#atomics.types.generic">issues</a> in [atomics.types.generic].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
<tt><atomic></tt> doesn't provide counterparts for <tt><inttypes.h></tt>'s most useful typedefs, possibly
|
|
because they're quasi-optional. We can easily fix this.
|
|
</p>
|
|
|
|
<p><i>[2014-11, Urbana]</i></p>
|
|
|
|
<p>
|
|
Typedefs were transitional compatibility hack. Should use <tt>_Atomic</tt> macro or template.
|
|
E.g. <tt>_Atomic(int8_t)</tt>. BUT <tt>_Atomic</tt> disappeared!</p>
|
|
|
|
<p>
|
|
Detlef will look for <tt>_Atomic</tt> macro. If missing, will open issue.
|
|
</p>
|
|
|
|
<p><i>[2014-11-25, Hans comments]</i></p>
|
|
|
|
<p>
|
|
There is no <tt>_Atomic</tt> in C++. This is related to the much more general unanswered question of whether C++17
|
|
should reference C11, C99, or neither.
|
|
</p>
|
|
|
|
<p><i>[2015-02 Cologne]</i></p>
|
|
|
|
<p>
|
|
AM: I think this is still an SG1 issue; they need to deal with it before we do.
|
|
</p>
|
|
|
|
<p><i>[2015-05 Lenexa, SG1 response]</i></p>
|
|
|
|
<p>
|
|
Move to SG1-OK status. This seems like an easy short-term fix. We probably need a paper on C/C++ atomics compatibility to deal with _Atomic, but that's a separable issue.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
This wording is relative to N3936.
|
|
</p>
|
|
|
|
<ol>
|
|
<li><p>Change 29.5 [atomics.types.generic] p8 as depicted:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-8- There shall be atomic typedefs corresponding to the typedefs in the header <tt><inttypes.h></tt> as specified in
|
|
Table 147. <ins><tt>atomic_int<i>N</i>_t</tt>, <tt>atomic_uint<i>N</i>_t</tt>, <tt>atomic_intptr_t</tt>, and
|
|
<tt>atomic_uintptr_t</tt> shall be defined if and only if <tt>int<i>N</i>_t</tt>, <tt>uint<i>N</i>_t</tt>, <tt>intptr_t</tt>,
|
|
and <tt>uintptr_t</tt> are defined, respectively.</ins>
|
|
</p>
|
|
</blockquote></li>
|
|
|
|
<li><p>Change 29.6.5 [atomics.types.operations.req], Table 147 ("<tt>atomic</tt> <tt><inttypes.h></tt>
|
|
typedefs"), as depicted:</p>
|
|
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 147 — <tt>atomic</tt> <tt><inttypes.h></tt> typedefs</caption>
|
|
<tr>
|
|
<th>Atomic typedef</th>
|
|
<th><tt><inttypes.h></tt> type</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<ins><tt>atomic_int8_t</tt></ins>
|
|
</td>
|
|
<td>
|
|
<ins><tt>int8_t</tt></ins>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<ins><tt>atomic_uint8_t</tt></ins>
|
|
</td>
|
|
<td>
|
|
<ins><tt>uint8_t</tt></ins>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<ins><tt>atomic_int16_t</tt></ins>
|
|
</td>
|
|
<td>
|
|
<ins><tt>int16_t</tt></ins>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<ins><tt>atomic_uint16_t</tt></ins>
|
|
</td>
|
|
<td>
|
|
<ins><tt>uint16_t</tt></ins>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<ins><tt>atomic_int32_t</tt></ins>
|
|
</td>
|
|
<td>
|
|
<ins><tt>int32_t</tt></ins>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<ins><tt>atomic_uint32_t</tt></ins>
|
|
</td>
|
|
<td>
|
|
<ins><tt>uint32_t</tt></ins>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<ins><tt>atomic_int64_t</tt></ins>
|
|
</td>
|
|
<td>
|
|
<ins><tt>int64_t</tt></ins>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<ins><tt>atomic_uint64_t</tt></ins>
|
|
</td>
|
|
<td>
|
|
<ins><tt>uint64_t</tt></ins>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="2" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2443"></a>2443. <tt>std::array</tt> member functions should be <tt>constexpr</tt></h3>
|
|
<p><b>Section:</b> 23.3.2 [array] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Peter Sommerlad <b>Opened:</b> 2014-10-06 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#array">active issues</a> in [array].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#array">issues</a> in [array].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
When experimenting with C++14 relaxed <tt>constexpr</tt> functions I made the observation that I couldn't
|
|
use <tt>std::array</tt> to create a table of data at compile time directly using loops in a function.
|
|
However, a simple substitute I could use instead:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
template <typename T, size_t n>
|
|
struct ar {
|
|
T a[n];
|
|
constexpr ar() : a{{}}{}
|
|
constexpr auto data() const { return &a[0];}
|
|
constexpr T const & operator[](size_t i) const { return a[i]; }
|
|
constexpr T & operator[](size_t i) { return a[i]; }
|
|
};
|
|
|
|
template <size_t n>
|
|
using arr = ar<size_t, n>; // std::array<size_t, n>;
|
|
|
|
template <size_t n>
|
|
constexpr auto make_tab(){
|
|
arr<n> result;
|
|
for(size_t i=0; i < n; ++i)
|
|
result[i] = (i+1)*(i+1); // cannot define operator[] for mutable array...
|
|
return result;
|
|
}
|
|
|
|
template <size_t n>
|
|
constexpr auto squares=make_tab< n>();
|
|
|
|
int main() {
|
|
int dummy[squares<5>[3]];
|
|
}
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
Therefore, I suggest that all member functions of <tt>std::array</tt> should be made <tt>constexpr</tt>
|
|
to make the type usable in <tt>constexpr</tt> functions.
|
|
<p/>
|
|
Wording should be straight forward, may be with the exception of <tt>fill</tt>, which would require
|
|
<tt>fill_n</tt> to be <tt>constexpr</tt> as well.
|
|
</p>
|
|
|
|
<p><i>[2014-11 Urbana]</i></p>
|
|
|
|
<p>Move to LEWG</p>
|
|
<p>
|
|
The extent to which <tt>constexpr</tt> becomes a part of the Library design is a policy
|
|
matter best handled initially by LEWG.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2444"></a>2444. Inconsistent complexity for <tt>std::sort_heap</tt></h3>
|
|
<p><b>Section:</b> 25.4.6.4 [sort.heap] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> François Dumont <b>Opened:</b> 2014-10-07 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
While creating complexity tests for the GNU libstdc++ implementation <a href="https://gcc.gnu.org/ml/libstdc++/2014-10/msg00048.html">I
|
|
stumbled</a> across a surprising requirement for the <tt>std::sort_heap</tt> algorithm.
|
|
<p/>
|
|
In 25.4.6.4 [sort.heap] p3 the Standard states:
|
|
</p>
|
|
<blockquote><p>
|
|
<i>Complexity</i>: At most <tt><i>N</i> log(<i>N</i>)</tt> comparisons (where <tt><i>N</i> == last - first</tt>).
|
|
</p></blockquote>
|
|
<p>
|
|
As stated on the libstdc++ mailing list by Marc Glisse <tt>sort_heap</tt> can be implemented by <tt><i>N</i></tt> calls to
|
|
<tt>pop_heap</tt>. As max number of comparisons of <tt>pop_heap</tt> is <tt>2 * log(<i>N</i>)</tt> then <tt>sort_heap</tt>
|
|
max limit should be <tt>2 * log(1) + 2 * log(2) + .... + 2 * log(<i>N</i>)</tt> that is to say <tt>2 * log(<i>N</i>!)</tt>.
|
|
In terms of <tt>log(<i>N</i>)</tt> we can also consider that this limit is also cap by <tt>2 * <i>N</i> * log(<i>N</i>)</tt>
|
|
which is surely what the Standard wanted to set as a limit.
|
|
<p/>
|
|
This is why I would like to propose to replace paragraph 3 by:
|
|
</p>
|
|
<blockquote><p>
|
|
<i>Complexity</i>: At most <tt><ins>2</ins><i>N</i> log(<i>N</i>)</tt> comparisons (where <tt><i>N</i> == last - first</tt>).
|
|
</p></blockquote>
|
|
|
|
<p><i>[2015-02 Cologne]</i></p>
|
|
|
|
<p>
|
|
Marshall will research the maths and report back in Lenexa.
|
|
</p>
|
|
|
|
<p><i>[2015-05-06 Lenexa]</i></p>
|
|
|
|
<p>STL: I dislike exact complexity requirements, they prevent one or two extra checks in debug mode. Would it be better to say O(N log(N)) not at most?</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
This wording is relative to N3936.
|
|
</p>
|
|
|
|
<ol><li>
|
|
<p>
|
|
In 25.4.6.4 [sort.heap] p3 the Standard states:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
template<class RandomAccessIterator>
|
|
void sort_heap(RandomAccessIterator first, RandomAccessIterator last);
|
|
template<class RandomAccessIterator, class Compare>
|
|
void sort_heap(RandomAccessIterator first, RandomAccessIterator last,
|
|
Compare comp);
|
|
</pre>
|
|
<blockquote><p>
|
|
[…]
|
|
<p/>
|
|
-3- <i>Complexity</i>: At most <tt><ins>2</ins><i>N</i> log(<i>N</i>)</tt> comparisons (where <tt><i>N</i> == last - first</tt>).
|
|
</p></blockquote>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2445"></a>2445. "Stronger" memory ordering</h3>
|
|
<p><b>Section:</b> 20.8.2.6 [util.smartptr.shared.atomic], 29.6.5 [atomics.types.operations.req] <b>Status:</b> <a href="lwg-active.html#SG1">SG1</a>
|
|
<b>Submitter:</b> JF Bastien <b>Opened:</b> 2014-10-08 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#util.smartptr.shared.atomic">issues</a> in [util.smartptr.shared.atomic].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#SG1">SG1</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The definitions of compare and exchange in 20.8.2.6 [util.smartptr.shared.atomic] p32 and
|
|
29.6.5 [atomics.types.operations.req] p20 state:
|
|
</p>
|
|
<blockquote><p>
|
|
<i>Requires</i>: The failure argument shall not be <tt>memory_order_release</tt> nor <tt>memory_order_acq_rel</tt>.
|
|
The <tt>failure</tt> argument shall be no stronger than the <tt>success</tt> argument.
|
|
</p></blockquote>
|
|
<p>
|
|
The term "stronger" isn't defined by the standard.
|
|
<p/>
|
|
It is hinted at by 29.6.5 [atomics.types.operations.req] p21:
|
|
</p>
|
|
<blockquote><p>
|
|
When only one <tt>memory_order</tt> argument is supplied, the value of <tt>success</tt> is <tt>order</tt>, and the
|
|
value of <tt>failure</tt> is <tt>order</tt> except that a value of <tt>memory_order_acq_rel</tt> shall be replaced
|
|
by the value <tt>memory_order_acquire</tt> and a value of <tt>memory_order_release</tt> shall be replaced by the
|
|
value <tt>memory_order_relaxed</tt>.
|
|
</p></blockquote>
|
|
<p>
|
|
Should the standard define a partial ordering for memory orders, where consume and acquire are incomparable with release?
|
|
</p>
|
|
|
|
<p><i>[2014-11 Urbana]</i></p>
|
|
|
|
<p>
|
|
Move to SG1.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2446"></a>2446. Unspecialized <tt>std::tuple_size</tt> should be defined</h3>
|
|
<p><b>Section:</b> 20.4.1 [tuple.general] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Nevin Liber <b>Opened:</b> 2014-10-10 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
In 20.4.1 [tuple.general] paragraph 2, the unspecialized <tt>std::tuple_size</tt> is undefined. It would
|
|
be a lot more useful with SFINAE if it were defined as an empty struct; that way, it can be used with <tt>enable_if</tt>
|
|
for determining whether or not it is valid to use <tt>tuple_size</tt>, <tt>tuple_element</tt> and get on the
|
|
corresponding data structure.
|
|
</p>
|
|
|
|
<p><i>[2014-11 Urbana]</i></p>
|
|
|
|
<p>Moved to LEWG 42.</p>
|
|
<p>
|
|
This request goes beyond simply making an API respond well to SFINAE, but coupling that with an
|
|
implication for other tuple APIs. The proper place for such design discussions is LEWG.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
This wording is relative to N3936.
|
|
</p>
|
|
|
|
<ol>
|
|
<li><p>Change 20.4.1 [tuple.general] p2, header <tt><tuple></tt> synopsis, as indicated</p>
|
|
<blockquote>
|
|
<pre>
|
|
[…]
|
|
// <i>20.4.2.5, tuple helper classes</i>:
|
|
template <class T> class tuple_size; <del>// undefined</del>
|
|
[…]
|
|
</pre>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 20.4.2.5 [tuple.helper] as indicated</p>
|
|
<blockquote>
|
|
<pre>
|
|
[…]
|
|
template <class T> struct tuple_size <ins>{ }</ins>;
|
|
[…]
|
|
</pre>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2447"></a>2447. Allocators and <tt>volatile</tt>-qualified value types</h3>
|
|
<p><b>Section:</b> 17.6.3.5 [allocator.requirements] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2014-10-16 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
According to Table 27 — "Descriptive variable definitions" which is used to define the symbols used in the
|
|
allocator requirements table within 17.6.3.5 [allocator.requirements] we have the following constraints for
|
|
the types <tt>T, U, C</tt>:
|
|
</p>
|
|
<blockquote><p>
|
|
any non-const object type (3.9)
|
|
</p></blockquote>
|
|
<p>
|
|
This wording can be read to allow instead a <tt>volatile</tt>-qualified value type such as <tt>volatile int</tt>.
|
|
<p/>
|
|
The nearest-by way of fixing this would be to add "non-<tt>volatile</tt>" as additional constraint to this table
|
|
row.
|
|
<p/>
|
|
Another choice would be to think of requiring that allocators must be capable to handle any <tt><i>cv</i></tt>-qualified
|
|
value types. This would make all currently existing allocators non-conforming that can't handle <tt><i>cv</i></tt>-qualified
|
|
value types, so I'm not suggesting to follow that route.
|
|
<p/>
|
|
A less radical step would be to allow <tt><ii>cv</ii></tt>-qualified types just for <tt>C</tt> (which is used to specify the
|
|
functions <tt>construct</tt> and <tt>destroy</tt> and where does not even exist any requirement that <tt>C</tt> actually
|
|
is related to the value type of the allocator at all). This seemingly extension would be harmless because as of p8 of the
|
|
same sub-clause "An allocator may constrain the types on which it can be instantiated and the arguments for which its
|
|
<tt>construct</tt> member may be called."
|
|
<p/>
|
|
This differs from the requirements imposed on the types <tt>T</tt> and <tt>U</tt> which both refer to value types of allocators.
|
|
<p/>
|
|
The proposed wording attempts to separate the two classes of requirements.
|
|
</p>
|
|
|
|
<p>
|
|
<strong>Previous resolution [SUPERSEDED]:</strong>
|
|
</p>
|
|
<blockquote class="note">
|
|
<p>
|
|
This wording is relative to N4140.
|
|
</p>
|
|
|
|
<ol>
|
|
<li><p>Change 17.6.3.5 [allocator.requirements], Table 27 — "Descriptive variable definitions", as indicated:</p>
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 27 — Descriptive variable definitions</caption>
|
|
<tr>
|
|
<th>Variable</th>
|
|
<th>Definition</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>T, U<del>, C</del></tt>
|
|
</td>
|
|
<td>
|
|
any non-<del>const</del><ins><tt>const</tt> and non-<tt>volatile</tt></ins> object type (3.9)
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<ins><tt>C</tt></ins>
|
|
</td>
|
|
<td>
|
|
<ins>any object type</ins>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="2" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 17.6.3.5 [allocator.requirements] p8 as indicated: (This wording change is intended to
|
|
fix an obvious asymmetry between <tt>construct</tt> and <tt>destroy</tt> which I believe is not intended)</p>
|
|
|
|
<blockquote><p>
|
|
-8- An allocator may constrain the types on which it can be instantiated and the arguments for which its
|
|
<tt>construct</tt> <ins>or <tt>destroy</tt></ins> member<ins>s</ins> may be called. If a type cannot be
|
|
used with a particular allocator, the allocator class or the call to <tt>construct</tt> <ins>or <tt>destroy</tt></ins>
|
|
may fail to instantiate.
|
|
</p></blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
</blockquote>
|
|
|
|
<p><i>[2014-11, Urbana]</i></p>
|
|
|
|
<p>
|
|
JW: say "cv-unqualified" instead?<br/>
|
|
JW: very nervous about allowing construct on const-types, because of the cast to (non-const) <tt>void*</tt><br/>
|
|
MA: should we just make the minimal fix?<br/>
|
|
STL: don't break <tt>C</tt> out for special treatment<br/>
|
|
New proposed resolution: just change "non-const" to "cv-unqualified". Keep addition of <tt>destroy</tt> later.
|
|
</p>
|
|
|
|
<p><i>[2015-02 Cologne]</i></p>
|
|
|
|
<p>
|
|
GR: It makes me nervous that someone at some point decided to not add "non-<tt>volatile</tt>".<br/>
|
|
AM: That was over ten years ago. It was a deliberate, minuted choice to support <tt>volatile</tt>. We are now reversing that decision.
|
|
It would be good to poll our vendors, none of which are in the room. This is a bit more work than we expect of a P0 issue.<br/>
|
|
VV: libstdc++ and libc++ seem to support <tt>volatile</tt> template parameters for the standard allocator.<br/>
|
|
AM: To clarify, the proposed resolution here would remove the requirement to support <tt>volatile</tt>. Implementations could still
|
|
choose to support <tt>volatile</tt>.<br/>
|
|
DK: I'm happy to drop this and open a new issue in regard to the <tt>destroy</tt> member specification.<br/>
|
|
AM: I just think this is harder than a P0. Let's reprioritize.
|
|
</p>
|
|
|
|
<p><i>[2015-04-01 Daniel comments]</i></p>
|
|
|
|
<p>
|
|
The less controversial part of the issue related to constraints imposed on <tt>destroy</tt> has be handed over to the new
|
|
issue <a href="lwg-defects.html#2470">2470</a>.
|
|
</p>
|
|
|
|
<p><i>[2015-05-06 Lenexa: Move to Ready]</i></p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
This wording is relative to N4431.
|
|
</p>
|
|
|
|
<ol>
|
|
<li><p>Change 17.6.3.5 [allocator.requirements], Table 27 — "Descriptive variable definitions", as indicated:</p>
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 27 — Descriptive variable definitions</caption>
|
|
<tr>
|
|
<th>Variable</th>
|
|
<th>Definition</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>T, U, C</tt>
|
|
</td>
|
|
<td>
|
|
any <del>non-const</del><ins><i>cv</i>-unqualified</ins> object type (3.9)
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="2" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2449"></a>2449. <tt>vector::insert</tt> invalidates <tt>end()</tt>?</h3>
|
|
<p><b>Section:</b> 23.3.6.5 [vector.modifiers] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Marc Glisse <b>Opened:</b> 2014-10-21 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#vector.modifiers">active issues</a> in [vector.modifiers].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#vector.modifiers">issues</a> in [vector.modifiers].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
this issue is based on the discussion <a href="https://groups.google.com/a/isocpp.org/d/topic/std-discussion/oYvKscnl280/discussion">here</a>.
|
|
<p/>
|
|
23.3.6.5 [vector.modifiers] says about <tt>vector::insert</tt>: "If no reallocation happens, all the iterators and references
|
|
before the insertion point remain valid." This doesn't seem to guarantee anything about the iterator <em>at</em> the point of insertion.
|
|
<p/>
|
|
The question comes from people asking if the following is valid, assuming a sufficient call to <tt>reserve()</tt> was done first:
|
|
</p>
|
|
<blockquote><pre>
|
|
v.insert(v.end(), v.begin(), v.end());
|
|
</pre></blockquote>
|
|
<p>
|
|
It could fail for an implementation using a sentinel for the end of the vector, but I don't know of any (it would be quite
|
|
inconvenient). And for any implementation using a simple position as iterator (pointer (possibly in a wrapper), or base+offset),
|
|
this is needlessly restrictive. The fact that this alternative:
|
|
</p>
|
|
<blockquote><pre>
|
|
v.insert(v.end(), &v[0], &v[0]+v.size())
|
|
</pre></blockquote>
|
|
<p>
|
|
is arguably valid (again assuming a large enough <tt>reserve()</tt>) makes it a bit confusing that the first version isn't
|
|
(23.2.3 [sequence.reqmts] has a precondition that iterator arguments to <tt>insert()</tt> do not point into the sequence,
|
|
but <tt>vector::insert</tt> is more refined and seems to give enough guarantees that it cannot fail).
|
|
<p/>
|
|
Then we might as well say that <tt>vector</tt> iterators act as positions, and that after a reallocation-free operation an
|
|
iterator points to the same position, whatever may be there now…
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2450"></a>2450. <tt>(greater|less|greater_equal|less_equal)<void></tt> do not yield a total order for pointers</h3>
|
|
<p><b>Section:</b> 20.9.6 [comparisons] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Joaquín M López Muñoz <b>Opened:</b> 2014-10-30 <b>Last modified:</b> 2015-05-06</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#comparisons">active issues</a> in [comparisons].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#comparisons">issues</a> in [comparisons].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
<tt>less<void>::operator(t, u)</tt> (and the same applies to the rest of <tt>void</tt> specializations for standard
|
|
comparison function objects) returns <tt>t < u</tt> even if <tt>t</tt> and <tt>u</tt> are pointers, which by
|
|
5.9 [expr.rel]/3 is undefined except if both pointers point to the same array or object. This might be
|
|
regarded as a specification defect since the intention of N3421 is that <tt>less<></tt> can substitute for
|
|
<tt>less<T></tt> in any case where the latter is applicable. <tt>less<void></tt> can be rewritten in
|
|
the following manner to cope with pointers:
|
|
</p>
|
|
<blockquote><pre>
|
|
template<> struct less<void>
|
|
{
|
|
|
|
typedef <i>unspecified</i> is_transparent;
|
|
|
|
template <class T, class U>
|
|
struct pointer_overload : std::is_pointer<std::common_type_t<T, U>>
|
|
{};
|
|
|
|
template <
|
|
class T, class U,
|
|
typename std::enable_if<!pointer_overload<T, U>::value>::type* = nullptr
|
|
>
|
|
auto operator()(T&& t, U&& u) const
|
|
-> decltype(std::forward<T>(t) < std::forward<U>(u))
|
|
{
|
|
return std::forward<T>(t) < std::forward<U>(u);
|
|
}
|
|
|
|
template <
|
|
class T, class U,
|
|
typename std::enable_if<pointer_overload<T, U>::value>::type* = nullptr
|
|
>
|
|
auto operator()(T&& t, U&& u) const
|
|
-> decltype(std::declval<std::less<std::common_type_t<T, U>>>()(std::forward<T>(t), std::forward<U>(u)))
|
|
{
|
|
std::less<std::common_type_t<T, U>> l;
|
|
return l(std::forward<T>(t), std::forward<U>(u));
|
|
}
|
|
|
|
};
|
|
</pre></blockquote>
|
|
|
|
<blockquote class="note">
|
|
<p>
|
|
This wording is relative to N4140.
|
|
</p>
|
|
|
|
<ol>
|
|
<li><p>Change 20.9.6 [comparisons] p14 as indicated:</p>
|
|
<blockquote><p>
|
|
-14- For templates <tt>greater</tt>, <tt>less</tt>, <tt>greater_equal</tt>, and <tt>less_equal</tt>, the specializations
|
|
for any pointer type yield a total order, even if the built-in operators <tt><</tt>, <tt>></tt>, <tt><=</tt>,
|
|
<tt>>=</tt> do not. <ins>For template specializations <tt>greater<void></tt>, <tt>less<void></tt>,
|
|
<tt>greater_equal<void></tt>, and <tt>less_equal<void></tt>, the call operator with arguments whose common
|
|
type <tt><i>CT</i></tt> is a pointer yields the same value as the corresponding comparison function object class
|
|
specialization for <tt><i>CT</i></tt>.</ins>
|
|
</p></blockquote>
|
|
</li>
|
|
</ol>
|
|
</blockquote>
|
|
|
|
<p><i>[2015-02, Cologne]</i></p>
|
|
|
|
<p>
|
|
AM: Is there any way this will be resolved elsewhere? VV: No. AM: Then we should bite the bullet and deal with it here.
|
|
<p/>
|
|
MC: These diamond operators are already ugly. Making them more ugly isn't a big problem.
|
|
<p/>
|
|
JY found some issue with types that are convertible, and will reword.
|
|
<p/>
|
|
Jeffrey suggests improved wording.
|
|
</p>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
STL: when diamond functions designed, this was on purpose<br/>
|
|
STL: this does go against the original design<br/>
|
|
STL: library is smarter and can give a total order<br/>
|
|
MC: given that the original design rejected this, give back to LEWG<br/>
|
|
STL: original proposal did not talk about total order<br/>
|
|
STL: don't feel strongly about changing the design<br/>
|
|
STL: no objections to taking this issue with some wording changes if people want it<br/>
|
|
MC: not happy with wording, comparing pointers — what does that mean?<br/>
|
|
STL: needs careful attention to wording<br/>
|
|
STL: want to guarantee that <tt>nullptr</tt> participates in total ordering<br/>
|
|
STL: all hooks into composite pointer type<br/>
|
|
MC: move from new to open with better wording<br/>
|
|
STL: to check updates to issue after Lenexa
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
This wording is relative to N4296.
|
|
</p>
|
|
|
|
<ol>
|
|
<li><p>Change 20.9.6 [comparisons] p14 as indicated:</p>
|
|
<blockquote><p>
|
|
-14- For templates <tt>greater</tt>, <tt>less</tt>, <tt>greater_equal</tt>, and <tt>less_equal</tt>, the specializations
|
|
for any pointer type yield a total order, even if the built-in operators <tt><</tt>, <tt>></tt>, <tt><=</tt>,
|
|
<tt>>=</tt> do not. <ins>For template specializations <tt>greater<void></tt>, <tt>less<void></tt>,
|
|
<tt>greater_equal<void></tt>, and <tt>less_equal<void></tt>, if the call operator calls a built-in operator
|
|
comparing pointers, the call operator yields a total order.</ins>
|
|
</p></blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2451"></a>2451. [fund.ts] <tt>optional<T></tt> should 'forward' <tt>T</tt>'s implicit conversions</h3>
|
|
<p><b>Section:</b> X [optional.object] <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
|
|
<b>Submitter:</b> Geoffrey Romer <b>Opened:</b> 2014-10-31 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p><b>Addresses: fund.ts</b></p>
|
|
<p>
|
|
Code such as the following is currently ill-formed (thanks to STL for the compelling example):
|
|
</p>
|
|
<blockquote><pre>
|
|
optional<string> opt_str = "meow";
|
|
</pre></blockquote>
|
|
<p>
|
|
This is because it would require two user-defined conversions (from <tt>const char*</tt> to <tt>string</tt>,
|
|
and from <tt>string</tt> to <tt>optional<string></tt>) where the language permits only one. This is
|
|
likely to be a surprise and an inconvenience for users.
|
|
<p/>
|
|
<tt>optional<T></tt> should be implicitly convertible from any <tt>U</tt> that is implicitly convertible
|
|
to <tt>T</tt>. This can be implemented as a non-explicit constructor template <tt>optional(U&&)</tt>,
|
|
which is enabled via SFINAE only if <tt>is_convertible_v<U, T></tt> and <tt>is_constructible_v<T, U></tt>,
|
|
plus any additional conditions needed to avoid ambiguity with other constructors (see
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4064.html">N4064</a>, particularly the
|
|
"Odd" example, for why <tt>is_convertible</tt> and <tt>is_constructible</tt> are both needed; thanks to Howard
|
|
Hinnant for spotting this).
|
|
<p/>
|
|
In addition, we may want to support explicit construction from <tt>U</tt>, which would mean providing a corresponding
|
|
explicit constructor with a complementary SFINAE condition (this is the single-argument case of the "perfect
|
|
initialization" pattern described in N4064).
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2452"></a>2452. <tt>is_constructible</tt>, etc. and default arguments</h3>
|
|
<p><b>Section:</b> 20.10 [meta] <b>Status:</b> <a href="lwg-active.html#Core">Core</a>
|
|
<b>Submitter:</b> Hubert Tong <b>Opened:</b> 2014-11-04 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#meta">active issues</a> in [meta].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#meta">issues</a> in [meta].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Core">Core</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The <tt>BaseCharacteristic</tt> for <tt>is_constructible</tt> is defined in terms of the well-formedness
|
|
of a declaration for an invented variable. The well-formedness of the described declaration itself may
|
|
change for the same set of arguments because of the introduction of default arguments.
|
|
<p/>
|
|
In the following program, there appears to be conflicting definitions of a specialization of
|
|
<tt>std::is_constructible</tt>; however, it seems that this situation is caused without a user violation
|
|
of the library requirements or the ODR. There is a similar issue with <tt>is_convertible</tt>, <tt>result_of</tt>
|
|
and others.
|
|
<p/>
|
|
a.cc:
|
|
</p>
|
|
<blockquote><pre>
|
|
#include <type_traits>
|
|
struct A { A(int, int); };
|
|
const std::false_type& x1 = std::is_constructible<A, int>();
|
|
|
|
int main() { }
|
|
</pre></blockquote>
|
|
<p>
|
|
b.cc:
|
|
</p>
|
|
<blockquote><pre>
|
|
#include <type_traits>
|
|
struct A { A(int, int); };
|
|
|
|
inline A::A(int, int = 0) { }
|
|
|
|
const std::true_type& x2 = std::is_constructible<A, int>();
|
|
</pre></blockquote>
|
|
<p>
|
|
Presumably this program should invoke undefined behaviour, but the Library specification doesn't
|
|
say that.
|
|
</p>
|
|
|
|
<p><i>[2015-02 Cologne]</i></p>
|
|
|
|
<p>
|
|
Core wording should say "this kind of thing is ill-formed, no diagnostic required"
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2453"></a>2453. [iterator.range] and now [iterator.container] aren't available via <tt><initializer_list></tt></h3>
|
|
<p><b>Section:</b> 18.9 [support.initlist], 24.7 [iterator.range], 24.8 [iterator.container] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Richard Smith <b>Opened:</b> 2014-11-11 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#support.initlist">active issues</a> in [support.initlist].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#support.initlist">issues</a> in [support.initlist].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
These sections define helper functions, some of which apply to <tt>initializer_list<T></tt>. And they're
|
|
available if you include one of a long list of header files, many of which include <tt><initializer_list></tt>.
|
|
But they are not available if you include <tt><initializer_list></tt>. This seems very odd.
|
|
</p>
|
|
<blockquote><pre>
|
|
#include <initializer_list>
|
|
auto x = {1, 2, 3};
|
|
const int *p = data(x); // error, undeclared
|
|
#include <vector>
|
|
const int *q = data(x); // ok
|
|
</pre></blockquote>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2456"></a>2456. Incorrect exception specifications for '<tt>swap</tt>' throughout library</h3>
|
|
<p><b>Section:</b> 20.2 [utility], 20.3.2 [pairs.pair], 20.4 [tuple], 23.3.2 [array], 23.6.3 [queue], 23.6.4 [priority.queue], 23.6.5 [stack] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
|
|
<b>Submitter:</b> Richard Smith <b>Opened:</b> 2014-11-14 <b>Last modified:</b> 2015-05-05</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#utility">active issues</a> in [utility].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#utility">issues</a> in [utility].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
We have this antipattern in various library classes:
|
|
</p>
|
|
<blockquote><pre>
|
|
void swap(priority_queue& q) noexcept(
|
|
noexcept(swap(c, q.c)) && noexcept(swap(comp, q.comp)))
|
|
</pre></blockquote>
|
|
<p>
|
|
This doesn't work. The unqualified lookup for 'swap' finds the member named 'swap', and that suppresses ADL,
|
|
so the exception specification is always ill-formed because you can't call the member 'swap' with two arguments.
|
|
<p/>
|
|
Relevant history on the core language side:
|
|
<p/>
|
|
This used to be ill-formed due to 3.3.7 [basic.scope.class] p1 rule 2: "A name <tt>N</tt> used in a class
|
|
<tt>S</tt> shall refer to the same declaration in its context and when re-evaluated in the completed scope of <tt>S</tt>.
|
|
No diagnostic is required for a violation of this rule."
|
|
<p/>
|
|
Core issue 1330 introduced delay-parsing for exception specifications. Due to the 3.3.7 [basic.scope.class] rules,
|
|
this shouldn't have changed the behavior of any conforming programs. But it changes the behavior in the non-conforming
|
|
case from "no diagnostic required" to "diagnostic required", so implementations that implement core issue 1330 are now
|
|
required to diagnose the ill-formed declarations in the standard library.
|
|
<p/>
|
|
Suggested resolution:
|
|
<p/>
|
|
Add an <tt>is_nothrow_swappable</tt> trait, and use it throughout the library in place of these <tt>noexcept</tt> expressions.
|
|
</p>
|
|
|
|
<p><i>[2015-02, Cologne]</i></p>
|
|
|
|
<p>
|
|
No action for now; we intend to have papers for Lenexa.
|
|
</p>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
Move to Open.
|
|
<p/>
|
|
Daniel: A first paper (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4426.html">N4426</a>) exists
|
|
to suggest some ways of solving this issue.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2457"></a>2457. <tt>std::begin()</tt> and <tt>std::end()</tt> do not support multi-dimensional arrays correctly</h3>
|
|
<p><b>Section:</b> 24.7 [iterator.range] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Janez Žemva <b>Opened:</b> 2014-11-16 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#iterator.range">active issues</a> in [iterator.range].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#iterator.range">issues</a> in [iterator.range].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The following code:
|
|
</p>
|
|
<blockquote><pre>
|
|
#include <algorithm>
|
|
#include <iterator>
|
|
#include <iostream>
|
|
#include <cassert>
|
|
|
|
int main()
|
|
{
|
|
int a[2][3][4] = { { { 1, 2, 3, 4}, { 5, 6, 7, 8}, { 9, 10, 11, 12} },
|
|
{ {13, 14, 15, 16}, {17, 18, 19, 20}, {21, 22, 23, 24} } };
|
|
int b[2][3][4];
|
|
|
|
assert(std::distance(std::begin(a), std::end(a)) == 2 * 3 * 4);
|
|
std::copy(std::begin(a), std::end(a), std::begin(b));
|
|
std::copy(std::begin(b), std::end(b), std::ostream_iterator<int>(std::cout, ","));
|
|
}
|
|
</pre></blockquote>
|
|
<p>
|
|
does not compile.
|
|
<p/>
|
|
A possible way to remedy this would be to add the following overloads of
|
|
<tt>begin</tt>, <tt>end</tt>, <tt>rbegin</tt>, and <tt>rend</tt> to 24.7 [iterator.range],
|
|
relying on recursive evaluation:
|
|
</p>
|
|
<blockquote><pre>
|
|
namespace std {
|
|
|
|
template <typename T, size_t M, size_t N>
|
|
constexpr remove_all_extents_t<T>*
|
|
begin(T (&array)[M][N])
|
|
{
|
|
return begin(*array);
|
|
}
|
|
|
|
template <typename T, size_t M, size_t N>
|
|
constexpr remove_all_extents_t<T>*
|
|
end(T (&array)[M][N])
|
|
{
|
|
return end(array[M - 1]);
|
|
}
|
|
|
|
template <typename T, size_t M, size_t N>
|
|
reverse_iterator<remove_all_extents_t<T>*>
|
|
rbegin(T (&array)[M][N])
|
|
{
|
|
return decltype(rbegin(array))(end(array[M - 1]));
|
|
}
|
|
|
|
template <typename T, size_t M, size_t N>
|
|
reverse_iterator<remove_all_extents_t<T>*>
|
|
rend(T (&array)[M][N])
|
|
{
|
|
return decltype(rend(array))(begin(*array));
|
|
}
|
|
|
|
}
|
|
</pre></blockquote>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2460"></a>2460. LWG issue 2408 and value categories</h3>
|
|
<p><b>Section:</b> 20.10.7.6 [meta.trans.other], 24.4.1 [iterator.traits] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Richard Smith <b>Opened:</b> 2014-11-19 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
LWG issue <a href="lwg-defects.html#2408">2408</a> changes the meat of the specification of <tt>common_type</tt> to compute:
|
|
</p>
|
|
<blockquote><p>
|
|
[..] the type, if any, of an unevaluated conditional expression (5.16) whose first operand is an
|
|
arbitrary value of type <tt>bool</tt>, whose second operand is an <tt>xvalue</tt> of type <tt>T1</tt>,
|
|
and whose third operand is an xvalue of type <tt>T2</tt>.
|
|
</p></blockquote>
|
|
<p>
|
|
This has an effect on the specification that I think was unintended. It used to be the case that
|
|
<tt>common_type<T&, U&&></tt> would consider the type of a conditional between an
|
|
lvalue of type <tt>T</tt> and an xvalue of type <tt>U</tt>. It's now either invalid (because there is
|
|
no such thing as an xvalue of reference type) or considers the type of a conditional between an xvalue
|
|
of type <tt>T</tt> and an xvalue of type <tt>U</tt>, depending on how you choose to read it.
|
|
<p/>
|
|
Put another way, this has the effect of changing the usual definition from:
|
|
</p>
|
|
<blockquote><pre>
|
|
typedef decay_t<decltype(true ? declval<T>() : declval<U>())> type;
|
|
</pre></blockquote>
|
|
<p>
|
|
to:
|
|
</p>
|
|
<blockquote><pre>
|
|
typedef decay_t<decltype(true ? declval<remove_reference_t<T>>() : declval<remove_reference_t<U>>())> type;
|
|
</pre></blockquote>
|
|
<p>
|
|
It also makes <tt>common_type</tt> underspecified in the case where one of the operands is of type <tt>void</tt>;
|
|
in that case, the resulting type depends on whether the expression is a throw-expression, which is not
|
|
specified (but used to be).
|
|
<p/>
|
|
Also on the subject of this wording: the changes to 24.4.1 [iterator.traits] say that
|
|
<tt>iterator_traits<T></tt> "shall have no members" in some cases. That's wrong. It's a class type;
|
|
it always has at least a copy constructor, a copy assignment operator, and a destructor. Plus this
|
|
removes the usual library liberty to add additional members with names that don't collide with normal
|
|
usage (for instance, if a later version of the standard adds members, they can't be present here as a
|
|
conforming extension). Perhaps this should instead require that the class doesn't have members with any
|
|
of those five names? That's what <a href="lwg-defects.html#2408">2408</a> does for <tt>common_type</tt>'s type member.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2461"></a>2461. Interaction between allocators and container exception safety guarantees</h3>
|
|
<p><b>Section:</b> 17.6.3.5 [allocator.requirements], 23.3.6.3 [vector.capacity], 23.3.6.5 [vector.modifiers] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> dyp <b>Opened:</b> 2014-12-06 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
When resizing a <tt>vector</tt>, the accessibility and exception specification of the value type's
|
|
constructors determines whether the elements are copied or moved to the new buffer.
|
|
However, the copy/move is performed via the allocator's <tt>construct</tt> member function, which is
|
|
assumed, but not required, to call the copy/move constructor and propagate only exceptions
|
|
from the value type's copy/move constructor. The issue might also affect other classes.
|
|
<p/>
|
|
The current wording in N4296 relevant here is from Table 28 — "Allocator requirements" in
|
|
17.6.3.5 [allocator.requirements]:
|
|
</p>
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 28 — Allocator requirements</caption>
|
|
<tr>
|
|
<th>Expression</th>
|
|
<th>Return type</th>
|
|
<th>Assertion/note<br/>pre-/post-condition</th>
|
|
<th>Default</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="4" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a.construct(c, args)</tt>
|
|
</td>
|
|
<td>
|
|
(not used)
|
|
</td>
|
|
<td>
|
|
<i>Effect</i>: Constructs an object of type <tt>C</tt> at <tt>c</tt>
|
|
</td>
|
|
<td>
|
|
<tt>::new ((void*)c) C(forward<Args>(args)...)</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="4" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote>
|
|
<p>
|
|
and from 17.6.3.5 [allocator.requirements] p9:
|
|
</p>
|
|
<blockquote><p>
|
|
An allocator may constrain the types on which it can be instantiated and the arguments for which its
|
|
<tt>construct</tt> member may be called. If a type cannot be used with a particular allocator, the allocator class
|
|
or the call to <tt>construct</tt> may fail to instantiate.
|
|
</p></blockquote>
|
|
<p>
|
|
I conclude the following from the wording:
|
|
</p>
|
|
<ol>
|
|
<li><p>The allocator is not required to call the copy constructor if the
|
|
arguments (args) is a single (potentially const) lvalue of the value
|
|
type. Similarly for a non-const rvalue + move constructor. See also
|
|
23.2.1 [container.requirements.general] p15 which seems to try to require
|
|
this, but is not sufficient:
|
|
That paragraph specifies the semantics of the allocator's operations,
|
|
but not which constructors of the value type are used, if any.
|
|
</p></li>
|
|
<li>
|
|
<p>The allocator may throw exceptions in addition to the exceptions propagated by
|
|
the constructors of the value type; it can also propagate exceptions from constructors
|
|
other than a copy/move constructor.
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
<p>
|
|
This leads to an issue with the wording of the exception safety guarantees for vector modifiers in
|
|
23.3.6.5 [vector.modifiers] p1:
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
[…]
|
|
</p>
|
|
<pre>
|
|
void push_back(const T& x);
|
|
void push_back(T&& x);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
<i>Remarks</i>: Causes reallocation if the new size is greater than the old capacity. If no
|
|
reallocation happens, all the iterators and references before the insertion point remain valid.
|
|
If an exception is thrown other than by the copy constructor, move constructor, assignment
|
|
operator, or move assignment operator of <tt>T</tt> or by any InputIterator operation there are
|
|
no effects.
|
|
<span style="color:#C80000;font-weight:bold">
|
|
If an exception is thrown while inserting a single element at the end and <tt>T</tt>
|
|
is <tt>CopyInsertable</tt> or <tt>is_nothrow_move_constructible<T>::value</tt>
|
|
is true, there are no effects. Otherwise, if an exception is thrown by the move constructor of a
|
|
non-<tt>CopyInsertable</tt> <tt>T</tt>, the effects are unspecified.
|
|
</span>
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
<p>
|
|
The wording leads to the following problem:
|
|
Copy and move assignment are invoked directly from <tt>vector</tt>.
|
|
For intermediary objects (see <a href="lwg-active.html#2164">2164</a>),
|
|
<tt>vector</tt> also directly invokes the copy and move constructor of the value type.
|
|
However, construction of the actual element within the buffer is invoked via the allocator abstraction.
|
|
As discussed above, the allocator currently is not required to call a copy/move constructor.
|
|
If <tt>is_nothrow_move_constructible<T>::value</tt> is <tt>true</tt> for some value type <tt>T</tt>,
|
|
but the allocator uses modifying operations for <tt>MoveInsertion</tt> that do throw,
|
|
the implementation is required to ensure that "there are no effects",
|
|
even if the source buffer has been modified.
|
|
<p/>
|
|
Similarly, the <tt>vector</tt> capacity functions specify exception safety guarantees
|
|
referring to the move constructor of the value type. For example, <tt>vector::resize</tt> in 23.3.6.3 [vector.capacity] p14:
|
|
</p>
|
|
<blockquote>
|
|
<i>Remarks</i>: If an exception is thrown other than by the move constructor of a
|
|
non-<tt>CopyInsertable</tt> <tt>T</tt> there are no effects.
|
|
</blockquote>
|
|
<p>
|
|
The wording leads to the same issue as described above.
|
|
<p/>
|
|
Code example:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
template<class T>
|
|
class allocator;
|
|
|
|
class pot_reg_type // a type which creates
|
|
// potentially registered instances
|
|
{
|
|
private:
|
|
friend class allocator<pot_reg_type>;
|
|
struct register_t {};
|
|
|
|
static std::set<pot_reg_type*>& get_registry()
|
|
{
|
|
static std::set<pot_reg_type*> registry;
|
|
return registry;
|
|
}
|
|
void enregister() noexcept(false)
|
|
{
|
|
get_registry().insert(this);
|
|
}
|
|
void deregister()
|
|
{
|
|
get_registry().erase(this);
|
|
}
|
|
|
|
public:
|
|
pot_reg_type(void ) noexcept(true) {}
|
|
pot_reg_type(pot_reg_type const&) noexcept(true) {}
|
|
pot_reg_type(pot_reg_type&& ) noexcept(true) {}
|
|
|
|
private:
|
|
pot_reg_type(register_t ) noexcept(false)
|
|
{ enregister(); }
|
|
pot_reg_type(register_t, pot_reg_type const&) noexcept(false)
|
|
{ enregister(); }
|
|
pot_reg_type(register_t, pot_reg_type&& ) noexcept(false)
|
|
{ enregister(); }
|
|
};
|
|
|
|
template<class T>
|
|
class allocator
|
|
{
|
|
public:
|
|
using value_type = T;
|
|
|
|
value_type* allocate(std::size_t p)
|
|
{ return (value_type*) ::operator new(p); }
|
|
|
|
void deallocate(value_type* p, std::size_t)
|
|
{ ::operator delete(p); }
|
|
|
|
void construct(pot_reg_type* pos)
|
|
{
|
|
new((void*)pos) pot_reg_type((pot_reg_type::register_t()));
|
|
}
|
|
void construct(pot_reg_type* pos, pot_reg_type const& source)
|
|
{
|
|
new((void*)pos) pot_reg_type(pot_reg_type::register_t(), source);
|
|
}
|
|
|
|
template<class... Args>
|
|
void construct(T* p, Args&&... args)
|
|
{
|
|
new((void*)p) T(std::forward<Args>(args)...);
|
|
}
|
|
};
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
The <tt>construct</tt> member function template is only required for rebinding,
|
|
which can be required e.g. to store additional debug information in
|
|
the allocated memory (e.g. VS2013).
|
|
<p/>
|
|
Even though the value type has an accessible and <tt>noexcept(true)</tt> move
|
|
constructor, this allocator won't call that constructor for rvalue arguments.
|
|
In any case, it does not call a constructor for which vector has formulated its
|
|
requirements. An exception thrown by a constructor called by this allocator is not
|
|
covered by the specification in 23.3.6.5 [vector.modifiers] and therefore is
|
|
guaranteed not to have any effect on the vector object when resizing.
|
|
<p/>
|
|
For an example how this might invalidate the exception safety
|
|
guarantees, see <a href="https://groups.google.com/a/isocpp.org/d/topic/std-discussion/BcM7ya8JeqY/discussion">this post on the std-discussion mailing list</a>.
|
|
<p/>
|
|
Another problem arises for value types whose constructors are private,
|
|
but may be called by the allocator e.g. via friendship.
|
|
Those value types are not <tt>MoveConstructible</tt>
|
|
(<tt>is_move_constructible</tt> is false), yet they can be <tt>MoveInsertable</tt>.
|
|
It is not possible for <tt>vector</tt> to create intermediary objects (see <a href="lwg-active.html#2164">2164</a>) of such a type
|
|
by directly using the move constructor.
|
|
Current implementations of the single-element forms of <tt>vector::insert</tt> and <tt>vector::emplace</tt>
|
|
do create intermediary objects by directly calling one of the value type's constructors,
|
|
probably to allow inserting objects from references that alias other elements of the container.
|
|
As far as I can see, Table 100 — "Sequence container requirements" in 23.2.3 [sequence.reqmts]
|
|
does not require that the creation of such intermediare objects can be performed
|
|
by containers using the value type's constructor directly.
|
|
It is unclear to me if the allocator's construct function could be used to create those
|
|
intermediary objects, given that they have not been allocated by the allocator.
|
|
<p/>
|
|
Two possible solutions:
|
|
</p>
|
|
<ol>
|
|
<li><p>
|
|
Add the following requirement to the <tt>allocator_traits::construct</tt> function:
|
|
If the parameter pack <tt>args</tt> consists of a single parameter of the type
|
|
<tt>value_type&&</tt>,
|
|
the function may only propagate exceptions if <tt>is_nothrow_move_constructible<value_type>::value</tt>
|
|
is <tt>false</tt>.
|
|
<p/>
|
|
Requiring <tt>alloctor_traits::construct</tt> to call a true copy/move constructor
|
|
of the value type breaks <tt>std::scoped_allocator_adapter</tt>,
|
|
as pointed out by <a href="https://groups.google.com/a/isocpp.org/d/msg/std-discussion/0yxikZInp-E/Lxj-msFT22cJ">Casey Carter in a post on the std-discussion mailing list</a>.
|
|
</p></li>
|
|
<li>
|
|
<p>
|
|
Change vector's criterion whether to move or copy when resizing:
|
|
<p/>
|
|
Instead of testing the value type's constructors via
|
|
<tt>is_move_constructible</tt>, check the value of
|
|
<tt>noexcept( allocator_traits<Allocator>::construct(alloc, ptr, rval) )</tt>
|
|
where
|
|
<tt>alloc</tt> is an lvalue of type <tt>Allocator</tt>,
|
|
<tt>ptr</tt> is an expression of type <tt>allocator_traits<Allocator>::pointer</tt>
|
|
and
|
|
<tt>rval</tt> is a non-const rvalue of type <tt>value_type</tt>.
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
<p>
|
|
A short discussion of the two solutions:
|
|
<p/>
|
|
Solution 1 allows keeping <tt>is_nothrow_move_constructible<value_type></tt>
|
|
as the criterion for <tt>vector</tt> to decide between copying and moving when resizing.
|
|
It restricts what can be done inside the <tt>construct</tt> member function of allocators,
|
|
and requires implementers of allocators to pay attention to the value types used.
|
|
One could conceive allocators checking the following with a <tt>static_assert</tt>:
|
|
If the value type <tt>is_nothrow_move_constructible</tt>,
|
|
then the constructor actually called for <tt>MoveInsertion</tt> within the <tt>construct</tt>
|
|
member function is also declared as noexcept.
|
|
<p/>
|
|
Solution 2 requires changing both the implementation of the default
|
|
allocator (add a conditional <tt>noexcept</tt>) and <tt>vector</tt> (replace
|
|
<tt>is_move_constructible</tt> with an allocator-targeted check).
|
|
It does not impose additional restrictions on the allocator (other than
|
|
23.2.1 [container.requirements.general] p15),
|
|
and works nicely even if the move constructor of a <tt>MoveInsertable</tt> type is private or deleted
|
|
(the allocator might be a friend of the value type).
|
|
<p/>
|
|
In both cases, an addition might be required to provide the basic exception safety guarantee.
|
|
A short discussion on this topic can be found
|
|
<a href="https://groups.google.com/a/isocpp.org/d/topic/std-discussion/yZLnYy_y2z0/discussion">
|
|
in the std-discussion mailing list</a>.
|
|
Essentially, if <tt>allocator_traits<Allocator>::construct</tt> throws an exception,
|
|
the object may or may not have been constructed.
|
|
Two solutions are mentioned in that discussion:
|
|
</p>
|
|
<ol>
|
|
<li><p>
|
|
<tt>allocator_traits<Allocator>::construct</tt> needs to tell its caller
|
|
whether or not the construction was successful, in case of an exception.
|
|
</p></li>
|
|
<li><p>
|
|
If <tt>allocator_traits<Allocator>::construct</tt> propagates an exception,
|
|
it shall either not have constructed an object at the specified location,
|
|
or that object shall have been destroyed
|
|
(or it shall ensure otherwise that no resources are leaked).
|
|
</p></li>
|
|
</ol>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2462"></a>2462. <tt>std::ios_base::failure</tt> is overspecified</h3>
|
|
<p><b>Section:</b> 27.5.3 [ios.base], 27.5.3.1.1 [ios::failure] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2014-12-15 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#ios.base">issues</a> in [ios.base].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
27.5.3 [ios.base] defines <tt>ios_base::failure</tt> as a nested class:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
namespace std {
|
|
class ios_base {
|
|
public:
|
|
class failure;
|
|
[…]
|
|
};
|
|
[…]
|
|
}
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
This means it is valid to use an elaborated-type-specifier to
|
|
refer to <tt>ios_base::failure</tt>:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
using F = class std::ios_base::failure;
|
|
throw F();
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
Therefore implementations are not permitted to define
|
|
<tt>ios_base::failure</tt> as a typedef e.g.
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
class ios_base {
|
|
public:
|
|
#if __cplusplus < 201103L
|
|
class failure_cxx03 : public exception {...};
|
|
typedef failure_cxx03 failure;
|
|
#else
|
|
class failure_cxx11 : public system_error {...};
|
|
typedef failure_cxx11 failure;
|
|
#endif
|
|
[…]
|
|
};
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
This constrains implementations, making it harder to manage the ABI
|
|
change to <tt>ios_base::failure</tt> between C++03 and C++11.
|
|
</p>
|
|
|
|
<p><i>[2015-05-06 Lenexa: Move to Ready]</i></p>
|
|
|
|
<p>JW: the issue is that users are currently allowed to write "class failure" with an elaborated-type-specifier and it must be well-formed, I want the freedom to make that type a typedef, so they can't necessarily use an elaborated-type-specifier (which there is no good reason to use anyway)</p>
|
|
<p>JW: ideally I'd like this everywhere for all nested classes, but that's a paper not an issue, I only need this type fixed right now.</p>
|
|
<p>RD: is a synonym the same as an alias?</p>
|
|
<p>JW: dcl.typedef says a typedef introduces a synonym for another type, so I think this is the right way to say this</p>
|
|
<p>JW: I already shipped this last month</p>
|
|
<p>PJP: we're going to have to break ABIs again some time, we need all the wiggle room we can get to make that easier. This helps.</p>
|
|
<p>MC: do we want this at all? Ready?</p>
|
|
<p>9 in favor, none opose or abstaining</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N4296.</p>
|
|
|
|
<ol>
|
|
<li><p>Change the synopsis in 27.5.3 [ios.base] as indicated:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
namespace std {
|
|
class ios_base {
|
|
public:
|
|
class failure; <ins><i>// see below</i></ins>
|
|
[…]
|
|
};
|
|
[…]
|
|
};
|
|
</pre>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 27.5.3 [ios.base] paragraph 1:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<tt>ios_base</tt> defines several member types:
|
|
</p>
|
|
<ul>
|
|
<li><p>a <del>class <tt>failure</tt></del><ins>type <tt>failure</tt>, defined as either
|
|
a class derived from <tt>system_error</tt> or a synonym for a class</ins> derived from
|
|
<tt>system_error</tt>;</p></li>
|
|
</ul>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 27.5.3.1.1 [ios::failure] paragraph 1:</p>
|
|
<blockquote>
|
|
<p>
|
|
-1- <ins>An implementation is permitted to define <tt>ios_base::failure</tt> as
|
|
a synonym for a class with equivalent functionality to class <tt>ios_base::failure</tt> shown
|
|
in this subclause. [<i>Note</i>: When <tt>ios_base::failure</tt> is a synonym for another type
|
|
it shall provide a nested type <tt>failure</tt>, to emulate the injected class name. —
|
|
<i>end note</i>]</ins> The class <tt>failure</tt> defines the base class for the types of all
|
|
objects thrown as exceptions, by functions in the iostreams library, to report errors detected
|
|
during stream buffer operations.
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2465"></a>2465. SFINAE-friendly <tt>common_type</tt> is nearly impossible to specialize
|
|
correctly and regresses key functionality</h3>
|
|
<p><b>Section:</b> 20.10.7.6 [meta.trans.other] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Eric Niebler <b>Opened:</b> 2015-01-12 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
I think there's a defect regarding <tt>common_type</tt> and its specializations.
|
|
Unless I've missed it, there is nothing preventing folks from
|
|
instantiating <tt>common_type</tt> with <i>cv</i>-qualified types or reference types. In
|
|
fact, the wording in N3797 explicitly mentions <i>cv</i> <tt>void</tt>, so presumably at
|
|
least <i>cv</i> qualifications are allowed.
|
|
<p/>
|
|
Users are given license to specialize <tt>common_type</tt> when at least of of
|
|
the types is user-defined. (A separate issue is the meaning of
|
|
user-defined. In core, I believe this is any class/struct/union/enum,
|
|
but in lib, I think it means any type not defined in std, right?) There
|
|
is at least one place in the standard that specializes <tt>common_type</tt>
|
|
(time.traits.specializations) on time_point and duration. But the
|
|
specializations are only for non-<i>cv</i>-qualified and non-reference
|
|
specializations of <tt>time_point</tt> and <tt>duration</tt>.
|
|
<p/>
|
|
If the user uses, say, <tt>common_type<duration<X,Y> const, duration<A,B>
|
|
const></tt>, they're not going to get the behavior they expect.
|
|
<p/>
|
|
Suggest we clarify the requirements of <tt>common_type</tt>'s template
|
|
parameters. Also, perhaps we can add blanket wording that <tt>common_type<A
|
|
[<i>cv</i>][&], B [<i>cv</i>][&]></tt> is required to be equivalent to
|
|
<tt>common_type<A,B></tt> (if that is in fact the way we intent this to work).
|
|
<p/>
|
|
Also, the change to make <tt>common_type</tt> SFINAE-friendly regressed key
|
|
functionality, as noted by Agustín K-ballo Bergé in
|
|
<a href="http://accu.org/cgi-bin/wg21/message?wg=lib&msg=37178">c++std-lib-37178</a>.
|
|
Since <tt>decay_t</tt> is not applied until the very end of the type computation,
|
|
user specializations are very likely to to be found.
|
|
<p/>
|
|
Agustín says:
|
|
</p>
|
|
<blockquote class="note">
|
|
<p>
|
|
Consider the following snippet:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
struct X {};
|
|
struct Y { explicit Y(X){} };
|
|
|
|
namespace std {
|
|
template<> struct common_type<X, Y> { typedef Y type; };
|
|
template<> struct common_type<Y, X> { typedef Y type; };
|
|
}
|
|
|
|
static_assert(is_same<common_type_t<X, Y>, Y>()); // (A)
|
|
static_assert(is_same<common_type_t<X, Y, Y>, Y>()); // (B)
|
|
static_assert(is_same<common_type_t<X, X, Y>, Y>()); // (C)
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
Under the original wording, all three assertion holds. Under the current wording,
|
|
</p>
|
|
<ul>
|
|
<li><p>(A) picks the user-defined specialization, so the assertion holds.</p></li>
|
|
|
|
<li><p>(B) goes to the third bullet and, ignoring the user-defined specialization, looks for
|
|
<tt>decltype(true ? declval<X>() : declval<Y>())</tt>; since it is ill-formed
|
|
there is no common type.</p></li>
|
|
|
|
<li><p>(C) goes to the third bullet and yields <tt>common_type_t<X&&, Y></tt>, which again misses
|
|
the user-defined specialization.</p></li>
|
|
</ul>
|
|
</blockquote>
|
|
<p>
|
|
The discussion following <a href="http://accu.org/cgi-bin/wg21/message?wg=lib&msg=35636">c++std-lib-35636</a>
|
|
seemed to cohere around the idea that the primary <tt>common_type</tt> specialization should have the effect
|
|
of stripping top-level ref and <i>cv</i> qualifiers by applying <tt>std::decay_t</tt> to its arguments and,
|
|
if any of them change as a result of that transformation, re-dispatching to <tt>common_type</tt> on those transformed
|
|
arguments, thereby picking up any user-defined specializations. This change to <tt>common_type</tt> would make
|
|
the specializations in time.traits.specializations sufficient.
|
|
<p/>
|
|
<b>Suggested wording</b>:
|
|
<p/>
|
|
I'm afraid I don't know enough to suggest wording. But for exposition,
|
|
the following is my best shot at implementing the suggested resolution.
|
|
I believe it also fixes the regression noted by Agustín K-ballo Bergé in
|
|
<a href="http://accu.org/cgi-bin/wg21/message?wg=lib&msg=37178">c++std-lib-37178</a>.
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
namespace detail
|
|
{
|
|
template<typename T, typename U>
|
|
using default_common_t =
|
|
decltype(true? std::declval<T>() : std::declval<U>());
|
|
|
|
template<typename T, typename U, typename Enable = void>
|
|
struct common_type_if
|
|
{};
|
|
|
|
template<typename T, typename U>
|
|
struct common_type_if<T, U,
|
|
void_t<default_common_t<T, U>>>
|
|
{
|
|
using type = decay_t<default_common_t<T, U>>;
|
|
};
|
|
|
|
template<typename T, typename U,
|
|
typename TT = decay_t<T>, typename UU = decay_t<U>>
|
|
struct common_type2
|
|
: common_type<TT, UU> // Recurse to catch user specializations
|
|
{};
|
|
|
|
template<typename T, typename U>
|
|
struct common_type2<T, U, T, U>
|
|
: common_type_if<T, U>
|
|
{};
|
|
|
|
template<typename Meta, typename Enable = void>
|
|
struct has_type
|
|
: std::false_type
|
|
{};
|
|
|
|
template<typename Meta>
|
|
struct has_type<Meta, void_t<typename Meta::type>>
|
|
: std::true_type
|
|
{};
|
|
|
|
template<typename Meta, typename...Ts>
|
|
struct common_type_recurse
|
|
: common_type<typename Meta::type, Ts...>
|
|
{};
|
|
|
|
template<typename Meta, typename...Ts>
|
|
struct common_type_recurse_if
|
|
: std::conditional<
|
|
has_type<Meta>::value,
|
|
common_type_recurse<Meta, Ts...>,
|
|
empty
|
|
>::type
|
|
{};
|
|
}
|
|
|
|
template<typename ...Ts>
|
|
struct common_type
|
|
{};
|
|
|
|
template<typename T>
|
|
struct common_type<T>
|
|
{
|
|
using type = std::decay_t<T>;
|
|
};
|
|
|
|
template<typename T, typename U>
|
|
struct common_type<T, U>
|
|
: detail::common_type2<T, U>
|
|
{};
|
|
|
|
template<typename T, typename U, typename... Vs>
|
|
struct common_type<T, U, Vs...>
|
|
: detail::common_type_recurse_if<common_type<T, U>, Vs...>
|
|
{};
|
|
</pre>
|
|
</blockquote>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2466"></a>2466. <tt>allocator_traits::max_size()</tt> default behavior is incorrect</h3>
|
|
<p><b>Section:</b> 17.6.3.5 [allocator.requirements], 20.7.8.2 [allocator.traits.members] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2015-01-17 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Table 28 — "Allocator requirements" says that default behavior for <tt>a.max_size()</tt> is
|
|
<tt>numeric_limits<size_type>::max()</tt>. And this is consistent with the matching statement
|
|
for <tt>allocator_traits</tt> in 20.7.8.2 [allocator.traits.members]/p7:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
static size_type max_size(const Alloc& a) noexcept;
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
<i>Returns</i>: <tt>a.max_size()</tt> if that expression is well-formed; otherwise,
|
|
<tt>numeric_limits<size_type>::max()</tt>.
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
<p>
|
|
However, when allocating memory, an allocator must allocate <tt>n*sizeof(value_type)</tt> bytes, for example:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
value_type*
|
|
allocate(std::size_t n)
|
|
{
|
|
return static_cast<value_type*>(::operator new (n * sizeof(value_type)));
|
|
}
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
When <tt>n == numeric_limits<size_type>::max(), n * sizeof(value_type)</tt> is <em>guaranteed</em>
|
|
to overflow except when <tt>sizeof(value_type) == 1</tt>.
|
|
<p/>
|
|
A more useful default would be <tt>numeric_limits<size_type>::max() / sizeof(value_type)</tt>.
|
|
</p>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
Marshall: Is this the right solution?<br/>
|
|
PJP: I think it's gilding the lily.<br/>
|
|
STL: I think this is right, and it doesn't interact with the incomplete container stuff because it's in a member function.<br/>
|
|
Marshall: Objections to this?<br/>
|
|
STL: Spaces around binary operators.<br/>
|
|
Hwrd: It's completely wrong without spaces.<br/>
|
|
Marshall: All in favor of Ready?<br/>
|
|
Lots.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N4296.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 17.6.3.5 [allocator.requirements], Table 28 — "Allocator requirements", as indicated:</p>
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 28 — Allocator requirements</caption>
|
|
<tr>
|
|
<th>Expression</th>
|
|
<th>Return type</th>
|
|
<th>Assertion/note<br/>pre-/post-condition</th>
|
|
<th>Default</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="4" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<tt>a.max_size()</tt>
|
|
</td>
|
|
<td>
|
|
<tt>X::size_type</tt>
|
|
</td>
|
|
<td>
|
|
the largest value that can<br/>
|
|
meaningfully be passed to<br/>
|
|
<tt>X::allocate()</tt>
|
|
</td>
|
|
<td>
|
|
<tt>numeric_limits<size_type>::max()<ins>/sizeof(value_type)</ins></tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="4" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote>
|
|
|
|
</li>
|
|
|
|
<li><p>Change 20.7.8.2 [allocator.traits.members]/p7 as indicated:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
static size_type max_size(const Alloc& a) noexcept;
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
<i>Returns</i>: <tt>a.max_size()</tt> if that expression is well-formed; otherwise,
|
|
<tt>numeric_limits<size_type>::max()<ins>/sizeof(value_type)</ins></tt>.
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2468"></a>2468. Self-move-assignment of library types</h3>
|
|
<p><b>Section:</b> 17.6.4.9 [res.on.arguments], 17.6.3.1 [utility.arg.requirements], 17.6.5.15 [lib.types.movedfrom], 23.2.1 [container.requirements.general] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Matt Austern <b>Opened:</b> 2015-01-22 <b>Last modified:</b> 2015-04-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#res.on.arguments">issues</a> in [res.on.arguments].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Suppose we write
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
vector<string> v{"a", "b", "c", "d"};
|
|
v = move(v);
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
What should be the state of <tt>v</tt> be? The standard doesn't say anything specific about self-move-assignment.
|
|
There's relevant text in several parts of the standard, and it's not clear how to reconcile them.
|
|
<p/>
|
|
17.6.4.9 [res.on.arguments] writes that, for all functions in the standard library, unless explicitly stated
|
|
otherwise, "If a function argument binds to an rvalue reference parameter, the implementation may assume that this
|
|
parameter is a unique reference to this argument." The <tt>MoveAssignable</tt> requirements table in
|
|
17.6.3.1 [utility.arg.requirements] writes that, given <tt>t = rv</tt>, <tt>t</tt>'s state is equivalent to
|
|
<tt>rv</tt>'s from before the assignment and <tt>rv</tt>'s state is unspecified (but valid). For containers
|
|
specifically, the requirements table in 23.2.1 [container.requirements.general] says that, given <tt>a = rv</tt>,
|
|
<tt>a</tt> becomes equal to what <tt>rv</tt> was before the assignment (and doesn't say anything about <tt>rv</tt>'s
|
|
state post-assignment).
|
|
<p/>
|
|
Taking each of these pieces in isolation, without reference to the other two:
|
|
</p>
|
|
<ul>
|
|
<li><p>17.6.4.9 [res.on.arguments] would clearly imply that the effect of <tt>v = move(v)</tt> is undefined.</p></li>
|
|
<li><p>17.6.3.1 [utility.arg.requirements] would clearly imply that <tt>v = move(v)</tt> has defined behavior.
|
|
It might be read to imply that this is a no-op, or might be read to imply that it leaves <tt>v</tt> in a valid but
|
|
unspecified state; I'm not sure which reading is more natural.</p></li>
|
|
<li><p>23.2.1 [container.requirements.general] would clearly imply that <tt>v = move(v)</tt> is a no-op.</p></li>
|
|
</ul>
|
|
<p>
|
|
It's not clear from the text how to put these pieces together, because it's not clear which one takes precedence.
|
|
Maybe 17.6.4.9 [res.on.arguments] wins (it imposes an implicit precondition that isn't mentioned in the
|
|
<tt>MoveAssignable</tt> requirements, so <tt>v = move(v)</tt> is undefined), or maybe
|
|
23.2.1 [container.requirements.general] wins (it explicitly gives additional guarantees for
|
|
<tt>Container::operator=</tt> beyond what's guaranteed for library functions in general, so <tt>v = move(v)</tt>
|
|
is a no-op), or maybe something else.
|
|
<p/>
|
|
On the existing implementations that I checked, for what it's worth, <tt>v = move(v)</tt> appeared to clear the vector;
|
|
it didn't leave the vector unchanged and it didn't cause a crash.
|
|
<p/>
|
|
<em>Proposed wording</em>:
|
|
<p/>
|
|
Informally: change the <tt>MoveAssignable</tt> and Container requirements tables (and any other requirements tables
|
|
that mention move assignment, if any) to make it explicit that <tt>x = move(x)</tt> is defined behavior and it leaves
|
|
<tt>x</tt> in a valid but unspecified state. That's probably not what the standard says today, but it's probably what
|
|
we intended and it's consistent with what we've told users and with what implementations actually do.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2469"></a>2469. Wrong specification of Requires clause of <tt>operator[]</tt> for <tt>map</tt> and <tt>unordered_map</tt></h3>
|
|
<p><b>Section:</b> 23.4.4.3 [map.access], 23.5.4.3 [unord.map.elem] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Tomasz Kamiński <b>Opened:</b> 2015-01-21 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#map.access">issues</a> in [map.access].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The "Requires:" clause for the <tt>operator[]</tt> for the <tt>unordered_map</tt> and <tt>map</tt>, are defining
|
|
separate requirements for insertability into container of <tt>mapped_type</tt> and <tt>key_type</tt>.
|
|
<p/>
|
|
23.4.4.3 [map.access] p2: // <tt>T& operator[](const key_type& x);</tt>
|
|
<p/>
|
|
<i>Requires</i>: <tt>key_type</tt> shall be <tt>CopyInsertable</tt> and <tt>mapped_type</tt> shall be <tt>DefaultInsertable</tt>
|
|
into <tt>*this</tt>.
|
|
<p/>
|
|
23.4.4.3 [map.access] p6: // <tt>T& operator[](key_type&& x)</tt>
|
|
<p/>
|
|
<i>Requires</i>: <tt>mapped_type</tt> shall be <tt>DefaultInsertable</tt> into <tt>*this</tt>.
|
|
<p/>
|
|
23.5.4.3 [unord.map.elem] p1: // <tt>mapped_type& operator[](const key_type& k);
|
|
mapped_type& operator[](key_type&& k);</tt>
|
|
<p/>
|
|
<i>Requires</i>: <tt>mapped_type</tt> shall be <tt>DefaultInsertable</tt> into <tt>*this</tt>. For the first operator,
|
|
<tt>key_type</tt> shall be <tt>CopyInsertable</tt> into <tt>*this</tt>. For the second operator, <tt>key_type</tt> shall
|
|
be <tt>MoveConstructible</tt>.
|
|
<p/>
|
|
Definition of the appropriate requirements: 23.2.1 [container.requirements.general] p15.
|
|
<p/>
|
|
<tt>T</tt> is <tt>DefaultInsertable</tt> into <tt>X</tt> means that the following expression is well-formed: //p15.1
|
|
<p/>
|
|
<tt>allocator_traits<A>::construct(m, p)</tt>
|
|
<p/>
|
|
<tt>T</tt> is <tt>MoveInsertable</tt> into <tt>X</tt> means that the following expression is well-formed: //p15.3
|
|
<p/>
|
|
<tt>allocator_traits<A>::construct(m, p, rv)</tt>
|
|
<p/>
|
|
<tt>T</tt> is <tt>CopyInsertable</tt> into <tt>X</tt> means that, in addition to <tt>T</tt> being <tt>MoveInsertable</tt>
|
|
into <tt>X</tt>, the following expression is well-formed: //p15.4
|
|
<p/>
|
|
<tt>allocator_traits<A>::construct(m, p, v)</tt>
|
|
<p/>
|
|
In the context of above definition the requirement "<tt>key_type</tt> shall be <tt>CopyInsertable</tt> into <tt>*this</tt>"
|
|
would mean that the key element of the <tt>pair<const key_type, mapped_type></tt> (<tt>value_type</tt> of the map)
|
|
should be constructed using separate call to the <tt>construct</tt> method, the same applies for the <tt>mapped_type</tt>.
|
|
Such behavior is explicitly prohibited by 23.2.1 [container.requirements.general] p3.
|
|
</p>
|
|
<blockquote><p>
|
|
For the components affected by this sub-clause that declare an allocator_type, objects stored in these
|
|
components shall be constructed using the <tt>allocator_traits<allocator_type>::construct</tt> function and
|
|
destroyed using the <tt>allocator_traits<allocator_type>::destroy</tt> function (20.7.8.2). These functions
|
|
are called only for the container's element type, not for internal types used by the container.
|
|
</p></blockquote>
|
|
<p>
|
|
It clearly states that <tt>element_type</tt> of the map, must be constructed using allocator for value type, which
|
|
disallows using of separate construction of first and second element, regardless of the fact if it can be actually
|
|
performed without causing undefined behavior.
|
|
<p/>
|
|
That means that the <tt>MoveInsertable</tt> and similar requirements may only be expressed in terms of <tt>value_type</tt>,
|
|
not its members types.
|
|
</p>
|
|
|
|
<p><i>[2015-02 Cologne]</i></p>
|
|
|
|
<p>
|
|
This issue is related to <a href="lwg-defects.html#2464">2464</a>.
|
|
<p/>
|
|
GR: Effects should say "returns ...". DK: Or just have a Returns clause? MC: A Returns clause is a directive to implementers.
|
|
<p/>
|
|
TK/DK: This PR fails to address the requirements about which it complained in the first place. DK: I can reword this. TK can help.
|
|
</p>
|
|
|
|
<p><i>[2015-03-29, Daniel provides improved wording]</i></p>
|
|
|
|
<p>
|
|
The revised wording fixes the proper usage of the magic "Equivalent to" wording, which automatically induces <i>Requires:</i>,
|
|
<i>Returns:</i>, and <i>Complexity:</i> elements (and possibly more). This allows us to strike all the remaining
|
|
elements, because they fall out from the semantics of the wording defined by <a href="lwg-defects.html#2464">2464</a>. In particular it is important
|
|
to realize that the wording form
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
<tt>value_type</tt> shall be <tt>EmplaceConstructible</tt> into <tt>map</tt> from <tt>piecewise_construct</tt>,
|
|
<tt>forward_as_tuple(k)</tt>, <tt>forward_as_tuple(forward<Args>(args)...)</tt>
|
|
</p>
|
|
</blockquote>
|
|
<p>
|
|
degenerates for the empty pack expansion <tt>args</tt> to:
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
<tt>value_type</tt> shall be <tt>EmplaceConstructible</tt> into <tt>map</tt> from <tt>piecewise_construct</tt>,
|
|
<tt>forward_as_tuple(k)</tt>, <tt>forward_as_tuple()</tt>
|
|
</p>
|
|
</blockquote>
|
|
<p>
|
|
which again means that such a <tt>pair</tt> construction (assuming <tt>std::allocator</tt>) would copy <tt>k</tt>
|
|
into member <tt>first</tt> and would value-initialize member <tt>second</tt>.
|
|
</p>
|
|
|
|
<p>
|
|
<strong>Previous resolution [SUPERSEDED]:</strong>
|
|
</p>
|
|
<blockquote class="note">
|
|
<p>This wording is relative to N4296.</p>
|
|
|
|
<p>Accept resolution of the issue issue <a href="lwg-defects.html#2464">2464</a> and define <tt>operator[]</tt> as follows
|
|
(This would also address issue <a href="lwg-defects.html#2274">2274</a>):</p>
|
|
|
|
<ol>
|
|
<li><p>Change 23.4.4.3 [map.access] as indicated:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
T& operator[](const key_type& x);
|
|
</pre>
|
|
<blockquote><p>
|
|
-1- <i>Effects</i>: <del>If there is no key equivalent to <tt>x</tt> in the map, inserts <tt>value_type(x, T())</tt>
|
|
into the map</del><ins>Equivalent to: <tt>try_emplace(x).first->second</tt></ins>.
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
</blockquote>
|
|
<pre>
|
|
T& operator[](key_type&& x);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-5- <i>Effects</i>: <del>If there is no key equivalent to <tt>x</tt> in the map, inserts <tt>value_type(std::move(x), T())</tt>
|
|
into the map</del><ins>Equivalent to: <tt>try_emplace(move(x)).first->second</tt></ins>.
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 23.5.4.3 [unord.map.elem] as indicated:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
mapped_type& operator[](const key_type& k);
|
|
mapped_type& operator[](key_type&& k);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
[…]
|
|
<p/>
|
|
-2- <i>Effects</i>: <del>If the <tt>unordered_map</tt> does not already contain an element whose key is equivalent to <tt>k</tt>,
|
|
the first operator inserts the value <tt>value_type(k, mapped_type())</tt> and the second operator inserts the
|
|
value <tt>value_type(std::move(k), mapped_type())</tt></del><ins>For the first operator, equivalent to:
|
|
<tt>try_emplace(k).first->second</tt>; for the second operator, equivalent to:
|
|
<tt>try_emplace(move(k)).first->second</tt></ins>.
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
</blockquote>
|
|
|
|
<p>
|
|
<strong>Previous resolution [SUPERSEDED]:</strong>
|
|
</p>
|
|
<blockquote class="note">
|
|
<p>This wording is relative to N4296.</p>
|
|
|
|
<p>Accept resolution of the issue issue <a href="lwg-defects.html#2464">2464</a> and define <tt>operator[]</tt> as follows
|
|
(This would also address issue <a href="lwg-defects.html#2274">2274</a>):</p>
|
|
|
|
<ol>
|
|
<li><p>Change 23.4.4.3 [map.access] as indicated:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
T& operator[](const key_type& x);
|
|
</pre>
|
|
<blockquote><p>
|
|
-1- <i>Effects</i>: <del>If there is no key equivalent to <tt>x</tt> in the map, inserts <tt>value_type(x, T())</tt>
|
|
into the map.</del><ins>Equivalent to: <tt>return try_emplace(x).first->second;</tt></ins>
|
|
<p/>
|
|
<del>-2- <i>Requires</i>: <tt>key_type</tt> shall be <tt>CopyInsertable</tt> and <tt>mapped_type</tt> shall be
|
|
<tt>DefaultInsertable</tt> into <tt>*this</tt>.</del>
|
|
<p/>
|
|
<del>-3- <i>Returns</i>: A reference to the <tt>mapped_type</tt> corresponding to <tt>x</tt> in <tt>*this</tt>.</del>
|
|
<p/>
|
|
<del>-4- <i>Complexity</i>: Logarithmic.</del>
|
|
</p>
|
|
</blockquote>
|
|
<pre>
|
|
T& operator[](key_type&& x);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-5- <i>Effects</i>: <del>If there is no key equivalent to <tt>x</tt> in the map, inserts <tt>value_type(std::move(x), T())</tt>
|
|
into the map.</del><ins>Equivalent to: <tt>return try_emplace(move(x)).first->second;</tt></ins>
|
|
<p/>
|
|
<del>-6- <i>Requires</i>: <tt>mapped_type</tt> shall be <tt>DefaultInsertable</tt> into <tt>*this</tt>.</del>
|
|
<p/>
|
|
<del>-7- <i>Returns</i>: A reference to the <tt>mapped_type</tt> corresponding to <tt>x</tt> in <tt>*this</tt>.</del>
|
|
<p/>
|
|
<del>-8- <i>Complexity</i>: Logarithmic.</del>
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 23.5.4.3 [unord.map.elem] as indicated:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
mapped_type& operator[](const key_type& k);
|
|
mapped_type& operator[](key_type&& k);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
<del>-1- <i>Requires</i>: <tt>mapped_type</tt> shall be <tt>DefaultInsertable</tt> into <tt>*this</tt>. For the first operator,
|
|
<tt>key_type</tt> shall be <tt>CopyInsertable</tt> into <tt>*this</tt>. For the second operator, <tt>key_type</tt> shall
|
|
be <tt>MoveConstructible</tt>.</del>
|
|
<p/>
|
|
-2- <i>Effects</i>: <del>If the <tt>unordered_map</tt> does not already contain an element whose key is equivalent to <tt>k</tt>,
|
|
the first operator inserts the value <tt>value_type(k, mapped_type())</tt> and the second operator inserts the
|
|
value <tt>value_type(std::move(k), mapped_type())</tt></del><ins>For the first operator, equivalent to:</ins>
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
<ins>return try_emplace(k).first->second;</ins>
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
<ins>for the second operator, equivalent to:</ins>
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
<ins>return try_emplace(move(k)).first->second;</ins>
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
<del>-3- <i>Returns</i>: A reference to <tt>x.second</tt>, where <tt>x</tt> is the (unique) element whose key is equivalent to
|
|
<tt>k</tt>.</del>
|
|
<p/>
|
|
<del>-4- <i>Complexity</i>: Average case 𝒪(<tt>1</tt>), worst case 𝒪(<tt>size()</tt>).</del>
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
</blockquote>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N4431.</p>
|
|
|
|
<p>Accept resolution of the issue issue <a href="lwg-defects.html#2464">2464</a> and define <tt>operator[]</tt> as follows
|
|
(This would also address issue <a href="lwg-defects.html#2274">2274</a>):</p>
|
|
|
|
<ol>
|
|
<li><p>Change 23.4.4.3 [map.access] as indicated:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
T& operator[](const key_type& x);
|
|
</pre>
|
|
<blockquote><p>
|
|
-1- <i>Effects</i>: <del>If there is no key equivalent to <tt>x</tt> in the map, inserts <tt>value_type(x, T())</tt>
|
|
into the map.</del><ins>Equivalent to: <tt>return try_emplace(x).first->second;</tt></ins>
|
|
<p/>
|
|
<del>-2- <i>Requires</i>: <tt>key_type</tt> shall be <tt>CopyInsertable</tt> and <tt>mapped_type</tt> shall be
|
|
<tt>DefaultInsertable</tt> into <tt>*this</tt>.</del>
|
|
<p/>
|
|
<del>-3- <i>Returns</i>: A reference to the <tt>mapped_type</tt> corresponding to <tt>x</tt> in <tt>*this</tt>.</del>
|
|
<p/>
|
|
<del>-4- <i>Complexity</i>: Logarithmic.</del>
|
|
</p>
|
|
</blockquote>
|
|
<pre>
|
|
T& operator[](key_type&& x);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-5- <i>Effects</i>: <del>If there is no key equivalent to <tt>x</tt> in the map, inserts <tt>value_type(std::move(x), T())</tt>
|
|
into the map.</del><ins>Equivalent to: <tt>return try_emplace(move(x)).first->second;</tt></ins>
|
|
<p/>
|
|
<del>-6- <i>Requires</i>: <tt>mapped_type</tt> shall be <tt>DefaultInsertable</tt> into <tt>*this</tt>.</del>
|
|
<p/>
|
|
<del>-7- <i>Returns</i>: A reference to the <tt>mapped_type</tt> corresponding to <tt>x</tt> in <tt>*this</tt>.</del>
|
|
<p/>
|
|
<del>-8- <i>Complexity</i>: Logarithmic.</del>
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 23.5.4.3 [unord.map.elem] as indicated:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
mapped_type& operator[](const key_type& k);
|
|
<del>mapped_type& operator[](key_type&& k);</del>
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
<del>-1- <i>Requires</i>: <tt>mapped_type</tt> shall be <tt>DefaultInsertable</tt> into <tt>*this</tt>. For the first operator,
|
|
<tt>key_type</tt> shall be <tt>CopyInsertable</tt> into <tt>*this</tt>. For the second operator, <tt>key_type</tt> shall
|
|
be <tt>MoveConstructible</tt>.</del>
|
|
<p/>
|
|
-2- <i>Effects</i>: <ins>Equivalent to <tt>return try_emplace(k).first->second;</tt></ins><del>If the <tt>unordered_map</tt>
|
|
does not already contain an element whose key is equivalent to <tt>k</tt>,
|
|
the first operator inserts the value <tt>value_type(k, mapped_type())</tt> and the second operator inserts the
|
|
value <tt>value_type(std::move(k), mapped_type())</tt></del>
|
|
</p>
|
|
<p>
|
|
<del>-3- <i>Returns</i>: A reference to <tt>x.second</tt>, where <tt>x</tt> is the (unique) element whose key is equivalent to
|
|
<tt>k</tt>.</del>
|
|
<p/>
|
|
<del>-4- <i>Complexity</i>: Average case 𝒪(<tt>1</tt>), worst case 𝒪(<tt>size()</tt>).</del>
|
|
</p>
|
|
</blockquote>
|
|
|
|
<pre>
|
|
<ins>mapped_type& operator[](key_type&& k);</ins>
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
<ins>-?- <i>Effects</i>: Equivalent to <tt>return try_emplace(move(k)).first->second;</tt></ins>
|
|
</p>
|
|
</blockquote>
|
|
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2471"></a>2471. <tt>copy_n</tt>'s number of <tt>InputIterator</tt> increments unspecified</h3>
|
|
<p><b>Section:</b> 25.3.1 [alg.copy] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2015-01-28 <b>Last modified:</b> 2015-05-04</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#alg.copy">active issues</a> in [alg.copy].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#alg.copy">issues</a> in [alg.copy].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
It's unspecified how many times <tt>copy_n</tt> increments the <tt>InputIterator</tt>.
|
|
<tt>uninitialized_copy_n</tt> is specified to increment it exactly <tt>n</tt> times,
|
|
which means if an <tt>istream_iterator</tt> is used then the next character
|
|
after those copied is read from the stream and then discarded, losing data.
|
|
<p/>
|
|
I believe all three of Dinkumware, libc++ and libstdc++ implement
|
|
<tt>copy_n</tt> with <tt>n - 1</tt> increments of the <tt>InputIterator</tt>, which avoids reading
|
|
and discarding a character when used with <tt>istream_iterator</tt>, but is
|
|
inconsistent with <tt>uninitialized_copy_n</tt> and causes surprising behaviour
|
|
with <tt>istreambuf_iterator</tt> instead, because <tt>copy_n(in, 2, copy_n(in, 2,
|
|
out))</tt> is not equivalent to <tt>copy_n(in, 4, out)</tt>
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2472"></a>2472. Heterogeneous comparisons in the standard library can result in ambiguities</h3>
|
|
<p><b>Section:</b> 20.4.2.7 [tuple.rel], 20.7.9.2 [allocator.globals], 20.8.1.5 [unique.ptr.special], 20.8.2.2.7 [util.smartptr.shared.cmp], 20.12.5.6 [time.duration.comparisons], 20.12.6.6 [time.point.comparisons], 20.13.5 [scoped.adaptor.operators], 24.5.1.3.13 [reverse.iter.op==], 24.5.3.3.13 [move.iter.op.comp] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Richard Smith <b>Opened:</b> 2015-02-07 <b>Last modified:</b> 2015-05-04</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#tuple.rel">active issues</a> in [tuple.rel].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#tuple.rel">issues</a> in [tuple.rel].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The standard library specifies a lot of heterogeneous comparison operators. For instance:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
template<class... TTypes, class... UTypes>
|
|
constexpr bool operator!=(const tuple<TTypes...>&, const tuple<UTypes...>&);
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
This has an unfortunate consequence:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
#include <tuple>
|
|
#include <utility>
|
|
|
|
using namespace std::rel_ops;
|
|
std::tuple<int> a(0);
|
|
bool b = a != a;
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
The last line here is ill-formed due to ambiguity: it might be <tt>rel_ops::operator!=</tt>, and it might be the
|
|
heterogeneous tuple <tt>operator!=</tt>. These are not partially ordered, because they have different constraints:
|
|
<tt>rel_ops</tt> requires the types to match, whereas the tuple comparison requires both types to be tuples (but not
|
|
to match). The same thing happens for user code that defines its own unconstrained
|
|
'<tt>template<typename T> operator!=(const T&, const T&)</tt>' rather than using <tt>rel_ops</tt>.
|
|
<p/>
|
|
One straightforward fix would be to add a homogeneous overload for each heterogeneous comparison:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
template<class... TTypes>
|
|
constexpr bool operator!=(const tuple<TTypes...>&, const tuple<TTypes...>&);
|
|
</pre>
|
|
<p>
|
|
This is then unambiguously chosen over the other options in the preceding case. FWIW, libstdc++ already does this
|
|
<a href="https://gcc.gnu.org/onlinedocs/gcc-4.6.4/libstdc++/api/a01065_source.html#l00788">in some cases</a>.
|
|
</p>
|
|
</blockquote>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2473"></a>2473. <tt>basic_filebuf</tt>'s relation to C <tt>FILE</tt> semantics</h3>
|
|
<p><b>Section:</b> 27.9.1.5 [filebuf.virtuals] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Aaron Ballman <b>Opened:</b> 2015-02-09 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#filebuf.virtuals">issues</a> in [filebuf.virtuals].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The restrictions on reading and writing a sequence controlled by an object of class
|
|
<tt>basic_filebuf<charT, traits></tt> are the same as for reading and writing with
|
|
the Standard C library <tt>FILE</tt>s. One of the restrictions placed by C is on the behavior of
|
|
a stream that is opened for input and output. See the C99 standard, 7.19.5.3p6 for more
|
|
details, but the gist is that when opened in update mode, reads and writes must have an
|
|
intervening file positioning or flushing call to not trigger UB.
|
|
</p>
|
|
|
|
<p>
|
|
27.9.1.5 [filebuf.virtuals] p13 specifies that <tt>basic_filebuf::seekoff()</tt> calls
|
|
<tt>std::fseek()</tt>. However, there is no mention of <tt>std::fseek()</tt> in
|
|
<tt>basic_filebuf::seekpos()</tt>, and no mention of <tt>std::fflush()</tt> in
|
|
<tt>basic_filebuf::sync()</tt>, which seem like an oversight.
|
|
</p>
|
|
|
|
<p>
|
|
<strong>Previous resolution [SUPERSEDED]:</strong>
|
|
</p>
|
|
<blockquote class="note">
|
|
<p>This wording is relative to N4296.</p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>Change 27.9.1.5 [filebuf.virtuals] p16 as follows [Editorial note: A footnote referring to <tt>fseek</tt> is not needed,
|
|
because this is already covered by the existing footnote 334]:</p>
|
|
<blockquote>
|
|
<p>
|
|
-16- Alters the file position, if possible, to correspond to the position stored in <tt>sp</tt> (as described below).
|
|
Altering the file position performs as follows:
|
|
</p>
|
|
<ol>
|
|
<li><p>if <tt>(om & ios_base::out) != 0</tt>, then update the output sequence and write any unshift sequence;</p></li>
|
|
<li><p>set the file position to <tt>sp</tt> <ins>as if by calling <tt>std::fseek(file, sp, SEEK_SET)</tt></ins>;</p></li>
|
|
<li><p>if <tt>(om & ios_base::in) != 0</tt>, then update the input sequence;</p></li>
|
|
</ol>
|
|
<p>
|
|
where <tt>om</tt> is the open mode passed to the last call to <tt>open()</tt>. The operation fails if
|
|
<tt>is_open()</tt> returns false.
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Change 27.9.1.5 [filebuf.virtuals] p19 as follows and add a new footnote that mimics comparable footnotes in
|
|
27.9.1.4 [filebuf.members] and 27.9.1.5 [filebuf.virtuals]:</p>
|
|
<blockquote>
|
|
<p>
|
|
-19- <i>Effects</i>: If a put area exists, calls <tt>filebuf::overflow</tt> to write the characters to the file<ins>, then
|
|
flushes the file as if by calling <tt>std::fflush(file)</tt> [Footnote: The function signature <tt>fflush(FILE*)</tt>
|
|
is declared in <tt><cstdio></tt> (27.9.2).]</ins>. If a get area exists, the effect is implementation-defined.
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
</blockquote>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
Aaron provides improved wording by removing the params from <tt>std::fseek()</tt> due to the concerns
|
|
regarding the parameters on systems where <tt>fseek</tt> uses 32-bit parameters.
|
|
<p/>
|
|
Second wording improvement, replacing the new one see below. It
|
|
</p>
|
|
<ol>
|
|
<li><p>drops the <tt>std::</tt></p></li>
|
|
<li><p>drops the footnote for <tt>fflush</tt></p></li>
|
|
<li><p>replaces <tt>fseek</tt> with <tt>fsetpos</tt></p></li>
|
|
</ol>
|
|
|
|
<p>
|
|
<strong>Previous resolution [SUPERSEDED]:</strong>
|
|
</p>
|
|
<blockquote class="note">
|
|
<p>This wording is relative to N4431.</p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>Change 27.9.1.5 [filebuf.virtuals] p16 as follows [Editorial note: A footnote referring to <tt>fseek</tt> is not needed,
|
|
because this is already covered by the existing footnote 334]:</p>
|
|
<blockquote>
|
|
<p>
|
|
-16- Alters the file position, if possible, to correspond to the position stored in <tt>sp</tt> (as described below).
|
|
Altering the file position performs as follows:
|
|
</p>
|
|
<ol>
|
|
<li><p>if <tt>(om & ios_base::out) != 0</tt>, then update the output sequence and write any unshift sequence;</p></li>
|
|
<li><p>set the file position to <tt>sp</tt> <ins>as if by a call to <tt>std::fseek</tt></ins>;</p></li>
|
|
<li><p>if <tt>(om & ios_base::in) != 0</tt>, then update the input sequence;</p></li>
|
|
</ol>
|
|
<p>
|
|
where <tt>om</tt> is the open mode passed to the last call to <tt>open()</tt>. The operation fails if
|
|
<tt>is_open()</tt> returns false.
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Change 27.9.1.5 [filebuf.virtuals] p19 as follows and add a new footnote that mimics comparable footnotes in
|
|
27.9.1.4 [filebuf.members] and 27.9.1.5 [filebuf.virtuals]:</p>
|
|
<blockquote>
|
|
<p>
|
|
-19- <i>Effects</i>: If a put area exists, calls <tt>filebuf::overflow</tt> to write the characters to the file<ins>, then
|
|
flushes the file as if by calling <tt>std::fflush(file)</tt> [Footnote: The function signature <tt>fflush(FILE*)</tt>
|
|
is declared in <tt><cstdio></tt> (27.9.2).]</ins>. If a get area exists, the effect is implementation-defined.
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
</blockquote>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N4431.</p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>Change 27.9.1.5 [filebuf.virtuals] p16 as follows [Editorial note: A footnote referring to <tt>fseek</tt> is not needed,
|
|
because this is already covered by the existing footnote 334]:</p>
|
|
<blockquote>
|
|
<p>
|
|
-16- Alters the file position, if possible, to correspond to the position stored in <tt>sp</tt> (as described below).
|
|
Altering the file position performs as follows:
|
|
</p>
|
|
<ol>
|
|
<li><p>if <tt>(om & ios_base::out) != 0</tt>, then update the output sequence and write any unshift sequence;</p></li>
|
|
<li><p>set the file position to <tt>sp</tt> <ins>as if by a call to <tt>fsetpos</tt></ins>;</p></li>
|
|
<li><p>if <tt>(om & ios_base::in) != 0</tt>, then update the input sequence;</p></li>
|
|
</ol>
|
|
<p>
|
|
where <tt>om</tt> is the open mode passed to the last call to <tt>open()</tt>. The operation fails if
|
|
<tt>is_open()</tt> returns false.
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Change 27.9.1.5 [filebuf.virtuals] p19 as follows and add a new footnote that mimics comparable footnotes in
|
|
27.9.1.4 [filebuf.members] and 27.9.1.5 [filebuf.virtuals]:</p>
|
|
<blockquote>
|
|
<p>
|
|
-19- <i>Effects</i>: If a put area exists, calls <tt>filebuf::overflow</tt> to write the characters to the file<ins>, then
|
|
flushes the file as if by calling <tt>fflush(file)</tt></ins>. If a get area exists, the effect is implementation-defined.
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2474"></a>2474. <tt><cmath></tt> functions unfriendly to <tt>integral_constant</tt> arguments</h3>
|
|
<p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Matheus Izvekov <b>Opened:</b> 2015-02-13 <b>Last modified:</b> 2015-05-04</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#c.math">issues</a> in [c.math].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Using numeric wrappers with <tt><cmath></tt> functions is currently troublesome.
|
|
Code such as: "<tt>std::exp2(std::integral_constant<int, 5>{})</tt>" will fail to
|
|
compile because of ambiguity.
|
|
<p/>
|
|
Arguments which are implicitly convertible to an arithmetic type should be accepted whenever
|
|
the latter would be accepted.
|
|
<p/>
|
|
David Krauss pointed out that some issue may present itself with numeric libraries which provide <tt><cmath></tt>
|
|
equivalents in their own namespace which are not more specialized than the ones provided in <tt><cmath></tt>.
|
|
If the changes proposed are implemented, then cases where the user brings those into scope through ADL might become ambiguous.
|
|
<p/>
|
|
It's hard to assess how much breakage this would cause in the wild, and how much work it would take to fix.
|
|
Should this be determined to be a problem, it's possible to make the new behaviour optional, and disabled by
|
|
default for all user-defined types.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N4296.</p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>Change 26.8 [c.math] p11 b2 as indicated:</p>
|
|
<blockquote>
|
|
<p>
|
|
-11- Moreover, there shall be additional overloads sufficient to ensure:
|
|
</p>
|
|
<ol>
|
|
<li><p>[…]</p></li>
|
|
<li><p>Otherwise, if any arithmetic argument corresponding to a <tt>double</tt> parameter has type <tt>double</tt> or
|
|
<del>an integer type</del><ins>a type which is not floating-point, but which is implicitly convertible to <tt>double</tt></ins>,
|
|
then all arithmetic arguments corresponding to <tt>double</tt> parameters are effectively cast to <tt>double</tt>.</p></li>
|
|
<li><p>[…]</p></li>
|
|
</ol>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2475"></a>2475. Allow overwriting of <tt>std::basic_string</tt> terminator with <tt>charT()</tt> to allow
|
|
cleaner interoperation with legacy APIs</h3>
|
|
<p><b>Section:</b> 21.4.5 [string.access] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Matt Weber <b>Opened:</b> 2015-02-21 <b>Last modified:</b> 2015-05-04</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#string.access">issues</a> in [string.access].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
It is often desirable to use a <tt>std::basic_string</tt> object as a buffer when interoperating with libraries
|
|
that mutate null-terminated arrays of characters. In many cases, these legacy APIs write a null terminator at
|
|
the specified end of the provided buffer. Providing such a function with an appropriately-sized
|
|
<tt>std::basic_string</tt> results in undefined behavior when the <tt>charT</tt> object at the <tt>size()</tt>
|
|
position is overwritten, even if the value remains unchanged.
|
|
<p/>
|
|
Absent the ability to allow for this, applications are forced into pessimizations such as: providing
|
|
appropriately-sized <tt>std::vectors</tt> of <tt>charT</tt> for interoperating with the legacy API, and then
|
|
copying the <tt>std::vector</tt> to a <tt>std::basic_string</tt>; providing an oversized <tt>std::basic_string</tt>
|
|
object and then calling <tt>resize()</tt> later.
|
|
<p/>
|
|
A trivial example:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
#include <string>
|
|
#include <vector>
|
|
|
|
void legacy_function(char *out, size_t count) {
|
|
for (size_t i = 0; i < count; ++i) {
|
|
*out++ = '0' + (i % 10);
|
|
}
|
|
*out = '\0'; // <span style="color:#C80000;font-weight:bold">if size() == count, this results in undefined behavior</span>
|
|
}
|
|
|
|
int main() {
|
|
std::string s(10, '\0');
|
|
legacy_function(&s[0], s.size()); // <span style="color:#C80000;font-weight:bold">undefined behavior</span>
|
|
|
|
std::vector<char> buffer(11);
|
|
legacy_function(&buffer[0], buffer.size() - 1);
|
|
std::string t(&buffer[0], buffer.size() - 1); // potentially expensive copy
|
|
|
|
std::string u(11, '\0');
|
|
legacy_function(&u[0], u.size() - 1);
|
|
u.resize(u.size() - 1); // needlessly complicates the program's logic
|
|
}
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
A slight relaxation of the requirement on the returned object from the element access operator would
|
|
allow for this interaction with no semantic change to existing programs.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N4296.</p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>Edit 21.4.5 [string.access] as indicated:</p>
|
|
<blockquote>
|
|
<pre>
|
|
const_reference operator[](size_type pos) const;
|
|
reference operator[](size_type pos);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-1- <i>Requires</i>: […]
|
|
<p/>
|
|
-2- <i>Returns</i>: <tt>*(begin() + pos) if pos < size()</tt>. Otherwise, returns a reference to an object of type
|
|
<tt>charT</tt> with value <tt>charT()</tt>, where modifying the object <ins>to any value other than <tt>charT()</tt></ins>
|
|
leads to undefined behavior.
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2476"></a>2476. <tt>scoped_allocator_adaptor</tt> is not assignable</h3>
|
|
<p><b>Section:</b> 20.13.1 [allocator.adaptor.syn] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2015-03-02 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The class definition in 20.13.1 [allocator.adaptor.syn] declares a move
|
|
constructor, which means that the copy assignment operator is defined
|
|
as deleted, and no move assignment operator is declared.
|
|
<p/>
|
|
This means a <tt>scoped_allocator_adaptor</tt> is not assignable, and a
|
|
container using <tt>scoped_allocator_adaptor<A...></tt> may not be
|
|
<tt>CopyAssignable</tt> or <tt>MoveAssignable</tt> (depending on the
|
|
<tt>propagate_on_container_xxxx_assignment</tt> traits of the outer and inner
|
|
allocator types).
|
|
</p>
|
|
|
|
<p><i>[2015-04-03 Howard comments]</i></p>
|
|
|
|
<p>
|
|
If the contained allocators are not assignable, I think we need the ability of <tt>= default</tt> to automagically become
|
|
<tt>= delete</tt>. My concern is that <tt>is_copy_assignable<scoped_allocator_adaptor<CustomAllocator>>::value</tt>
|
|
get the right answer for both cases:
|
|
</p>
|
|
<ol>
|
|
<li><p><tt>is_copy_assignable<CustomAllocator>::value</tt> is <tt>true</tt>.</p></li>
|
|
<li><p><tt>is_copy_assignable<CustomAllocator>::value</tt> is <tt>false</tt>.</p></li>
|
|
</ol>
|
|
<p>
|
|
If we allow the vendor to declare and provide the copy assignment operator, the chance of getting #2 correct goes to zero.
|
|
</p>
|
|
|
|
<p>
|
|
<strong>Previous resolution [SUPERSEDED]:</strong>
|
|
</p>
|
|
<blockquote class="note">
|
|
<p>This wording is relative to N4296.</p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>Add to the synopsis in 20.13.1 [allocator.adaptor.syn]/1 [<i>Editorial remark</i>: The proposed wording
|
|
does not explicitly specify the semantics of the added copy/move assignment operators, based on
|
|
17.5.2.2 [functions.within.classes] p1, which says:
|
|
<p/>
|
|
"For the sake of exposition, Clauses 18 through 30 and Annex D do not describe copy/move constructors,
|
|
assignment operators, or (non-virtual) destructors with the same apparent semantics as those that can be
|
|
generated by default (12.1, 12.4, 12.8)."
|
|
<p/>
|
|
— <i>end remark</i>]:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
[…]
|
|
template <class OuterA2>
|
|
scoped_allocator_adaptor(
|
|
scoped_allocator_adaptor<OuterA2, InnerAllocs...>&& other) noexcept;
|
|
<ins>
|
|
scoped_allocator_adaptor& operator=(const scoped_allocator_adaptor&);
|
|
scoped_allocator_adaptor& operator=(scoped_allocator_adaptor&&);
|
|
</ins>
|
|
~scoped_allocator_adaptor();
|
|
[…]
|
|
</pre>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
</blockquote>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
Move to Immediate.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N4296.</p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>Add to the synopsis in 20.13.1 [allocator.adaptor.syn]/1:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
[…]
|
|
template <class OuterA2>
|
|
scoped_allocator_adaptor(
|
|
scoped_allocator_adaptor<OuterA2, InnerAllocs...>&& other) noexcept;
|
|
<ins>
|
|
scoped_allocator_adaptor& operator=(const scoped_allocator_adaptor&) = default;
|
|
scoped_allocator_adaptor& operator=(scoped_allocator_adaptor&&) = default;
|
|
</ins>
|
|
~scoped_allocator_adaptor();
|
|
[…]
|
|
</pre>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2477"></a>2477. Inconsistency of wordings in <tt>std::vector::erase()</tt> and <tt>std::deque::erase()</tt></h3>
|
|
<p><b>Section:</b> 23.3.3.4 [deque.modifiers], 23.3.6.5 [vector.modifiers] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Anton Savin <b>Opened:</b> 2015-03-03 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#deque.modifiers">issues</a> in [deque.modifiers].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
In the latest draft N4296, and in all drafts up to at least N3337:
|
|
<p/>
|
|
23.3.3.4 [deque.modifiers]/5 (regarding <tt>deque::erase()</tt>):
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
<i>Complexity</i>: The number of calls to the destructor is the same as the number of elements erased, but
|
|
the number of calls to the <span style="color:#C80000;font-weight:bold">assignment operator</span> is no more
|
|
than the lesser of the number of elements before the erased elements and the number of elements after the erased elements.
|
|
</p>
|
|
</blockquote>
|
|
<p>
|
|
23.3.6.5 [vector.modifiers]/4 (regarding <tt>vector::erase()</tt>):
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
<i>Complexity</i>: The destructor of <tt>T</tt> is called the number of times equal to the number of the elements
|
|
erased, but the <span style="color:#C80000;font-weight:bold">move assignment operator</span> of <tt>T</tt> is called
|
|
the number of times equal to the number of elements in the vector after the erased elements.
|
|
</p>
|
|
</blockquote>
|
|
<p>
|
|
Is there any reason for explicit mentioning of move assignment for <tt>std::vector::erase()</tt>?
|
|
Shouldn't these two wordings be the same with this regard?
|
|
<p/>
|
|
Also, for <tt>std::deque</tt>, it's not clear from the text which destructors and assignment operators are called.
|
|
</p>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
Move to Immediate.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N4296.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 23.3.3.4 [deque.modifiers]/5 to:</p>
|
|
|
|
<p>
|
|
-5- <i>Complexity</i>: The number of calls to the destructor <ins>of <tt>T</tt></ins> is the same as the number of
|
|
elements erased, but the number of calls to the assignment operator <ins>of <tt>T</tt></ins> is no more than the
|
|
lesser of the number of elements before the erased elements and the number of elements after the erased elements.
|
|
</p>
|
|
</li>
|
|
|
|
<li><p>Change 23.3.6.5 [vector.modifiers]/4 to:</p>
|
|
|
|
<p>
|
|
-4- <i>Complexity</i>: The destructor of <tt>T</tt> is called the number of times equal to the number of the elements
|
|
erased, but the <del>move</del> assignment operator of <tt>T</tt> is called the number of times equal to the number of
|
|
elements in the vector after the erased elements.
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2478"></a>2478. Unclear how <tt>wstring_convert</tt> uses <tt>cvtstate</tt></h3>
|
|
<p><b>Section:</b> 22.3.3.2.2 [conversions.string] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2015-03-04 <b>Last modified:</b> 2015-05-04</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#conversions.string">active issues</a> in [conversions.string].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#conversions.string">issues</a> in [conversions.string].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
How do <tt>wstring_convert::from_bytes</tt> and <tt>wstring_convert::to_bytes</tt> use
|
|
the <tt>cvtstate</tt> member?
|
|
<p/>
|
|
Is it passed to the <tt>codecvt</tt> member functions? Is a copy of it passed
|
|
to the member functions? "Otherwise it shall be left unchanged"
|
|
implies a copy is used, but if that's really what's intended there are
|
|
simpler ways to say so.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2479"></a>2479. Unclear how <tt>wbuffer_convert</tt> uses <tt>cvtstate</tt></h3>
|
|
<p><b>Section:</b> 22.3.3.2.3 [conversions.buffer] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2015-03-04 <b>Last modified:</b> 2015-05-04</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#conversions.buffer">active issues</a> in [conversions.buffer].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#conversions.buffer">issues</a> in [conversions.buffer].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
How does <tt>wbuffer_convert</tt> use the <tt>cvtstate</tt> member?
|
|
<p/>
|
|
Is the same conversion state object used for converting both the get
|
|
and put areas? That means a read which runs out of bytes halfway
|
|
through a multibyte character will leave some shift state in cvtstate,
|
|
which would then be used by a following write, even though the shift
|
|
state of the get area is unrelated to the put area.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2480"></a>2480. Error handling of <tt>wbuffer_convert</tt> unclear</h3>
|
|
<p><b>Section:</b> 22.3.3.2.3 [conversions.buffer] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2015-03-04 <b>Last modified:</b> 2015-05-04</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#conversions.buffer">active issues</a> in [conversions.buffer].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#conversions.buffer">issues</a> in [conversions.buffer].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
If a <tt>codecvt</tt> conversion returns <tt>codecvt_base::error</tt> should that be
|
|
treated as <tt>EOF</tt>? An exception? Should all the successfully converted
|
|
characters before a conversion error be available to the users of the
|
|
<tt>wbuffer_convert</tt> and/or the internal <tt>streambuf</tt>, or does a conversion
|
|
error lose information?
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2481"></a>2481. <tt>wstring_convert</tt> should be more precise regarding "byte-error string" etc.</h3>
|
|
<p><b>Section:</b> 22.3.3.2.2 [conversions.string] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2015-03-04 <b>Last modified:</b> 2015-05-04</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#conversions.string">active issues</a> in [conversions.string].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#conversions.string">issues</a> in [conversions.string].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Paragraph 4 of 22.3.3.2.2 [conversions.string] introduces <tt>byte_err_string</tt>
|
|
as "a byte string to display on errors". What does display mean? The string is returned
|
|
on error, it's not displayed anywhere.
|
|
<p/>
|
|
Paragraph 14 says "Otherwise, if the object was constructed with a
|
|
byte-error string, the member function shall return the byte-error
|
|
string." The term byte-error string is not used anywhere else.
|
|
<p/>
|
|
Paragraph 17 talks about storing "default values in <tt>byte_err_string</tt>".
|
|
What default value? Is "Hello, world!" allowed? If it means
|
|
default-construction it should say so. If paragraph 14 says it won't
|
|
be used what does it matter how it's initialized? The end of the
|
|
paragraph refers to storing "<tt>byte_err</tt> in <tt>byte_err_string</tt>". This should
|
|
be more clearly related to the wording in paragraph 14.
|
|
<p/>
|
|
It might help if the constructor (and destructor) was specified before
|
|
the other member functions, so it can more formally define the
|
|
difference between being "constructed with a byte-error string" and
|
|
not.
|
|
<p/>
|
|
All the same issues apply to the <tt>wide_err_string</tt> member.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2483"></a>2483. <tt>throw_with_nested()</tt> should use <tt>is_final</tt></h3>
|
|
<p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2015-03-27 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#except.nested">issues</a> in [except.nested].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
When <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2559.htm">N2559</a> was voted into the Working Paper,
|
|
it said "This function template must take special case to handle non-class types, unions and <tt>[[final]]</tt> classes that cannot
|
|
be derived from, and [...]". However, its Standardese didn't handle <tt>final</tt> classes, and this was never revisited. Now that
|
|
we have <tt>is_final</tt>, we can achieve this proposal's original intention.
|
|
<p/>
|
|
Additionally, we need to handle the case where <tt>U</tt> is <tt>nested_exception</tt> itself. <tt>is_base_of</tt>'s wording
|
|
handles this and ignores <i>cv</i>-qualifiers. (Note that <tt>is_class</tt> detects "non-union class type".)
|
|
</p>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
STL, MC and JW already do this<br/>
|
|
MC: move to Ready, bring to motion on Friday<br/>
|
|
7 in favor, none opposed
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N4296.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 18.8.6 [except.nested] as depicted:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
template <class T> [[noreturn]] void throw_with_nested(T&& t);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-6- Let <tt>U</tt> be <tt>remove_reference_t<T></tt>.
|
|
<p/>
|
|
-7- Requires: <tt>U</tt> shall be <tt>CopyConstructible</tt>.
|
|
<p/>
|
|
-8- Throws: if <del><tt>U</tt> is a non-union class type not derived from
|
|
<tt>nested_exception</tt></del><ins><tt>is_class<U>::value && !is_final<U>::value &&
|
|
!is_base_of<nested_exception, U>::value</tt> is <tt>true</tt></ins>, an exception of unspecified type that
|
|
is publicly derived from both <tt>U</tt> and <tt>nested_exception</tt> and constructed from
|
|
<tt>std::forward<T>(t)</tt>, otherwise <tt>std::forward<T>(t)</tt>.
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2484"></a>2484. <tt>rethrow_if_nested()</tt> is doubly unimplementable</h3>
|
|
<p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2015-03-27 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#except.nested">issues</a> in [except.nested].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
<tt>rethrow_if_nested()</tt> wants to determine "If the dynamic type of <tt>e</tt> is publicly and unambiguously derived
|
|
from <tt>nested_exception</tt>", but 5.2.7 [expr.dynamic.cast] specifies that <tt>dynamic_cast</tt> has a couple
|
|
of limitations.
|
|
<p/>
|
|
First, nonpolymorphic inputs. These could be non-classes, or nonpolymorphic classes. The Standardese handles non-classes,
|
|
although implementers need special logic. (If <tt>E</tt> is <tt>int</tt>, the dynamic type can't possibly derive from
|
|
<tt>nested_exception</tt>. Implementers need to detect this and avoid <tt>dynamic_cast</tt>, which would be ill-formed
|
|
due to 5.2.7 [expr.dynamic.cast]/2.) The Standardese is defective when <tt>E</tt> is a nonpolymorphic class.
|
|
Consider the following example:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
struct Nonpolymorphic { };
|
|
struct MostDerived : Nonpolymorphic, nested_exception { };
|
|
MostDerived md;
|
|
const Nonpolymorphic& np = md;
|
|
rethrow_if_nested(np);
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
According to 1.3 [defns.dynamic.type], the dynamic type of <tt>np</tt> is <tt>MostDerived</tt>. However, it's
|
|
physically impossible to discover this, and attempting to do so will lead to an ill-formed <tt>dynamic_cast</tt>
|
|
(5.2.7 [expr.dynamic.cast]/6). The Standardese must be changed to say that if <tt>E</tt> is nonpolymorphic, nothing happens.
|
|
<p/>
|
|
Second, statically good but dynamically bad inputs. Consider the following example:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
struct Nested1 : nested_exception { };
|
|
struct Nested2 : nested_exception { };
|
|
struct Ambiguous : Nested1, Nested2 { };
|
|
Ambiguous amb;
|
|
const Nested1& n1 = amb;
|
|
rethrow_if_nested(n1);
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
Here, the static type <tt>Nested1</tt> is good (i.e. publicly and unambiguously derived from <tt>nested_exception</tt>), but
|
|
the dynamic type <tt>Ambiguous</tt> is bad. The Standardese currently says that we have to detect the dynamic badness, but
|
|
<tt>dynamic_cast</tt> won't let us. 5.2.7 [expr.dynamic.cast]/3 and /5 are special cases (identity-casting and upcasting,
|
|
respectively) that activate before the "run-time check" behavior that we want (/6 and below). Statically good inputs succeed
|
|
(regardless of the dynamic type) and statically bad inputs are ill-formed (implementers must use type traits to avoid this).
|
|
<p/>
|
|
It might be possible to implement this with clever trickery involving virtual base classes, but implementers shouldn't be asked
|
|
to do that. It would definitely be possible to implement this with a compiler hook (a special version of <tt>dynamic_cast</tt>),
|
|
but implementers shouldn't be asked to do so much work for such an unimportant case. (This case is pathological because the
|
|
usual way of adding <tt>nested_exception</tt> inheritance is <tt>throw_with_nested()</tt>, which avoids creating bad inheritance.)
|
|
The Standardese should be changed to say that statically good inputs are considered good.
|
|
<p/>
|
|
Finally, we want <tt>is_base_of</tt>'s "base class or same class" semantics. If the static type is <tt>nested_exception</tt>,
|
|
we have to consider it good due to <tt>dynamic_cast</tt>'s identity-casting behavior. And if the dynamic type is
|
|
<tt>nested_exception</tt>, it is definitely good.
|
|
</p>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
WB: so the <tt>is_polymorphic</tt> trait must be used?<br/>
|
|
STL and JW: yes, that must be used to decide whether to try using <tt>dynamic_cast</tt> or not.<br/>
|
|
JW: I'd already made this fix in our implementation<br/>
|
|
STL: the harder case also involves <tt>dynamic_cast</tt>. should not try using <tt>dynamic_cast</tt> if we can
|
|
statically detect it is OK, doing the <tt>dynamic_cast</tt> might fail.<br/>
|
|
STL: finally, want "is the same or derived from" behaviour of <tt>is_base_of</tt><br/>
|
|
WB: should there be an "else no effect" at the end? We have "Otherwise, if ..." and nothing saying what if the condition is false.<br/>
|
|
TP I agree.<br/>
|
|
MC: move to Ready and bring to motion on Friday<br/>
|
|
7 in favor, none opposed
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N4296.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 18.8.6 [except.nested] as depicted:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
template <class E> void rethrow_if_nested(const E& e);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-9- <i>Effects</i>: If <ins><tt>E</tt> is not a polymorphic class type, there is no effect. Otherwise, if the static
|
|
type or</ins> the dynamic type of <tt>e</tt> <ins>is <tt>nested_exception</tt> or</ins> is publicly and unambiguously
|
|
derived from <tt>nested_exception</tt>, calls <tt>dynamic_cast<const nested_exception&>(e).rethrow_nested()</tt>.
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2485"></a>2485. <tt>get()</tt> should be overloaded for <tt>const tuple&&</tt></h3>
|
|
<p><b>Section:</b> 20.4.2.6 [tuple.elem] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2015-03-27 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#tuple.elem">issues</a> in [tuple.elem].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
<tt>const</tt> rvalues are weird, but they're part of the type system. Consider the following code:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
#include <functional>
|
|
#include <string>
|
|
#include <tuple>
|
|
|
|
using namespace std;
|
|
|
|
string str1() { return "one"; }
|
|
const string str2() { return "two"; }
|
|
tuple<string> tup3() { return make_tuple("three"); }
|
|
const tuple<string> tup4() { return make_tuple("four"); }
|
|
|
|
int main() {
|
|
// cref(str1()); // BAD, properly rejected
|
|
// cref(str2()); // BAD, properly rejected
|
|
// cref(get<0>(tup3())); // BAD, properly rejected
|
|
cref(get<0>(tup4())); // BAD, but improperly accepted!
|
|
}
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
As <tt>tuple</tt> is a fundamental building block (and the only convenient way to have variadic data members), it should
|
|
not open a hole in the type system. <tt>get()</tt> should imitate 5.2.5 [expr.ref]'s rules for accessing data members.
|
|
(This is especially true for <tt>pair</tt>, where both <tt>get<0>()</tt> and <tt>.first</tt> are available.)
|
|
<p/>
|
|
While we're in the neighborhood, we can dramatically simplify the wording here. All we need to do is follow
|
|
20.4.2.6 [tuple.elem]/9's example of saying "Returns: A reference to STUFF", and allow implementers to figure out how
|
|
to achieve that with the given return types.
|
|
</p>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
TP: for the existing overloads there's no change to the code, just descriptions?<br/>
|
|
STL: right.<br/>
|
|
JW: I love it<br/>
|
|
MC: in favor of moving to Ready and bringing up for vote on Friday<br/>
|
|
7 in favor, none opposed
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N4296.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 20.2 [utility]/2 "Header <tt><utility></tt> synopsis" as depicted:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
[…]
|
|
template<size_t I, class T1, class T2>
|
|
constexpr tuple_element_t<I, pair<T1, T2>>&
|
|
get(pair<T1, T2>&) noexcept;
|
|
template<size_t I, class T1, class T2>
|
|
constexpr tuple_element_t<I, pair<T1, T2>>&&
|
|
get(pair<T1, T2>&&) noexcept;
|
|
template<size_t I, class T1, class T2>
|
|
constexpr const tuple_element_t<I, pair<T1, T2>>&
|
|
get(const pair<T1, T2>&) noexcept;
|
|
<ins>template<size_t I, class T1, class T2>
|
|
constexpr const tuple_element_t<I, pair<T1, T2>>&&
|
|
get(const pair<T1, T2>&&) noexcept;</ins>
|
|
template <class T, class U>
|
|
constexpr T& get(pair<T, U>& p) noexcept;
|
|
template <class T, class U>
|
|
constexpr const T& get(const pair<T, U>& p) noexcept;
|
|
template <class T, class U>
|
|
constexpr T&& get(pair<T, U>&& p) noexcept;
|
|
<ins>template <class T, class U>
|
|
constexpr const T&& get(const pair<T, U>&& p) noexcept;</ins>
|
|
template <class T, class U>
|
|
constexpr T& get(pair<U, T>& p) noexcept;
|
|
template <class T, class U>
|
|
constexpr const T& get(const pair<U, T>& p) noexcept;
|
|
template <class T, class U>
|
|
constexpr T&& get(pair<U, T>&& p) noexcept;
|
|
<ins>template <class T, class U>
|
|
constexpr const T&& get(const pair<U, T>&& p) noexcept;</ins>
|
|
[…]
|
|
</pre>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 20.4.1 [tuple.general]/2 "Header <tt><tuple></tt> synopsis" as depicted:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
[…]
|
|
<i>// 20.4.2.6, element access:</i>
|
|
template <size_t I, class... Types>
|
|
constexpr tuple_element_t<I, tuple<Types...>>&
|
|
get(tuple<Types...>&) noexcept;
|
|
template <size_t I, class... Types>
|
|
constexpr tuple_element_t<I, tuple<Types...>>&&
|
|
get(tuple<Types...>&&) noexcept;
|
|
template <size_t I, class... Types>
|
|
constexpr const tuple_element_t<I, tuple<Types...>>&
|
|
get(const tuple<Types...>&) noexcept;
|
|
<ins>template <size_t I, class... Types>
|
|
constexpr const tuple_element_t<I, tuple<Types...>>&&
|
|
get(const tuple<Types...>&&) noexcept;</ins>
|
|
template <class T, class... Types>
|
|
constexpr T& get(tuple<Types...>& t) noexcept;
|
|
template <class T, class... Types>
|
|
constexpr T&& get(tuple<Types...>&& t) noexcept;
|
|
template <class T, class... Types>
|
|
constexpr const T& get(const tuple<Types...>& t) noexcept;
|
|
<ins>template <class T, class... Types>
|
|
constexpr const T&& get(const tuple<Types...>&& t) noexcept;</ins>
|
|
[…]
|
|
</pre>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 23.3.1 [sequences.general]/2 "Header <tt><array></tt> synopsis" as depicted:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
[…]
|
|
template <size_t I, class T, size_t N>
|
|
constexpr T& get(array<T, N>&) noexcept;
|
|
template <size_t I, class T, size_t N>
|
|
constexpr T&& get(array<T, N>&&) noexcept;
|
|
template <size_t I, class T, size_t N>
|
|
constexpr const T& get(const array<T, N>&) noexcept;
|
|
<ins>template <size_t I, class T, size_t N>
|
|
constexpr const T&& get(const array<T, N>&&) noexcept;</ins>
|
|
[…]
|
|
</pre>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 20.3.4 [pair.astuple] as depicted:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
template<size_t I, class T1, class T2>
|
|
constexpr tuple_element_t<I, pair<T1, T2>>&
|
|
get(pair<T1, T2>& p) noexcept;
|
|
template<size_t I, class T1, class T2>
|
|
constexpr const tuple_element_t<I, pair<T1, T2>>&
|
|
get(const pair<T1, T2>& p) noexcept;
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
<del>-3- <i>Returns</i>: If <tt>I == 0</tt> returns <tt>p.first</tt>; if <tt>I == 1</tt> returns <tt>p.second</tt>;
|
|
otherwise the program is ill-formed.</del>
|
|
</p>
|
|
</blockquote>
|
|
<pre>
|
|
template<size_t I, class T1, class T2>
|
|
constexpr tuple_element_t<I, pair<T1, T2>>&&
|
|
get(pair<T1, T2>&& p) noexcept;
|
|
<ins>template<size_t I, class T1, class T2>
|
|
constexpr const tuple_element_t<I, pair<T1, T2>>&&
|
|
get(const pair<T1, T2>&& p) noexcept;</ins>
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-4- <i>Returns</i>: If <tt>I == 0</tt> returns <ins>a reference to</ins>
|
|
<tt><del>std::forward<T1&&>(</del>p.first<del>)</del></tt>; if <tt>I == 1</tt>
|
|
returns <ins>a reference to</ins> <tt><del>std::forward<T2&&>(</del>p.second<del>)</del></tt>;
|
|
otherwise the program is ill-formed.
|
|
</p>
|
|
</blockquote>
|
|
<pre>
|
|
template <class T, class U>
|
|
constexpr T& get(pair<T, U>& p) noexcept;
|
|
template <class T, class U>
|
|
constexpr const T& get(const pair<T, U>& p) noexcept;
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
<del>-5- Requires: <tt>T</tt> and <tt>U</tt> are distinct types. Otherwise, the program is ill-formed.</del>
|
|
<p/>
|
|
<del>-6- Returns: <tt>get<0>(p)</tt>;</del>
|
|
</p>
|
|
</blockquote>
|
|
<pre>
|
|
template <class T, class U>
|
|
constexpr T&& get(pair<T, U>&& p) noexcept;
|
|
<ins>template <class T, class U>
|
|
constexpr const T&& get(const pair<T, U>&& p) noexcept;</ins>
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-7- Requires: <tt>T</tt> and <tt>U</tt> are distinct types. Otherwise, the program is ill-formed.
|
|
<p/>
|
|
-8- Returns: <ins>A reference to <tt>p.first</tt>.</ins><del><tt>get<0>(std::move(p))</tt>;</del>
|
|
</p>
|
|
</blockquote>
|
|
<pre>
|
|
template <class T, class U>
|
|
constexpr T& get(pair<U, T>& p) noexcept;
|
|
template <class T, class U>
|
|
constexpr const T& get(const pair<U, T>& p) noexcept;
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
<del>-9- Requires: <tt>T</tt> and <tt>U</tt> are distinct types. Otherwise, the program is ill-formed.</del>
|
|
<p/>
|
|
<del>-10- Returns: <tt>get<1>(p)</tt>;</del>
|
|
</p>
|
|
</blockquote>
|
|
<pre>
|
|
template <class T, class U>
|
|
constexpr T&& get(pair<U, T>&& p) noexcept;
|
|
<ins>template <class T, class U>
|
|
constexpr const T&& get(const pair<U, T>&& p) noexcept;</ins>
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-11- Requires: <tt>T</tt> and <tt>U</tt> are distinct types. Otherwise, the program is ill-formed.
|
|
<p/>
|
|
-12- Returns: <ins>A reference to <tt>p.second</tt>.</ins><del><tt>get<1>(std::move(p))</tt>;</del>
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 20.4.2.6 [tuple.elem] as depicted:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
template <size_t I, class... Types>
|
|
constexpr tuple_element_t<I, tuple<Types...> >& get(tuple<Types...>& t) noexcept;
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
<del>-1- <i>Requires</i>: <tt>I < sizeof...(Types)</tt>. The program is ill-formed if <tt>I</tt> is out of bounds.</del>
|
|
<p/>
|
|
<del>-2- <i>Returns</i>: A reference to the <tt>I</tt>th element of <tt>t</tt>, where indexing is zero-based.</del>
|
|
</p>
|
|
</blockquote>
|
|
<pre>
|
|
template <size_t I, class... Types>
|
|
constexpr tuple_element_t<I, tuple<Types...> >&& get(tuple<Types...>&& t) noexcept; <ins><i>// Note A</i></ins>
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
<del>-3- <i>Effects</i>: Equivalent to return std::forward<typename tuple_element<I, tuple<Types...> >::type&&>(get<I>(t));</del>
|
|
<p/>
|
|
<del>-4- <i>Note</i>: if a <tt>T</tt> in <tt>Types</tt> is some reference type <tt>X&</tt>, the return type is <tt>X&</tt>, not
|
|
<tt>X&&</tt>. However, if the element type is a non-reference type <tt>T</tt>, the return type is <tt>T&&</tt>.</del>
|
|
</p>
|
|
</blockquote>
|
|
<pre>
|
|
template <size_t I, class... Types>
|
|
constexpr tuple_element_t<I, tuple<Types...> > const& get(const tuple<Types...>& t) noexcept; <ins><i>// Note B</i></ins>
|
|
<ins>template <size_t I, class... Types>
|
|
constexpr const tuple_element_t<I, tuple<Types...> >&& get(const tuple<Types...>&& t) noexcept;</ins>
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-5- <i>Requires</i>: <tt>I < sizeof...(Types)</tt>. The program is ill-formed if <tt>I</tt> is out of bounds.
|
|
<p/>
|
|
-6- <i>Returns</i>: A <del>const</del> reference to the <tt>I</tt>th element of <tt>t</tt>, where indexing is zero-based.
|
|
<p/>
|
|
<ins>-?- [<i>Note A</i>: if a <tt>T</tt> in <tt>Types</tt> is some reference type <tt>X&</tt>, the return type is <tt>X&</tt>,
|
|
not <tt>X&&</tt>. However, if the element type is a non-reference type <tt>T</tt>, the return type is <tt>T&&</tt>.
|
|
— <i>end note</i>]</ins>
|
|
<p/>
|
|
-7- [<i>Note <ins>B</ins></i>: Constness is shallow. If a <tt>T</tt> in <tt>Types</tt> is some reference type <tt>X&</tt>,
|
|
the return type is <tt>X&</tt>, not <tt>const X&</tt>. However, if the element type is non-reference type <tt>T</tt>,
|
|
the return type is <tt>const T&</tt>. This is consistent with how constness is defined to work for member variables of
|
|
reference type. — <i>end note</i>]
|
|
</p>
|
|
</blockquote>
|
|
<pre>
|
|
template <class T, class... Types>
|
|
constexpr T& get(tuple<Types...>& t) noexcept;
|
|
template <class T, class... Types>
|
|
constexpr T&& get(tuple<Types...>&& t) noexcept;
|
|
template <class T, class... Types>
|
|
constexpr const T& get(const tuple<Types...>& t) noexcept;
|
|
<ins>template <class T, class... Types>
|
|
constexpr const T&& get(const tuple<Types...>&& t) noexcept;</ins>
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-8- <i>Requires</i>: The type <tt>T</tt> occurs exactly once in <tt>Types...</tt>. Otherwise, the program is ill-formed.
|
|
<p/>
|
|
-9- <i>Returns</i>: A reference to the element of <tt>t</tt> corresponding to the type <tt>T</tt> in <tt>Types...</tt>.
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 23.3.2.9 [array.tuple] as depicted:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
template <size_t I, class T, size_t N>
|
|
<ins> </ins>constexpr T& get(array<T, N>& a) noexcept;
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
<del>-3- <i>Requires</i>: <tt>I < N</tt>. The program is ill-formed if <tt>I</tt> is out of bounds.</del>
|
|
<p/>
|
|
<del>-4- <i>Returns</i>: A reference to the <tt>I</tt>th element of <tt>a</tt>, where indexing is zero-based.</del>
|
|
</p>
|
|
</blockquote>
|
|
<pre>
|
|
template <size_t I, class T, size_t N>
|
|
<ins> </ins>constexpr T&& get(array<T, N>&& a) noexcept;
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
<del>-5- <i>Effects</i>: Equivalent to <tt>return std::move(get<I>(a));</tt></del>
|
|
</p>
|
|
</blockquote>
|
|
<pre>
|
|
template <size_t I, class T, size_t N>
|
|
<ins> </ins>constexpr const T& get(const array<T, N>& a) noexcept;
|
|
<ins>template <size_t I, class T, size_t N>
|
|
constexpr const T&& get(const array<T, N>&& a) noexcept;</ins>
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-6- <i>Requires</i>: <tt>I < N</tt>. The program is ill-formed if <tt>I</tt> is out of bounds.
|
|
<p/>
|
|
-7- <i>Returns</i>: A <del>const</del> reference to the <tt>I</tt>th element of <tt>a</tt>, where indexing is zero-based.
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2486"></a>2486. <tt>mem_fn()</tt> should be required to use perfect forwarding</h3>
|
|
<p><b>Section:</b> 20.9.2 [func.require] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2015-03-27 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#func.require">active issues</a> in [func.require].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#func.require">issues</a> in [func.require].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
20.9.2 [func.require]/4 defines "simple call wrapper" and "forwarding call wrapper". Only <tt>mem_fn()</tt> is
|
|
specified to be a "simple call wrapper", by 20.9.11 [func.memfn]/1: "A simple call wrapper (20.9.1) <tt>fn</tt>
|
|
such that the expression <tt>fn(t, a2, ..., aN)</tt> is equivalent to <tt>INVOKE(pm, t, a2, ..., aN)</tt> (20.9.2)."
|
|
<p/>
|
|
This suggests, but doesn't outright state, that perfect forwarding is involved. It matters for PMFs like
|
|
<tt>R (T::*)(Arg)</tt> where <tt>Arg</tt> is passed by value — if the <tt>mem_fn()</tt> wrapper's function call
|
|
operator takes <tt>Arg</tt> by value, an extra copy/move will be observable. We should require perfect forwarding here.
|
|
</p>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
Move to Immediate.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N4296.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 20.9.2 [func.require] as depicted [<i>Editorial remark</i>: This simply adds "A simple call wrapper
|
|
is a <ins>forwarding</ins> call wrapper", then moves the sentence. — <i>end of remark</i>]:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
-4- Every call wrapper (20.9.1) shall be <tt>MoveConstructible</tt>. <del>A <i>simple call wrapper</i> is a call wrapper that is
|
|
<tt>CopyConstructible</tt> and <tt>CopyAssignable</tt> and whose copy constructor, move constructor, and assignment
|
|
operator do not throw exceptions.</del> A <i>forwarding call wrapper</i> is a call wrapper that can be called with
|
|
an arbitrary argument list and delivers the arguments to the wrapped callable object as references. This
|
|
forwarding step shall ensure that rvalue arguments are delivered as rvalue-references and lvalue arguments
|
|
are delivered as lvalue-references. <ins>A <i>simple call wrapper</i> is a forwarding call wrapper that is <tt>CopyConstructible</tt>
|
|
and <tt>CopyAssignable</tt> and whose copy constructor, move constructor, and assignment operator do not throw exceptions.</ins>
|
|
[<i>Note</i>: In a typical implementation […] — <i>end note</i>]
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2487"></a>2487. <tt>bind()</tt> should be <tt>const</tt>-overloaded, not <i>cv</i>-overloaded</h3>
|
|
<p><b>Section:</b> 20.9.10.3 [func.bind.bind] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2015-03-27 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The Standard currently requires <tt>bind()</tt> to return something with a <i>cv</i>-overloaded function call operator.
|
|
<tt>const</tt> is great, but <tt>volatile</tt> is not. First, the Library almost always ignores <tt>volatile</tt>'s
|
|
existence (with <tt><type_traits></tt> and <tt><atomic></tt> being rare exceptions). Second, implementations
|
|
typically store bound arguments in a <tt>tuple</tt>, but <tt>get()</tt> isn't overloaded for <tt>volatile tuple</tt>. Third,
|
|
when a bound argument is a <tt>reference_wrapper</tt>, we have to call <tt>tid.get()</tt>, but that won't compile for a
|
|
<tt>volatile reference_wrapper</tt>. Finally, <tt>const</tt> and <tt>volatile</tt> don't always have to be handled symmetrically
|
|
— for example, lambda function call operators are <tt>const</tt> by default, but they can't ever be <tt>volatile</tt>.
|
|
<p/>
|
|
Implementers shouldn't be required to provide <i>cv</i>-overloading here. (They can provide it as a conforming extension if
|
|
they want.)
|
|
</p>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
JW: why would a <tt>reference_wrapper</tt> be volatile?<br/>
|
|
STL: if a bound argument is a <tt>reference_wrapper</tt> then in a volatile-qualified operator() that
|
|
member will be volatile so you can't call get() on it<br/>
|
|
STL: worded like this it's a conforming extension to kep overloading on volatile<br/>
|
|
HH: libc++ doesn't overload on volatile<br/>
|
|
JW: libstdc++ does overload for volatile<br/>
|
|
MC: move to Ready and bring motion on Friday<br/>
|
|
10 in favor, none opposed
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N4296.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 20.9.10.3 [func.bind.bind] as depicted:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
template<class F, class... BoundArgs>
|
|
<i>unspecified</i> bind(F&& f, BoundArgs&&... bound_args);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-2- <i>Requires</i>: <tt>is_constructible<FD, F>::value</tt> shall be <tt>true</tt>. For each <tt>Ti</tt>
|
|
in <tt>BoundArgs</tt>, <tt>is_constructible<TiD, Ti>::value</tt> shall be <tt>true</tt>.
|
|
<tt><i>INVOKE</i>(fd, w1, w2, ..., wN)</tt> (20.9.2) shall be a valid expression for some values <tt>w1</tt>, <tt>w2</tt>,
|
|
..., <tt>wN</tt>, where <tt>N == sizeof...(bound_args)</tt>. <ins>The <i>cv</i>-qualifiers <i>cv</i> of the call
|
|
wrapper <tt>g</tt>, as specified below, shall be neither <tt>volatile</tt> nor <tt>const volatile</tt>.</ins>
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
</blockquote>
|
|
<pre>
|
|
template<class R, class F, class... BoundArgs>
|
|
<i>unspecified</i> bind(F&& f, BoundArgs&&... bound_args);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
-6- <i>Requires</i>: <tt>is_constructible<FD, F>::value</tt> shall be <tt>true</tt>. For each <tt>Ti</tt>
|
|
in <tt>BoundArgs</tt>, <tt>is_constructible<TiD, Ti>::value</tt> shall be <tt>true</tt>.
|
|
<tt><i>INVOKE</i>(fd, w1, w2, ..., wN)</tt> shall be a valid expression for some values <tt>w1</tt>, <tt>w2</tt>,
|
|
..., <tt>wN</tt>, where <tt>N == sizeof...(bound_args)</tt>. <ins>The <i>cv</i>-qualifiers <i>cv</i> of the call
|
|
wrapper <tt>g</tt>, as specified below, shall be neither <tt>volatile</tt> nor <tt>const volatile</tt>.</ins>
|
|
<p/>
|
|
[…]
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2489"></a>2489. <tt>mem_fn()</tt> should be <tt>noexcept</tt></h3>
|
|
<p><b>Section:</b> 20.9.11 [func.memfn] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2015-03-27 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#func.memfn">issues</a> in [func.memfn].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
<tt>mem_fn()</tt> is wide contract and doesn't do anything that could throw exceptions, so it should be marked <tt>noexcept</tt>.
|
|
<p/>
|
|
Note that <tt>mem_fn()</tt> is perfectly happy to wrap a null PMF/PMD, it just can't be invoked later. This is exactly like
|
|
<tt>std::function</tt>, which can be constructed from null PMFs/PMDs. Therefore, <tt>mem_fn()</tt> will remain wide contract forever.
|
|
</p>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
Move to Immediate.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N4296.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 20.9 [function.objects] p2 "Header <tt><functional></tt> synopsis" as depicted:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
[…]
|
|
<i>// 20.9.11, member function adaptors:</i>
|
|
template<class R, class T> <i>unspecified</i> mem_fn(R T::*) <ins>noexcept</ins>;
|
|
[…]
|
|
</pre>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 20.9.11 [func.memfn] as depicted:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
template<class R, class T> <i>unspecified</i> mem_fn(R T::* pm) <ins>noexcept</ins>;
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
[…]
|
|
<p/>
|
|
<del>-4- <i>Throws</i>: Nothing.</del>
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2490"></a>2490. <tt><regex></tt> needs lots of <tt>noexcept</tt></h3>
|
|
<p><b>Section:</b> 28 [re] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2015-03-27 <b>Last modified:</b> 2015-05-04</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#re">active issues</a> in [re].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#re">issues</a> in [re].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Only 4 functions are marked <tt>noexcept</tt> in all of Clause 28. Many more need to be marked — for example,
|
|
<tt>regex_error::code()</tt>, <tt>basic_regex::swap()</tt>, and <tt>sub_match::length()</tt>.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2491"></a>2491. <tt>std::less<T*></tt> in constant expression</h3>
|
|
<p><b>Section:</b> 20.9.6 [comparisons] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Agustín K-ballo Bergé <b>Opened:</b> 2015-04-01 <b>Last modified:</b> 2015-05-04</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#comparisons">active issues</a> in [comparisons].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#comparisons">issues</a> in [comparisons].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
It is not entirely clear if and when the specializations of <tt>std::less</tt> (and friends) for pointer types
|
|
can be used in a constant expression. Consider the following code:
|
|
</p>
|
|
<blockquote><pre>
|
|
#include <functional>
|
|
|
|
struct foo {};
|
|
foo x, y;
|
|
constexpr bool b = std::less<foo*>{}(&x, &y); // [1]
|
|
|
|
foo z[] = {{}, {}};
|
|
constexpr bool ba = std::less<foo*>{}(&z[0], &z[1]); // [2]
|
|
</pre></blockquote>
|
|
<p>
|
|
Comparing the address of unrelated objects is not a constant expression since the result is unspecified, so
|
|
it could be expected for [1] to fail and [2] to succeed. However, <tt>std::less</tt> specialization for pointer
|
|
types is well-defined and yields a total order, so it could just as well be expected for [1] to succeed. Finally,
|
|
since the implementation of such specializations is not mandated, [2] could fail as well (This could happen, if
|
|
an implementation would provide such a specialization and if that would use built-in functions that would not be
|
|
allowed in constant expressions, for example). In any case, the standard should be clear so as to avoid
|
|
implementation-defined <tt>constexpr</tt>-ness.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2492"></a>2492. Clarify requirements for <tt>comp</tt></h3>
|
|
<p><b>Section:</b> 25.4 [alg.sorting] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Anton Savin <b>Opened:</b> 2015-04-14 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#alg.sorting">issues</a> in [alg.sorting].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
N4296 25.4 [alg.sorting]/3 reads:
|
|
</p>
|
|
<blockquote><p>
|
|
For all algorithms that take <tt>Compare</tt>, there is a version that uses <tt>operator<</tt> instead. That is,
|
|
<tt>comp(*i,*j) != false</tt> defaults to <tt>*i < *j != false</tt>. For algorithms other than those described in
|
|
25.4.3 to work correctly, <tt>comp</tt> has to induce a strict weak ordering on the values.
|
|
</p></blockquote>
|
|
<p>
|
|
So it's not specified clearly what happens if <tt>comp</tt> or <tt>operator<</tt> don't induce a strict weak ordering.
|
|
Is it undefined or implementation-defined behavior? It seems that it should be stated more clearly that the behavior is
|
|
undefined.
|
|
</p>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
Move to Immediate.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N4431.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 25.4 [alg.sorting]/3 to the following:</p>
|
|
<blockquote>
|
|
<p>
|
|
For all algorithms that take <tt>Compare</tt>, there is a version that uses <tt>operator<</tt> instead. That is, <tt>comp(*i,
|
|
*j) != false</tt> defaults to <tt>*i < *j != false</tt>. For algorithms other than those described in 25.4.3 <del>to work
|
|
correctly</del>, <tt>comp</tt> <ins>shall</ins><del>has to</del> induce a strict weak ordering on the values.
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2493"></a>2493. <tt>initializer_list</tt> supports incomplete classes</h3>
|
|
<p><b>Section:</b> 18.9 [support.initlist] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> David Krauss <b>Opened:</b> 2015-04-27 <b>Last modified:</b> 2015-05-04</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#support.initlist">active issues</a> in [support.initlist].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#support.initlist">issues</a> in [support.initlist].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The typical use-case of <tt>std::initializer_list<T></tt> is for a pass-by-value parameter of <tt>T</tt>'s constructor.
|
|
However, this contravenes 17.6.4.8 [res.on.functions]/2.5 because <tt>initializer_list</tt> doesn't specifically allow
|
|
incomplete types (as do for example <tt>std::unique_ptr</tt> (20.8.1 [unique.ptr]/5) and
|
|
<tt>std::enable_shared_from_this</tt> (20.8.2.5 [util.smartptr.enab]/2)).
|
|
<p/>
|
|
A resolution would be to copy-paste the relevant text from such a paragraph.
|
|
</p>
|
|
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2494"></a>2494. [fund.ts.v2] <tt>ostream_joiner</tt> needs <tt>noexcept</tt></h3>
|
|
<p><b>Section:</b> X [iterator.ostream.joiner] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
|
|
<b>Submitter:</b> Nate Wilson <b>Opened:</b> 2015-05-03 <b>Last modified:</b> 2015-05-08</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p><b>Addresses: fund.ts.v2</b></p>
|
|
<p>
|
|
In Library Fundamentals 2
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4481.html#iterator.ostream.joiner.ops">N4481</a>,
|
|
[iterator.ostream.joiner], all operations are no-ops other than the assignment operator.
|
|
<p/>
|
|
So, they should be marked as <tt>noexcept</tt>.
|
|
</p>
|
|
|
|
<p><i>[2015-05, Lenexa]</i></p>
|
|
|
|
<p>
|
|
Move to Immediate.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N4481 in regard to fundamental-ts-2 changes.</p>
|
|
|
|
<ol>
|
|
<li><p>Change class template <tt>ostream_joiner</tt> synopsis, [iterator.ostream.joiner] p2, as indicated:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
namespace std {
|
|
namespace experimental {
|
|
inline namespace fundamentals_v2 {
|
|
|
|
template <class DelimT, class charT = char, class traits = char_traits<charT> >
|
|
class ostream_joiner {
|
|
public:
|
|
[…]
|
|
ostream_joiner<DelimT, charT,traits>& operator*() <ins>noexcept</ins>;
|
|
ostream_joiner<DelimT, charT,traits>& operator++() <ins>noexcept</ins>;
|
|
ostream_joiner<DelimT, charT,traits>& operator++(int) <ins>noexcept</ins>;
|
|
[…]
|
|
};
|
|
|
|
} // inline namespace fundamentals_v2
|
|
} // namespace experimental
|
|
} // namespace std
|
|
</pre>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li><p>Change [iterator.ostream.joiner.ops] p3+5, as indicated:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
ostream_joiner<DelimT, charT, traits>& operator*() <ins>noexcept</ins>;
|
|
</pre>
|
|
<p>
|
|
[…]
|
|
</p>
|
|
<pre>
|
|
ostream_joiner<DelimT, charT, traits>& operator++() <ins>noexcept</ins>;
|
|
ostream_joiner<DelimT, charT, traits>& operator++(int) <ins>noexcept</ins>;
|
|
</pre>
|
|
</blockquote>
|
|
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2495"></a>2495. There is no such thing as an <i>Exception Safety</i> element</h3>
|
|
<p><b>Section:</b> 20.8.2.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2015-05-05 <b>Last modified:</b> 2015-05-20</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
20.8.2.2.1 [util.smartptr.shared.const] includes several "Exception safety"
|
|
elements, but that is not one of the elements defined in 17.5.1.4
|
|
17.5.1.4 [structure.specifications]. We should either define what it means, or
|
|
just move those sentences into the <i>Effects:</i> clause.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N4431.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 20.8.2.2.1 [util.smartptr.shared.const] as follows:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
template<class Y> explicit shared_ptr(Y* p);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
[…]
|
|
<p/>
|
|
-4- <i>Effects</i>: Constructs a <tt>shared_ptr</tt> object that <i>owns</i> the pointer <tt>p</tt>. <ins>If an exception
|
|
is thrown, <tt>delete p</tt> is called.</ins>
|
|
<p/>
|
|
[…]
|
|
<p/>
|
|
<del>-7- <i>Exception safety</i>: If an exception is thrown, <tt>delete p</tt> is called.</del>
|
|
</p>
|
|
</blockquote>
|
|
<pre>
|
|
template <class Y, class D> shared_ptr(Y* p, D d);
|
|
template <class Y, class D, class A> shared_ptr(Y* p, D d, A a);
|
|
template <class D> shared_ptr(nullptr_t p, D d);
|
|
template <class D, class A> shared_ptr(nullptr_t p, D d, A a);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
[…]
|
|
<p/>
|
|
-9- <i>Effects</i>: Constructs a <tt>shared_ptr</tt> object that owns the object <tt>p</tt> and the deleter <tt>d</tt>.
|
|
The second and fourth constructors shall use a copy of <tt>a</tt> to allocate memory for internal use. <ins>If an exception
|
|
is thrown, <tt>d(p)</tt> is called.</ins>
|
|
<p/>
|
|
[…]
|
|
<p/>
|
|
<del>-12- <i>Exception safety</i>: If an exception is thrown, <tt>d(p)</tt> is called.</del>
|
|
</p>
|
|
</blockquote>
|
|
[…]
|
|
<pre>
|
|
template <class Y> explicit shared_ptr(const weak_ptr<Y>& r);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
[…]
|
|
<p/>
|
|
-24- <i>Effects</i>: Constructs a <tt>shared_ptr</tt> object that shares ownership with <tt>r</tt> and stores a copy of the pointer
|
|
stored in <tt>r</tt>. <ins>If an exception is thrown, the constructor has no effect.</ins>
|
|
<p/>
|
|
[…]
|
|
<p/>
|
|
<del>-27- <i>Exception safety</i>: If an exception is thrown, the constructor has no effect.</del>
|
|
</p>
|
|
</blockquote>
|
|
<pre>
|
|
template <class Y, class D> shared_ptr(unique_ptr<Y, D>&& r);
|
|
</pre>
|
|
<blockquote>
|
|
<p>
|
|
[…]
|
|
<p/>
|
|
-29- <i>Effects</i>: Equivalent to <tt>shared_ptr(r.release(), r.get_deleter())</tt> when <tt>D</tt> is not a reference type,
|
|
otherwise <tt>shared_ptr(r.release(), ref(r.get_deleter()))</tt>. <ins>If an exception is thrown, the constructor has no effect.</ins>
|
|
<p/>
|
|
<del>-30- <i>Exception safety</i>: If an exception is thrown, the constructor has no effect.</del>
|
|
</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2496"></a>2496. Certain hard-to-avoid errors not in the immediate context are not allowed to be triggered by
|
|
the evaluation of type traits</h3>
|
|
<p><b>Section:</b> 20.10.4.3 [meta.unary.prop] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Hubert Tong <b>Opened:</b> 2015-05-07 <b>Last modified:</b> 2015-05-20</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
I do not believe that the wording in 20.10.4.3 [meta.unary.prop] paragraph 3 allows for the following program to be ill-formed:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
#include <type_traits>
|
|
|
|
template <typename T> struct B : T { };
|
|
template <typename T> struct A { A& operator=(const B<T>&); };
|
|
|
|
std::is_assignable<A<int>, int> q;
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
In particular, I do not see where the wording allows for the "compilation of the expression"
|
|
<tt>declval<T>() = declval<U>()</tt> to occur as a consequence of instantiating <tt>std::is_assignable<T, U></tt>
|
|
(where <tt>T</tt> and <tt>U</tt> are, respectively, <tt>A<int></tt> and <tt>int</tt> in the example code).
|
|
<p/>
|
|
Instantiating <tt>A<int></tt> as a result of requiring it to be a complete type does not trigger the instantiation of
|
|
<tt>B<int></tt>; however, the "compilation of the expression" in question does.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2497"></a>2497. Use of <tt>uncaught_exception()</tt></h3>
|
|
<p><b>Section:</b> 27.7.3.4 [ostream::sentry] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Roger Orr <b>Opened:</b> 2015-05-08 <b>Last modified:</b> 2015-05-20</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#ostream::sentry">issues</a> in [ostream::sentry].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
In the current 27.7.3.4 [ostream::sentry], p4 refers to the now deprecated <tt>std::uncaught_exception()</tt>:
|
|
D.9 [depr.uncaught].
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
If <tt>((os.flags() & ios_base::unitbuf) && !uncaught_exception() && os.good())</tt> is true, calls
|
|
<tt>os.rdbuf()->pubsync()</tt>.
|
|
</p>
|
|
</blockquote>
|
|
<p>
|
|
This needs to be changed, for example to use <tt>std::uncaught_exceptions()</tt> and to capture the value on entry and
|
|
compare with the saved value on exit.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2498"></a>2498. <tt>operator>>(basic_istream&&, T&&)</tt> returns <tt>basic_istream&</tt>, but should probably return
|
|
<tt>basic_istream&&</tt></h3>
|
|
<p><b>Section:</b> 27.7.2.6 [istream.rvalue] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Richard Smith <b>Opened:</b> 2015-05-08 <b>Last modified:</b> 2015-05-20</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#istream.rvalue">active issues</a> in [istream.rvalue].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#istream.rvalue">issues</a> in [istream.rvalue].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
Consider:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
auto& is = make_istream() >> x; // oops, istream object is already gone
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
With a <tt>basic_istream&&</tt> return type, the above would be ill-formed, and generally we'd
|
|
preserve the value category properly.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2499"></a>2499. <tt>operator>>(basic_istream&, CharT*)</tt> makes it hard to avoid buffer overflows</h3>
|
|
<p><b>Section:</b> 27.7.2.2.3 [istream::extractors] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Richard Smith <b>Opened:</b> 2015-05-08 <b>Last modified:</b> 2015-05-21</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
We removed <tt>gets()</tt> (due to an NB comment and C11 — bastion of backwards compatibility — doing the same).
|
|
Should we remove this too?
|
|
<p/>
|
|
Unlike <tt>gets()</tt>, there are legitimate uses:
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
char buffer[32];
|
|
char text[32] = // ...
|
|
ostream_for_buffer(text) >> buffer; // ok, can't overrun buffer
|
|
</pre>
|
|
</blockquote>
|
|
<p>
|
|
… but the risk from constructs like "<tt>std::cin >> buffer</tt>" seems to outweigh the benefit.
|
|
<p/>
|
|
The issue had been discussed on the library reflector starting around
|
|
<a href="http://accu.org/cgi-bin/wg21/message?wg=lib&msg=35541">c++std-lib-35541</a>.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2500"></a>2500. [fund.ts.v2] fundts.memory.smartptr.shared.obs/6 should apply to <i>cv</i>-unqualified <tt>void</tt></h3>
|
|
<p><b>Section:</b> X [memory.smartptr.shared.obs] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2015-05-11 <b>Last modified:</b> 2015-05-20</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p><b>Addresses: fund.ts.v2</b></p>
|
|
<p>
|
|
S. B. Tam reported this <a href="https://github.com/cplusplus/fundamentals-ts/issues/51">here</a>.
|
|
<p/>
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3920.html">N3920</a> changed <tt>operator*()</tt> in
|
|
[util.smartptr.shared.obs] as:
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
<i>Remarks</i>: When <tt>T</tt> is <ins>an array type or <i>cv</i>-qualified</ins> <tt>void</tt>, it
|
|
is unspecified whether this member function is declared. …
|
|
</p>
|
|
</blockquote>
|
|
<p>
|
|
This excludes <i>cv</i>-unqualified <tt>void</tt>, which is probably unintended.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<ol>
|
|
<li><p>In the <a href="https://rawgit.com/cplusplus/fundamentals-ts/v2/fundamentals-ts.html#memory.smartptr.shared.obs.6">library
|
|
fundamentals v2</a>, [memory.smartptr.shared.obs] p2, change as indicated:</p>
|
|
<blockquote>
|
|
<p>
|
|
<i>Remarks</i>: When <tt>T</tt> is an array type or <ins>(possibly</ins> <i>cv</i>-qualified<ins>)</ins>
|
|
<tt>void</tt>, it is unspecified whether this
|
|
member function is declared. If it is declared, it is unspecified what
|
|
its return type is, except that the declaration (although not
|
|
necessarily the definition) of the function shall be well formed.
|
|
</p>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2501"></a>2501. <tt>std::function</tt> requires POCMA/POCCA</h3>
|
|
<p><b>Section:</b> 20.9.12.2 [func.wrap.func] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> David Krauss <b>Opened:</b> 2015-05-20 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The idea behind <tt>propagate_on_container_move_assignment</tt> is that you can keep an allocator attached to a container.
|
|
But it's not really designed to work with polymorphism, which introduces the condition where the current allocator is non-POCMA
|
|
and the RHS of assignment, being POCMA, wants to replace it. If function were to respect the literal meaning, any would-be
|
|
attached allocator is at the mercy of every assignment operation. So, <tt>std::function</tt> is inherently POCMA, and passing
|
|
a non-POCMA allocator should be ill-formed.
|
|
<p/>
|
|
The other alternative, and the status quo, is to ignore POCMA and assume it is true. This seems just dangerous enough to outlaw.
|
|
It is, in theory, possible to properly support POCMA as far as I can see, albeit with difficulty and brittle results. It would
|
|
require function to keep a throwing move constructor, which otherwise can be <tt>noexcept</tt>.
|
|
<p/>
|
|
The same applies to <tt>propagate_on_container_copy_assignment</tt>. This presents more difficulty because <tt>std::allocator</tt>
|
|
does not set this to true. Perhaps it should. For function to respect this would require inspecting the POCCA of the source allocator,
|
|
slicing the target from the erasure of the source, slicing the allocation from the erasure of the destination, and performing a
|
|
copy with the destination's allocator with the source's target. This comes out of the blue for the destination allocator, which
|
|
might not support the new type anyway. Theoretically possible, but brittle and not very practical. Again, current implementations
|
|
quietly ignore the issue but this isn't very clean.
|
|
<p/>
|
|
The following code example is intended to demonstrate the issue here:
|
|
</p>
|
|
<blockquote><pre>
|
|
#include <functional>
|
|
#include <iostream>
|
|
#include <vector>
|
|
|
|
template <typename T>
|
|
struct diag_alloc
|
|
{
|
|
std::string name;
|
|
|
|
T* allocate(std::size_t n) const
|
|
{
|
|
std::cout << '+' << name << '\n';
|
|
return static_cast<T*>(::operator new(n * sizeof(T)));
|
|
}
|
|
|
|
void deallocate(T* p, std::size_t) const
|
|
{
|
|
std::cout << '-' << name << '\n';
|
|
return ::operator delete(p);
|
|
}
|
|
|
|
template <typename U>
|
|
operator diag_alloc<U>() const { return {name}; }
|
|
|
|
friend bool operator==(const diag_alloc& a, const diag_alloc& b)
|
|
{ return a.name == b.name; }
|
|
|
|
friend bool operator!=(const diag_alloc& a, const diag_alloc& b)
|
|
{ return a.name != b.name; }
|
|
|
|
typedef T value_type;
|
|
|
|
template <typename U>
|
|
struct rebind { typedef diag_alloc<U> other; };
|
|
};
|
|
|
|
int main() {
|
|
std::cout << "VECTOR\n";
|
|
std::vector<int, diag_alloc<int>> foo({1, 2}, {"foo"}); // +foo
|
|
std::vector<int, diag_alloc<int>> bar({3, 4}, {"bar"}); // +bar
|
|
|
|
std::cout << "move\n";
|
|
foo = std::move(bar); // no message
|
|
|
|
std::cout << "more foo\n";
|
|
foo.reserve(40); // +foo -foo
|
|
std::cout << "more bar\n";
|
|
bar.reserve(40); // +bar -bar
|
|
|
|
std::cout << "\nFUNCTION\n";
|
|
int bigdata[100];
|
|
auto bigfun = [bigdata]{};
|
|
typedef decltype(bigfun) ft;
|
|
std::cout << "make fizz\n";
|
|
std::function<void()> fizz(std::allocator_arg, diag_alloc<ft>{"fizz"}, bigfun); // +fizz
|
|
std::cout << "another fizz\n";
|
|
std::function<void()> fizz2;
|
|
fizz2 = fizz; // +fizz as if POCCA
|
|
std::cout << "make buzz\n";
|
|
std::function<void()> buzz(std::allocator_arg, diag_alloc<ft>{"buzz"}, bigfun); // +buzz
|
|
std::cout << "move\n";
|
|
buzz = std::move(fizz); // -buzz as if POCMA
|
|
|
|
std::cout << "\nCLEANUP\n";
|
|
}
|
|
</pre></blockquote>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2502"></a>2502. <tt>std::function</tt> does not use <tt>allocator::construct</tt></h3>
|
|
<p><b>Section:</b> 20.9.12.2 [func.wrap.func] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> David Krauss <b>Opened:</b> 2015-05-20 <b>Last modified:</b> 2015-05-21</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
It is impossible for <tt>std::function</tt> to construct its target object using the <tt>construct</tt> method of a type-erased
|
|
allocator. More confusingly, it is possible when the allocator and the target are created at the same time. The means
|
|
of target construction should be specified.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<h3><a name="2503"></a>2503. multiline option should be added to <tt>syntax_option_type</tt></h3>
|
|
<p><b>Section:</b> 28.5.1 [re.synopt] <b>Status:</b> <a href="lwg-active.html#New">New</a>
|
|
<b>Submitter:</b> Nozomu Katō <b>Opened:</b> 2015-05-22 <b>Last modified:</b> 2015-05-22</p>
|
|
<p><b>View other</b> <a href="lwg-index-open.html#re.synopt">active issues</a> in [re.synopt].</p>
|
|
<p><b>View all other</b> <a href="lwg-index.html#re.synopt">issues</a> in [re.synopt].</p>
|
|
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
|
|
<p><b>Discussion:</b></p>
|
|
<p>
|
|
The specification of ECMAScript defines the Multiline property for its
|
|
RegExp and the regular expressions ^ and $ behave differently according
|
|
to the value of this property. Thus, this property should be available
|
|
also in the ECMAScript compatible engine in <tt>std::regex</tt>.
|
|
</p>
|
|
|
|
<p><i>[2015-05-22, Daniel comments]</i></p>
|
|
|
|
<p>
|
|
This issue interacts somewhat with LWG <a href="lwg-active.html#2343">2343</a>.
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>This wording is relative to N4431.</p>
|
|
|
|
<ol>
|
|
<li><p>Change 28.5.1 [re.synopt] as indicated:</p>
|
|
|
|
<blockquote><pre>
|
|
namespace std::regex_constants {
|
|
typedef T1 syntax_option_type;
|
|
constexpr syntax_option_type icase = <i>unspecified</i> ;
|
|
constexpr syntax_option_type nosubs = <i>unspecified</i> ;
|
|
constexpr syntax_option_type optimize = <i>unspecified</i> ;
|
|
constexpr syntax_option_type collate = <i>unspecified</i> ;
|
|
constexpr syntax_option_type ECMAScript = <i>unspecified</i> ;
|
|
constexpr syntax_option_type basic = <i>unspecified</i> ;
|
|
constexpr syntax_option_type extended = <i>unspecified</i> ;
|
|
constexpr syntax_option_type awk = <i>unspecified</i> ;
|
|
constexpr syntax_option_type grep = <i>unspecified</i> ;
|
|
constexpr syntax_option_type egrep = <i>unspecified</i> ;
|
|
<ins>constexpr syntax_option_type multiline = <i>unspecified</i> ;</ins>
|
|
}
|
|
</pre></blockquote>
|
|
</li>
|
|
|
|
<li><p>Change 28.5.2 [re.matchflag], Table 138 — "<tt>syntax_option_type</tt> effects" as indicated:</p>
|
|
|
|
<blockquote>
|
|
<table border="1">
|
|
<caption>Table 138 — <tt>syntax_option_type</tt> effects</caption>
|
|
<tr>
|
|
<th align="center">Element</th>
|
|
<th align="center">Effect(s) if set</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="2" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<ins><tt>multiline</tt></ins>
|
|
</td>
|
|
<td>
|
|
<ins>Specifies that <tt>^</tt> shall match the beginning of a line
|
|
and <tt>$</tt> shall match the end of a line, if the ECMAScript engine is
|
|
selected.</ins>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="2" align="center">
|
|
<tt>…</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
</blockquote>
|
|
|
|
</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
</body>
|
|
</html>
|