diff options
| author | Paolo Carlini <pcarlini@suse.de> | 2005-06-29 12:05:32 +0000 |
|---|---|---|
| committer | Paolo Carlini <paolo@gcc.gnu.org> | 2005-06-29 12:05:32 +0000 |
| commit | 7d31a1f43716b73d356552e8879d061f8f5a3dbc (patch) | |
| tree | dab9eb2abcc32d1520df8f8d7ee818fc98dd9a90 /libstdc++-v3 | |
| parent | c7b802913b04dab9286d61358922517fb266db12 (diff) | |
| download | gcc-7d31a1f43716b73d356552e8879d061f8f5a3dbc.tar.gz | |
lwg-active.html, [...]: Import Revision 37.
2005-06-29 Paolo Carlini <pcarlini@suse.de>
* docs/html/ext/lwg-active.html, lwg-defects.html: Import Revision 37.
* docs/html/ext/howto.html: Adjust.
From-SVN: r101418
Diffstat (limited to 'libstdc++-v3')
| -rw-r--r-- | libstdc++-v3/ChangeLog | 5 | ||||
| -rw-r--r-- | libstdc++-v3/docs/html/ext/howto.html | 6 | ||||
| -rw-r--r-- | libstdc++-v3/docs/html/ext/lwg-active.html | 3563 | ||||
| -rw-r--r-- | libstdc++-v3/docs/html/ext/lwg-defects.html | 1046 |
4 files changed, 1706 insertions, 2914 deletions
diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog index 66ed86e7834..14d29d5c4d7 100644 --- a/libstdc++-v3/ChangeLog +++ b/libstdc++-v3/ChangeLog @@ -1,5 +1,10 @@ 2005-06-29 Paolo Carlini <pcarlini@suse.de> + * docs/html/ext/lwg-active.html, lwg-defects.html: Import Revision 37. + * docs/html/ext/howto.html: Adjust. + +2005-06-29 Paolo Carlini <pcarlini@suse.de> + PR libstdc++/22131 * include/bits/locale_facets.tcc (num_get<>::_M_extract_int, num_get<>::_M_extract_float, money_get<>::_M_extract): diff --git a/libstdc++-v3/docs/html/ext/howto.html b/libstdc++-v3/docs/html/ext/howto.html index 72317f83c5d..0b7b17b59de 100644 --- a/libstdc++-v3/docs/html/ext/howto.html +++ b/libstdc++-v3/docs/html/ext/howto.html @@ -503,19 +503,19 @@ <dd>Replace "new" with "::new". </dd> - <dt><a href="lwg-active.html#409">409</a>: + <dt><a href="lwg-defects.html#409">409</a>: <em>Closing an fstream should clear the error state</em> </dt> <dd>Have <code>open</code> clear the error flags. </dd> - <dt><a href="lwg-active.html#434">434</a>: + <dt><a href="lwg-defects.html#434">434</a>: <em>bitset::to_string() hard to use</em> </dt> <dd>Add three overloads, taking fewer template arguments. </dd> - <dt><a href="lwg-active.html#453">453</a>: + <dt><a href="lwg-defects.html#453">453</a>: <em>basic_stringbuf::seekoff need not always fail for an empty stream</em> </dt> <dd>Don't fail if the next pointer is null and newoff is zero. diff --git a/libstdc++-v3/docs/html/ext/lwg-active.html b/libstdc++-v3/docs/html/ext/lwg-active.html index bb6dd4c1a57..e698dc582d6 100644 --- a/libstdc++-v3/docs/html/ext/lwg-active.html +++ b/libstdc++-v3/docs/html/ext/lwg-active.html @@ -5,11 +5,11 @@ <table> <tbody><tr> <td align="left">Doc. no.</td> -<td align="left">N1762=05-0022</td> +<td align="left">N1830=05-0090</td> </tr> <tr> <td align="left">Date:</td> -<td align="left">2005-03-04</td> +<td align="left">2005-06-24</td> </tr> <tr> <td align="left">Project:</td> @@ -17,10 +17,10 @@ </tr> <tr> <td align="left">Reply to:</td> -<td align="left">Matt Austern <austern@google.com></td> +<td align="left">Howard Hinnant <howard.hinnant@gmail.com></td> </tr> </tbody></table> -<h1>C++ Standard Library Active Issues List (Revision 35)</h1> +<h1>C++ Standard Library Active Issues List (Revision R37)</h1> <p>Reference ISO/IEC IS 14882:1998(E)</p> <p>Also see:</p> <ul> @@ -88,19 +88,28 @@ directory as the issues list files. </p> <h2>Revision History</h2> <ul> +<li>R37: +2005-06 mid-term mailing. +Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>. +</li> +<li>R36: +2005-04 post-Lillehammer mailing. All issues in "ready" status except +for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#454">454</a> were moved to "DR" status, and all issues +previously in "DR" status were moved to "WP". +</li> <li>R35: 2005-03 pre-Lillehammer mailing. </li> <li>R34: -2005-01 mid-term mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#488">488</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#494">494</a>. +2005-01 mid-term mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#488">488</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#494">494</a>. </li> <li>R33: -2004-11 post-Redmond mailing. Reflections actions taken in Redmond. +2004-11 post-Redmond mailing. Reflects actions taken in Redmond. </li> <li>R32: 2004-09 pre-Redmond mailing: reflects new proposed resolutions and new issues received after the 2004-07 mailing. Added -new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#479">479</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#481">481</a>. +new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#479">479</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#481">481</a>. </li> <li>R31: 2004-07 mid-term mailing: reflects new proposed resolutions and @@ -110,10 +119,10 @@ new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html# <li>R30: Post-Sydney mailing: reflects decisions made at the Sydney meeting. Voted all "Ready" issues from R29 into the working paper. -Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#462">462</a>. +Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#462">462</a>. </li> <li>R29: -Pre-Sydney mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#457">457</a>. +Pre-Sydney mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>. </li> <li>R28: Post-Kona mailing: reflects decisions made at the Kona meeting. @@ -142,7 +151,7 @@ Pre-Santa Cruz mailing. Added new issues <a href="http://www.open-std.org/jtc1/ Moved issues in the TC to TC status. </li> <li>R22: -Post-Curaçao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#366">366</a>. +Post-Curaçao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#366">366</a>. </li> <li>R21: Pre-Curaçao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#361">361</a>. @@ -268,7 +277,7 @@ post-Dublin mailing. Updated to reflect LWG and full committee actions in Dublin. (99-0016/N1193, 21 Apr 99) </li> <li>R7: -pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#131">131</a>, +pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#131">131</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#132">132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#133">133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#135">135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a> (31 Mar 99) @@ -472,73 +481,17 @@ upon overflow. We considered three options based on this:</p> <p>Straw poll: (1) 5; (2) 0; (3) 8.</p> -<p><b>Further discussion from Santa Cruz:</b></p> - -<p>There was some discussion of what the intent of our error - reporting mechanism was. There was general agreement on the - following principles:</p> -<ul> -<li>We want to convert strings to numbers in the same way as the - C <tt>strto*</tt> functions do. The same things that those - functions would consider errors, we consider errors.</li> -<li>Overflow is an error. Floating-point underflow is not an error. - 1.e-9999999, for example, should be treated as 0. (A negative - number whose magnitude is too large is still overflow, and is just - the same error as a positive number whose magnitude is too large. - Finally, <tt>strtoul</tt> already specifies what happens if you - try to convert a sequence beginning with a minus sign into an - unsigned value.)</li> -<li>Our mechanism for reporting errors is to set failbit. Our - mechanism is not errno. Nothing in the standard should - require or imply that streams or facets ever set errno. - (Even if some implementations might have that effect.) </li> -</ul> - -<p>The crux of the disagreement was that some people, but not all, - believed that the design was also based on a fourth principle: - whenever converstion fails and failbit is set, nothing is to be - extracted and the value of the variable being extracted into is - guaranteed to be unchanged.</p> - -<p>Some people believe that upon overflow, an implementation should - "extract" a special value that allows the user to tell that it was - overflow instead of some other kind of error. Straw poll: 1 person - believed the standard should require that, 2 thought it should - forbid it, and 6 thought the standard should allow but not require - it.</p> <p><b>Proposed resolution:</b></p> -<p>typo: 22.2.2.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>, para 2, bullet 3. Strike "in." from -the end.</p> - -<p>Change 22.2.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.nm.put"> [lib.locale.nm.put]</a>, para 11, bullet 2 from:</p> -<blockquote> -The sequence of chars accumulated in stage 2 would have -caused scanf to report an input failure. ios_base::failbit is -assigned to err. -</blockquote> -<p>to:</p> -<blockquote> -The sequence of chars accumulated in stage 2 would have -caused scanf to report an input failure or to store a value -outside the range representable by val. ios_base::failbit is -assigned to err. -</blockquote> - -<p><i>[PJP provided wording. this treats overflow or underflow the same -as an ill-formed field. It's not exactly the consensus from Santa -Cruz, but he thinks it's the simplest and most robust rule and that it -corresponds to widespread common practice.]</i></p> - -<p><i>[Kona: Wording here still isn't quite right, partly because it -refers to scanf and the scanf description of error conditions is -murky. The LWG had to do a very close reading of scanf in an attempt -to figure out what this proposed resolution means. General agreement -that the correct solution: (1) should not refer to scanf behavior, (2) -should not set errno, (3) should allow users who care to figure out -what kind of error happened. Martin will provide wording, Howard may -help.]</i></p> +<p>Discussed at Lillehammer. General outline of what we want the + solution to look like: we want to say that overflow is an error, and + provide a way to distinguish overflow from other kinds of errors. + Choose candidate field the same way scanf does, but don't describe + the rest of the process in terms of format. If a finite input field + is too large (positive or negative) to be represented as a finite + value, then set failbit and assign the nearest representable value. + Bill will provide wording.</p> <hr> <a name="96"><h3>96. Vector<bool> is not a container</h3></a><p><b>Section:</b> 23.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.bool"> [lib.vector.bool]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p> @@ -591,147 +544,18 @@ my dead body. This resolution was mentioned in the LWG report to the full committee, where several additional committee members indicated over-my-dead-body positions.]</i></p> -<p><i>[Tokyo: Not discussed by the full LWG; no one claimed new -insights and so time was more productively spent on other issues. In -private discussions it was asserted that requirements for any solution -include 1) Increasing the full committee's understanding of the -problem, and 2) providing compiler vendors, authors, teachers, and of -course users with specific suggestions as to how to apply the eventual -solution.]</i></p> - -<p><i>[Redmond: briefly discussed, since there are options for C++0x - that weren't reasonable for TC1. Two options were discussed. (1) - deprecate std::vector<bool> and introduce std::bit_vector. Then - gradually, over a period of years, we could reintroduce - std::vector<bool> but this time as an ordinary vector. (2) Change - iterarator and container requirements so that vector<bool> will - be a fully conforming container. These options are not mutually - exclusive.]</i></p> -<hr> -<a name="130"><h3>130. Return type of container::erase(iterator) differs for associative containers</h3></a><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2 Mar 1999</p> -<p>Table 67 (23.1.1) says that container::erase(iterator) returns an -iterator. Table 69 (23.1.2) says that in addition to this requirement, -associative containers also say that container::erase(iterator) -returns void. That's not an addition; it's a change to the -requirements, which has the effect of making associative containers -fail to meet the requirements for containers.</p> -<p><b>Proposed resolution:</b></p> - -<p> -In 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, in Table 69 Associative container -requirements, change the return type of <tt>a.erase(q)</tt> from -<tt>void</tt> to <tt>iterator</tt>. Change the -assertion/not/pre/post-condition from "erases the element pointed to -by <tt>q</tt>" to "erases the element pointed to by <tt>q</tt>. -Returns an iterator pointing to the element immediately following q -prior to the element being erased. If no such element exists, a.end() -is returned." -</p> - -<p> -In 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, in Table 69 Associative container -requirements, change the return type of <tt>a.erase(q1, q2)</tt> -from <tt>void</tt> to <tt>iterator</tt>. Change the -assertion/not/pre/post-condition from "erases the elements in the -range <tt>[q1, q2)</tt>" to "erases the elements in the range <tt>[q1, -q2)</tt>. Returns q2." -</p> - -<p> -In 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a>, in the <tt>map</tt> class synopsis; and -in 23.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.multimap"> [lib.multimap]</a>, in the <tt>multimap</tt> class synopsis; and -in 23.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.set"> [lib.set]</a>, in the <tt>set</tt> class synopsis; and -in 23.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.multiset"> [lib.multiset]</a>, in the <tt>multiset</tt> class synopsis: -change the signature of the first <tt>erase</tt> overload to -</p> -<pre> iterator erase(iterator position); -</pre> -<p>and change the signature of the third <tt>erase</tt> overload to</p> -<pre> iterator erase(iterator first, iterator last); -</pre> - - -<p><i>[Pre-Kona: reopened at the request of Howard Hinnant]</i></p> - -<p><i>[Post-Kona: the LWG agrees the return type should be -<tt>iterator</tt>, not <tt>void</tt>. (Alex Stepanov agrees too.) -Matt provided wording.]</i></p> - -<p><i>[ - Sydney: the proposed wording went in the right direction, but it - wasn't good enough. We want to return an iterator from the range form - of erase as well as the single-iterator form. Also, the wording is - slightly different from the wording we have for sequences; there's no - good reason for having a difference. Matt provided new wording, - which we will review at the next meeting. -]</i></p> - -<hr> -<a name="197"></a><h3><a name="197">197. max_size() underspecified</a></h3><p><b>Section:</b> 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>, 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 21 Oct 1999</p> -<p>Must the value returned by max_size() be unchanged from call to call? </p> - -<p>Must the value returned from max_size() be meaningful? </p> - -<p>Possible meanings identified in lib-6827: </p> - -<p>1) The largest container the implementation can support given "best -case" conditions - i.e. assume the run-time platform is "configured to -the max", and no overhead from the program itself. This may possibly -be determined at the point the library is written, but certainly no -later than compile time.<br> -<br> -2) The largest container the program could create, given "best case" -conditions - i.e. same platform assumptions as (1), but take into -account any overhead for executing the program itself. (or, roughly -"storage=storage-sizeof(program)"). This does NOT include any resource -allocated by the program. This may (or may not) be determinable at -compile time.<br> -<br> -3) The largest container the current execution of the program could -create, given knowledge of the actual run-time platform, but again, -not taking into account any currently allocated resource. This is -probably best determined at program start-up.<br> -<br> -4) The largest container the current execution program could create at -the point max_size() is called (or more correctly at the point -max_size() returns :-), given it's current environment (i.e. taking -into account the actual currently available resources). This, -obviously, has to be determined dynamically each time max_size() is -called. </p> -<p><b>Proposed resolution:</b></p> -<p>Change 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> table 32 max_size() wording from:<br> -<br> - the largest value that can meaningfully be -passed to X::allocate<br> -to:<br> - the value of the largest constant expression -(5.19 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/expr.html#expr.const"> [expr.const]</a>) that could ever meaningfully be passed to X::allocate</p> - -<p> -Change 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> table 65 max_size() wording from:<br> -<br> - size() of the largest possible container.<br> -to:<br> - the value of the largest constant expression -(5.19 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/expr.html#expr.const"> [expr.const]</a>) that could ever meaningfully be returned by X::size(). -</p> - -<p><i>[Kona: The LWG informally discussed this and asked Andy Sawyer to submit -an issue.]</i></p> +<p>Discussed at Lillehammer. General agreement that we should + deprecate vector<bool> and introduce this functionality under + a different name, e.g. bit_vector. This might make it possible to + remove the vector<bool> specialization in the standard that comes + after C++0x. There was also a suggestion that + in C++0x we could additional say that it's implementation defined + whether vector<bool> refers to the specialization or to the + primary template, but there wasn't general agreement that this was a + good idea.</p> -<p><i>[Tokyo: The LWG believes (1) above is the intended meaning.]</i></p> +<p>We need a paper for the new bit_vector class.</p> -<p><i>[Post-Tokyo: Beman Dawes supplied the above resolution at the -request of the LWG. 21.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.capacity"> [lib.string.capacity]</a> was not changed because it -references max_size() in 23.1. The term "compile-time" was -avoided because it is not defined anywhere in the standard (even -though it is used several places in the library clauses).]</i></p> - -<p><i>[Copenhagen: Exactly what <tt>max_size</tt> means is still -unclear. It may have a different meaning as a container member -function than as an allocator member function. For the latter, -it is probably best thought of as an architectural limit. -Nathan will provide new wording.]</i></p> <hr> <a name="201"><h3>201. Numeric limits terminology wrong</h3></a><p><b>Section:</b> 18.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.limits"> [lib.limits]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Stephen Cleary <b>Date:</b> 21 Dec 1999</p> <p> @@ -742,91 +566,10 @@ pointers are scalar types, neither of which should have specializations of numeric_limits. </p> <p><b>Proposed resolution:</b></p> -<p>Change 18.2 [lib.support.limits] para 1 from:</p> -<blockquote> - -<p> The headers <limits>, <climits>, and <cfloat> -supply characteristics of implementation-dependent fundamental types -(3.9.1).</p> -</blockquote> - -<p>to:</p> -<blockquote> - -<p> The headers <limits>, <climits>, and <cfloat> -supply characteristics of implementation-dependent arithmetic types -(3.9.1).</p> -</blockquote> - -<p>Change 18.2.1 [lib.limits] para 1 from:</p> -<blockquote> - -<p> The numeric_limits component provides a C++ program with -information about various properties of the implementation's -representation of the fundamental -types.</p> -</blockquote> - -<p>to:</p> -<blockquote> - -<p> The numeric_limits component provides a C++ program with -information about various properties of the implementation's -representation of the arithmetic -types.</p> -</blockquote> - -<p>Change 18.2.1 [lib.limits] para 2 from:</p> -<blockquote> - -<p> Specializations shall be provided for each fundamental type. . .</p> -</blockquote> - -<p>to:</p> -<blockquote> - -<p> Specializations shall be provided for each arithmetic type. . .</p> -</blockquote> - -<p>Change 18.2.1 [lib.limits] para 4 from:</p> -<blockquote> - -<p> Non-fundamental standard types. . .</p> -</blockquote> - -<p>to:</p> -<blockquote> - -<p> Non-arithmetic standard types. . .</p> -</blockquote> - -<p>Change 18.2.1.1 [lib.numeric.limits] para 1 from:</p> -<blockquote> - -<p> The member is_specialized makes it possible to distinguish between -fundamental types, which have specializations, and non-scalar types, -which -do not.</p> -</blockquote> - -<p>to:</p> -<blockquote> - -<p> The member is_specialized makes it possible to distinguish between -arithmetic types, which have specializations, and non-arithmetic types, -which do not.</p> -</blockquote> - -<p><i>[post-Toronto: The opinion of the LWG is that the wording in the -standard, as well as the wording of the proposed resolution, is -flawed. The term "arithmetic types" is well defined in C -and C++, and it is not clear that the term is being used correctly. -It is also not clear that the term "implementation -dependent" has any useful meaning in this context. The biggest -problem is that numeric_limits seems to be intended both for built-in -types and for user-defined types, and the standard doesn't make it -clear how numeric_limits applies to each of those cases. A wholesale -review of numeric_limits is needed. A paper would be welcome.]</i></p> +<p><i>[Lillehammer: it remains true that numeric_limits is using + imprecise language. However, none of the proposals for changed + wording are clearer. A redesign of numeric_limits is needed, but this + is more a task than an open issue.]</i></p> <hr> <a name="233"><h3>233. Insertion hints in associative containers</h3></a><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 30 Apr 2000</p> <p> @@ -923,8 +666,20 @@ enough to make the detailed semantics hard to satisfy."]</i></p> <p><i>[Curaçao: Nathan should give us the alternative wording he suggests so the LWG can decide between the two options.]</i></p> +<p><i>[Lillehammer: The LWG previously rejected the more detailed + semantics, because it seemed more loike a new feature than like + defect fixing. We're now more sympathetic to it, but we (especially + Bill) are still worried about performance. N1780 describes a naive + algorithm, but it's not clear whether there is a non-naive + implementation. Is it possible to implement this as efficently as + the current version of insert?]</i></p> + +<p><i>[Post Lillehammer: N1780 updated in post meeting mailing with +feedback from Lillehammer with more information regarding performance. +]</i></p> + <hr> -<a name="247"><h3>247. <tt>vector</tt>, <tt>deque::insert</tt> complexity</h3></a><p><b>Section:</b> 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Lisa Lippincott <b>Date:</b> 06 June 2000</p> +<a name="247"><h3>247. <tt>vector</tt>, <tt>deque::insert</tt> complexity</h3></a><p><b>Section:</b> 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Lisa Lippincott <b>Date:</b> 06 June 2000</p> <p>Paragraph 2 of 23.2.4.3 [lib.vector.modifiers] describes the complexity of <tt>vector::insert</tt>:</p> @@ -944,17 +699,6 @@ of <tt>vector::insert</tt>:</p> it requires that an arbitrary number of elements can be added at the end of a <tt>vector</tt> in constant time.</p> -<p>At the risk of strengthening the requirement, I suggest simply</p> - - <blockquote> - Complexity: The complexity is linear in the number of elements - inserted plus the distance to the end of the vector. - </blockquote> - -<p>For input iterators, one may achieve this complexity by first -inserting at the end of the <tt>vector</tt>, and then using -<tt>rotate</tt>.</p> - <p>I looked to see if <tt>deque</tt> had a similar problem, and was surprised to find that <tt>deque</tt> places no requirement on the complexity of inserting multiple elements (23.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.modifiers"> [lib.deque.modifiers]</a>, @@ -969,8 +713,19 @@ paragraph 3):</p> takes constant time and causes a single call to the copy constructor of T. </blockquote> +<p><b>Proposed resolution:</b></p> -<p>I suggest:</p> +<p>Change Paragraph 2 of 23.2.4.3 [lib.vector.modifiers] to</p> + <blockquote> + Complexity: The complexity is linear in the number of elements + inserted plus the distance to the end of the vector. + </blockquote> + + <p><i>[For input iterators, one may achieve this complexity by first + inserting at the end of the <tt>vector</tt>, and then using + <tt>rotate</tt>.]</i></p> + +<p>Change 23.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.modifiers"> [lib.deque.modifiers]</a>, paragraph 3, to:</p> <blockquote> Complexity: The complexity is linear in the number of elements @@ -979,19 +734,13 @@ paragraph 3):</p> beginning or the end of a deque causes a single call to the copy constructor of T. </blockquote> -<p><b>Proposed resolution:</b></p> -<p><i>[Toronto: It's agreed that there is a defect in complexity of -multi-element insert for vector and deque. For vector, the complexity -should probably be something along the lines of <tt>c<sub>1</sub> * N -+ c<sub>2</sub> * distance(i, end())</tt>. However, there is some -concern about whether it is reasonable to amortize away the copies -that we get from a reallocation whenever we exceed the vector's -capacity. For deque, the situation is somewhat less clear. Deque is -notoriously complicated, and we may not want to impose complexity -requirements that would imply any implementation technique more -complicated than a while loop whose body is a single-element -insert.]</i></p> +<p><b>Rationale:</b></p> +<p>This is a real defect, and proposed resolution fixes it: some + complexities aren't specified that should be. This proposed + resolution does constrain deque implementations (it rules out the + most naive possible implementations), but the LWG doesn't see a + reason to permit that implementation.</p> <hr> <a name="254"><h3>254. Exception types in clause 19 are constructed from <tt>std::string</tt> </h3></a><p><b>Section:</b> 19.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-diagnostics.html#lib.std.exceptions"> [lib.std.exceptions]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 01 Aug 2000</p> @@ -1137,7 +886,7 @@ intended here is that the copy constructors can't fail.</p> <hr> <a name="258"><h3>258. Missing allocator requirement</h3></a><p><b>Section:</b> 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 22 Aug 2000</p> <p> -From lib-7752: +>From lib-7752: </p> <p> @@ -1204,7 +953,7 @@ the second line from the bottom in table 32 already implies the desired property. This issue should be considered in light of other issues related to allocator instances.]</i></p> <hr> -<a name="280"><h3>280. Comparison of reverse_iterator to const reverse_iterator</h3></a><p><b>Section:</b> 24.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iterators"> [lib.reverse.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Steve Cleary <b>Date:</b> 27 Nov 2000</p> +<a name="280"><h3>280. Comparison of reverse_iterator to const reverse_iterator</h3></a><p><b>Section:</b> 24.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iterators"> [lib.reverse.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Steve Cleary <b>Date:</b> 27 Nov 2000</p> <p> This came from an email from Steve Cleary to Fergus in reference to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed @@ -1265,6 +1014,11 @@ make this change without implementation experience. It may be desirable to provide this feature in a different way. ]</i></p> +<p><i>[ +Lillehammer: We now have implementation experience, and agree that +this solution is safe and correct. +]</i></p> + <hr> <a name="290"><h3>290. Requirements to for_each and its function object</h3></a><p><b>Section:</b> 25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 03 Jan 2001</p> <p>The specification of the for_each algorithm does not have a @@ -1292,25 +1046,14 @@ understand that there are restrictions even if the description of the algorithm does not say so. </p> <p><b>Proposed resolution:</b></p> -<p>Add a "Requires" section to section 25.1.1 similar to those -proposed for transform and the numeric algorithms (see issue -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#242">242</a>): -</p> - -<blockquote> - -2- <b>Requires</b>: In the range [first, last], f shall not invalidate - iterators or subranges. -</blockquote> - -<p><i>[Copenhagen: The LWG agrees that a function object passed to an -algorithm should not invalidate iterators in the range that the -algorithm is operating on. The LWG believes that this should be a -blanket statement in Clause 25, not just a special requirement for -<tt>for_each</tt>. -]</i></p> +<p><i>[Lillehammer: This is more general than for_each. We don't want + the function object in transform invalidiating iterators + either. There should be a note somewhere in clause 17 (17, not 25) + saying that user code operating on a range may not invalidate + iterators unless otherwise specified. Bill will provide wording.]</i></p> <hr> -<a name="294"></a><h3><a name="294">294. User defined macros and standard headers</a></h3><p><b>Section:</b> 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> James Kanze <b>Date:</b> 11 Jan 2001</p> +<a name="294"><h3>294. User defined macros and standard headers</h3></a><p><b>Section:</b> 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> James Kanze <b>Date:</b> 11 Jan 2001</p> <p>Paragraph 2 of 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a> reads: "A translation unit that includes a header shall not contain any macros that define names declared in that header." As I read this, it @@ -1330,15 +1073,32 @@ headers. The phrase would be perfectly appropriate for C, for example. In light of 17.4.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.headers"> [lib.res.on.headers]</a> paragraph 1, however, it isn't stringent enough.</p> <p><b>Proposed resolution:</b></p> -<p>In paragraph 2 of 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a>, change "A -translation unit that includes a header shall not contain any macros -that define names declared in that header." to "A -translation unit that includes a header shall not contain any macros -that define names declared in any standard header."</p> +<p>For 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a>, replace the current wording, which reads:</p> +<blockquote> + <p>Each name defined as a macro in a header is reserved to the + implementation for any use if the translation unit includes + the header.168)</p> -<p><i>[Copenhagen: the general idea is clearly correct, but there is -concern about making sure that the two paragraphs in 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a> remain consistent. Nathan will provide new -wording.]</i></p> + <p>A translation unit that includes a header shall not contain any + macros that define names declared or defined in that header. Nor shall + such a translation unit define macros for names lexically + identical to keywords.</p> + + <p>168) It is not permissible to remove a library macro definition by + using the #undef directive.</p> +</blockquote> + +<p>with the wording:</p> + +<blockquote> + <p>A translation unit that includes a standard library header shall not + #define or #undef names declared in any standard library header.</p> + + <p>A translation unit shall not #define or #undef names lexically + identical to keywords.</p> +</blockquote> + +<p><i>[Lillehammer: Beman provided new wording]</i></p> <hr> <a name="299"><h3>299. Incorrect return types for iterator dereference</h3></a><p><b>Section:</b> 24.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.bidirectional.iterators"> [lib.bidirectional.iterators]</a>, 24.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> John Potter <b>Date:</b> 22 Jan 2001</p> @@ -1440,247 +1200,11 @@ with a return type of convertible to <tt>T</tt> and operational semantics of <tt>*(a + n) = t</tt>. </p> -<hr> -<a name="309"><h3>309. Does sentry catch exceptions?</h3></a><p><b>Section:</b> 27.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.format"> [lib.iostream.format]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 19 Mar 2001</p> -<p> -The descriptions of the constructors of basic_istream<>::sentry -(27.6.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>) and basic_ostream<>::sentry -(27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>) do not explain what the functions do in -case an exception is thrown while they execute. Some current -implementations allow all exceptions to propagate, others catch them -and set ios_base::badbit instead, still others catch some but let -others propagate. -</p> - -<p> -The text also mentions that the functions may call setstate(failbit) -(without actually saying on what object, but presumably the stream -argument is meant). That may have been fine for -basic_istream<>::sentry prior to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>, since -the function performs an input operation which may fail. However, -issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a> amends 27.6.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>, p2 to -clarify that the function should actually call setstate(failbit | -eofbit), so the sentence in p3 is redundant or even somewhat -contradictory. -</p> - -<p> -The same sentence that appears in 27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>, p3 -doesn't seem to be very meaningful for basic_istream<>::sentry -which performs no input. It is actually rather misleading since it -would appear to guide library implementers to calling -setstate(failbit) when os.tie()->flush(), the only called function, -throws an exception (typically, it's badbit that's set in response to -such an event). -</p> - -<p><b>Additional comments from Martin, who isn't comfortable with the - current proposed resolution</b> (see c++std-lib-11530)</p> - -<p> -The istream::sentry ctor says nothing about how the function -deals with exemptions (27.6.1.1.2, p1 says that the class is -responsible for doing "exception safe"(*) prefix and suffix -operations but it doesn't explain what level of exception -safety the class promises to provide). The mockup example -of a "typical implementation of the sentry ctor" given in -27.6.1.1.2, p6, removed in ISO/IEC 14882:2003, doesn't show -exception handling, either. Since the ctor is not classified -as a formatted or unformatted input function, the text in -27.6.1.1, p1 through p4 does not apply. All this would seem -to suggest that the sentry ctor should not catch or in any -way handle exceptions thrown from any functions it may call. -Thus, the typical implementation of an istream extractor may -look something like [1]. -</p> - -<p> -The problem with [1] is that while it correctly sets ios::badbit -if an exception is thrown from one of the functions called from -the sentry ctor, if the sentry ctor reaches EOF while extracting -whitespace from a stream that has eofbit or failbit set in -exceptions(), it will cause an ios::failure to be thrown, which -will in turn cause the extractor to set ios::badbit. -</p> - -<p> -The only straightforward way to prevent this behavior is to -move the definition of the sentry object in the extractor -above the try block (as suggested by the example in 22.2.8, -p9 and also indirectly supported by 27.6.1.3, p1). See [2]. -But such an implementation will allow exceptions thrown from -functions called from the ctor to freely propagate to the -caller regardless of the setting of ios::badbit in the stream -object's exceptions(). -</p> - -<p> -So since neither [1] nor [2] behaves as expected, the only -possible solution is to have the sentry ctor catch exceptions -thrown from called functions, set badbit, and propagate those -exceptions if badbit is also set in exceptions(). (Another -solution exists that deals with both kinds of sentries, but -the code is non-obvious and cumbersome -- see [3].) -</p> - -<p> -Please note that, as the issue points out, current libraries -do not behave consistently, suggesting that implementors are -not quite clear on the exception handling in istream::sentry, -despite the fact that some LWG members might feel otherwise. -(As documented by the parenthetical comment here: -http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1480.html#309) -</p> - -<p> -Also please note that those LWG members who in Copenhagen -felt that "a sentry's constructor should not catch exceptions, -because sentries should only be used within (un)formatted input -functions and that exception handling is the responsibility of -those functions, not of the sentries," as noted here -http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1310.html#309 -would in effect be either arguing for the behavior described -in [1] or for extractors implemented along the lines of [3]. -</p> - -<p> -The original proposed resolution (Revision 25 of the issues -list) clarifies the role of the sentry ctor WRT exception -handling by making it clear that extractors (both library -or user-defined) should be implemented along the lines of -[2] (as opposed to [1]) and that no exception thrown from -the callees should propagate out of either function unless -badbit is also set in exceptions(). -</p> - - -<p>[1] Extractor that catches exceptions thrown from sentry:</p> - -<blockquote> -<pre>struct S { long i; }; - -istream& operator>> (istream &strm, S &s) -{ - ios::iostate err = ios::goodbit; - try { - const istream::sentry guard (strm, false); - if (guard) { - use_facet<num_get<char> >(strm.getloc ()) - .get (istreambuf_iterator<char>(strm), - istreambuf_iterator<char>(), - strm, err, s.i); - } - } - catch (...) { - bool rethrow; - try { - strm.setstate (ios::badbit); - rethrow = false; - } - catch (...) { - rethrow = true; - } - if (rethrow) - throw; - } - if (err) - strm.setstate (err); - return strm; -} -</pre> -</blockquote> - -<p>[2] Extractor that propagates exceptions thrown from sentry:</p> - -<blockquote> -<pre>istream& operator>> (istream &strm, S &s) -{ - istream::sentry guard (strm, false); - if (guard) { - ios::iostate err = ios::goodbit; - try { - use_facet<num_get<char> >(strm.getloc ()) - .get (istreambuf_iterator<char>(strm), - istreambuf_iterator<char>(), - strm, err, s.i); - } - catch (...) { - bool rethrow; - try { - strm.setstate (ios::badbit); - rethrow = false; - } - catch (...) { - rethrow = true; - } - if (rethrow) - throw; - } - if (err) - strm.setstate (err); - } - return strm; -} -</pre> -</blockquote> - -<p> -[3] Extractor that catches exceptions thrown from sentry -but doesn't set badbit if the exception was thrown as a -result of a call to strm.clear(). -</p> - -<blockquote> -<pre>istream& operator>> (istream &strm, S &s) -{ - const ios::iostate state = strm.rdstate (); - const ios::iostate except = strm.exceptions (); - ios::iostate err = std::ios::goodbit; - bool thrown = true; - try { - const istream::sentry guard (strm, false); - thrown = false; - if (guard) { - use_facet<num_get<char> >(strm.getloc ()) - .get (istreambuf_iterator<char>(strm), - istreambuf_iterator<char>(), - strm, err, s.i); - } - } - catch (...) { - if (thrown && state & except) - throw; - try { - strm.setstate (ios::badbit); - thrown = false; - } - catch (...) { - thrown = true; - } - if (thrown) - throw; - } - if (err) - strm.setstate (err); - - return strm; -} -</pre> -</blockquote> - +<p><i>[Lillehammer: Real problem, but should be addressed as part of + iterator redesign]</i></p> -<p><b>Proposed resolution:</b></p> -<p>Remove the last sentence of 27.6.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a> p5 (but not - the footnote, which should be moved to the preceding sentence).</p> -<p>Remove the last sentence of 27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a> p3 (but not - the footnote, which should be moved to the preceding sentence).</p> -<p><b>Rationale:</b></p> -<p>The LWG feels that no clarification of EH policy is necessary: the - standard is precise about which operations sentry's constructor - performs, and about which of those operations can throw. However, the - sentence at the end should be removed because it's redundant.</p> <hr> -<a name="342"><h3>342. seek and eofbit</h3></a><p><b>Section:</b> 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 09 Oct 201</p> +<a name="342"><h3>342. seek and eofbit</h3></a><p><b>Section:</b> 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 09 Oct 2001</p> <p>I think we have a defect.</p> <p>According to lwg issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a> which is now a dr, the @@ -1742,167 +1266,32 @@ modes than actual input. If we do really mean that it's unformatted input, it should behave the same way as other unformatted input. On the other hand, "principle of least surprise" is that seeking from EOF ought to be OK.</p> - -<p>Dietmar: nothing should depend on eofbit. Eofbit should only be -examined by the user to determine why something failed.</p> - -<p><i>[Taken from c++std-lib-8873, c++std-lib-8874, c++std-lib-8876]</i></p> - <p><b>Proposed resolution:</b></p> -<p><i>[Santa Cruz: On the one hand, it would clearly be silly to seek - to a non-EOF position without resetting eofbit. On the other hand, - having seek clear eofbit explicitly would set a major precedent: - there is currently <i>no</i> place where any of the flags are reset - without the user explicitly asking for them to be. This is the tip - of a general problem, that the various flags are stickier than many - users might expect. Bill, Gaby, and Howard will discuss this issue - and propose a resolution.]</i></p> - -<hr> -<a name="356"><h3>356. Meaning of ctype_base::mask enumerators</h3></a><p><b>Section:</b> 22.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 23 Jan 2002</p> - -<p>What should the following program print?</p> - -<pre> #include <locale> - #include <iostream> - - class my_ctype : public std::ctype<char> - { - typedef std::ctype<char> base; - public: - my_ctype(std::size_t refs = 0) : base(my_table, false, refs) - { - std::copy(base::classic_table(), base::classic_table() + base::table_size, - my_table); - my_table[(unsigned char) '_'] = (base::mask) (base::print | base::space); - } - private: - mask my_table[base::table_size]; - }; - - int main() - { - my_ctype ct; - std::cout << "isspace: " << ct.is(std::ctype_base::space, '_') << " " - << "isalpha: " << ct.is(std::ctype_base::alpha, '_') << std::endl; - } -</pre> - -<p>The goal is to create a facet where '_' is treated as whitespace.</p> - -<p>On gcc 3.0, this program prints "isspace: 1 isalpha: 0". On -Microsoft C++ it prints "isspace: 1 isalpha: 1".</p> - -<p> -I believe that both implementations are legal, and the standard does not -give enough guidance for users to be able to use std::ctype's -protected interface portably.</p> - -<p> -The above program assumes that ctype_base::mask enumerators like -<tt>space</tt> and <tt>print</tt> are disjoint, and that the way to -say that a character is both a space and a printing character is to or -those two enumerators together. This is suggested by the "exposition -only" values in 22.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a>, but it is nowhere specified in -normative text. An alternative interpretation is that the more -specific categories subsume the less specific. The above program -gives the results it does on the Microsoft compiler because, on that -compiler, <tt>print</tt> has all the bits set for each specific -printing character class. -</p> - -<p>From the point of view of std::ctype's public interface, there's no -important difference between these two techniques. From the point of -view of the protected interface, there is. If I'm defining a facet -that inherits from std::ctype<char>, I'm the one who defines the -value that table()['a'] returns. I need to know what combination of -mask values I should use. This isn't so very esoteric: it's exactly -why std::ctype has a protected interface. If we care about users -being able to write their own ctype facets, we have to give them a -portable way to do it. -</p> - -<p> -Related reflector messages: -lib-9224, lib-9226, lib-9229, lib-9270, lib-9272, lib-9273, lib-9274, -lib-9277, lib-9279. -</p> - -<p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a> is related, but not identical. The -proposed resolution if issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a> says that -ctype_base::mask must be a bitmask type. It does not say that the -ctype_base::mask elements are bitmask elements, so it doesn't -directly affect this issue.</p> - -<p>More comments from Benjamin Kosnik, who believes that -that C99 compatibility essentially requires what we're -calling option 1 below.</p> - +<p>Change 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> to:</p> <blockquote> -<pre>I think the C99 standard is clear, that isspace -> !isalpha. --------- - -#include <locale> -#include <iostream> - -class my_ctype : public std::ctype<char> -{ -private: - typedef std::ctype<char> base; - mask my_table[base::table_size]; - -public: - my_ctype(std::size_t refs = 0) : base(my_table, false, refs) - { - std::copy(base::classic_table(), base::classic_table() + base::table_size, - my_table); - mask both = base::print | base::space; - my_table[static_cast<mask>('_')] = both; - } -}; - -int main() -{ - using namespace std; - my_ctype ct; - cout << "isspace: " << ct.is(ctype_base::space, '_') << endl; - cout << "isprint: " << ct.is(ctype_base::print, '_') << endl; - - // ISO C99, isalpha iff upper | lower set, and !space. - // 7.5, p 193 - // -> looks like g++ behavior is correct. - // 356 -> bitmask elements are required for ctype_base - // 339 -> bitmask type required for mask - cout << "isalpha: " << ct.is(ctype_base::alpha, '_') << endl; -} -</pre> +Behaves as an unformatted input function (as described in 27.6.1.3, +paragraph 1), except that it does not count the number of characters +extracted, does not affect the value returned by subsequent calls to +gcount(), and does not examine the value returned by the sentry +object. After constructing a sentry object, if <tt>fail() != +true</tt>, executes <tt>rdbuf()->pubseekpos(pos)</tt>. In +case of success, the function calls clear(). +In case of failure, the function calls <tt>setstate(failbit)</tt> +(which may throw <tt>ios_base::failure</tt>). </blockquote> -<p><b>Proposed resolution:</b></p> -<p>Informally, we have three choices:</p> -<ol> -<li>Require that the enumerators are disjoint (except for alnum and -graph)</li> -<li>Require that the enumerators are not disjoint, and specify which -of them subsume which others. (e.g. mandate that lower includes alpha -and print)</li> -<li>Explicitly leave this unspecified, which the result that the above -program is not portable.</li> -</ol> - -<p>Either of the first two options is just as good from the standpoint -of portability. Either one will require some implementations to -change.</p> - -<p><i>[ -More discussion is needed. Nobody likes option 3. Options 1 and 2 -are both controversial, 2 perhaps less so. Benjamin thinks that -option 1 is required for C99 compatibility. -]</i></p> +<p><i>[Lillehammer: Matt provided wording.]</i></p> +<p><b>Rationale:</b></p> +<p>In C, fseek does clear EOF. This is probably what most users would + expect. We agree that having eofbit set should not deter a seek, + and that a successful seek should clear eofbit. Note + that <tt>fail()</tt> is true only if <tt>failbit</tt> + or <tt>badbit</tt> is set, so using <tt>!fail()</tt>, rather + than <tt>good()</tt>, satisfies this goal.</p> <hr> -<a name="362"><h3>362. bind1st/bind2nd type safety</h3></a><p><b>Section:</b> 20.3.6.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Andrew Demkin <b>Date:</b> 26 Apr 2002</p> +<a name="362"><h3>362. bind1st/bind2nd type safety</h3></a><p><b>Section:</b> 20.3.6.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Andrew Demkin <b>Date:</b> 26 Apr 2002</p> <p> The definition of bind1st() (20.3.6.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a>) can result in the construction of an unsafe binding between incompatible pointer @@ -1939,156 +1328,18 @@ as a reinterpret_cast, thus masking the error. <p>The problem and proposed change also apply to 20.3.6.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.bind.2nd"> [lib.bind.2nd]</a>.</p> <p><b>Proposed resolution:</b></p> -<p> -The simplest and most localized change to prevent such errors is to -require bind1st() use a static_cast expression rather than the -functional-style conversion; that is, have bind1st() return: -</p> -<pre> binder1st<Operation>( op, - static_cast<typename Operation::first_argument_type>(x)). -</pre> - -<p> -A more agressive solution is to change the semantics of -functional-style conversions to not permit a reinterpret_cast. For -contexts that require the semantics of reinterpret_cast, the language -may want to require the use of an explicit cast expression such as -'(T) x' or 'reinterpret_cast<T>(x)' and limit the behavior of -the functional notation to match statically-checked and standard -conversions (as defined by 5.2.9 and 4.10, etc.). Although changing -the semantics of functional-style conversions may seem drastic and -does have language-wide ramifications, it has the benefit of better -unifying the conversion rules for user defined types and built-in -types, which can be especially important for generic template -programming. -</p> - -<p><i>[Santa Cruz: it's clear that a function-style cast is - wrong. Maybe a static cast would be better, or maybe no cast at - all. Jeremy will check with the original author of this part - of the Standard and will see what the original intent was.]</i></p> -<hr> -<a name="366"><h3>366. Excessive const-qualification</h3></a><p><b>Section:</b> 27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Walter Brown, Marc Paterno <b>Date:</b> 10 May 2002</p> -<p> -The following member functions are declared const, yet return non-const -pointers. We believe they are should be changed, because they allow code -that may surprise the user. See document N1360 for details and -rationale. -</p> - -<p><i>[Santa Cruz: the real issue is that we've got const member -functions that return pointers to non-const, and N1360 proposes -replacing them by overloaded pairs. There isn't a consensus about -whether this is a real issue, since we've never said what our -constness policy is for iostreams. N1360 relies on a distinction -between physical constness and logical constness; that distinction, or -those terms, does not appear in the standard.]</i></p> - -<p><b>Proposed resolution:</b></p> -<p>In 27.4.4 and 27.4.4.2</p> -<p>Replace</p> -<pre> basic_ostream<charT,traits>* tie() const; -</pre> -<p>with</p> -<pre> basic_ostream<charT,traits>* tie(); - const basic_ostream<charT,traits>* tie() const; -</pre> - -<p>and replace</p> -<pre> basic_streambuf<charT,traits>* rdbuf() const; -</pre> -<p>with</p> -<pre> basic_streambuf<charT,traits>* rdbuf(); - const basic_streambuf<charT,traits>* rdbuf() const; -</pre> - -<p>In 27.5.2 and 27.5.2.3.1</p> -<p>Replace</p> -<pre> char_type* eback() const; -</pre> -<p>with</p> -<pre> char_type* eback(); - const char_type* eback() const; -</pre> +<p>Add this sentence to the end of 20.3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.binders"> [lib.binders]</a>/1: + "Binders <tt>bind1st</tt> and <tt>bind2nd</tt> are deprecated in + favor of <tt>std::tr1::bind</tt>."</p> -<p>Replace</p> -<pre> char_type gptr() const; -</pre> -<p>with</p> -<pre> char_type* gptr(); - const char_type* gptr() const; -</pre> - -<p>Replace</p> -<pre> char_type* egptr() const; -</pre> -<p>with</p> -<pre> char_type* egptr(); - const char_type* egptr() const; -</pre> - -<p>In 27.5.2 and 27.5.2.3.2</p> -<p>Replace</p> -<pre> char_type* pbase() const; -</pre> -<p>with</p> -<pre> char_type* pbase(); - const char_type* pbase() const; -</pre> - -<p>Replace</p> -<pre> char_type* pptr() const; -</pre> -<p>with</p> -<pre> char_type* pptr(); - const char_type* pptr() const; -</pre> - -<p>Replace</p> -<pre> char_type* epptr() const; -</pre> -<p>with</p> -<pre> char_type* epptr(); - const char_type* epptr() const; -</pre> - -<p>In 27.7.2, 27.7.2.2, 27.7.3 27.7.3.2, 27.7.4, and 27.7.6</p> -<p>Replace</p> -<pre> basic_stringbuf<charT,traits,Allocator>* rdbuf() const; -</pre> -<p>with</p> -<pre> basic_stringbuf<charT,traits,Allocator>* rdbuf(); - const basic_stringbuf<charT,traits,Allocator>* rdbuf() const; -</pre> - -<p>In 27.8.1.5, 27.8.1.7, 27.8.1.8, 27.8.1.10, 27.8.1.11, and 27.8.1.13</p> -<p>Replace</p> -<pre> basic_filebuf<charT,traits>* rdbuf() const; -</pre> -<p>with</p> -<pre> basic_filebuf<charT,traits>* rdbuf(); - const basic_filebuf<charT,traits>* rdbuf() const; -</pre> -<hr> -<a name="368"><h3>368. basic_string::replace has two "Throws" paragraphs</h3></a><p><b>Section:</b> 21.3.5.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::replace"> [lib.string::replace]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 3 Jun 2002</p> -<p> -21.3.5.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::replace"> [lib.string::replace]</a> basic_string::replace, second -signature, given in paragraph 1, has two "Throws" paragraphs (3 and -5). -</p> - -<p> -In addition, the second "Throws" paragraph (5) includes specification -(beginning with "Otherwise, the function replaces ...") that should be -part of the "Effects" paragraph. -</p> -<p><b>Proposed resolution:</b></p> -<p><i>[This is a typo that escalated. It's clear that what's in the - Standard is wrong. It's less clear what the fix ought to be. - Someone who understands string replace well needs to work on - this.]</i></p> +<p>(Notes to editor: (1) when and if tr1::bind is incorporated into + the standard, "std::tr1::bind" should be changed to "std::bind". (2) + 20.3.6 should probably be moved to Annex D.</p> +<p><b>Rationale:</b></p> +<p>There is no point in fixing bind1st and bind2nd. tr1::bind is a + superior solution. It solves this problem and others.</p> <hr> -<a name="369"><h3>369. io stream objects and static ctors</h3></a><p><b>Section:</b> 27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Ruslan Abdikeev <b>Date:</b> 8 Jul 2002</p> +<a name="369"><h3>369. io stream objects and static ctors</h3></a><p><b>Section:</b> 27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Ruslan Abdikeev <b>Date:</b> 8 Jul 2002</p> <p> Is it safe to use standard iostream objects from constructors of static objects? Are standard iostream objects constructed and are @@ -2154,31 +1405,17 @@ mention of an _instance_ of ios_base::Init in Standard. </p> <p><b>Proposed resolution:</b></p> -<p><i>[Redmond: This still isn't precise enough. We need to give - users some guarantees, i.e. "if you do X, then you are guaranteed - that you will see behavior Y." We should guarantee that stream - objects are constructed before a static constructor if (1) - <iostream> is #included before the relevant static object; or - (2) the user explicitly constructs an ios_base::Init object before - calling that constuctor.]</i></p> - -<p>Add to [lib.iostream.objects], p2, immediately before the last sentence +<p>Add to 27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>, p2, immediately before the last sentence of the paragraph, the following two sentences:</p> <blockquote> -It is implementation-defined whether the header <iostream> defines -an ios_base::Init object or not. If it does not, an implementation -must specify the means of achieving safe access to the standard -objects for input and output during program startup. +If a translation unit includes <iostream>, or explicitly +constructs an ios_base::Init object, dynamic initialization of objects +later in that translation unit may assume that these stream objects +have been constructed and destructors may assume that these stream +objects have not yet been destroyed. </blockquote> -<p><i>[Santa Cruz: The LWG is leaning toward NAD. There isn't any -normative wording saying that the Init scheme will be used, but that -is probably intentional. Implementers use dirty tricks for iostream -initialization, and doing it portably is somewhere between difficult -and impossible. Too much constraint in this area is dangerous, and if -we are to make any changes it would probably be more appropriate -for them to be nonnormative. Summer '04 mid-meeting mailing: Martin -provided wording for resolution and rationale.]</i></p> +<p><i>[Lillehammer: Matt provided wording.]</i></p> <p><b>Rationale:</b></p> <p> The original proposed resolution unconditionally required @@ -2192,34 +1429,10 @@ is no need to require implementations to document the name of the object.</p> <p> -The new proposed resolution specifies that implementations may -(but need not) define an ios_base::Init object, while requiring -them to document whether they do or not, and if not, to document -how portable programs achieve safe access to the 8 standard iostream -objects during program startup (3.6)(*). The intent is that if an -implementation documents that <iostream> defines an ios_base::Init -object, it implies that the header must be #included before any -references to the standard iostream objects. Otherwise, if an -implementation does not define an ios_base::Init object in -<iostream> it must either assure and document that the standard -iostream objects are safely accessible at startup, or specify what -a portable program must do to safely access them (e.g., it may -require that a program define an ios_base::Init object before -doing so, or that it call ios::sync_with_stdio(), etc.). -</p> - -<p> -(*) Note that the term startup is broader than the term "Constructors -and destructors for static objects" used in Footnote 265 since the -former includes other functions besides constructors and destructors, -including the following example: -</p> -<pre> int foo () { return (std::cout << "foo()\n").rdstate (); } - int i = foo (); - int main () { return i; } -</pre> +The new proposed resolution gives users guidance on what they need to +do to ensure that stream objects are constructed during startup.</p> <hr> -<a name="371"></a><h3><a name="371">371. Stability of multiset and multimap member functions</a></h3><p><b>Section:</b> 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Frank Compagner <b>Date:</b> 20 Jul 2002</p> +<a name="371"><h3>371. Stability of multiset and multimap member functions</h3></a><p><b>Section:</b> 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Frank Compagner <b>Date:</b> 20 Jul 2002</p> <p> The requirements for multiset and multimap containers (23.1 [lib.containers.requirements], 23.1.2 [lib.associative.reqmnts], @@ -2271,22 +1484,41 @@ be hard to track down by users. This would also make the need for an erase_if() member function that much greater. </p> -<p>This issue is somewhat related to LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#130">130</a>.</p> - -<p><i>[Santa Cruz: More people need to look at this. Much user code - may assume stability. On the other hand, it seems drastic to add a - new requirement now.]</i></p> +<p>This issue is somewhat related to LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>.</p> <p><b>Proposed resolution:</b></p> + +<p>Add the following to the end of 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> paragraph 4: +"For <tt>set</tt> and <tt>map</tt>, <tt>insert</tt>and <tt>erase</tt> + are <i>stable</i>: they preserve the relative ordering of equivalent + elements.</p> + +<p><i>[Lillehammer: Matt provided wording]</i></p> +<p><i>[Joe Gottman points out that the provided wording does not address +multimap and multiset. N1780 also addresses this issue and suggests +wording.]</i></p> + +<p><b>Rationale:</b></p> +<p>The LWG agrees that this guarantee is necessary for common user + idioms to work, and that all existing implementations provide this + property. Note that this resolution guarantees stability for + multimap and multiset, not for all associative containers in + general.</p> <hr> -<a name="376"><h3>376. basic_streambuf semantics</h3></a><p><b>Section:</b> 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 14 Aug 2002</p> +<a name="376"><h3>376. basic_streambuf semantics</h3></a><p><b>Section:</b> 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 14 Aug 2002</p> <p> In Section 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, Table 90, the implication is that the four conditions should be mutually exclusive, but they are not. -The first two cases, as written, are subcases of the third. I think it -would be clearer if the conditions were rewritten as follows: +The first two cases, as written, are subcases of the third.</p> + +<p> +As written, it is unclear what should be the result if cases 1 and 2 +are both true, but case 3 is false. </p> +<p><b>Proposed resolution:</b></p> + +<p>Rewrite these conditions as:</p> <blockquote> <p> (which & (ios_base::in|ios_base::out)) == ios_base::in @@ -2305,19 +1537,9 @@ would be clearer if the conditions were rewritten as follows: <p>Otherwise</p> </blockquote> -<p> -As written, it is unclear what should be the result if cases 1 & 2 -are true, but case 3 is false, e.g., -</p> - -<blockquote> - seekoff(0, ios_base::cur, ios_base::in | ios_base::out) -</blockquote> - -<p><i>[Santa Cruz: The ambiguity seems real. We need to do a survey of -implementations before we decide on a solution.]</i></p> - -<p><b>Proposed resolution:</b></p> +<p><b>Rationale:</b></p> +<p>It's clear what we wanted to say, we just failed to say it. This + fixes it.</p> <hr> <a name="382"><h3>382. codecvt do_in/out result</h3></a><p><b>Section:</b> 22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 30 Aug 2002</p> <p> @@ -2416,79 +1638,22 @@ which would make perfect sense, since, as far as I understand it, partial can only occur if (from_next != from_end)? </p> <p><b>Proposed resolution:</b></p> -<p> -To address these issues, I propose that paragraphs 2, 3, and 4 -be rewritten as follows. The proposal incorporates the accepted -resolution of lwg issue 19. -</p> -<pre>-2- Effects: Converts characters in the range of source elements - [from, from_end), placing the results in sequential positions - starting at destination to. Converts no more than (from_end from) - source elements, and stores no more than (to_limit to) - destination elements. - - Stops if it encounters a sequence of source elements it cannot - convert to a valid destination character. It always leaves the - from_next and to_next pointers pointing one beyond the last - element successfully converted. - - [Note: If returns noconv, internT and externT are the same type - and the converted sequence is identical to the input sequence - [from, from_next). to_next is set equal to to, the value of - state is unchanged, and there are no changes to the values in - [to, to_limit). --end note] - --3- Notes: Its operations on state are unspecified. - [Note: This argument can be used, for example, to maintain shift - state, to specify conversion options (such as count only), or to - identify a cache of seek offsets. --end note] - --4- Returns: An enumeration value, as summarized in Table 53: - - Table 53 -- do_in/do_out result values - - Value Meaning - +---------+----------------------------------------------------+ - | ok | successfully completed the conversion of all | - | | complete characters in the source range | - +---------+----------------------------------------------------+ - | partial | the characters in the source range would, after | - | | conversion, require space greater than that | - | | available in the destination range | - +---------+----------------------------------------------------+ - | error | encountered either a sequence of elements in the | - | | source range forming a valid source character that | - | | could not be converted to a destination character, | - | | or a sequence of elements in the source range that | - | | could not possibly form a valid source character | - +---------+----------------------------------------------------+ - | noconv | internT and externT are the same type, and input | - | | sequence is identical to converted sequence | - +---------+----------------------------------------------------+ - - A return value of partial, i.e., if (from_next != from_end), - indicates that either the destination sequence has not absorbed - all the available destination elements, or that additional - source elements are needed before another destination character - can be produced. -</pre> -<p><i>[Santa Cruz: The LWG agrees that this is an important issue and -that this general direction is probably correct. Dietmar, Howard, -PJP, and Matt will review this wording.]</i></p> - -<p><i>[Kona: this isn't quite right. (a) the description of noconv is -too vague, both in the existing standard and in the current proposed -resolution; (b) the description of what noconv means should be -normative; (c) the phrase "partial, i.e. if from_next != from_end" -isn't quite right, because those are two separate cases, it's possible -to get partial either form insufficient input or from insufficient -space in the output buffer. The big problem is that the standard is -written with the assumption of 1->N conversion in mind, not M->N. -Bill, Howard, and Martin will provide new wording. -]</i></p> +<p><i>[Lillehammer: Defer for the moment, but this really needs to be + fixed. Right now, the description of codecvt is too vague for it to + be a useful contract between providers and clients of codecvt + facets. (Note that both vendors and users can be both providers and + clients of codecvt facets.) The major philosophical issue is whether + the standard should only describe mappings that take a single wide + character to multiple narrow characters (and vice versa), or whether + it should describe fully general N-to-M conversions. When the + original standard was written only the former was contemplated, but + today, in light of the popularity of utf8 and utf16, that doesn't + seem sufficient for C++0x. Bill supports general N-to-M conversions; + we need to make sure Martin and Howard agree.]</i></p> + <hr> -<a name="384"><h3>384. equal_range has unimplementable runtime complexity</h3></a><p><b>Section:</b> 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Hans Bos <b>Date:</b> 18 Oct 2002</p> +<a name="384"><h3>384. equal_range has unimplementable runtime complexity</h3></a><p><b>Section:</b> 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Hans Bos <b>Date:</b> 18 Oct 2002</p> <p> Section 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a> states that at most 2 * log(last - first) + 1 @@ -2526,14 +1691,25 @@ have log(distance) characteristics when at most match is found in the range but 2log(distance) + 4 for the worst case). </p> -<p><i>[Santa Cruz: The issue is real, but of greater scope than just -equal_range: it affects all of the binary search algorithms. What is -the complexity supposed to be for ranges of 0 or 1 elements? What -base are we using for the logarithm? Are these bounds supposed to be -exact, or asymptotic? (If the latter, of course, then none of the -other questions matter.)]</i></p> - <p><b>Proposed resolution:</b></p> +<p>In 25.3.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.lower.bound"> [lib.lower.bound]</a>/4, change <tt>log(last - first) + 1</tt> +to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p> + +<p>In 25.3.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.upper.bound"> [lib.upper.bound]</a>/4, change <tt>log(last - first) + 1</tt> +to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p> + +<p>In 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>/4, change <tt>2*log(last - first) + 1</tt> +to <tt>2*log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p> + +<p><i>[Matt provided wording]</i></p> +<p><b>Rationale:</b></p> +<p>The LWG considered just saying <i>O</i>(log n) for all three, but +Ê decided that threw away too much valuable information.Ê The fact +Ê that lower_bound is twice as fast as equal_range is important. +Ê However, it's better to allow an arbitrary additive constant than to +Ê specify an exact count.Ê An exact count would have to +Ê involve <tt>floor</tt> or <tt>ceil</tt>.Ê It would be too easy to +Ê get this wrong, and don't provide any substantial value for users.</p> <hr> <a name="385"><h3>385. Does call by value imply the CopyConstructible requirement?</h3></a><p><b>Section:</b> 17 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.library"> [lib.library]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 23 Oct 2002</p> <p> @@ -2571,57 +1747,6 @@ into references? References aren't copy constructible, so this should not be allowed. ]</i></p> <hr> -<a name="386"><h3>386. Reverse iterator's operator[] has impossible return type</h3></a><p><b>Section:</b> 24.4.1.3.11 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.opindex"> [lib.reverse.iter.opindex]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 23 Oct 2002</p> -<p>In 24.4.1.3.11 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.opindex"> [lib.reverse.iter.opindex]</a>, <tt>reverse_iterator<>::operator[]</tt> -is specified as having a return type of <tt>reverse_iterator::reference</tt>, -which is the same as <tt>iterator_traits<Iterator>::reference</tt>. -(Where <tt>Iterator</tt> is the underlying iterator type.)</p> - -<p>The trouble is that <tt>Iterator</tt>'s own operator[] doesn't - necessarily have a return type - of <tt>iterator_traits<Iterator>::reference</tt>. Its - return type is merely required to be convertible - to <tt>Iterator</tt>'s value type. The return type specified for - reverse_iterator's operator[] would thus appear to be impossible.</p> - -<p>With the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a>, the type of - <tt>a[n]</tt> will continue to be required (for random access - iterators) to be convertible to the value type, and also <tt>a[n] = - t</tt> will be a valid expression. Implementations of - <tt>reverse_iterator</tt> will likely need to return a proxy from - <tt>operator[]</tt> to meet these requirements. As mentioned in the - comment from Dave Abrahams, the simplest way to specify that - <tt>reverse_iterator</tt> meet this requirement to just mandate - it and leave the return type of <tt>operator[]</tt> unspecified.</p> - -<p><b>Proposed resolution:</b></p> - -<p>In 24.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.requirements"> [lib.reverse.iter.requirements]</a> change:</p> - -<blockquote> -<pre>reference operator[](difference_type n) const; -</pre> -</blockquote> - -<p>to:</p> - -<blockquote> -<pre><b><i>unspecified</i></b> operator[](difference_type n) const; // see <font color="red">lib.random.access.iterators</font> -</pre> -</blockquote> - - - - -<p><i>[ -Comments from Dave Abrahams: IMO we should resolve 386 by just saying - that the return type of reverse_iterator's operator[] is - unspecified, allowing the random access iterator requirements to - impose an appropriate return type. If we accept 299's proposed - resolution (and I think we should), the return type will be - readable and writable, which is about as good as we can do. -]</i></p> -<hr> <a name="387"><h3>387. std::complex over-encapsulated</h3></a><p><b>Section:</b> 26.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.numbers"> [lib.complex.numbers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 8 Nov 2002</p> <p> The absence of explicit description of std::complex<T> layout @@ -2827,7 +1952,7 @@ functions should be changed as proposed below. <p><b>Rationale:</b></p> <hr> -<a name="396"><h3>396. what are characters zero and one</h3></a><p><b>Section:</b> 23.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 5 Jan 2003</p> +<a name="396"></a><h3><a name="396">396. what are characters zero and one</a></h3><p><b>Section:</b> 23.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 5 Jan 2003</p> <p> 23.3.5.1, p6 [lib.bitset.cons] talks about a generic character having the value of 0 or 1 but there is no definition of what @@ -3108,29 +2233,6 @@ in 13.5.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/over.html#over.re non-default pointer types.]</i></p> <hr> -<a name="406"><h3>406. vector::insert(s) exception safety</h3></a><p><b>Section:</b> 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 27 Apr 2003</p> -<p> -There is a possible defect in the standard: the standard text was -never intended to prevent arbitrary ForwardIterators, whose operations -may throw exceptions, from being passed, and it also wasn't intended -to require a temporary buffer in the case where ForwardIterators were -passed (and I think most implementations don't use one). As is, the -standard appears to impose requirements that aren't met by any -existing implementation. -</p> -<p><b>Proposed resolution:</b></p> -<p>Replace 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a> paragraph 1 with:</p> -<blockquote> - 1- Notes: 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 or assignment operator - of T or by any InputIterator operation there are no effects. -</blockquote> - -<p><i>[We probably need to say something similar for deque.]</i></p> - -<hr> <a name="408"><h3>408. Is vector<reverse_iterator<char*> > forbidden?</h3></a><p><b>Section:</b> 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 3 June 2003</p> <p> I've been discussing iterator semantics with Dave Abrahams, and a @@ -3255,126 +2357,6 @@ wrong to impose so strict a requirement for iterators. ]</i></p> <hr> -<a name="409"><h3>409. Closing an fstream should clear error state</h3></a><p><b>Section:</b> 27.8.1.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a>, 27.8.1.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ofstream.members"> [lib.ofstream.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 3 June 2003</p> -<p> -A strict reading of 27.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a> shows that opening or -closing a basic_[io]fstream does not affect the error bits. This -means, for example, that if you read through a file up to EOF, and -then close the stream and reopen it at the beginning of the file, -the EOF bit in the stream's error state is still set. This is -counterintuitive. -</p> -<p> -The LWG considered this issue once before, as issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#22">22</a>, -and put in a footnote to clarify that the strict reading was indeed -correct. We did that because we believed the standard was -unambiguous and consistent, and that we should not make architectural -changes in a TC. Now that we're working on a new revision of the -language, those considerations no longer apply. -</p> -<p><b>Proposed resolution:</b></p> - -<p>Change 27.8.1.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a>, para. 3 from:</p> - -<blockquote> -Calls rdbuf()->open(s,mode|in). If that function returns a null -pointer, calls setstate(failbit) (which may throw ios_base::failure -[Footnote: (lib.iostate.flags)]. -</blockquote> - -<p>to:</p> - -<blockquote>Calls rdbuf()->open(s,mode|in). If that function returns -a null pointer, calls setstate(failbit) (which may throw -ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear(). -</blockquote> - -<p>Change 27.8.1.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ofstream.members"> [lib.ofstream.members]</a>, para. 3 from:</p> - -<blockquote>Calls rdbuf()->open(s,mode|out). If that function -returns a null pointer, calls setstate(failbit) (which may throw -ios_base::failure [Footnote: (lib.iostate.flags)). -</blockquote> - -<p>to:</p> - -<blockquote>Calls rdbuf()->open(s,mode|out). If that function -returns a null pointer, calls setstate(failbit) (which may throw -ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear(). -</blockquote> - -<p>Change 27.8.1.13 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstream.members"> [lib.fstream.members]</a>, para. 3 from:</p> - -<blockquote>Calls rdbuf()->open(s,mode), If that function returns a -null pointer, calls setstate(failbit), (which may throw -ios_base::failure). (lib.iostate.flags) ) -</blockquote> - -<p>to:</p> - -<blockquote>Calls rdbuf()->open(s,mode), If that function returns a -null pointer, calls setstate(failbit), (which may throw -ios_base::failure). (lib.iostate.flags) ), else calls clear(). -</blockquote> - - - -<p><i>[Kona: the LWG agrees this is a good idea. Post-Kona: Bill -provided wording. He suggests having open, not close, clear the error -flags.]</i></p> - -<p><i>[Post-Sydney: Howard provided a new proposed resolution. The - old one didn't make sense because it proposed to fix this at the - level of basic_filebuf, which doesn't have access to the stream's - error state. Howard's proposed resolution fixes this at the level - of the three fstream class template instead.]</i></p> - -<hr> -<a name="413"><h3>413. Proposed resolution to LDR#64 still wrong</h3></a><p><b>Section:</b> 27.6.1.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Bo Persson <b>Date:</b> 13 Jul 2003</p> -<p> -The second sentence of the proposed resolution says: -</p> - -<p> -"If it inserted no characters because it caught an exception thrown -while extracting characters from sb and ..." -</p> - -<p> -However, we are not extracting from sb, but extracting from the -basic_istream (*this) and inserting into sb. I can't really tell if -"extracting" or "sb" is a typo. -</p> - -<p><i>[ -Sydney: Definitely a real issue. We are, indeed, extracting characters -from an istream and not from sb. The problem was there in the FDIS and -wasn't fixed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a>. Probably what was intended was -to have *this instead of sb. We're talking about the exception flag -state of a basic_istream object, and there's only one basic_istream -object in this discussion, so that would be a consistent -interpretation. (But we need to be careful: the exception policy of -this member function must be consistent with that of other -extractors.) PJP will provide wording. -]</i></p> - -<p><b>Proposed resolution:</b></p> -<p>Change the sentence from:</p> - -<blockquote> -If it inserted no characters because it caught an exception thrown -while extracting characters from sb and failbit is on in exceptions(), -then the caught exception is rethrown. -</blockquote> - -<p>to:</p> - -<blockquote> -If it inserted no characters because it caught an exception thrown -while extracting characters from *this and failbit is on in exceptions(), -then the caught exception is rethrown. -</blockquote> -<hr> <a name="416"><h3>416. definitions of XXX_MIN and XXX_MAX macros in climits</h3></a><p><b>Section:</b> 18.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.c.limits"> [lib.c.limits]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p> <p> @@ -3653,7 +2635,8 @@ Constructs an independent copy of sb as if with sb.str(), and with the openmode getloc() == sb.getloc() </pre> -<p>Note: The only requirement on epptr() is that it point beyond the +<p> +Note: The only requirement on epptr() is that it point beyond the initialized range if an output sequence exists. There is no requirement that epptr() - pbase() == sb.epptr() - sb.pbase(). </p> @@ -3721,7 +2704,7 @@ basic_filebuf. </p> <hr> -<a name="422"></a><h3><a name="422">422. explicit specializations of member functions of class templates</a></h3><p><b>Section:</b> 17.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p> +<a name="422"><h3>422. explicit specializations of member functions of class templates</h3></a><p><b>Section:</b> 17.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p> <p> It has been suggested that 17.4.3.1, p1 may or may not allow programs to explicitly specialize members of standard templates on user-defined types. @@ -3948,566 +2931,6 @@ object (e.g., slice (2, 1, 1) for a valarray of size 1). <p><i>[pre-Sydney: Howard argues for option 3 in n1599.]</i></p> <hr> -<a name="434"><h3>434. bitset::to_string() hard to use</h3></a><p><b>Section:</b> 23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 15 Oct 2003</p> -<p> -It has been pointed out a number of times that the bitset to_string() member -function template is tedious to use since callers must explicitly specify the -entire template argument list (3 arguments). At least two implementations -provide a number of overloads of this template to make it easier to use. -</p> -<p><b>Proposed resolution:</b></p> -<p>In order to allow callers to specify no template arguments at all, just the -first one (charT), or the first 2 (charT and traits), in addition to all -three template arguments, add the following three overloads to both the -interface (declarations only) of the class template bitset as well as to -section 23.3.5.2, immediately after p34, the Returns clause of the existing -to_string() member function template:</p> - -<pre> template <class charT, class traits> - basic_string<charT, traits, allocator<charT> > - to_string () const; - - -34.1- Returns: to_string<charT, traits, allocator<charT> >(). - - template <class charT> - basic_string<charT, char_traits<charT>, allocator<charT> > - to_string () const; - - -34.2- Returns: to_string<charT, char_traits<charT>, allocator<charT> >(). - - basic_string<char, char_traits<char>, allocator<char> > - to_string () const; - - -34.3- Returns: to_string<char, char_traits<char>, allocator<char> >(). -</pre> - -<p><i>[Kona: the LWG agrees that this is an improvement over the - status quo. Dietmar thought about an alternative using a proxy - object but now believes that the proposed resolution above is the - right choice. -]</i></p> - -<hr> -<a name="438"><h3>438. Ambiguity in the "do the right thing" clause</h3></a><p><b>Section:</b> 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 20 Oct 2003</p> - -<p>Section 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>, paragraphs 9-11, fixed up the problem -noticed with statements like:</p> -<pre>vector<int> v(10, 1); -</pre> - -<p>The intent of the above statement was to construct with:</p> -<pre>vector(size_type, const value_type&); -</pre> - -<p>but early implementations failed to compile as they bound to:</p> -<pre>template <class InputIterator> -vector(InputIterator f, InputIterator l); -</pre> -<p>instead.</p> - -<p>Paragraphs 9-11 say that if InputIterator is an integral type, then the -member template constructor will have the same effect as:</p> -<pre>vector<static_cast<size_type>(f), static_cast<value_type>(l)); -</pre> -<p>(and similarly for the other member template functions of sequences).</p> - -<p>There is also a note that describes one implementation technique:</p> -<blockquote> - One way that sequence implementors can satisfy this requirement is to - specialize the member template for every integral type. -</blockquote> - -<p>This might look something like:</p> -<blockquote> -<pre>template <class T> -struct vector -{ - typedef unsigned size_type; - - explicit vector(size_type) {} - vector(size_type, const T&) {} - - template <class I> - vector(I, I); - - // ... -}; - -template <class T> -template <class I> -vector<T>::vector(I, I) { ... } - -template <> -template <> -vector<int>::vector(int, int) { ... } - -template <> -template <> -vector<int>::vector(unsigned, unsigned) { ... } - -// ... -</pre> -</blockquote> - -<p>Label this solution 'A'.</p> - -<p>The standard also says:</p> -<blockquote> - Less cumbersome implementation techniques also exist. -</blockquote> -<p> -A popular technique is to not specialize as above, but instead catch -every call with the member template, detect the type of InputIterator, -and then redirect to the correct logic. Something like: -</p> -<blockquote> -<pre>template <class T> -template <class I> -vector<T>::vector(I f, I l) -{ - choose_init(f, l, int2type<is_integral<I>::value>()); -} - -template <class T> -template <class I> -vector<T>::choose_init(I f, I l, int2type<false>) -{ - // construct with iterators -} - -template <class T> -template <class I> -vector<T>::choose_init(I f, I l, int2type<true>) -{ - size_type sz = static_cast<size_type>(f); - value_type v = static_cast<value_type>(l); - // construct with sz,v -} -</pre> -</blockquote> - -<p>Label this solution 'B'.</p> - -<p>Both of these solutions solve the case the standard specifically -mentions:</p> -<pre>vector<int> v(10, 1); // ok, vector size 10, initialized to 1 -</pre> - -<p> -However, (and here is the problem), the two solutions have different -behavior in some cases where the value_type of the sequence is not an -integral type. For example consider: -</p> -<blockquote><pre> pair<char, char> p('a', 'b'); - vector<vector<pair<char, char> > > d('a', 'b'); -</pre></blockquote> -<p> -The second line of this snippet is likely an error. Solution A catches -the error and refuses to compile. The reason is that there is no -specialization of the member template constructor that looks like: -</p> -<pre>template <> -template <> -vector<vector<pair<char, char> > >::vector(char, char) { ... } -</pre> - -<p> -So the expression binds to the unspecialized member template -constructor, and then fails (compile time) because char is not an -InputIterator. -</p> - -<p> -Solution B compiles the above example though. 'a' is casted to an -unsigned integral type and used to size the outer vector. 'b' is -static casted to the inner vector using it's explicit constructor: -</p> - -<pre>explicit vector(size_type n); -</pre> - -<p> -and so you end up with a static_cast<size_type>('a') by -static_cast<size_type>('b') matrix. -</p> - -<p> -It is certainly possible that this is what the coder intended. But the -explicit qualifier on the inner vector has been thwarted at any rate. -</p> - -<p> -The standard is not clear whether the expression: -</p> - -<pre> vector<vector<pair<char, char> > > d('a', 'b'); -</pre> - -<p> -(and similar expressions) are: -</p> - -<ol> -<li> undefined behavior.</li> -<li> illegal and must be rejected.</li> -<li> legal and must be accepted.</li> -</ol> - -<p>My preference is listed in the order presented.</p> - -<p>There are still other techniques for implementing the requirements of -paragraphs 9-11, namely the "restricted template technique" (e.g. -enable_if). This technique is the most compact and easy way of coding -the requirements, and has the behavior of #2 (rejects the above -expression). -</p> - -<p> -Choosing 1 would allow all implementation techniques I'm aware of. -Choosing 2 would allow only solution 'A' and the enable_if technique. -Choosing 3 would allow only solution 'B'. -</p> - -<p> -Possible wording for a future standard if we wanted to actively reject -the expression above would be to change "static_cast" in paragraphs -9-11 to "implicit_cast" where that is defined by: -</p> - -<blockquote> -<pre>template <class T, class U> -inline -T implicit_cast(const U& u) -{ - return u; -} -</pre> -</blockquote> - -<p><b>Proposed resolution:</b></p> - -Replace 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> paragraphs 9 - 11 with: - -<p>For every sequence defined in this clause and in clause lib.strings:</p> - -<ul> - <li> - <p>If the constructor</p> - <pre> template <class InputIterator> - X(InputIterator f, InputIterator l, - const allocator_type& a = allocator_type()) - </pre> - <p>is called with a type InputIterator that does not qualify as - an input iterator, then the constructor will behave as if the - overloaded constructor:</p> - <pre> X(size_type, const value_type& = value_type(), - const allocator_type& = allocator_type()) - </pre> - <p>were called instead, with the arguments static_cast<size_type>(f), l and a, respectively.</p> - </li> - - <li> - <p>If the member functions of the forms:</p> - <pre> template <class InputIterator> // such as insert() - rt fx1(iterator p, InputIterator f, InputIterator l); - - template <class InputIterator> // such as append(), assign() - rt fx2(InputIterator f, InputIterator l); - - template <class InputIterator> // such as replace() - rt fx3(iterator i1, iterator i2, InputIterator f, InputIterator l); - </pre> - <p>are called with a type InputIterator that does not qualify as - an input iterator, then these functions will behave as if the - overloaded member functions:</p> - <pre> rt fx1(iterator, size_type, const value_type&); - - rt fx2(size_type, const value_type&); - - rt fx3(iterator, iterator, size_type, const value_type&); - </pre> - <p>were called instead, with the same arguments.</p> - </li> -</ul> - -<p>In the previous paragraph the alternative binding will fail if f -is not implicitly convertible to X::size_type or if l is not implicitly -convertible to X::value_type.</p> - -<p> -The extent to which an implementation determines that a type cannot be -an input iterator is unspecified, except that as a minimum integral -types shall not qualify as input iterators. -</p> - - - -<p><i>[ -Kona: agreed that the current standard requires <tt>v('a', 'b')</tt> -to be accepted, and also agreed that this is surprising behavior. The -LWG considered several options, including something like -implicit_cast, which doesn't appear to be quite what we want. We -considered Howards three options: allow acceptance or rejection, -require rejection as a compile time error, and require acceptance. By -straw poll (1-6-1), we chose to require a compile time error. -Post-Kona: Howard provided wording. -]</i></p> - -<p><i>[ -Sydney: The LWG agreed with this general direction, but there was some -discomfort with the wording in the original proposed resolution. -Howard submitted new wording, and we will review this again in -Redmond. -]</i></p> - -<p><i>[Redmond: one very small change in wording: the first argument - is cast to size_t. This fixes the problem of something like - <tt>vector<vector<int> >(5, 5)</tt>, where int is not - implicitly convertible to the value type.]</i></p> - -<p><b>Rationale:</b></p> -<p>The proposed resolution fixes:</p> - -<pre> vector<int> v(10, 1); -</pre> - -<p> -since as integral types 10 and 1 must be disqualified as input -iterators and therefore the (size,value) constructor is called (as -if).</p> - -<p>The proposed resolution breaks:</p> - -<pre> vector<vector<T> > v(10, 1); -</pre> - -<p> -because the integral type 1 is not *implicitly* convertible to -vector<T>. The wording above requires a diagnostic.</p> - -<p> -The proposed resolution leaves the behavior of the following code -unspecified. -</p> - -<pre> struct A - { - operator int () const {return 10;} - }; - - struct B - { - B(A) {} - }; - - vector<B> v(A(), A()); -</pre> - -<p> -The implementation may or may not detect that A is not an input -iterator and employee the (size,value) constructor. Note though that -in the above example if the B(A) constructor is qualified explicit, -then the implementation must reject the constructor as A is no longer -implicitly convertible to B. -</p> -<hr> -<a name="444"><h3>444. Bad use of casts in fstream</h3></a><p><b>Section:</b> 27.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Vincent Leloup <b>Date:</b> 20 Nov 2003</p> -<p> -27.8.1.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a> p1, 27.8.1.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ofstream.members"> [lib.ofstream.members]</a> p1, 27.8.1.13 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstream.members"> [lib.fstream.members]</a> p1 seems have same problem as exposed in LWG issue -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a>. -</p> -<p><b>Proposed resolution:</b></p> - -<p><i>[Sydney: Genuine defect. 27.8.1.13 needs a cast to cast away - constness. The other two places are stylistic: we could change the - C-style casts to const_cast. Post-Sydney: Howard provided wording. -]</i></p> - -<p>Change 27.8.1.7/1 from:</p> -<blockquote> - Returns: (basic_filebuf<charT,traits>*)&sb. -</blockquote> - -<p>to:</p> -<blockquote> - Returns: const_cast<basic_filebuf<charT,traits>*>(&sb). -</blockquote> - -<p>Change 27.8.1.10/1 from:</p> -<blockquote> - Returns: (basic_filebuf<charT,traits>*)&sb. -</blockquote> - -<p>to:</p> -<blockquote> - Returns: const_cast<basic_filebuf<charT,traits>*>(&sb). -</blockquote> - -<p>Change 27.8.1.13/1 from:</p> -<blockquote> - Returns: &sb. -</blockquote> - -<p>to:</p> -<blockquote> - Returns: const_cast<basic_filebuf<charT,traits>*>(&sb). -</blockquote> - - - -<hr> -<a name="445"></a><h3><a name="445">445. iterator_traits::reference unspecified for some iterator categories</a></h3><p><b>Section:</b> 24.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.traits"> [lib.iterator.traits]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 9 Dec 2003</p> -<p> -The standard places no restrictions at all on the reference type -of input, output, or forward iterators (for forward iterators it -only specifies that *x must be value_type& and doesn't mention -the reference type). Bidirectional iterators' reference type is -restricted only by implication, since the base iterator's -reference type is used as the return type of reverse_iterator's -operator*, which must be T& in order to be a conforming forward -iterator. -</p> - -<p> -Here's what I think we ought to be able to expect from an input -or forward iterator's reference type R, where a is an iterator -and V is its value_type -</p> - -<ul> - <li> - *a is convertible to R - </li> - - <li> - R is convertible to V - </li> - - <li> - static_cast<V>(static_cast<R>(*a)) is equivalent to - static_cast<V>(*a) - </li> -</ul> - -<p>A mutable forward iterator ought to satisfy, for x of type V:</p> - <li> - { R r = *a; r = x; } is equivalent to *a = x; - </li> - -<p> -I think these requirements capture existing container iterators -(including vector<bool>'s), but render istream_iterator invalid; -its reference type would have to be changed to a constant -reference. -</p> - - -<p> -(Jeremy Siek) During the discussion in Sydney, it was felt that a -simpler long term solution for this was needed. The solution proposed -was to require <tt>reference</tt> to be the same type as <tt>*a</tt> -and <tt>pointer</tt> to be the same type as <tt>a-></tt>. Most -iterators in the Standard Library already meet this requirement. Some -iterators are output iterators, and do not need to meet the -requirement, and others are only specified through the general -iterator requirements (which will change with this resolution). The -sole case where there is an explicit definition of the reference type -that will need to change is <tt>istreambuf_iterator</tt> which returns -<tt>charT</tt> from <tt>operator*</tt> but has a reference type of -<tt>charT&</tt>. We propose changing the reference type of -<tt>istreambuf_iterator</tt> to <tt>charT</tt>. -</p> - -<p>The other option for resolving the issue with <tt>pointer</tt>, - mentioned in the note below, is to remove <tt>pointer</tt> - altogether. I prefer placing requirements on <tt>pointer</tt> to - removing it for two reasons. First, <tt>pointer</tt> will become - useful for implementing iterator adaptors and in particular, - <tt>reverse_iterator</tt> will become more well defined. Second, - removing <tt>pointer</tt> is a rather drastic and publicly-visible - action to take.</p> - -<p>The proposed resolution technically enlarges the requirements for -iterators, which means there are existing iterators (such as -<tt>istreambuf_iterator</tt>, and potentially some programmer-defined -iterators) that will no longer meet the requirements. Will this break -existing code? The scenario in which it would is if an algorithm -implementation (say in the Standard Library) is changed to rely on -<tt>iterator_traits::reference</tt>, and then is used with one of the -iterators that do not have an appropriately defined -<tt>iterator_traits::reference</tt>. -</p> - - -<p>The proposed resolution makes one other subtle change. Previously, -it was required that output iterators have a <tt>difference_type</tt> -and <tt>value_type</tt> of <tt>void</tt>, which means that a forward -iterator could not be an output iterator. This is clearly a mistake, -so I've changed the wording to say that those types may be -<tt>void</tt>. -</p> - -<p><b>Proposed resolution:</b></p> - -<p>In 24.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.traits"> [lib.iterator.traits]</a>, after:</p> - -<blockquote> -be defined as the iterator's difference type, value type and iterator -category, respectively. -</blockquote> - -<p>add</p> - -<blockquote> -In addition, the types -<pre>iterator_traits<Iterator>::reference -iterator_traits<Iterator>::pointer -</pre> -must be defined as the iterator's reference and pointer types, that -is, the same type as the type of <tt>*a</tt> and <tt>a-></tt>, -respectively. -</blockquote> - -<p>In 24.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.traits"> [lib.iterator.traits]</a>, change:</p> - -<blockquote> -In the case of an output iterator, the types -<pre>iterator_traits<Iterator>::difference_type -iterator_traits<Iterator>::value_type -</pre> -are both defined as <tt>void</tt>. -</blockquote> - -<p>to:</p> -<blockquote> -In the case of an output iterator, the types -<pre>iterator_traits<Iterator>::difference_type -iterator_traits<Iterator>::value_type -iterator_traits<Iterator>::reference -iterator_traits<Iterator>::pointer -</pre> -may be defined as <tt>void</tt>. -</blockquote> - -<p>In 24.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator"> [lib.istreambuf.iterator]</a>, change:</p> -<blockquote> -<pre>typename traits::off_type, charT*, charT&> -</pre> -</blockquote> -<p>to:</p> -<blockquote> -<pre>typename traits::off_type, charT*, charT> -</pre> -</blockquote> - -<p><i>[ -Redmond: there was concern in Sydney that this might not be the only place -where things were underspecified and needed to be changed. Jeremy -reviewed iterators in the standard and confirmed that nothing else -needed to be changed. -]</i></p> - -<hr> <a name="446"><h3>446. Iterator equality between different containers</h3></a><p><b>Section:</b> 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>, 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Andy Koenig <b>Date:</b> 16 Dec 2003</p> <p> What requirements does the standard place on equality comparisons between @@ -4532,37 +2955,7 @@ reachability. ]</i></p> <hr> -<a name="453"><h3>453. basic_stringbuf::seekoff need not always fail for an empty stream</h3></a><p><b>Section:</b> 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 30 Jan 2004</p> -<pre> pos_type basic_stringbuf::seekoff(off_type, ios_base::seekdir, - ios_base::openmode); -</pre> -<p> -is obliged to fail if nothing has been inserted into the stream. This -is unnecessary and undesirable. It should be permissible to seek to -an effective offset of zero.</p> - -<p><i>[ - Sydney: Agreed that this is an annoying problem: seeking to zero should be - legal. Bill will provide wording. -]</i></p> - -<p><b>Proposed resolution:</b></p> -<p>Change the sentence from:</p> -<blockquote> -For a sequence to be positioned, if its next pointer (either -gptr() or pptr()) is a null pointer, the positioning operation -fails. -</blockquote> - -<p>to:</p> - -<blockquote> -For a sequence to be positioned, if its next pointer (either -gptr() or pptr()) is a null pointer and the new offset newoff -is nonzero, the positioning operation fails. -</blockquote> -<hr> -<a name="454"><h3>454. basic_filebuf::open should accept wchar_t names</h3></a><p><b>Section:</b> 27.8.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.members"> [lib.filebuf.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 30 Jan 2004</p> +<a name="454"><h3>454. basic_filebuf::open should accept wchar_t names</h3></a><p><b>Section:</b> 27.8.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.members"> [lib.filebuf.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 30 Jan 2004</p> <pre> basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode); </pre> @@ -4633,35 +3026,13 @@ names and files in a filesystem is implementation defined. The counterargument, which most but not all LWG members accepted, is that the mapping between narrow files names and files is also implemenation defined.</p> -<hr> -<a name="455"><h3>455. cerr::tie() and wcerr::tie() are overspecified</h3></a><p><b>Section:</b> 27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 30 Jan 2004</p> -<p> -Both cerr::tie() and wcerr::tie() are obliged to be null at program -startup. This is overspecification and overkill. It is both traditional -and useful to tie cerr to cout, to ensure that standard output is drained -whenever an error message is written. This behavior should at least be -permitted if not required. Same for wcerr::tie(). -</p> -<p><b>Proposed resolution:</b></p> - -<p>Add to the description of cerr:</p> -<blockquote> -After the object cerr is initialized, cerr.tie() returns &cout. -Its state is otherwise the same as required for basic_ios<char>::init -(lib.basic.ios.cons). -</blockquote> - -<p>Add to the description of wcerr:</p> -<blockquote> -After the object wcerr is initialized, wcerr.tie() returns &wcout. -Its state is otherwise the same as required for basic_ios<wchar_t>::init -(lib.basic.ios.cons). -</blockquote> +<p><i>[Lillehammer: Moved back to "open" status, at Beman's urging. +(1) Why just basic_filebuf, instead of also basic_fstream (and +possibly other things too). (2) Why not also constructors that take +std::basic_string? (3) We might want to wait until we see Beman's +filesystem library; we might decide that it obviates this.]</i></p> -<p><i>[Sydney: straw poll (3-1): we should <i>require</i>, not just - permit, cout and cerr to be tied on startup. Pre-Redmond: Bill will - provide wording.]</i></p> <hr> <a name="456"><h3>456. Traditional C header files are overspecified</h3></a><p><b>Section:</b> 17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 30 Jan 2004</p> @@ -4747,27 +3118,6 @@ declaring C names in headers. <p><b>Proposed resolution:</b></p> <hr> -<a name="457"><h3>457. bitset constructor: incorrect number of initialized bits</h3></a><p><b>Section:</b> 23.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Dag Henriksson <b>Date:</b> 30 Jan 2004</p> -<p> -The constructor from unsigned long says it initializes "the first M -bit positions to the corresponding bit values in val. M is the smaller -of N and the value CHAR_BIT * sizeof(unsigned long)." -</p> - -<p> -Object-representation vs. value-representation strikes again. CHAR_BIT * -sizeof (unsigned long) does not give us the number of bits an unsigned long -uses to hold the value. Thus, the first M bit position above is not -guaranteed to have any corresponding bit values in val. -</p> -<p><b>Proposed resolution:</b></p> -<p>In 23.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</a> paragraph 2, change "M is the smaller of - N and the value CHAR_BIT * sizeof (unsigned long). (249)" to - "<tt>M</tt> is the smaller of <tt>N</tt> and the number of bits in - the value representation (section 3.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/basic.html#basic.types"> [basic.types]</a>) of <tt>unsigned - long</tt>." -</p> -<hr> <a name="458"><h3>458. 24.1.5 contains unintented limitation for operator-</h3></a><p><b>Section:</b> 24.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Daniel Frey <b>Date:</b> 27 Feb 2004</p> <p> In 24.1.5 [lib.random.access.iterators], table 76 the operational @@ -4874,32 +3224,7 @@ technique to perform the comparison:</p> if it the source and destination types are the same</li> </ol> <hr> -<a name="460"></a><h3><a name="460">460. Default modes missing from basic_fstream member specifications</a></h3><p><b>Section:</b> 27.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Ben Hutchings <b>Date:</b> 1 Apr 2004</p> -<p> -The second parameters of the non-default constructor and of the open -member function for basic_fstream, named "mode", are optional -according to the class declaration in 27.8.1.11 [lib.fstream]. The -specifications of these members in 27.8.1.12 [lib.fstream.cons] and -27.8.1.13 lib.fstream.members] disagree with this, though the -constructor declaration has the "explicit" function-specifier implying -that it is intended to be callable with one argument. -</p> -<p><b>Proposed resolution:</b></p> -<p>In 27.8.1.12 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstream.cons"> [lib.fstream.cons]</a>, change</p> -<pre> explicit basic_fstream(const char* s, ios_base::openmode mode); -</pre> -<p>to</p> -<pre> explicit basic_fstream(const char* s, - ios_base::openmode mode = ios_base::in|ios_base::out); -</pre> -<p>In 27.8.1.13 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstream.members"> [lib.fstream.members]</a>, change</p> -<pre> void open(const char*s, ios_base::openmode mode); -</pre> -<p>to</p> - void open(const char*s, - ios_base::openmode mode = ios_base::in|ios_base::out); -<hr> -<a name="461"></a><h3><a name="461">461. time_get hard or impossible to implement</a></h3><p><b>Section:</b> 22.2.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.get.virtuals"> [lib.locale.time.get.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 23 Mar 2004</p> +<a name="461"><h3>461. time_get hard or impossible to implement</h3></a><p><b>Section:</b> 22.2.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.get.virtuals"> [lib.locale.time.get.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 23 Mar 2004</p> <p> Template time_get currently contains difficult, if not impossible, requirements for do_date_order, do_get_time, and do_get_date. All require @@ -4952,34 +3277,36 @@ encounters an error or end of sequence. <p><b>to:</b> "%H:%M:%S"</p> -<p><b>In the description:</b></p> +<p>Change</p> <pre>iter_type do_get_date(iter_type s, iter_type end, ios_base& str, ios_base::iostate& err, tm* t) const; -</pre> -<p> -4 Effects: Reads characters starting at suntil it has extracted those + +4 Effects: Reads characters starting at s until it has extracted those struct tm members, and remaining format characters, used by time_put<>::put to produce the format specified by 'x', or until it encounters an error. -</p> +</pre> -<p> -<b>change:</b> used by time_put<>::put to produce the format -specified by 'x', or until it encounters an error. -</p> +<p>to</p> +iter_type do_get_date(iter_type s, iter_type end, ios_base& str, + ios_base::iostate& err, tm* t) const; -<p><b>to:</b> used by time_put<>:: put to produce one of the -following formats, or until it encounters an error. The format depends -on the value returned by date_order() as follows: -</p> -<pre> date_order() format +4 Effects: Reads characters starting at s until it has extracted those +struct tm members, and remaining format characters, used by +time_put<>::put to produce one of the following formats, or until it +encounters an error. The format depends on the value returned by +date_order() as follows: + + date_order() format no_order "%m/%d/%y" dmy "%d/%m/%y" mdy "%m/%d/%y" ymd "%y/%m/%d" ydm "%y/%d/%m" -</pre> + +An implementation may also accept additional implementation-defined formats. +<pre></pre> <p><i>[Redmond: agreed that this is a real problem. The solution is probably to match C99's parsing rules. Bill provided wording. @@ -5274,7 +3601,7 @@ from r-value derived to base). want to fix auto_ptr for C++-0x, or remove it and replace it with move_ptr and unique_ptr.]</i></p> <hr> -<a name="464"><h3>464. Suggestion for new member functions in standard containers</h3></a><p><b>Section:</b> 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>, 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 12 May 2004</p> +<a name="464"><h3>464. Suggestion for new member functions in standard containers</h3></a><p><b>Section:</b> 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>, 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 12 May 2004</p> <p>To add slightly more convenience to vector<T> and map<Key,T> we should consider to add</p> <ol> @@ -5312,7 +3639,7 @@ at() (which will then throw if the vector is empty). </li> const_pointer data() const; </pre> <p><b>Returns:</b> A pointer such that [data(), data() + size()) is a valid - range that contains the same elements as [begin(), end()).</p> + range. For a non-empty vector, data() == &front().</p> <p><b>Complexity:</b> Constant time.</p> <p><b>Throws:</b> Nothing.</p> </blockquote> @@ -5341,7 +3668,7 @@ synopsis immediately after the line for operator[]:</p> exception type chosen for <tt>at</tt>, <tt>std::out_of_range</tt>, was chosen to match <tt>vector::at</tt>.</p> <hr> -<a name="465"><h3>465. Contents of <ciso646></h3></a><p><b>Section:</b> 17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 3 Jun 2004</p> +<a name="465"><h3>465. Contents of <ciso646></h3></a><p><b>Section:</b> 17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 3 Jun 2004</p> <p>C header <iso646.h> defines macros for some operators, such as not_eq for !=.</p> @@ -5404,7 +3731,7 @@ ambiguate any other legal ctors.</p> value is a null pointer), at run time, or both.]</i></p> <hr> -<a name="467"><h3>467. char_traits::lt(), compare(), and memcmp()</h3></a><p><b>Section:</b> 21.1.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits.specializations.char"> [lib.char.traits.specializations.char]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 Jun 2004</p> +<a name="467"><h3>467. char_traits::lt(), compare(), and memcmp()</h3></a><p><b>Section:</b> 21.1.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits.specializations.char"> [lib.char.traits.specializations.char]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 Jun 2004</p> <p> Table 37 describes the requirements on Traits::compare() in terms of @@ -5434,7 +3761,7 @@ imposed by Table 37 on compare() when char is signed. <p>to</p> <blockquote> The two-argument member assign is defined identically to - the built-in operators = and == respectively. The two + the built-in operator =. The two argument members eq and lt are defined identically to the built-in operators == and < for type unsigned char. </blockquote> @@ -5444,7 +3771,7 @@ imposed by Table 37 on compare() when char is signed. Post-Redmond: Martin provided wording.]</i></p> <hr> -<a name="468"><h3>468. unexpected consequences of ios_base::operator void*()</h3></a><p><b>Section:</b> 27.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostate.flags"> [lib.iostate.flags]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 Jun 2004</p> +<a name="468"><h3>468. unexpected consequences of ios_base::operator void*()</h3></a><p><b>Section:</b> 27.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostate.flags"> [lib.iostate.flags]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 Jun 2004</p> <p>The program below is required to compile but when run it typically produces unexpected results due to the user-defined conversion from @@ -5476,41 +3803,31 @@ the value need not be valid. <pre> operator void*() const; </pre> <p>to</p> -<pre> operator unspecified_pointer_type () const; +<pre> operator unspecified-bool-type() const; </pre> <p>and change [lib.iostate.flags], p1 from</p> <pre> operator void*() const; </pre> <p>to</p> -<pre> operator unspecified_pointer_type() const; - -1- Returns: If fail() then a null pointer; otherwise some - non-null but not necessarily valid pointer to indicate - success. - -2- Note: The type named unspecified_pointer_type above is a pointer - to some unspecified, possibly incomplete type, that is guaranteed - not to be convertible to any other type except bool.(Footnote 1) - -- - Footnote 1: A pointer-to-member might be one such suitable type. -</pre> +<pre>operator unspecified-bool-type() const; -<p><i>[Redmond: 5-4 straw poll in favor of doing this.]</i></p> + -1- Returns: if fail() then a value that will evaluate false in a + boolean context; otherwise a value that will evaluate true in a + boolean context. The value type returned shall not be + convertible to int. -<hr> -<a name="469"><h3>469. vector<bool> ill-formed relational operators</h3></a><p><b>Section:</b> 23.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.bool"> [lib.vector.bool]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 Jun 2004</p> + -2- [Note: This conversion can be used in contexts where a bool + is expected (e.g., an if condition); however, implicit + conversions (e.g., to int) that can occur with bool are not + allowed, eliminating some sources of user error. One possible + implementation choice for this type is pointer-to-member. - end + note] +</pre> -<p> -The overloads of relational operators for vector<bool> specified -in [lib.vector.bool] are redundant (they are semantically identical -to those provided for the vector primary template) and may even be -diagnosed as ill-formed (refer to Daveed Vandevoorde's explanation -in c++std-lib-13647). -</p> +<p><i>[Redmond: 5-4 straw poll in favor of doing this.]</i></p> +<p><i>[Lillehammer: Doug provided revised wording for + "unspecified-bool-type".]</i></p> -<p><b>Proposed resolution:</b></p> -<p> -Remove all overloads of overloads of relational operators for -vector<bool> from [lib.vector.bool]. -</p> <hr> <a name="470"><h3>470. accessing containers from their elements' special functions</h3></a><p><b>Section:</b> 23 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.containers"> [lib.containers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 Jun 2004</p> @@ -5583,21 +3900,7 @@ ctor was called). <p><b>Proposed resolution:</b></p> <hr> -<a name="472"></a><h3><a name="472">472. Missing "Returns" clause in std::equal_range</a></h3><p><b>Section:</b> 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Prateek R Karandikar <b>Date:</b> 29 Feb 1900</p> -<p> -There is no "Returns:" clause for std::equal_range, which returns non-void. -</p> -<p><b>Proposed resolution:</b></p> -<p>In 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>, change</p> -<blockquote> - <b>Effects:</b> Finds the largest subrange [i, j)... -</blockquote> -<p>to</p> -<blockquote> - <b>Returns:</b> The largest subrange [i, j)... -</blockquote> -<hr> -<a name="473"><h3>473. underspecified ctype calls</h3></a><p><b>Section:</b> 22.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype"> [lib.locale.ctype]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 1 Jul 2004</p> +<a name="473"><h3>473. underspecified ctype calls</h3></a><p><b>Section:</b> 22.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype"> [lib.locale.ctype]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 1 Jul 2004</p> <p> Most ctype member functions come in two forms: one that operates on a single character at a time and another form that operates @@ -5658,41 +3961,21 @@ up in an infinite loop if the called form of the base implementation of the function in turn calls the other form. </p> <p><b>Proposed resolution:</b></p> -<p> -To fix these problems I propose the following: -</p> -<p> -Add two paragraphs immediately after 22.2.1.1 [lib.locale.ctype], -p2, with the following text: -</p> - -<pre> -3- Each ctype non-virtual member function that comes in two forms, - one that takes a range of elements of char_type, and another - that takes just a single element of char_type, is required to - call the corresponding form of the virtual member function - with the same value of char_type to obtain the result. The - result for the same argument may be cached and returned from - subsequent calls to either form of the non-virtual member - function with that argument. - -4- For each ctype virtual member function that comes in two forms - (as explained above), the single element form is required to - produce the same result for a character c that the corresponding - array form produces for the array element with the same value as - c, and vice versa. - - -5- It is unspecified whether the array form of each virtual member - function calls the single-element virtual overload of the same - function in a loop, or whether the single element form calls - the array form with an array of a single element with the value - of its argument, or whether neither form calls the other. In - any case, an implementation is not permitted to make calls from - one form of any virtual member function to the corresponding - other form that is overridden in a derived class. -</pre> +<p> +Lillehammer: Part of this isn't a real problem. We already talk about +caching. 22.1.1/6 But part is a real problem. ctype virtuals may call +each other, so users don't know which ones to override to avoid avoid +infinite loops.</p> +<p>This is a problem for all facet virtuals, not just ctype virtuals, +so we probably want a blanket statement in clause 22 for all +facets. The LWG is leaning toward a blanket prohibition, that a +facet's virtuals may never call each other. We might want to do that +in clause 27 too, for that matter. A review is necessary. Bill will +provide wording.</p> <hr> -<a name="474"><h3>474. confusing Footnote 297</h3></a><p><b>Section:</b> 27.6.2.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 1 Jul 2004</p> +<a name="474"><h3>474. confusing Footnote 297</h3></a><p><b>Section:</b> 27.6.2.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 1 Jul 2004</p> <p> I think Footnote 297 is confused. The paragraph it applies to seems @@ -5705,7 +3988,7 @@ value of widen(c) is otherwise. I propose to strike the Footnote. </p> <hr> -<a name="475"><h3>475. May the function object passed to for_each modify the elements of the iterated sequence?</h3></a><p><b>Section:</b> 25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Stephan T. Lavavej, Jaakko Jarvi <b>Date:</b> 9 Jul 2004</p> +<a name="475"><h3>475. May the function object passed to for_each modify the elements of the iterated sequence?</h3></a><p><b>Section:</b> 25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Stephan T. Lavavej, Jaakko Jarvi <b>Date:</b> 9 Jul 2004</p> <p> It is not clear whether the function object passed to for_each is allowed to modify the elements of the sequence being iterated over. @@ -5764,78 +4047,19 @@ We suggest that the standard be clarified to explicitly allow the function objec passed to for_each modify its argument.</p> <p><b>Proposed resolution:</b></p> -<p>Add the following sentence to the Effects in 25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a>:</p> - -<blockquote> -"f may apply non-constant functions through the dereferenced iterators -passed to it; if it does, the type of first shall satisfy the requirements -of a mutable iterator (24.1)." -</blockquote> - -<hr> -<a name="476"><h3>476. Forward Iterator implied mutability</h3></a><p><b>Section:</b> 24.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.forward.iterators"> [lib.forward.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 9 Jul 2004</p> - -<p>24.1/3 says:</p> -<blockquote> - Forward iterators satisfy all the requirements of the input and - output iterators and can be used whenever either kind is specified -</blockquote> - -<p> -The problem is that satisfying the requirements of output iterator -means that you can always assign *something* into the result of -dereferencing it. That makes almost all non-mutable forward -iterators non-conforming. I think we need to sever the refinement -relationship between forward iterator and output iterator. +<p>Add a nonnormative note to the Effects in 25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a>: If +the type of 'first' satisfies the requirements of a mutable iterator, +'f' may apply nonconstant functions through the dereferenced iterators +passed to it. </p> -<p><b>Proposed resolution:</b></p> -<p>in 24.1/3, replace:</p> -<blockquote> - Forward iterators satisfy all the requirements of the input and - output iterators and can be used whenever either kind is specified. -</blockquote> -<p>with</p> -<blockquote> - A forward iterator satisfies all the input iterator requirements. - A mutable forward iterator satisfies all the output iterator - requirements. -</blockquote> -<hr> -<a name="477"><h3>477. Operator-> for const forward iterators</h3></a><p><b>Section:</b> 24.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.forward.iterators"> [lib.forward.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 11 Jul 2004</p> -<p> -The Forward Iterator requirements table contains the following: -</p> -<pre> expression return type operational precondition - semantics - ========== ================== =========== ========================== - a->m U& if X is mutable, (*a).m pre: (*a).m is well-defined. - otherwise const U& - - r->m U& (*r).m pre: (*r).m is well-defined. -</pre> - -<p> -The first line is exactly right. The second line is wrong. Basically -it implies that the const-ness of the iterator affects the const-ness -of referenced members. But Paragraph 11 of [lib.iterator.requirements] says: -</p> - -<blockquote> - In the following sections, a and b denote values of type const X, n - denotes a value of the difference type Distance, u, tmp, and m - denote identifiers, r denotes a value of X&, t denotes a value of - value type T, o denotes a value of some type that is writable to - the output iterator. -</blockquote> - -<p>AFAICT if we need the second line at all, it should read the same -as the first line.</p> - -<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#478">478</a></p> -<p><b>Proposed resolution:</b></p> +<p><b>Rationale:</b></p> +<p>The LWG believes that nothing in the standard prohibits function + objects that modify the sequence elements. The problem is that + for_each is in a secion entitled "nonmutating algorithms", and the + title may be confusing. A nonnormative note should clarify that.</p> <hr> -<a name="478"></a><h3><a name="478">478. Should forward iterator requirements table have a line for r->m?</a></h3><p><b>Section:</b> 24.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.forward.iterators"> [lib.forward.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 11 Jul 2004</p> +<a name="478"><h3>478. Should forward iterator requirements table have a line for r->m?</h3></a><p><b>Section:</b> 24.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.forward.iterators"> [lib.forward.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 11 Jul 2004</p> <p> The Forward Iterator requirements table contains the following: </p> @@ -5864,9 +4088,13 @@ The Forward Iterator requirements table contains the following: Because operators can be overloaded on an iterator's const-ness, the current requirements allow iterators to make many of the operations specified using the identifiers a and b invalid for non-const -iterators. Rather than expanding the tables, I think the right -answer is to change -</p> +iterators.</p> + +<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#477">477</a></p> +<p><b>Proposed resolution:</b></p> + +<p>Remove the "r->m" line from the Forward Iterator requirements +table. Change</p> <blockquote> "const X" </blockquote> @@ -5879,10 +4107,9 @@ answer is to change <p>in paragraph 11 of [lib.iterator.requirements].</p> -<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#477">477</a></p> -<p><b>Proposed resolution:</b></p> + <hr> -<a name="479"><h3>479. Container requirements and placement new</h3></a><p><b>Section:</b> 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Herb Sutter <b>Date:</b> 1 Aug 2004</p> +<a name="479"><h3>479. Container requirements and placement new</h3></a><p><b>Section:</b> 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Herb Sutter <b>Date:</b> 1 Aug 2004</p> <p>Nothing in the standard appears to make this program ill-formed:</p> <pre> struct C { @@ -5900,76 +4127,21 @@ answer is to change to require containers to support types that define their own special versions of <tt>operator new</tt>.</p> -<p><b>Proposed resolution:</b></p> -<hr> -<a name="480"><h3>480. unary_function and binary_function should have protected nonvirtual destructors</h3></a><p><b>Section:</b> 20.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.base"> [lib.base]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Joe Gottman <b>Date:</b> 19 Aug 2004</p> -<p>The classes std::unary_function and std::binary_function are both -designed to be inherited from but contain no virtual functions. This -makes it too easy for a novice programmer to write code like -binary_function<int, int, int> *p = new plus<int>; delete p;</p> - -<p>There are two common ways to prevent this source of undefined -behavior: give the base class a public virtual destructor, or give it -a protected nonvirtual destructor. Since unary_function and -binary_function have no other virtual functions, (note in particular -the absence of an operator()() ), it would cost too much to give them -public virtual destructors. Therefore, they should be given protected -nonvirtual destructors.</p> -<p><b>Proposed resolution:</b></p> -<p>Change Paragraph 20.3.1 of the Standard from</p> -<pre> template <class Arg, class Result> - struct unary_function { - typedef Arg argument_type; - typedef Result result_type; - }; - - template <class Arg1, class Arg2, class Result> - struct binary_function { - typedef Arg1 first_argument_type; - typedef Arg2 second_argument_type; - typedef Result result_type; - }; -</pre> - -<p>to</p> -<pre> template <class Arg, class Result> - struct unary_function { - typedef Arg argument_type; - typedef Result result_type; - protected: - ~unary_function() {} - }; - - template <class Arg1, class Arg2, class Result> - struct binary_function { - typedef Arg1 first_argument_type; - typedef Arg2 second_argument_type; - typedef Result result_type; - protected: - ~binary_function() {} - }; -</pre> -<hr> -<a name="481"><h3>481. unique's effects on the range [result, last)</h3></a><p><b>Section:</b> 25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 30 Aug 2004</p> -<p> -The standard says that unique(first, last) "eliminates all but the -first element from every consecutive group of equal elements" in -[first, last) and returns "the end of the resulting range". So a -postcondition is that [first, result) is the same as the old [first, -last) except that duplicates have been eliminated. -</p> - -<p>What postconditions are there on the range [result, last)? One - might argue that the standard says nothing about those values, so - they can be anything. One might also argue that the standard - doesn't permit those values to be changed, so they must not be. - Should the standard say something explicit one way or the other?</p> +<notes> +Lillehammer: A container will definitely never use this overridden +operator new, but whether it will fail to compile is unclear from the +standard. Are containers supposed to use qualified or unqualified +placement new? 20.4.1.1 is somewhat relevant, but the standard +doesn't make it completely clear whether containers have to use +Allocator::construct(). If containers don't use it, the details of how +containers use placement new are unspecified. That is the real bug, +but it needs to be fixed as part of the allocator overhaul. Weak +support that the eventual solution should make this code well formed. +</notes> <p><b>Proposed resolution:</b></p> -<p> -</p> <hr> -<a name="482"><h3>482. Swapping pairs</h3></a><p><b>Section:</b> 20.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.pairs"> [lib.pairs]</a>, 25.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.swap"> [lib.alg.swap]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 14 Sep 2004</p> +<a name="482"><h3>482. Swapping pairs</h3></a><p><b>Section:</b> 20.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.pairs"> [lib.pairs]</a>, 25.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.swap"> [lib.alg.swap]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 14 Sep 2004</p> <p>(Based on recent comp.std.c++ discussion)</p> <p>Pair (and tuple) should specialize std::swap to work in terms of @@ -5977,8 +4149,13 @@ std::swap on their components. For example, there's no obvious reason why swapping two objects of type pair<vector<int>, list<double> > should not take O(1).</p> <p><b>Proposed resolution:</b></p> + + +<p><i>[Lillehammer: We agree it should be swappable. Howard will + provide wording.]</i></p> + <hr> -<a name="484"><h3>484. Convertible to T</h3></a><p><b>Section:</b> 24.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Chris <b>Date:</b> 16 Sep 2004</p> +<a name="484"><h3>484. Convertible to T</h3></a><p><b>Section:</b> 24.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Chris <b>Date:</b> 16 Sep 2004</p> <p>From comp.std.c++:</p> <p> @@ -6017,10 +4194,12 @@ class I expect?</p> to T".</p> <p><b>Proposed resolution:</b></p> -<p> -</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> <hr> -<a name="485"><h3>485. output iterator insufficently constrained</h3></a><p><b>Section:</b> 24.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.output.iterators"> [lib.output.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Chris <b>Date:</b> 13 Oct 2004</p> +<a name="485"><h3>485. output iterator insufficently constrained</h3></a><p><b>Section:</b> 24.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.output.iterators"> [lib.output.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Chris <b>Date:</b> 13 Oct 2004</p> <p> The note on 24.1.2 Output iterators insufficently limits what can be performed on output iterators. While it requires that each iterator is @@ -6048,48 +4227,11 @@ wording (I believe) x,a,b,c could be written to in any order. <p>I do not believe this was the intension of the standard?</p> <p><b>Proposed resolution:</b></p> -<p>Add to the note:</p> - -<p>"The values of an output iterator must be assigned to in the order they -are generated. It is undefined to progress forward more than once from a -value of an output iterator which has not yet been assigned."</p> - -<p>This is I believe the intension of the existing text. The "progress -forward once" is allowed so that "*r++=t" is allowed. It may be prefered -to instead allow something more along the lines of:</p> - -<p>"The values of an output iterator must be assigned to in the order they -are generated. With the exception of '*r++=t', an iterator must always -be assigned to before it is incremented".</p> +<p><i>[Lillehammer: Real issue. There are lots of constraints we + intended but didn't specify. Should be solved as part of iterator + redesign.]</i></p> <hr> -<a name="487"><h3>487. Allocator::construct is too limiting</h3></a><p><b>Section:</b> 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Dhruv Matani <b>Date:</b> 17 Oct 2004</p> -<p> -The standard's version of allocator::construct(pointer, -const_reference) severely limits what you can construct using this -function. Say you can construct a socket from a file descriptor. Now, -using this syntax, I first have to manually construct a socket from -the fd, and then pass the constructed socket to the construct() -function so it will just to an uninitialized copy of the socket I -manually constructed. Now it may not always be possible to copy -construct a socket eh! So, I feel that the changes should go in the -allocator::construct(), making it: -</p> -<pre> template<typename T> - struct allocator{ - template<typename T1> - void construct(pointer T1 const& rt1); - }; -</pre> - -<p> -Now, the ctor of the class T which matches the one that takes a T1 can -be called! Doesn't that sound great? -</p> -<p><b>Proposed resolution:</b></p> -<p> -</p> -<hr> -<a name="488"><h3>488. rotate throws away useful information</h3></a><p><b>Section:</b> 25.2.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.rotate"> [lib.alg.rotate]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 22 Nov 2004</p> +<a name="488"><h3>488. rotate throws away useful information</h3></a><p><b>Section:</b> 25.2.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.rotate"> [lib.alg.rotate]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 22 Nov 2004</p> <p> rotate takes 3 iterators: first, middle and last which point into a sequence, and rearranges the sequence such that the subrange [middle, @@ -6121,7 +4263,7 @@ and the resulting program becomes significantly more efficient. <p> While the backwards compatibility hit with this change is not zero, it -is very small (similar to that of lwg <ire ref="130"></ire>), and there is +is very small (similar to that of lwg <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>), and there is a significant benefit to the change. </p> @@ -6156,614 +4298,21 @@ a significant benefit to the change. <p>In 25.2.10 insert a new paragraph after p1:</p> <blockquote> -<p><b>Returns</b>: advance(first, distance(middle, last)).</p> +<p><b>Returns</b>: <tt>first + (last - middle)</tt>.</p> </blockquote> -<hr> -<a name="489"><h3>489. std::remove / std::remove_if wrongly specified</h3></a><p><b>Section:</b> 25.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Thomas Mang <b>Date:</b> 12 Dec 2004</p> -<p>In Section 25.2.7 [lib.alg.remove], paragraphs 1 to 5 describe the -behavior of the mutating sequence operations std::remove and -std::remove_if. However, the wording does not reflect the intended -behavior [Note: See definition of intended behavior below] of these -algorithms, as it is known to the C++ community [1]. -</p> - - - -<p>1) Analysis of current wording:</p> - - -<p>25.2.7 [lib.alg.remove], paragraph 2:</p> - -<p>Current wording says: -"Effects: Eliminates all the elements referred to by iterator i in the -range [first, last) for which the following corresponding conditions -hold: *i == value, pred(*i) != false."</p> - -<p> -This sentences expresses specifically that all elements denoted by the -(original) range [first, last) for which the corresponding condition -hold will be eliminated. Since there is no formal definition of the term -"eliminate" provided, the meaning of "eliminate" in everyday language -implies that as postcondition, no element in the range denoted by -[first, last) will hold the corresponding condition on reiteration over -the range [first, last). -</p> - -<p> -However, this is neither the intent [Note: See definition of intended -behavior below] nor a general possible approach. It can be easily proven -that if all elements of the original range[first, last) will hold the -condition, it is not possible to substitute them by an element for which -the condition will not hold. -</p> - - -<p>25.2.7 [lib.alg.remove], paragraph 3:</p> - -<p> -Current wording says: -"Returns: The end of the resulting range." -</p> - -<p> -The resulting range is not specified. In combination with 25.2.7 -[lib.alg.remove], paragraph 2, the only reasonable interpretation of -this so-called resulting range is the range [first,last) - thus -returning always the ForwardIterator 'last' parameter. -</p> - - -<p> -25.2.7 [lib.alg.remove], paragraph 4: -</p> - -<p> -Current wording says: -"Notes: Stable: the relative order of the elements that are not removed -is the same as their relative order in the original range" -</p> - -<p> -This sentences makes use of the term "removed", which is neither -specified, nor used in a previous paragraph (which uses the term -"eliminate"), nor unamgiuously separated from the name of the algorithm. -</p> - - -<p>2) Description of intended behavior:</p> - -<p> -For the rest of this Defect Report, it is assumed that the intended -behavior was that all elements of the range [first, last) which do not -hold the condition *i == value (std::remove) or pred(*i) != false -(std::remove_if)], call them s-elements [Note: s...stay], will be placed -into a contiguous subrange of [first, last), denoted by the iterators -[first, return value). The number of elements in the resulting range -[first, return value) shall be equal to the number of s-elements in the -original range [first, last). The relative order of the elements in the -resulting subrange[first, return value) shall be the same as the -relative order of the corresponding elements in the original range. It -is undefined whether any elements in the resulting subrange [return -value, last) will hold the corresponding condition, or not. -</p> - -<p> -All implementations known to the author of this Defect Report comply -with this intent. Since the intent of the behavior (contrary to the -current wording) is also described in various utility references serving -the C++ community [1], it is not expected that fixing the paragraphs -will influence current code - unless the code relies on the behavior as -it is described by current wording and the implementation indeed -reflects the current wording, and not the intent. -</p> - - - -<p>3) Proposed fixes:</p> - - -<p>Change 25.2.7 [lib.alg.remove], paragraph 2 to:</p> - -<p> -"Effect: Places all the elements referred to by iterator i in the range -[first, last) for which the following corresponding conditions hold : -!(*i == value), pred(*i) == false into the subrange [first, k) of the -original range, where k shall denote a value of type ForwardIterator. It -is undefined whether any elements in the resulting subrange [k, last) -will hold the corresponding condition, or not." -</p> - -<p>Comments to the new wording:</p> - -<p> -a) "Places" has no special meaning, and the everyday language meaning -should fit. -b) The corresponding conditions were negated compared to the current -wording, becaue the new wording requires it. -c) The wording "of the original range" might be redundant, since any -subrange starting at 'first' and containing no more elements than the -original range is implicitly a subrange of the original range [first, -last). -d) The iterator k was introduced instead of "return value" in order to -avoid a cyclic dependency on 25.2.7/3. The wording ", where k shall -denote a value of type ForwardIterator" might be redundant, because it -follows implicitly by 25.2.7/3. -e) "Places" does, in the author's opinion, explicitly forbid duplicating -any element holding the corresponding condition in the original range -[first, last) within the resulting range [first, k). If there is doubt -this term might be not unambiguous regarding this, it is suggested that -k is specified more closely by the following wording: "k shall denote a -value of type ForwardIterator [Note: see d)] so that k - first is equal -to the number of elements in the original range [first, last) for which -the corresponding condition did hold". This could also be expressed as a -separate paragraph "Postcondition:" -f) The senctence "It is undefined whether any elements in the resulting -subrange [k, last) will hold the corresponding condition, or not." was -added consciously so the term "Places" does not imply if the original -range [first, last) contains n elements holding the corresponding -condition, the identical range[first, last) will also contain exactly n -elements holding the corresponding condition after application of the -algorithm. -</p> - -<p> -Change 25.2.7 [lib.alg.remove], paragraph 3 to: - -"Returns: The iterator k." -</p> - -<p> -Change 25.2.7 [lib.alg.remove], paragraph 4 to: - -"Notes: Stable: the relative order of the elements that are placed into -the subrange [first, return value) shall be the same as their relative -order was in the original range [first, last) prior to application of -the algorithm." -</p> - -<p> -Comments to the new wording: -</p> - -<p> -a) the wording "was ... prior to application of the algorithm" is used -to explicitly distinguish the original range not only by means of -iterators, but also by a 'chronological' factor from the resulting range -[first, return value). It might be redundant. -</p> - -<p> -[1]: -The wording of these references is not always unambiguous, and provided -examples partially contradict verbal description of the algorithms, -because the verbal description resembles the problematic wording of -ISO/IEC 14882:2003. -</p> -<p><b>Proposed resolution:</b></p> -<p> -</p> -<hr> -<a name="490"><h3>490. std::unique wrongly specified</h3></a><p><b>Section:</b> 25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Thomas Mang <b>Date:</b> 12 Dec 2004</p> -<p>In Section 25.2.8 [lib.alg.unique], paragraphs 1 to 3 describe the -behavior of the mutating sequence operation std::unique. However, the -wording does not reflect the intended behavior [Note: See definition of -intended behavior below] of these algorithms, as it is known to the C++ -community [1].</p> - - - -<p>1) Analysis of current wording:</p> - - -<p>25.2.8 [lib.alg.unique], paragraph 1:</p> - -<p> -Current wording says: -"Effects: Eliminates all but the first element from every consecutive -group of equal elements referred to by the iterator i in the range -[first, last) for which the following corresponding conditions hold: *i -== *(i - 1) or pred(*i, *(i -1)) != false" -</p> -<p> -This sentences expresses specifically that all elements denoted by the -(original) range [first, last) which are not but the first element from -a consecutive group of equal elements (where equality is defined as *i -== *(i - 1) or pred(*i, *(i - 1)) ! = false) [Note: See DR 202], call -them r-elements [Note: r...remove], will be eliminated. Since there is -no formal definition of the term "eliminate" provided, it is undefined -how this "elimination" takes place. But the meaning of "eliminate" in -everyday language seems to disallow explicitly that after application of -the algorithm, any r-element will remain at any position of the range -[first, last) [2]. -</p> - -<p> -Another defect in the current wording concerns the iterators used to -compare two elements for equality: The current wording contains the -expression "(i - 1)", which is not covered by 25/9 [Note: See DR -submitted by Thomas Mang regarding invalid iterator arithmetic -expressions]. -</p> - - -<p> -25.2.8 [lib.alg.unique], paragraph 2: -</p> -<p>Current wording says: -"Returns: The end of the resulting range."</p> - -<p> -The resulting range is not specified. In combination with 25.2.8 -[lib.alg.unique], paragraph 1, one reasonable interpretation (in the -author's opinion even the only possible interpretation) of this -so-called resulting range is the range [first, last) - thus returning -always the ForwardIterator 'last' parameter. -</p> - -<p>2) Description of intended behavior:</p> - -<p> -For the rest of this Defect Report, it is assumed that the intended -behavior was that all elements denoted by the original range [first, -last) which are the first element from a consecutive group of elements -for which the corresponding conditions: *(i-1) == *i (for the version of -unique without a predicate argument) or pred(*(i-1), *i) ! = false (for -the version of unique with a predicate argument) [Note: If such a group -of elements consists of only a single element, this is also considered -the first element] [Note: See resolutions of DR 202], call them -s-elements [Note: s...stay], will be placed into a contiguous subrange -of [first, last), denoted by the iterators [first, return value). The -number of elements in the resulting range [first, return value) shall be -equal to the number of s-elements in the original range [first, last). -Invalid iterator arithmetic expressions are expected to be resolved as -proposed in DR submitted by Thomas Mang regarding invalid iterator -arithmetic expressions. It is also assumed by the author that the -relative order of the elements in the resulting subrange [first, return -value) shall be the same as the relative order of the corresponding -elements (the s-elements) in the original range [Note: If this was not -intended behavior, the additional proposed paragraph about stable order -will certainly become obsolete]. -Furthermore, the resolutions of DR 202 are partially considered. -</p> - -<p> -All implementations known to the author of this Defect Report comply -with this intent [Note: Except possible effects of DR 202]. Since this -intent of the behavior (contrary to the current wording) is also -described in various utility references serving the C++ community [1], -it is not expected that fixing the paragraphs will influence current -code [Note: Except possible effects of DR 202] - unless the code relies -on the behavior as it is described by current wording and the -implementation indeed reflects the current wording, and not the intent. -</p> - - - -<p>3) Proposed fixes:</p> - -<p> -Change 25.2.8 [lib.alg.unique], paragraph 1 to: -</p> - -<p> -"Effect: Places the first element from every consecutive group of -elements, referred to by the iterator i in the range [first, last), for -which the following conditions hold: *(i-1) == *i (for the version of -unique without a predicate argument) or pred(*(i -1), *i) != false (for -the version of unique with a predicate argument), into the subrange -[first, k) of the original range, where k shall denote a value of type -ForwardIterator." -</p> - -<p>Comments to the new wording:</p> - -<p> -a) The new wording was influenced by the resolutions of DR 202. If DR -202 is resolved in another way, the proposed wording need also -additional review. -b) "Places" has no special meaning, and the everyday language meaning -should fit. -c) The expression "(i - 1)" was left, but is expected that DR submitted -by Thomas Mang regarding invalid iterator arithmetic expressions will -take this into account. -d) The wording "(for the version of unique without a predicate -argument)" and "(for the version of unique with a predicate argument)" -was added consciously for clarity and is in resemblence with current -23.2.2.4 [lib.list.ops], paragraph 19. It might be considered redundant. -e) The wording "of the original range" might be redundant, since any -subrange starting at first and containing no more elements than the -original range is implicitly a subrange of the original range [first, -last). -f) The iterator k was introduced instead of "return value" in order to -avoid a cyclic dependency on 25.2.8 [lib.alg.unique], paragraph 2. The -wording ", where k shall denote a value of type ForwardIterator" might -be redundant, because it follows implicitly by 25.2.8 [lib.alg.unique], -paragraph 2. -g) "Places" does, in the author's opinion, explicitly forbid duplicating -any s-element in the original range [first, last) within the resulting -range [first, k). If there is doubt this term might be not unambiguous -regarding this, it is suggested that k is specified more closely by the -following wording: "k shall denote a value of type ForwardIterator -[Note: See f)] so that k - first is equal to the number of elements in -the original range [first, last) being the first element from every -consecutive group of elements for which the corresponding condition did -hold". This could also be expressed as a separate paragraph -"Postcondition:". -h) If it is considered that the wording is unclear whether it declares -the element of a group which consists of only a single element -implicitly to be the first element of this group [Note: Such an -interpretation could eventually arise especially in case last - first == -1] , the following additional sentence is proposed: "If such a group of -elements consists of only a single element, this element is also -considered the first element." -</p> - -<p> -Change 25.2.8 [lib.alg.unique], paragraph 2 to: -"Returns: The iterator k." -</p> - -<p> -Add a separate paragraph "Notes:" as 25.2.8 [lib.alg.unique], paragraph -2a or 3a, or a separate paragraph "Postcondition:" before 25.2.8 -[lib.alg.unique], paragraph 2 (wording inside {} shall be eliminated if -the preceding expressions are used, or the preceding expressions shall -be eliminated if wording inside {} is used): -</p> - -<p> -"Notes:{Postcondition:} Stable: the relative order of the elements that -are placed into the subrange [first, return value {k}) shall be the same -as their relative order was in the original range [first, last) prior to -application of the algorithm." -</p> - -<p>Comments to the new wording:</p> - -<p> -a) It is assumed by the author that the algorithm was intended to be -stable. -In case this was not the intent, this paragraph becomes certainly -obsolete. -b) The wording "was ... prior to application of the algorithm" is used -to explicitly distinguish the original range not only by means of -iterators, but also by a 'chronological' factor from the resulting range -[first, return value). It might be redundant. -</p> - -<p> -25.2.8 [lib.alg.unique], paragraph 3: -</p> -<p>See DR 239.</p> - -<p> -4) References to other DRs: -</p> - -<p> -See DR 202, but which does not address any of the problems described in -this Defect Report [Note: This DR is supposed to complement DR 202]. -See DR 239. -See DR submitted by Thomas Mang regarding invalid iterator arithmetic -expressions. -</p> - -<p> -[1]: -The wording of these references is not always unambiguous, and provided -examples partially contradict verbal description of the algorithms, -because the verbal description resembles the problematic wording of -ISO/IEC 14882:2003. -</p> - -<p> -[2]: -Illustration of conforming implementations according to current wording: -</p> - -<p> -One way the author of this DR considers how this "elimination" could be -achieved by a conforming implementation according to current wording is -by substituting each r-element by _any_ s-element [Note: s...stay; any -non-r-element], since all r-elements are "eliminated". -</p> - -<p> -In case of a sequence consisting of elements being all 'equal' [Note: -See DR 202], substituting each r-element by the single s-element is the -only possible solution according to current wording. -</p> -<p><b>Proposed resolution:</b></p> -<p> -</p> -<hr> -<a name="491"><h3>491. std::list<>::unique incorrectly specified</h3></a><p><b>Section:</b> 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Thomas Mang <b>Date:</b> 12 Dec 2004</p> -<p>In Section 23.2.2.4 [lib.list.ops], paragraphs 19 to 21 describe the -behavior of the std::list<T, Allocator>::unique operation. However, the -current wording is defective for various reasons.</p> - - - -<p> -1) Analysis of current wording: -</p> - -<p>23.2.2.4 [lib.list.ops], paragraph 19:</p> - -<p> -Current wording says: -"Effects: Eliminates all but the first element from every consecutive -group of equal elements referred to by the iterator i in the range -[first + 1, last) for which *i == *(i - 1) (for the version of unique -with no argument) or pred(*i, *(i -1)) (for the version of unique with a -predicate argument) holds."</p> - -<p> -This sentences makes use of the undefined term "Eliminates". Although it -is, to a certain degree, reasonable to consider the term "eliminate" -synonymous with "erase", using "Erase" in the first place, as the -wording of 23.2.2.4 [lib.list.ops], paragraph 15 does, would be clearer.</p> - -<p> -The range of the elements referred to by iterator i is "[first + 1, -last)". However, neither "first" nor "last" is defined.</p> - -<p> -The sentence makes three times use of iterator arithmetic expressions ( -"first + 1", "*i == *(i - 1)", "pred(*i, *(i -1))" ) which is not -defined for bidirectional iterator [see DR submitted by Thomas Mang -regarding invalid iterator arithmetic expressions].</p> - -<p> -The same problems as pointed out in DR 202 (equivalence relation / order -of arguments for pred()) apply to this paragraph.</p> - -<p> -23.2.2.4 [lib.list.ops], paragraph 20: -</p> - -<p> -Current wording says: -"Throws: Nothing unless an exception in thrown by *i == *(i-1) or -pred(*i, *(i - 1))"</p> - -<p> -The sentence makes two times use of invalid iterator arithmetic -expressions ( "*i == *(i - 1)", "pred(*i, *(i -1))" ). -</p> -<p> -[Note: Minor typos: "in" / missing dot at end of sentence.] -</p> - -<p> -23.2.2.4 [lib.list.ops], paragraph 21:</p> - -<p> -Current wording says: -"Complexity: If the range (last - first) is not empty, exactly (last - -first) - 1 applications of the corresponding predicate, otherwise no -application of the predicate.</p> - -<p> -See DR 315 regarding "(last - first)" not yielding a range.</p> - -<p> -Invalid iterator arithmetic expression "(last - first) - 1" left .</p> - - -<p>2) Description of intended behavior:</p> - -<p> -For the rest of this Defect Report, it is assumed that "eliminate" is -supposed to be synonymous to "erase", that "first" is equivalent to an -iterator obtained by a call to begin(), "last" is equivalent to an -iterator obtained by a call to end(), and that all invalid iterator -arithmetic expressions are resolved as described in DR submitted by -Thomas Mang regarding invalid iterator arithmetic expressions.</p> - -<p> -Furthermore, the resolutions of DR 202 are considered regarding -equivalence relation and order of arguments for a call to pred.</p> - -<p> -All implementations known to the author of this Defect Report comply -with these assumptions, apart from the impact of the alternative -resolution of DR 202. Except for the changes implied by the resolutions -of DR 202, no impact on current code is expected.</p> - -<p> -3) Proposed fixes:</p> - -<p> -Change 23.2.2.4 [lib.list.ops], paragraph 19 to:</p> - -<p> -"Effect: Erases all but the first element from every consecutive group -of elements, referred to by the iterator i in the range [begin(), -end()), for which the following conditions hold: *(i-1) == *i (for the -version of unique with no argument) or pred(*(i-1), *i) != false (for -the version of unique with a predicate argument)."</p> - -<p> -Comments to the new wording:</p> - -<p> -a) The new wording was influenced by DR 202 and the resolutions -presented there. If DR 202 is resolved in another way, the proposed -wording need also additional review. -b) "Erases" refers in the author's opinion unambiguously to the member -function "erase". In case there is doubt this might not be unamgibuous, -a direct reference to the member function "erase" is suggested [Note: -This would also imply a change of 23.2.2.4 [lib.list.ops], paragraph -15.]. -c) The expression "(i - 1)" was left, but is expected that DR submitted -by Thomas Mang regarding invalid iterator arithmetic expressions will -take this into account. -d) The wording "(for the version of unique with no argument)" and "(for -the version of unique with a predicate argument)" was kept consciously -for clarity. -e) "begin()" substitutes "first", and "end()" substitutes "last". The -range need adjustment from "[first + 1, last)" to "[begin(), end())" to -ensure a valid range in case of an empty list. -f) If it is considered that the wording is unclear whether it declares -the element of a group which consists of only a single element -implicitly to be the first element of this group [Note: Such an -interpretation could eventually arise especially in case size() == 1] , -the following additional sentence is proposed: "If such a group of -elements consists of only a single element, this element is also -considered the first element."</p> - -<p> -Change 23.2.2.4 [lib.list.ops], paragraph 20 to:</p> - -<p> -"Throws: Nothing unless an exception is thrown by *(i-1) == *i or -pred(*(i-1), *i)."</p> - -<p> -Comments to the new wording:</p> - -<p> -a) The wording regarding the conditions is identical to proposed -23.2.2.4 [lib.list.ops], paragraph 19. If 23.2.2.4 [lib.list.ops], -paragraph 19 is resolved in another way, the proposed wording need also -additional review. -b) The expression "(i - 1)" was left, but is expected that DR submitted -by Thomas Mang regarding invalid iterator arithmetic expressions will -take this into account. -c) Typos fixed.</p> - -<p> -Change 23.2.2.4 [lib.list.ops], paragraph 21 to:</p> - -<p> -"Complexity: If empty() == false, exactly size() - 1 applications of the -corresponding predicate, otherwise no applications of the corresponding -predicate."</p> - -<p> -Comments to the new wording:</p> - -<p> -a) The new wording is supposed to also replace the proposed resolution -of DR 315, which suffers from the problem of undefined "first" / "last". -</p> - -<p> -5) References to other DRs:</p> +<p><i>[ +The LWG agrees with this idea, but has one quibble: we want to make +sure not to give the impression that the function "advance" is +actually called, just that the nth iterator is returned. (Calling +advance is observable behavior, since users can specialize it for +their own iterators.) Howard will provide wording. +]</i></p> -<p>See DR 202. -See DR 239. -See DR 315. -See DR submitted by Thomas Mang regarding invalid iterator arithmetic -expressions.</p> +<p><i>[Howard provided wording for mid-meeting-mailing Jun. 2005.]</i></p> -<p><b>Proposed resolution:</b></p> -<p> -</p> <hr> -<a name="492"><h3>492. Invalid iterator arithmetic expressions</h3></a><p><b>Section:</b> 23 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.containers"> [lib.containers]</a>, 24 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterators"> [lib.iterators]</a>, 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Thomas Mang <b>Date:</b> 12 Dec 2004</p> +<a name="492"><h3>492. Invalid iterator arithmetic expressions</h3></a><p><b>Section:</b> 23 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.containers"> [lib.containers]</a>, 24 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterators"> [lib.iterators]</a>, 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Thomas Mang <b>Date:</b> 12 Dec 2004</p> <p>Various clauses other than clause 25 make use of iterator arithmetic not supported by the iterator category in question. Algorithms in clause 25 are exceptional because of 25 [lib.algorithms], @@ -6923,78 +4472,14 @@ See DR 237. The resolution could then also read "Linear in last - first". </p> <p><b>Proposed resolution:</b></p> -<p> -</p> -<hr> -<a name="493"><h3>493. Undefined Expression in Input Iterator Note Title</h3></a><p><b>Section:</b> 24.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Chris Jefferson <b>Date:</b> 13 Dec 2004</p> -<p>1) In 24.1.1/3, the following text is currently present.</p> - -<p>"Note: For input iterators, a==b does not imply ++a=++b (Equality does -not guarantee the substitution property or referential transparency)."</p> - -<p>However, when in Table 72, part of the definition of ++r is given as:</p> - -<p>"pre: r is dereferenceable. -post: any copies of the previous value of r are no longer required -either to be dereferenceable ..."</p> - -<p>While a==b does not imply that b is a copy of a, this statement should -perhaps still be made more clear.</p> -<p>2) There are no changes to intended behaviour</p> +<p><i>[Lillehammer: Minor issue, but real. We have a blanket statement +about this in 25/11. But (a) it should be in 17, not 25; and (b) it's +not quite broad enough, because there are some arithmetic expressions +it doesn't cover. Bill will provide wording.]</i></p> -<p> -3) This Note should be altered to say "Note: For input iterators a==b, -when its behaviour is defined ++a==++b may still be false (Equality does -not guarantee the substitution property or referential transparency).</p> - -<p><b>Proposed resolution:</b></p> -<p> -</p> -<hr> -<a name="494"><h3>494. Wrong runtime complexity for associative container's insert and delete</h3></a><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Hans B os <b>Date:</b> 19 Dec 2004</p> -<p>According to [lib.associative.reqmts] table 69, the runtime comlexity -of insert(p, t) and erase(q) can be done in amortized constant time.</p> - -<p>It was my understanding that an associative container could be -implemented as a balanced binary tree.</p> - -<p>For inser(p, t), you 'll have to iterate to p's next node to see if t -can be placed next to p. Furthermore, the insertion usually takes -place at leaf nodes. An insert next to the root node will be done at -the left of the root next node</p> - -<p>So when p is the root node you 'll have to iterate from the root to -its next node, which takes O(log(size)) time in a balanced tree.</p> - -<p>If you insert all values with insert(root, t) (where root is the -root of the tree before insertion) then each insert takes O(log(size)) -time. The amortized complexity per insertion will be O(log(size)) -also.</p> - -<p>For erase(q), the normal algorithm for deleting a node that has no -empty left or right subtree, is to iterate to the next (or previous), -which is a leaf node. Then exchange the node with the next and delete -the leaf node. Furthermore according to DR 130, erase should return -the next node of the node erased. Thus erasing the root node, -requires iterating to the next node.</p> - -<p>Now if you empty a map by deleting the root node until the map is -empty, each operation will take O(log(size)), and the amortized -complexity is still O(log(size)).</p> - -<p>The operations can be done in amortized constant time if iterating -to the next node can be done in (non amortized) constant time. This -can be done by putting all nodes in a double linked list. This -requires two extra links per node. To me this is a bit overkill since -you can already efficiently insert or erase ranges with erase(first, -last) and insert(first, last).</p> - -<p><b>Proposed resolution:</b></p> -<p> -</p> <hr> -<a name="495"><h3>495. Clause 22 template parameter requirements</h3></a><p><b>Section:</b> 22 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.localization"> [lib.localization]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 10 Jan 2005</p> +<a name="495"><h3>495. Clause 22 template parameter requirements</h3></a><p><b>Section:</b> 22 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.localization"> [lib.localization]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 10 Jan 2005</p> <p>It appears that there are no requirements specified for many of the template parameters in clause 22. It looks like this issue has never come up, except perhaps for Facet.</p> @@ -7028,8 +4513,36 @@ text identifies the requirements for the name International but not for Intl.</li> </ul> <p><b>Proposed resolution:</b></p> +<p>Change 17.3.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.type.descriptions"> [lib.type.descriptions]</a>, paragraph 1, from:</p> +<blockquote> +The Requirements subclauses may describe names that are used to +specify constraints on template arguments.153) These names are used in +clauses 20, 23, 25, and 26 to describe the types that may be supplied +as arguments by a C++ program when instantiating template components +from the library. +</blockquote> +<p>to:</p> +<blockquote> +The Requirements subclauses may describe names that are used to +specify constraints on template arguments.153) These names are used in +library clauses to describe the types that may be supplied as +arguments by a C++ program when instantiating template components from +the library. +</blockquote> + +<p>In the front matter of class 22, locales, add:</p> +<blockquote> +Template parameter types internT and externT shall meet the +requirements of charT (described in 21 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.strings"> [lib.strings]</a>). +</blockquote> +<p><b>Rationale:</b></p> +<p> + Again, a blanket clause isn't blanket enough. Also, we've got a + couple of names that we don't have blanket requirement statements + for. The only issue is what to do about stateT. This wording is + thin, but probably adequate.</p> <hr> -<a name="496"><h3>496. Illegal use of "T" in vector<bool></h3></a><p><b>Section:</b> 23.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.bool"> [lib.vector.bool]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> richard@ex-parrot.com <b>Date:</b> 10 Feb 2005</p> +<a name="496"><h3>496. Illegal use of "T" in vector<bool></h3></a><p><b>Section:</b> 23.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.bool"> [lib.vector.bool]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> richard@ex-parrot.com <b>Date:</b> 10 Feb 2005</p> <p> In the synopsis of the std::vector<bool> specialisation in 23.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.bool"> [lib.vector.bool]</a>, the non-template assign() function has the signature</p> @@ -7037,9 +4550,341 @@ the non-template assign() function has the signature</p> <pre> void assign( size_type n, const T& t ); </pre> +<p>The type, T, is not defined in this context.</p> +<p><b>Proposed resolution:</b></p> +<p>Replace "T" with "value_type".</p> +<hr> +<a name="497"><h3>497. meaning of numeric_limits::traps for floating point types</h3></a><p><b>Section:</b> 18.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.numeric.limits.members"> [lib.numeric.limits.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2 Mar 2005</p> + +<p>18.2.1.2, p59 says this much about the traps member of numeric_limits:</p> + +<blockquote> +<p>static const bool traps;<br> +-59- true if trapping is implemented for the type.204) +<br> +Footnote 204: Required by LIA-1. +</p> +</blockquote> + +<p>It's not clear what is meant by "is implemented" here.</p> + +<p> +In the context of floating point numbers it seems reasonable to expect +to be able to use traps to determine whether a program can "safely" use +infinity(), quiet_NaN(), etc., in arithmetic expressions, that is +without causing a trap (i.e., on UNIX without having to worry about +getting a signal). When traps is true, I would expect any of the +operations in section 7 of IEEE 754 to cause a trap (and my program +to get a SIGFPE). So, for example, on Alpha, I would expect traps +to be true by default (unless I compiled my program with the -ieee +option), false by default on most other popular architectures, +including IA64, MIPS, PA-RISC, PPC, SPARC, and x86 which require +traps to be explicitly enabled by the program. +</p> + +<p> +Another possible interpretation of p59 is that traps should be true +on any implementation that supports traps regardless of whether they +are enabled by default or not. I don't think such an interpretation +makes the traps member very useful, even though that is how traps is +implemented on several platforms. It is also the only way to implement +traps on platforms that allow programs to enable and disable trapping +at runtime. +</p> +<p><b>Proposed resolution:</b></p> +<p>Change p59 to read:</p> +<blockquote>True if, at program startup, there exists a value of the type that + would cause an arithmetic operation using that value to trap.</blockquote> +<p><b>Rationale:</b></p> +<p> + Real issue, since trapping can be turned on and off. Unclear what a + static query can say about a dynamic issue. The real advice we should + give users is to use cfenv for these sorts of queries. But this new + proposed resolution is at least consistent and slightly better than + nothing.</p> +<hr> +<a name="498"><h3>498. Requirements for partition() and stable_partition() too strong</h3></a><p><b>Section:</b> 25.2.12 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.partitions"> [lib.alg.partitions]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Sean Parent, Joe Gottman <b>Date:</b> 4 May 2005</p> +<p> +Problem: +The iterator requirements for partition() and stable_partition() [25.2.12] +are listed as BidirectionalIterator, however, there are efficient algorithms +for these functions that only require ForwardIterator that have been known +since before the standard existed. The SGI implementation includes these (see +<a href="http://www.sgi.com/tech/stl/partition.html">http://www.sgi.com/tech/stl/partition.html</a> +and +<a href="http://www.sgi.com/tech/stl/stable_partition.html">http://www.sgi.com/tech/stl/stable_partition.html</a>). +</p> +<p><b>Proposed resolution:</b></p> +<p> +Change 25.2.12 from </p> +<blockquote><pre>template<class BidirectionalIterator, class Predicate> +BidirectionalIterator partition(BidirectionalIterato r first, + BidirectionalIterator last, + Predicate pred); +</pre></blockquote> +<p>to </p> +<blockquote><pre>template<class ForwardIterator, class Predicate> +ForwardIterator partition(ForwardIterator first, + ForwardIterator last, + Predicate pred); +</pre></blockquote> +<p>Change the complexity from </p> + +<blockquote><p> +At most (last - first)/2 swaps are done. Exactly (last - first) +applications of the predicate are done. +</p></blockquote> + +<p>to </p> + +<blockquote><p> +If ForwardIterator is a bidirectional_iterator, at most (last - first)/2 +swaps are done; otherwise at most (last - first) swaps are done. Exactly +(last - first) applications of the predicate are done. +</p></blockquote> + +<hr> +<a name="499"><h3>499. Std. doesn't seem to require stable_sort() to be stable!</h3></a><p><b>Section:</b> 25.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.stable.sort"> [lib.stable.sort]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Prateek Karandikar <b>Date:</b> 12 Apr 2005</p> +<blockquote> +<p> +17.3.1.1 Summary</p> + +<p> +1 The Summary provides a synopsis of the category, and introduces the +first-level subclauses. Each subclause also provides a summary, listing +the headers specified in the subclause and the library entities +provided in each header. +</p> +<p> +2 Paragraphs labelled "Note(s):" or "Example(s):" are informative, +other paragraphs are normative. +</p> +</blockquote> + +<p>So this means that a "Notes" paragraph wouldn't be normative. </p> + +<blockquote> +<p> +25.3.1.2 stable_sort +</p> +<pre>template<class RandomAccessIterator> +void stable_sort(RandomAccessIterat or first, RandomAccessIterator last); + +template<class RandomAccessIterator, class Compare> +void stable_sort(RandomAccessIterat or first, RandomAccessIterator last, Compare comp); +</pre> +<p> +1 Effects: Sorts the elements in the range [first, last). +</p> +<p> +2 Complexity: It does at most N(log N)^2 (where N == last - first) +comparisons; if enough extra memory is available, it is N log N. +</p> +<p> +3 Notes: Stable: the relative order of the equivalent elements is +preserved. +</p> +</blockquote> + +<p> +The Notes para is informative, and nowhere else is stability mentioned above. +</p> + +<p> +Also, I just searched for the word "stable" in my copy of the Standard. +and the phrase "Notes: Stable: the relative order of the elements..." +is repeated several times in the Standard library clauses for +describing various functions. How is it that stability is talked about +in the informative paragraph? Or am I missing something obvious? +</p> +<p><b>Proposed resolution:</b></p> +<p> +</p> +<hr> +<a name="500"><h3>500. do_length cannot be implemented correctly</h3></a><p><b>Section:</b> 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Krzysztof ¯elechowski <b>Date:</b> 24 May 2005</p> +<ol> +<li>codecvt::do_length is of type int;</li> +<li>it is assumed to be sort-of returning from_next - from of type ptrdiff_t;</li> +<li>ptrdiff_t cannot be cast to an int without data loss.</li> +</ol> <p> -The type, T, is not defined in this context and should be replaced by -bool or value_type.</p> +Contradiction. +</p> +<p><b>Proposed resolution:</b></p> +<p> +</p> +<hr> +<a name="501"><h3>501. Proposal: strengthen guarantees of lib.comparisons</h3></a><p><b>Section:</b> 20.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.comparisons"> [lib.comparisons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Me <anti_spam_email2003@yahoo.com> <b>Date:</b> 7 Jun 2005</p> +<blockquote> +"For templates greater, less, greater_equal, and less_equal, +the specializations for any pointer type yield a total order, even if +the built-in operators <, >, <=, >= do not." +</blockquote> + +<p> +The standard should do much better than guarantee that these provide a +total order, it should guarantee that it can be used to test if memory +overlaps, i.e. write a portable memmove. You can imagine a platform +where the built-in operators use a uint32_t comparison (this tests for +overlap on this platform) but the less<T*> functor is allowed to be +defined to use a int32_t comparison. On this platform, if you use +std::less with the intent of making a portable memmove, comparison on +an array that straddles the 0x7FFFFFFF/0x8000000 boundary can give +incorrect results. +</p> +<p><b>Proposed resolution:</b></p> +<p> +Add a footnote to 20.3.3/8 saying: +</p> + +<blockquote> +Given a p1 and p2 such that p1 points to N objects of type T and p2 +points to M objects of type T. If [p1,p1+N) does not overlap [p2,p2+M), +less returns the same value when comparing all pointers in [p1,p1+N) to +all pointers in [p2,p2+M). Otherwise, there is a value Q and a value R +such that less returns the same value when comparing all pointers in +[p1,p1+Q) to all pointers in [p2,p2+R) and an opposite value when +comparing all pointers in [p1+Q,p1+N) to all pointers in [p2+R,p2+M). +For the sake of completeness, the null pointer value (4.10) for T is +considered to be an array of 1 object that doesn't overlap with any +non-null pointer to T. less_equal, greater, greater_equal, equal_to, +and not_equal_to give the expected results based on the total ordering +semantics of less. For T of void, treat it as having similar semantics +as T of char i.e. less<cv T*>(a, b) gives the same results as less<cv +void*>(a, b) which gives the same results as less<cv char*>((cv +char*)(cv void*)a, (cv char*)(cv void*)b). +</blockquote> + +<p> +I'm also thinking there should be a footnote to 20.3.3/1 saying that if +A and B are similar types (4.4/4), comp<A>(a,b) returns the same value +as comp<B>(a,b) (where comp is less, less_equal, etc.). But this might +be problematic if there is some really funky operator overloading going +on that does different things based on cv (that should be undefined +behavior if somebody does that though). This at least should be +guaranteed for all POD types (especially pointers) that use the +built-in comparison operators. +</p> + +<hr> +<a name="502"><h3>502. Proposition: Clarification of the interaction between a facet and an iterator</h3></a><p><b>Section:</b> 22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Christopher Conrade Zseleghovski <b>Date:</b> 7 Jun 2005</p> +<p> +Motivation: +</p> + +<p> +This requirement seems obvious to me, it is the essence of code modularity. +I have complained to Mr. Plauger that the Dinkumware library does not +observe this principle but he objected that this behaviour is not covered in +the standard. +</p> +<p><b>Proposed resolution:</b></p> +<p> +Append the following point to 22.1.1.1.1: +</p> + +<p> +6. The implementation of a facet of Table 52 parametrized with an +InputIterator/OutputIterator should use that iterator only as character +source/sink respectively. +For a *_get facet, it means that the value received depends only on the +sequence of input characters and not on how they are accessed. +For a *_put facet, it means that the sequence of characters output depends +only on the value to be formatted and not of how the characters are stored. +</p> +<hr> +<a name="503"><h3>503. more on locales</h3></a><p><b>Section:</b> 22.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.categories"> [lib.locale.categories]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> P.J. Plauger <b>Date:</b> 20 Jun 2005</p> +<p> +a) In 22.2.1.1 para. 2 we refer to "the instantiations required in Table +51" to refer to the facet *objects* associated with a locale. And we +almost certainly mean just those associated with the default or "C" +locale. Otherwise, you can't switch to a locale that enforces a different +mapping between narrow and wide characters, or that defines additional +uppercase characters. +</p> + +<p> +b) 22.2.1.5 para. 3 (codecvt) has the same issues. +</p> + +<p> +c) 22.2.1.5.2 (do_unshift) is even worse. It *forbids* the generation of +a homing sequence for the basic character set, which might very well need +one. +</p> + +<p> +d) 22.2.1.5.2 (do_length) likewise dictates that the default mapping +between wide and narrow characters be taken as one-for-one. +</p> + +<p> +e) 22.2.2 para. 2 (num_get/put) is both muddled and vacuous, as far as +I can tell. The muddle is, as before, calling Table 51 a list of +instantiations. But the constraint it applies seems to me to cover +*all* defined uses of num_get/put, so why bother to say so? +</p> + +<p> +f) 22.2.3.1.2 para. 1(do_decimal_point) says "The required instantiations +return '.' or L'.'.) Presumably this means "as appropriate for the +character type. But given the vague definition of "required" earlier, +this overrules *any* change of decimal point for non "C" locales. +Surely we don't want to do that. +</p> + +<p> +g) 22.2.3.1.2 para. 2 (do_thousands_sep) says "The required instantiations +return ',' or L','.) As above, this probably means "as appropriate for the +character type. But this overrules the "C" locale, which requires *no* +character ('\0') for the thousands separator. Even if we agree that we +don't mean to block changes in decimal point or thousands separator, +we should also eliminate this clear incompatibility with C. +</p> + +<p> +h) 22.2.3.1.2 para. 2 (do_grouping) says "The required instantiations +return the empty string, indicating no grouping." Same considerations +as for do_decimal_point. +</p> + +<p> +i) 22.2.4.1 para. 1 (collate) refers to "instantiations required in Table +51". Same bad jargon. +</p> + +<p> +j) 22.2.4.1.2 para. 1 (do_compare) refers to "instantiations required +in Table 51". Same bad jargon. +</p> + +<p> +k) 22.2.5 para. 1 (time_get/put) uses the same muddled and vacuous +as num_get/put. +</p> + +<p> +l) 22.2.6 para. 2 (money_get/put) uses the same muddled and vacuous +as num_get/put. +</p> + +<p> +m) 22.2.6.3.2 (do_pos/neg_format) says "The instantiations required +in Table 51 ... return an object of type pattern initialized to +{symbol, sign, none, value}." This once again *overrides* the "C" +locale, as well as any other locale." +</p> + +<p> +3) We constrain the use_facet calls that can be made by num_get/put, +so why don't we do the same for money_get/put? Or for any of the +other facets, for that matter? +</p> + +<p> +4) As an almost aside, we spell out when a facet needs to use the ctype +facet, but several also need to use a codecvt facet and we don't say so. +</p> <p><b>Proposed resolution:</b></p> <p> </p> diff --git a/libstdc++-v3/docs/html/ext/lwg-defects.html b/libstdc++-v3/docs/html/ext/lwg-defects.html index 1dd18551422..f7ff410c01d 100644 --- a/libstdc++-v3/docs/html/ext/lwg-defects.html +++ b/libstdc++-v3/docs/html/ext/lwg-defects.html @@ -5,11 +5,11 @@ <table> <tbody><tr> <td align="left">Doc. no.</td> -<td align="left">N1763=05-0023</td> +<td align="left">N1831=05-0091</td> </tr> <tr> <td align="left">Date:</td> -<td align="left">2005-03-04</td> +<td align="left">2005-06-24</td> </tr> <tr> <td align="left">Project:</td> @@ -17,10 +17,10 @@ </tr> <tr> <td align="left">Reply to:</td> -<td align="left">Matt Austern <austern@google.com></td> +<td align="left">Howard Hinnant <howard.hinnant@gmail.com></td> </tr> </tbody></table> -<h1>C++ Standard Library Defect Report List (Revision 35)</h1> +<h1>C++ Standard Library Defect Report List (Revision R37)</h1> <p>Reference ISO/IEC IS 14882:1998(E)</p> <p>Also see:</p> <ul> @@ -42,19 +42,28 @@ document.</p> <h2>Revision History</h2> <ul> +<li>R37: +2005-06 mid-term mailing. +Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>. +</li> +<li>R36: +2005-04 post-Lillehammer mailing. All issues in "ready" status except +for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#454">454</a> were moved to "DR" status, and all issues +previously in "DR" status were moved to "WP". +</li> <li>R35: 2005-03 pre-Lillehammer mailing. </li> <li>R34: -2005-01 mid-term mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#488">488</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#494">494</a>. +2005-01 mid-term mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#488">488</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#494">494</a>. </li> <li>R33: -2004-11 post-Redmond mailing. Reflections actions taken in Redmond. +2004-11 post-Redmond mailing. Reflects actions taken in Redmond. </li> <li>R32: 2004-09 pre-Redmond mailing: reflects new proposed resolutions and new issues received after the 2004-07 mailing. Added -new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#479">479</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#481">481</a>. +new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#479">479</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#481">481</a>. </li> <li>R31: 2004-07 mid-term mailing: reflects new proposed resolutions and @@ -64,10 +73,10 @@ new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html# <li>R30: Post-Sydney mailing: reflects decisions made at the Sydney meeting. Voted all "Ready" issues from R29 into the working paper. -Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#462">462</a>. +Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#462">462</a>. </li> <li>R29: -Pre-Sydney mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#457">457</a>. +Pre-Sydney mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>. </li> <li>R28: Post-Kona mailing: reflects decisions made at the Kona meeting. @@ -96,7 +105,7 @@ Pre-Santa Cruz mailing. Added new issues <a href="http://www.open-std.org/jtc1/ Moved issues in the TC to TC status. </li> <li>R22: -Post-Curaçao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#366">366</a>. +Post-Curaçao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#366">366</a>. </li> <li>R21: Pre-Curaçao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#361">361</a>. @@ -222,7 +231,7 @@ post-Dublin mailing. Updated to reflect LWG and full committee actions in Dublin. (99-0016/N1193, 21 Apr 99) </li> <li>R7: -pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#131">131</a>, +pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#131">131</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#132">132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#133">133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#135">135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a> (31 Mar 99) @@ -618,7 +627,7 @@ list maintainer's note: the IS is the same.]</p> <p>See 99-0040/N1216, October 22, 1999, by Stephen D. Clamage for the analysis supporting to the proposed resolution.</p> <hr> -<a name="11"><h3>11. Bitset minor problems</h3></a><p><b>Section:</b> 23.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 22 Jan 1998</p> +<a name="11"></a><h3><a name="11">11. Bitset minor problems</a></h3><p><b>Section:</b> 23.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 22 Jan 1998</p> <p>(1) bitset<>::operator[] is mentioned in the class synopsis (23.3.5), but it is not documented in 23.3.5.2. </p> @@ -671,7 +680,7 @@ it's undefined. </p> <p>In 27.6.1.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>, replace "eos" with "charT()"</p> <hr> -<a name="14"><h3>14. Locale::combine should be const</h3></a><p><b>Section:</b> 22.1.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.members"> [lib.locale.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> +<a name="14"></a><h3><a name="14">14. Locale::combine should be const</a></h3><p><b>Section:</b> 22.1.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.members"> [lib.locale.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> <p>locale::combine is the only member function of locale (other than constructors and destructor) that is not const. There is no reason for it not to be const, and good reasons why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1 @@ -880,7 +889,7 @@ and do_out". </p> "do_convert" to "do_in or do_out". Also, in 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, change "do_convert()" to "do_in or do_out". </p> <hr> -<a name="25"><h3>25. String operator<< uses width() value wrong</h3></a><p><b>Section:</b> 21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> +<a name="25"></a><h3><a name="25">25. String operator<< uses width() value wrong</a></h3><p><b>Section:</b> 21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> <p>In the description of operator<< applied to strings, the standard says that uses the smaller of os.width() and str.size(), to pad "as described in stage 3" elsewhere; but this is inconsistent, as this allows no possibility of space for padding. </p> @@ -1200,7 +1209,7 @@ initialization/identification system depends...", or (at the editor's option) replace it with a place-holder to keep the paragraph numbering the same. </p> <hr> -<a name="41"></a><h3><a name="41">41. Ios_base needs clear(), exceptions()</a></h3><p><b>Section:</b> 27.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> +<a name="41"><h3>41. Ios_base needs clear(), exceptions()</h3></a><p><b>Section:</b> 27.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> <p>The description of ios_base::iword() and pword() in 27.4.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>, say that if they fail, they "set badbit, which may throw an exception". However, ios_base offers no interface to set or to test badbit; those interfaces are defined in @@ -1662,8 +1671,7 @@ character c by</p> <p>for any sequences of characters; and the effect of pushing back a character c by</p> -<pre> - ungetc(c, f); +<pre> ungetc(c, f); </pre> <p>is the same as the effect of</p> @@ -2360,7 +2368,7 @@ item from:</p> extracted. </blockquote> <hr> -<a name="69"><h3>69. Must elements of a vector be contiguous?</h3></a><p><b>Section:</b> 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 29 Jul 1998</p> +<a name="69"></a><h3><a name="69">69. Must elements of a vector be contiguous?</a></h3><p><b>Section:</b> 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 29 Jul 1998</p> <p>The issue is this: Must the elements of a vector be in contiguous memory?</p> <p>(Please note that this is entirely separate from the question of @@ -2604,7 +2612,7 @@ return value.]</i></p> <p>to:</p> <pre> template<class T> complex<T> polar(const T& rho, const T& theta = 0); </pre> <hr> -<a name="80"></a><h3><a name="80">80. Global Operators of complex declared twice</a></h3><p><b>Section:</b> 26.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, 26.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex"> [lib.complex]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p> +<a name="80"><h3>80. Global Operators of complex declared twice</h3></a><p><b>Section:</b> 26.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, 26.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex"> [lib.complex]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p> <p>Both 26.2.1 and 26.2.2 contain declarations of global operators for class complex. This redundancy should be removed.</p> <p><b>Proposed resolution:</b></p> @@ -2861,7 +2869,7 @@ for <tt>*r++</tt> from <tt>T</tt> to "convertible to T". of input iterators, we can't impose any requirements in the Input Iterator requirements table that forward iterators don't satisfy.</p> <hr> -<a name="103"><h3>103. set::iterator is required to be modifiable, but this allows modification of keys</h3></a><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p> +<a name="103"></a><h3><a name="103">103. set::iterator is required to be modifiable, but this allows modification of keys</a></h3><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p> <p>Set::iterator is described as implementation-defined with a reference to the container requirement; the container requirement says that const_iterator is an iterator pointing to const T and iterator an @@ -3132,7 +3140,7 @@ replace:</p> <pre>bool equal(const istreambuf_iterator& b) const;</pre> </blockquote> <hr> -<a name="112"></a><h3><a name="112">112. Minor typo in <tt>ostreambuf_iterator</tt> constructor</a></h3><p><b>Section:</b> 24.5.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.ostreambuf.iter.cons"> [lib.ostreambuf.iter.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 20 Oct 1998</p> +<a name="112"><h3>112. Minor typo in <tt>ostreambuf_iterator</tt> constructor</h3></a><p><b>Section:</b> 24.5.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.ostreambuf.iter.cons"> [lib.ostreambuf.iter.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 20 Oct 1998</p> <p>The <b>requires</b> clause for <tt>ostreambuf_iterator</tt>'s constructor from an <tt>ostream_type</tt> (24.5.4.1, paragraph 1) reads "<i>s</i> is not null". However, <i>s</i> is a @@ -3150,7 +3158,7 @@ reading:</p> <p><b>Requires</b>: <tt>s.rdbuf()</tt> is not null.</p> </blockquote> <hr> -<a name="114"><h3>114. Placement forms example in error twice</h3></a><p><b>Section:</b> 18.4.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.placement"> [lib.new.delete.placement]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 28 Oct 1998</p> +<a name="114"></a><h3><a name="114">114. Placement forms example in error twice</a></h3><p><b>Section:</b> 18.4.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.placement"> [lib.new.delete.placement]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 28 Oct 1998</p> <p>Section 18.4.1.3 contains the following example: </p> <pre>[Example: This can be useful for constructing an object at a known address: @@ -3359,7 +3367,7 @@ operator>>(int& val);</pre> <p><i>[Post-Tokyo: PJP provided the above wording.]</i></p> <hr> -<a name="119"></a><h3><a name="119">119. Should virtual functions be allowed to strengthen the exception specification?</a></h3><p><b>Section:</b> 17.4.4.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p> +<a name="119"><h3>119. Should virtual functions be allowed to strengthen the exception specification?</h3></a><p><b>Section:</b> 17.4.4.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p> <p>Section 17.4.4.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> states: </p> <p>"An implementation may strengthen the exception-specification @@ -3754,6 +3762,65 @@ stream state in case of failure.</p> <p><b>Rationale:</b></p> <p>Setting failbit is the usual error reporting mechanism for streams</p> <hr> +<a name="130"><h3>130. Return type of container::erase(iterator) differs for associative containers</h3></a><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2 Mar 1999</p> +<p>Table 67 (23.1.1) says that container::erase(iterator) returns an +iterator. Table 69 (23.1.2) says that in addition to this requirement, +associative containers also say that container::erase(iterator) +returns void. That's not an addition; it's a change to the +requirements, which has the effect of making associative containers +fail to meet the requirements for containers.</p> +<p><b>Proposed resolution:</b></p> + +<p> +In 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, in Table 69 Associative container +requirements, change the return type of <tt>a.erase(q)</tt> from +<tt>void</tt> to <tt>iterator</tt>. Change the +assertion/not/pre/post-condition from "erases the element pointed to +by <tt>q</tt>" to "erases the element pointed to by <tt>q</tt>. +Returns an iterator pointing to the element immediately following q +prior to the element being erased. If no such element exists, a.end() +is returned." +</p> + +<p> +In 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, in Table 69 Associative container +requirements, change the return type of <tt>a.erase(q1, q2)</tt> +from <tt>void</tt> to <tt>iterator</tt>. Change the +assertion/not/pre/post-condition from "erases the elements in the +range <tt>[q1, q2)</tt>" to "erases the elements in the range <tt>[q1, +q2)</tt>. Returns q2." +</p> + +<p> +In 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a>, in the <tt>map</tt> class synopsis; and +in 23.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.multimap"> [lib.multimap]</a>, in the <tt>multimap</tt> class synopsis; and +in 23.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.set"> [lib.set]</a>, in the <tt>set</tt> class synopsis; and +in 23.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.multiset"> [lib.multiset]</a>, in the <tt>multiset</tt> class synopsis: +change the signature of the first <tt>erase</tt> overload to +</p> +<pre> iterator erase(iterator position); +</pre> +<p>and change the signature of the third <tt>erase</tt> overload to</p> +<pre> iterator erase(iterator first, iterator last); +</pre> + + +<p><i>[Pre-Kona: reopened at the request of Howard Hinnant]</i></p> + +<p><i>[Post-Kona: the LWG agrees the return type should be +<tt>iterator</tt>, not <tt>void</tt>. (Alex Stepanov agrees too.) +Matt provided wording.]</i></p> + +<p><i>[ + Sydney: the proposed wording went in the right direction, but it + wasn't good enough. We want to return an iterator from the range form + of erase as well as the single-iterator form. Also, the wording is + slightly different from the wording we have for sequences; there's no + good reason for having a difference. Matt provided new wording, + which we will review at the next meeting. +]</i></p> + +<hr> <a name="132"><h3>132. list::resize description uses random access iterators</h3></a><p><b>Section:</b> 23.2.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.capacity"> [lib.list.capacity]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 6 Mar 1999</p> <p>The description reads:</p> @@ -4084,7 +4151,7 @@ follows an "all-or-none" rule.</p> <p>For inserters, the LWG believes there is no defect; the standard is correct as written.</p> <hr> -<a name="147"><h3>147. Library Intro refers to global functions that aren't global</h3></a><p><b>Section:</b> 17.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.global.functions"> [lib.global.functions]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Lois Goldthwaite <b>Date:</b> 4 Jun 1999</p> +<a name="147"></a><h3><a name="147">147. Library Intro refers to global functions that aren't global</a></h3><p><b>Section:</b> 17.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.global.functions"> [lib.global.functions]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Lois Goldthwaite <b>Date:</b> 4 Jun 1999</p> <p>The library had many global functions until 17.4.1.1 [lib.contents] paragraph 2 was added: </p> @@ -4338,8 +4405,8 @@ be fixed to use <tt>sbumpc()</tt> instead.</p> "supplied" with the words "extracted from the stream".</p> <hr> -<a name="160"><h3>160. Typo: Use of non-existing function <tt>exception()</tt> -</h3></a><p><b>Section:</b> 27.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream"> [lib.istream]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p> +<a name="160"></a><h3><a name="160">160. Typo: Use of non-existing function <tt>exception()</tt> +</a></h3><p><b>Section:</b> 27.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream"> [lib.istream]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p> <p>The paragraph 4 refers to the function <tt>exception()</tt> which is not defined. Probably, the referred function is <tt>basic_ios<>::exceptions()</tt>.</p> @@ -4500,7 +4567,7 @@ traits class for some arbitrary charT type, and we somehow have to deal with a const char*. There's nothing better to do but fall back to char_traits<char></p> <hr> -<a name="168"><h3>168. Typo: formatted vs. unformatted</h3></a><p><b>Section:</b> 27.6.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p> +<a name="168"></a><h3><a name="168">168. Typo: formatted vs. unformatted</a></h3><p><b>Section:</b> 27.6.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p> <p>The first paragraph begins with a descriptions what has to be done in <i>formatted</i> output functions. Probably this is a typo and the paragraph really want to describe unformatted output functions...</p> @@ -5829,7 +5896,7 @@ change. or change the return to distance(b,a). The LWG preferred the former for consistency.</p> <hr> -<a name="211"><h3>211. operator>>(istream&, string&) doesn't set failbit</h3></a><p><b>Section:</b> 21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Scott Snyder <b>Date:</b> 4 Feb 2000</p> +<a name="211"></a><h3><a name="211">211. operator>>(istream&, string&) doesn't set failbit</a></h3><p><b>Section:</b> 21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Scott Snyder <b>Date:</b> 4 Feb 2000</p> <p>The description of the stream extraction operator for std::string (section 21.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in the case that the operator fails to extract any characters from the input @@ -5940,7 +6007,7 @@ declared above.</pre> return 0; }</pre> <hr> -<a name="220"></a><h3><a name="220">220. ~ios_base() usage valid?</a></h3><p><b>Section:</b> 27.4.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.cons"> [lib.ios.base.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Jonathan Schilling, Howard Hinnant <b>Date:</b> 13 Mar 2000</p> +<a name="220"><h3>220. ~ios_base() usage valid?</h3></a><p><b>Section:</b> 27.4.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.cons"> [lib.ios.base.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Jonathan Schilling, Howard Hinnant <b>Date:</b> 13 Mar 2000</p> <p>The pre-conditions for the ios_base destructor are described in 27.4.2.7 paragraph 2:</p> <blockquote> @@ -7248,10 +7315,10 @@ iterators into *this, not into x. <p>The original proposed resolution said that iterators and references would remain "valid". The new proposed resolution clarifies what that means. Note that this only applies to the case of equal allocators. -From 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> paragraph 4, the behavior of list when +>From 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> paragraph 4, the behavior of list when allocators compare nonequal is outside the scope of the standard.</p> <hr> -<a name="251"></a><h3><a name="251">251. basic_stringbuf missing allocator_type</a></h3><p><b>Section:</b> 27.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf"> [lib.stringbuf]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 Jul 2000</p> +<a name="251"><h3>251. basic_stringbuf missing allocator_type</h3></a><p><b>Section:</b> 27.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf"> [lib.stringbuf]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 Jul 2000</p> <p>The synopsis for the template class <tt>basic_stringbuf</tt> doesn't list a typedef for the template parameter <tt>Allocator</tt>. This makes it impossible to determine the type of @@ -7493,8 +7560,8 @@ In section 21.3.4, paragraph 1, change <i>pos</i>)</tt>". </p> <hr> -<a name="260"></a><h3><a name="260">260. Inconsistent return type of <tt>istream_iterator::operator++(int)</tt> -</a></h3><p><b>Section:</b> 24.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istream.iterator.ops"> [lib.istream.iterator.ops]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 27 Aug 2000</p> +<a name="260"><h3>260. Inconsistent return type of <tt>istream_iterator::operator++(int)</tt> +</h3></a><p><b>Section:</b> 24.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istream.iterator.ops"> [lib.istream.iterator.ops]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 27 Aug 2000</p> <p>The synopsis of istream_iterator::operator++(int) in 24.5.1 shows it as returning the iterator by value. 24.5.1.2, p5 shows the same operator as returning the iterator by reference. That's incorrect @@ -8955,7 +9022,7 @@ list" is excessively vague.]</i></p> <p><i>[Post-Curaçao: Robert Klarer provided new wording.]</i></p> <hr> -<a name="301"><h3>301. basic_string template ctor effects clause omits allocator argument</h3></a><p><b>Section:</b> 21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 27 Jan 2001</p> +<a name="301"></a><h3><a name="301">301. basic_string template ctor effects clause omits allocator argument</a></h3><p><b>Section:</b> 21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 27 Jan 2001</p> <p> The effects clause for the basic_string template ctor in 21.3.1, p15 leaves out the third argument of type Allocator. I believe this to be @@ -9506,7 +9573,7 @@ Table 82. However, <cstdio> is mentioned several times within section 27.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a>, including 27.8.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.c.files"> [lib.c.files]</a>.]</i></p> <hr> -<a name="310"></a><h3><a name="310">310. Is errno a macro?</a></h3><p><b>Section:</b> 17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a>, 19.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-diagnostics.html#lib.errno"> [lib.errno]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 21 Mar 2001</p> +<a name="310"><h3>310. Is errno a macro?</h3></a><p><b>Section:</b> 17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a>, 19.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-diagnostics.html#lib.errno"> [lib.errno]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 21 Mar 2001</p> <p> Exactly how should errno be declared in a conforming C++ header? </p> @@ -10449,7 +10516,7 @@ parameter name conveys real normative meaning. <hr> <a name="338"><h3>338. is whitespace allowed between `-' and a digit?</h3></a><p><b>Section:</b> 22.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.categories"> [lib.locale.categories]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 17 Sep 2001</p> <p> -From Stage 2 processing in 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>, p8 and 9 (the +>From Stage 2 processing in 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>, p8 and 9 (the original text or the text corrected by the proposed resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a>) it seems clear that no whitespace is allowed within a number, but 22.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.numpunct"> [lib.locale.numpunct]</a>, p2, which gives the @@ -10506,7 +10573,7 @@ for it to differ gratuitously from the very specific description of numeric processing in 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>. The proposed resolution removes all mention of "whitespace" from that format.</p> <hr> -<a name="339"></a><h3><a name="339">339. definition of bitmask type restricted to clause 27</a></h3><p><b>Section:</b> 22.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a>, 17.3.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 17 September 2001</p> +<a name="339"><h3>339. definition of bitmask type restricted to clause 27</h3></a><p><b>Section:</b> 22.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a>, 17.3.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 17 September 2001</p> <p> The ctype_category::mask type is declared to be an enum in 22.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a> with p1 then stating that it is a bitmask type, most likely referring to the definition of bitmask type in 17.3.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a>, p1. However, the said definition only applies to @@ -10564,8 +10631,8 @@ following (note, in particluar, the cross-reference to 17.3.2.1.2 in consistent with the rest of the standard.]</i></p> <hr> -<a name="340"></a><h3><a name="340">340. interpretation of <tt>has_facet<Facet>(loc)</tt> -</a></h3><p><b>Section:</b> 22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2001</p> +<a name="340"><h3>340. interpretation of <tt>has_facet<Facet>(loc)</tt> +</h3></a><p><b>Section:</b> 22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2001</p> <p> It's unclear whether 22.1.1.1.1, p3 says that <tt>has_facet<Facet>(loc)</tt> returns true for any <tt>Facet</tt> @@ -11489,6 +11556,57 @@ Change the guarantee to "postcondition: r is dereferenceable." <p><b>Rationale:</b></p> <p>Fixes an obvious typo</p> <hr> +<a name="386"><h3>386. Reverse iterator's operator[] has impossible return type</h3></a><p><b>Section:</b> 24.4.1.3.11 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.opindex"> [lib.reverse.iter.opindex]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 23 Oct 2002</p> +<p>In 24.4.1.3.11 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.opindex"> [lib.reverse.iter.opindex]</a>, <tt>reverse_iterator<>::operator[]</tt> +is specified as having a return type of <tt>reverse_iterator::reference</tt>, +which is the same as <tt>iterator_traits<Iterator>::reference</tt>. +(Where <tt>Iterator</tt> is the underlying iterator type.)</p> + +<p>The trouble is that <tt>Iterator</tt>'s own operator[] doesn't + necessarily have a return type + of <tt>iterator_traits<Iterator>::reference</tt>. Its + return type is merely required to be convertible + to <tt>Iterator</tt>'s value type. The return type specified for + reverse_iterator's operator[] would thus appear to be impossible.</p> + +<p>With the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a>, the type of + <tt>a[n]</tt> will continue to be required (for random access + iterators) to be convertible to the value type, and also <tt>a[n] = + t</tt> will be a valid expression. Implementations of + <tt>reverse_iterator</tt> will likely need to return a proxy from + <tt>operator[]</tt> to meet these requirements. As mentioned in the + comment from Dave Abrahams, the simplest way to specify that + <tt>reverse_iterator</tt> meet this requirement to just mandate + it and leave the return type of <tt>operator[]</tt> unspecified.</p> + +<p><b>Proposed resolution:</b></p> + +<p>In 24.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.requirements"> [lib.reverse.iter.requirements]</a> change:</p> + +<blockquote> +<pre>reference operator[](difference_type n) const; +</pre> +</blockquote> + +<p>to:</p> + +<blockquote> +<pre><b><i>unspecified</i></b> operator[](difference_type n) const; // see <font color="red">lib.random.access.iterators</font> +</pre> +</blockquote> + + + + +<p><i>[ +Comments from Dave Abrahams: IMO we should resolve 386 by just saying + that the return type of reverse_iterator's operator[] is + unspecified, allowing the random access iterator requirements to + impose an appropriate return type. If we accept 299's proposed + resolution (and I think we should), the return type will be + readable and writable, which is about as good as we can do. +]</i></p> +<hr> <a name="389"><h3>389. Const overload of valarray::operator[] returns by value</h3></a><p><b>Section:</b> 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 8 Nov 2002</p> <p>Consider the following program:</p> <pre> #include <iostream> @@ -11772,7 +11890,7 @@ Providing this functionality would be difficult in some cases, and is believed to be of limited value. </p> <hr> -<a name="405"><h3>405. qsort and POD</h3></a><p><b>Section:</b> 25.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.c.library"> [lib.alg.c.library]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 08 Apr 2003</p> +<a name="405"><h3>405. qsort and POD</h3></a><p><b>Section:</b> 25.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.c.library"> [lib.alg.c.library]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 08 Apr 2003</p> <p> Section 25.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.c.library"> [lib.alg.c.library]</a> describes bsearch and qsort, from the C standard library. Paragraph 4 does not list any restrictions on qsort, @@ -11791,6 +11909,29 @@ type." <p><i>[Something along these lines is clearly necessary. Matt provided wording.]</i></p> <hr> +<a name="406"><h3>406. vector::insert(s) exception safety</h3></a><p><b>Section:</b> 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 27 Apr 2003</p> +<p> +There is a possible defect in the standard: the standard text was +never intended to prevent arbitrary ForwardIterators, whose operations +may throw exceptions, from being passed, and it also wasn't intended +to require a temporary buffer in the case where ForwardIterators were +passed (and I think most implementations don't use one). As is, the +standard appears to impose requirements that aren't met by any +existing implementation. +</p> +<p><b>Proposed resolution:</b></p> +<p>Replace 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a> paragraph 1 with:</p> +<blockquote> + 1- Notes: 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 or assignment operator + of T or by any InputIterator operation there are no effects. +</blockquote> + +<p><i>[We probably need to say something similar for deque.]</i></p> + +<hr> <a name="407"><h3>407. Can singular iterators be destroyed?</h3></a><p><b>Section:</b> 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 3 June 2003</p> <p> Clause 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>, paragraph 5, says that the only expression @@ -11807,7 +11948,82 @@ destroying an iterator that holds a singular value, or the assignment of a non-singular value to an iterator that holds a singular value." </p> <hr> -<a name="410"><h3>410. Missing semantics for stack and queue comparison operators</h3></a><p><b>Section:</b> 23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.queue"> [lib.queue]</a>, 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Hans Bos <b>Date:</b> 7 Jun 2003</p> +<a name="409"><h3>409. Closing an fstream should clear error state</h3></a><p><b>Section:</b> 27.8.1.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a>, 27.8.1.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ofstream.members"> [lib.ofstream.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 3 June 2003</p> +<p> +A strict reading of 27.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a> shows that opening or +closing a basic_[io]fstream does not affect the error bits. This +means, for example, that if you read through a file up to EOF, and +then close the stream and reopen it at the beginning of the file, +the EOF bit in the stream's error state is still set. This is +counterintuitive. +</p> +<p> +The LWG considered this issue once before, as issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#22">22</a>, +and put in a footnote to clarify that the strict reading was indeed +correct. We did that because we believed the standard was +unambiguous and consistent, and that we should not make architectural +changes in a TC. Now that we're working on a new revision of the +language, those considerations no longer apply. +</p> +<p><b>Proposed resolution:</b></p> + +<p>Change 27.8.1.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a>, para. 3 from:</p> + +<blockquote> +Calls rdbuf()->open(s,mode|in). If that function returns a null +pointer, calls setstate(failbit) (which may throw ios_base::failure +[Footnote: (lib.iostate.flags)]. +</blockquote> + +<p>to:</p> + +<blockquote>Calls rdbuf()->open(s,mode|in). If that function returns +a null pointer, calls setstate(failbit) (which may throw +ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear(). +</blockquote> + +<p>Change 27.8.1.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ofstream.members"> [lib.ofstream.members]</a>, para. 3 from:</p> + +<blockquote>Calls rdbuf()->open(s,mode|out). If that function +returns a null pointer, calls setstate(failbit) (which may throw +ios_base::failure [Footnote: (lib.iostate.flags)). +</blockquote> + +<p>to:</p> + +<blockquote>Calls rdbuf()->open(s,mode|out). If that function +returns a null pointer, calls setstate(failbit) (which may throw +ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear(). +</blockquote> + +<p>Change 27.8.1.13 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstream.members"> [lib.fstream.members]</a>, para. 3 from:</p> + +<blockquote>Calls rdbuf()->open(s,mode), If that function returns a +null pointer, calls setstate(failbit), (which may throw +ios_base::failure). (lib.iostate.flags) ) +</blockquote> + +<p>to:</p> + +<blockquote>Calls rdbuf()->open(s,mode), If that function returns a +null pointer, calls setstate(failbit), (which may throw +ios_base::failure). (lib.iostate.flags) ), else calls clear(). +</blockquote> + + + +<p><i>[Kona: the LWG agrees this is a good idea. Post-Kona: Bill +provided wording. He suggests having open, not close, clear the error +flags.]</i></p> + +<p><i>[Post-Sydney: Howard provided a new proposed resolution. The + old one didn't make sense because it proposed to fix this at the + level of basic_filebuf, which doesn't have access to the stream's + error state. Howard's proposed resolution fixes this at the level + of the three fstream class template instead.]</i></p> + +<hr> +<a name="410"></a><h3><a name="410">410. Missing semantics for stack and queue comparison operators</a></h3><p><b>Section:</b> 23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.queue"> [lib.queue]</a>, 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Hans Bos <b>Date:</b> 7 Jun 2003</p> <p> Sections 23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.queue"> [lib.queue]</a> and 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a> list comparison operators (==, !=, <, <=, >, =>) for queue and @@ -11892,7 +12108,7 @@ set_intersection(), not union() and intersection(). <p><b>Proposed resolution:</b></p> <p>Change that sentence to use the correct names.</p> <hr> -<a name="412"><h3>412. Typo in 27.4.4.3</h3></a><p><b>Section:</b> 27.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostate.flags"> [lib.iostate.flags]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 10 Jul 2003</p> +<a name="412"></a><h3><a name="412">412. Typo in 27.4.4.3</a></h3><p><b>Section:</b> 27.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostate.flags"> [lib.iostate.flags]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 10 Jul 2003</p> <p> The Effects clause in 27.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostate.flags"> [lib.iostate.flags]</a> paragraph 5 says that the function only throws if the respective bits are already set prior to @@ -11914,6 +12130,51 @@ exceptions()) == 0" with "If ((state | (rdbuf() ? goodbit : badbit)) latter, of course. Post-Kona: Martin provided wording.]</i></p> <hr> +<a name="413"><h3>413. Proposed resolution to LDR#64 still wrong</h3></a><p><b>Section:</b> 27.6.1.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Bo Persson <b>Date:</b> 13 Jul 2003</p> +<p> +The second sentence of the proposed resolution says: +</p> + +<p> +"If it inserted no characters because it caught an exception thrown +while extracting characters from sb and ..." +</p> + +<p> +However, we are not extracting from sb, but extracting from the +basic_istream (*this) and inserting into sb. I can't really tell if +"extracting" or "sb" is a typo. +</p> + +<p><i>[ +Sydney: Definitely a real issue. We are, indeed, extracting characters +from an istream and not from sb. The problem was there in the FDIS and +wasn't fixed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a>. Probably what was intended was +to have *this instead of sb. We're talking about the exception flag +state of a basic_istream object, and there's only one basic_istream +object in this discussion, so that would be a consistent +interpretation. (But we need to be careful: the exception policy of +this member function must be consistent with that of other +extractors.) PJP will provide wording. +]</i></p> + +<p><b>Proposed resolution:</b></p> +<p>Change the sentence from:</p> + +<blockquote> +If it inserted no characters because it caught an exception thrown +while extracting characters from sb and failbit is on in exceptions(), +then the caught exception is rethrown. +</blockquote> + +<p>to:</p> + +<blockquote> +If it inserted no characters because it caught an exception thrown +while extracting characters from *this and failbit is on in exceptions(), +then the caught exception is rethrown. +</blockquote> +<hr> <a name="414"><h3>414. Which iterators are invalidated by v.erase()?</h3></a><p><b>Section:</b> 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 19 Aug 2003</p> <p> Consider the following code fragment: @@ -11975,7 +12236,7 @@ erase". and references in parallel, and it would seem counterintuitive to say that a reference to an erased value remains valid.</p> <hr> -<a name="415"><h3>415. behavior of std::ws</h3></a><p><b>Section:</b> 27.6.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.manip"> [lib.istream.manip]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p> +<a name="415"><h3>415. behavior of std::ws</h3></a><p><b>Section:</b> 27.6.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.manip"> [lib.istream.manip]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p> <p> According to 27.6.1.4, the ws() manipulator is not required to construct the sentry object. The manipulator is also not a member function so the @@ -12023,7 +12284,7 @@ allowed to just declare it without providing a full definition? already says. We don't want to make anything implementation defined, because that imposes new requirements in implementations.</p> <hr> -<a name="425"><h3>425. return value of std::get_temporary_buffer</h3></a><p><b>Section:</b> 20.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.temporary.buffer"> [lib.temporary.buffer]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p> +<a name="425"><h3>425. return value of std::get_temporary_buffer</h3></a><p><b>Section:</b> 20.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.temporary.buffer"> [lib.temporary.buffer]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p> <p> The standard is not clear about the requirements on the value returned from a call to get_temporary_buffer(0). In particular, it fails to specify whether @@ -12038,7 +12299,7 @@ values if no storage can be obtained" to "...or a pair of 0 values if no storage can be obtained or if <i>n</i> <= 0."</p> <p><i>[Kona: Matt provided wording]</i></p> <hr> -<a name="426"><h3>426. search_n(), fill_n(), and generate_n() with negative n</h3></a><p><b>Section:</b> 25.1.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.search"> [lib.alg.search]</a>, 25.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.fill"> [lib.alg.fill]</a>, 25.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.generate"> [lib.alg.generate]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p> +<a name="426"><h3>426. search_n(), fill_n(), and generate_n() with negative n</h3></a><p><b>Section:</b> 25.1.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.search"> [lib.alg.search]</a>, 25.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.fill"> [lib.alg.fill]</a>, 25.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.generate"> [lib.alg.generate]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p> <p> The complexity requirements for these function templates are incorrect (or don't even make sense) for negative n:</p> @@ -12129,7 +12390,7 @@ which is most likely not the intent. option, on the grounds that duplicating text always risks the possibility that it might be duplicated incorrectly.</p> <hr> -<a name="432"><h3>432. stringbuf::overflow() makes only one write position available</h3></a><p><b>Section:</b> 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Christian W Brock <b>Date:</b> 24 Sep 2003</p> +<a name="432"><h3>432. stringbuf::overflow() makes only one write position available</h3></a><p><b>Section:</b> 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Christian W Brock <b>Date:</b> 24 Sep 2003</p> <p>27.7.1.3 par 8 says:</p> <blockquote> Notes: The function can make a write position available only if @@ -12400,7 +12661,47 @@ longer allowable since [pbase(), epptr()) may now contain uninitialized characters. Positioning is only allowable over the initialized range.</p> <hr> -<a name="435"><h3>435. bug in DR 25</h3></a><p><b>Section:</b> 21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 15 Oct 2003</p> +<a name="434"><h3>434. bitset::to_string() hard to use</h3></a><p><b>Section:</b> 23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 15 Oct 2003</p> +<p> +It has been pointed out a number of times that the bitset to_string() member +function template is tedious to use since callers must explicitly specify the +entire template argument list (3 arguments). At least two implementations +provide a number of overloads of this template to make it easier to use. +</p> +<p><b>Proposed resolution:</b></p> +<p>In order to allow callers to specify no template arguments at all, just the +first one (charT), or the first 2 (charT and traits), in addition to all +three template arguments, add the following three overloads to both the +interface (declarations only) of the class template bitset as well as to +section 23.3.5.2, immediately after p34, the Returns clause of the existing +to_string() member function template:</p> + +<pre> template <class charT, class traits> + basic_string<charT, traits, allocator<charT> > + to_string () const; + + -34.1- Returns: to_string<charT, traits, allocator<charT> >(). + + template <class charT> + basic_string<charT, char_traits<charT>, allocator<charT> > + to_string () const; + + -34.2- Returns: to_string<charT, char_traits<charT>, allocator<charT> >(). + + basic_string<char, char_traits<char>, allocator<char> > + to_string () const; + + -34.3- Returns: to_string<char, char_traits<char>, allocator<char> >(). +</pre> + +<p><i>[Kona: the LWG agrees that this is an improvement over the + status quo. Dietmar thought about an alternative using a proxy + object but now believes that the proposed resolution above is the + right choice. +]</i></p> + +<hr> +<a name="435"><h3>435. bug in DR 25</h3></a><p><b>Section:</b> 21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 15 Oct 2003</p> <p> It has been pointed out that the proposed resolution in DR 25 may not be @@ -12473,7 +12774,330 @@ template parameter.</p> text.]</i></p> <hr> -<a name="441"><h3>441. Is fpos::state const?</h3></a><p><b>Section:</b> 27.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos"> [lib.fpos]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Vincent Leloup <b>Date:</b> 17 Nov 2003</p> +<a name="438"></a><h3><a name="438">438. Ambiguity in the "do the right thing" clause</a></h3><p><b>Section:</b> 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 20 Oct 2003</p> + +<p>Section 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>, paragraphs 9-11, fixed up the problem +noticed with statements like:</p> +<pre>vector<int> v(10, 1); +</pre> + +<p>The intent of the above statement was to construct with:</p> +<pre>vector(size_type, const value_type&); +</pre> + +<p>but early implementations failed to compile as they bound to:</p> +<pre>template <class InputIterator> +vector(InputIterator f, InputIterator l); +</pre> +<p>instead.</p> + +<p>Paragraphs 9-11 say that if InputIterator is an integral type, then the +member template constructor will have the same effect as:</p> +<pre>vector<static_cast<size_type>(f), static_cast<value_type>(l)); +</pre> +<p>(and similarly for the other member template functions of sequences).</p> + +<p>There is also a note that describes one implementation technique:</p> +<blockquote> + One way that sequence implementors can satisfy this requirement is to + specialize the member template for every integral type. +</blockquote> + +<p>This might look something like:</p> +<blockquote> +<pre>template <class T> +struct vector +{ + typedef unsigned size_type; + + explicit vector(size_type) {} + vector(size_type, const T&) {} + + template <class I> + vector(I, I); + + // ... +}; + +template <class T> +template <class I> +vector<T>::vector(I, I) { ... } + +template <> +template <> +vector<int>::vector(int, int) { ... } + +template <> +template <> +vector<int>::vector(unsigned, unsigned) { ... } + +// ... +</pre> +</blockquote> + +<p>Label this solution 'A'.</p> + +<p>The standard also says:</p> +<blockquote> + Less cumbersome implementation techniques also exist. +</blockquote> +<p> +A popular technique is to not specialize as above, but instead catch +every call with the member template, detect the type of InputIterator, +and then redirect to the correct logic. Something like: +</p> +<blockquote> +<pre>template <class T> +template <class I> +vector<T>::vector(I f, I l) +{ + choose_init(f, l, int2type<is_integral<I>::value>()); +} + +template <class T> +template <class I> +vector<T>::choose_init(I f, I l, int2type<false>) +{ + // construct with iterators +} + +template <class T> +template <class I> +vector<T>::choose_init(I f, I l, int2type<true>) +{ + size_type sz = static_cast<size_type>(f); + value_type v = static_cast<value_type>(l); + // construct with sz,v +} +</pre> +</blockquote> + +<p>Label this solution 'B'.</p> + +<p>Both of these solutions solve the case the standard specifically +mentions:</p> +<pre>vector<int> v(10, 1); // ok, vector size 10, initialized to 1 +</pre> + +<p> +However, (and here is the problem), the two solutions have different +behavior in some cases where the value_type of the sequence is not an +integral type. For example consider: +</p> +<blockquote><pre> pair<char, char> p('a', 'b'); + vector<vector<pair<char, char> > > d('a', 'b'); +</pre></blockquote> +<p> +The second line of this snippet is likely an error. Solution A catches +the error and refuses to compile. The reason is that there is no +specialization of the member template constructor that looks like: +</p> +<pre>template <> +template <> +vector<vector<pair<char, char> > >::vector(char, char) { ... } +</pre> + +<p> +So the expression binds to the unspecialized member template +constructor, and then fails (compile time) because char is not an +InputIterator. +</p> + +<p> +Solution B compiles the above example though. 'a' is casted to an +unsigned integral type and used to size the outer vector. 'b' is +static casted to the inner vector using it's explicit constructor: +</p> + +<pre>explicit vector(size_type n); +</pre> + +<p> +and so you end up with a static_cast<size_type>('a') by +static_cast<size_type>('b') matrix. +</p> + +<p> +It is certainly possible that this is what the coder intended. But the +explicit qualifier on the inner vector has been thwarted at any rate. +</p> + +<p> +The standard is not clear whether the expression: +</p> + +<pre> vector<vector<pair<char, char> > > d('a', 'b'); +</pre> + +<p> +(and similar expressions) are: +</p> + +<ol> +<li> undefined behavior.</li> +<li> illegal and must be rejected.</li> +<li> legal and must be accepted.</li> +</ol> + +<p>My preference is listed in the order presented.</p> + +<p>There are still other techniques for implementing the requirements of +paragraphs 9-11, namely the "restricted template technique" (e.g. +enable_if). This technique is the most compact and easy way of coding +the requirements, and has the behavior of #2 (rejects the above +expression). +</p> + +<p> +Choosing 1 would allow all implementation techniques I'm aware of. +Choosing 2 would allow only solution 'A' and the enable_if technique. +Choosing 3 would allow only solution 'B'. +</p> + +<p> +Possible wording for a future standard if we wanted to actively reject +the expression above would be to change "static_cast" in paragraphs +9-11 to "implicit_cast" where that is defined by: +</p> + +<blockquote> +<pre>template <class T, class U> +inline +T implicit_cast(const U& u) +{ + return u; +} +</pre> +</blockquote> + +<p><b>Proposed resolution:</b></p> + +Replace 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> paragraphs 9 - 11 with: + +<p>For every sequence defined in this clause and in clause lib.strings:</p> + +<ul> + <li> + <p>If the constructor</p> + <pre> template <class InputIterator> + X(InputIterator f, InputIterator l, + const allocator_type& a = allocator_type()) + </pre> + <p>is called with a type InputIterator that does not qualify as + an input iterator, then the constructor will behave as if the + overloaded constructor:</p> + <pre> X(size_type, const value_type& = value_type(), + const allocator_type& = allocator_type()) + </pre> + <p>were called instead, with the arguments static_cast<size_type>(f), l and a, respectively.</p> + </li> + + <li> + <p>If the member functions of the forms:</p> + <pre> template <class InputIterator> // such as insert() + rt fx1(iterator p, InputIterator f, InputIterator l); + + template <class InputIterator> // such as append(), assign() + rt fx2(InputIterator f, InputIterator l); + + template <class InputIterator> // such as replace() + rt fx3(iterator i1, iterator i2, InputIterator f, InputIterator l); + </pre> + <p>are called with a type InputIterator that does not qualify as + an input iterator, then these functions will behave as if the + overloaded member functions:</p> + <pre> rt fx1(iterator, size_type, const value_type&); + + rt fx2(size_type, const value_type&); + + rt fx3(iterator, iterator, size_type, const value_type&); + </pre> + <p>were called instead, with the same arguments.</p> + </li> +</ul> + +<p>In the previous paragraph the alternative binding will fail if f +is not implicitly convertible to X::size_type or if l is not implicitly +convertible to X::value_type.</p> + +<p> +The extent to which an implementation determines that a type cannot be +an input iterator is unspecified, except that as a minimum integral +types shall not qualify as input iterators. +</p> + + + +<p><i>[ +Kona: agreed that the current standard requires <tt>v('a', 'b')</tt> +to be accepted, and also agreed that this is surprising behavior. The +LWG considered several options, including something like +implicit_cast, which doesn't appear to be quite what we want. We +considered Howards three options: allow acceptance or rejection, +require rejection as a compile time error, and require acceptance. By +straw poll (1-6-1), we chose to require a compile time error. +Post-Kona: Howard provided wording. +]</i></p> + +<p><i>[ +Sydney: The LWG agreed with this general direction, but there was some +discomfort with the wording in the original proposed resolution. +Howard submitted new wording, and we will review this again in +Redmond. +]</i></p> + +<p><i>[Redmond: one very small change in wording: the first argument + is cast to size_t. This fixes the problem of something like + <tt>vector<vector<int> >(5, 5)</tt>, where int is not + implicitly convertible to the value type.]</i></p> + +<p><b>Rationale:</b></p> +<p>The proposed resolution fixes:</p> + +<pre> vector<int> v(10, 1); +</pre> + +<p> +since as integral types 10 and 1 must be disqualified as input +iterators and therefore the (size,value) constructor is called (as +if).</p> + +<p>The proposed resolution breaks:</p> + +<pre> vector<vector<T> > v(10, 1); +</pre> + +<p> +because the integral type 1 is not *implicitly* convertible to +vector<T>. The wording above requires a diagnostic.</p> + +<p> +The proposed resolution leaves the behavior of the following code +unspecified. +</p> + +<pre> struct A + { + operator int () const {return 10;} + }; + + struct B + { + B(A) {} + }; + + vector<B> v(A(), A()); +</pre> + +<p> +The implementation may or may not detect that A is not an input +iterator and employee the (size,value) constructor. Note though that +in the above example if the B(A) constructor is qualified explicit, +then the implementation must reject the constructor as A is no longer +implicitly convertible to B. +</p> +<hr> +<a name="441"><h3>441. Is fpos::state const?</h3></a><p><b>Section:</b> 27.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos"> [lib.fpos]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Vincent Leloup <b>Date:</b> 17 Nov 2003</p> <p> In section 27.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos.members"> [lib.fpos.members]</a> fpos<stateT>::state() is declared non const, but in section 27.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos"> [lib.fpos]</a> it is declared const. @@ -12484,7 +13108,7 @@ In section 27.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-ios <tt>fpos<stateT>::state()</tt> to const. </p> <hr> -<a name="442"><h3>442. sentry::operator bool() inconsistent signature</h3></a><p><b>Section:</b> 27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Vincent Leloup <b>Date:</b> 18 Nov 2003</p> +<a name="442"><h3>442. sentry::operator bool() inconsistent signature</h3></a><p><b>Section:</b> 27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Vincent Leloup <b>Date:</b> 18 Nov 2003</p> <p> In section 27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a> paragraph 4, in description part basic_ostream<charT, traits>::sentry::operator bool() is declared @@ -12497,7 +13121,7 @@ In section 27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-ios of <tt>sentry::operator bool()</tt> to const. </p> <hr> -<a name="443"><h3>443. filebuf::close() inconsistent use of EOF</h3></a><p><b>Section:</b> 27.8.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.members"> [lib.filebuf.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Vincent Leloup <b>Date:</b> 20 Nov 2003</p> +<a name="443"><h3>443. filebuf::close() inconsistent use of EOF</h3></a><p><b>Section:</b> 27.8.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.members"> [lib.filebuf.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Vincent Leloup <b>Date:</b> 20 Nov 2003</p> <p> In section 27.8.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.members"> [lib.filebuf.members]</a> par6, in effects description of basic_filebuf<charT, traits>::close(), overflow(EOF) is used twice; @@ -12508,7 +13132,204 @@ should be overflow(traits::eof()). Change overflow(EOF) to overflow(traits::eof()). </p> <hr> -<a name="448"><h3>448. Random Access Iterators over abstract classes</h3></a><p><b>Section:</b> 24.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 7 Jan 2004</p> +<a name="444"><h3>444. Bad use of casts in fstream</h3></a><p><b>Section:</b> 27.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Vincent Leloup <b>Date:</b> 20 Nov 2003</p> +<p> +27.8.1.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a> p1, 27.8.1.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ofstream.members"> [lib.ofstream.members]</a> p1, 27.8.1.13 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstream.members"> [lib.fstream.members]</a> p1 seems have same problem as exposed in LWG issue +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a>. +</p> +<p><b>Proposed resolution:</b></p> + +<p><i>[Sydney: Genuine defect. 27.8.1.13 needs a cast to cast away + constness. The other two places are stylistic: we could change the + C-style casts to const_cast. Post-Sydney: Howard provided wording. +]</i></p> + +<p>Change 27.8.1.7/1 from:</p> +<blockquote> + Returns: (basic_filebuf<charT,traits>*)&sb. +</blockquote> + +<p>to:</p> +<blockquote> + Returns: const_cast<basic_filebuf<charT,traits>*>(&sb). +</blockquote> + +<p>Change 27.8.1.10/1 from:</p> +<blockquote> + Returns: (basic_filebuf<charT,traits>*)&sb. +</blockquote> + +<p>to:</p> +<blockquote> + Returns: const_cast<basic_filebuf<charT,traits>*>(&sb). +</blockquote> + +<p>Change 27.8.1.13/1 from:</p> +<blockquote> + Returns: &sb. +</blockquote> + +<p>to:</p> +<blockquote> + Returns: const_cast<basic_filebuf<charT,traits>*>(&sb). +</blockquote> + + + +<hr> +<a name="445"><h3>445. iterator_traits::reference unspecified for some iterator categories</h3></a><p><b>Section:</b> 24.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.traits"> [lib.iterator.traits]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 9 Dec 2003</p> +<p> +The standard places no restrictions at all on the reference type +of input, output, or forward iterators (for forward iterators it +only specifies that *x must be value_type& and doesn't mention +the reference type). Bidirectional iterators' reference type is +restricted only by implication, since the base iterator's +reference type is used as the return type of reverse_iterator's +operator*, which must be T& in order to be a conforming forward +iterator. +</p> + +<p> +Here's what I think we ought to be able to expect from an input +or forward iterator's reference type R, where a is an iterator +and V is its value_type +</p> + +<ul> + <li> + *a is convertible to R + </li> + + <li> + R is convertible to V + </li> + + <li> + static_cast<V>(static_cast<R>(*a)) is equivalent to + static_cast<V>(*a) + </li> +</ul> + +<p>A mutable forward iterator ought to satisfy, for x of type V:</p> + <li> + { R r = *a; r = x; } is equivalent to *a = x; + </li> + +<p> +I think these requirements capture existing container iterators +(including vector<bool>'s), but render istream_iterator invalid; +its reference type would have to be changed to a constant +reference. +</p> + + +<p> +(Jeremy Siek) During the discussion in Sydney, it was felt that a +simpler long term solution for this was needed. The solution proposed +was to require <tt>reference</tt> to be the same type as <tt>*a</tt> +and <tt>pointer</tt> to be the same type as <tt>a-></tt>. Most +iterators in the Standard Library already meet this requirement. Some +iterators are output iterators, and do not need to meet the +requirement, and others are only specified through the general +iterator requirements (which will change with this resolution). The +sole case where there is an explicit definition of the reference type +that will need to change is <tt>istreambuf_iterator</tt> which returns +<tt>charT</tt> from <tt>operator*</tt> but has a reference type of +<tt>charT&</tt>. We propose changing the reference type of +<tt>istreambuf_iterator</tt> to <tt>charT</tt>. +</p> + +<p>The other option for resolving the issue with <tt>pointer</tt>, + mentioned in the note below, is to remove <tt>pointer</tt> + altogether. I prefer placing requirements on <tt>pointer</tt> to + removing it for two reasons. First, <tt>pointer</tt> will become + useful for implementing iterator adaptors and in particular, + <tt>reverse_iterator</tt> will become more well defined. Second, + removing <tt>pointer</tt> is a rather drastic and publicly-visible + action to take.</p> + +<p>The proposed resolution technically enlarges the requirements for +iterators, which means there are existing iterators (such as +<tt>istreambuf_iterator</tt>, and potentially some programmer-defined +iterators) that will no longer meet the requirements. Will this break +existing code? The scenario in which it would is if an algorithm +implementation (say in the Standard Library) is changed to rely on +<tt>iterator_traits::reference</tt>, and then is used with one of the +iterators that do not have an appropriately defined +<tt>iterator_traits::reference</tt>. +</p> + + +<p>The proposed resolution makes one other subtle change. Previously, +it was required that output iterators have a <tt>difference_type</tt> +and <tt>value_type</tt> of <tt>void</tt>, which means that a forward +iterator could not be an output iterator. This is clearly a mistake, +so I've changed the wording to say that those types may be +<tt>void</tt>. +</p> + +<p><b>Proposed resolution:</b></p> + +<p>In 24.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.traits"> [lib.iterator.traits]</a>, after:</p> + +<blockquote> +be defined as the iterator's difference type, value type and iterator +category, respectively. +</blockquote> + +<p>add</p> + +<blockquote> +In addition, the types +<pre>iterator_traits<Iterator>::reference +iterator_traits<Iterator>::pointer +</pre> +must be defined as the iterator's reference and pointer types, that +is, the same type as the type of <tt>*a</tt> and <tt>a-></tt>, +respectively. +</blockquote> + +<p>In 24.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.traits"> [lib.iterator.traits]</a>, change:</p> + +<blockquote> +In the case of an output iterator, the types +<pre>iterator_traits<Iterator>::difference_type +iterator_traits<Iterator>::value_type +</pre> +are both defined as <tt>void</tt>. +</blockquote> + +<p>to:</p> +<blockquote> +In the case of an output iterator, the types +<pre>iterator_traits<Iterator>::difference_type +iterator_traits<Iterator>::value_type +iterator_traits<Iterator>::reference +iterator_traits<Iterator>::pointer +</pre> +may be defined as <tt>void</tt>. +</blockquote> + +<p>In 24.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator"> [lib.istreambuf.iterator]</a>, change:</p> +<blockquote> +<pre>typename traits::off_type, charT*, charT&> +</pre> +</blockquote> +<p>to:</p> +<blockquote> +<pre>typename traits::off_type, charT*, charT> +</pre> +</blockquote> + +<p><i>[ +Redmond: there was concern in Sydney that this might not be the only place +where things were underspecified and needed to be changed. Jeremy +reviewed iterators in the standard and confirmed that nothing else +needed to be changed. +]</i></p> + +<hr> +<a name="448"><h3>448. Random Access Iterators over abstract classes</h3></a><p><b>Section:</b> 24.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 7 Jan 2004</p> <p> Table 76, the random access iterator requirement table, says that the return type of a[n] must be "convertible to T". When an iterator's @@ -12520,7 +13341,7 @@ Surely this isn't an intended restriction? Change the return type to "convertible to T const&". </p> <hr> -<a name="449"><h3>449. Library Issue 306 Goes Too Far</h3></a><p><b>Section:</b> 18.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.types"> [lib.support.types]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Pete Becker <b>Date:</b> 15 Jan 2004</p> +<a name="449"><h3>449. Library Issue 306 Goes Too Far</h3></a><p><b>Section:</b> 18.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.types"> [lib.support.types]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Pete Becker <b>Date:</b> 15 Jan 2004</p> <p>Original text:</p> <blockquote> The macro offsetof accepts a restricted set of type arguments in this @@ -12549,5 +13370,126 @@ the results are undefined. The result of applying the offsetof macro to a field that is a static data member or a function member is undefined." </blockquote> +<hr> +<a name="453"><h3>453. basic_stringbuf::seekoff need not always fail for an empty stream</h3></a><p><b>Section:</b> 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 30 Jan 2004</p> +<pre> pos_type basic_stringbuf::seekoff(off_type, ios_base::seekdir, + ios_base::openmode); +</pre> +<p> +is obliged to fail if nothing has been inserted into the stream. This +is unnecessary and undesirable. It should be permissible to seek to +an effective offset of zero.</p> + +<p><i>[ + Sydney: Agreed that this is an annoying problem: seeking to zero should be + legal. Bill will provide wording. +]</i></p> + +<p><b>Proposed resolution:</b></p> +<p>Change the sentence from:</p> +<blockquote> +For a sequence to be positioned, if its next pointer (either +gptr() or pptr()) is a null pointer, the positioning operation +fails. +</blockquote> + +<p>to:</p> + +<blockquote> +For a sequence to be positioned, if its next pointer (either +gptr() or pptr()) is a null pointer and the new offset newoff +is nonzero, the positioning operation fails. +</blockquote> +<hr> +<a name="455"><h3>455. cerr::tie() and wcerr::tie() are overspecified</h3></a><p><b>Section:</b> 27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 30 Jan 2004</p> +<p> +Both cerr::tie() and wcerr::tie() are obliged to be null at program +startup. This is overspecification and overkill. It is both traditional +and useful to tie cerr to cout, to ensure that standard output is drained +whenever an error message is written. This behavior should at least be +permitted if not required. Same for wcerr::tie(). +</p> +<p><b>Proposed resolution:</b></p> + +<p>Add to the description of cerr:</p> +<blockquote> +After the object cerr is initialized, cerr.tie() returns &cout. +Its state is otherwise the same as required for basic_ios<char>::init +(lib.basic.ios.cons). +</blockquote> + +<p>Add to the description of wcerr:</p> + +<blockquote> +After the object wcerr is initialized, wcerr.tie() returns &wcout. +Its state is otherwise the same as required for basic_ios<wchar_t>::init +(lib.basic.ios.cons). +</blockquote> + +<p><i>[Sydney: straw poll (3-1): we should <i>require</i>, not just + permit, cout and cerr to be tied on startup. Pre-Redmond: Bill will + provide wording.]</i></p> +<hr> +<a name="457"><h3>457. bitset constructor: incorrect number of initialized bits</h3></a><p><b>Section:</b> 23.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Dag Henriksson <b>Date:</b> 30 Jan 2004</p> +<p> +The constructor from unsigned long says it initializes "the first M +bit positions to the corresponding bit values in val. M is the smaller +of N and the value CHAR_BIT * sizeof(unsigned long)." +</p> + +<p> +Object-representation vs. value-representation strikes again. CHAR_BIT * +sizeof (unsigned long) does not give us the number of bits an unsigned long +uses to hold the value. Thus, the first M bit position above is not +guaranteed to have any corresponding bit values in val. +</p> +<p><b>Proposed resolution:</b></p> +<p>In 23.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</a> paragraph 2, change "M is the smaller of + N and the value CHAR_BIT * sizeof (unsigned long). (249)" to + "<tt>M</tt> is the smaller of <tt>N</tt> and the number of bits in + the value representation (section 3.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/basic.html#basic.types"> [basic.types]</a>) of <tt>unsigned + long</tt>." +</p> +<hr> +<a name="460"><h3>460. Default modes missing from basic_fstream member specifications</h3></a><p><b>Section:</b> 27.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Ben Hutchings <b>Date:</b> 1 Apr 2004</p> +<p> +The second parameters of the non-default constructor and of the open +member function for basic_fstream, named "mode", are optional +according to the class declaration in 27.8.1.11 [lib.fstream]. The +specifications of these members in 27.8.1.12 [lib.fstream.cons] and +27.8.1.13 lib.fstream.members] disagree with this, though the +constructor declaration has the "explicit" function-specifier implying +that it is intended to be callable with one argument. +</p> +<p><b>Proposed resolution:</b></p> +<p>In 27.8.1.12 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstream.cons"> [lib.fstream.cons]</a>, change</p> +<pre> explicit basic_fstream(const char* s, ios_base::openmode mode); +</pre> +<p>to</p> +<pre> explicit basic_fstream(const char* s, + ios_base::openmode mode = ios_base::in|ios_base::out); +</pre> +<p>In 27.8.1.13 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstream.members"> [lib.fstream.members]</a>, change</p> +<pre> void open(const char*s, ios_base::openmode mode); +</pre> +<p>to</p> + void open(const char*s, + ios_base::openmode mode = ios_base::in|ios_base::out); +<hr> +<a name="469"><h3>469. vector<bool> ill-formed relational operators</h3></a><p><b>Section:</b> 23.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.bool"> [lib.vector.bool]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 Jun 2004</p> + +<p> +The overloads of relational operators for vector<bool> specified +in [lib.vector.bool] are redundant (they are semantically identical +to those provided for the vector primary template) and may even be +diagnosed as ill-formed (refer to Daveed Vandevoorde's explanation +in c++std-lib-13647). +</p> + +<p><b>Proposed resolution:</b></p> +<p> +Remove all overloads of overloads of relational operators for +vector<bool> from [lib.vector.bool]. +</p> <p>----- End of document -----</p> </body></html>
\ No newline at end of file |