diff options
| author | paolo <paolo@138bc75d-0d04-0410-961f-82ee72b054a4> | 2006-10-12 00:16:48 +0000 |
|---|---|---|
| committer | paolo <paolo@138bc75d-0d04-0410-961f-82ee72b054a4> | 2006-10-12 00:16:48 +0000 |
| commit | 4e9934d9215d09942f077d3effca7df3353223b6 (patch) | |
| tree | ad71d035c1508495766264d2a2e47d3cf311a304 /libstdc++-v3/docs | |
| parent | 763840d6bb21c2944947ce8878d3946228473f4d (diff) | |
| download | gcc-4e9934d9215d09942f077d3effca7df3353223b6.tar.gz | |
2006-10-11 Paolo Carlini <pcarlini@suse.de>
* docs/html/ext/lwg-active.html, lwg-defects.html: Import Revision 44.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@117651 138bc75d-0d04-0410-961f-82ee72b054a4
Diffstat (limited to 'libstdc++-v3/docs')
| -rw-r--r-- | libstdc++-v3/docs/html/ext/howto.html | 6 | ||||
| -rw-r--r-- | libstdc++-v3/docs/html/ext/lwg-active.html | 1195 | ||||
| -rw-r--r-- | libstdc++-v3/docs/html/ext/lwg-defects.html | 450 |
3 files changed, 1393 insertions, 258 deletions
diff --git a/libstdc++-v3/docs/html/ext/howto.html b/libstdc++-v3/docs/html/ext/howto.html index 7a9e4ef15a6..22bc5916f92 100644 --- a/libstdc++-v3/docs/html/ext/howto.html +++ b/libstdc++-v3/docs/html/ext/howto.html @@ -593,6 +593,12 @@ <dd>In case of input_iterator/output_iterator rely on Assignability of input_iterator' value_type. </dd> + + <dt><a href="lwg-active.html#586">586</a>: + <em>String inserter not a formatted function</em> + </dt> + <dd>Change it to be a formatted output function (i.e. catch exceptions). + </dd> <!-- <dt><a href="lwg-defects.html#"></a>: <em></em> diff --git a/libstdc++-v3/docs/html/ext/lwg-active.html b/libstdc++-v3/docs/html/ext/lwg-active.html index 3e279f4d93d..7a2b949377f 100644 --- a/libstdc++-v3/docs/html/ext/lwg-active.html +++ b/libstdc++-v3/docs/html/ext/lwg-active.html @@ -8,11 +8,11 @@ del {background-color:#FFFFA0}</style></head> <table> <tbody><tr> <td align="left">Doc. no.</td> -<td align="left">N2000=06-0070</td> +<td align="left">N2091=06-0161</td> </tr> <tr> <td align="left">Date:</td> -<td align="left">2006-04-21</td> +<td align="left">2006-09-08</td> </tr> <tr> <td align="left">Project:</td> @@ -23,7 +23,7 @@ del {background-color:#FFFFA0}</style></head> <td align="left">Howard Hinnant <howard.hinnant@gmail.com></td> </tr> </tbody></table> -<h1>C++ Standard Library Active Issues List (Revision R42)</h1> +<h1>C++ Standard Library Active Issues List (Revision R44)</h1> <p>Reference ISO/IEC IS 14882:1998(E)</p> <p>Also see:</p> <ul> @@ -91,6 +91,16 @@ del {background-color:#FFFFA0}</style></head> directory as the issues list files. </p> <h2>Revision History</h2> <ul> +<li>R44: +2006-09-08 pre-Portland mailing. +Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#583">583</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#592">592</a>. +</li> +<li>R43: +2006-06-23 mid-term mailing. +Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#575">575</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>. +Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255">255</a>. +Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#569">569</a> to Tentatively Ready. +</li> <li>R42: 2006-04-21 post-Berlin mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#572">572</a>. @@ -537,7 +547,7 @@ upon overflow. We considered three options based on this:</p> 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> +<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"> [lib.vector]</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> <p><tt>vector<bool></tt> is not a container as its reference and pointer types are not references and pointers. </p> @@ -614,6 +624,50 @@ specializations of numeric_limits. 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="206"><h3>206. operator new(size_t, nothrow) may become unlinked to ordinary operator new if ordinary version replaced</h3></a><p><b>Section:</b> 18.5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</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> 29 Aug 1999</p> +<p>As specified, the implementation of the nothrow version of operator +new does not necessarily call the ordinary operator new, but may +instead simply call the same underlying allocator and return a null +pointer instead of throwing an exception in case of failure.</p> + +<p>Such an implementation breaks code that replaces the ordinary +version of new, but not the nothrow version. If the ordinary version +of new/delete is replaced, and if the replaced delete is not +compatible with pointers returned from the library versions of new, +then when the replaced delete receives a pointer allocated by the +library new(nothrow), crash follows.</p> + +<p>The fix appears to be that the lib version of new(nothrow) must +call the ordinary new. Thus when the ordinary new gets replaced, the +lib version will call the replaced ordinary new and things will +continue to work.</p> + +<p>An alternative would be to have the ordinary new call +new(nothrow). This seems sub-optimal to me as the ordinary version of +new is the version most commonly replaced in practice. So one would +still need to replace both ordinary and nothrow versions if one wanted +to replace the ordinary version.</p> + +<p>Another alternative is to put in clear text that if one version is +replaced, then the other must also be replaced to maintain +compatibility. Then the proposed resolution below would just be a +quality of implementation issue. There is already such text in +paragraph 7 (under the new(nothrow) version). But this nuance is +easily missed if one reads only the paragraphs relating to the +ordinary new.</p> + +<p><b>Proposed resolution:</b></p> +<p><b>Rationale:</b></p> +<p>Yes, they may become unlinked, and that is by design. If a user +replaces one, the user should also replace the other.</p> + +<p><i>[ +Reopened due to a gcc conversation between Howard, Martin and Gaby. Forwarding +or not is visible behavior to the client and it would be useful for the client +to know which behavior it could depend on. +]</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> If <tt>mm</tt> is a multimap and <tt>p</tt> is an iterator @@ -864,7 +918,72 @@ intended here is that the copy constructors can't fail.</p> compiler-generated constructors might in principle throw anything.]</i></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> +<a name="255"><h3>255. Why do <tt>basic_streambuf<>::pbump()</tt> and <tt>gbump()</tt> take an int?</h3></a><p><b>Section:</b> 27.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf"> [lib.streambuf]</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> 12 Aug 2000</p> +<p> +The basic_streambuf members gbump() and pbump() are specified to take an +int argument. This requirement prevents the functions from effectively +manipulating buffers larger than std::numeric_limits<int>::max() +characters. It also makes the common use case for these functions +somewhat difficult as many compilers will issue a warning when an +argument of type larger than int (such as ptrdiff_t on LLP64 +architectures) is passed to either of the function. Since it's often the +result of the subtraction of two pointers that is passed to the +functions, a cast is necessary to silence such warnings. Finally, the +usage of a native type in the functions signatures is inconsistent with +other member functions (such as sgetn() and sputn()) that manipulate the +underlying character buffer. Those functions take a streamsize argument. +</p> +<p><b>Proposed resolution:</b></p> +<p> +Change the signatures of these functions in the synopsis of template +class basic_streambuf (27.5.2) and in their descriptions (27.5.2.3.1, p4 +and 27.5.2.3.2, p4) to take a streamsize argument. +</p> + +<p> +Although this change has the potential of changing the ABI of the +library, the change will affect only platforms where int is different +than the definition of streamsize. However, since both functions are +typically inline (they are on all known implementations), even on such +platforms the change will not affect any user code unless it explicitly +relies on the existing type of the functions (e.g., by taking their +address). Such a possibility is IMO quite remote. +</p> + +<p> +Alternate Suggestion from Howard Hinnant, c++std-lib-7780: +</p> + +<p> +This is something of a nit, but I'm wondering if streamoff wouldn't be a +better choice than streamsize. The argument to pbump and gbump MUST be +signed. But the standard has this to say about streamsize +(27.4.1/2/Footnote): +</p> + +<blockquote> + [Footnote: streamsize is used in most places where ISO C would use + size_t. Most of the uses of streamsize could use size_t, except for + the strstreambuf constructors, which require negative values. It + should probably be the signed type corresponding to size_t (which is + what Posix.2 calls ssize_t). --- end footnote] +</blockquote> + +<p> +This seems a little weak for the argument to pbump and gbump. Should we +ever really get rid of strstream, this footnote might go with it, along +with the reason to make streamsize signed. +</p> +<p><b>Rationale:</b></p> +<p>The LWG believes this change is too big for now. We may wish to +reconsider this for a future revision of the standard. One +possibility is overloading pbump, rather than changing the +signature.</p> +<p><i>[ +[2006-05-04: Reopened at the request of Chris (Krzysztof ?elechowski)] +]</i></p> +<hr> +<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.default.con.req"> [lib.default.con.req]</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: </p> @@ -933,7 +1052,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="290"></a><h3><a name="290">290. Requirements to for_each and its function object</a></h3><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> +<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 "Requires" section, which means that there are no restrictions imposed on the function object whatsoever. In essence it @@ -1411,7 +1530,7 @@ In case of failure, the function calls <tt>setstate(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="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> +<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.byname"> [lib.locale.codecvt.byname]</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> It seems that the descriptions of codecvt do_in() and do_out() leave sufficient room for interpretation so that two implementations of @@ -1436,7 +1555,7 @@ the following seems less than adequately specified: <ol> <li> - 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>, p2 says this about the effects of the + <font color="red">22.2.1.5.2</font>, p2 says this about the effects of the function: ...Stops if it encounters a character it cannot convert... This assumes that there *is* a character to convert. What happens when there is a sequence that doesn't form a @@ -1469,7 +1588,7 @@ the following seems less than adequately specified: </li> </ol> <p> -Finally, the conditions described at the end of 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>, p4 don't seem to be possible: +Finally, the conditions described at the end of <font color="red">22.2.1.5.2</font>, p4 don't seem to be possible: </p> <blockquote> "A return value of partial, if (from_next == from_end), @@ -1483,7 +1602,7 @@ If the value is partial, it's not clear to me that (from_next ==from_end) could ever hold if there isn't enough room in the destination buffer. In order for (from_next==from_end) to hold, all characters in that range must have been successfully -converted (according to 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>, p2) and since there are no +converted (according to <font color="red">22.2.1.5.2</font>, p2) and since there are no further source characters to convert, no more room in the destination buffer can be needed. </p> @@ -1559,7 +1678,7 @@ into references? References aren't copy constructible, so this should not be allowed. ]</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> +<a name="387"><h3>387. std::complex over-encapsulated</h3></a><p><b>Section:</b> 26.3 <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 makes it imposible to reuse existing software developed in traditional @@ -1591,7 +1710,7 @@ of std::complex<> is not justified. </p> <p><b>Proposed resolution:</b></p> -<p>Add the following requirements to 26.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.numbers"> [lib.complex.numbers]</a> as 26.2/4:</p> +<p>Add the following requirements to 26.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.numbers"> [lib.complex.numbers]</a> as 26.3/4:</p> <blockquote> <p>If z is an lvalue expression of type cv std::complex<T> then</p> @@ -1618,7 +1737,7 @@ imaginary part of a[i].</li> </ul> </blockquote> -<p>In the header synopsis in 26.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, replace</p> +<p>In the header synopsis in 26.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, replace</p> <pre> template<class T> T real(const complex<T>&); template<class T> T imag(const complex<T>&); </pre> @@ -1631,7 +1750,7 @@ imaginary part of a[i].</li> template<class T> T& imag( complex<T>&); </pre> -<p>In 26.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a> paragraph 1, change</p> +<p>In 26.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a> paragraph 1, change</p> <pre> template<class T> T real(const complex<T>&); </pre> <p>to</p> @@ -1641,7 +1760,7 @@ imaginary part of a[i].</li> <p>and change the <b>Returns</b> clause to "<b>Returns:</b> The real part of <i>x</i></p>. -<p>In 26.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a> paragraph 2, change</p> +<p>In 26.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a> paragraph 2, change</p> <pre> template<class T> T imag(const complex<T>&); </pre> <p>to</p> @@ -1994,9 +2113,9 @@ end-of-file): and changing it on an individual basis wouldn't make things better. Dietmar will do this work.</p> <hr> -<a name="401"><h3>401. incorrect type casts in table 32 in lib.allocator.requirements</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> Markus Mauhart <b>Date:</b> 27 Feb 2003</p> +<a name="401"><h3>401. incorrect type casts in table 32 in lib.allocator.requirements</h3></a><p><b>Section:</b> 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.default.con.req"> [lib.default.con.req]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Markus Mauhart <b>Date:</b> 27 Feb 2003</p> <p> -I think that in par2 of 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> the last two +I think that in par2 of 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.default.con.req"> [lib.default.con.req]</a> the last two lines of table 32 contain two incorrect type casts. The lines are ... </p> @@ -2561,7 +2680,7 @@ library class templates. We need to consult with CWG to make sure we use the right wording.]</i></p> <hr> -<a name="423"></a><h3><a name="423">423. effects of negative streamsize in iostreams</a></h3><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> Martin Sebor <b>Date:</b> 18 Sep 2003</p> +<a name="423"><h3>423. effects of negative streamsize in iostreams</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> Martin Sebor <b>Date:</b> 18 Sep 2003</p> <p> A third party test suite tries to exercise istream::ignore(N) with @@ -2689,7 +2808,7 @@ traits classes, then the facet could reasonably be required to use <tt>char_traits<charT></tt></p>. <hr> -<a name="430"><h3>430. valarray subset operations</h3></a><p><b>Section:</b> 26.3.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.sub"> [lib.valarray.sub]</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="430"><h3>430. valarray subset operations</h3></a><p><b>Section:</b> 26.5.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.sub"> [lib.valarray.sub]</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> The standard fails to specify the behavior of valarray::operator[](slice) and other valarray subset operations when they are passed an "invalid" @@ -2703,8 +2822,8 @@ object (e.g., slice (2, 1, 1) for a valarray of size 1). performance, so we don't want to require specific checking. We need wording to express this decision.]</i></p> <hr> -<a name="431"><h3>431. Swapping containers with unequal allocators</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>, 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> Matt Austern <b>Date:</b> 20 Sep 2003</p> -<p>Clause 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 says that implementations +<a name="431"><h3>431. Swapping containers with unequal allocators</h3></a><p><b>Section:</b> 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.default.con.req"> [lib.default.con.req]</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> Matt Austern <b>Date:</b> 20 Sep 2003</p> +<p>Clause 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.default.con.req"> [lib.default.con.req]</a> paragraph 4 says that implementations are permitted to supply containers that are unable to cope with allocator instances and that container implementations may assume that all instances of an allocator type compare equal. We gave @@ -3043,7 +3162,7 @@ technique to perform the comparison:</p> if it the source and destination types are the same</li> </ol> <hr> -<a name="462"><h3>462. Destroying objects with static storage duration</h3></a><p><b>Section:</b> 3.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/basic.html#basic.start.term"> [basic.start.term]</a>, 18.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.start.term"> [lib.support.start.term]</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> 23 Mar 2004</p> +<a name="462"><h3>462. Destroying objects with static storage duration</h3></a><p><b>Section:</b> 3.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/basic.html#basic.start.term"> [basic.start.term]</a>, 18.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.cstdint"> [lib.cstdint]</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> 23 Mar 2004</p> <p> 3.6.3 Termination spells out in detail the interleaving of static destructor calls and calls to functions registered with atexit. To @@ -3077,7 +3196,7 @@ even if we don't require it. <p> </p> <hr> -<a name="463"><h3>463. auto_ptr usability issues</h3></a><p><b>Section:</b> 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Rani Sharoni <b>Date:</b> 7 Dec 2003</p> +<a name="463"><h3>463. auto_ptr usability issues</h3></a><p><b>Section:</b> 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.unary"> [lib.meta.unary]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Rani Sharoni <b>Date:</b> 7 Dec 2003</p> <p> TC1 CWG DR #84 effectively made the template<class Y> operator auto_ptr<Y>() @@ -3392,7 +3511,7 @@ in some surprising (i.e., undefined) behavior. <hr> -<a name="471"><h3>471. result of what() implementation-defined</h3></a><p><b>Section:</b> 18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.exception"> [lib.exception]</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> +<a name="471"><h3>471. result of what() implementation-defined</h3></a><p><b>Section:</b> 18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.type.info"> [lib.type.info]</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> <p>[lib.exception] specifies the following:</p> <pre> exception (const exception&) throw(); @@ -4266,7 +4385,7 @@ The same issue applies to unordered_multiset and unordered_multimap. <p> </p> <hr> -<a name="520"><h3>520. Result_of and pointers to data members</h3></a><p><b>Section:</b> TR1 3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.func.bind"> [tr.func.bind]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Pete Becker <b>Date:</b> 3 Jul 2005</p> +<a name="520"><h3>520. Result_of and pointers to data members</h3></a><p><b>Section:</b> TR1 3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.func.bind"> [tr.func.bind]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Tentatively%20Ready">Tentatively Ready</a> <b>Submitter:</b> Pete Becker <b>Date:</b> 3 Jul 2005</p> <p> In the original proposal for binders, the return type of bind() when called with a pointer to member data as it's callable object was @@ -4281,6 +4400,19 @@ to member data. <p><i>[ Pete and Peter will provide wording. ]</i></p> + +<p> +In 20.5.4 [lib.func.ret] ([tr.func.ret]) p3 add the following bullet after bullet 2: +</p> +<ol start="3"> +<li>If <tt>F</tt> is a member data pointer type <tt>R T::*</tt>, <tt>type</tt> +shall be <tt><i>cv</i> R&</tt> when <tt>T1</tt> is <tt><i>cv</i> U1&</tt>, +<tt>R</tt> otherwise.</li> +</ol> + +<p><i>[ +Peter provided wording. +]</i></p> <hr> <a name="521"><h3>521. Garbled requirements for argument_type in reference_wrapper</h3></a><p><b>Section:</b> TR1 2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.refwrp.refwrp"> [tr.util.refwrp.refwrp]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Pete Becker <b>Date:</b> 3 Jul 2005</p> <p> @@ -4674,7 +4806,20 @@ Berlin: not quite editorial, needs proposed wording. <p><b>Proposed resolution:</b></p> <p> +In 20.5.10.1.3 [lib.func.bind.bind] ([tr.func.bind.bind]), add a new paragraph after p2: +</p> +<blockquote> +<i>Throws:</i> Nothing unless one of the copy constructors of <tt>f, t1, t2, ..., tN</tt> +throws an exception. +</blockquote> + +<p> +Add a new paragraph after p4: </p> +<blockquote> +<i>Throws:</i> nothing unless one of the copy constructors of <tt>f, t1, t2, ..., tN</tt> +throws an exception. +</blockquote> <hr> <a name="528"><h3>528. TR1: issue 6.19 vs 6.3.4.3/2 (and 6.3.4.5/2)</h3></a><p><b>Section:</b> TR1 6.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.unord.unord"> [tr.unord.unord]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Paolo Carlini <b>Date:</b> 12 Oct 2005</p> <p> @@ -5236,7 +5381,7 @@ must be CopyConstructible (20.1.3) <ins>and Assignable</ins>. Otherwise CopyConstructible is not required. </blockquote> <hr> -<a name="539"><h3>539. partial_sum and adjacent_difference should mention requirements</h3></a><p><b>Section:</b> 26.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numeric.ops"> [lib.numeric.ops]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Marc Schoolderman <b>Date:</b> 6 Feb 2006</p> +<a name="539"><h3>539. partial_sum and adjacent_difference should mention requirements</h3></a><p><b>Section:</b> 26.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.rand"> [lib.rand]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Marc Schoolderman <b>Date:</b> 6 Feb 2006</p> <p> There are some problems in the definition of partial_sum and adjacent_difference in 26.4 [lib.numeric.ops] @@ -5429,7 +5574,7 @@ definition) of the function shall be well-formed.</ins> </blockquote> <hr> -<a name="541"><h3>541. shared_ptr template assignment and void</h3></a><p><b>Section:</b> TR1 2.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.smartptr.shared"> [tr.util.smartptr.shared]</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> 16 Oct 2005</p> +<a name="541"><h3>541. shared_ptr template assignment and void</h3></a><p><b>Section:</b> TR1 2.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.smartptr.shared"> [tr.util.smartptr.shared]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Tentatively%20Ready">Tentatively Ready</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 16 Oct 2005</p> <p> Is the void specialization of the template assignment operator taking a shared_ptr<void> as an argument supposed be well-formed? @@ -5479,7 +5624,23 @@ int main () </pre></blockquote> <p><b>Proposed resolution:</b></p> <p> +In [lib.memory] change: +</p> +<blockquote><pre>template<class X> class auto_ptr; +<ins>template<> class auto_ptr<void>;</ins> +</pre></blockquote> + +<p> +In [lib.auto.ptr]/2 add the following before the last closing brace: </p> + +<blockquote><pre>template<> class auto_ptr<void> +{ +public: + typedef void element_type; +}; +</pre></blockquote> + <hr> <a name="542"><h3>542. shared_ptr observers</h3></a><p><b>Section:</b> TR1 2.2.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.smartptr.shared.obs"> [tr.util.smartptr.shared.obs]</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> 18 Oct 2005</p> <p> @@ -5517,7 +5678,7 @@ capture the intent. <p> </p> <hr> -<a name="543"><h3>543. valarray slice default constructor</h3></a><p><b>Section:</b> 26.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.class.slice"> [lib.class.slice]</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> 3 Nov 2005</p> +<a name="543"><h3>543. valarray slice default constructor</h3></a><p><b>Section:</b> 26.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.members"> [lib.complex.members]</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> 3 Nov 2005</p> <p> If one explicitly constructs a slice or glice with the default constructor, does the standard require this slice to have any usable @@ -5557,7 +5718,7 @@ There is a similar question and wording for gslice at 26.3.6.1p1. <p> </p> <hr> -<a name="544"><h3>544. minor NULL problems in C.2</h3></a><p><b>Section:</b> C.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/diff.html#diff.library"> [diff.library]</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> 25 Nov 2005</p> +<a name="544"><h3>544. minor NULL problems in C.2</h3></a><p><b>Section:</b> C.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/diff.html#diff.library"> [diff.library]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Tentatively%20Ready">Tentatively Ready</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 25 Nov 2005</p> <p> According to C.2.2.3, p1, "the macro NULL, defined in any of <clocale>, <cstddef>, <cstdio>, <cstdlib>, <cstring>, <ctime>, @@ -5596,7 +5757,19 @@ instances). We should say which it is. </p> <p><b>Proposed resolution:</b></p> <p> +Add after the first sentence of [lib.util.smartptr.getdeleter]/1: +</p> +<blockquote> +<p> +The returned pointer remains valid as long as there exists a <tt>shared_ptr</tt> instance +that owns <tt><i>d</i></tt>. +</p> +<p> +[<i>Note:</i> it is unspecified whether the pointer remains valid longer than that. +This can happen if the implementation doesn't destroy the deleter until all +<tt>weak_ptr</tt> instances in the ownership group are destroyed. <i>-- end note</i>] </p> +</blockquote> <hr> <a name="546"><h3>546. _Longlong and _ULonglong are integer types</h3></a><p><b>Section:</b> TR1 5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.req"> [tr.rand.req]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 10 Jan 2006</p> <p> @@ -5665,7 +5838,7 @@ are. What's n? Berlin: Typo: "n" replaced by "t" in N1932: see 26.3.7.2.2/1. </p> <hr> -<a name="550"><h3>550. What should the return type of pow(float,int) be?</h3></a><p><b>Section:</b> 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.c.math"> [lib.c.math]</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> 12 Jan 2006</p> +<a name="550"><h3>550. What should the return type of pow(float,int) be?</h3></a><p><b>Section:</b> 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numarray"> [lib.numarray]</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> 12 Jan 2006</p> <p> Assuming we adopt the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">C @@ -6005,7 +6178,7 @@ member of <code>numeric_limits<T></code>. </p> <hr> -<a name="560"><h3>560. User-defined allocators without default constructor</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> Sergey P. Derevyago <b>Date:</b> 17 Feb 2006</p> +<a name="560"><h3>560. User-defined allocators without default constructor</h3></a><p><b>Section:</b> 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.default.con.req"> [lib.default.con.req]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Sergey P. Derevyago <b>Date:</b> 17 Feb 2006</p> <h4>1. The essence of the problem.</h4> <p> User-defined allocators without default constructor are not explicitly @@ -6594,7 +6767,7 @@ And change 27.6.2.5.3, p7 as follows: Add <tt>log2</tt> to the list of functions in 8.16.4p1. </p> <hr> -<a name="569"><h3>569. Postcondition for basic_ios::clear(iostate) incorrectly stated</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#New">New</a> <b>Submitter:</b> Seungbeom Kim <b>Date:</b> 10 Mar 2006</p> +<a name="569"><h3>569. Postcondition for basic_ios::clear(iostate) incorrectly stated</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#Tentatively%20Ready">Tentatively Ready</a> <b>Submitter:</b> Seungbeom Kim <b>Date:</b> 10 Mar 2006</p> <p> Section: 27.4.4.3 [lib.iostate.flags] </p> @@ -6616,13 +6789,10 @@ The postcondition "rdstate()==state|ios_base::badbit" is parsed as committee meant. </p> <p><b>Proposed resolution:</b></p> +<p><b>Rationale:</b></p> <p> -Change 27.4.4.3p4: +This is a duplicate of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a>. </p> -<blockquote> -<i>Postcondition:</i> If <tt>rdbuf()!=0</tt> then <tt><i>state</i> == rdstate();</tt> -otherwise <tt>rdstate()==<ins>(</ins><i>state</i>|ios_base::badbit</tt><ins>)</ins>. -</blockquote> <hr> <a name="570"><h3>570. Request adding additional explicit specializations of char_traits</h3></a><p><b>Section:</b> 21.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits"> [lib.char.traits]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Jack Reeves <b>Date:</b> 6 Apr 2006</p> <p> @@ -6672,7 +6842,7 @@ this issue WP status (mistakenly). Strike the proposed resolution of issue 507. </p> <hr> -<a name="573"><h3>573. C++0x file positioning should handle modern file sizes</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#New">New</a> <b>Submitter:</b> Your name <b>Date:</b> 29 Feb 1900</p> +<a name="573"><h3>573. C++0x file positioning should handle modern file sizes</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#New">New</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 12 Apr 2006</p> <p> There are two deficiencies related to file sizes: </p> @@ -6723,5 +6893,954 @@ not destroyed during program execution." <p><b>Proposed resolution:</b></p> <p> </p> +<hr> +<a name="575"><h3>575. the specification of ~shared_ptr is MT-unfriendly, makes implementation assumptions</h3></a><p><b>Section:</b> 20.6.6.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.util.smartptr.shared.dest"> [lib.util.smartptr.shared.dest]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Peter Dimov <b>Date:</b> 23 Apr 2006</p> +<p> +[tr.util.smartptr.shared.dest] says in its second bullet: +</p> + +<p> +"If *this shares ownership with another shared_ptr instance (use_count() > 1), +decrements that instance's use count." +</p> + +<p> +The problem with this formulation is that it presupposes the existence of an +"use count" variable that can be decremented and that is part of the state of a +shared_ptr instance (because of the "that instance's use count".) +</p> + +<p> +This is contrary to the spirit of the rest of the specification that carefully +avoids to require an use count variable. Instead, use_count() is specified to +return a value, a number of instances. +</p> + +<p> +In multithreaded code, the usual implicit assumption is that a shared variable +should not be accessed by more than one thread without explicit synchronization, +and by introducing the concept of an "use count" variable, the current wording +implies that two shared_ptr instances that share ownership cannot be destroyed +simultaneously. +</p> + +<p> +In addition, if we allow the interpretation that an use count variable is part +of shared_ptr's state, this would lead to other undesirable consequences WRT +multiple threads. For example, +</p> + +<blockquote><pre>p1 = p2; +</pre></blockquote> + +<p> +would now visibly modify the state of p2, a "write" operation, requiring a lock. +</p> +<p><b>Proposed resolution:</b></p> +<p> +Change the first two bullets of [lib.util.smartptr.shared.dest]/1 to: +</p> + +<blockquote><p> +</p><ul> +<li>If <tt>*this</tt> is <i>empty</i> <ins>or shares ownership with another +<tt>shared_ptr</tt> instance (<tt>use_count() > 1</tt>)</ins>, there are no side effects.</li> +<li><del>If <tt>*this</tt> <i>shares ownership</i> with another <tt>shared_ptr</tt> instance +(<tt>use_count() > 1</tt>), decrements that instance's use count.</del></li> +</ul> +<p></p></blockquote> + +<p> +Add the following paragraph after [lib.util.smartptr.shared.dest]/1: +</p> + +<blockquote><p> +[<i>Note:</i> since the destruction of <tt>*this</tt> decreases the number of instances in +<tt>*this</tt>'s ownership group by one, all <tt>shared_ptr</tt> instances that share ownership +with <tt>*this</tt> will report an <tt>use_count()</tt> that is one lower than its previous value +after <tt>*this</tt> is destroyed. <i>--end note</i>] +</p></blockquote> +<hr> +<a name="576"><h3>576. find_first_of is overconstrained</h3></a><p><b>Section:</b> 25.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.find.first.of"> [lib.alg.find.first.of]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Doug Gregor <b>Date:</b> 25 Apr 2006</p> +<p> +In 25.1.4 Find First [lib.alg.find.first], the two iterator type parameters to +find_first_of are specified to require Forward Iterators, as follows: +</p> + +<blockquote><pre>template<class ForwardIterator1, class ForwardIterator2> + ForwardIterator1 + find_first_of(ForwardIterator1 first1, ForwardIterator1 last1, + ForwardIterator2 first2, ForwardIterator2 last2); +template<class ForwardIterator1, class ForwardIterator2, + class BinaryPredicate> +ForwardIterator1 + find_first_of(ForwardIterator1 first1, ForwardIterator1 last1, + ForwardIterator2 first2, ForwardIterator2 last2, + BinaryPredicate pred); +</pre></blockquote> + +<p> +However, ForwardIterator1 need not actually be a Forward Iterator; an Input +Iterator suffices, because we do not need the multi-pass property of the Forward +Iterator or a true reference. +</p> +<p><b>Proposed resolution:</b></p> +<p> +Change the declarations of <tt>find_first_of</tt> to: +</p> + +<blockquote><pre>template<class <del>ForwardIterator1</del><ins>InputIterator1</ins>, class ForwardIterator2> + <del>ForwardIterator1</del><ins>InputIterator1</ins> + find_first_of(<del>ForwardIterator1</del><ins>InputIterator1</ins> first1, <del>ForwardIterator1</del><ins>InputIterator1</ins> last1, + ForwardIterator2 first2, ForwardIterator2 last2); +template<class <del>ForwardIterator1</del><ins>InputIterator1</ins>, class ForwardIterator2, + class BinaryPredicate> +<del>ForwardIterator1</del><ins>InputIterator1</ins> + find_first_of(<del>ForwardIterator1</del><ins>InputIterator1</ins> first1, <del>ForwardIterator1</del><ins>InputIterator1</ins> last1, + ForwardIterator2 first2, ForwardIterator2 last2, + BinaryPredicate pred); +</pre></blockquote> + +<hr> +<a name="577"><h3>577. upper_bound(first, last, ...) cannot return last</h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Seungbeom Kim <b>Date:</b> 3 May 2006</p> +<p> +ISO/IEC 14882:2003 says: +</p> + +<blockquote> +<p> +25.3.3.2 upper_bound +</p> +<p> +<i>Returns:</i> The furthermost iterator <tt>i</tt> in the range +<tt>[<i>first</i>, <i>last</i>)</tt> such that +for any iterator <tt>j</tt> in the range <tt>[<i>first</i>, i)</tt> the following corresponding +conditions hold: <tt>!(value < *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j) == false</tt>. +</p> +</blockquote> + +<p> +From the description above, upper_bound cannot return last, since it's +not in the interval [first, last). This seems to be a typo, because if +value is greater than or equal to any other values in the range, or if +the range is empty, returning last seems to be the intended behaviour. +The corresponding interval for lower_bound is also [first, last]. +</p> +<p><b>Proposed resolution:</b></p> +<p> +Change [lib.upper.bound]: +</p> + +<blockquote> +<p> +<i>Returns:</i> The furthermost iterator <tt>i</tt> in the range +<tt>[<i>first</i>, <i>last</i><del>)</del><ins>]</ins></tt> such that +for any iterator <tt>j</tt> in the range <tt>[<i>first</i>, i)</tt> the following corresponding +conditions hold: <tt>!(value < *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j) == false</tt>. +</p> +</blockquote> + +<hr> +<a name="578"><h3>578. purpose of hint to allocator::allocate()</h3></a><p><b>Section:</b> 20.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</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> 17 May 2006</p> + <p> + +The description of the allocator member function +<code>allocate()</code> requires that the <i>hint</i> argument be +either 0 or a value previously returned from <code>allocate()</code>. +Footnote 227 further suggests that containers may pass the address of +an adjacent element as this argument. + + </p> + <p> + +I believe that either the footnote is wrong or the normative +requirement that the argument be a value previously returned from a +call to <code>allocate()</code> is wrong. The latter is supported by +the resolution to issue 20-004 proposed in c++std-lib-3736 by Nathan +Myers. In addition, the <i>hint</i> is an ordinary void* and not the +<code>pointer</code> type returned by <code>allocate()</code>, with +the two types potentially being incompatible and the requirement +impossible to satisfy. + + </p> + <p> + +See also c++std-lib-14323 for some more context on where this came up +(again). + + </p> + <p><b>Proposed resolution:</b></p> + <p> + +Remove the requirement in 20.6.1.1, p4 that the hint be a value +previously returned from <code>allocate()</code>. Specifically, change +the paragraph as follows: + + </p> + <p> + +<i>Requires</i>: <i>hint</i> <ins>is </ins>either 0 or <del>previously +obtained from member <code>allocate</code> and not yet passed to +member <code>deallocate</code></del><ins> the address of a byte in +memory (1.7)</ins>. + + </p> + <hr> +<a name="579"><h3>579. erase(iterator) for unordered containers should not return an iterator</h3></a><p><b>Section:</b> 23.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.unord.req"> [lib.unord.req]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Joaquín M López Muñoz <b>Date:</b> 13 Jun 2006</p> +<p> +See +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf">N2023</a> +for full discussion. +</p> +<p><b>Proposed resolution:</b></p> +<p> +Option 1: +</p> + +<p> +The problem can be eliminated by omitting the requirement that <tt>a.erase(q)</tt> return an +iterator. This is, however, in contrast with the equivalent requirements for other +standard containers. +</p> + +<p> +Option 2: +</p> + +<p> +<tt>a.erase(q)</tt> can be made to compute the next iterator only when explicitly requested: +the technique consists in returning a proxy object implicitly convertible to <tt>iterator</tt>, so +that +</p> + +<blockquote><pre>iterator q1=a.erase(q); +</pre></blockquote> + +<p> +works as expected, while +</p> + +<blockquote><pre>a.erase(q); +</pre></blockquote> + +<p> +does not ever invoke the conversion-to-iterator operator, thus avoiding the associated +computation. To allow this technique, some sections of TR1 along the line "return value +is an iterator..." should be changed to "return value is an unspecified object implicitly +convertible to an iterator..." Although this trick is expected to work transparently, it can +have some collateral effects when the expression <tt>a.erase(q)</tt> is used inside generic +code. +</p> + +<hr> +<a name="580"><h3>580. unused allocator members</h3></a><p><b>Section:</b> 20.1.6 <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> Martin Sebor <b>Date:</b> 14 June 2006</p> + <p> + +C++ Standard Library templates that take an allocator as an argument +are required to call the <code>allocate()</code> and +<code>deallocate()</code> members of the allocator object to obtain +storage. However, they do not appear to be required to call any other +allocator members such as <code>construct()</code>, +<code>destroy()</code>, <code>address()</code>, and +<code>max_size()</code>. This makes these allocator members less than +useful in portable programs. + + </p> + <p><b>Proposed resolution:</b></p> + <p> + +It's unclear to me whether the absence of the requirement to use these +allocator members is an unintentional omission or a deliberate +choice. However, since the functions exist in the standard allocator +and since they are required to be provided by any user-defined +allocator I believe the standard ought to be clarified to explictly +specify whether programs should or should not be able to rely on +standard containers calling the functions. + + </p> + <p> + +I propose that all containers be required to make use of these +functions. + + </p> + <hr> +<a name="581"></a><h3><a name="581">581. <code>flush()</code> not unformatted function</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#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 14 June 2006</p> + <p> + +The resolution of issue 60 changed <code>basic_ostream::flush()</code> +so as not to require it to behave as an unformatted output function. +That has at least two in my opinion problematic consequences: + + </p> + <p> + +First, <code>flush()</code> now calls <code>rdbuf()->pubsync()</code> +unconditionally, without regard to the state of the stream. I can't +think of any reason why <code>flush()</code> should behave differently +from the vast majority of stream functions in this respect. + + </p> + <p> + +Second, <code>flush()</code> is not required to catch exceptions from +<code>pubsync()</code> or set <code>badbit</code> in response to such +events. That doesn't seem right either, as most other stream functions +do so. + + </p> + <p><b>Proposed resolution:</b></p> + <p> + +I propose to revert the resolution of issue 60 with respect to +<code>flush()</code>. Specifically, I propose to change 27.6.2.6, p7 +as follows: + + </p> + +Effects: <ins>Behaves as an unformatted output function (as described +in 27.6.2.6, paragraph 1). </ins>If <code>rdbuf()</code> is not a null +pointer, <ins>constructs a sentry object. If this object returns +<code>true</code> when converted to a value of type bool the function +</ins>calls <code>rdbuf()->pubsync()</code>. If that function returns +-1 calls <code>setstate(badbit)</code> (which may throw +<code>ios_base::failure</code> (27.4.4.3)). <ins>Otherwise, if the +sentry object returns <code>false</code>, does nothing.</ins><del>Does +not behave as an unformatted output function (as described in +27.6.2.6, paragraph 1).</del> + + <hr> +<a name="582"><h3>582. specialized algorithms and volatile storage</h3></a><p><b>Section:</b> 20.6.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.uninitialized.copy"> [lib.uninitialized.copy]</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> 14 June 2006</p> + <p> + +The specialized algorithms [lib.specialized.algorithms] are specified +as having the general effect of invoking the following expression: + + </p> + <p> + </p><pre> +new (static_cast<void*>(&*i)) + typename iterator_traits<ForwardIterator>::value_type (x) + + </pre> + <p></p> + <p> + +This expression is ill-formed when the type of the subexpression +<code>&*i</code> is some volatile-qualified <code>T</code>. + + </p> + <p><b>Proposed resolution:</b></p> + <p> + +In order to allow these algorithms to operate on volatile storage I +propose to change the expression so as to make it well-formed even for +pointers to volatile types. Specifically, I propose the following +changes to clauses 20 and 24. Change 20.6.4.1, p1 to read: + + </p> + <p> + </p><pre> +<i>Effects</i>: + +typedef typename iterator_traits<ForwardIterator>::pointer pointer; +typedef typename iterator_traits<ForwardIterator>::value_type value_type; + +for (; first != last; ++result, ++first) + new (static_cast<void*>(const_cast<pointer>(&*result)) + value_type (*first); + + </pre> + <p></p> + <p> + +change 20.6.4.2, p1 to read + + </p> + <p> + </p><pre> +<i>Effects</i>: + +typedef typename iterator_traits<ForwardIterator>::pointer pointer; +typedef typename iterator_traits<ForwardIterator>::value_type value_type; + +for (; first != last; ++result, ++first) + new (static_cast<void*>(const_cast<pointer>(&*first)) + value_type (*x); + + </pre> + <p></p> + <p> + +and change 20.6.4.3, p1 to read + + </p> + <p> + </p><pre> +<i>Effects</i>: + +typedef typename iterator_traits<ForwardIterator>::pointer pointer; +typedef typename iterator_traits<ForwardIterator>::value_type value_type; + +for (; n--; ++first) + new (static_cast<void*>(const_cast<pointer>(&*first)) + value_type (*x); + + </pre> + <p></p> + <p> + +In addition, since there is no partial specialization for +<code>iterator_traits<volatile T*></code> I propose to add one +to parallel such specialization for <const T*>. Specifically, I +propose to add the following text to the end of 24.3.1, p3: + + </p> + <p> + +and for pointers to volatile as + + </p> + <p> + </p><pre> +namespace std { +template<class T> struct iterator_traits<volatile T*> { +typedef ptrdiff_t difference_type; +typedef T value_type; +typedef volatile T* pointer; +typedef volatile T& reference; +typedef random_access_iterator_tag iterator_category; +}; +} + + </pre> + <p></p> + <p> + +Note that the change to <code>iterator_traits</code> isn't necessary +in order to implement the specialized algorithms in a way that allows +them to operate on volatile strorage. It is only necesassary in order +to specify their effects in terms of <code>iterator_traits</code> as +is done here. Implementations can (and some do) achieve the same +effect by means of function template overloading. + + </p> + <hr> +<a name="583"><h3>583. div() for unsigned integral types</h3></a><p><b>Section:</b> 26.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.c.math"> [lib.c.math]</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> 15 Jun 2006</p> +<p> +There is no div() function for unsigned integer types. +</p> +<p> +There are several possible resolutions. The simplest one is noted below. Other +possibilities include a templated solution. +</p> +<p><b>Proposed resolution:</b></p> +<p> +Add to 26.7 [lib.c.math] paragraph 8: +</p> + +<blockquote><pre>struct udiv_t div(unsigned, unsigned); +struct uldiv_t div(unsigned long, unsigned long); +struct ulldiv_t div(unsigned long long, unsigned long long); +</pre></blockquote> + +<hr> +<a name="584"><h3>584. missing int pow(int,int) functionality</h3></a><p><b>Section:</b> 26.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.c.math"> [lib.c.math]</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> 15 Jun 2006</p> +<p> +There is no pow() function for any integral type. +</p> +<p><b>Proposed resolution:</b></p> +<p> +Add something like: +</p> + +<blockquote><pre>template< typename T> +T power( T x, int n ); +// requires: n >=0 +</pre></blockquote> +<hr> +<a name="585"></a><h3><a name="585">585. facet error reporting</a></h3><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> Martin Sebor, Paolo Carlini <b>Date:</b> 22 June 2006</p> + <p> + +Section 22.2, paragraph 2 requires facet <code>get()</code> members +that take an <code>ios_base::iostate&</code> argument, +<code><i>err</i></code>, to ignore the (initial) value of the +argument, but to set it to <code>ios_base::failbit</code> in case of a +parse error. + + </p> + <p> + +We believe there are a few minor problems with this blanket +requirement in conjunction with the wording specific to each +<code>get()</code> member function. + + </p> + <p> + +First, besides <code>get()</code> there are other member functions +with a slightly different name (for example, +<code>get_date()</code>). It's not completely clear that the intent of +the paragraph is to include those as well, and at least one +implementation has interpreted the requirement literally. + + </p> + <p> + +Second, the requirement to "set the argument to +<code>ios_base::failbit</code> suggests that the functions are not +permitted to set it to any other value (such as +<code>ios_base::eofbit</code>, or even <code>ios_base::eofbit | +ios_base::failbit</code>). + + </p> + <p> + +However, 22.2.2.1.2, p5 (Stage 3 of <code>num_get</code> parsing) and +p6 (<code>bool</code> parsing) specifies that the <code>do_get</code> +functions perform <code><i>err</i> |= ios_base::eofbit</code>, which +contradicts the earlier requirement to ignore <i>err</i>'s initial +value. + + </p> + <p> + +22.2.6.1.2, p1 (the Effects clause of the <code>money_get</code> +facet's <code>do_get</code> member functions) also specifies that +<code><i>err</i></code>'s initial value be used to compute the final +value by ORing it with either <code>ios_base::failbit</code> or +with<code>ios_base::eofbit | ios_base::failbit</code>. + + </p> + <p><b>Proposed resolution:</b></p> + <p> + +We believe the intent is for all facet member functions that take an +<code>ios_base::iostate&</code> argument to: + + </p> + <p> + </p><ul> + <li> + +ignore the initial value of the <code><i>err</i></code> argument, + + </li> + <li> + +reset <code><i>err</i></code> to <code>ios_base::goodbit</code> prior +to any further processing, + + </li> + <li> + +and set either <code>ios_base::eofbit</code>, or +<code>ios_base::failbit</code>, or both in <code><i>err</i></code>, as +appropriate, in response to reaching the end-of-file or on parse +error, or both. + + </li> + </ul> + <p></p> + <p> + +To that effect we propose to change 22.2, p2 as follows: + + </p> + <p> + +The <i>put</i><del>()</del> members make no provision for error +reporting. (Any failures of the OutputIterator argument must be +extracted from the returned iterator.) <ins>Unless otherwise +specified, </ins>the <i>get</i><del>()</del> members <ins>that</ins> +take an <code>ios_base::iostate&</code> argument <del>whose value +they ignore, but set to ios_base::failbit in case of a parse +error.</del><ins>, <code><i>err</i></code>, start by evaluating +<code>err = ios_base::goodbit</code>, and may subsequently set +<i>err</i> to either <code>ios_base::eofbit</code>, or +<code>ios_base::failbit</code>, or <code>ios_base::eofbit | +ios_base::failbit</code> in response to reaching the end-of-file or in +case of a parse error, or both, respectively.</ins> + + </p> + <hr> +<a name="586"><h3>586. string inserter not a formatted function</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#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 22 June 2006</p> + <p> + +Section and paragraph numbers in this paper are relative to the +working draft document number N2009 from 4/21/2006. + + </p> + + <p> + +The <code>basic_string</code> extractor in 21.3.7.9, p1 is clearly +required to behave as a formatted input function, as is the +<code>std::getline()</code> overload for string described in p7. + + </p> + <p> + +However, the <code>basic_string</code> inserter described in p5 of the +same section has no such requirement. This has implications on how the +operator responds to exceptions thrown from <code>xsputn()</code> +(formatted output functions are required to set <code>badbit</code> +and swallow the exception unless <code>badbit</code> is also set in +<code>exceptions()</code>; the string inserter doesn't have any such +requirement). + + </p> + <p> + +I don't see anything in the spec for the string inserter that would +justify requiring it to treat exceptions differently from all other +similar operators. (If it did, I think it should be made this explicit +by saying that the operator "does not behave as a formatted output +function" as has been made customary by the adoption of the resolution +of issue 60). + + </p> + <p><b>Proposed resolution:</b></p> + <p> + +I propose to change the Effects clause in 21.3.7.9, p5, as follows: + + </p> + <p> + </p><blockquote> + +<i>Effects</i>: <del>Begins by constructing a sentry object k as if k +were constructed by typename <code>basic_ostream<charT, +traits>::sentry k (os)</code>. If <code>bool(k)</code> is +<code>true</code>, </del><ins>Behaves as a formatted output function +(27.6.2.5.1). After constructing a <code>sentry</code> object, if +this object returns <code>true</code> when converted to a value of +type <code>bool</code>, determines padding as described in +22.2.2.2.2</ins>, then inserts the resulting sequence of characters +<code><i>seq</i></code> as if by calling <code>os.rdbuf()->sputn(seq , +n)</code>, where <code><i>n</i></code> is the larger of +<code>os.width()</code> and <code>str.size()</code>; then calls +<code>os.width(0)</code>. <del>If the call to sputn fails, calls +<code>os.setstate(ios_base::failbit)</code>.</del> + + </blockquote> + <p></p> + <p> + +This proposed resilution assumes the resolution of issue 394 (i.e., +that all formatted output functions are required to set +<code>ios_base::badbit</code> in response to any kind of streambuf +failure), and implicitly assumes that a return value of +<code>sputn(seq, <i>n</i>)</code> other than <code><i>n</i></code> +indicates a failure. + + </p> + <hr> +<a name="587"><h3>587. iststream ctor missing description</h3></a><p><b>Section:</b> D.7.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.istrstream.cons"> [depr.istrstream.cons]</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> 22 June 2006</p> + <p> + +The <code>iststream(char*, streamsize)</code> ctor is in the class +synopsis in D.7.2 but its signature is missing in the description +below (in D.7.2.1). + + </p> + <p><b>Proposed resolution:</b></p> + <p> + +This seems like a simple editorial issue and the missing signature can +be added to the one for <code>const char*</code> in paragraph 2. + + </p> + <hr> +<a name="588"><h3>588. requirements on zero sized tr1::arrays and other details</h3></a><p><b>Section:</b> 23.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.array"> [lib.array]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Gennaro Prota <b>Date:</b> 18 Jul 2006</p> +<p> +The wording used for section 23.2.1 [lib.array] seems to be subtly +ambiguous about zero sized arrays (N==0). Specifically: +</p> +<p> +* "An instance of array<T, N> stores N elements of type T, so that +[...]" +</p> +<p> +Does this imply that a zero sized array object stores 0 elements, i.e. +that it cannot store any element of type T? The next point clarifies +the rationale behind this question, basically how to implement begin() +and end(): +</p> +<p> +* 23.2.1.5 [lib.array.zero], p2: "In the case that N == 0, begin() == +end() == unique value." +</p> +<p> +What does "unique" mean in this context? Let's consider the following +possible implementations, all relying on a partial specialization: +</p> +<blockquote><pre>a) + template< typename T > + class array< T, 0 > { + + .... + + iterator begin() + { return iterator( reinterpret_cast< T * >( this ) ); } + .... + + }; +</pre></blockquote> +<p> +This has been used in boost, probably intending that the return value +had to be unique to the specific array object and that array couldn't +store any T. Note that, besides relying on a reinterpret_cast, has +(more than potential) alignment problems. +</p> +<blockquote><pre>b) + template< typename T > + class array< T, 0 > { + + T t; + + iterator begin() + { return iterator( &t ); } + .... + + }; +</pre></blockquote> +<p> +This provides a value which is unique to the object and to the type of +the array, but requires storing a T. Also, it would allow the user to +mistakenly provide an initializer list with one element. +</p> +<p> +A slight variant could be returning *the* null pointer of type T +</p> +<blockquote><pre> return static_cast<T*>(0); +</pre></blockquote> +<p> +In this case the value would be unique to the type array<T, 0> but not +to the objects (all objects of type array<T, 0> with the same value +for T would yield the same pointer value). +</p> +<p> +Furthermore this is inconsistent with what the standard requires from +allocation functions (see library issue 9). +</p> +<p> +c) same as above but with t being a static data member; again, the +value would be unique to the type, not to the object. +</p> +<p> +d) to avoid storing a T *directly* while disallowing the possibility +to use a one-element initializer list a non-aggregate nested class +could be defined +</p> +<blockquote><pre> struct holder { holder() {} T t; } h; +</pre></blockquote> +<p> +and then begin be defined as +</p> +<blockquote><pre> iterator begin() { return &h.t; } +</pre></blockquote> +<p> +But then, it's arguable whether the array stores a T or not. +Indirectly it does. +</p> +<p> +----------------------------------------------------- +</p> +<p> +Now, on different issues: +</p> +<p> +* what's the effect of calling assign(T&) on a zero-sized array? There +seems to be only mention of front() and back(), in 23.2.1 [lib.array] +p4 (I would also suggest to move that bullet to section 23.2.1.5 +[lib.array.zero], for locality of reference) +</p> +<p> +* (minor) the opening paragraph of 23.2.1 [lib.array] wording is a bit +inconsistent with that of other sequences: that's not a problem in +itself, but compare it for instance with "A vector is a kind of +sequence that supports random access iterators"; though the intent is +obvious one might argue that the wording used for arrays doesn't tell +what an array is, and relies on the reader to infer that it is what +the <array> header defines. +</p> +<p> +* it would be desiderable to have a static const data member of type +std::size_t, with value N, for usage as integral constant expression +</p> +<p> +* section 23.1 [lib.container.requirements] seem not to consider +fixed-size containers at all, as it says: "[containers] control +allocation and deallocation of these objects [the contained objects] +through constructors, destructors, *insert and erase* operations" +</p> +<p> +* max_size() isn't specified: the result is obvious but, technically, +it relies on table 80: "size() of the largest possible container" +which, again, doesn't seem to consider fixed size containers +</p> +<p><b>Proposed resolution:</b></p> +<p> +</p> +<hr> +<a name="589"><h3>589. Requirements on iterators of member template functions of containers</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> Peter Dimov <b>Date:</b> 2 Aug 2006</p> +<p> +There appears to be no requirements on the InputIterators used in sequences in 23.1.1 in +terms of their value_type, and the requirements in 23.1.2 appear to be overly strict +(requires InputIterator::value_type be the same type as the container's value_type). +</p> +<p><b>Proposed resolution:</b></p> +<p> +Change 23.1.1 p3: +</p> + +<blockquote> +In Tables 82 and 83, <tt>X</tt> denotes a sequence class, <tt>a</tt> denotes a +value of <tt>X</tt>, <tt>i</tt> and <tt>j</tt> denote iterators satisfying input +iterator requirements <ins>and refer to elements <ins>implicitly +convertible to</ins> <tt>value_type</tt></ins>, <tt>[i, j)</tt> denotes a valid +range, <tt>n</tt> denotes a value of <tt>X::size_type</tt>, <tt>p</tt> denotes a +valid iterator to <tt>a</tt>, <tt>q</tt> denotes a valid dereferenceable +iterator to <tt>a</tt>, <tt>[q1, q2)</tt> denotes a valid range in <tt>a</tt>, +and <tt>t</tt> denotes a value of <tt>X::value_type</tt>. +</blockquote> + +<p> +Change 23.1.2 p7: +</p> + +<blockquote> +In Table 84, <tt>X</tt> is an associative container class, <tt>a</tt> is a value +of <tt>X</tt>, <tt>a_uniq</tt> is a value of <tt>X</tt> when <tt>X</tt> supports +unique keys, and <tt>a_eq</tt> is a value of <tt>X</tt> when <tt>X</tt> supports +multiple keys, <tt>i</tt> and <tt>j</tt> satisfy input iterator requirements and +refer to elements <del>of</del> <ins>implicitly convertible to</ins> +<tt>value_type</tt>, <tt>[i, j)</tt> is a valid range, <tt>p</tt> is a valid +iterator to <tt>a</tt>, <tt>q</tt> is a valid dereferenceable iterator to +<tt>a</tt>, <tt>[q1, q2)</tt> is a valid range in <tt>a</tt>, <tt>t</tt> is a +value of <tt>X::value_type</tt>, <tt>k</tt> is a value of <tt>X::key_type</tt> +and <tt>c</tt> is a value of type <tt>X::key_compare</tt>. +</blockquote> + +<hr> +<a name="590"><h3>590. Type traits implementation latitude should be removed for C++0x</h3></a><p><b>Section:</b> <font color="red">20.4.9</font> <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 Aug 2006</p> +<p> +20.4.9 [lib.meta.req], Implementation requirements, provides latitude for type +traits implementers that is not needed in C++0x. It includes the wording: +</p> + +<blockquote> +[<i>Note:</i> the latitude granted to implementers in this clause is temporary, +and is expected to be removed in future revisions of this document. -- <i>end note</i>] +</blockquote> + +<p> +Note: +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2028.html">N2028: +Minor Modifications to the type traits Wording</a> +also has the intent of removing this wording from the WP. +</p> + +<p><b>Proposed resolution:</b></p> +<p> +Remove 20.4.9 [lib.meta.req] in its entirety from the WP. +</p> +<hr> +<a name="591"><h3>591. Misleading "built-in</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#New">New</a> <b>Submitter:</b> whyglinux <b>Date:</b> 8 Aug 2006</p> +<p> +18.2.1.2 numeric_limits members [lib.numeric.limits.members] +Paragraph 7: +</p> +<blockquote> +"For built-in integer types, the number of non-sign bits in the +representation." +</blockquote> + +<p> +26.1 Numeric type requirements [lib.numeric.requirements] +Footnote: +</p> + +<blockquote> +"In other words, value types. These include built-in arithmetic types, +pointers, the library class complex, and instantiations of valarray for +value types." +</blockquote> + +<p> +Integer types (which are bool, char, wchar_t, and the signed and +unsigned integer types) and arithmetic types (which are integer and +floating types) are all built-in types and thus there are no +non-built-in (that is, user-defined) integer or arithmetic types. Since +the redundant "built-in" in the above 2 sentences can mislead that +there may be built-in or user-defined integer and arithmetic types +(which is not correct), the "built-in" should be removed. +</p> +<p><b>Proposed resolution:</b></p> +<p> +</p><p> +18.2.1.2 numeric_limits members [lib.numeric.limits.members] +Paragraph 7: +</p> +<blockquote> +"For <del>built-in</del> integer types, the number of non-sign bits in the +representation." +</blockquote> + +<p> +26.1 Numeric type requirements [lib.numeric.requirements] +Footnote: +</p> + +<blockquote> +"In other words, value types. These include <del>built-in</del> arithmetic types, +pointers, the library class complex, and instantiations of valarray for +value types." +</blockquote> +<p></p> +<hr> +<a name="592"><h3>592. Incorrect treatment of rdbuf()->close() return type</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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Christopher Kohlhoff <b>Date:</b> 17 Aug 2006</p> +<p> +I just spotted a minor problem in 27.8.1.7 +[lib.ifstream.members] para 4 and also 27.8.1.13 +[lib.fstream.members] para 4. In both places it says: +</p> +<blockquote> +<pre>void close(); +</pre> +<p> +Effects: Calls rdbuf()->close() and, if that function returns false, ... +</p> +</blockquote> +<p> +However, basic_filebuf::close() (27.8.1.2) returns a pointer to the +filebuf on success, null on failure, so I think it is meant to +say "if that function returns a null pointer". Oddly, it is +correct for basic_ofstream. +</p> +<p><b>Proposed resolution:</b></p> +<p> +Change 27.8.1.7 [lib.ifstream.members], p5: +</p> + +<blockquote> +<i>Effects:</i> Calls <tt>rdbuf()->close()</tt> and, if that function +<ins>fails (</ins>returns <del><tt>false</tt></del> <ins>a null pointer)</ins>, +calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt> +(27.4.4.3)). +</blockquote> + +<p> +Change 27.8.1.13 [lib.fstream.members], p5: +</p> + +<blockquote> +<i>Effects:</i> Calls <tt>rdbuf()->close()</tt> and, if that function +<ins>fails (</ins>returns <del><tt>false</tt></del> <ins>a null pointer)</ins>, +calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt> +(27.4.4.3)). +</blockquote> + <p>----- End of document -----</p> </body></html>
\ No newline at end of file diff --git a/libstdc++-v3/docs/html/ext/lwg-defects.html b/libstdc++-v3/docs/html/ext/lwg-defects.html index 1907a4a8502..ab3fe6bc622 100644 --- a/libstdc++-v3/docs/html/ext/lwg-defects.html +++ b/libstdc++-v3/docs/html/ext/lwg-defects.html @@ -8,11 +8,11 @@ del {background-color:#FFFFA0}</style></head> <table> <tbody><tr> <td align="left">Doc. no.</td> -<td align="left">N2001=06-0071</td> +<td align="left">N2092=06-0162</td> </tr> <tr> <td align="left">Date:</td> -<td align="left">2006-04-21</td> +<td align="left">2006-09-08</td> </tr> <tr> <td align="left">Project:</td> @@ -23,7 +23,7 @@ del {background-color:#FFFFA0}</style></head> <td align="left">Howard Hinnant <howard.hinnant@gmail.com></td> </tr> </tbody></table> -<h1>C++ Standard Library Defect Report List (Revision R42)</h1> +<h1>C++ Standard Library Defect Report List (Revision R44)</h1> <p>Reference ISO/IEC IS 14882:1998(E)</p> <p>Also see:</p> <ul> @@ -45,6 +45,16 @@ del {background-color:#FFFFA0}</style></head> document.</p> <h2>Revision History</h2> <ul> +<li>R44: +2006-09-08 pre-Portland mailing. +Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#583">583</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#592">592</a>. +</li> +<li>R43: +2006-06-23 mid-term mailing. +Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#575">575</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>. +Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255">255</a>. +Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#569">569</a> to Tentatively Ready. +</li> <li>R42: 2006-04-21 post-Berlin mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#572">572</a>. @@ -326,7 +336,7 @@ from:</p> use extern "C++" linkage for this purpose.</p> </blockquote> <hr> -<a name="3"><h3>3. Atexit registration during atexit() call is not described</h3></a><p><b>Section:</b> 18.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.start.term"> [lib.support.start.term]</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> 12 Dec 1997</p> +<a name="3"><h3>3. Atexit registration during atexit() call is not described</h3></a><p><b>Section:</b> 18.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.cstdint"> [lib.cstdint]</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> 12 Dec 1997</p> <p>We appear not to have covered all the possibilities of exit processing with respect to atexit registration. <br> @@ -610,7 +620,7 @@ paragraph 2: </p> </blockquote> <hr> -<a name="9"><h3>9. Operator new(0) calls should not yield the same pointer</h3></a><p><b>Section:</b> 18.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete"> [lib.new.delete]</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> 4 Jan 1998</p> +<a name="9"><h3>9. Operator new(0) calls should not yield the same pointer</h3></a><p><b>Section:</b> 18.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete"> [lib.new.delete]</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> 4 Jan 1998</p> <p>Scott Meyers, in a comp.std.c++ posting: I just noticed that section 3.7.3.1 of CD2 seems to allow for the possibility that all calls to operator new(0) yield the same pointer, an implementation @@ -650,12 +660,12 @@ list maintainer's note: the IS is the same.]</p> pointer to any other object.]</p> </blockquote> <p>Retain the first sentence, and delete the remainder.</p> -<p>18.4.1 currently has no text. Add the following:</p> +<p>18.5.1 currently has no text. Add the following:</p> <blockquote> <p>Except where otherwise specified, the provisions of 3.7.3 apply to the library versions of operator new and operator delete.</p> </blockquote> -<p>To 18.4.1.3, add the following text:</p> +<p>To 18.5.1.3, add the following text:</p> <blockquote> <p>The provisions of 3.7.3 do not apply to these reserved placement forms of operator new and operator delete.</p> @@ -744,7 +754,7 @@ constructor, but there is no matching constructor. </p> "<tt>locale(name().c_str())</tt>". </p> <hr> -<a name="16"><h3>16. Bad ctype_byname<char> decl</h3></a><p><b>Section:</b> 22.2.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.byname.special"> [lib.locale.ctype.byname.special]</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="16"><h3>16. Bad ctype_byname<char> decl</h3></a><p><b>Section:</b> 22.2.1.4 <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#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> <p>The new virtual members ctype_byname<char>::do_widen and do_narrow did not get edited in properly. Instead, the member do_widen appears four times, with wrong argument lists. </p> @@ -842,7 +852,7 @@ virtual is listed everywhere appropriate. </p> another get member for bool&, copied from the entry in 22.2.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.num.get"> [lib.locale.num.get]</a>.</p> <hr> -<a name="19"><h3>19. "Noconv" definition too vague</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#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> +<a name="19"><h3>19. "Noconv" definition too vague</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.byname"> [lib.locale.codecvt.byname]</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 definitions of codecvt<>::do_out and do_in, they are specified to return noconv if "no conversion is @@ -852,7 +862,7 @@ normatively what is done with the buffers. <p><b>Proposed resolution:</b></p> <p> Change the entry for noconv in the table under paragraph 4 in section -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> to read: +<font color="red">22.2.1.5.2</font> to read: </p> <blockquote> <p><tt>noconv</tt>: <tt>internT</tt> and <tt>externT</tt> are the same type, @@ -916,14 +926,14 @@ one case. The resolution of this issue clarifies what the LWG believes to have been the original intent.</p> <hr> -<a name="24"><h3>24. "do_convert" doesn't exist</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#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> +<a name="24"><h3>24. "do_convert" doesn't exist</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.byname"> [lib.locale.codecvt.byname]</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 codecvt<>::do_out and do_in mentions a symbol "do_convert" which is not defined in the standard. This is a leftover from an edit, and should be "do_in and do_out". </p> <p><b>Proposed resolution:</b></p> -<p>In 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>, paragraph 3, change -"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 +<p>In 22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a>, paragraph 3, change +"do_convert" to "do_in or do_out". Also, in <font color="red">22.2.1.5.2</font>, 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> @@ -1101,7 +1111,7 @@ Specifically, the latter says it calls pbackfail if: </p> <p>Note deliberate reordering of arguments for clarity in addition to the correction of the argument value.</p> <hr> -<a name="33"><h3>33. Codecvt<> mentions from_type</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#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> +<a name="33"><h3>33. Codecvt<> mentions from_type</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.byname"> [lib.locale.codecvt.byname]</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 table defining the results from do_out and do_in, the specification for the result <i>error</i> says </p> @@ -1112,7 +1122,7 @@ result <i>error</i> says </p> <p>but from_type is not defined. This clearly is intended to be an externT for do_in, or an internT for do_out. </p> <p><b>Proposed resolution:</b></p> -<p>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> paragraph 4, replace the definition +<p>In <font color="red">22.2.1.5.2</font> paragraph 4, replace the definition in the table for the case of _error_ with </p> <blockquote> @@ -1655,7 +1665,7 @@ base class, exception, with exception(msg). Class exception (see <p>EFFECTS: Constructs an object of class <tt>failure</tt>.</p> </blockquote> <hr> -<a name="49"><h3>49. Underspecification of ios_base::sync_with_stdio</h3></a><p><b>Section:</b> 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> <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> 21 Jun 1998</p> +<a name="49"></a><h3><a name="49">49. Underspecification of ios_base::sync_with_stdio</a></h3><p><b>Section:</b> 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> <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> 21 Jun 1998</p> <p>Two problems</p> <p>(1) 27.4.2.4 doesn't say what ios_base::sync_with_stdio(f) @@ -2405,7 +2415,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"><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.container.adaptors"> [lib.container.adaptors]</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 @@ -2413,7 +2423,7 @@ whether a vector iterator is required to be a pointer; the answer to that question is clearly "no," as it would rule out debugging implementations)</p> <p><b>Proposed resolution:</b></p> -<p>Add the following text to the end of 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>, +<p>Add the following text to the end of 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.adaptors"> [lib.container.adaptors]</a>, paragraph 1. </p> <blockquote> @@ -2430,7 +2440,7 @@ directly defined in the standard. Discussion included:</p> <ul> <li>An operational definition similar to the above proposed resolution is - already used for valarray (26.3.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.access"> [lib.valarray.access]</a>).</li> + already used for valarray (<font color="red">26.3.2.3</font>).</li> <li>There is no need to explicitly consider a user-defined operator& because elements must be copyconstructible (23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> para 3) and copyconstructible (20.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.copyconstructible"> [lib.copyconstructible]</a>) specifies @@ -2438,7 +2448,7 @@ directly defined in the standard. Discussion included:</p> <li>There is no issue of one-past-the-end because of language rules.</li> </ul> <hr> -<a name="70"><h3>70. Uncaught_exception() missing throw() specification</h3></a><p><b>Section:</b> 18.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.exception"> [lib.support.exception]</a>, 18.6.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.uncaught"> [lib.uncaught]</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> Unknown</p> +<a name="70"><h3>70. Uncaught_exception() missing throw() specification</h3></a><p><b>Section:</b> 18.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.exception"> [lib.support.exception]</a>, 18.7.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.uncaught"> [lib.uncaught]</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> Unknown</p> <p>In article 3E04@pratique.fr, Valentin Bonnard writes: </p> <p>uncaught_exception() doesn't have a throw specification.</p> @@ -2449,7 +2459,7 @@ handle exceptions thrown from uncaught_exception() ?</p> <p>uncaught_exception() is called in exception handling contexts where exception safety is very important.</p> <p><b>Proposed resolution:</b></p> -<p>In 15.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/except.html#except.uncaught"> [except.uncaught]</a>, paragraph 1, 18.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.exception"> [lib.support.exception]</a>, and 18.6.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.uncaught"> [lib.uncaught]</a>, add "throw()" to uncaught_exception().</p> +<p>In 15.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/except.html#except.uncaught"> [except.uncaught]</a>, paragraph 1, 18.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.exception"> [lib.support.exception]</a>, and 18.7.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.uncaught"> [lib.uncaught]</a>, add "throw()" to uncaught_exception().</p> <hr> <a name="71"><h3>71. Do_get_monthname synopsis missing argument</h3></a><p><b>Section:</b> 22.2.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.get"> [lib.locale.time.get]</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> 13 Aug 1998</p> <p>The locale facet member <tt>time_get<>::do_get_monthname</tt> @@ -2466,12 +2476,12 @@ the declaration of member do_monthname as follows:</p> ios_base::iostate& err, tm* t) const;</pre> <hr> <a name="74"><h3>74. Garbled text for <tt>codecvt::do_max_length</tt> -</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#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 8 Sep 1998</p> +</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.byname"> [lib.locale.codecvt.byname]</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> 8 Sep 1998</p> <p>The text of <tt>codecvt::do_max_length</tt>'s "Returns" clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced parentheses and a spurious <b>n</b>.</p> <p><b>Proposed resolution:</b></p> -<p>Replace 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> paragraph 11 with the +<p>Replace <font color="red">22.2.1.5.2</font> paragraph 11 with the following:</p> <blockquote> @@ -2482,7 +2492,7 @@ following:</p> mbstate_t>::do_max_length()</tt> returns 1. </blockquote> <hr> -<a name="75"><h3>75. Contradiction in <tt>codecvt::length</tt>'s argument types</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#TC">TC</a> <b>Submitter:</b> Matt +<a name="75"><h3>75. Contradiction in <tt>codecvt::length</tt>'s argument types</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.byname"> [lib.locale.codecvt.byname]</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> 18 Sep 1998</p> <p>The class synopses for classes <tt>codecvt<></tt> (22.2.1.5) and <tt>codecvt_byname<></tt> (22.2.1.6) say that the first @@ -2496,7 +2506,7 @@ synopsis or the summary must be changed. </p> then we must also add text saying how <tt>do_length</tt> changes its <tt>stateT</tt> argument. </p> <p><b>Proposed resolution:</b></p> -<p>In 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>, and also in 22.2.1.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a>, +<p>In 22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a>, and also in <font color="red">22.2.1.6</font>, change the <tt>stateT</tt> argument type on both member <tt>length()</tt> and member <tt>do_length()</tt> from </p> @@ -2510,7 +2520,7 @@ change the <tt>stateT</tt> argument type on both member <p><tt>stateT&</tt></p> </blockquote> -<p>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>, add to the definition for member +<p>In <font color="red">22.2.1.5.2</font>, add to the definition for member <tt>do_length</tt> a paragraph:</p> <blockquote> @@ -2520,7 +2530,7 @@ change the <tt>stateT</tt> argument type on both member <tt>max</tt> elements.</p> </blockquote> <hr> -<a name="76"><h3>76. Can a <tt>codecvt</tt> facet always convert one internal character at a time?</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#WP">WP</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 25 Sep 1998</p> +<a name="76"><h3>76. Can a <tt>codecvt</tt> facet always convert one internal character at a time?</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.byname"> [lib.locale.codecvt.byname]</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> 25 Sep 1998</p> <p>This issue concerns the requirements on classes derived from <tt>codecvt</tt>, including user-defined classes. What are the restrictions on the conversion from external characters @@ -2555,7 +2565,7 @@ sequence of <i>M</i> external characters that maps to a sequence of subsequence that maps to <i>N-1</i> internal characters.) </p> <p>Some of the wording in the standard, such as the description of -<tt>codecvt::do_max_length</tt> (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>, +<tt>codecvt::do_max_length</tt> (<font color="red">22.2.1.5.2</font>, paragraph 11) and <tt>basic_filebuf::underflow</tt> (27.8.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 3) suggests that it must always be possible to pick off internal characters one at a time from a sequence of external characters. However, this is never explicitly stated one @@ -2569,7 +2579,7 @@ be aware of the assumptions that the library makes. This issue affects positioning operations on <tt>basic_filebuf</tt>, unbuffered input, and several of <tt>codecvt</tt>'s member functions. </p> <p><b>Proposed resolution:</b></p> -<p>Add the following text as a new paragraph, following 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> paragraph 2:</p> +<p>Add the following text as a new paragraph, following <font color="red">22.2.1.5.2</font> paragraph 2:</p> <blockquote> <p>A <tt>codecvt</tt> facet that is used by <tt>basic_filebuf</tt> @@ -2634,22 +2644,22 @@ return value.]</i></p> <p>In the 27.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> synopsis change "event_call_back" to "event_callback". </p> <hr> -<a name="79"><h3>79. Inconsistent declaration of polar()</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.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</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>In 26.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a> polar is declared as follows:</p> +<a name="79"><h3>79. Inconsistent declaration of polar()</h3></a><p><b>Section:</b> 26.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, 26.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</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>In 26.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a> polar is declared as follows:</p> <pre> template<class T> complex<T> polar(const T&, const T&); </pre> -<p>In 26.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a> it is declared as follows:</p> +<p>In 26.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a> it is declared as follows:</p> <pre> template<class T> complex<T> polar(const T& rho, const T& theta = 0); </pre> <p>Thus whether the second parameter is optional is not clear. </p> <p><b>Proposed resolution:</b></p> -<p>In 26.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a> change:</p> +<p>In 26.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a> change:</p> <pre> template<class T> complex<T> polar(const T&, const T&);</pre> <p>to:</p> <pre> template<class T> complex<T> polar(const T& rho, const T& theta = 0); </pre> <hr> -<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> +<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.cfenv.syn"> [lib.cfenv.syn]</a>, 26.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.fenv"> [lib.fenv]</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> @@ -3015,7 +3025,7 @@ conversion from <tt>iterator</tt> to <tt>const_iterator</tt>. <p><i>[Tokyo: The LWG crafted the proposed resolution and rationale.]</i></p> <hr> -<a name="106"><h3>106. Numeric library private members are implementation defined</h3></a><p><b>Section:</b> 26.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p> +<a name="106"><h3>106. Numeric library private members are implementation defined</h3></a><p><b>Section:</b> 26.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.member.ops"> [lib.complex.member.ops]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p> <p>This is the only place in the whole standard where the implementation has to document something private.</p> <p><b>Proposed resolution:</b></p> @@ -3024,23 +3034,23 @@ Remove the comment which says "// remainder implementation defined" from: </p> <ul> - <li>26.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> + <li>26.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.member.ops"> [lib.complex.member.ops]</a> </li> - <li>26.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a> + <li>26.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a> </li> - <li>26.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a> + <li>26.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.transcendentals"> [lib.complex.transcendentals]</a> </li> - <li>26.3.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a> + <li>26.3.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.cmplx.over"> [lib.cmplx.over]</a> </li> </ul> <hr> -<a name="108"><h3>108. Lifetime of exception::what() return unspecified</h3></a><p><b>Section:</b> 18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.exception"> [lib.exception]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p> +<a name="108"><h3>108. Lifetime of exception::what() return unspecified</h3></a><p><b>Section:</b> 18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.type.info"> [lib.type.info]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p> <p>In 18.6.1, paragraphs 8-9, the lifetime of the return value of exception::what() is left unspecified. This issue has implications with exception safety of exception handling: some exceptions should not throw bad_alloc.</p> <p><b>Proposed resolution:</b></p> -<p>Add to 18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.exception"> [lib.exception]</a> paragraph 9 (exception::what notes +<p>Add to 18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.type.info"> [lib.type.info]</a> paragraph 9 (exception::what notes clause) the sentence:</p> <blockquote> @@ -3053,7 +3063,7 @@ to set internal state that should affect the contents of the string returned by <tt>what()</tt>. </p> <hr> -<a name="109"><h3>109. Missing binders for non-const sequence elements</h3></a><p><b>Section:</b> 20.3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.binders"> [lib.binders]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Bjarne Stroustrup <b>Date:</b> 7 Oct 1998</p> +<a name="109"><h3>109. Missing binders for non-const sequence elements</h3></a><p><b>Section:</b> 20.5.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.arithmetic.operations"> [lib.arithmetic.operations]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Bjarne Stroustrup <b>Date:</b> 7 Oct 1998</p> <p>There are no versions of binders that apply to non-const elements of a sequence. This makes examples like for_each() using bind2nd() on @@ -3128,7 +3138,7 @@ public: <p><b>Howard believes there is a flaw</b> in this resolution. See c++std-lib-9127. We may need to reopen this issue.</p> -<p>In 20.3.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.binder.1st"> [lib.binder.1st]</a> in the declaration of binder1st after:</p> +<p>In <font color="red">20.5.6.1</font> in the declaration of binder1st after:</p> <blockquote> <p><tt>typename Operation::result_type<br> operator()(const typename Operation::second_argument_type& x) const;</tt></p> @@ -3138,7 +3148,7 @@ See c++std-lib-9127. We may need to reopen this issue.</p> <p><tt>typename Operation::result_type<br> operator()(typename Operation::second_argument_type& x) const;</tt></p> </blockquote> -<p>In 20.3.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.binder.2nd"> [lib.binder.2nd]</a> in the declaration of binder2nd after:</p> +<p>In <font color="red">20.5.6.3</font> in the declaration of binder2nd after:</p> <blockquote> <p><tt>typename Operation::result_type<br> operator()(const typename Operation::first_argument_type& x) const;</tt></p> @@ -3195,8 +3205,8 @@ 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> -<p>Section 18.4.1.3 contains the following example: </p> +<a name="114"><h3>114. Placement forms example in error twice</h3></a><p><b>Section:</b> 18.5.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.5.1.3 contains the following example: </p> <pre>[Example: This can be useful for constructing an object at a known address: char place[sizeof(Something)]; @@ -3213,7 +3223,7 @@ believes the () are correct.]</p> likely to fail.</p> <p><b>Proposed resolution:</b></p> <p>Replace the <u> first line of code</u> in the example in -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> with: +18.5.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> with: </p> <blockquote> @@ -3560,21 +3570,21 @@ sentences). </p> <p>The <tt>streambuf</tt> synopsis already has a declaration for the typedefs and that is sufficient. </p> <hr> -<a name="123"><h3>123. Should valarray helper arrays fill functions be const?</h3></a><p><b>Section:</b> 26.3.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a>, 26.3.7.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.gslice.array.fill"> [lib.gslice.array.fill]</a>, 26.3.8.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.mask.array.fill"> [lib.mask.array.fill]</a>, 26.3.9.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.indirect.array.fill"> [lib.indirect.array.fill]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998 </p> +<a name="123"><h3>123. Should valarray helper arrays fill functions be const?</h3></a><p><b>Section:</b> 26.5.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a>, 26.5.7.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.gslice.array.fill"> [lib.gslice.array.fill]</a>, 26.5.8.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.mask.array.fill"> [lib.mask.array.fill]</a>, 26.5.9.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.indirect.array.fill"> [lib.indirect.array.fill]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998 </p> <p>One of the operator= in the valarray helper arrays is const and one is not. For example, look at slice_array. This operator= in Section -26.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a> is const: </p> +26.5.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a> is const: </p> <p> <tt>void operator=(const valarray<T>&) const;</tt> </p> -<p>but this one in Section 26.3.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a> is not: </p> +<p>but this one in Section 26.5.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a> is not: </p> <p> <tt>void operator=(const T&); </tt></p> <p>The description of the semantics for these two functions is similar. </p> <p><b>Proposed resolution:</b></p> -<p>26.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> Template class slice_array</p> +<p>26.5.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> Template class slice_array</p> <blockquote> <p>In the class template definition for slice_array, replace the member @@ -3586,7 +3596,7 @@ is not. For example, look at slice_array. This operator= in Section </pre> </blockquote> -<p>26.3.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a> slice_array fill function</p> +<p>26.5.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a> slice_array fill function</p> <blockquote> <p>Change the function declaration</p> @@ -3597,7 +3607,7 @@ is not. For example, look at slice_array. This operator= in Section </pre> </blockquote> -<p>26.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a> Template class gslice_array</p> +<p>26.5.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a> Template class gslice_array</p> <blockquote> <p>In the class template definition for gslice_array, replace the member @@ -3609,7 +3619,7 @@ is not. For example, look at slice_array. This operator= in Section </pre> </blockquote> -<p>26.3.7.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.gslice.array.fill"> [lib.gslice.array.fill]</a> gslice_array fill function</p> +<p>26.5.7.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.gslice.array.fill"> [lib.gslice.array.fill]</a> gslice_array fill function</p> <blockquote> <p>Change the function declaration</p> @@ -3620,7 +3630,7 @@ is not. For example, look at slice_array. This operator= in Section </pre> </blockquote> -<p>26.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a> Template class mask_array</p> +<p>26.5.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a> Template class mask_array</p> <blockquote> <p>In the class template definition for mask_array, replace the member @@ -3632,7 +3642,7 @@ is not. For example, look at slice_array. This operator= in Section </pre> </blockquote> -<p>26.3.8.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.mask.array.fill"> [lib.mask.array.fill]</a> mask_array fill function</p> +<p>26.5.8.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.mask.array.fill"> [lib.mask.array.fill]</a> mask_array fill function</p> <blockquote> <p>Change the function declaration</p> @@ -3643,7 +3653,7 @@ is not. For example, look at slice_array. This operator= in Section </pre> </blockquote> -<p>26.3.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a> Template class indirect_array</p> +<p>26.5.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a> Template class indirect_array</p> <blockquote> <p>In the class template definition for indirect_array, replace the member @@ -3655,7 +3665,7 @@ is not. For example, look at slice_array. This operator= in Section </pre> </blockquote> -<p>26.3.9.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.indirect.array.fill"> [lib.indirect.array.fill]</a> indirect_array fill function</p> +<p>26.5.9.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.indirect.array.fill"> [lib.indirect.array.fill]</a> indirect_array fill function</p> <blockquote> <p>Change the function declaration</p> @@ -3684,12 +3694,12 @@ to return a const char* not a const charT*. </p> <tt>do_scan_not()</tt> to return a <tt> const charT*</tt>. </p> <hr> -<a name="125"><h3>125. valarray<T>::operator!() return type is inconsistent</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#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p> -<p>In Section 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> valarray<T>::operator!() is -declared to return a valarray<T>, but in Section 26.3.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.unary"> [lib.valarray.unary]</a> it is declared to return a valarray<bool>. The +<a name="125"><h3>125. valarray<T>::operator!() return type is inconsistent</h3></a><p><b>Section:</b> 26.3.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> Judy Ward <b>Date:</b> 15 Dec 1998</p> +<p>In Section 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex"> [lib.complex]</a> valarray<T>::operator!() is +declared to return a valarray<T>, but in Section <font color="red">26.3.2.5</font> it is declared to return a valarray<bool>. The latter appears to be correct. </p> <p><b>Proposed resolution:</b></p> -<p>Change in Section 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> the declaration of +<p>Change in Section 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex"> [lib.complex]</a> the declaration of <tt>operator!()</tt> so that the return type is <tt>valarray<bool></tt>. </p> <hr> @@ -3712,7 +3722,7 @@ latter appears to be correct. </p> <pre> (is(M,c) || !ctc.is(M, do_narrow(c,dfault)) )</pre> <hr> -<a name="127"><h3>127. auto_ptr<> conversion issues</h3></a><p><b>Section:</b> 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Greg Colvin <b>Date:</b> 17 Feb 1999</p> +<a name="127"><h3>127. auto_ptr<> conversion issues</h3></a><p><b>Section:</b> 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.unary"> [lib.meta.unary]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Greg Colvin <b>Date:</b> 17 Feb 1999</p> <p>There are two problems with the current <tt>auto_ptr</tt> wording in the standard: </p> @@ -3749,23 +3759,23 @@ object parameter may be bound to an rvalue [13.3.3.1.4/3] <p>Tokyo: The LWG removed the following from the proposed resolution:</p> - <p>In 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>, paragraph 2, and 20.4.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.auto.ptr.conv"> [lib.auto.ptr.conv]</a>, + <p>In 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.unary"> [lib.meta.unary]</a>, paragraph 2, and 20.4.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.unary.prop"> [lib.meta.unary.prop]</a>, paragraph 2, make the conversion to auto_ptr_ref const:</p> <blockquote> <pre>template<class Y> operator auto_ptr_ref<Y>() const throw();</pre> </blockquote> <p><b>Proposed resolution:</b></p> -<p>In 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>, paragraph 2, move +<p>In 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.unary"> [lib.meta.unary]</a>, paragraph 2, move the <tt>auto_ptr_ref</tt> definition to namespace scope.</p> -<p>In 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>, paragraph 2, add +<p>In 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.unary"> [lib.meta.unary]</a>, paragraph 2, add a public assignment operator to the <tt>auto_ptr</tt> definition: </p> <blockquote> <pre>auto_ptr& operator=(auto_ptr_ref<X> r) throw();</pre> </blockquote> -<p>Also add the assignment operator to 20.4.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.auto.ptr.conv"> [lib.auto.ptr.conv]</a>: </p> +<p>Also add the assignment operator to 20.4.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.unary.prop"> [lib.meta.unary.prop]</a>: </p> <blockquote> <pre>auto_ptr& operator=(auto_ptr_ref<X> r) throw()</pre> @@ -3858,7 +3868,7 @@ Matt provided wording.]</i></p> ]</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> +<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.deque.capacity"> [lib.deque.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> <p>-1- Effects:</p> @@ -3897,14 +3907,14 @@ after operator= in the map declaration:</p> <pre> allocator_type get_allocator() const;</pre> <hr> -<a name="134"><h3>134. vector constructors over specified</h3></a><p><b>Section:</b> 23.2.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.cons"> [lib.vector.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> Howard Hinnant <b>Date:</b> 6 Mar 1999</p> +<a name="134"><h3>134. vector constructors over specified</h3></a><p><b>Section:</b> 23.2.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.queue"> [lib.queue]</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 complexity description says: "It does at most 2N calls to the copy constructor of T and logN reallocations if they are just input iterators ...".</p> <p>This appears to be overly restrictive, dictating the precise memory/performance tradeoff for the implementor.</p> <p><b>Proposed resolution:</b></p> -<p>Change 23.2.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.cons"> [lib.vector.cons]</a>, paragraph 1 to:</p> +<p>Change 23.2.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.queue"> [lib.queue]</a>, paragraph 1 to:</p> <p>-1- Complexity: The constructor template <class InputIterator> vector(InputIterator first, InputIterator last) @@ -3980,7 +3990,7 @@ This requirement is a bit weird. There's no similar requirement for basic_streambuf<>::seekpos, or for basic_filebuf<>::seekoff or basic_filebuf<>::seekpos.]</i></p> <hr> -<a name="137"><h3>137. Do use_facet and has_facet look in the global locale?</h3></a><p><b>Section:</b> 22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 17 Mar 1999</p> +<a name="137"></a><h3><a name="137">137. Do use_facet and has_facet look in the global locale?</a></h3><p><b>Section:</b> 22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 17 Mar 1999</p> <p>Section 22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a> says:</p> <p>-4- In the call to use_facet<Facet>(loc), the type argument @@ -4050,7 +4060,7 @@ proposed resolution.]</i></p> <tt><br> </tt>— <tt>xpos <= pos</tt> and <tt>xpos < size();</tt></p> <hr> -<a name="142"><h3>142. lexicographical_compare complexity wrong</h3></a><p><b>Section:</b> 25.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.lex.comparison"> [lib.alg.lex.comparison]</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> 20 Jun 1999</p> +<a name="142"></a><h3><a name="142">142. lexicographical_compare complexity wrong</a></h3><p><b>Section:</b> 25.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.lex.comparison"> [lib.alg.lex.comparison]</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> 20 Jun 1999</p> <p>The lexicographical_compare complexity is specified as:<br> <br> "At most min((last1 - first1), (last2 - first2)) @@ -4083,7 +4093,7 @@ right! (and Matt states this complexity in his book)</p> --end example] </blockquote> <hr> -<a name="144"><h3>144. Deque constructor complexity wrong </h3></a><p><b>Section:</b> 23.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.cons"> [lib.deque.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> Herb Sutter <b>Date:</b> 9 May 1999</p> +<a name="144"><h3>144. Deque constructor complexity wrong </h3></a><p><b>Section:</b> 23.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.array.cons"> [lib.array.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> Herb Sutter <b>Date:</b> 9 May 1999</p> <p>In 23.2.1.1 paragraph 6, the deque ctor that takes an iterator range appears to have complexity requirements which are incorrect, and which contradict the complexity requirements for insert(). I suspect that the text in question, @@ -4114,7 +4124,7 @@ typo):</p> <p>Complexity: Makes last - first calls to the copy constructor of T.</p> </blockquote> <hr> -<a name="146"><h3>146. complex<T> Inserter and Extractor need sentries</h3></a><p><b>Section:</b> 26.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.ops"> [lib.complex.ops]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 12 May 1999</p> +<a name="146"><h3>146. complex<T> Inserter and Extractor need sentries</h3></a><p><b>Section:</b> 26.3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.ops"> [lib.complex.ops]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 12 May 1999</p> <p>The <u> extractor</u> for complex numbers is specified as: </p> <blockquote> @@ -4171,7 +4181,7 @@ consistency with the other inserters and extractors in the library. Regarding the issue of padding in the inserter, I don't know what the intent was. </p> <p><b>Proposed resolution:</b></p> -<p>After 26.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.ops"> [lib.complex.ops]</a> paragraph 14 (operator>>), add a +<p>After 26.3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.ops"> [lib.complex.ops]</a> paragraph 14 (operator>>), add a Notes clause:</p> <blockquote> @@ -4188,7 +4198,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> @@ -4706,8 +4716,8 @@ paragraph 14 from:</p> <p><i>[Kona: Dietmar is working on a proposed resolution.]</i></p> <p><i>[Post-Tokyo: Dietmar supplied the above wording.]</i></p> <hr> -<a name="172"><h3>172. Inconsistent types for <tt>basic_istream::ignore()</tt> -</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#TC">TC</a> <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 23 Jul 1999</p> +<a name="172"></a><h3><a name="172">172. Inconsistent types for <tt>basic_istream::ignore()</tt> +</a></h3><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#TC">TC</a> <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 23 Jul 1999</p> <p>In 27.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream"> [lib.istream]</a> the function <tt>ignore()</tt> gets an object of type <tt>streamsize</tt> as first argument. However, in 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> @@ -5239,7 +5249,7 @@ error. The full text was supplied by Bill Plauger; it was cross checked against changes supplied by Andy Sawyer. It should be further checked by the LWG.]</i></p> <hr> -<a name="184"><h3>184. numeric_limits<bool> wording problems</h3></a><p><b>Section:</b> 18.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.numeric.special"> [lib.numeric.special]</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> 21 Jul 1999</p> +<a name="184"></a><h3><a name="184">184. numeric_limits<bool> wording problems</a></h3><p><b>Section:</b> 18.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.numeric.special"> [lib.numeric.special]</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> 21 Jul 1999</p> <p>bools are defined by the standard to be of integer types, as per 3.9.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/basic.html#basic.fundamental"> [basic.fundamental]</a> paragraph 7. However "integer types" seems to have a special meaning for the author of 18.2. The net effect @@ -5331,8 +5341,8 @@ resolution.]</i></p> <p><i>[Post-Tokyo: At the request of the LWG in Tokyo, Nico Josuttis provided the above wording.]</i></p> <hr> -<a name="185"><h3>185. Questionable use of term "inline"</h3></a><p><b>Section:</b> 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> UK Panel <b>Date:</b> 26 Jul 1999</p> -<p>Paragraph 4 of 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> says:</p> +<a name="185"><h3>185. Questionable use of term "inline"</h3></a><p><b>Section:</b> 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.tuple"> [lib.tuple]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> UK Panel <b>Date:</b> 26 Jul 1999</p> +<p>Paragraph 4 of 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.tuple"> [lib.tuple]</a> says:</p> <blockquote> <p> [Example: To negate every element of a: transform(a.begin(), a.end(), a.begin(), negate<double>()); The corresponding functions will inline @@ -5357,17 +5367,17 @@ any "inlining" will take place in this case.</p> <p>Thus the example "mandates" behavior that is explicitly not required elsewhere.</p> <p><b>Proposed resolution:</b></p> -<p>In 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> paragraph 1, remove the sentence:</p> +<p>In 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.tuple"> [lib.tuple]</a> paragraph 1, remove the sentence:</p> <blockquote> <p>They are important for the effective use of the library.</p> </blockquote> -<p>Remove 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> paragraph 2, which reads:</p> +<p>Remove 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.tuple"> [lib.tuple]</a> paragraph 2, which reads:</p> <blockquote> <p> Using function objects together with function templates increases the expressive power of the library as well as making the resulting code much more efficient.</p> </blockquote> -<p>In 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> paragraph 4, remove the sentence:</p> +<p>In 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.tuple"> [lib.tuple]</a> paragraph 4, remove the sentence:</p> <blockquote> <p>The corresponding functions will inline the addition and the negation.</p> @@ -5376,7 +5386,7 @@ not required elsewhere.</p> <p><i>[Kona: The LWG agreed there was a defect.]</i></p> <p><i>[Tokyo: The LWG crafted the proposed resolution.]</i></p> <hr> -<a name="186"></a><h3><a name="186">186. bitset::set() second parameter should be bool</a></h3><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#WP">WP</a> <b>Submitter:</b> Darin Adler <b>Date:</b> 13 Aug 1999</p> +<a name="186"><h3>186. bitset::set() second parameter should be bool</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#WP">WP</a> <b>Submitter:</b> Darin Adler <b>Date:</b> 13 Aug 1999</p> <p>In section 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>, paragraph 13 defines the bitset::set operation to take a second parameter of type int. The function tests whether this value is non-zero to determine whether to @@ -5609,14 +5619,14 @@ elements of containers.</p> <p>The standard itself assumes that pointers and references obtained from an iterator are still valid after iterator destruction or -change. The definition of reverse_iterator::operator*(), 24.4.1.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.op.star"> [lib.reverse.iter.op.star]</a>, which returns a reference, defines +change. The definition of reverse_iterator::operator*(), 24.4.1.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.conv"> [lib.reverse.iter.conv]</a>, which returns a reference, defines effects:</p> <blockquote> <pre>Iterator tmp = current; return *--tmp;</pre> </blockquote> -<p>The definition of reverse_iterator::operator->(), 24.4.1.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.opref"> [lib.reverse.iter.opref]</a>, which returns a pointer, defines effects:</p> +<p>The definition of reverse_iterator::operator->(), 24.4.1.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.op.star"> [lib.reverse.iter.op.star]</a>, which returns a pointer, defines effects:</p> <blockquote> <pre>return &(operator*());</pre> </blockquote> @@ -5633,7 +5643,7 @@ Destruction of an iterator may invalidate pointers and references previously obtained from that iterator. </blockquote> -<p>Replace paragraph 1 of 24.4.1.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.op.star"> [lib.reverse.iter.op.star]</a> with:</p> +<p>Replace paragraph 1 of 24.4.1.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.conv"> [lib.reverse.iter.conv]</a> with:</p> <blockquote> <p><b>Effects:</b></p> @@ -5685,7 +5695,7 @@ Clause 23 should be reviewed to make sure that guarantees for predefined iterators are as strong as users expect.</p> <hr> -<a name="199"><h3>199. What does <tt>allocate(0)</tt> return?</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#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 19 Nov 1999</p> +<a name="199"><h3>199. What does <tt>allocate(0)</tt> return?</h3></a><p><b>Section:</b> 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.default.con.req"> [lib.default.con.req]</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> 19 Nov 1999</p> <p> Suppose that <tt>A</tt> is a class that conforms to the Allocator requirements of Table 32, and <tt>a</tt> is an @@ -6469,7 +6479,7 @@ resolution is the one proposed by Howard.]</i></p> (such as iter_swap, swap_ranges, reverse, rotate, and sort) conform to that concept. The Swappable concept will make it clear that these algorithms use unqualified lookup for the calls - to <tt>swap</tt>. Also, in 26.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.transcend"> [lib.valarray.transcend]</a> paragraph 1, + to <tt>swap</tt>. Also, in <font color="red">26.3.3.3</font> paragraph 1, state that the valarray transcendentals use unqualified lookup.</p> <hr> <a name="227"><h3>227. std::swap() should require CopyConstructible or DefaultConstructible arguments</h3></a><p><b>Section:</b> 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#TC">TC</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 09 Apr 2000</p> @@ -6514,8 +6524,8 @@ resolution is the one proposed by Howard.]</i></p> </blockquote> <hr> <a name="228"><h3>228. Incorrect specification of "..._byname" facets</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> Dietmar Kühl <b>Date:</b> 20 Apr 2000</p> -<p>The sections 22.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a>, 22.2.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.byname.special"> [lib.locale.ctype.byname.special]</a>, -22.2.1.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a>, 22.2.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.numpunct.byname"> [lib.locale.numpunct.byname]</a>, 22.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.collate.byname"> [lib.locale.collate.byname]</a>, 22.2.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.put.byname"> [lib.locale.time.put.byname]</a>, 22.2.6.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.moneypunct.byname"> [lib.locale.moneypunct.byname]</a>, and 22.2.7.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.messages.byname"> [lib.locale.messages.byname]</a> overspecify the +<p>The sections 22.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a>, 22.2.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a>, +<font color="red">22.2.1.6</font>, 22.2.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.numpunct.byname"> [lib.locale.numpunct.byname]</a>, 22.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.collate.byname"> [lib.locale.collate.byname]</a>, 22.2.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.put.byname"> [lib.locale.time.put.byname]</a>, 22.2.6.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.moneypunct.byname"> [lib.locale.moneypunct.byname]</a>, and 22.2.7.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.messages.byname"> [lib.locale.messages.byname]</a> overspecify the definitions of the "..._byname" classes by listing a bunch of virtual functions. At the same time, no semantics of these functions are defined. Real implementations do not define these @@ -6634,7 +6644,7 @@ specialization it is not virtual.</p> ~messages_byname(); // virtual }; }</pre> -<p>Remove section 22.2.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.byname.special"> [lib.locale.ctype.byname.special]</a> completely (because in +<p>Remove section 22.2.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a> completely (because in this case only those members are defined to be virtual which are defined to be virtual in 'ctype<cT>'.)</p> @@ -6705,7 +6715,7 @@ determine if the same defect existed elsewhere.</p> <p>There are a number of places (see proposed resolution below) where Assignable is specified without also specifying CopyConstructible. There are also several cases where both are -specified. For example, 26.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.accumulate"> [lib.accumulate]</a>.</p> +specified. For example, 26.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.rand.req"> [lib.rand.req]</a>.</p> <p><b>Proposed resolution:</b></p> <p>In 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 for value_type: change "T is Assignable" to "T is CopyConstructible and @@ -6856,7 +6866,7 @@ implementor?</p> <p><i>[post-Toronto: Judy provided the above proposed resolution and rationale.]</i></p> <hr> -<a name="234"><h3>234. Typos in allocator definition</h3></a><p><b>Section:</b> 20.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.members"> [lib.allocator.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> Dietmar Kühl <b>Date:</b> 24 Apr 2000</p> +<a name="234"><h3>234. Typos in allocator definition</h3></a><p><b>Section:</b> 20.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.members"> [lib.allocator.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> Dietmar Kühl <b>Date:</b> 24 Apr 2000</p> <p>In paragraphs 12 and 13 the effects of <tt>construct()</tt> and <tt>destruct()</tt> are described as returns but the functions actually return <tt>void</tt>.</p> @@ -6881,7 +6891,7 @@ should do.</p> <p><i>[pre-Copenhagen: Dietmar provide wording for proposed resolution.]</i></p> <hr> -<a name="237"><h3>237. Undefined expression in complexity specification</h3></a><p><b>Section:</b> 23.2.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.cons"> [lib.list.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> Dietmar Kühl <b>Date:</b> 24 Apr 2000</p> +<a name="237"><h3>237. Undefined expression in complexity specification</h3></a><p><b>Section:</b> 23.2.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.cons"> [lib.deque.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> Dietmar Kühl <b>Date:</b> 24 Apr 2000</p> <p>The complexity specification in paragraph 6 says that the complexity is linear in <tt>first - last</tt>. Even if <tt>operator-()</tt> is defined on iterators this term is in general undefined because it @@ -7008,7 +7018,7 @@ the value type is CopyConstructible and Assignable.</p> specify any additional requirements that they impose on any of the types used by the algorithm. An example of an algorithm that creates temporary copies and correctly specifies the additional requirements -is accumulate(), 26.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.accumulate"> [lib.accumulate]</a>.</p> +is accumulate(), 26.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.rand.req"> [lib.rand.req]</a>.</p> <p>Since the specifications of unique() and unique_copy() do not require CopyConstructible and Assignable of the InputIterator's value @@ -7051,7 +7061,7 @@ minor as not to require re-review. ]</i></p> <hr> -<a name="242"><h3>242. Side effects of function objects</h3></a><p><b>Section:</b> 25.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.transform"> [lib.alg.transform]</a>, 26.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numeric.ops"> [lib.numeric.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> Angelika Langer <b>Date:</b> May 15 2000</p> +<a name="242"><h3>242. Side effects of function objects</h3></a><p><b>Section:</b> 25.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.transform"> [lib.alg.transform]</a>, 26.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.rand"> [lib.rand]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> May 15 2000</p> <p>The algorithms transform(), accumulate(), inner_product(), partial_sum(), and adjacent_difference() require that the function object supplied to them shall not have any side effects.</p> @@ -7276,7 +7286,7 @@ had language that made this an unambiguous requirement; those words were moved to a place where their context made them less clear. See Jerry Schwarz's message c++std-lib-7618.</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#WP">WP</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.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> 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> @@ -7298,7 +7308,7 @@ the end of a <tt>vector</tt> in constant time.</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>, +complexity of inserting multiple elements (23.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.array.size"> [lib.array.size]</a>, paragraph 3):</p> <blockquote> @@ -7322,7 +7332,7 @@ paragraph 3):</p> 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> +<p>Change 23.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.array.size"> [lib.array.size]</a>, paragraph 3, to:</p> <blockquote> Complexity: The complexity is linear in the number of elements @@ -7357,7 +7367,7 @@ member functions, the member sets ios_base::eofbit in err. because it was more consistent with the way eof is described for other input facets.</p> <hr> -<a name="250"><h3>250. splicing invalidates iterators</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#WP">WP</a> <b>Submitter:</b> Brian Parker <b>Date:</b> 14 Jul 2000</p> +<a name="250"><h3>250. splicing invalidates iterators</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.deque.special"> [lib.deque.special]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Brian Parker <b>Date:</b> 14 Jul 2000</p> <p> Section 23.2.2.4 [lib.list.ops] states that </p> @@ -7374,14 +7384,14 @@ after <tt>splice</tt>. </p> <p><b>Proposed resolution:</b></p> -<p>Add a footnote to 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>, paragraph 1:</p> +<p>Add a footnote to 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.special"> [lib.deque.special]</a>, paragraph 1:</p> <blockquote> -[<i>Footnote:</i> As specified in 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>, paragraphs +[<i>Footnote:</i> As specified in 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.default.con.req"> [lib.default.con.req]</a>, paragraphs 4-5, the semantics described in this clause applies only to the case where allocators compare equal. --end footnote] </blockquote> -<p>In 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>, replace paragraph 4 with:</p> +<p>In 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.special"> [lib.deque.special]</a>, replace paragraph 4 with:</p> <blockquote> Effects: Inserts the contents of x before position and x becomes empty. Pointers and references to the moved elements of x now refer to @@ -7390,7 +7400,7 @@ moved elements will continue to refer to their elements, but they now behave as iterators into *this, not into x. </blockquote> -<p>In 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>, replace paragraph 7 with:</p> +<p>In 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.special"> [lib.deque.special]</a>, replace paragraph 7 with:</p> <blockquote> Effects: Inserts an element pointed to by i from list x before position and removes the element from x. The result is unchanged if @@ -7400,7 +7410,7 @@ to refer to this same element but as a member of *this. Iterators to *i behave as iterators into *this, not into x. </blockquote> -<p>In 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>, replace paragraph 12 with:</p> +<p>In 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.special"> [lib.deque.special]</a>, replace paragraph 12 with:</p> <blockquote> Requires: [first, last) is a valid range in x. The result is undefined if position is an iterator in the range [first, last). @@ -7415,7 +7425,7 @@ 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.default.con.req"> [lib.default.con.req]</a> paragraph 4, the behavior of list when allocators compare nonequal is outside the scope of the standard.</p> <hr> <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> @@ -7467,7 +7477,7 @@ issue is stylistic rather than a matter of correctness.</p> <p>with</p> <pre> -2- Returns: const_cast<strstreambuf*>(&sb).</pre> <hr> -<a name="253"><h3>253. valarray helper functions are almost entirely useless</h3></a><p><b>Section:</b> 26.3.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.cons"> [lib.valarray.cons]</a>, 26.3.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.assign"> [lib.valarray.assign]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Robert Klarer <b>Date:</b> 31 Jul 2000</p> +<a name="253"><h3>253. valarray helper functions are almost entirely useless</h3></a><p><b>Section:</b> 26.5.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.cons"> [lib.valarray.cons]</a>, 26.5.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.assign"> [lib.valarray.assign]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Robert Klarer <b>Date:</b> 31 Jul 2000</p> <p>This discussion is adapted from message c++std-lib-7056 posted November 11, 1999. I don't think that anyone can reasonably claim that the problem described below is NAD.</p> @@ -7542,66 +7552,66 @@ classes are almost entirely useless.</p> <p>slice_array:</p> <ul> <li> Make the copy constructor and copy-assignment operator declarations - public in the slice_array class template definition in 26.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> </li> -<li> remove paragraph 3 of 26.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> + public in the slice_array class template definition in 26.5.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> </li> +<li> remove paragraph 3 of 26.5.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> </li> -<li> remove the copy constructor declaration from 26.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.cons.slice.arr"> [lib.cons.slice.arr]</a> +<li> remove the copy constructor declaration from 26.5.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.cons.slice.arr"> [lib.cons.slice.arr]</a> </li> -<li> change paragraph 1 of 26.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.cons.slice.arr"> [lib.cons.slice.arr]</a> to read "This constructor is declared +<li> change paragraph 1 of 26.5.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.cons.slice.arr"> [lib.cons.slice.arr]</a> to read "This constructor is declared to be private. This constructor need not be defined."</li> -<li> remove the first sentence of paragraph 1 of 26.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a> +<li> remove the first sentence of paragraph 1 of 26.5.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a> </li> <li> Change the first three words of the second sentence of paragraph 1 of - 26.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a> to "These assignment operators have"</li> + 26.5.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a> to "These assignment operators have"</li> </ul> <p>gslice_array:</p> <ul> <li> Make the copy constructor and copy-assignment operator declarations - public in the gslice_array class template definition in 26.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a> </li> -<li> remove the note in paragraph 3 of 26.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a> + public in the gslice_array class template definition in 26.5.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a> </li> +<li> remove the note in paragraph 3 of 26.5.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a> </li> -<li> remove the copy constructor declaration from 26.3.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.gslice.array.cons"> [lib.gslice.array.cons]</a> +<li> remove the copy constructor declaration from 26.5.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.gslice.array.cons"> [lib.gslice.array.cons]</a> </li> -<li> change paragraph 1 of 26.3.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.gslice.array.cons"> [lib.gslice.array.cons]</a> to read "This constructor is declared +<li> change paragraph 1 of 26.5.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.gslice.array.cons"> [lib.gslice.array.cons]</a> to read "This constructor is declared to be private. This constructor need not be defined."</li> -<li> remove the first sentence of paragraph 1 of 26.3.7.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.gslice.array.assign"> [lib.gslice.array.assign]</a> +<li> remove the first sentence of paragraph 1 of 26.5.7.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.gslice.array.assign"> [lib.gslice.array.assign]</a> </li> <li> Change the first three words of the second sentence of paragraph 1 of - 26.3.7.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.gslice.array.assign"> [lib.gslice.array.assign]</a> to "These assignment operators have"</li> + 26.5.7.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.gslice.array.assign"> [lib.gslice.array.assign]</a> to "These assignment operators have"</li> </ul> <p>mask_array:</p> <ul> <li> Make the copy constructor and copy-assignment operator declarations - public in the mask_array class template definition in 26.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a> </li> -<li> remove the note in paragraph 2 of 26.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a> + public in the mask_array class template definition in 26.5.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a> </li> +<li> remove the note in paragraph 2 of 26.5.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a> </li> -<li> remove the copy constructor declaration from 26.3.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.mask.array.cons"> [lib.mask.array.cons]</a> +<li> remove the copy constructor declaration from 26.5.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.mask.array.cons"> [lib.mask.array.cons]</a> </li> -<li> change paragraph 1 of 26.3.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.mask.array.cons"> [lib.mask.array.cons]</a> to read "This constructor is declared +<li> change paragraph 1 of 26.5.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.mask.array.cons"> [lib.mask.array.cons]</a> to read "This constructor is declared to be private. This constructor need not be defined."</li> -<li> remove the first sentence of paragraph 1 of 26.3.8.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.mask.array.assign"> [lib.mask.array.assign]</a> +<li> remove the first sentence of paragraph 1 of 26.5.8.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.mask.array.assign"> [lib.mask.array.assign]</a> </li> <li> Change the first three words of the second sentence of paragraph 1 of - 26.3.8.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.mask.array.assign"> [lib.mask.array.assign]</a> to "These assignment operators have"</li> + 26.5.8.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.mask.array.assign"> [lib.mask.array.assign]</a> to "These assignment operators have"</li> </ul> <p>indirect_array:</p> <ul> <li>Make the copy constructor and copy-assignment operator declarations - public in the indirect_array class definition in 26.3.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a> + public in the indirect_array class definition in 26.5.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a> </li> -<li> remove the note in paragraph 2 of 26.3.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a> +<li> remove the note in paragraph 2 of 26.5.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a> </li> -<li> remove the copy constructor declaration from 26.3.9.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.indirect.array.cons"> [lib.indirect.array.cons]</a> +<li> remove the copy constructor declaration from 26.5.9.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.indirect.array.cons"> [lib.indirect.array.cons]</a> </li> -<li> change the descriptive text in 26.3.9.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.indirect.array.cons"> [lib.indirect.array.cons]</a> to read "This constructor is +<li> change the descriptive text in 26.5.9.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.indirect.array.cons"> [lib.indirect.array.cons]</a> to read "This constructor is declared to be private. This constructor need not be defined."</li> -<li> remove the first sentence of paragraph 1 of 26.3.9.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.indirect.array.assign"> [lib.indirect.array.assign]</a> +<li> remove the first sentence of paragraph 1 of 26.5.9.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.indirect.array.assign"> [lib.indirect.array.assign]</a> </li> <li> Change the first three words of the second sentence of paragraph 1 of - 26.3.9.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.indirect.array.assign"> [lib.indirect.array.assign]</a> to "These assignment operators have"</li> + 26.5.9.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.indirect.array.assign"> [lib.indirect.array.assign]</a> to "These assignment operators have"</li> </ul> <p><i>[Proposed resolution was modified in Santa Cruz: explicitly make copy constructor and copy assignment operators public, instead of @@ -7870,7 +7880,7 @@ default constructor was written the obvious way. This has been clarified by core issue 178, and there is no longer any doubt that the straightforward implementation is correct.</p> <hr> -<a name="266"><h3>266. bad_exception::~bad_exception() missing Effects clause</h3></a><p><b>Section:</b> 18.6.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.bad.exception"> [lib.bad.exception]</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> 24 Sep 2000</p> +<a name="266"><h3>266. bad_exception::~bad_exception() missing Effects clause</h3></a><p><b>Section:</b> 18.7.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.bad.exception"> [lib.bad.exception]</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> 24 Sep 2000</p> <p> The synopsis for std::bad_exception lists the function ~bad_exception() but there is no description of what the function does (the Effects @@ -7879,10 +7889,10 @@ clause is missing). <p><b>Proposed resolution:</b></p> <p> Remove the destructor from the class synopses of -<tt>bad_alloc</tt> (18.4.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.bad.alloc"> [lib.bad.alloc]</a>), -<tt>bad_cast</tt> (18.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.bad.cast"> [lib.bad.cast]</a>), -<tt>bad_typeid</tt> (18.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.bad.typeid"> [lib.bad.typeid]</a>), -and <tt>bad_exception</tt> (18.6.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.bad.exception"> [lib.bad.exception]</a>). +<tt>bad_alloc</tt> (<font color="red">18.4.2.1</font>), +<tt>bad_cast</tt> (18.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.alloc.errors"> [lib.alloc.errors]</a>), +<tt>bad_typeid</tt> (<font color="red">18.5.3</font>), +and <tt>bad_exception</tt> (18.7.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.bad.exception"> [lib.bad.exception]</a>). </p> <p><b>Rationale:</b></p> <p> @@ -8208,7 +8218,7 @@ class (14.6.2 [temp.dep]) and thus not visible.</p> <p>Qualify the names with the name of the class of which they are members, i.e., ios_base.</p> <hr> -<a name="274"><h3>274. a missing/impossible 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#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 02 Nov 2000</p> +<a name="274"><h3>274. a missing/impossible 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.default.con.req"> [lib.default.con.req]</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> 02 Nov 2000</p> <p> I see that table 31 in 20.1.5, p3 allows T in std::allocator<T> to be of any type. But the synopsis in 20.4.1 calls for allocator<>::address() to @@ -8453,7 +8463,7 @@ implement <tt>vector::push_back</tt> in terms of <tt>vector::insert</tt>.</p> <hr> -<a name="278"><h3>278. What does iterator validity mean?</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#WP">WP</a> <b>Submitter:</b> P.J. Plauger <b>Date:</b> 27 Nov 2000</p> +<a name="278"><h3>278. What does iterator validity mean?</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.deque.special"> [lib.deque.special]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> P.J. Plauger <b>Date:</b> 27 Nov 2000</p> <p> Section 23.2.2.4 [lib.list.ops] states that </p> @@ -8784,8 +8794,8 @@ imposing a greater restriction that what the standard currently says (which is convertible to bool). </p> <hr> -<a name="284"><h3>284. unportable example in 20.3.7, p6</h3></a><p><b>Section:</b> 20.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.pointer.adaptors"> [lib.function.pointer.adaptors]</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> 26 Dec 2000</p> -<p>The example in 20.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.pointer.adaptors"> [lib.function.pointer.adaptors]</a>, p6 shows how to use the C +<a name="284"><h3>284. unportable example in 20.3.7, p6</h3></a><p><b>Section:</b> 20.5.7 <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#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 26 Dec 2000</p> +<p>The example in 20.5.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.comparisons"> [lib.comparisons]</a>, p6 shows how to use the C library function <tt>strcmp()</tt> with the function pointer adapter <tt>ptr_fun()</tt>. But since it's unspecified whether the C library functions have <tt>extern "C"</tt> or <tt>extern @@ -8795,7 +8805,7 @@ function pointers with different the language linkage specifications well-formed is unspecified. </p> <p><b>Proposed resolution:</b></p> -<p>Change 20.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.pointer.adaptors"> [lib.function.pointer.adaptors]</a> paragraph 6 from:</p> +<p>Change 20.5.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.comparisons"> [lib.comparisons]</a> paragraph 6 from:</p> <blockquote> <p>[<i>Example:</i></p> <pre> replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++"); @@ -9057,7 +9067,7 @@ it isn't stringent enough.</p> <p><i>[Lillehammer: Beman provided new wording]</i></p> <hr> -<a name="295"><h3>295. Is abs defined in <cmath>?</h3></a><p><b>Section:</b> 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.c.math"> [lib.c.math]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Jens Maurer <b>Date:</b> 12 Jan 2001</p> +<a name="295"><h3>295. Is abs defined in <cmath>?</h3></a><p><b>Section:</b> 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numarray"> [lib.numarray]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Jens Maurer <b>Date:</b> 12 Jan 2001</p> <p> Table 80 lists the contents of the <cmath> header. It does not list <tt>abs()</tt>. However, 26.5, paragraph 6, which lists added @@ -9067,7 +9077,7 @@ of <tt>abs()</tt> should be defined in <cmath>. <p><b>Proposed resolution:</b></p> <p> Add <tt>abs</tt> to Table 80. Also, remove the parenthetical list -of functions "(abs(), div(), rand(), srand())" from 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.c.math"> [lib.c.math]</a>, +of functions "(abs(), div(), rand(), srand())" from 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numarray"> [lib.numarray]</a>, paragraph 1. </p> @@ -9080,10 +9090,10 @@ separate question is whether we're doing the right thing in putting some overloads in <cmath> that we aren't also putting in <cstdlib>. That's issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.</p> <hr> -<a name="297"><h3>297. const_mem_fun_t<>::argument_type should be const T*</h3></a><p><b>Section:</b> 20.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.member.pointer.adaptors"> [lib.member.pointer.adaptors]</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> 6 Jan 2001</p> -<p>The class templates <tt>const_mem_fun_t</tt> in 20.3.8, p8 and +<a name="297"><h3>297. const_mem_fun_t<>::argument_type should be const T*</h3></a><p><b>Section:</b> 20.5.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.logical.operations"> [lib.logical.operations]</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> 6 Jan 2001</p> +<p>The class templates <tt>const_mem_fun_t</tt> in 20.5.8, p8 and <tt>const_mem_fun1_t</tt> -in 20.3.8, p9 derive from <tt>unary_function<T*, S></tt>, and +in 20.5.8, p9 derive from <tt>unary_function<T*, S></tt>, and <tt>binary_function<T*, A, S></tt>, respectively. Consequently, their <tt>argument_type</tt>, and <tt>first_argument_type</tt> @@ -9124,7 +9134,7 @@ function </p> <p><b>Proposed resolution:</b></p> <p>Replace the top portion of the definition of the class template -const_mem_fun_t in 20.3.8, p8 +const_mem_fun_t in 20.5.8, p8 </p> <p><tt>template <class S, class T> class const_mem_fun_t</tt> <br><tt> : public @@ -9136,7 +9146,7 @@ unary_function<T*, S> {</tt> unary_function<<b>const</b> T*, S> {</tt> </p> <p>Also replace the top portion of the definition of the class template -const_mem_fun1_t in 20.3.8, p9</p> +const_mem_fun1_t in 20.5.8, p9</p> <p><tt>template <class S, class T, class A> class const_mem_fun1_t</tt> <br><tt> : public binary_function<T*, A, S> {</tt> @@ -9150,19 +9160,19 @@ binary_function<<b>const</b> T*, A, S> {</tt> <p>This is simply a contradiction: the <tt>argument_type</tt> typedef, and the argument type itself, are not the same.</p> <hr> -<a name="298"><h3>298. ::operator delete[] requirement incorrect/insufficient</h3></a><p><b>Section:</b> 18.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> John A. Pedretti <b>Date:</b> 10 Jan 2001</p> +<a name="298"><h3>298. ::operator delete[] requirement incorrect/insufficient</h3></a><p><b>Section:</b> 18.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> John A. Pedretti <b>Date:</b> 10 Jan 2001</p> <p> -The default behavior of <tt>operator delete[]</tt> described in 18.4.1.2, p12 - +The default behavior of <tt>operator delete[]</tt> described in 18.5.1.2, p12 - namely that for non-null value of <i>ptr</i>, the operator reclaims storage allocated by the earlier call to the default <tt>operator new[]</tt> - is not correct in all cases. Since the specified <tt>operator new[]</tt> default -behavior is to call <tt>operator new</tt> (18.4.1.2, p4, p8), which can be +behavior is to call <tt>operator new</tt> (18.5.1.2, p4, p8), which can be replaced, along with <tt>operator delete</tt>, by the user, to implement their own memory management, the specified default behavior of<tt> operator delete[]</tt> must be to call <tt>operator delete</tt>. </p> <p><b>Proposed resolution:</b></p> -<p>Change 18.4.1.2, p12 from</p> +<p>Change 18.5.1.2, p12 from</p> <blockquote> <b>-12-</b> <b>Default behavior:</b> <ul> @@ -9190,7 +9200,7 @@ or <tt>operator delete(<i>ptr</i>, std::nothrow)</tt> respectively. </blockquote> <p>and expunge paragraph 13.</p> <hr> -<a name="300"><h3>300. list::merge() specification incomplete</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#WP">WP</a> <b>Submitter:</b> John Pedretti <b>Date:</b> 23 Jan 2001</p> +<a name="300"><h3>300. list::merge() specification incomplete</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.deque.special"> [lib.deque.special]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> John Pedretti <b>Date:</b> 23 Jan 2001</p> <p> The "Effects" clause for list::merge() (23.2.2.4, p23) appears to be incomplete: it doesn't cover the case where the argument @@ -9199,7 +9209,7 @@ note in p24 (below) is that x be empty after the merge which is surely unintended in this case. </p> <p><b>Proposed resolution:</b></p> -<p>In 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>, replace paragraps 23-25 with:</p> +<p>In 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.special"> [lib.deque.special]</a>, replace paragraps 23-25 with:</p> <blockquote> <p> 23 Effects: if (&x == this) does nothing; otherwise, merges the two @@ -9228,7 +9238,7 @@ effects. </blockquote> <p><i>[Copenhagen: The original proposed resolution did not fix all of -the problems in 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>, p22-25. Three different +the problems in 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.special"> [lib.deque.special]</a>, p22-25. Three different paragraphs (23, 24, 25) describe the effects of <tt>merge</tt>. Changing p23, without changing the other two, appears to introduce contradictions. Additionally, "merges the argument list into the @@ -9369,7 +9379,7 @@ input. Using <tt>widen</tt> does mean that alternative digit representations will not be recognized, but this was a known consequence of the design choice.</p> <hr> -<a name="305"><h3>305. Default behavior of codecvt<wchar_t, char, mbstate_t>::length()</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#WP">WP</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 24 Jan 2001</p> +<a name="305"><h3>305. Default behavior of codecvt<wchar_t, char, mbstate_t>::length()</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.byname"> [lib.locale.codecvt.byname]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 24 Jan 2001</p> <p>22.2.1.5/3 introduces codecvt in part with:</p> <blockquote> @@ -9507,13 +9517,13 @@ members thought that diagnostics should be required whenever possible.]</i></p> <hr> -<a name="307"><h3>307. Lack of reference typedefs in container adaptors</h3></a><p><b>Section:</b> 23.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.adaptors"> [lib.container.adaptors]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 13 Mar 2001</p> +<a name="307"><h3>307. Lack of reference typedefs in container adaptors</h3></a><p><b>Section:</b> 23.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list"> [lib.list]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 13 Mar 2001</p> <p>From reflector message c++std-lib-8330. See also lib-8317.</p> <p> -The standard is currently inconsistent in 23.2.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.priority.queue"> [lib.priority.queue]</a> -paragraph 1 and 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a> paragraph 1. +The standard is currently inconsistent in 23.2.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.capacity"> [lib.list.capacity]</a> +paragraph 1 and 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.modifiers"> [lib.list.modifiers]</a> paragraph 1. 23.2.3.3/1, for example, says: </p> @@ -9907,14 +9917,14 @@ comment in c++std-lib-8939. <a name="312"><h3>312. Table 27 is missing headers</h3></a><p><b>Section:</b> 20 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.utilities"> [lib.utilities]</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> 29 Mar 2001</p> <p>Table 27 in section 20 lists the header <memory> (only) for Memory (lib.memory) but neglects to mention the headers -<cstdlib> and <cstring> that are discussed in 20.4.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.c.malloc"> [lib.c.malloc]</a>.</p> +<cstdlib> and <cstring> that are discussed in 20.4.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.rel"> [lib.meta.rel]</a>.</p> <p><b>Proposed resolution:</b></p> <p>Add <cstdlib> and <cstring> to Table 27, in the same row as <memory>.</p> <hr> -<a name="315"><h3>315. Bad "range" in list::unique complexity</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#WP">WP</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 1 May 2001</p> +<a name="315"><h3>315. Bad "range" in list::unique complexity</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.deque.special"> [lib.deque.special]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 1 May 2001</p> <p> -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>, Para 21 describes the complexity of +23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.special"> [lib.deque.special]</a>, Para 21 describes the complexity of list::unique as: "If the range (last - first) is not empty, exactly (last - first) -1 applications of the corresponding predicate, otherwise no applications of the predicate)". @@ -10015,7 +10025,7 @@ template at all, but simply provide the primary template.</p> <p>Remove the comment from the text in 22.2.3.2 and from the proposed resolution of library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>.</p> <hr> -<a name="319"><h3>319. Storage allocation wording confuses "Required behavior", "Requires"</h3></a><p><b>Section:</b> 18.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a>, 18.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 15 May 2001</p> +<a name="319"><h3>319. Storage allocation wording confuses "Required behavior", "Requires"</h3></a><p><b>Section:</b> 18.5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a>, 18.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 15 May 2001</p> <p>The standard specifies 17.3.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> that "Required behavior" elements describe "the semantics of a function definition provided by either the implementation or a C++ program."</p> @@ -10029,7 +10039,7 @@ should be specified as "Requires".</p> <p><b>Proposed resolution:</b></p> -<p>In 18.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a> Para 12 Change:</p> +<p>In 18.5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a> Para 12 Change:</p> <blockquote> <p>Required behavior: accept a value of ptr that is null or that was returned by an earlier call ...</p> @@ -10040,7 +10050,7 @@ should be specified as "Requires".</p> earlier call ...</p> </blockquote> -<p>In 18.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a> Para 11 Change:</p> +<p>In 18.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a> Para 11 Change:</p> <blockquote> <p>Required behavior: accept a value of ptr that is null or that was returned by an earlier call ...</p> @@ -10052,7 +10062,7 @@ should be specified as "Requires".</p> </blockquote> <hr> -<a name="320"><h3>320. list::assign overspecified</h3></a><p><b>Section:</b> 23.2.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.cons"> [lib.list.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> Howard Hinnant <b>Date:</b> 17 May 2001</p> +<a name="320"><h3>320. list::assign overspecified</h3></a><p><b>Section:</b> 23.2.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.cons"> [lib.deque.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> Howard Hinnant <b>Date:</b> 17 May 2001</p> <p> Section 23.2.2.1, paragraphs 6-8 specify that list assign (both forms) have the "effects" of a call to erase followed by a call to insert. @@ -10387,11 +10397,11 @@ modifier.</p> <p><b>Rationale:</b></p> <p>Fixes an obvious typo</p> <hr> -<a name="329"><h3>329. vector capacity, reserve and reallocation</h3></a><p><b>Section:</b> 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a>, 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> Anthony Williams <b>Date:</b> 13 Jul 2001</p> +<a name="329"><h3>329. vector capacity, reserve and reallocation</h3></a><p><b>Section:</b> 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.priority.queue"> [lib.priority.queue]</a>, 23.2.4.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> Anthony Williams <b>Date:</b> 13 Jul 2001</p> <p> There is an apparent contradiction about which circumstances can cause -a reallocation of a vector in Section 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a> and -section 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>. +a reallocation of a vector in Section 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.priority.queue"> [lib.priority.queue]</a> and +section 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a>. </p> <p>23.2.4.2p5 says:</p> @@ -10443,7 +10453,7 @@ than the old capacity, I think the intent is clear. </p> <p><b>Proposed resolution:</b></p> -<p>Change the wording of 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a> paragraph 5 to:</p> +<p>Change the wording of 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.priority.queue"> [lib.priority.queue]</a> paragraph 5 to:</p> <blockquote> Notes: Reallocation invalidates all the references, pointers, and @@ -10484,7 +10494,7 @@ and the following declaration of ~failure() in ios_base::failure }; } </pre> -<p>the class failure cannot be implemented since in 18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.exception"> [lib.exception]</a> the destructor of class exception has an empty +<p>the class failure cannot be implemented since in 18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.type.info"> [lib.type.info]</a> the destructor of class exception has an empty exception specification:</p> <pre> namespace std { class exception { @@ -10904,7 +10914,7 @@ required to contain an infinite number of facets.</p> OutputIterator must be supported. Table 51 already contains a complete list of the ones we need.</p> <hr> -<a name="341"><h3>341. Vector reallocation and swap</h3></a><p><b>Section:</b> 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Anthony Williams <b>Date:</b> 27 Sep 2001</p> +<a name="341"><h3>341. Vector reallocation and swap</h3></a><p><b>Section:</b> 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.priority.queue"> [lib.priority.queue]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Anthony Williams <b>Date:</b> 27 Sep 2001</p> <p>It is a common idiom to reduce the capacity of a vector by swapping it with an empty one:</p> <pre> std::vector<SomeType> vec; @@ -10913,7 +10923,7 @@ an empty one:</p> // vec is now empty, with minimal capacity </pre> -<p>However, the wording of 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a>paragraph 5 prevents +<p>However, the wording of 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.priority.queue"> [lib.priority.queue]</a>paragraph 5 prevents the capacity of a vector being reduced, following a call to reserve(). This invalidates the idiom, as swap() is thus prevented from reducing the capacity. The proposed wording for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#329">329</a> does not affect this. Consequently, the example above @@ -10944,7 +10954,7 @@ pointing to the same element. Consequently iterators and references that referred to one vector now refer to the other, and vice-versa.</li> </ol> <p><b>Proposed resolution:</b></p> -<p>Add a new paragraph after 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a> paragraph 5:</p> +<p>Add a new paragraph after 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.priority.queue"> [lib.priority.queue]</a> paragraph 5:</p> <blockquote> <pre> void swap(vector<T,Allocator>& x); </pre> @@ -11450,9 +11460,9 @@ prevents locale from being implemented efficiently. <p>This change is reasonable becuase it clarifies the intent of this part of the standard.</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#WP">WP</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> D.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.lib.binders"> [depr.lib.binders]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</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 definition of bind1st() (<font color="red">20.5.6.2</font>) can result in the construction of an unsafe binding between incompatible pointer types. For example, given a function whose first parameter type is 'pointer to T', it's possible without error to bind an argument of @@ -11485,15 +11495,15 @@ semantically equivalent to an explicit cast expression (5.4 <a href="http://www. as a reinterpret_cast, thus masking the error. </p> -<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>The problem and proposed change also apply to <font color="red">20.5.6.4</font>.</p> <p><b>Proposed resolution:</b></p> -<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: +<p>Add this sentence to the end of 20.5.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.arithmetic.operations"> [lib.arithmetic.operations]</a>/1: "Binders <tt>bind1st</tt> and <tt>bind2nd</tt> are deprecated in favor of <tt>std::tr1::bind</tt>."</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> + 20.5.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> @@ -11709,7 +11719,7 @@ with the following signature:</p> <p><b>Rationale:</b></p> <p>Fixes an obvious typo.</p> <hr> -<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#WP">WP</a> <b>Submitter:</b> Frank Compagner <b>Date:</b> 20 Jul 2002</p> +<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#WP">WP</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], @@ -11790,7 +11800,7 @@ wording.]</i></p> <p> In 27.6.1.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a> and 27.6.2.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a> (exception()&badbit) != 0 is used in testing for rethrow, yet -exception() is the constructor to class std::exception in 18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.exception"> [lib.exception]</a> that has no return type. Should member function +exception() is the constructor to class std::exception in 18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.type.info"> [lib.type.info]</a> that has no return type. Should member function exceptions() found in 27.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios"> [lib.ios]</a> be used instead? </p> @@ -11893,9 +11903,9 @@ following text: <p><b>Rationale:</b></p> <p>The LWG believes this is just a typo, and that this is the correct fix.</p> <hr> -<a name="380"><h3>380. typos in codecvt tables 53 and 54</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#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 6 Sep 2002</p> +<a name="380"><h3>380. typos in codecvt tables 53 and 54</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.byname"> [lib.locale.codecvt.byname]</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> 6 Sep 2002</p> <p> -Tables 53 and 54 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> are both titled "convert +Tables 53 and 54 in 22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a> are both titled "convert result values," when surely "do_in/do_out result values" must have been intended for Table 53 and "do_unshift result values" for Table 54. @@ -11920,7 +11930,7 @@ heading Meaning, to "space for more than (to_limit - to) destination elements was needed to terminate a sequence given the value of state." </p> <hr> -<a name="381"><h3>381. detection of invalid mbstate_t in codecvt</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#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 6 Sep 2002</p> +<a name="381"><h3>381. detection of invalid mbstate_t in codecvt</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.byname"> [lib.locale.codecvt.byname]</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> 6 Sep 2002</p> <p> All but one codecvt member functions that take a state_type argument list as one of their preconditions that the state_type argument have @@ -12085,8 +12095,8 @@ to <tt>2*log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p> Ê 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="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> +<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.op-="> [lib.reverse.iter.op-=]</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.op-="> [lib.reverse.iter.op-=]</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> @@ -12136,7 +12146,7 @@ Comments from Dave Abrahams: IMO we should resolve 386 by just saying 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> +<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.complex"> [lib.complex]</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> #include <ostream> @@ -12176,8 +12186,8 @@ integration within programs written in C++. There is no reason why subscripting an expression of type valarray<T> that is const-qualified should not return a const T&.</p> <p><b>Proposed resolution:</b></p> -<p>In the class synopsis in 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a>, and in -26.3.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.access"> [lib.valarray.access]</a> just above paragraph 1, change</p> +<p>In the class synopsis in 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex"> [lib.complex]</a>, and in +<font color="red">26.3.2.3</font> just above paragraph 1, change</p> <pre> T operator[](size_t const); </pre> <p>to</p> @@ -12206,9 +12216,9 @@ const in the header file synopsis in section 22.1 <a href="http://www.open-std.o <p><b>Rationale:</b></p> <p>Fixes an obvious typo</p> <hr> -<a name="395"><h3>395. inconsistencies in the definitions of rand() and random_shuffle()</h3></a><p><b>Section:</b> 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.c.math"> [lib.c.math]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> James Kanze <b>Date:</b> 3 Jan 2003</p> +<a name="395"><h3>395. inconsistencies in the definitions of rand() and random_shuffle()</h3></a><p><b>Section:</b> 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numarray"> [lib.numarray]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> James Kanze <b>Date:</b> 3 Jan 2003</p> <p> -In 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.c.math"> [lib.c.math]</a>, the C++ standard refers to the C standard for the +In 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numarray"> [lib.numarray]</a>, the C++ standard refers to the C standard for the definition of rand(); in the C standard, it is written that "The implementation shall behave as if no library function calls the rand function." @@ -12246,9 +12256,9 @@ implementation is permitted to use <tt>rand</tt>.] problem if the number of elements in the sequence is greater than RAND_MAX.</p> <hr> -<a name="400"><h3>400. redundant type cast in lib.allocator.members</h3></a><p><b>Section:</b> 20.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.members"> [lib.allocator.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> Markus Mauhart <b>Date:</b> 27 Feb 2003</p> +<a name="400"><h3>400. redundant type cast in lib.allocator.members</h3></a><p><b>Section:</b> 20.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.members"> [lib.allocator.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> Markus Mauhart <b>Date:</b> 27 Feb 2003</p> <p> -20.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a> allocator members, contains +20.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a> allocator members, contains the following 3 lines: </p> @@ -12268,16 +12278,16 @@ Replace "((T*) p)" with "p". <p><b>Rationale:</b></p> <p>Just a typo, this is really editorial.</p> <hr> -<a name="402"><h3>402. wrong new expression in [some_]allocator::construct</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>, 20.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.members"> [lib.allocator.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> Markus Mauhart <b>Date:</b> 27 Feb 2003</p> +<a name="402"><h3>402. wrong new expression in [some_]allocator::construct</h3></a><p><b>Section:</b> 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.default.con.req"> [lib.default.con.req]</a>, 20.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.members"> [lib.allocator.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> Markus Mauhart <b>Date:</b> 27 Feb 2003</p> <p> This applies to the new expression that is contained in both par12 of -20.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a> and in par2 (table 32) of 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>. +20.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a> and in par2 (table 32) of 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.default.con.req"> [lib.default.con.req]</a>. I think this new expression is wrong, involving unintended side effects. </p> -<p>20.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a> contains the following 3 lines:</p> +<p>20.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a> contains the following 3 lines:</p> <pre> 11 Returns: the largest value N for which the call allocate(N,0) might succeed. void construct(pointer p, const_reference val); @@ -12285,7 +12295,7 @@ effects. </pre> -<p>20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> in table 32 has the following line:</p> +<p>20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.default.con.req"> [lib.default.con.req]</a> in table 32 has the following line:</p> <pre> a.construct(p,t) Effect: new((void*)p) T(t) </pre> @@ -12376,7 +12386,7 @@ In 21.3.5.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.htm Throws: Shall not throw exceptions. </p> <hr> -<a name="404"><h3>404. May a replacement allocation function be declared inline?</h3></a><p><b>Section:</b> 17.4.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a>, 18.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete"> [lib.new.delete]</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> 24 Apr 2003</p> +<a name="404"></a><h3><a name="404">404. May a replacement allocation function be declared inline?</a></h3><p><b>Section:</b> 17.4.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a>, 18.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete"> [lib.new.delete]</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> 24 Apr 2003</p> <p> The eight basic dynamic memory allocation functions (single-object and array versions of ::operator new and ::operator delete, in the @@ -12387,12 +12397,12 @@ in preference to the implementation's definition. <p> Three different parts of the standard mention requirements on -replacement functions: 17.4.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a>, 18.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a> -and 18.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a>, and 3.7.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/basic.html#basic.stc.dynamic"> [basic.stc.dynamic]</a>. +replacement functions: 17.4.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a>, 18.5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a> +and 18.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a>, and 3.7.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/basic.html#basic.stc.dynamic"> [basic.stc.dynamic]</a>. </p> <p>None of these three places say whether a replacement function may - be declared inline. 18.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a> paragraph 2 specifies a + be declared inline. 18.5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a> paragraph 2 specifies a signature for the replacement function, but that's not enough: the <tt>inline</tt> specifier is not part of a function's signature. One might also reason from 7.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/dcl.html#dcl.fct.spec"> [dcl.fct.spec]</a> paragraph 2, which @@ -12438,7 +12448,7 @@ 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> +<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.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> 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 @@ -12449,7 +12459,7 @@ 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> +<p>Replace 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</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 @@ -12552,16 +12562,16 @@ flags.]</i></p> of the three fstream class template instead.]</i></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#WP">WP</a> <b>Submitter:</b> Hans Bos <b>Date:</b> 7 Jun 2003</p> +<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.list.cons"> [lib.list.cons]</a>, 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.modifiers"> [lib.list.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> 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 +Sections 23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.cons"> [lib.list.cons]</a> and 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.modifiers"> [lib.list.modifiers]</a> list comparison operators (==, !=, <, <=, >, =>) for queue and -stack. Only the semantics for queue::operator== (23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.queue"> [lib.queue]</a> par2) and queue::operator< (23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.queue"> [lib.queue]</a> +stack. Only the semantics for queue::operator== (23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.cons"> [lib.list.cons]</a> par2) and queue::operator< (23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.cons"> [lib.list.cons]</a> par3) are defined. </p> <p><b>Proposed resolution:</b></p> -<p>Add the following new paragraphs after 23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.queue"> [lib.queue]</a> +<p>Add the following new paragraphs after 23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.cons"> [lib.list.cons]</a> paragraph 3:</p> <blockquote> @@ -12584,7 +12594,7 @@ par3) are defined. </blockquote> -<p>Add the following paragraphs at the end of 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a>:</p> +<p>Add the following paragraphs at the end of 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.modifiers"> [lib.list.modifiers]</a>:</p> <blockquote> @@ -12704,7 +12714,7 @@ 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> +<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.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> Matt Austern <b>Date:</b> 19 Aug 2003</p> <p> Consider the following code fragment: </p> @@ -12753,7 +12763,7 @@ techniques.) </p> <p><b>Proposed resolution:</b></p> <p> -In 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 3, change "Invalidates all the +In 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a> paragraph 3, change "Invalidates all the iterators and references after the point of the erase" to "Invalidates iterators and references at or after the point of the erase". @@ -12813,7 +12823,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#WP">WP</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.meta.help"> [lib.meta.help]</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 @@ -12823,7 +12833,7 @@ malloc). The standard also fails to mention what the required behavior is when the argument is less than 0. </p> <p><b>Proposed resolution:</b></p> -<p>Change 20.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.temporary.buffer"> [lib.temporary.buffer]</a> paragraph 2 from "...or a pair of 0 +<p>Change 20.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.help"> [lib.meta.help]</a> paragraph 2 from "...or a pair of 0 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> @@ -14094,7 +14104,7 @@ An implementation may also accept additional implementation-defined formats. ]</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#WP">WP</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.container.adaptors"> [lib.container.adaptors]</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#WP">WP</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> @@ -14118,14 +14128,14 @@ at() (which will then throw if the vector is empty). </li> </ul> <p><b>Proposed resolution:</b></p> -<p>In 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>, add the following to the <tt>vector</tt> +<p>In 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.adaptors"> [lib.container.adaptors]</a>, add the following to the <tt>vector</tt> synopsis after "element access" and before "modifiers":</p> <pre> // <i>[lib.vector.data] data access</i> pointer data(); const_pointer data() const; </pre> -<p>Add a new subsection of 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>:</p> +<p>Add a new subsection of 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.adaptors"> [lib.container.adaptors]</a>:</p> <blockquote> <p>23.2.4.x <tt>vector</tt> data access</p> <pre> pointer data(); @@ -14293,7 +14303,7 @@ the value need not be valid. "unspecified-bool-type".]</i></p> <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> +<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"> [lib.vector]</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 @@ -14510,9 +14520,9 @@ requirements of charT (described in 21 <a href="http://www.open-std.org/jtc1/sc2 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#WP">WP</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"> [lib.vector]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</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>, +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"> [lib.vector]</a>, the non-template assign() function has the signature</p> <pre> void assign( size_type n, const T& t ); |