diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog index ad336c90538..7c752b02854 100644 --- a/libstdc++-v3/ChangeLog +++ b/libstdc++-v3/ChangeLog @@ -1,3 +1,20 @@ +2002-07-20 Phil Edwards + + * docs/html/abi.txt: New file. + * docs/html/23_containers/howto.html: Tweak vector-overhead text. + * docs/html/ext/lwg-active.html, docs/html/ext/lwg-defects.html: + Import from upstream, R22. + + * include/bits/char_traits.h, include/bits/stl_iterator.h, + include/bits/stl_iterator_base_types.h, libsupc++/exception, + libsupc++/new, libsupc++/typeinfo: Use @brief markup. + + * include/bits/deque.tcc, include/bits/stl_alloc.h, + include/bits/stl_deque.h, include/bits/stl_list.h: Postpone removal + of deprecated functions until 3.4. (Same timeframe, different text.) + * include/bits/stl_vector.h: Ditto. Also do the same cleanups that + the other sequence classes received. + 2002-07-18 Brendan Kehoe * bits/slice_array.h (_DEFINE_VALARRAY_OPERATOR): Fix typo of diff --git a/libstdc++-v3/docs/html/23_containers/howto.html b/libstdc++-v3/docs/html/23_containers/howto.html index 4ad7ac6a21e..a64d79c75ae 100644 --- a/libstdc++-v3/docs/html/23_containers/howto.html +++ b/libstdc++-v3/docs/html/23_containers/howto.html @@ -27,7 +27,7 @@
  • "Hinting" during insertion
  • Bitmasks and string arguments
  • std::list::size() is O(n)! -
  • Memory management for vectors +
  • Space overhead management for vectors
    @@ -434,17 +434,19 @@

    -

    Memory management for vectors

    +

    Space overhead management for vectors

    In this message to the list, Daniel Kostecky announced work on an alternate form of std::vector that would support hints - about free store management. The design was also described, along - with possible implementation choices. + on the number of elements to be over-allocated. The design was also + described, along with possible implementation choices.

    -

    The first alpha release was announced - recently - and the releases themselves are available at +

    The first two alpha releases were announced + here + and + here. + The releases themselves are available at http://www.kotelna.sk/dk/sw/caphint/.

    diff --git a/libstdc++-v3/docs/html/abi.txt b/libstdc++-v3/docs/html/abi.txt new file mode 100644 index 00000000000..6c0ae1e79dd --- /dev/null +++ b/libstdc++-v3/docs/html/abi.txt @@ -0,0 +1,166 @@ + +=========================== + +See http://gcc.gnu.org/ml/libstdc++/2002-07/msg00054.html for why this +document exists, why it's incomplete, and what needs to be done still. + +=========================== + +2002-07-01 Benjamin Kosnik + +Description of the libstdc++ ABI. + +I. What is an ABI? What's covered? What's not? + +- What's the deal with C++? Why can't different compiler's object + files link with each other? Bug? Feature? + +- scope of document, of use to system integrators. + +- compilation includes and linked library binary must match up.. + +- library ABI, compiler ABI different (but effects) + +- GNU C++ does not have a compiler command line option to switch + between various different C++ ABIs. For instance, there is no way to + switch between the gcc-3.0.x ABI, gcc-3.1.x ABI, and the gcc-3.2.x + ABI during compilation. Other C++ compilers do allow this, and some + g++ command line options may change the ABI (-fno-exceptions, see + the complete list), but there is no version switch. Sorry. The GNU + Project recommends that + +- shared library only, static is immutable. + +- Minimum environment that supports a versioned ABI: what's needed? A + supported dynamic linker, a GNU linker of sufficient vintage to + understand demangled C++ name globbing (ld), a shared executable + compiled with g++, and shared libraries (libgcc_s, libstdc++-v3) + compiled by a compiler (g++) with a compatible ABI. Phew. + + On top of all that, an additional constraint: libstdc++ did not + attempt to version symbols (or age gracefully, really) until version + 3.1.0. + + Most modern Linux and BSD versions, particularly ones using + gcc-3.1.x tools, will meet the requirements above. + +- What configure options impact symbol versioning? + There is only one: --enable-symvers. For more information see: + http://gcc.gnu.org/onlinedocs/libstdc++/configopts.html + + In particular, libstdc++-v3/acinclude.m4 has a macro called + GLIBCPP_ENABLE_SYMVERS that defaults to yes (or the argument passed + in via --enable-symvers=foo). At that point, the macro attempts to + make sure that all the requirement for symbol versioning are in + place. For more information, please consult acinclude.m4. + +- How can I tell if symbol versioning is, indeed, active? + + When the GNU C++ library is being built with symbol versioning on, + you should see the following at configure time for libstdc++-v3: + +checking versioning on shared library symbols... gnu + + If you don't see this line in the configure output, or if this line + appears but the last word is 'no', then you are out of luck. + + If the compiler is pre-installed, a quick way to test is to compile + the following (or any) simple C++ file: + +#include + +int main() +{ std::cout << "hello" << std::endl; return 0; } + +%g++ hello.cc -o hello.out +%nm hello.out + +If you see symbols in the resulting output with "GLIBCPP_3.x" as part +of the name, then the executable is versioned. Here's an example: + + U _ZNSt8ios_base4InitC1Ev@@GLIBCPP_3.1 + + + + + + +II. ABI changes + +- (anything) changing size of an exported symbol + +- (anything) changing alignment of an exported symbol + +- (anything) changing the layout of an exported symbol + +- (anything) changing mangling on an exported symbol + +- (anything) adding or deleting an exported symbol + + +III. Versioning + +- include files + + - versioning headers with version, why necessary + (need to control member/non-member functions, add delete files) + +- shared library binaries + + - release versions + + - libtool versions + + - when does so version get a bump? what are the options? + + - how is the link map used? + + - in an non-abi breaking minor release, how are symbols added? + removed? + + - in an abi-breaking major release, what happens? symbol fall back + + +IV. Testing ABI changes + +- 'make check-abi'?? + +- other ABI checkers + + +V. Issues not directly addressed, and possible suggestions + +- what to do about multi-ABI systems (nathan scenario)? + + - compatibility libs + + --enable-version-specific-runtime-libs + + - Alexandre Oliva proposal to have extended name attributes, modify ld + + - directory-level versioning + +- wrapping C++ API's n "C" to use the C ABI. + + +V. References + +ABIcheck, a vauge idea of checking ABI compatibility +http://abicheck.sourceforge.net/ + +C++ ABI reference +http://www.codesourcery.com/cxx-abi/ + +Intel ABI documentation +"Intel® Compilers for Linux* -Compatibility with the GNU Compilers" +(included in icc 6.0) + +Sun Solaris 2.9 docs +Linker and Libraries Guide (document 816-1386) +C++ Migration Guide (document 816-2459) +http://docs.sun.com/db/prod/solaris.9 +http://docs.sun.com/?p=/doc/816-1386&a=load + +Ulrich Drepper, "ELF Symbol Versioning" +http://people.redhat.com/drepper/symbol-versioning + diff --git a/libstdc++-v3/docs/html/ext/lwg-active.html b/libstdc++-v3/docs/html/ext/lwg-active.html index 977df966b5a..c8d33f36f4b 100644 --- a/libstdc++-v3/docs/html/ext/lwg-active.html +++ b/libstdc++-v3/docs/html/ext/lwg-active.html @@ -5,11 +5,11 @@ - + - + @@ -20,7 +20,7 @@
    Doc. no.J16/01-0052 = WG21 N1337J16/02-0027 = WG21 N1369
    Date:09 Nov 200110 May 2002
    Project:Matt Austern <austern@research.att.com>
    -

    C++ Standard Library Active Issues List (Revision 20)

    +

    C++ Standard Library Active Issues List (Revision 22)

    Reference ISO/IEC IS 14882:1998(E)

    Also see:

      @@ -88,6 +88,12 @@ directory as the issues list files.

      Revision History

        +
      • R22: +Post-Curaçao mailing. Added new issues 362-366. +
        • +
      • R21: +Pre-Curaçao mailing. Added new issues 351-361. +
      • R20: Post-Redmond mailing; reflects actions taken in Redmond. Added new issues 336-350, of which issues @@ -95,19 +101,19 @@ new issues 336-3 not discussed at the meeting. All Ready issues were moved to DR status, with the exception of issues -284, 241, and 267. +284, 241, and 267. Noteworthy issues discussed at Redmond include 120 202, 226, 233, -270, 253, 254, 323. +270, 253, 254, 323.
      • R19: Pre-Redmond mailing. Added new issues -323-335. +323-335.
      • R18: Post-Copenhagen mailing; reflects actions taken in Copenhagen. -Added new issues 312-317, and discussed +Added new issues 312-317, and discussed new issues 271-314. Changed status of issues @@ -126,7 +132,7 @@ Changed status of issues 238 241 242 250 259 264 266 267 271 272 273 275 -281 284 285 286 +281 284 285 286 288 292 295 297 298 301 303 306 307 308 312 @@ -141,8 +147,8 @@ as NAD.
      • R17: Pre-Copenhagen mailing. Converted issues list to XML. Added proposed -resolutions for issues 49, 76, 91, 235, 250, 267. -Added new issues 278-311. +resolutions for issues 49, 76, 91, 235, 250, 267. +Added new issues 278-311.
      • R16: post-Toronto mailing; reflects actions taken in Toronto. Added new @@ -188,7 +194,7 @@ of issue 29. Add further rationale to issue post-Kona mailing: Updated to reflect LWG and full committee actions in Kona (99-0048/N1224). Note changed resolution of issues 4 and 38. Added issues 196 -to 198. Closed issues list split into "defects" and +to 198. Closed issues list split into "defects" and "closed" documents. Changed the proposed resolution of issue 4 to NAD, and changed the wording of proposed resolution of issue 38. @@ -272,7 +278,7 @@ format, 64 title. (17 Sep 98)

        Dup - The LWG has reached consensus that the issue is a duplicate of another issue, and will not be further - dealt with. A Rationale identities the duplicated issue's + dealt with. A Rationale identifies the duplicated issue's issue number.

        @@ -438,122 +444,9 @@ Tokyo: the LWG reaffirmed that this is a defect, and requires careful review of clause 27 as the changes are context sensitive. ]

        -
        -

        76. Can a codecvt facet always convert one internal character at a time?

        -Section: 22.2.1.5 [lib.locale.codecvt]  Status: Ready  Submitter: Matt Austern  Date: 25 Sep 1998

        -

        This issue concerns the requirements on classes derived from -codecvt, including user-defined classes. What are the -restrictions on the conversion from external characters -(e.g. char) to internal characters (e.g. wchar_t)? -Or, alternatively, what assumptions about codecvt facets can -the I/O library make?

        - -

        The question is whether it's possible to convert from internal -characters to external characters one internal character at a time, -and whether, given a valid sequence of external characters, it's -possible to pick off internal characters one at a time. Or, to put it -differently: given a sequence of external characters and the -corresponding sequence of internal characters, does a position in the -internal sequence correspond to some position in the external -sequence?

        - -

        To make this concrete, suppose that [first, last) is a -sequence of M external characters and that [ifirst, -ilast) is the corresponding sequence of N internal -characters, where N > 1. That is, my_encoding.in(), -applied to [first, last), yields [ifirst, -ilast). Now the question: does there necessarily exist a -subsequence of external characters, [first, last_1), such -that the corresponding sequence of internal characters is the single -character *ifirst? -

        - -

        (What a "no" answer would mean is that -my_encoding translates sequences only as blocks. There's a -sequence of M external characters that maps to a sequence of -N internal characters, but that external sequence has no -subsequence that maps to N-1 internal characters.)

        - -

        Some of the wording in the standard, such as the description of -codecvt::do_max_length (22.2.1.5.2 [lib.locale.codecvt.virtuals], -paragraph 11) and basic_filebuf::underflow (27.8.1.4 [lib.filebuf.virtuals], 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 -way or the other.

        - -

        This issue seems (and is) quite technical, but it is important if -we expect users to provide their own encoding facets. This is an area -where the standard library calls user-supplied code, so a well-defined -set of requirements for the user-supplied code is crucial. Users must -be aware of the assumptions that the library makes. This issue affects -positioning operations on basic_filebuf, unbuffered input, -and several of codecvt's member functions.

        -

        Proposed resolution:

        -

        Add the following text as a new paragraph, following 22.2.1.5.2 [lib.locale.codecvt.virtuals] paragraph 2:

        - -
        -

        A codecvt facet that is used by basic_filebuf -(27.8 [lib.file.streams]) must have the property that if

        -
        -    do_out(state, from, from_end, from_next, to, to_lim, to_next)
-
        -would return ok, where from != from_end, then -
        -    do_out(state, from, from + 1, from_next, to, to_end, to_next)
-
        -must also return ok, and that if -
        -    do_in(state, from, from_end, from_next, to, to_lim, to_next)
-
        -would return ok, where to != to_lim, then -
        -    do_in(state, from, from_end, from_next, to, to + 1, to_next)
-
        -

        must also return ok. [Footnote: Informally, this -means that basic_filebuf assumes that the mapping from -internal to external characters is 1 to N: a codecvt that is -used by basic_filebuf must be able to translate characters -one internal character at a time. --End Footnote]

        -
        - -

        [Redmond: Minor change in proposed resolution. Original -proposed resolution talked about "success", with a parenthetical -comment that success meant returning ok. New wording -removes all talk about "success", and just talks about the -return value.]

        - -

        Rationale:

        - -

        The proposed resoluion says that conversions can be performed one - internal character at a time. This rules out some encodings that - would otherwise be legal. The alternative answer would mean there - would be some internal positions that do not correspond to any - external file position.

        -

        - An example of an encoding that this rules out is one where the - internT and externT are of the same type, and - where the internal sequence c1 c2 corresponds to the - external sequence c2 c1. -

        -

        It was generally agreed that basic_filebuf relies - on this property: it was designed under the assumption that - the external-to-internal mapping is N-to-1, and it is not clear - that basic_filebuf is implementable without that - restriction. -

        -

        - The proposed resolution is expressed as a restriction on - codecvt when used by basic_filebuf, rather - than a blanket restriction on all codecvt facets, - because basic_filebuf is the only other part of the - library that uses codecvt. If a user wants to define - a codecvt facet that implements a more general N-to-M - mapping, there is no reason to prohibit it, so long as the user - does not expect basic_filebuf to be able to use it. -

        91. Description of operator>> and getline() for string<> might cause endless loop

        -Section: 21.3.7.9 [lib.string.io]  Status: Review  Submitter: Nico Josuttis  Date: 29 Sep 1998

        +Section: 21.3.7.9 [lib.string.io]  Status: Ready  Submitter: Nico Josuttis  Date: 29 Sep 1998

        Operator >> and getline() for strings read until eof() in the input stream is true. However, this might never happen, if the stream can't read anymore without reaching EOF. So shouldn't it be @@ -604,6 +497,8 @@ should be a formatted input function, not an unformatted input function. there is no mechanism for gcount to be set except by one of basic_istream's member functions.]

        +

        [Curaçao: Nico agrees with proposed resolution.]

        +

        Rationale:

        The real issue here is whether or not these string input functions get their characters from a streambuf, rather than by calling an @@ -725,6 +620,9 @@ multiple problems beyond the underlying problem of no definition of

        [Post-Tokyo: Nico provided the above proposed resolutions.]

        +

        [Curaçao: Nico will provide wording to make options clearer: are +the exclusive, or is one a superset of the other?]

        +

        96. Vector<bool> is not a container

        Section: 23.2.5 [lib.vector.bool]  Status: Open  Submitter: AFNOR  Date: 7 Oct 1998

        @@ -810,6 +708,9 @@ how many times a copy constructor is called, even if the copy constructor has observable behavior. (See issue 334 for a similar problem.)

        +

        [Issue still isn't clear. Matt will try to explain it more +clearly at the next meeting.]

        +

        Proposed resolution:

        120. Can an implementor add specializations?

        @@ -881,35 +782,43 @@ different explicit instantiations might be harmless.

        -

        [Copenhagen: LWG discussed three options. (A) Users may not +

        [Copenhagen: LWG discussed three options. (1) Users may not explicitly instantiate standard library templates, except on user-defined types. Consequence: library implementors may freely -specialize or instantiate templates. (B) It is implementation defined -whether users may explicitly instantiate standard library templates on -non-user-defined types. Consequence: library implementors may freely -specialize or instantiate templates, but may need to document some or -all templates that have been explicitly instantiated. (C) Users may -explicitly instantiate any standard library template. +specialize or instantiate templates. (2) Users may explicitly +instantiate any standard library template. Consequence: if +implementors specialize or instantiate library templates, they may +need to take special steps to make sure users can do it too. (3) It +is implementation defined whether users may explicitly instantiate +standard library templates on non-user-defined types. Consequence: +library implementors may freely specialize or instantiate templates, +but may need to document some or all templates that have been +explicitly instantiated. ]

        -

        [Straw poll (first number is favor, second is strongly oppose): -A - 4, 0; B - 0, 9; C - 9, 1. Proposed resolution 1, above, is -option A. (It is the original proposed resolution.) Proposed -resolution 2, above, is option C. Because there was no support -for option B, no wording is provided.]

        +

        [Straw poll (first number is favor, second is strongly oppose): 1 +- 4, 0; 2 - 9, 1; 3 - 0, 9. (Proposed resolution 1 was the original +proposed resolution.) Because there was no support for option 3, no +wording is provided.]

        [Redmond: discussed again; straw poll had results similar to -those of Copenhagen (A - 1, 3; B - 6, 2; C - 8, 4). Most people said -they could live with any option. The only objection to option A is +those of Copenhagen (1 - 1, 3; 2 - 8, 4; 3 - 6, 2). Most people said +they could live with any option. The only objection to option 2 is potential implementation difficulty. Steve Clamage volunteered do a -survey to see if there are any popular platforms where option A would +survey to see if there are any popular platforms where option 2 would present a real problem for implementors. See his reflector message, c++std-lib-9002. ]

        +

        [Steve and Pete Becker will talk to Jonathan Caves. The +Microsoft linker might present a problem if there are multiple copies, +some of which have static data and some of which are in DLLs. There +may be similar problems with the Apple linker; Matt will clarify +that.]

        +

        123. Should valarray helper arrays fill functions be const?

        -Section: 26.3.5.4 [lib.slice.arr.fill], 26.3.7.4 [lib.gslice.array.fill], 26.3.8.4 [lib.mask.array.fill], 26.3.9.4 [lib.indirect.array.fill]  Status: Review  Submitter: Judy Ward  Date: 15 Dec 1998

        +Section: 26.3.5.4 [lib.slice.arr.fill], 26.3.7.4 [lib.gslice.array.fill], 26.3.8.4 [lib.mask.array.fill], 26.3.9.4 [lib.indirect.array.fill]  Status: Ready  Submitter: Judy Ward  Date: 15 Dec 1998

        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 [lib.slice.arr.assign] is const:

        @@ -1098,7 +1007,7 @@ text got garbled when the signed char/unsigned char specializations were removed. Dietmar will provide revised wording.]

        179. Comparison of const_iterators to iterators doesn't work

        -Section: 23.1 [lib.container.requirements]  Status: Review  Submitter: Judy Ward  Date: 2 Jul 1998

        +Section: 23.1 [lib.container.requirements]  Status: Ready  Submitter: Judy Ward  Date: 2 Jul 1998

        Currently the following will not compile on two well-known standard library implementations:

        @@ -1335,135 +1244,9 @@ unclear. It may have a different meaning as a container member function than as an allocator member function. For the latter, it is probably best thought of as an architectural limit. Nathan will provide new wording.]

        -
        -

        198. Validity of pointers and references unspecified after iterator destruction

        -Section: 24.1 [lib.iterator.requirements]  Status: Ready  Submitter: Beman Dawes  Date: 3 Nov 1999

        -

        -Is a pointer or reference obtained from an iterator still valid after -destruction of the iterator? -

        -

        -Is a pointer or reference obtained from an iterator still valid after the value -of the iterator changes? -

        -
        -
        -#include <iostream>
-#include <vector>
-#include <iterator>
-
-int main()
-{
-    typedef std::vector<int> vec_t;
-    vec_t v;
-    v.push_back( 1 );
-
-    // Is a pointer or reference obtained from an iterator still
-    // valid after destruction of the iterator?
-    int * p = &*v.begin();
-    std::cout << *p << '\n';  // OK?
-
-    // Is a pointer or reference obtained from an iterator still
-    // valid after the value of the iterator changes?
-    vec_t::iterator iter( v.begin() );
-    p = &*iter++;
-    std::cout << *p << '\n';  // OK?
-
-    return 0;
-}
-
        -
        - -

        The standard doesn't appear to directly address these -questions. The standard needs to be clarified. At least two real-world -cases have been reported where library implementors wasted -considerable effort because of the lack of clarity in the -standard. The question is important because requiring pointers and -references to remain valid has the effect for practical purposes of -prohibiting iterators from pointing to cached rather than actual -elements of containers.

        - -

        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 [lib.reverse.iter.op.star], which returns a reference, defines -effects:

        - -
        - 
        Iterator tmp = current;
-return *--tmp;
        -
        -

        The definition of reverse_iterator::operator->(), 24.4.1.3.4 [lib.reverse.iter.opref], which returns a pointer, defines effects:

        -
        - 
        return &(operator*());
        -
        - -

        Because the standard itself assumes pointers and references remain -valid after iterator destruction or change, the standard should say so -explicitly. This will also reduce the chance of user code breaking -unexpectedly when porting to a different standard library -implementation.

        -

        Proposed resolution:

        -

        Add a new paragraph to 24.1 [lib.iterator.requirements]:

        -
        -Destruction of an iterator may invalidate pointers and references -previously obtained from that iterator. -
        - -

        Replace paragraph 1 of 24.4.1.3.3 [lib.reverse.iter.op.star] with:

        - -
        -

        Effects:

        -
        -  this->tmp = current;
-  --this->tmp;
-  return *this->tmp;
-
        - -

        -[Note: This operation must use an auxiliary member variable, -rather than a temporary variable, to avoid returning a reference that -persists beyond the lifetime of its associated iterator. (See -24.1 [lib.iterator.requirements].) The name of this member variable is shown for -exposition only. --end note] -

        -
        - -

        [Post-Tokyo: The issue has been reformulated purely -in terms of iterators.]

        - -

        [Pre-Toronto: Steve Cleary pointed out the no-invalidation -assumption by reverse_iterator. The issue and proposed resolution was -reformulated yet again to reflect this reality.]

        - -

        [Copenhagen: Steve Cleary pointed out that reverse_iterator -assumes its underlying iterator has persistent pointers and -references. Andy Koenig pointed out that it is possible to rewrite -reverse_iterator so that it no longer makes such an assupmption. -However, this issue is related to issue 299. If we -decide it is intentional that p[n] may return by value -instead of reference when p is a Random Access Iterator, -other changes in reverse_iterator will be necessary.]

        -

        Rationale:

        -

        This issue has been discussed extensively. Note that it is -not an issue about the behavior of predefined iterators. It is -asking whether or not user-defined iterators are permitted to have -transient pointers and references. Several people presented examples -of useful user-defined iterators that have such a property; examples -include a B-tree iterator, and an "iota iterator" that doesn't point -to memory. Library implementors already seem to be able to cope with -such iterators: they take pains to avoid forming references to memory -that gets iterated past. The only place where this is a problem is -reverse_iterator, so this issue changes -reverse_iterator to make it work.

        - -

        This resolution does not weaken any guarantees provided by -predefined iterators like list<int>::iterator. -Clause 23 should be reviewed to make sure that guarantees for -predefined iterators are as strong as users expect.

        -

        200. Forward iterator requirements don't allow constant iterators

        -Section: 24.1.3 [lib.forward.iterators]  Status: Review  Submitter: Matt Austern  Date: 19 Nov 1999

        +Section: 24.1.3 [lib.forward.iterators]  Status: Ready  Submitter: Matt Austern  Date: 19 Nov 1999

        In table 74, the return type of the expression *a is given as T&, where T is the iterator's value type. @@ -1581,7 +1364,7 @@ clear how numeric_limits applies to each of those cases. A wholesale review of numeric_limits is needed. A paper would be welcome.]

        202. unique() effects unclear when predicate not an equivalence relation

        -Section: 25.2.8 [lib.alg.unique]  Status: Review  Submitter: Andrew Koenig  Date: 13 Jan 2000

        +Section: 25.2.8 [lib.alg.unique]  Status: Ready  Submitter: Andrew Koenig  Date: 13 Jan 2000

        What should unique() do if you give it a predicate that is not an equivalence relation? There are at least two plausible answers: @@ -1652,7 +1435,7 @@ In fact, the SGI implementation of unique() does neither: It yields 1,

        For a nonempty range, eliminates all but the first element from every consecutive group of equivalent elements referred to by the iterator -i in the range (first, last) for which the following +i in the range [first+1, last) for which the following conditions hold: *(i-1) == *i or pred(*(i-1), *i) != false.
        @@ -1672,6 +1455,11 @@ pointed out that "i-1" is incorrect, since "i" can refer to iterator in the range. Matt provided wording to address this problem.]

        +

        [Curaçao: The LWG changed "... the range (first, +last)..." to "... the range [first+1, last)..." for +clarity. They considered this change close enough to editorial to not +require another round of review.]

        +

        Rationale:

        The LWG also considered an alternative resolution: change 25.2.8 [lib.alg.unique] paragraph 1 to:

        @@ -1795,6 +1583,13 @@ illegal, since, under certain circumstances, its semantics are not those specified in the standard. The standard's description of unique does not say that overloading adjacent_find should have any effect.]

        + +

        [Curaçao: An LWG-subgroup spent an afternoon working on issues +225, 226, and 229. Their conclusion was that the issues should be +separated into an LWG portion (Howard will write a proposal), and a +EWG portion (Dave will write a proposal). The LWG and EWG had +(separate) discussions of this plan the next day.]

        +

        226. User supplied specializations or overloads of namespace std function templates

        Section: 17.4.3.1 [lib.reserved.names]  Status: Open  Submitter: Dave Abrahams  Date: 01 Apr 2000

        @@ -1867,6 +1662,19 @@ similar set of concerns was earlier raised on the boost.org mailing list and the ACCU-general mailing list. Also see library reflector message c++std-lib-7354.

        +

        +J. C. van Winkel points out (in c++std-lib-9565) another unexpected +fact: it's impossible to output a container of std::pair's using copy +and an ostream_iterator, as long as both pair-members are built-in or +std:: types. That's because a user-defined operator<< for (for +example) std::pair<const std::string, int> will not be found: +lookup for operator<< will be performed only in namespace std. +Opinions differed on whether or not this was a defect, and, if so, +whether the defect is that something is wrong with user-defined +functionality and std, or whether it's that the standard library does +not provide an operator<< for std::pair<>. +

        +

        Proposed resolution:

        [Tokyo: Summary, "There is no conforming way to extend @@ -1924,6 +1732,12 @@ unqualified call of swap. (And which other functions? Any?) A small group (Nathan, Howard, Jeremy, Dave, Matt, Walter, Marc) will try to put together a proposal before the next meeting.]

        +

        [Curaçao: An LWG-subgroup spent an afternoon working on issues +225, 226, and 229. Their conclusion was that the issues should be +separated into an LWG portion (Howard will write a proposal), and a +EWG portion (Dave will write a proposal). The LWG and EWG had +(separate) discussions of this plan the next day.]

        +

        229. Unqualified references of other library entities

        Section: 17.4.1.1 [lib.contents]  Status: Open  Submitter: Steve Clamage  Date: 19 Apr 2000

        @@ -1967,9 +1781,16 @@ are intended to be called by library code. Several LWG members are concerned that valarray appears to require argument-dependent lookup, but that the wording may not be clear enough to fall under "unless explicitly described otherwise".]

        + +

        [Curaçao: An LWG-subgroup spent an afternoon working on issues +225, 226, and 229. Their conclusion was that the issues should be +separated into an LWG portion (Howard will write a proposal), and a +EWG portion (Dave will write a proposal). The LWG and EWG had +(separate) discussions of this plan the next day.]

        +

        231. Precision in iostream?

        -Section: 22.2.2.2.2 [lib.facet.num.put.virtuals]  Status: Ready  Submitter: James Kanze, Stephen Clamage  Date:  25 Apr 2000

        +Section: 22.2.2.2.2 [lib.facet.num.put.virtuals]  Status: Open  Submitter: James Kanze, Stephen Clamage  Date:  25 Apr 2000

        What is the following program supposed to output?

        #include <iostream>
 
@@ -2025,9 +1846,13 @@ for %f and %e, but not for %g: for %g, precision 0 is taken
 to be the same as precision 1.
        
 
        The proposed resolution has the effect that the output of
 the above program will be "1e+00".
        
+
+
        [Curaçao: Howard will send Matt improved wording dealing with
+case not covered by current PR.]
        
+
 
        
 
        233. Insertion hints in associative containers
        
-Section: 23.1.2  [lib.associative.reqmts]  Status: Review  Submitter: Andrew Koenig  Date: 30 Apr 2000
        
+Section: 23.1.2  [lib.associative.reqmts]  Status: Open  Submitter: Andrew Koenig  Date: 30 Apr 2000
        
 
        
 If mm is a multimap and p is an iterator
 into the multimap, then mm.insert(p, x) inserts
@@ -2095,18 +1920,21 @@ t is inserted adjacent to iterator p.
 
        [Toronto: there was general agreement that this is a real defect:
 when inserting an element x into a multiset that already contains
 several copies of x, there is no way to know whether the hint will be
-used.  There was some support for an alternative resolution: we check
-on both sides of the hint (both before and after, in that order).  If
-either is the correct location, the hint is used; otherwise it is not.
-This would be different from the original proposed resolution, because
-in the proposed resolution the hint will be used even if it is very
-far from the insertion point.  JC van Winkel supplied precise wording
-for both options.]
        
+used.  The proposed resolution was that the new element should always
+be inserted as close to the hint as possible.  So, for example, if
+there is a subsequence of equivalent values, then providing a.begin()
+as the hint means that the new element should be inserted before the
+subsequence even if a.begin() is far away.  JC van Winkel supplied
+precise wording for this proposed resolution, and also for an
+alternative resolution in which hints are only used when they are
+adjacent to the insertion point.]
        
 
-
        [Copenhagen: the LWG looked at both options, and preferred the
-original.  This preference is contingent on seeing a reference
+
        [Copenhagen: the LWG agreed to the original proposed resolution,
+in which an insertion hint would be used even when it is far from the
+insertion point.  This was contingent on seeing a reference
 implementation showing that it is possible to implement this
-requirement without loss of efficiency.]
        
+requirement without loss of efficiency.  John Potter provided such a
+reference implementation.]
        
 
 
        [Redmond: The LWG was reluctant to adopt the proposal that
 emerged from Copenhagen: it seemed excessively complicated, and went
@@ -2117,92 +1945,12 @@ you can do it efficiently enough with a red-black tree, but there are
 other (perhaps better) balanced tree techniques that might differ
 enough to make the detailed semantics hard to satisfy."]
        
 
-
        
-
        239. Complexity of unique() and/or unique_copy incorrect
        
-Section: 25.2.8  [lib.alg.unique]  Status: Review  Submitter: Angelika Langer  Date: May 15 2000
        
-
        The complexity of unique and unique_copy are inconsistent with each
-other and inconsistent with the implementations.  The standard
-specifies:
        
-
-
        for unique():
        
-
-
        -3- Complexity: If the range (last - first) is not empty, exactly
-(last - first) - 1 applications of the corresponding predicate, otherwise
-no applications of the predicate.
        
-
-
        for unique_copy():
        
-
-
        -7- Complexity: Exactly last - first applications of the corresponding
-predicate.
        
-
-
        
-The implementations do it the other way round: unique() applies the
-predicate last-first times and unique_copy() applies it last-first-1
-times.
        
-
-
        As both algorithms use the predicate for pair-wise comparison of
-sequence elements I don't see a justification for unique_copy()
-applying the predicate last-first times, especially since it is not
-specified to which pair in the sequence the predicate is applied
-twice.
        
-
        Proposed resolution:
        
-
        Change both complexity sections in 25.2.8  [lib.alg.unique] to:
        
-
-
        Complexity: For nonempty ranges, exactly last - first - 1
-applications of the corresponding predicate.
        
-
-
        
-
        240. Complexity of adjacent_find() is meaningless
        
-Section: 25.1.5  [lib.alg.adjacent.find]  Status: Ready  Submitter: Angelika Langer  Date: May 15 2000
        
-
        The complexity section of adjacent_find is defective:
        
-
-
        
-
        -template <class ForwardIterator>
-ForwardIterator adjacent_find(ForwardIterator first, ForwardIterator last
-                              BinaryPredicate pred);
-
        
-
-
        -1- Returns: The first iterator i such that both i and i + 1 are in
-the range [first, last) for which the following corresponding
-conditions hold: *i == *(i + 1), pred(*i, *(i + 1)) != false. Returns
-last if no such iterator is found.
        
-
-
        -2- Complexity: Exactly find(first, last, value) - first applications
-of the corresponding predicate.
-
        
-
        
-
-
        In the Complexity section, it is not defined what "value"
-is supposed to mean. My best guess is that "value" means an
-object for which one of the conditions pred(*i,value) or
-pred(value,*i) is true, where i is the iterator defined in the Returns
-section. However, the value type of the input sequence need not be
-equality-comparable and for this reason the term find(first, last,
-value) - first is meaningless.
        
-
-
        A term such as find_if(first, last, bind2nd(pred,*i)) - first or
-find_if(first, last, bind1st(pred,*i)) - first might come closer to
-the intended specification.  Binders can only be applied to function
-objects that have the function call operator declared const, which is
-not required of predicates because they can have non-const data
-members. For this reason, a specification using a binder could only be
-an "as-if" specification.
        
-
        Proposed resolution:
        
-
        Change the complexity section in 25.1.5  [lib.alg.adjacent.find] to:
        
-
        
-For a nonempty range, exactly min((i - first) + 1,
-(last - first) - 1) applications of the
-corresponding predicate, where i is adjacent_find's
-return value.
-
        
-
-
        [Copenhagen: the original resolution specified an upper
-bound.  The LWG preferred an exact count.]
        
+
        [Curaçao: Nathan should give us the alternative wording he
+suggests so the LWG can decide between the two options.]
        
 
 
        
 
        241. Does unique_copy() require CopyConstructible and Assignable?
        
-Section: 25.2.8  [lib.alg.unique]  Status: Review  Submitter: Angelika Langer  Date: May 15 2000
        
+Section: 25.2.8  [lib.alg.unique]  Status: Ready  Submitter: Angelika Langer  Date: May 15 2000
        
 
 
        Some popular implementations of unique_copy() create temporary
 copies of values in the input sequence, at least if the input iterator
@@ -2231,11 +1979,12 @@ shall not overlap.
 
        to:
        
 
 
        
--4- Requires: The ranges [first, last) and [result, result+(last-first)) 
-shall not overlap. The expression *result = *first must be valid.  If 
-both InputIterator and OutputIterator do not meet the requirements of 
-forward iterator then the value type of InputIterator must be copy 
-constructible.  Otherwise copy constructible is not required.
+  
        -4- Requires: The ranges [first, last) and [result,
+  result+(last-first)) shall not overlap. The expression *result =
+  *first must be valid. If neither InputIterator nor OutputIterator
+  meets the requirements of forward iterator then the value type of
+  InputIterator must be copy constructible. Otherwise copy
+  constructible is not required. 
        
 
        
 
 
        [Redmond: the original proposed resolution didn't impose an
@@ -2247,6 +1996,13 @@ it might be possible to implement unique_copy without
 requiring assignability, although current implementations do impose
 that requirement.  Howard provided new wording.]
        
 
+
        [
+Curaçao: The LWG changed the PR editorially to specify
+"neither...nor...meet..." as clearer than
+"both...and...do not meet...". Change believed to be so
+minor as not to require re-review.
+]
        
+
 
        
 
        247. vector, deque::insert complexity
        
 Section: 23.2.4.3  [lib.vector.modifiers]  Status: Open  Submitter: Lisa Lippincott  Date: 06 June 2000
        
@@ -2319,7 +2075,7 @@ complicated than a while loop whose body is a single-element
 insert.]
        
 
        
 
        253. valarray helper functions are almost entirely useless
        
-Section: 26.3.2.1  [lib.valarray.cons], 26.3.2.2  [lib.valarray.assign]  Status: Review  Submitter: Robert Klarer  Date: 31 Jul 2000
        
+Section: 26.3.2.1  [lib.valarray.cons], 26.3.2.2  [lib.valarray.assign]  Status: Ready  Submitter: Robert Klarer  Date: 31 Jul 2000
        
 
        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.
        
@@ -2570,7 +2326,9 @@ copy constructor is potentially invoked during stack unwinding.
        
 
 
        The copy constructor is a more serious problem, becuase failure
 during stack unwinding invokes terminate.  The copy
-constructor must be nothrow.
        
+constructor must be nothrow. Curaçao: Howard thinks this
+requirement is already present.
+
        
 
 
        The fundamental problem is that it's difficult to get the nothrow
 requirement to work well with the requirement that the exception
@@ -2607,6 +2365,8 @@ members thought there was a real defect lurking here.  A small group
 (Herb, Kevlin, Howard, Martin, Dave) will try to make a
 recommendation.]
        
 
+
        [Curaçao: Howard will nag the others to work on a recommendation.]
        
+
 
        
 
        258. Missing allocator requirement
        
 Section: 20.1.5  [lib.allocator.requirements]  Status: Open  Submitter: Matt Austern  Date: 22 Aug 2000
        
@@ -2677,458 +2437,9 @@ required that X(x1) == x1.  Another opinion is that
 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.]
        
-
        
-
        270. Binary search requirements overly strict
        
-Section: 25.3.3  [lib.alg.binary.search]  Status: Ready  Submitter: Matt Austern  Date: 18 Oct 2000
        
-
        
-Each of the four binary search algorithms (lower_bound, upper_bound,
-equal_range, binary_search) has a form that allows the user to pass a
-comparison function object.  According to 25.3, paragraph 2, that
-comparison function object has to be a strict weak ordering.
-
        
-
-
        
-This requirement is slightly too strict.  Suppose we are searching
-through a sequence containing objects of type X, where X is some
-large record with an integer key.  We might reasonably want to look
-up a record by key, in which case we would want to write something
-like this:
-
        
-
        -    struct key_comp {
-      bool operator()(const X& x, int n) const {
-        return x.key() < n;
-      }
-    }
-
-    std::lower_bound(first, last, 47, key_comp());
-
        
-
-
        
-key_comp is not a strict weak ordering, but there is no reason to
-prohibit its use in lower_bound.
-
        
-
-
        
-There's no difficulty in implementing lower_bound so that it allows
-the use of something like key_comp.  (It will probably work unless an
-implementor takes special pains to forbid it.)  What's difficult is
-formulating language in the standard to specify what kind of
-comparison function is acceptable.  We need a notion that's slightly
-more general than that of a strict weak ordering, one that can encompass
-a comparison function that involves different types.  Expressing that
-notion may be complicated.
-
        
-
-
        Additional questions raised at the Toronto meeting:
        
-
          
-
        •  Do we really want to specify what ordering the implementor must
-     use when calling the function object?  The standard gives 
-     specific expressions when describing these algorithms, but it also
-     says that other expressions (with different argument order) are
-     equivalent.
          • 
-
        •  If we are specifying ordering, note that the standard uses both
-     orderings when describing equal_range.
          • 
-
        •  Are we talking about requiring these algorithms to work properly
-     when passed a binary function object whose two argument types
-     are not the same, or are we talking about requirements when
-     they are passed a binary function object with several overloaded
-     versions of operator()?
          • 
-
        •  The definition of a strict weak ordering does not appear to give
-     any guidance on issues of overloading; it only discusses expressions,
-     and all of the values in these expressions are of the same type.
-     Some clarification would seem to be in order.
          • 
-
        
-
-
        Additional discussion from Copenhagen:
        
-
          
-
        • It was generally agreed that there is a real defect here: if
-the predicate is merely required to be a Strict Weak Ordering, then
-it's possible to pass in a function object with an overloaded
-operator(), where the version that's actually called does something
-completely inappropriate.  (Such as returning a random value.)
          • 
-
-
        • An alternative formulation was presented in a paper distributed by
-David Abrahams at the meeting, "Binary Search with Heterogeneous
-Comparison", J16-01/0027 = WG21 N1313: Instead of viewing the
-predicate as a Strict Weak Ordering acting on a sorted sequence, view
-the predicate/value pair as something that partitions a sequence.
-This is almost equivalent to saying that we should view binary search
-as if we are given a unary predicate and a sequence, such that f(*p)
-is true for all p below a specific point and false for all p above it.
-The proposed resolution is based on that alternative formulation.
          • 
-
        
-
        Proposed resolution:
        
-
-
        Change 25.3 [lib.alg.sorting] paragraph 3 from:
        
-
-
        
-  3 For all algorithms that take Compare, there is a version that uses
-  operator< instead. That is, comp(*i, *j) != false defaults to *i <
-  *j != false. For the algorithms to work correctly, comp has to
-  induce a strict weak ordering on the values.
-
        
-
-
        to:
        
-
-
        
-  3 For all algorithms that take Compare, there is a version that uses
-  operator< instead. That is, comp(*i, *j) != false defaults to *i
-  < *j != false. For algorithms other than those described in
-  lib.alg.binary.search (25.3.3) to work correctly, comp has to induce
-  a strict weak ordering on the values.
-
        
-
-
        Add the following paragraph after 25.3 [lib.alg.sorting] paragraph 5:
        
-
-
        
-  -6- A sequence [start, finish) is partitioned with respect to an
-  expression f(e) if there exists an integer n such that
-  for all 0 <= i < distance(start, finish), f(*(begin+i)) is true if
-  and only if i < n.
-
        
-
-
        Change 25.3.3 [lib.alg.binary.search] paragraph 1 from:
        
-
-
        
-  -1- All of the algorithms in this section are versions of binary
-   search and assume that the sequence being searched is in order
-   according to the implied or explicit comparison function. They work
-   on non-random access iterators minimizing the number of
-   comparisons, which will be logarithmic for all types of
-   iterators. They are especially appropriate for random access
-   iterators, because these algorithms do a logarithmic number of
-   steps through the data structure. For non-random access iterators
-   they execute a linear number of steps.
-
        
-
-
        to:
        
-
-
        
-   -1- All of the algorithms in this section are versions of binary
-    search and assume that the sequence being searched is partitioned
-    with respect to an expression formed by binding the search key to
-    an argument of the implied or explicit comparison function. They
-    work on non-random access iterators minimizing the number of
-    comparisons, which will be logarithmic for all types of
-    iterators. They are especially appropriate for random access
-    iterators, because these algorithms do a logarithmic number of
-    steps through the data structure. For non-random access iterators
-    they execute a linear number of steps.
-
        
-
-
        Change 25.3.3.1 [lib.lower.bound] paragraph 1 from:
        
-
-
        
-   -1- Requires: Type T is LessThanComparable
-    (lib.lessthancomparable). 
-
        
-
-
        to:
        
-
-
        
-   -1- Requires: The elements e of [first, last) are partitioned with
-   respect to the expression e < value or comp(e, value)
-
        
-
-
-
        Remove 25.3.3.1 [lib.lower.bound] paragraph 2:
        
-
-
        
-   -2- Effects: Finds the first position into which value can be
-    inserted without violating the ordering. 
-
        
-
-
        Change 25.3.3.2 [lib.upper.bound] paragraph 1 from:
        
-
-
        
-  -1- Requires: Type T is LessThanComparable (lib.lessthancomparable).
-
        
-
-
        to:
        
-
-
        
-   -1- Requires: The elements e of [first, last) are partitioned with
-   respect to the expression !(value < e) or !comp(value, e)
-
        
-
-
        Remove 25.3.3.2 [lib.upper.bound] paragraph 2:
        
-
-
        
-   -2- Effects: Finds the furthermost position into which value can be
-    inserted without violating the ordering.
-
        
-
-
        Change 25.3.3.3 [lib.equal.range] paragraph 1 from:
        
-
-
        
-   -1- Requires: Type T is LessThanComparable
-    (lib.lessthancomparable).
-
        
-
-
        to:
        
-
-
        
-   -1- Requires: The elements e of [first, last) are partitioned with
-   respect to the expressions e < value and !(value < e) or
-   comp(e, value) and !comp(value, e).  Also, for all elements e of
-   [first, last), e < value implies !(value < e) or comp(e,
-   value) implies !comp(value, e)
-
        
-
-
        Change 25.3.3.3 [lib.equal.range] paragraph 2 from:
        
-
-
        
-   -2- Effects: Finds the largest subrange [i, j) such that the value
-    can be inserted at any iterator k in it without violating the
-    ordering. k satisfies the corresponding conditions: !(*k < value)
-    && !(value < *k) or comp(*k, value) == false && comp(value, *k) ==
-    false.
-
        
-
-
        to:
        
-
-
        -   -2- Returns: 
-         make_pair(lower_bound(first, last, value),
-                   upper_bound(first, last, value))
-       or
-         make_pair(lower_bound(first, last, value, comp),
-                   upper_bound(first, last, value, comp))
-
        
-
-
        Change 25.3.3.3 [lib.binary.search] paragraph 1 from:
        
-
-
        
-   -1- Requires: Type T is LessThanComparable
-    (lib.lessthancomparable).
-
        
-
-
        to:
        
-
-
        
-   -1- Requires: The elements e of [first, last) are partitioned with
-   respect to the expressions e < value and !(value < e) or comp(e,
-   value) and !comp(value, e). Also, for all elements e of [first,
-   last), e < value implies !(value < e) or comp(e, value) implies
-   !comp(value, e)
-
        
-
-
        [Copenhagen: Dave Abrahams provided this wording]
        
-
-
        [Redmond: Minor changes in wording.  (Removed "non-negative", and
-changed the "other than those described in" wording.) Also, the LWG
-decided to accept the "optional" part.]
        
-
-
        Rationale:
        
-
        The proposed resolution reinterprets binary search. Instead of
-thinking about searching for a value in a sorted range, we view that
-as an important special case of a more general algorithm: searching
-for the partition point in a partitioned range.
        
-
-
        We also add a guarantee that the old wording did not: we ensure
-that the upper bound is no earlier than the lower bound, that
-the pair returned by equal_range is a valid range, and that the first
-part of that pair is the lower bound.
        
-
        
-
        274. a missing/impossible allocator requirement
        
-Section: 20.1.5  [lib.allocator.requirements]  Status: Ready  Submitter: Martin Sebor  Date: 02 Nov 2000
        
-
        
-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
-be overloaded on reference and const_reference, which is ill-formed for
-all T = const U. In other words, this won't work:
-
        
-
-
        
-template class std::allocator<const int>;
-
        
-
-
        
-The obvious solution is to disallow specializations of allocators on
-const types. However, while containers' elements are required to be
-assignable (which rules out specializations on const T's), I think that
-allocators might perhaps be potentially useful for const values in other
-contexts. So if allocators are to allow const types a partial
-specialization of std::allocator<const T> would probably have to be
-provided.
-
        
-
        Proposed resolution:
        
-
        Change the text in row 1, column 2 of table 32 in 20.1.5, p3 from
        
-
-    
        
-    any type
-    
        
-
-
        to
        
-    
        
-    any non-const, non-reference type
-    
        
-
-
        [Redmond: previous proposed resolution was "any non-const,
-non-volatile, non-reference type".  Got rid of the "non-volatile".]
        
-
-
        Rationale:
        
-
        
-Two resolutions were originally proposed: one that partially
-specialized std::allocator for const types, and one that said an
-allocator's value type may not be const.  The LWG chose the second.
-The first wouldn't be appropriate, because allocators are intended for
-use by containers, and const value types don't work in containers.
-Encouraging the use of allocators with const value types would only
-lead to unsafe code.
-
        
-
        
-The original text for proposed resolution 2 was modified so that it
-also forbids volatile types and reference types.
-
        
-
        
-
        276. Assignable requirement for container value type overly strict
        
-Section: 23.1  [lib.container.requirements]  Status: Ready  Submitter: Peter Dimov  Date: 07 Nov 2000
        
-
        
-23.1/3 states that the objects stored in a container must be
-Assignable.  23.3.1  [lib.map], paragraph 2,
-states that map satisfies all requirements for a container, while in
-the same time defining value_type as pair<const Key, T> - a type
-that is not Assignable.
-
        
-
-
        
-It should be noted that there exists a valid and non-contradictory
-interpretation of the current text. The wording in 23.1/3 avoids 
-mentioning value_type, referring instead to "objects stored in a
-container." One might argue that map does not store objects of
-type map::value_type, but of map::mapped_type instead, and that the
-Assignable requirement applies to map::mapped_type, not
-map::value_type.
-
        
-
-
        
-However, this makes map a special case (other containers store objects of
-type value_type) and the Assignable requirement is needlessly restrictive in
-general.
-
        
-
-
        
-For example, the proposed resolution of active library issue 
-103 is to make set::iterator a constant iterator; this
-means that no set operations can exploit the fact that the stored
-objects are Assignable.
-
        
-
-
        
-This is related to, but slightly broader than, closed issue
-140.
-
        
-
        Proposed resolution:
        
-
        23.1/3: Strike the trailing part of the sentence:
        
-    
        
-    , and the additional requirements of Assignable types from 23.1/3
-    
        
-
        so that it reads:
        
-    
        
-    -3- The type of objects stored in these components must meet the 
-    requirements of CopyConstructible types (lib.copyconstructible).
-    
        
-
-
        23.1/4: Modify to make clear that this requirement is not for all 
-containers.  Change to:
        
-
-
        
--4- Table 64 defines the Assignable requirement.  Some containers 
-require this property of the types to be stored in the container.  T is 
-the type used to instantiate the container. t is a value of T, and u is 
-a value of (possibly const) T.
-
        
-
-
        23.1, Table 65: in the first row, change "T is Assignable" to "T is
-CopyConstructible".
        
-
-
        23.2.1/2: Add sentence for Assignable requirement.  Change to:
        
-
-
        
--2- A deque satisfies all of the requirements of a container and of a 
-reversible container (given in tables in lib.container.requirements) and 
-of a sequence, including the optional sequence requirements 
-(lib.sequence.reqmts).  In addition to the requirements on the stored 
-object described in 23.1[lib.container.requirements], the stored object 
-must also meet the requirements of Assignable.  Descriptions are 
-provided here only for operations on deque that are not described in one 
-of these tables or for operations where there is additional semantic 
-information.
-
        
-
-
        23.2.2/2:  Add Assignable requirement to specific methods of list.  
-Change to:
        
-
-
        
-
        -2- A list satisfies all of the requirements of a container and of a 
-reversible container (given in two tables in lib.container.requirements) 
-and of a sequence, including most of the the optional sequence 
-requirements (lib.sequence.reqmts). The exceptions are the operator[] 
-and at member functions, which are not provided. 
-
-[Footnote: These member functions are only provided by containers whose 
-iterators are random access iterators. --- end foonote]
-
        
-
-
        list does not require the stored type T to be Assignable unless the 
-following methods are instantiated:
-
-[Footnote: Implementors are permitted but not required to take advantage 
-of T's Assignable properties for these methods. -- end foonote]
-
        
-
        -     list<T,Allocator>& operator=(const list<T,Allocator>&  x );
-     template <class InputIterator>
-       void assign(InputIterator first, InputIterator last);
-     void assign(size_type n, const T& t);
-
        
-
-
-
        Descriptions are provided here only for operations on list that are not 
-described in one of these tables or for operations where there is 
-additional semantic information.
        
-
        
-
-
        23.2.4/2:   Add sentence for Assignable requirement.  Change to:
        
-
-
        
--2- A vector satisfies all of the requirements of a container and of a 
-reversible container (given in two tables in lib.container.requirements) 
-and of a sequence, including most of the optional sequence requirements 
-(lib.sequence.reqmts). The exceptions are the push_front and pop_front 
-member functions, which are not provided.  In addition to the 
-requirements on the stored object described in 
-23.1[lib.container.requirements], the stored object must also meet the 
-requirements of Assignable.  Descriptions are provided here only for 
-operations on vector that are not described in one of these tables or 
-for operations where there is additional semantic information.
-
        
-
        Rationale:
        
-
        list, set, multiset, map, multimap are able to store non-Assignables.
-However, there is some concern about list<T>:
-although in general there's no reason for T to be Assignable, some
-implementations of the member functions operator= and
-assign do rely on that requirement.  The LWG does not want
-to forbid such implementations.
        
-
-
        Note that the type stored in a standard container must still satisfy
-the requirements of the container's allocator; this rules out, for
-example, such types as "const int".  See issue 274
-for more details.
-
        
-
-
        In principle we could also relax the "Assignable" requirement for
-individual vector member functions, such as
-push_back.  However, the LWG did not see great value in such
-selective relaxation.  Doing so would remove implementors' freedom to
-implement vector::push_back in terms of
-vector::insert.
        
-
 
        
 
        278. What does iterator validity mean?
        
-Section: 23.2.2.4  [lib.list.ops]  Status: Review  Submitter: P.J. Plauger  Date: 27 Nov 2000
        
+Section: 23.2.2.4  [lib.list.ops]  Status: Open  Submitter: P.J. Plauger  Date: 27 Nov 2000
        
 
        
 Section 23.2.2.4 [lib.list.ops] states that
 
        
@@ -3171,6 +2482,11 @@ has been invalidated is undefined.]
 
        [Redmond: General agreement with the intent, some objections to
 the wording.  Dave provided new wording.]
        
 
+
        [Curaçao: The definition of "singular" is
+contentious.  The 278 resolution must be made consistent with
+issue 208 and 24.1/5. Furthermore, a Rationale paragraph
+is required.]
        
+
 
        
 
        280. Comparison of reverse_iterator to const reverse_iterator
        
 Section: 24.4.1  [lib.reverse.iterators]  Status: Open  Submitter: Steve Cleary  Date: 27 Nov 2000
        
@@ -3277,9 +2593,12 @@ floating-point input even though this is unambiguously required by the
 standard.
 ]
        
 
+
        [Curaçao: Howard will email Bill and other implementors to try to
+move the issue forward.]
        
+
 
        
 
        283. std::replace() requirement incorrect/insufficient
        
-Section: 25.2.4  [lib.alg.replace]  Status: Review  Submitter: Martin Sebor  Date: 15 Dec 2000
        
+Section: 25.2.4  [lib.alg.replace]  Status: Open  Submitter: Martin Sebor  Date: 15 Dec 2000
        
 
        
 The requirements in 25.2.4  [lib.alg.replace], p1 that T to be
 Assignable (23.1  [lib.container.requirements]) is not necessary or
@@ -3526,53 +2845,10 @@ std::iterator_traits<ForwardIterator>::value_type must be Assignable
 (23.1  [lib.container.requirements]).
 
 
-
        
-
        284. unportable example in 20.3.7, p6
        
-Section: 20.3.7  [lib.function.pointer.adaptors]  Status: Ready  Submitter: Martin Sebor  Date: 26 Dec 2000
        
-
        The example in 20.3.7  [lib.function.pointer.adaptors], p6 shows how to use the C
-library function strcmp() with the function pointer adapter
-ptr_fun(). But since it's unspecified whether the C library
-functions have extern "C" or extern
-"C++" linkage [17.4.2.2  [lib.using.linkage]], and since
-function pointers with different the language linkage specifications
-(7.5  [dcl.link]) are incompatible, whether this example is
-well-formed is unspecified.
-
        
-
        Proposed resolution:
        
-
        Change 20.3.7  [lib.function.pointer.adaptors] paragraph 6 from:
        
-
        
-  
        [Example:
-
        
-  
        -    replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++");
-  
        
-  
        replaces each C with C++ in sequence v.
        
-
        
-
-
-
        to:
        
-
        
-  
        [Example:
-
        
-  
        -    int compare(const char*, const char*);
-    replace_if(v.begin(), v.end(),
-               not1(bind2nd(ptr_fun(compare), "abc")), "def");
-  
        
-  
        replaces each abc with def in sequence v.
        
-
        
-
-
        Also, remove footnote 215 in that same paragraph.
        
-
-
        [Copenhagen: Minor change in the proposed resolution.  Since this
-issue deals in part with C and C++ linkage, it was believed to be too
-confusing for the strings in the example to be "C" and "C++".
-]
        
-
-
        [Redmond: More minor changes.  Got rid of the footnote (which
-seems to make a sweeping normative requirement, even though footnotes
-aren't normative), and changed the sentence after the footnote so that
-it corresponds to the new code fragment.]
        
+
        [Curaçao: Jeremy reports he has run the changes through his
+automated test tools.  At the request of the LWG, Jeremy will reword
+the PR in terms of valid expressions rather than "equality
+operator".]
        
 
 
        
 
        290. Requirements to for_each and its function object
        
@@ -3621,7 +2897,7 @@ blanket statement in Clause 25, not just a special requirement for
 
 
        
 
        291. Underspecification of set algorithms
        
-Section: 25.3.5  [lib.alg.set.operations]  Status: Open  Submitter: Matt Austern  Date: 03 Jan 2001
        
+Section: 25.3.5  [lib.alg.set.operations]  Status: Review  Submitter: Matt Austern  Date: 03 Jan 2001
        
 
        
 The standard library contains four algorithms that compute set
 operations on sorted ranges: set_union, set_intersection,
@@ -3671,8 +2947,50 @@ same way.
 
        
 
 
        Proposed resolution:
        
-
        [The LWG agrees that the standard should answer these questions.
-Matt will provide wording.]
        
+
+
        Add the following to the end of 25.3.5.2  [lib.set.union] paragraph 5:
        
+
        
+If [first1, last1) contains m elements that are equivalent to
+each other and [first2, last2) contains n elements that are
+equivalent to them, then max(m, n) of these elements
+will be copied to the output range: all m of these elements
+from [first1, last1), and the last max(n-m, 0) of them from
+[first2, last2), in that order.
+
        
+
+
        Add the following to the end of 25.3.5.3  [lib.set.intersection] paragraph 5:
        
+
        
+If [first1, last1) contains m elements that are equivalent to each
+other and [first2, last2) contains n elements that are
+equivalent to them, the first min(m, n) of those 
+elements from [first1, last1) are copied to the output range.
+
        
+
+
        Add a new paragraph, Notes, after 25.3.5.4  [lib.set.difference]
+paragraph 4:
        
+
        
+If [first1, last1) contains m elements that are equivalent to each
+other and [first2, last2) contains n elements that are
+equivalent to them, the last max(m-n, 0) elements from 
+[first1, last1) are copied to the output range.
+
        
+
+
        Add a new paragraph, Notes, after 25.3.5.5  [lib.set.symmetric.difference]
+paragraph 4:
        
+
        
+If [first1, last1) contains m elements that are equivalent to
+each other and [first2, last2) contains n elements that are
+equivalent to them, then |m - n| of those elements will be
+copied to the output range: the last m - n of these elements
+from [first1, last1) if m > n, and the last n -
+m of these elements from [first2, last2) if m < n.
+
        
+
+
        [Curaçao: Missing Rationale and missing status comments from
+Redmond made discussion difficult. For union, doesn't the standard
+already say this? Howard, others think maybe so. Several thought the
+PR may be "too complicated".]
        
+
 
        
 
        294. User defined macros and standard headers
        
 Section: 17.4.3.1.1  [lib.macro.names]  Status: Open  Submitter: James Kanze  Date: 11 Jan 2001
        
@@ -3768,6 +3086,8 @@ about issue 299 should keep this possibility in mind.
 
        In section 24.1.5  [lib.random.access.iterators], change the return type in table
 76 from "convertible to T" to T&.
        
 
+
        [Curaçao: Jeremy volunteered to work on this issue.]
        
+
 
        
 
        300. list::merge() specification incomplete
        
 Section: 23.2.2.4  [lib.list.ops]  Status: Open  Submitter: John Pedretti  Date: 23 Jan 2001
        
@@ -3794,6 +3114,8 @@ Changing p23, without changing the other two, appears to introduce
 contradictions.  Additionally, "merges the argument list into the
 list" is excessively vague.]
        
 
+
        [Curaçao: Robert Klarer volunteers to work on this issue.]
        
+
 
        
 
        304. Must *a return an lvalue when a is an input iterator?
        
 Section: 24.1  [lib.iterator.requirements]  Status: Open  Submitter: Dave Abrahams  Date: 5 Feb 2001
        
@@ -3834,7 +3156,7 @@ it has no operator->.  A straw poll showed roughly equal
 support for the two options.]
        
 
        
 
        305. Default behavior of codecvt<wchar_t, char, mbstate_t>::length()
        
-Section: 22.2.1.5.2  [lib.locale.codecvt.virtuals]  Status: Review  Submitter: Howard Hinnant  Date: 24 Jan 2001
        
+Section: 22.2.1.5.2  [lib.locale.codecvt.virtuals]  Status: Ready  Submitter: Howard Hinnant  Date: 24 Jan 2001
        
 
        22.2.1.5/3 introduces codecvt in part with:
        
 
 
        
@@ -3939,8 +3261,12 @@ would expect the default encoding to be whatever C uses in the default
 "C" locale.  We could impose a guarantee like the one Nathan suggested
 (a character from the basic execution character set must map to a
 single external character), but this would rule out important
-encodings that are in common use: it would rule out Shift-JIS, for
+encodings that are in common use: it would rule out JIS, for
 example, and it would rule out a fixed-width encoding of UCS-4.
        
+
+
        [Curaçao: fixed rationale typo at the request of Ichiro Koshida;
+"shift-JIS" changed to "JIS".]
        
+
 
        
 
        309. Does sentry catch exceptions?
        
 Section: 27.6  [lib.iostream.format]  Status: Open  Submitter: Martin Sebor  Date: 19 Mar 2001
        
@@ -4044,270 +3370,9 @@ exception handling is the responsibility of those functions, not of
 the sentries.
 ]
        
 
-
        
-
        310. Is errno a macro?
        
-Section: 17.4.1.2  [lib.headers], 19.3  [lib.errno]  Status: Ready  Submitter: Steve Clamage  Date: 21 Mar 2001
        
-  
        
-  Exactly how should errno be declared in a conforming C++ header?
-  
        
-
-  
        
-  The C standard says in 7.1.4 that it is unspecified whether errno is a
-  macro or an identifier with external linkage.  In some implementations
-  it can be either, depending on compile-time options.  (E.g., on
-  Solaris in multi-threading mode, errno is a macro that expands to a
-  function call, but is an extern int otherwise.  "Unspecified" allows
-  such variability.)
-  
        
-
-  
        The C++ standard:
        
-  
          
-  
        • 17.4.1.2 says in a note that errno must be macro in C. (false)
          • 
-  
        • 17.4.3.1.3 footnote 166 says errno is reserved as an external 
-      name (true), and implies that it is an identifier.
          • 
-  
        • 19.3 simply lists errno as a macro (by what reasoning?) and goes
-      on to say that the contents of of C++ <errno.h> are the
-      same as in C, begging the question.
          • 
-  
        • C.2, table 95 lists errno as a macro, without comment.
          • 
-  
        
-
-  
        I find no other references to errno.
        
-
-  
        We should either explicitly say that errno must be a macro, even
-  though it need not be a macro in C, or else explicitly leave it
-  unspecified.  We also need to say something about namespace std. 
-  A user who includes <cerrno> needs to know whether to write
-  errno, or ::errno, or std::errno, or
-  else <cerrno> is useless.
        
-
-  
        Two acceptable fixes:
        
-  
          
-    
        • errno must be a macro. This is trivially satisfied by adding
          
-          #define errno (::std::errno)
          
-        to the headers if errno is not already a macro. You then always
-        write errno without any scope qualification, and it always expands
-        to a correct reference. Since it is always a macro, you know to
-        avoid using errno as a local identifer.
          • 
-    
        • errno is in the global namespace. This fix is inferior, because
-        ::errno is not guaranteed to be well-formed.
          • 
-  
        
-
-  
        [
-    This issue was first raised in 1999, but it slipped through 
-    the cracks.
-  ]
        
-
        Proposed resolution:
        
-  
        Change the Note in section 17.4.1.2p5 from
        
-
-    
        
-    Note: the names defined as macros in C include the following:
-    assert, errno, offsetof, setjmp, va_arg, va_end, and va_start.
-    
        
-
-  
        to
        
-
-    
        
-    Note: the names defined as macros in C include the following:
-    assert, offsetof, setjmp, va_arg, va_end, and va_start.
-    
        
-
-  
        In section 19.3, change paragraph 2 from
        
-
-    
        
-    The contents are the same as the Standard C library header
-    <errno.h>.
-    
        
-
-  
        to
        
-
-    
        
-    The contents are the same as the Standard C library header 
-    <errno.h>, except that errno shall be defined as a macro.
-    
        
-
        Rationale:
        
-
        C++ must not leave it up to the implementation to decide whether
-or not a name is a macro; it must explicitly specify exactly which
-names are required to be macros.
        
-
        
-
        311. Incorrect wording in basic_ostream class synopsis
        
-Section: 27.6.2.1  [lib.ostream]  Status: Ready  Submitter: Andy Sawyer  Date: 21 Mar 2001
        
-
-
        In 27.6.2.1  [lib.ostream], the synopsis of class basic_ostream says:
        
-
-
        -  // partial specializationss
-  template<class traits>
-    basic_ostream<char,traits>& operator<<( basic_ostream<char,traits>&,
-                                            const char * );
-
        
-
-
        Problems:
        
-
          
-
        • Too many 's's at the end of "specializationss" 
          • 
-
        • This is an overload, not a partial specialization
          • 
-
        
-
-
        Proposed resolution:
        
-
        In the synopsis in 27.6.2.1  [lib.ostream], remove the 
-// partial specializationss comment.  Also remove the same 
-comment (correctly spelled, but still incorrect) from the synopsis in 
-27.6.2.5.4  [lib.ostream.inserters.character].
-
        
-
-
        [
-Pre-Redmond: added 27.6.2.5.4  [lib.ostream.inserters.character] because of Martin's
-comment in c++std-lib-8939.
-]
        
-
-
        
-
        315. Bad "range" in list::unique complexity
        
-Section: 23.2.2.4  [lib.list.ops]  Status: Ready  Submitter: Andy Sawyer  Date: 1 May 2001
        
-
        
-23.2.2.4  [lib.list.ops], 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)".
-
        
-
-
        
-"(last - first)" is not a range.
-
        
-
        Proposed resolution:
        
-
        
-Change the "range" from (last - first) to [first, last).
-
        
-
        
-
        316. Vague text in Table 69
        
-Section: 23.1.2  [lib.associative.reqmts]  Status: Ready  Submitter: Martin Sebor  Date: 4 May 2001
        
-
        Table 69 says this about a_uniq.insert(t):
        
-
-
        
-inserts t if and only if there is no element in the container with key
-equivalent to the key of t. The bool component of the returned pair 
-indicates whether the insertion takes place and the iterator component of the
-pair points to the element with key equivalent to the key of t.
-
        
-
-
        The description should be more specific about exactly how the bool component
-indicates whether the insertion takes place.
        
-
        Proposed resolution:
        
-
        Change the text in question to
        
-
-
        
-...The bool component of the returned pair is true if and only if the insertion
-takes place...
-
        
-
        
-
        317. Instantiation vs. specialization of facets
        
-Section: 22  [lib.localization]  Status: Ready  Submitter: Martin Sebor  Date: 4 May 2001
        
-
        
-The localization section of the standard refers to specializations of
-the facet templates as instantiations even though the required facets
-are typically specialized rather than explicitly (or implicitly)
-instantiated. In the case of ctype<char> and
-ctype_byname<char> (and the wchar_t versions), these facets are
-actually required to be specialized. The terminology should be
-corrected to make it clear that the standard doesn't mandate explicit
-instantiation (the term specialization encompasses both explicit
-instantiations and specializations).
-
        
-
        Proposed resolution:
        
-
        
-In the following paragraphs, replace all occurrences of the word
-instantiation or instantiations with specialization or specializations,
-respectively:
-
        
-
-
        
-22.1.1.1.1, p4, Table 52, 22.2.1.1, p2, 22.2.1.5, p3, 22.2.1.5.1, p5,
-22.2.1.5.2, p10, 22.2.2, p2, 22.2.3.1, p1, 22.2.3.1.2, p1, p2 and p3, 
-22.2.4.1, p1, 22.2.4.1.2, p1, 22,2,5, p1, 22,2,6, p2, 22.2.6.3.2, p7, and
-Footnote 242.
-
        
-
-
        And change the text in 22.1.1.1.1, p4 from
        
-
-
        
-    An implementation is required to provide those instantiations
-    for facet templates identified as members of a category, and
-    for those shown in Table 52:
-
        
-
-
        to
        
-
-
        
-    An implementation is required to provide those specializations...
-
        
-
-
        [Nathan will review these changes, and will look for places where
-explicit specialization is necessary.]
        
-
-
        Rationale:
        
-
        This is a simple matter of outdated language.  The language to
-describe templates was clarified during the standardization process,
-but the wording in clause 22 was never updated to reflect that
-change.
        
-
        
-
        318. Misleading comment in definition of numpunct_byname
        
-Section: 22.2.3.2  [lib.locale.numpunct.byname]  Status: Ready  Submitter: Martin Sebor  Date: 12 May 2001
        
-
        The definition of the numpunct_byname template contains the following
-comment:
        
-
-
        -    namespace std {
-        template <class charT>
-        class numpunct_byname : public numpunct<charT> {
-    // this class is specialized for char and wchar_t.
-        ...
-
        
-
-
        There is no documentation of the specializations and it seems
-conceivable that an implementation will not explicitly specialize the
-template at all, but simply provide the primary template.
        
-
        Proposed resolution:
        
-
        Remove the comment from the text in 22.2.3.2 and from the proposed
-resolution of library issue 228.
        
-
        
-
        319. Storage allocation wording confuses "Required behavior", "Requires"
        
-Section: 18.4.1.1  [lib.new.delete.single], 18.4.1.2  [lib.new.delete.array]  Status: Ready  Submitter: Beman Dawes  Date: 15 May 2001
        
-
        The standard specifies 17.3.1.3  [lib.structure.specifications] that "Required
-behavior" elements describe "the semantics of a function definition
-provided by either the implementation or a C++ program."
        
-
-
        The standard specifies 17.3.1.3  [lib.structure.specifications] that "Requires"
-elements describe "the preconditions for calling the function."
        
-
-
        In the sections noted below, the current wording specifies
-"Required Behavior" for what are actually preconditions, and thus
-should be specified as "Requires".
        
-
-
        Proposed resolution:
        
-
-
        In 18.4.1.1  [lib.new.delete.single] Para 12 Change:
        
-
        
-  
        Required behavior: accept a value of ptr that is null or that was
-  returned by an earlier call ...
        
-
        
-
        to:
        
-
        
-  
        Requires: the value of ptr is null or the value returned by an
-  earlier call ...
        
-
        
-
-
        In 18.4.1.2  [lib.new.delete.array] Para 11 Change:
        
-
        
-  
        Required behavior: accept a value of ptr that is null or that was
-  returned by an earlier call ...
        
-
        
-
        to:
        
-
        
-  
        Requires: the value of ptr is null or the value returned by an
-  earlier call ...
        
-
        
-
 
        
 
        320. list::assign overspecified
        
-Section: 23.2.2.1  [lib.list.cons]  Status: Review  Submitter: Howard Hinnant  Date: 17 May 2001
        
+Section: 23.2.2.1  [lib.list.cons]  Status: Ready  Submitter: Howard Hinnant  Date: 17 May 2001
        
 
        
 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.
@@ -4351,11 +3416,15 @@ Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't.
 
        
 
 
        In 23.1.1  [lib.sequence.reqmts], in Table 67 (sequence requirements), 
-add a new row:
        
+add two new rows:
        
 
               a.assign(i,j)     void      pre: i,j are not iterators into a.
-                                  Replaces elements in a with copies
-                                  of elements in [i, j).
+                                  Replaces elements in a with a copy
+                                  of [i, j).
+
+      a.assign(n,t)     void      pre: t is not a reference into a.
+                                  Replaces elements in a with n copies
+                                  of t.
 
        
 
 
        Change 23.2.2.1/8 from:
        
@@ -4380,58 +3449,14 @@ Also, the change in the sequence requirements is new.  Without that
 change, the proposed resolution would have required that assignment of
 a subrange would have to work.  That too would have been
 overspecification; it would effectively mandate that assignment use a
-temporary.
+temporary.  Howard provided wording.
 ]
        
 
-
        
-
        321. Typo in num_get
        
-Section: 22.2.2.1.2  [lib.facet.num.get.virtuals]  Status: Ready  Submitter: Kevin Djang  Date: 17 May 2001
        
-
        
-Section 22.2.2.1.2 at p7 states that "A length specifier is added to
-the conversion function, if needed, as indicated in Table 56."
-However, Table 56 uses the term "length modifier", not "length
-specifier".
-
        
-
        Proposed resolution:
        
-
        
-In 22.2.2.1.2 at p7, change the text "A length specifier is added ..."
-to be "A length modifier is added ..."
-
        
-
        Rationale:
        
-
        C uses the term "length modifier".  We should be consistent.
        
-
        
-
        322. iterator and const_iterator should have the same value type
        
-Section: 23.1  [lib.container.requirements]  Status: Ready  Submitter: Matt Austern  Date: 17 May 2001
        
-
        
-It's widely assumed that, if X is a container,
-iterator_traits<X::iterator>::value_type and
-iterator_traits<X::const_iterator>::value_type should both be
-X::value_type.  However, this is nowhere stated.  The language in
-Table 65 is not precise about the iterators' value types (it predates
-iterator_traits), and could even be interpreted as saying that
-iterator_traits<X::const_iterator>::value_type should be "const
-X::value_type".
-
        
+
        [Curaçao: Made editorial improvement in wording; changed
+"Replaces elements in a with copies of elements in [i, j)."
+with "Replaces the elements of a with a copy of [i, j)."
+Changes not deemed serious enough to requre rereview.]
        
 
-
        Related issue: 279.
        
-
        Proposed resolution:
        
-
        In Table 65 ("Container Requirements"), change the return type for
-X::iterator to "iterator type whose value type is T".  Change the
-return type for X::const_iterator to "constant iterator type whose
-value type is T".
        
-
        Rationale:
        
-
        
-This belongs as a container requirement, rather than an iterator
-requirement, because the whole notion of iterator/const_iterator
-pairs is specific to containers' iterator.
-
        
-
        
-It is existing practice that (for example) 
-iterator_traits<list<int>::const_iterator>::value_type
-is "int", rather than "const int".  This is consistent with
-the way that const pointers are handled: the standard already 
-requires that iterator_traits<const int*>::value_type is int.
-
        
 
        
 
        323. abs() overloads in different headers
        
 Section: 26.5  [lib.c.math]  Status: Open  Submitter: Dave Abrahams  Date: 4 June 2001
        
@@ -4487,7 +3512,7 @@ defined in which headers. (See issue 343)]
 
 
        
 
        324. Do output iterators have value types?
        
-Section: 24.1.2  [lib.output.iterators]  Status: Review  Submitter: Dave Abrahams  Date: 7 June 2001
        
+Section: 24.1.2  [lib.output.iterators]  Status: Ready  Submitter: Dave Abrahams  Date: 7 June 2001
        
 
 
        Table 73 suggests that output iterators have value types.  It 
 requires the expression "*a = t".  Additionally, although Table 73
@@ -4540,7 +3565,7 @@ output iterators' pointer and reference types?
        
 
        
 
        All iterators i support the expression *i, resulting
 in a value of some class, enumeration, or built-in type T,
-called the value type of the itereator.
        
+called the value type of the iterator.
        
 
        
 
 
        to
        
@@ -4611,7 +3636,7 @@ and any language suggesting otherwise is simply a mistake.
        
 decision.
        
 
        
 
        325. Misleading text in moneypunct<>::do_grouping
        
-Section: 22.2.6.3.2  [lib.locale.moneypunct.virtuals]  Status: Review  Submitter: Martin Sebor  Date: 02 Jul 2001
        
+Section: 22.2.6.3.2  [lib.locale.moneypunct.virtuals]  Status: Ready  Submitter: Martin Sebor  Date: 02 Jul 2001
        
 
        The Returns clause in 22.2.6.3.2, p3 says about
 moneypunct<charT>::do_grouping()
 
        
@@ -4663,47 +3688,8 @@ locale. It is just a reminder that the values are interpreted as small
 integers, not ASCII characters.
 
        
 
        
-
        327. Typo in time_get facet in table 52
        
-Section: 22.1.1.1.1  [lib.locale.category]  Status: Ready  Submitter: Tiki Wan  Date: 06 Jul 2001
        
-
        The wchar_t versions of time_get and
-time_get_byname are listed incorrectly in table 52,
-required instantiations.  In both cases the second template
-parameter is given as OutputIterator.  It should instead be
-InputIterator, since these are input facets.
        
-
        Proposed resolution:
        
-
        
-In table 52, required instantiations, in 
-22.1.1.1.1  [lib.locale.category], change
        
-
        -    time_get<wchar_t, OutputIterator>
-    time_get_byname<wchar_t, OutputIterator>
-
        
-
        to
        
-
        -    time_get<wchar_t, InputIterator>
-    time_get_byname<wchar_t, InputIterator>
-
        
-
-
        [Redmond: Very minor change in proposed resolution.  Original had
-a typo, wchart instead of wchar_t.]
        
-
-
        
-
        328. Bad sprintf format modifier in money_put<>::do_put()
        
-Section: 22.2.6.2.2  [lib.locale.money.put.virtuals]  Status: Ready  Submitter: Martin Sebor  Date: 07 Jul 2001
        
-
        The sprintf format string , "%.01f" (that's the digit one), in the
-description of the do_put() member functions of the money_put facet in
-22.2.6.2.2, p1 is incorrect. First, the f format specifier is wrong
-for values of type long double, and second, the precision of 01
-doesn't seem to make sense. What was most likely intended was
-"%.0Lf"., that is a precision of zero followed by the L length
-modifier.
        
-
        Proposed resolution:
        
-
        Change the format string to "%.0Lf".
        
-
        Rationale:
        
-
        Fixes an obvious typo
        
-
        
 
        329. vector capacity, reserve and reallocation
        
-Section: 23.2.4.2  [lib.vector.capacity], 23.2.4.3  [lib.vector.modifiers]  Status: Review  Submitter: Anthony Williams  Date: 13 Jul 2001
        
+Section: 23.2.4.2  [lib.vector.capacity], 23.2.4.3  [lib.vector.modifiers]  Status: Ready  Submitter: Anthony Williams  Date: 13 Jul 2001
        
 
        
 There is an apparent contradiction about which circumstances can cause
 a reallocation of a vector in Section 23.2.4.2  [lib.vector.capacity] and
@@ -4784,45 +3770,8 @@ the argument to the first, the intent was for the second invocation to
 have no effect.  Wording implying that such cases have an effect on
 reallocation guarantees was inadvertant.
        
 
        
-
        331. bad declaration of destructor for ios_base::failure
        
-Section: 27.4.2.1.1  [lib.ios::failure]  Status: Ready  Submitter: PremAnand M. Rao  Date: 23 Aug 2001
        
-
        
-With the change in 17.4.4.8  [lib.res.on.exception.handling] to state
-   "An implementation may strengthen the exception-specification for a 
-    non-virtual function by removing listed exceptions."
-(issue 119)
-and the following declaration of ~failure() in ios_base::failure
-
        
-
        -    namespace std {
-       class ios_base::failure : public exception {
-       public:
-           ...
-           virtual ~failure();
-           ...
-       };
-     }
-
        
-
        the class failure cannot be implemented since in 18.6.1  [lib.exception] the destructor of class exception has an empty
-exception specification:
        
-
        -    namespace std {
-       class exception {
-       public:
-         ...
-         virtual ~exception() throw();
-         ...
-       };
-     }
-
        
-
        Proposed resolution:
        
-
        Remove the declaration of ~failure().
        
-
        Rationale:
        
-
        The proposed resolution is consistent with the way that destructors
-of other classes derived from exception are handled.
        
-
        
 
        333. does endl imply synchronization with the device?
        
-Section: 27.6.2.7  [lib.ostream.manip]  Status: Review  Submitter: PremAnand M. Rao  Date: 27 Aug 2001
        
+Section: 27.6.2.7  [lib.ostream.manip]  Status: Ready  Submitter: PremAnand M. Rao  Date: 27 Aug 2001
        
 
        A footnote in 27.6.2.7  [lib.ostream.manip] states:
        
 
        
     [Footnote: The effect of executing cout << endl is to insert a 
@@ -4857,7 +3806,7 @@ because it appears to make promises about what flush
 does.
        
 
        
 
        334. map::operator[] specification forces inefficient implementation
        
-Section: 23.3.1.2  [lib.map.access]  Status: Review  Submitter: Andrea Griffini  Date: 02 Sep 2001
        
+Section: 23.3.1.2  [lib.map.access]  Status: Ready  Submitter: Andrea Griffini  Date: 02 Sep 2001
        
 
        
 The current standard describes map::operator[] using a
 code example. That code example is however quite
@@ -4957,49 +3906,15 @@ clause 17 saying that we do not intend the semantics of sample code
 fragments to be interpreted as specifing exactly how many copies are
 made.  See issue 98 for a similar problem.]
        
 
-
        
-
        335. minor issue with char_traits, table 37
        
-Section: 21.1.1  [lib.char.traits.require]  Status: Ready  Submitter: Andy Sawyer  Date: 06 Sep 2001
        
+
        Rationale:
        
 
        
-Table 37, in 21.1.1  [lib.char.traits.require], descibes char_traits::assign
-as:
-
        
-
        -  X::assign(c,d)   assigns c = d.
-
        
-
-
        And para 1 says:
        
-
-
        
- [...] c and d denote values of type CharT [...]
-
        
-
-
        
-Naturally, if c and d are values, then the assignment is
-(effectively) meaningless. It's clearly intended that (in the case of
-assign, at least), 'c' is intended to be a reference type.
+This is the second solution described above; as noted, it is
+consistent with existing practice.
 
        
 
-
        I did a quick survey of the four implementations I happened to have
-lying around, and sure enough they all have signatures:
        
-
        -    assign( charT&, const charT& );
-
        
-
-
        (or the equivalent). It's also described this way in Nico's book.
-(Not to mention the synopses of char_traits<char> in 21.1.3.1
-and char_traits<wchar_t> in 21.1.3.2...)
-
        
-
        Proposed resolution:
        
-
        Add the following to 21.1.1 para 1:
        
-
        
- r denotes an lvalue of CharT
-
        
-
-
        and change the description of assign in the table to:
        
-
        -  X::assign(r,d)   assigns r = d
-
        
+
        Note that we now need to specify the complexity explicitly, because
+we are no longer defining operator[] in terms of
+insert.
        
 
        
 
        336. Clause 17 lack of references to deprecated headers
        
 Section: 17  [lib.library]  Status: Open  Submitter: Detlef Vollmann  Date: 05 Sep 2001
        
@@ -5017,22 +3932,13 @@ library (though a deprecated one).
        
 to table 11.  A review is needed to determine whether there are any
 other places in clause 17 where clause D material should be referred
 to. Beman will review clause 17.]
        
-
        
-
        337. replace_copy_if's template parameter should be InputIterator
        
-Section: 25.2.4  [lib.alg.replace]  Status: Ready  Submitter: Detlef Vollmann  Date: 07 Sep 2001
        
-
        From c++std-edit-876:
        
 
-
        
-In section 25.2.4  [lib.alg.replace] before p4: The name of the first
-parameter of template replace_copy_if should be "InputIterator"
-instead of "Iterator".  According to 17.3.2.1  [lib.type.descriptions] p1 the
-parameter name conveys real normative meaning.
-
        
-
        Proposed resolution:
        
-
        Change Iterator to InputIterator.
        
+
        [Curaçao: Beman emailed wording to Matt, but not in time for the
+pre-meeting mailing.]
        
+
 
        
 
        338.  is whitespace allowed between `-' and a digit?
        
-Section: 22.2  [lib.locale.categories]  Status: Review  Submitter: Martin Sebor  Date: 17 Sep 2001
        
+Section: 22.2  [lib.locale.categories]  Status: Ready  Submitter: Martin Sebor  Date: 17 Sep 2001
        
 
        
 From Stage 2 processing in 22.2.2.1.2  [lib.facet.num.get.virtuals], p8 and 9 (the
 original text or the text corrected by the proposed resolution of
@@ -5094,7 +4000,7 @@ numeric processing in 22.2.2.1.2 
        339. definition of bitmask type restricted to clause 27
        
-Section: 22.2.1  [lib.category.ctype], 17.3.2.1.2  [lib.bitmask.types]  Status: Review  Submitter: Martin Sebor  Date: 17 September 2001
        
+Section: 22.2.1  [lib.category.ctype], 17.3.2.1.2  [lib.bitmask.types]  Status: Ready  Submitter: Martin Sebor  Date: 17 September 2001
        
 
        
 The ctype_category::mask type is declared to be an enum in 22.2.1  [lib.category.ctype] with p1 then stating that it is a bitmask type, most
 likely referring to the definition of bitmask type in 17.3.2.1.2  [lib.bitmask.types], p1. However, the said definition only applies to
@@ -5128,7 +4034,7 @@ following (note, in particluar, the cross-reference to 17.3.2.1.2 in
 namespace std {
     class ctype_base {
     public:
-        typedef T mask;
+        typedef T mask;
 
         // numeric values are for exposition only.
         static const mask space = 1 << 0;
@@ -5149,10 +4055,13 @@ namespace std {
 
        The type mask is a bitmask type (17.3.2.1.2  [lib.bitmask.types]).
        
 
        
 
+
        [Curaçao: The LWG notes that T above should be bold-italics to be
+consistent with the rest of the standard.]
        
+
 
        
 
        340. interpretation of has_facet<Facet>(loc)
 
        
-Section: 22.1.1.1.1  [lib.locale.category]  Status: Review  Submitter: Martin Sebor  Date: 18 Sep 2001
        
+Section: 22.1.1.1.1  [lib.locale.category]  Status: Ready  Submitter: Martin Sebor  Date: 18 Sep 2001
        
 
        
 It's unclear whether 22.1.1.1.1, p3 says that
 has_facet<Facet>(loc) returns true for any Facet
@@ -5210,7 +4119,7 @@ OutputIterator must be supported.  Table 51 already contains a
 complete list of the ones we need.
        
 
        
 
        341. Vector reallocation and swap
        
-Section: 23.2.4.2  [lib.vector.capacity]  Status: Review  Submitter: Anthony Williams  Date: 27 Sep 2001
        
+Section: 23.2.4.2  [lib.vector.capacity]  Status: Ready  Submitter: Anthony Williams  Date: 27 Sep 2001
        
 
        It is a common idiom to reduce the capacity of a vector by swapping it with
 an empty one:
        
 
        @@ -5272,7 +4181,6 @@ containers.]
        
 swap should be constant time.  The clear intent is that it should just
 do pointer twiddling, and that it should exchange all properties of
 the two vectors, including their reallocation guarantees.
-ay be useful.
 
        
 
        
 
        342. seek and eofbit
        
@@ -5348,64 +4256,9 @@ examined by the user to determine why something failed.
        
 
        [Howard will do a survey to find out if there are any other
 places where we have a problem, where the difference between
 fail() and !good() is important.]
        
-
        
-
        345. type tm in <cwchar>
        
-Section: 21.4  [lib.c.strings]  Status: Ready  Submitter: Clark Nelson  Date: 19 Oct 2001
        
-
        
-C99, and presumably amendment 1 to C90, specify that <wchar.h>
-declares struct tm as an incomplete type. However, table 48 in 21.4  [lib.c.strings] does not mention the type tm as being declared in
-<cwchar>. Is this omission intentional or accidental?
-
        
-
        Proposed resolution:
        
-
        In section 21.4  [lib.c.strings], add "tm" to table 48.
        
-
        
-
        346. Some iterator member functions should be const
        
-Section: 24.1  [lib.iterator.requirements]  Status: Ready  Submitter: Jeremy Siek  Date: 20 Oct 2001
        
-
        Iterator member functions and operators that do not change the state
-of the iterator should be defined as const member functions or as
-functions that take iterators either by const reference or by
-value. The standard does not explicitly state which functions should
-be const.  Since this a fairly common mistake, the following changes
-are suggested to make this explicit.
        
-
-
        The tables almost indicate constness properly through naming: r
-for non-const and a,b for const iterators. The following changes
-make this more explicit and also fix a couple problems.
        
-
        Proposed resolution:
        
-
        In 24.1  [lib.iterator.requirements] Change the first section of p9 from
-"In the following sections, a and b denote values of X..." to
-"In the following sections, a and b denote values of type const X...".
        
-
-
        In Table 73, change
        
-
        -    a->m   U&         ...
-
        
-
-
        to
        
-
-
        -    a->m   const U&   ...
-    r->m   U&         ...
-
        
-
-
        In Table 73 expression column, change
        
-
-
        -    *a = t
-
        
-
-
        to
        
-
-
        -    *r = t
-
        
-
-
        [Redmond: The container requirements should be reviewed to see if
-the same problem appears there.]
        
-
 
        
 
        347. locale::category and bitmask requirements
        
-Section: 22.1.1.1.1  [lib.locale.category]  Status: New  Submitter: P.J. Plauger, Nathan Myers  Date: 23 Oct 2001
        
+Section: 22.1.1.1.1  [lib.locale.category]  Status: Open  Submitter: P.J. Plauger, Nathan Myers  Date: 23 Oct 2001
        
 
        
 In 22.1.1.1.1  [lib.locale.category] paragraph 1, the category members
 are described as bitmask elements.  In fact, the bitmask requirements
@@ -5485,9 +4338,11 @@ of the other enumerated values; implementations may add extra categories.]
 
        
 
 
+
        [Curaçao: need input from locale experts.]
        
+
 
        
 
        348. Minor issue with std::pair operator<
        
-Section: 20.2.2  [lib.pairs]  Status: New  Submitter: Andy Sawyer  Date: 23 Oct 2001
        
+Section: 20.2.2  [lib.pairs]  Status: Open  Submitter: Andy Sawyer  Date: 23 Oct 2001
        
 
        
 The current wording of 20.2.2 [lib.pairs] p6 precludes the use of
 operator< on any pair type which contains a pointer.
@@ -5504,9 +4359,18 @@ operator< on any pair type which contains a pointer.
              (!std::less<T1>()( y.first, x.first) && 
              std::less<T2>()( x.second, y.second ) )
 
        
+
+
        [Curaçao: LWG leaning toward NAD.  In favor of the PR is
+that it removes a trap for users.  Concerns: 1) will break some
+small amount of existing code (which define less and operator <
+with different behavior), 2) don't have any indication of rationale
+for current design (and unwilling to change without knowing
+rationale), 3) consistency; pairs of ptrs would behave differenly from
+individual pointers.]
        
+
 
        
 
        349. Minor typographical error in ostream_iterator
        
-Section: 24.5.2  [lib.ostream.iterator]  Status: New  Submitter: Andy Sawyer  Date: 24 Oct 2001
        
+Section: 24.5.2  [lib.ostream.iterator]  Status: Ready  Submitter: Andy Sawyer  Date: 24 Oct 2001
        
 
        24.5.2 [lib.ostream.iterator] states:
        
 
             [...]
@@ -5525,7 +4389,7 @@ In 24.5.2  [lib.ostream.iterat
 
        
 
        
 
        350. allocator<>::address
        
-Section: 20.4.1.1  [lib.allocator.members], 20.1.5  [lib.allocator.requirements], 17.4.1.1  [lib.contents]  Status: New  Submitter: Nathan Myers  Date: 25 Oct 2001
        
+Section: 20.4.1.1  [lib.allocator.members], 20.1.5  [lib.allocator.requirements], 17.4.1.1  [lib.contents]  Status: Open  Submitter: Nathan Myers  Date: 25 Oct 2001
        
 
        See c++std-lib-9006 and c++std-lib-9007.  This issue is taken
 verbatim from -9007.
        
 
@@ -5550,6 +4414,14 @@ no semantics at all for member address(), and allocator<>::address is
 defined in terms of unadorned operator &.
 
        
 
+
        [Curaçao: The LWG believes both examples are ill-formed. 
+The contained type is required to be CopyConstructible (20.1.3), and
+that includes the requirement that &t return the usual types and
+values. Since the CopyConstructible requirements appear to have been
+written to deal with the concerns of this issue, the LWG feels it is
+NAD unless someone can come up with a well-formed example exhibiting a
+problem.]
        
+
 
        Proposed resolution:
        
 
        
 In 20.4.1.1, Change the definition of allocator<>::address from:
        
@@ -5581,6 +4453,9 @@ a.address(s) lines, respectively:
  operator& may be overloaded.
  
 
+
        [Curaçao: If the issues isn't NAD, suggest changing "if not
+overloaded" to "ignoring all overloads".]
        
+
 
        Rationale:
        
 
        The obvious implementations for std::allocator<>::address are
        
 
        @@ -5598,6 +4473,816 @@ but to define them formally in terms of reinterpret_cast<> seems
 to introduce semantic difficulties best avoided.  Using a.address()
 should not introduce unspecified or implementation-defined semantics
 into a user program.
        
+
        
+
        352. missing fpos requirements
        
+Section: 21.1.2  [lib.char.traits.typedefs]  Status: Open  Submitter: Martin Sebor  Date: 2 Dec 2001
        
+
        
+(1)
+There are no requirements on the stateT template parameter of
+fpos listed in 27.4.3. The interface appears to require that
+the type be at least Assignable and CopyConstructible (27.4.3.1, p1),
+and I think also DefaultConstructible (to implement the operations in
+Table 88).
+
        
+
        
+21.1.2, p3, however, only requires that
+char_traits<charT>::state_type meet the requirements of
+CopyConstructible types.
+
        
+
        
+(2)
+Additionally, the stateT template argument has no
+corresponding typedef in fpos which might make it difficult to use in
+generic code.
+
        
+
        Proposed resolution:
        
+
        
+Modify 21.1.2, p4 from
+
        
+
        
+    Requires: state_type shall meet the requirements of
+              CopyConstructible types (20.1.3).
+
        
+
        
+    Requires: state_type shall meet the requirements of Assignable
+              (23.1, p4), CopyConstructible (20.1.3), and
+              DefaultConstructible  (20.1.4) types.
+
        
+
        
+Add to the definition of the fpos class template the following member:
+
        
+
        +    typedef stateT state_type;
+
        
+
        
+and add to 27.4.3.1 a paragraph with the following text:
+
        
+
        +    typedef stateT state_type;
+
        
+
        
+    Requires: state_type shall meet the requirements of
+              Assignable (23.1, p4), CopyConstructible (20.1.3), and
+              DefaultConstructible (20.1.4) types.
+
        
+
+
        [Curaçao: The LWG feels this is two issues, as indicated
+above. The first is a defect; more I/O experts need to review
+the PR. The second is questionable; who would use it? Unless
+motivation is provided, the second should be considered NAD.]
        
+
+
        
+
        354. Associative container lower/upper bound requirements
        
+Section: 23.1.2  [lib.associative.reqmts]  Status: Ready  Submitter: Hans Aberg  Date: 17 Dec 2001
        
+
        
+Discussions in the thread "Associative container lower/upper bound
+requirements" on comp.std.c++ suggests that there is a defect in the
+C++ standard, Table 69 of section 23.1.2, "Associative containers",
+[lib.associative.reqmts].  It currently says:
        
+
+
        
+
        
+a.find(k): returns an iterator pointing to an element with the key equivalent to
+k, or a.end() if such an element is not found.
+
        
+
+
        
+a.lower_bound(k): returns an iterator pointing to the first element with
+key not less than k.
+
        
+
+
        
+a.upper_bound(k): returns an iterator pointing to the first element with
+key greater than k.
+
        
+
        
+
+
        
+We have "or a.end() if such an element is not found" for
+find, but not for upper_bound or
+lower_bound.  As the text stands, one would be forced to
+insert a new element into the container and return an iterator to that
+in case the sought iterator does not exist, which does not seem to be
+the intention (and not possible with the "const" versions).
+
        
+
        Proposed resolution:
        
+
+
        Change Table 69 of section 23.1.2  [lib.associative.reqmts] indicated entries
+to:
        
+
+
        
+
        
+a.lower_bound(k): returns an iterator pointing to the first element with
+key not less than k, or a.end() if such an element is not found.
+
        
+
+
        
+a.upper_bound(k): returns an iterator pointing to the first element with
+key greater than k, or a.end() if such an element is not found.
+
        
+
        
+
+
        [Curaçao: LWG reviewed PR.]
        
+
+
        
+
        355. Operational semantics for a.back()
        
+Section: 23.1.1  [lib.sequence.reqmts]  Status: Review  Submitter: Yaroslav Mironov  Date: 23 Jan 2002
        
+
+
        Table 68 "Optional Sequence Operations" in 23.1.1/12
+specifies operational semantics for "a.back()" as
+"*--a.end()", which may be ill-formed [because calling
+operator-- on a temporary (the return) of a built-in type is
+ill-formed], provided a.end() returns a simple pointer rvalue
+(this is almost always the case for std::vector::end(), for
+example). Thus, the specification is not only incorrect, it
+demonstrates a dangerous construct: "--a.end()" may
+successfully compile and run as intended, but after changing the type
+of the container or the mode of compilation it may produce
+compile-time error. 
        
+
+
        Proposed resolution:
        
+
        Change the specification in table 68 "Optional Sequence
+Operations" in 23.1.1/12 for "a.back()" from
        
+
+
+
        
+*--a.end()
+
        
+
+
        to
        
+
+
        
+  
        *a.rbegin()
        
+
        
+
+
        and the specification for "a.pop_back()" from
        
+
+
        
+a.erase(--a.end())
+
        
+
+
        to
        
+
+
        
+  
        a.erase(rbegin())
        
+
        
+
+
        [Curaçao: LWG changed PR from "{ X::iterator tmp =
+a.end(); return *--tmp; }" to "*a.rbegin()", and from
+"{ X::iterator tmp = a.end(); a.erase(--tmp); }" to
+"a.erase(rbegin())".]
        
+
+
        [There is a second possible defect; table 68 "Optional
+Sequence Operations" in the "Operational Semantics"
+column uses operations present only in the "Reversible
+Container" requirements, yet there is no stated dependency
+between these separate requirements tables. Ask in Santa Cruz if the
+LWG would like a new issue opened.]
        
+
+
        
+
        356. Meaning of ctype_base::mask enumerators
        
+Section: 22.2.1  [lib.category.ctype]  Status: New  Submitter: Matt Austern  Date: 23 Jan 2002
        
+
+
        What should the following program print?
        
+
+
        +  #include <locale>
+  #include <iostream>
+
+  class my_ctype : public std::ctype<char>
+  {
+    typedef std::ctype<char> base;
+  public:
+    my_ctype(std::size_t refs = 0) : base(my_table, false, refs)
+    {
+      std::copy(base::classic_table(), base::classic_table() + base::table_size,
+                my_table);
+      my_table[(unsigned char) '_'] = (base::mask) (base::print | base::space);
+    }
+  private:
+    mask my_table[base::table_size];
+  };
+
+  int main()
+  {
+    my_ctype ct;
+    std::cout << "isspace: " << ct.is(std::ctype_base::space, '_') << "    "
+              << "isalpha: " << ct.is(std::ctype_base::alpha, '_') << std::endl;
+  }
+
        
+
+
        The goal is to create a facet where '_' is treated as whitespace.
        
+
+
        On gcc 3.0, this program prints "isspace: 1 isalpha: 0".  On
+Microsoft C++ it prints "isspace: 1 isalpha: 1".
        
+
+
        
+I believe that both implementations are legal, and the standard does not
+give enough guidance for users to be able to use std::ctype's
+protected interface portably.
        
+
+
        
+The above program assumes that ctype_base::mask enumerators like
+space and print are disjoint, and that the way to
+say that a character is both a space and a printing character is to or
+those two enumerators together.  This is suggested by the "exposition
+only" values in 22.2.1  [lib.category.ctype], but it is nowhere specified in
+normative text.  An alternative interpretation is that the more
+specific categories subsume the less specific.  The above program
+gives the results it does on the Microsoft compiler because, on that
+compiler, print has all the bits set for each specific
+printing character class.
+
        
+
+
        From the point of view of std::ctype's public interface, there's no
+important difference between these two techniques.  From the point of
+view of the protected interface, there is.  If I'm defining a facet
+that inherits from std::ctype<char>, I'm the one who defines the
+value that table()['a'] returns.  I need to know what combination of
+mask values I should use.  This isn't so very esoteric: it's exactly
+why std::ctype has a protected interface.  If we care about users
+being able to write their own ctype facets, we have to give them a
+portable way to do it.
+
        
+
+
        
+Related reflector messages:
+lib-9224, lib-9226, lib-9229, lib-9270, lib-9272, lib-9273, lib-9274,
+lib-9277, lib-9279.
+
        
+
+
        Issue 339 is related, but not identical.  The
+proposed resolution if issue 339 says that
+ctype_base::mask must be a bitmask type. It does not say that the
+ctype_base::mask elements are bitmask elements, so it doesn't
+directly affect this issue.
        
+
+
        Proposed resolution:
        
+
        Informally, we have three choices:
         
+
          
+
        1. Require that the enumerators are disjoint (except for alnum and
+graph)
          2. 
+
        2. Require that the enumerators are not disjoint, and specify which
+of them subsume which others.  (e.g. mandate that lower includes alpha
+and print)
          3. 
+
        3. Explicitly leave this unspecified, which the result that the above
+program is not portable.
          4. 
+
        
+
+
        Either of the first two options is just as good from the standpoint
+of portability.  Either one will require some implementations to
+change.
        
+
+
        
+
        357. <cmath> float functions cannot return HUGE_VAL
        
+Section: 26.5  [lib.c.math]  Status: Open  Submitter: Ray Lischner  Date: 26 Feb 2002
        
+
        
+The float versions of the math functions have no meaningful value to return 
+for a range error. The long double versions have a value they can return, 
+but it isn't necessarily the most reasonable value.
+
        
+
+
        
+Section 26.5 [lib.c.math], paragraph 5, says that C++ "adds float and long 
+double overloaded versions of these functions, with the same semantics," 
+referring to the math functions from the C90 standard.
+
        
+
+
        
+The C90 standard, in section 7.5.1, paragraph 3, says that functions return 
+"the value of the macro HUGE_VAL" when they encounter a range error. 
+Section 7.5, paragraph 2, defines HUGE_VAL as a macro that "expands to a 
+positive double expression, not necessarily representable as a float."
+
        
+
+
        
+Therefore, the float versions of the math functions have no way to
+signal a range error. [Curaçao: The LWG notes that this isn't
+strictly correct, since errno is set.] The semantics require that they
+return HUGE_VAL, but they cannot because HUGE_VAL might not be
+representable as a float.
+
        
+
+
        
+The problem with long double functions is less severe because HUGE_VAL is 
+representable as a long double. On the other hand, it might not be a "huge" 
+long double value, and might fall well within the range of normal return 
+values for a long double function. Therefore, it does not make sense for a 
+long double function to return a double (HUGE_VAL) for a range error.
+
        
+
        Proposed resolution:
        
+
        Curaçao: C99 was faced with a similar problem, which they fixed by
+adding HUGE_VALF and HUGE_VALL in addition to HUGE_VAL.
        
+
+
        C++ must also fix, but it should be done in the context of the
+general C99 based changes to C++, not via DR. Thus the LWG in Curaçao
+felt the resolution should be NAD, FUTURE, but the issue is being held
+open for one more meeting to ensure LWG members not present during the
+discussion concur.
        
+
        
+
        358. interpreting thousands_sep after a decimal_point
+
        
+Section: 22.2.2.1.2  [lib.facet.num.get.virtuals]  Status: New  Submitter: Martin Sebor  Date: 12 Mar 2002
        
+
        
+I don't think thousands_sep is being treated correctly after
+decimal_point has been seen. Since grouping applies only to the
+integral part of the number, the first such occurrence should, IMO,
+terminate Stage 2. (If it does not terminate it, then 22.2.2.1.2, p12
+and 22.2.3.1.2, p3 need to explain how thousands_sep is to be
+interpreted in the fractional part of a number.)
+
        
+
+
        
+The easiest change I can think of that resolves this issue would be
+something like below.
+
        
+
        Proposed resolution:
        
+
        
+Change the first sentence of 22.2.2.1.2, p9 from
+
        
+
+
        
+    If discard is true then the position of the character is
+    remembered, but the character is otherwise ignored. If it is not
+    discarded, then a check is made to determine if c is allowed as
+    the next character of an input field of the conversion specifier
+    returned by stage 1. If so it is accumulated.
+
        
+
+
        to
        
+
+
        
+    If discard is true, then if '.' has not yet been
+    accumulated, then the position of the character is remembered, but
+    the character is otherwise ignored. Otherwise, if '.' has
+    already been accumulated, the character is discarded and Stage 2
+     terminates. ...
+
        
+
+
        
+
        359. num_put<>::do_put (..., bool) undocumented
        
+Section: 22.2.2.2.1  [lib.facet.num.put.members]  Status: New  Submitter: Martin Sebor  Date: 12 Mar 2002
        
+
        22.2.2.2.1, p1:
        
+
+    
        +    iter_type put (iter_type out, ios_base& str, char_type fill,
+                   bool val) const;
+    ...
+
+    1   Returns: do_put (out, str, fill, val).
+    
        
+
+
        AFAICS, the behavior of do_put (..., bool) is not documented anywhere,
+however, 22.2.2.2.2, p23:
        
+
+
        
+
        +iter_type put (iter_type out, ios_base& str, char_type fill,
+               bool val) const;
+
        
+
+
+        Effects: If (str.flags() & ios_base::boolalpha) == 0 then do
+             out = do_put(out, str, fill, (int)val)
+           Otherwise do
+
        +             string_type s =
+                 val ? use_facet<ctype<charT> >(loc).truename()
+                     : use_facet<ctype<charT> >(loc).falsename();
+
        
+           and then insert the characters of s into out. out.
+
        
+
+
        
+This means that the bool overload of do_put() will never be called,
+which contradicts the first paragraph. Perhaps the declaration
+should read do_put(), and not put()?
+
        
+
+
        
+Note also that there is no Returns clause for this function, which
+should probably be corrected, just as should the second occurrence
+of "out." in the text.
+
        
+
+
        
+I think the least invasive change to fix it would be something like
+the following:
+
        
+
        Proposed resolution:
        
+
        
+In 22.2.2.2.2, p23, make the following changes
+
        
+
+
        
+     Replace put() with do_put() in the declaration
+     of the member function.
+
        
+
+
        
+    Change the Effects clause to a Returns clause (to
+    avoid the requirement to call do_put(..., int) from 
+    do_put (..., bool))
+    like so:
+
        
+
+
        
+    23   Returns: If (str.flags() &
+         ios_base::boolalpha) == 0 then
+         do_put (out, str, fill, (int)val)
+         Otherwise the function obtains a string s as if by
+
        +             string_type s =
+                val ? use_facet<ctype<charT> >(loc).truename()
+                    : use_facet<ctype<charT> >(loc).falsename();
+
        
+         and then inserts each character c of s into out via
+           *out++ = c
+         and returns out.
+
        
+
+
        
+
        360. locale mandates inefficient implementation
        
+Section: 22.1.1  [lib.locale]  Status: New  Submitter: Martin Sebor  Date: 12 Mar 2002
        
+
        
+22.1.1, p7 (copied below) allows iostream formatters and extractors
+to make assumptions about the values returned from facet members.
+However, such assumptions are apparently not guaranteed to hold
+in other cases (e.g., when the facet members are being called directly
+rather than as a result of iostream calls, or between successive
+calls to the same iostream functions with no interevening calls to
+imbue(), or even when the facet member functions are called
+from other member functions of other facets). This restriction
+prevents locale from being implemented efficiently.
+
        
+
        Proposed resolution:
        
+
        Change the first sentence in 22.1.1, p7 from
        
+
        
+    In successive calls to a locale facet member function during
+    a call to an iostream inserter or extractor or a streambuf member
+    function, the returned result shall be identical. [Note: This
+    implies that such results may safely be reused without calling
+    the locale facet member function again, and that member functions
+    of iostream classes cannot safely call imbue()
+    themselves, except as specified elsewhere. --end note]
+
        
+
+
        to
        
+
+
        
+    In successive calls to a locale facet member function on a facet
+    object installed in the same locale, the returned result shall be
+    identical. ...
+
        
+
+
        
+
        361. num_get<>::do_get (..., void*&) checks grouping
        
+Section: 22.2.2.2.2  [lib.facet.num.put.virtuals]  Status: New  Submitter: Martin Sebor  Date: 12 Mar 2002
        
+
        
+22.2.2.2.2, p12 specifies that thousands_sep is to be inserted only
+for integral types (issue 282 suggests that this should be done for
+all arithmetic types).
+
        
+
+
        
+22.2.2.1.2, p12 requires that grouping be checked for all extractors
+including that for void*.
+
        
+
+
        
+I don't think that's right. void* values should not be checked for
+grouping, should they? (Although if they should, then num_put needs
+to write them out, otherwise their extraction will fail.)
+
        
+
        Proposed resolution:
        
+
        
+Change the first sentence of 22.2.2.2.2, p12 from
+
        
+
        
+    Digit grouping is checked. That is, the positions of discarded
+    separators is examined for consistency with
+    use_facet<numpunct<charT> >(loc).grouping().
+    If they are not consistent then ios_base::failbit is assigned
+    to err.
+
        
+
+
        to
        
+
        
+    Except for conversions to void*, digit grouping is checked...
+
        
+
+
        
+
        362. bind1st/bind2nd type safety
        
+Section: 20.3.6.2  [lib.bind.1st]  Status: New  Submitter: Andrew Demkin  Date: 26 Apr 2002
        
+
        
+The definition of bind1st() (20.3.6.2  [lib.bind.1st]) 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
+type 'pointer to U' when U does not derive from T:
+
        
+
        +   foo(T*, int);
+
+   struct T {};
+   struct U {};
+
+   U u;
+
+   int* p;
+   int* q;
+
+   for_each(p, q, bind1st(ptr_fun(foo), &u));    // unsafe binding
+
        
+
+
        
+The definition of bind1st() includes a functional-style conversion to
+map its argument to the expected argument type of the bound function
+(see below):
+
        
+
        +  typename Operation::first_argument_type(x)
+
        
+
+
        
+A functional-style conversion (5.2.3  [expr.type.conv]) is defined to be
+semantically equivalent to an explicit cast expression (5.4  [expr.cast]), which may (according to 5.4, paragraph 5) be interpreted
+as a reinterpret_cast, thus masking the error.
+
        
+
+
        The problem and proposed change also apply to 20.3.6.4  [lib.bind.2nd].
        
+
        Proposed resolution:
        
+
        
+The simplest and most localized change to prevent such errors is to
+require bind1st() use a static_cast expression rather than the
+functional-style conversion; that is, have bind1st() return:
+
        
+
        +   binder1st<Operation>( op,
+     static_cast<typename Operation::first_argument_type>(x)).
+
        
+
+
        
+A more agressive solution is to change the semantics of
+functional-style conversions to not permit a reinterpret_cast. For
+contexts that require the semantics of reinterpret_cast, the language
+may want to require the use of an explicit cast expression such as
+'(T) x' or 'reinterpret_cast<T>(x)' and limit the behavior of
+the functional notation to match statically-checked and standard
+conversions (as defined by 5.2.9 and 4.10, etc.).  Although changing
+the semantics of functional-style conversions may seem drastic and
+does have language-wide ramifications, it has the benefit of better
+unifying the conversion rules for user defined types and built-in
+types, which can be especially important for generic template
+programming.
+
        
+
        
+
        363. Missing exception specification in 27.4.2.1.1
        
+Section: 27.4.2.1.1  [lib.ios::failure]  Status: New  Submitter: Walter Brown  Date: 20 May 2002
        
+
        
+The destructor of ios_base::failure should have an empty throw
+specification, because the destructor of its base class, exception, is
+declared in this way.
+
        
+
        Proposed resolution:
        
+
        Change the destructor to
        
+
        +  virtual ~failure() throw();
+
        
+
        
+
        364. Inconsistent wording in 27.5.2.4.2
        
+Section: 27.5.2.4.2  [lib.streambuf.virt.buffer]  Status: New  Submitter: Walter Brown  Date: 10 May 2002
        
+
        
+27.5.2.4.2  [lib.streambuf.virt.buffer] paragraph 1 is inconsistent with the Effects
+clause for seekoff.
+
        
+
        Proposed resolution:
        
+
        
+Make this paragraph, the Effects clause for setbuf, consistent in wording
+with the Effects clause for seekoff in paragraph 3 by amending paragraph 1
+to indicate the purpose of setbuf:
+
        
+
+
        Original text:
        
+
+
        
+1 Effects: Performs an operation that is defined separately for each
+class derived from basic_streambuf in this clause (27.7.1.3, 27.8.1.4).
+
        
+
+
        Proposed text:
        
+
+
        
+1 Effects: Influences stream buffering in a way that is defined separately
+for each class derived from basic_streambuf in this clause
+(27.7.1.3, 27.8.1.4).
+
        
+
+
        
+
        365. Lack of const-qualification in clause 27
        
+Section: 27  [lib.input.output]  Status: New  Submitter: Walter Brown  Date: 10 May 2002
        
+
        
+None of the following member functions are declared const, but we
+believe each should be. See document N1360 for details and rationale.
+
        
+
        Proposed resolution:
        
+
        In 27.5.2 and 27.5.2.2.3
        
+
        Replace
        
+
        +  streamsize in_avail();
+
        
+
        with
        
+
        +  streamsize in_avail() const;
+
        
+
+
        In 27.5.2 and 27.5.2.4.3, and  27.8.1.1 and 27.8.1.4
        
+
        Replace
        
+
        +  virtual streamsize showmanyc();
+
        
+
        with
        
+
        +  virtual streamsize showmanyc() const;
+
        
+
+
        In 27.6.1.1 and 27.6.1.3
        
+
        Replace
        
+
        +  pos_type tellg();
+
        
+
        with
        
+
        +  pos_type tellg() const;
+
        
+
+
        This requires additional change, because paragraph 37 describes the
+return value in terms of calls to non-const member functions. Either of
+the two following solutions would allow tellg to be declared const.
        
+
+
        Option 1: Implementers may cast away const-ness, to allow calling the
+non-const rdbuf.
        
+
        In paragraph 37, replace:
        
+
        +  .... rdbuf()
+  ->pubseekoff(0, cur, in).
+
        
+
        by
        
+
        +  .... const_cast<basic_istream<charT, traits>*>(this)->rdbuf()
+  ->pubseekoff(0, cur, in).
+
        
+
+
        Option 2: Provide const member functions to do the job. The proposals in
+a later section (specifically, the modifications concerning rdbuf
+throughout the iostream library) meet most of this need; we would also
+need the following addition to basic_streambuf:
        
+
+
        
+
        +basic_streambuf<charT,traits>::pos_type
+basic_streambuf<charT,traits>::position(ios_base::openmode mode =
+                                        ios_base::in|ios_base::out)
+                                        const;
+
        
+
        Effects: same as calling basic_streambuf::pubseekoff(0, ios base::cur, mode)
        
+
        
+
+
        In 27.6.2.1 and 27.6.2.4
        
+
        Replace
        
+
        +  pos_type tellp();
+
        
+
        with
        
+
        +  pos_type tell() const;
+
        
+
+
        This requires additional change; see the discussion for tellg() above.
        
+
+
        In 27.8.1.5, 27.8.1.7, 27.8.1.8, 27.8.1.10, 27.8.1.11, and 27.8.1.13
        
+
        Replace
        
+
        +  bool is_open();
+
        
+
        with
        
+
        +  bool is_open() const;
+
        
+
        
+
        366. Excessive const-qualification
        
+Section: 27  [lib.input.output]  Status: New  Submitter: Walter Brown  Date: 10 May 2002
        
+
        
+The following member functions are declared const, yet return non-const
+pointers. We believe they are should be changed, because they allow code
+that may surprise the user. See document N1360 for details and
+rationale.
+
        
+
        Proposed resolution:
        
+
        In 27.4.4 and 27.4.4.2
        
+
        Replace
        
+
        +  basic_ostream<charT,traits>* tie() const;
+
        
+
        with
        
+
        +  basic_ostream<charT,traits>* tie();
+  const basic_ostream<charT,traits>* tie() const;
+
        
+
+
        and replace
        
+
        +  basic_streambuf<charT,traits>* rdbuf() const;
+
        
+
        with
        
+
        +  basic_streambuf<charT,traits>* rdbuf();
+  const basic_streambuf<charT,traits>* rdbuf() const;
+
        
+
+
        In 27.5.2 and 27.5.2.3.1
        
+
        Replace
        
+
        +  char_type* eback() const;
+
        
+
        with
        
+
        +  char_type* eback();
+  const char_type* eback() const;
+
        
+
+
        Replace
        
+
        +  char_type gptr() const;
+
        
+
        with
        
+
        +  char_type* gptr();
+  const char_type* gptr() const;
+
        
+
+
        Replace
        
+
        +  char_type* egptr() const;
+
        
+
        with
        
+
        +  char_type* egptr();
+  const char_type* egptr() const;
+
        
+
+
        In 27.5.2 and 27.5.2.3.2
        
+
        Replace
        
+
        +  char_type* pbase() const;
+
        
+
        with
        
+
        +  char_type* pbase();
+  const char_type* pbase() const;
+
        
+
+
        Replace
        
+
        +  char_type* pptr() const;
+
        
+
        with
        
+
        +  char_type* pptr();
+  const char_type* pptr() const;
+
        
+
+
        Replace
        
+
        +  char_type* epptr() const;
+
        
+
        with
        
+
        +  char_type* epptr();
+  const char_type* epptr() const;
+
        
+
+
        In 27.7.2, 27.7.2.2, 27.7.3 27.7.3.2, 27.7.4, and 27.7.6
        
+
        Replace
        
+
        +  basic_stringbuf<charT,traits,Allocator>* rdbuf() const;
+
        
+
        with
        
+
        +  basic_stringbuf<charT,traits,Allocator>* rdbuf();
+  const basic_stringbuf<charT,traits,Allocator>* rdbuf() const;
+
        
+
+
        In  27.8.1.5, 27.8.1.7, 27.8.1.8, 27.8.1.10, 27.8.1.11, and 27.8.1.13
        
+
        Replace
        
+
        +  basic_filebuf<charT,traits>* rdbuf() const;
+
        
+
        with
        
+
        +  basic_filebuf<charT,traits>* rdbuf();
+  const basic_filebuf<charT,traits>* rdbuf() const;
+
        
 
        ----- End of document -----
        
 
 
diff --git a/libstdc++-v3/docs/html/ext/lwg-defects.html b/libstdc++-v3/docs/html/ext/lwg-defects.html
index bd3af811383..eea548b8db7 100644
--- a/libstdc++-v3/docs/html/ext/lwg-defects.html
+++ b/libstdc++-v3/docs/html/ext/lwg-defects.html
@@ -5,11 +5,11 @@
 
-
+
-
+
@@ -20,7 +20,7 @@
 
        
 
        
 Doc. no.J16/01-0053 = WG21 N1338J16/02-0028 = WG21 N1370
 
        
 
        
 Date:09 Nov 200110 May 2002
 
        
 
        
 Project:Matt Austern <austern@research.att.com>
 
        
 
        
-
        C++ Standard Library Defect Report List (Revision 20)
        
+
        C++ Standard Library Defect Report List (Revision 22)
        
   
        Reference ISO/IEC IS 14882:1998(E)
        
   
        Also see:
        
     
          
@@ -42,6 +42,12 @@
   document.
          
 
          Revision History
          
 
            
+
          • R22: 
+Post-Curaçao mailing.  Added new issues 362-366.
+
            • 
+
          • R21: 
+Pre-Curaçao mailing.  Added new issues 351-361.
+
            • 
 
          • R20: 
 Post-Redmond mailing; reflects actions taken in Redmond.  Added
 new issues 336-350, of which issues 
@@ -49,19 +55,19 @@ new issues 336-3
 not discussed at the meeting.  
 
 All Ready issues were moved to DR status, with the exception of issues
-284, 241, and 267.
+284, 241, and 267.
 
 Noteworthy issues discussed at Redmond include 
 120 202, 226, 233, 
-270, 253, 254, 323.
+270, 253, 254, 323.
 
            • 
 
          • R19: 
 Pre-Redmond mailing.  Added new issues 
-323-335.
+323-335.
 
            • 
 
          • R18: 
 Post-Copenhagen mailing; reflects actions taken in Copenhagen.
-Added new issues 312-317, and discussed
+Added new issues 312-317, and discussed
 new issues 271-314.
 
 Changed status of issues
@@ -80,7 +86,7 @@ Changed status of issues
 238 241 242 250
 259 264 266 267
 271 272 273 275
-281 284 285 286
+281 284 285 286
 288 292 295 297
 298 301 303 306
 307 308 312
@@ -95,8 +101,8 @@ as NAD.
 
            • 
 
          • R17: 
 Pre-Copenhagen mailing.  Converted issues list to XML.  Added proposed
-resolutions for issues 49, 76, 91, 235, 250, 267.
-Added new issues 278-311.
+resolutions for issues 49, 76, 91, 235, 250, 267.
+Added new issues 278-311.
 
            • 
 
          • R16:  
 post-Toronto mailing; reflects actions taken in Toronto. Added new
@@ -142,7 +148,7 @@ of issue 29.  Add further rationale to issue
 post-Kona mailing: Updated to reflect LWG and full committee actions
 in Kona (99-0048/N1224). Note changed resolution of issues
 4 and 38. Added issues 196
-to 198. Closed issues list split into "defects" and
+to 198. Closed issues list split into "defects" and
 "closed" documents.  Changed the proposed resolution of issue
 4 to NAD, and changed the wording of proposed resolution
 of issue 38.
@@ -2229,6 +2235,119 @@ change the stateT argument type on both member
   max elements.
            
 
 
            
+
            76. Can a codecvt facet always convert one internal character at a time?
            
+Section: 22.2.1.5  [lib.locale.codecvt]  Status: DR  Submitter: Matt Austern  Date: 25 Sep 1998
            
+
            This issue concerns the requirements on classes derived from
+codecvt, including user-defined classes. What are the
+restrictions on the conversion from external characters
+(e.g. char) to internal characters (e.g. wchar_t)?
+Or, alternatively, what assumptions about codecvt facets can
+the I/O library make? 
            
+
+
            The question is whether it's possible to convert from internal
+characters to external characters one internal character at a time,
+and whether, given a valid sequence of external characters, it's
+possible to pick off internal characters one at a time. Or, to put it
+differently: given a sequence of external characters and the
+corresponding sequence of internal characters, does a position in the
+internal sequence correspond to some position in the external
+sequence? 
            
+
+
            To make this concrete, suppose that [first, last) is a
+sequence of M external characters and that [ifirst,
+ilast) is the corresponding sequence of N internal
+characters, where N > 1. That is, my_encoding.in(),
+applied to [first, last), yields [ifirst,
+ilast). Now the question: does there necessarily exist a
+subsequence of external characters, [first, last_1), such
+that the corresponding sequence of internal characters is the single
+character *ifirst?
+
            
+
+
            (What a "no" answer would mean is that
+my_encoding translates sequences only as blocks. There's a
+sequence of M external characters that maps to a sequence of
+N internal characters, but that external sequence has no
+subsequence that maps to N-1 internal characters.) 
            
+
+
            Some of the wording in the standard, such as the description of
+codecvt::do_max_length (22.2.1.5.2  [lib.locale.codecvt.virtuals],
+paragraph 11) and basic_filebuf::underflow (27.8.1.4  [lib.filebuf.virtuals], 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
+way or the other. 
            
+
+
            This issue seems (and is) quite technical, but it is important if
+we expect users to provide their own encoding facets. This is an area
+where the standard library calls user-supplied code, so a well-defined
+set of requirements for the user-supplied code is crucial. Users must
+be aware of the assumptions that the library makes. This issue affects
+positioning operations on basic_filebuf, unbuffered input,
+and several of codecvt's member functions. 
            
+
            Proposed resolution:
            
+
            Add the following text as a new paragraph, following 22.2.1.5.2  [lib.locale.codecvt.virtuals] paragraph 2:
            
+
+
            
+
            A codecvt facet that is used by basic_filebuf
+(27.8  [lib.file.streams]) must have the property that if
            
+
            +    do_out(state, from, from_end, from_next, to, to_lim, to_next)
+
            
+would return ok, where from != from_end, then 
+
            +    do_out(state, from, from + 1, from_next, to, to_end, to_next)
+
            
+must also return ok, and that if
+
            +    do_in(state, from, from_end, from_next, to, to_lim, to_next)
+
            
+would return ok, where to != to_lim, then
+
            +    do_in(state, from, from_end, from_next, to, to + 1, to_next)
+
            
+
            must also return ok.  [Footnote: Informally, this
+means that basic_filebuf assumes that the mapping from
+internal to external characters is 1 to N: a codecvt that is
+used by basic_filebuf must be able to translate characters
+one internal character at a time.  --End Footnote]
            
+
            
+
+
            [Redmond: Minor change in proposed resolution.  Original
+proposed resolution talked about "success", with a parenthetical
+comment that success meant returning ok.  New wording
+removes all talk about "success", and just talks about the
+return value.]
            
+
+
            Rationale:
            
+
+  
            The proposed resoluion says that conversions can be performed one
+  internal character at a time.  This rules out some encodings that
+  would otherwise be legal.  The alternative answer would mean there
+  would be some internal positions that do not correspond to any
+  external file position.
            
+  
            
+  An example of an encoding that this rules out is one where the
+  internT and externT are of the same type, and
+  where the internal sequence c1 c2 corresponds to the
+  external sequence c2 c1.
+  
            
+  
            It was generally agreed that basic_filebuf relies
+  on this property: it was designed under the assumption that
+  the external-to-internal mapping is N-to-1, and it is not clear
+  that basic_filebuf is implementable without that 
+  restriction.
+  
            
+  
            
+  The proposed resolution is expressed as a restriction on
+  codecvt when used by basic_filebuf, rather
+  than a blanket restriction on all codecvt facets,
+  because basic_filebuf is the only other part of the 
+  library that uses codecvt.  If a user wants to define
+  a codecvt facet that implements a more general N-to-M
+  mapping, there is no reason to prohibit it, so long as the user
+  does not expect basic_filebuf to be able to use it.
+  
            
+
            
 
            78. Typo: event_call_back
            
 Section: 27.4.2  [lib.ios.base]  Status: DR  Submitter: Nico Josuttis  Date: 29 Sep 1998
            
 
            typo: event_call_back should be event_callback   
            
@@ -3210,7 +3329,7 @@ with:
            
 
            Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they
 say:
            
 
            
-— xpos <= pos and pos < size();
+— xpos <= pos and pos < size();
 
            
 
 
            Surely the document meant to say ``xpos < size()'' in both places.
            
@@ -3220,11 +3339,11 @@ proposed resolution.]
            
 
            Proposed resolution:
            
 
            Change Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1, the line which says:
            
 
            
-— xpos <= pos and pos < size();
            
+— xpos <= pos and pos < size();
            
 
            
             to:
            
 
            
-            — xpos <= pos and xpos < size();
+            — xpos <= pos and xpos < size();
 
            
 
            
 
            142. lexicographical_compare complexity wrong
            
@@ -3989,10 +4108,10 @@ proposed resolution passed their test suites.
            
 omit the  std:: namespace qualification.
             
            For
 example, 17.4.3.4  [lib.replacement.functions] paragraph 2:
            
 
            
-
            — operator new(size_t)
-— operator new(size_t, const std::nothrow_t&)
-— operator new[](size_t)
-— operator new[](size_t, const std::nothrow_t&)
            
+
            — operator new(size_t)
+— operator new(size_t, const std::nothrow_t&)
+— operator new[](size_t)
+— operator new[](size_t, const std::nothrow_t&)
            
 
            
 
            Proposed resolution:
            
 
               In 17.4.3.4  [lib.replacement.functions] paragraph 2: replace:
            
@@ -4521,6 +4640,132 @@ returns traits::eof(), the function calls
 ios_base::failure).
 
            
 
+
            
+
            198. Validity of pointers and references unspecified after iterator destruction
            
+Section: 24.1  [lib.iterator.requirements]  Status: DR  Submitter: Beman Dawes  Date: 3 Nov 1999
            
+
            
+Is a pointer or reference obtained from an iterator still valid after
+destruction of the iterator?
+
            
+
            
+Is a pointer or reference obtained from an iterator still valid after the value
+of the iterator changes?
+
            
+
            
+
            +#include <iostream>
+#include <vector>
+#include <iterator>
+
+int main()
+{
+    typedef std::vector<int> vec_t;
+    vec_t v;
+    v.push_back( 1 );
+
+    // Is a pointer or reference obtained from an iterator still
+    // valid after destruction of the iterator?
+    int * p = &*v.begin();
+    std::cout << *p << '\n';  // OK?
+
+    // Is a pointer or reference obtained from an iterator still
+    // valid after the value of the iterator changes?
+    vec_t::iterator iter( v.begin() );
+    p = &*iter++;
+    std::cout << *p << '\n';  // OK?
+
+    return 0;
+}
+
            
+
            
+
+
            The standard doesn't appear to directly address these
+questions. The standard needs to be clarified. At least two real-world
+cases have been reported where library implementors wasted
+considerable effort because of the lack of clarity in the
+standard. The question is important because requiring pointers and
+references to remain valid has the effect for practical purposes of
+prohibiting iterators from pointing to cached rather than actual
+elements of containers.
            
+
+
            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  [lib.reverse.iter.op.star], which returns a reference, defines
+effects:
            
+
+
            
+  
            Iterator tmp = current;
+return *--tmp;
            
+
            
+
            The definition of reverse_iterator::operator->(), 24.4.1.3.4  [lib.reverse.iter.opref], which returns a pointer, defines effects:
            
+
            
+  
            return &(operator*());
            
+
            
+
+
            Because the standard itself assumes pointers and references remain
+valid after iterator destruction or change, the standard should say so
+explicitly. This will also reduce the chance of user code breaking
+unexpectedly when porting to a different standard library
+implementation.
            
+
            Proposed resolution:
            
+
            Add a new paragraph to 24.1  [lib.iterator.requirements]:
            
+
            
+Destruction of an iterator may invalidate pointers and references
+previously obtained from that iterator.
+
            
+
+
            Replace paragraph 1 of 24.4.1.3.3  [lib.reverse.iter.op.star] with:
            
+
+
            
+
            Effects:
            
+
            +  this->tmp = current;
+  --this->tmp;
+  return *this->tmp;
+
            
+
+
            
+[Note: This operation must use an auxiliary member variable,
+rather than a temporary variable, to avoid returning a reference that
+persists beyond the lifetime of its associated iterator.  (See
+24.1  [lib.iterator.requirements].)  The name of this member variable is shown for
+exposition only.  --end note]
+
            
+
            
+
+
            [Post-Tokyo: The issue has been reformulated purely
+in terms of iterators.]
            
+
+
            [Pre-Toronto: Steve Cleary pointed out the no-invalidation
+assumption by reverse_iterator. The issue and proposed resolution was
+reformulated yet again to reflect this reality.]
            
+
+
            [Copenhagen: Steve Cleary pointed out that reverse_iterator
+assumes its underlying iterator has persistent pointers and
+references.  Andy Koenig pointed out that it is possible to rewrite
+reverse_iterator so that it no longer makes such an assupmption.
+However, this issue is related to issue 299.  If we
+decide it is intentional that p[n] may return by value
+instead of reference when p is a Random Access Iterator,
+other changes in reverse_iterator will be necessary.]
            
+
            Rationale:
            
+
            This issue has been discussed extensively.  Note that it is
+not an issue about the behavior of predefined iterators.  It is
+asking whether or not user-defined iterators are permitted to have
+transient pointers and references.  Several people presented examples
+of useful user-defined iterators that have such a property; examples
+include a B-tree iterator, and an "iota iterator" that doesn't point
+to memory.  Library implementors already seem to be able to cope with
+such iterators: they take pains to avoid forming references to memory
+that gets iterated past.  The only place where this is a problem is
+reverse_iterator, so this issue changes
+reverse_iterator to make it work.
            
+
+
            This resolution does not weaken any guarantees provided by
+predefined iterators like list<int>::iterator.
+Clause 23 should be reviewed to make sure that guarantees for
+predefined iterators are as strong as users expect.
            
+
 
            
 
            199. What does allocate(0) return?
            
 Section: 20.1.5  [lib.allocator.requirements]  Status: DR  Submitter: Matt Austern  Date: 19 Nov 1999
            
@@ -5217,6 +5462,89 @@ defined to be basic_string<cT>().
            
 
            We could fix 27.7.1.1 paragraph 4, but there would be no point.  If
 we fixed it, it would say just the same thing as text that's already
 in the standard.
            
+
            
+
            239. Complexity of unique() and/or unique_copy incorrect
            
+Section: 25.2.8  [lib.alg.unique]  Status: DR  Submitter: Angelika Langer  Date: May 15 2000
            
+
            The complexity of unique and unique_copy are inconsistent with each
+other and inconsistent with the implementations.  The standard
+specifies:
            
+
+
            for unique():
            
+
+
            -3- Complexity: If the range (last - first) is not empty, exactly
+(last - first) - 1 applications of the corresponding predicate, otherwise
+no applications of the predicate.
            
+
+
            for unique_copy():
            
+
+
            -7- Complexity: Exactly last - first applications of the corresponding
+predicate.
            
+
+
            
+The implementations do it the other way round: unique() applies the
+predicate last-first times and unique_copy() applies it last-first-1
+times.
            
+
+
            As both algorithms use the predicate for pair-wise comparison of
+sequence elements I don't see a justification for unique_copy()
+applying the predicate last-first times, especially since it is not
+specified to which pair in the sequence the predicate is applied
+twice.
            
+
            Proposed resolution:
            
+
            Change both complexity sections in 25.2.8  [lib.alg.unique] to:
            
+
+
            Complexity: For nonempty ranges, exactly last - first - 1
+applications of the corresponding predicate.
            
+
+
            
+
            240. Complexity of adjacent_find() is meaningless
            
+Section: 25.1.5  [lib.alg.adjacent.find]  Status: DR  Submitter: Angelika Langer  Date: May 15 2000
            
+
            The complexity section of adjacent_find is defective:
            
+
+
            
+
            +template <class ForwardIterator>
+ForwardIterator adjacent_find(ForwardIterator first, ForwardIterator last
+                              BinaryPredicate pred);
+
            
+
+
            -1- Returns: The first iterator i such that both i and i + 1 are in
+the range [first, last) for which the following corresponding
+conditions hold: *i == *(i + 1), pred(*i, *(i + 1)) != false. Returns
+last if no such iterator is found.
            
+
+
            -2- Complexity: Exactly find(first, last, value) - first applications
+of the corresponding predicate.
+
            
+
            
+
+
            In the Complexity section, it is not defined what "value"
+is supposed to mean. My best guess is that "value" means an
+object for which one of the conditions pred(*i,value) or
+pred(value,*i) is true, where i is the iterator defined in the Returns
+section. However, the value type of the input sequence need not be
+equality-comparable and for this reason the term find(first, last,
+value) - first is meaningless.
            
+
+
            A term such as find_if(first, last, bind2nd(pred,*i)) - first or
+find_if(first, last, bind1st(pred,*i)) - first might come closer to
+the intended specification.  Binders can only be applied to function
+objects that have the function call operator declared const, which is
+not required of predicates because they can have non-const data
+members. For this reason, a specification using a binder could only be
+an "as-if" specification.
            
+
            Proposed resolution:
            
+
            Change the complexity section in 25.1.5  [lib.alg.adjacent.find] to:
            
+
            
+For a nonempty range, exactly min((i - first) + 1,
+(last - first) - 1) applications of the
+corresponding predicate, where i is adjacent_find's
+return value.
+
            
+
+
            [Copenhagen: the original resolution specified an upper
+bound.  The LWG preferred an exact count.]
            
+
 
            
 
            242. Side effects of function objects
            
 Section: 25.2.3  [lib.alg.transform], 26.4  [lib.numeric.ops]  Status: DR  Submitter: Angelika Langer  Date: May 15 2000
            
@@ -5894,6 +6222,259 @@ are missing.
            
         locale(const locale& other) throw();
 
        
 
        
+
        270. Binary search requirements overly strict
        
+Section: 25.3.3  [lib.alg.binary.search]  Status: DR  Submitter: Matt Austern  Date: 18 Oct 2000
        
+
        
+Each of the four binary search algorithms (lower_bound, upper_bound,
+equal_range, binary_search) has a form that allows the user to pass a
+comparison function object.  According to 25.3, paragraph 2, that
+comparison function object has to be a strict weak ordering.
+
        
+
+
        
+This requirement is slightly too strict.  Suppose we are searching
+through a sequence containing objects of type X, where X is some
+large record with an integer key.  We might reasonably want to look
+up a record by key, in which case we would want to write something
+like this:
+
        
+
        +    struct key_comp {
+      bool operator()(const X& x, int n) const {
+        return x.key() < n;
+      }
+    }
+
+    std::lower_bound(first, last, 47, key_comp());
+
        
+
+
        
+key_comp is not a strict weak ordering, but there is no reason to
+prohibit its use in lower_bound.
+
        
+
+
        
+There's no difficulty in implementing lower_bound so that it allows
+the use of something like key_comp.  (It will probably work unless an
+implementor takes special pains to forbid it.)  What's difficult is
+formulating language in the standard to specify what kind of
+comparison function is acceptable.  We need a notion that's slightly
+more general than that of a strict weak ordering, one that can encompass
+a comparison function that involves different types.  Expressing that
+notion may be complicated.
+
        
+
+
        Additional questions raised at the Toronto meeting:
        
+
          
+
        •  Do we really want to specify what ordering the implementor must
+     use when calling the function object?  The standard gives 
+     specific expressions when describing these algorithms, but it also
+     says that other expressions (with different argument order) are
+     equivalent.
          • 
+
        •  If we are specifying ordering, note that the standard uses both
+     orderings when describing equal_range.
          • 
+
        •  Are we talking about requiring these algorithms to work properly
+     when passed a binary function object whose two argument types
+     are not the same, or are we talking about requirements when
+     they are passed a binary function object with several overloaded
+     versions of operator()?
          • 
+
        •  The definition of a strict weak ordering does not appear to give
+     any guidance on issues of overloading; it only discusses expressions,
+     and all of the values in these expressions are of the same type.
+     Some clarification would seem to be in order.
          • 
+
        
+
+
        Additional discussion from Copenhagen:
        
+
          
+
        • It was generally agreed that there is a real defect here: if
+the predicate is merely required to be a Strict Weak Ordering, then
+it's possible to pass in a function object with an overloaded
+operator(), where the version that's actually called does something
+completely inappropriate.  (Such as returning a random value.)
          • 
+
+
        • An alternative formulation was presented in a paper distributed by
+David Abrahams at the meeting, "Binary Search with Heterogeneous
+Comparison", J16-01/0027 = WG21 N1313: Instead of viewing the
+predicate as a Strict Weak Ordering acting on a sorted sequence, view
+the predicate/value pair as something that partitions a sequence.
+This is almost equivalent to saying that we should view binary search
+as if we are given a unary predicate and a sequence, such that f(*p)
+is true for all p below a specific point and false for all p above it.
+The proposed resolution is based on that alternative formulation.
          • 
+
        
+
        Proposed resolution:
        
+
+
        Change 25.3 [lib.alg.sorting] paragraph 3 from:
        
+
+
        
+  3 For all algorithms that take Compare, there is a version that uses
+  operator< instead. That is, comp(*i, *j) != false defaults to *i <
+  *j != false. For the algorithms to work correctly, comp has to
+  induce a strict weak ordering on the values.
+
        
+
+
        to:
        
+
+
        
+  3 For all algorithms that take Compare, there is a version that uses
+  operator< instead. That is, comp(*i, *j) != false defaults to *i
+  < *j != false. For algorithms other than those described in
+  lib.alg.binary.search (25.3.3) to work correctly, comp has to induce
+  a strict weak ordering on the values.
+
        
+
+
        Add the following paragraph after 25.3 [lib.alg.sorting] paragraph 5:
        
+
+
        
+  -6- A sequence [start, finish) is partitioned with respect to an
+  expression f(e) if there exists an integer n such that
+  for all 0 <= i < distance(start, finish), f(*(begin+i)) is true if
+  and only if i < n.
+
        
+
+
        Change 25.3.3 [lib.alg.binary.search] paragraph 1 from:
        
+
+
        
+  -1- All of the algorithms in this section are versions of binary
+   search and assume that the sequence being searched is in order
+   according to the implied or explicit comparison function. They work
+   on non-random access iterators minimizing the number of
+   comparisons, which will be logarithmic for all types of
+   iterators. They are especially appropriate for random access
+   iterators, because these algorithms do a logarithmic number of
+   steps through the data structure. For non-random access iterators
+   they execute a linear number of steps.
+
        
+
+
        to:
        
+
+
        
+   -1- All of the algorithms in this section are versions of binary
+    search and assume that the sequence being searched is partitioned
+    with respect to an expression formed by binding the search key to
+    an argument of the implied or explicit comparison function. They
+    work on non-random access iterators minimizing the number of
+    comparisons, which will be logarithmic for all types of
+    iterators. They are especially appropriate for random access
+    iterators, because these algorithms do a logarithmic number of
+    steps through the data structure. For non-random access iterators
+    they execute a linear number of steps.
+
        
+
+
        Change 25.3.3.1 [lib.lower.bound] paragraph 1 from:
        
+
+
        
+   -1- Requires: Type T is LessThanComparable
+    (lib.lessthancomparable). 
+
        
+
+
        to:
        
+
+
        
+   -1- Requires: The elements e of [first, last) are partitioned with
+   respect to the expression e < value or comp(e, value)
+
        
+
+
+
        Remove 25.3.3.1 [lib.lower.bound] paragraph 2:
        
+
+
        
+   -2- Effects: Finds the first position into which value can be
+    inserted without violating the ordering. 
+
        
+
+
        Change 25.3.3.2 [lib.upper.bound] paragraph 1 from:
        
+
+
        
+  -1- Requires: Type T is LessThanComparable (lib.lessthancomparable).
+
        
+
+
        to:
        
+
+
        
+   -1- Requires: The elements e of [first, last) are partitioned with
+   respect to the expression !(value < e) or !comp(value, e)
+
        
+
+
        Remove 25.3.3.2 [lib.upper.bound] paragraph 2:
        
+
+
        
+   -2- Effects: Finds the furthermost position into which value can be
+    inserted without violating the ordering.
+
        
+
+
        Change 25.3.3.3 [lib.equal.range] paragraph 1 from:
        
+
+
        
+   -1- Requires: Type T is LessThanComparable
+    (lib.lessthancomparable).
+
        
+
+
        to:
        
+
+
        
+   -1- Requires: The elements e of [first, last) are partitioned with
+   respect to the expressions e < value and !(value < e) or
+   comp(e, value) and !comp(value, e).  Also, for all elements e of
+   [first, last), e < value implies !(value < e) or comp(e,
+   value) implies !comp(value, e)
+
        
+
+
        Change 25.3.3.3 [lib.equal.range] paragraph 2 from:
        
+
+
        
+   -2- Effects: Finds the largest subrange [i, j) such that the value
+    can be inserted at any iterator k in it without violating the
+    ordering. k satisfies the corresponding conditions: !(*k < value)
+    && !(value < *k) or comp(*k, value) == false && comp(value, *k) ==
+    false.
+
        
+
+
        to:
        
+
+
        +   -2- Returns: 
+         make_pair(lower_bound(first, last, value),
+                   upper_bound(first, last, value))
+       or
+         make_pair(lower_bound(first, last, value, comp),
+                   upper_bound(first, last, value, comp))
+
        
+
+
        Change 25.3.3.3 [lib.binary.search] paragraph 1 from:
        
+
+
        
+   -1- Requires: Type T is LessThanComparable
+    (lib.lessthancomparable).
+
        
+
+
        to:
        
+
+
        
+   -1- Requires: The elements e of [first, last) are partitioned with
+   respect to the expressions e < value and !(value < e) or comp(e,
+   value) and !comp(value, e). Also, for all elements e of [first,
+   last), e < value implies !(value < e) or comp(e, value) implies
+   !comp(value, e)
+
        
+
+
        [Copenhagen: Dave Abrahams provided this wording]
        
+
+
        [Redmond: Minor changes in wording.  (Removed "non-negative", and
+changed the "other than those described in" wording.) Also, the LWG
+decided to accept the "optional" part.]
        
+
+
        Rationale:
        
+
        The proposed resolution reinterprets binary search. Instead of
+thinking about searching for a value in a sorted range, we view that
+as an important special case of a more general algorithm: searching
+for the partition point in a partitioned range.
        
+
+
        We also add a guarantee that the old wording did not: we ensure
+that the upper bound is no earlier than the lower bound, that
+the pair returned by equal_range is a valid range, and that the first
+part of that pair is the lower bound.
        
+
        
 
        271. basic_iostream missing typedefs
        
 Section: 27.6.1.5  [lib.iostreamclass]  Status: DR  Submitter: Martin Sebor  Date: 02 Nov 2000
        
 
        
@@ -5942,6 +6523,62 @@ class (14.6.2 [temp.dep]) and thus not visible.
        
 
        Proposed resolution:
        
 
        Qualify the names with the name of the class of which they are
 members, i.e., ios_base.
        
+
        
+
        274. a missing/impossible allocator requirement
        
+Section: 20.1.5  [lib.allocator.requirements]  Status: DR  Submitter: Martin Sebor  Date: 02 Nov 2000
        
+
        
+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
+be overloaded on reference and const_reference, which is ill-formed for
+all T = const U. In other words, this won't work:
+
        
+
+
        
+template class std::allocator<const int>;
+
        
+
+
        
+The obvious solution is to disallow specializations of allocators on
+const types. However, while containers' elements are required to be
+assignable (which rules out specializations on const T's), I think that
+allocators might perhaps be potentially useful for const values in other
+contexts. So if allocators are to allow const types a partial
+specialization of std::allocator<const T> would probably have to be
+provided.
+
        
+
        Proposed resolution:
        
+
        Change the text in row 1, column 2 of table 32 in 20.1.5, p3 from
        
+
+    
        
+    any type
+    
        
+
+
        to
        
+    
        
+    any non-const, non-reference type
+    
        
+
+
        [Redmond: previous proposed resolution was "any non-const,
+non-volatile, non-reference type".  Got rid of the "non-volatile".]
        
+
+
        Rationale:
        
+
        
+Two resolutions were originally proposed: one that partially
+specialized std::allocator for const types, and one that said an
+allocator's value type may not be const.  The LWG chose the second.
+The first wouldn't be appropriate, because allocators are intended for
+use by containers, and const value types don't work in containers.
+Encouraging the use of allocators with const value types would only
+lead to unsafe code.
+
        
+
        
+The original text for proposed resolution 2 was modified so that it
+also forbids volatile types and reference types.
+
        
+
+
        [Curaçao: LWG double checked and believes volatile is correctly
+excluded from the PR.]
        
+
 
        
 
        275. Wrong type in num_get::get() overloads
        
 Section: 22.2.2.1.1  [lib.facet.num.get.members]  Status: DR  Submitter: Matt Austern  Date: 02 Nov 2000
        
@@ -5993,6 +6630,150 @@ the arguments it was given.
   iter_type get(iter_type in, iter_type end, ios_base& str,
                 ios_base::iostate& err, float& val) const;
 
        
+
        
+
        276. Assignable requirement for container value type overly strict
        
+Section: 23.1  [lib.container.requirements]  Status: DR  Submitter: Peter Dimov  Date: 07 Nov 2000
        
+
        
+23.1/3 states that the objects stored in a container must be
+Assignable.  23.3.1  [lib.map], paragraph 2,
+states that map satisfies all requirements for a container, while in
+the same time defining value_type as pair<const Key, T> - a type
+that is not Assignable.
+
        
+
+
        
+It should be noted that there exists a valid and non-contradictory
+interpretation of the current text. The wording in 23.1/3 avoids 
+mentioning value_type, referring instead to "objects stored in a
+container." One might argue that map does not store objects of
+type map::value_type, but of map::mapped_type instead, and that the
+Assignable requirement applies to map::mapped_type, not
+map::value_type.
+
        
+
+
        
+However, this makes map a special case (other containers store objects of
+type value_type) and the Assignable requirement is needlessly restrictive in
+general.
+
        
+
+
        
+For example, the proposed resolution of active library issue 
+103 is to make set::iterator a constant iterator; this
+means that no set operations can exploit the fact that the stored
+objects are Assignable.
+
        
+
+
        
+This is related to, but slightly broader than, closed issue
+140.
+
        
+
        Proposed resolution:
        
+
        23.1/3: Strike the trailing part of the sentence:
        
+    
        
+    , and the additional requirements of Assignable types from 23.1/3
+    
        
+
        so that it reads:
        
+    
        
+    -3- The type of objects stored in these components must meet the 
+    requirements of CopyConstructible types (lib.copyconstructible).
+    
        
+
+
        23.1/4: Modify to make clear that this requirement is not for all 
+containers.  Change to:
        
+
+
        
+-4- Table 64 defines the Assignable requirement.  Some containers 
+require this property of the types to be stored in the container.  T is 
+the type used to instantiate the container. t is a value of T, and u is 
+a value of (possibly const) T.
+
        
+
+
        23.1, Table 65: in the first row, change "T is Assignable" to "T is
+CopyConstructible".
        
+
+
        23.2.1/2: Add sentence for Assignable requirement.  Change to:
        
+
+
        
+-2- A deque satisfies all of the requirements of a container and of a 
+reversible container (given in tables in lib.container.requirements) and 
+of a sequence, including the optional sequence requirements 
+(lib.sequence.reqmts).  In addition to the requirements on the stored 
+object described in 23.1[lib.container.requirements], the stored object 
+must also meet the requirements of Assignable.  Descriptions are 
+provided here only for operations on deque that are not described in one 
+of these tables or for operations where there is additional semantic 
+information.
+
        
+
+
        23.2.2/2:  Add Assignable requirement to specific methods of list.  
+Change to:
        
+
+
        
+
        -2- A list satisfies all of the requirements of a container and of a 
+reversible container (given in two tables in lib.container.requirements) 
+and of a sequence, including most of the the optional sequence 
+requirements (lib.sequence.reqmts). The exceptions are the operator[] 
+and at member functions, which are not provided. 
+
+[Footnote: These member functions are only provided by containers whose 
+iterators are random access iterators. --- end foonote]
+
        
+
+
        list does not require the stored type T to be Assignable unless the 
+following methods are instantiated:
+
+[Footnote: Implementors are permitted but not required to take advantage 
+of T's Assignable properties for these methods. -- end foonote]
+
        
+
        +     list<T,Allocator>& operator=(const list<T,Allocator>&  x );
+     template <class InputIterator>
+       void assign(InputIterator first, InputIterator last);
+     void assign(size_type n, const T& t);
+
        
+
+
+
        Descriptions are provided here only for operations on list that are not 
+described in one of these tables or for operations where there is 
+additional semantic information.
        
+
        
+
+
        23.2.4/2:   Add sentence for Assignable requirement.  Change to:
        
+
+
        
+-2- A vector satisfies all of the requirements of a container and of a 
+reversible container (given in two tables in lib.container.requirements) 
+and of a sequence, including most of the optional sequence requirements 
+(lib.sequence.reqmts). The exceptions are the push_front and pop_front 
+member functions, which are not provided.  In addition to the 
+requirements on the stored object described in 
+23.1[lib.container.requirements], the stored object must also meet the 
+requirements of Assignable.  Descriptions are provided here only for 
+operations on vector that are not described in one of these tables or 
+for operations where there is additional semantic information.
+
        
+
        Rationale:
        
+
        list, set, multiset, map, multimap are able to store non-Assignables.
+However, there is some concern about list<T>:
+although in general there's no reason for T to be Assignable, some
+implementations of the member functions operator= and
+assign do rely on that requirement.  The LWG does not want
+to forbid such implementations.
        
+
+
        Note that the type stored in a standard container must still satisfy
+the requirements of the container's allocator; this rules out, for
+example, such types as "const int".  See issue 274
+for more details.
+
        
+
+
        In principle we could also relax the "Assignable" requirement for
+individual vector member functions, such as
+push_back.  However, the LWG did not see great value in such
+selective relaxation.  Doing so would remove implementors' freedom to
+implement vector::push_back in terms of
+vector::insert.
        
+
 
        
 
        281. std::min() and max() requirements overly restrictive
        
 Section: 25.3.7  [lib.alg.min.max]  Status: DR  Submitter: Martin Sebor  Date: 02 Dec 2000
        
@@ -6015,6 +6796,54 @@ is unnecessary.
 -4- Requires: Type T is LessThanComparable 
 (20.1.2  [lib.lessthancomparable]).
 
        
+
        
+
        284. unportable example in 20.3.7, p6
        
+Section: 20.3.7  [lib.function.pointer.adaptors]  Status: DR  Submitter: Martin Sebor  Date: 26 Dec 2000
        
+
        The example in 20.3.7  [lib.function.pointer.adaptors], p6 shows how to use the C
+library function strcmp() with the function pointer adapter
+ptr_fun(). But since it's unspecified whether the C library
+functions have extern "C" or extern
+"C++" linkage [17.4.2.2  [lib.using.linkage]], and since
+function pointers with different the language linkage specifications
+(7.5  [dcl.link]) are incompatible, whether this example is
+well-formed is unspecified.
+
        
+
        Proposed resolution:
        
+
        Change 20.3.7  [lib.function.pointer.adaptors] paragraph 6 from:
        
+
        
+  
        [Example:
+
        
+  
        +    replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++");
+  
        
+  
        replaces each C with C++ in sequence v.
        
+
        
+
+
+
        to:
        
+
        
+  
        [Example:
+
        
+  
        +    int compare(const char*, const char*);
+    replace_if(v.begin(), v.end(),
+               not1(bind2nd(ptr_fun(compare), "abc")), "def");
+  
        
+  
        replaces each abc with def in sequence v.
        
+
        
+
+
        Also, remove footnote 215 in that same paragraph.
        
+
+
        [Copenhagen: Minor change in the proposed resolution.  Since this
+issue deals in part with C and C++ linkage, it was believed to be too
+confusing for the strings in the example to be "C" and "C++".
+]
        
+
+
        [Redmond: More minor changes.  Got rid of the footnote (which
+seems to make a sweeping normative requirement, even though footnotes
+aren't normative), and changed the sentence after the footnote so that
+it corresponds to the new code fragment.]
        
+
 
        
 
        285. minor editorial errors in fstream ctors
        
 Section: 27.8.1.6  [lib.ifstream.cons]  Status: DR  Submitter: Martin Sebor  Date: 31 Dec 2000
        
@@ -6694,6 +7523,125 @@ original proposed resolution also said to remove <cstdio> from
 Table 82.  However, <cstdio> is mentioned several times within
 section 27.8  [lib.file.streams], including 27.8.2  [lib.c.files].]
        
 
+
        
+
        310. Is errno a macro?
        
+Section: 17.4.1.2  [lib.headers], 19.3  [lib.errno]  Status: DR  Submitter: Steve Clamage  Date: 21 Mar 2001
        
+  
        
+  Exactly how should errno be declared in a conforming C++ header?
+  
        
+
+  
        
+  The C standard says in 7.1.4 that it is unspecified whether errno is a
+  macro or an identifier with external linkage.  In some implementations
+  it can be either, depending on compile-time options.  (E.g., on
+  Solaris in multi-threading mode, errno is a macro that expands to a
+  function call, but is an extern int otherwise.  "Unspecified" allows
+  such variability.)
+  
        
+
+  
        The C++ standard:
        
+  
          
+  
        • 17.4.1.2 says in a note that errno must be macro in C. (false)
          • 
+  
        • 17.4.3.1.3 footnote 166 says errno is reserved as an external 
+      name (true), and implies that it is an identifier.
          • 
+  
        • 19.3 simply lists errno as a macro (by what reasoning?) and goes
+      on to say that the contents of of C++ <errno.h> are the
+      same as in C, begging the question.
          • 
+  
        • C.2, table 95 lists errno as a macro, without comment.
          • 
+  
        
+
+  
        I find no other references to errno.
        
+
+  
        We should either explicitly say that errno must be a macro, even
+  though it need not be a macro in C, or else explicitly leave it
+  unspecified.  We also need to say something about namespace std. 
+  A user who includes <cerrno> needs to know whether to write
+  errno, or ::errno, or std::errno, or
+  else <cerrno> is useless.
        
+
+  
        Two acceptable fixes:
        
+  
          
+    
        • errno must be a macro. This is trivially satisfied by adding
          
+          #define errno (::std::errno)
          
+        to the headers if errno is not already a macro. You then always
+        write errno without any scope qualification, and it always expands
+        to a correct reference. Since it is always a macro, you know to
+        avoid using errno as a local identifer.
          • 
+    
        • errno is in the global namespace. This fix is inferior, because
+        ::errno is not guaranteed to be well-formed.
          • 
+  
        
+
+  
        [
+    This issue was first raised in 1999, but it slipped through 
+    the cracks.
+  ]
        
+
        Proposed resolution:
        
+  
        Change the Note in section 17.4.1.2p5 from
        
+
+    
        
+    Note: the names defined as macros in C include the following:
+    assert, errno, offsetof, setjmp, va_arg, va_end, and va_start.
+    
        
+
+  
        to
        
+
+    
        
+    Note: the names defined as macros in C include the following:
+    assert, offsetof, setjmp, va_arg, va_end, and va_start.
+    
        
+
+  
        In section 19.3, change paragraph 2 from
        
+
+    
        
+    The contents are the same as the Standard C library header
+    <errno.h>.
+    
        
+
+  
        to
        
+
+    
        
+    The contents are the same as the Standard C library header 
+    <errno.h>, except that errno shall be defined as a macro.
+    
        
+
        Rationale:
        
+
        C++ must not leave it up to the implementation to decide whether or
+not a name is a macro; it must explicitly specify exactly which names
+are required to be macros.  The only one that really works is for it
+to be a macro.
        
+
+
        [Curaçao: additional rationale added.]
        
+
+
        
+
        311. Incorrect wording in basic_ostream class synopsis
        
+Section: 27.6.2.1  [lib.ostream]  Status: DR  Submitter: Andy Sawyer  Date: 21 Mar 2001
        
+
+
        In 27.6.2.1  [lib.ostream], the synopsis of class basic_ostream says:
        
+
+
        +  // partial specializationss
+  template<class traits>
+    basic_ostream<char,traits>& operator<<( basic_ostream<char,traits>&,
+                                            const char * );
+
        
+
+
        Problems:
        
+
          
+
        • Too many 's's at the end of "specializationss" 
          • 
+
        • This is an overload, not a partial specialization
          • 
+
        
+
+
        Proposed resolution:
        
+
        In the synopsis in 27.6.2.1  [lib.ostream], remove the 
+// partial specializationss comment.  Also remove the same 
+comment (correctly spelled, but still incorrect) from the synopsis in 
+27.6.2.5.4  [lib.ostream.inserters.character].
+
        
+
+
        [
+Pre-Redmond: added 27.6.2.5.4  [lib.ostream.inserters.character] because of Martin's
+comment in c++std-lib-8939.
+]
        
+
 
        
 
        312. Table 27 is missing headers
        
 Section: 20  [lib.utilities]  Status: DR  Submitter: Martin Sebor  Date: 29 Mar 2001
        
@@ -6703,6 +7651,388 @@ Memory (lib.memory) but neglects to mention the headers
 
        Proposed resolution:
        
 
        Add <cstdlib> and <cstring> to Table 27, in the same row
 as <memory>.
        
+
        
+
        315. Bad "range" in list::unique complexity
        
+Section: 23.2.2.4  [lib.list.ops]  Status: DR  Submitter: Andy Sawyer  Date: 1 May 2001
        
+
        
+23.2.2.4  [lib.list.ops], 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)".
+
        
+
+
        
+"(last - first)" is not a range.
+
        
+
        Proposed resolution:
        
+
        
+Change the "range" from (last - first) to [first, last).
+
        
+
        
+
        316. Vague text in Table 69
        
+Section: 23.1.2  [lib.associative.reqmts]  Status: DR  Submitter: Martin Sebor  Date: 4 May 2001
        
+
        Table 69 says this about a_uniq.insert(t):
        
+
+
        
+inserts t if and only if there is no element in the container with key
+equivalent to the key of t. The bool component of the returned pair 
+indicates whether the insertion takes place and the iterator component of the
+pair points to the element with key equivalent to the key of t.
+
        
+
+
        The description should be more specific about exactly how the bool component
+indicates whether the insertion takes place.
        
+
        Proposed resolution:
        
+
        Change the text in question to
        
+
+
        
+...The bool component of the returned pair is true if and only if the insertion
+takes place...
+
        
+
        
+
        317. Instantiation vs. specialization of facets
        
+Section: 22  [lib.localization]  Status: DR  Submitter: Martin Sebor  Date: 4 May 2001
        
+
        
+The localization section of the standard refers to specializations of
+the facet templates as instantiations even though the required facets
+are typically specialized rather than explicitly (or implicitly)
+instantiated. In the case of ctype<char> and
+ctype_byname<char> (and the wchar_t versions), these facets are
+actually required to be specialized. The terminology should be
+corrected to make it clear that the standard doesn't mandate explicit
+instantiation (the term specialization encompasses both explicit
+instantiations and specializations).
+
        
+
        Proposed resolution:
        
+
        
+In the following paragraphs, replace all occurrences of the word
+instantiation or instantiations with specialization or specializations,
+respectively:
+
        
+
+
        
+22.1.1.1.1, p4, Table 52, 22.2.1.1, p2, 22.2.1.5, p3, 22.2.1.5.1, p5,
+22.2.1.5.2, p10, 22.2.2, p2, 22.2.3.1, p1, 22.2.3.1.2, p1, p2 and p3, 
+22.2.4.1, p1, 22.2.4.1.2, p1, 22,2,5, p1, 22,2,6, p2, 22.2.6.3.2, p7, and
+Footnote 242.
+
        
+
+
        And change the text in 22.1.1.1.1, p4 from
        
+
+
        
+    An implementation is required to provide those instantiations
+    for facet templates identified as members of a category, and
+    for those shown in Table 52:
+
        
+
+
        to
        
+
+
        
+    An implementation is required to provide those specializations...
+
        
+
+
        [Nathan will review these changes, and will look for places where
+explicit specialization is necessary.]
        
+
+
        Rationale:
        
+
        This is a simple matter of outdated language.  The language to
+describe templates was clarified during the standardization process,
+but the wording in clause 22 was never updated to reflect that
+change.
        
+
        
+
        318. Misleading comment in definition of numpunct_byname
        
+Section: 22.2.3.2  [lib.locale.numpunct.byname]  Status: DR  Submitter: Martin Sebor  Date: 12 May 2001
        
+
        The definition of the numpunct_byname template contains the following
+comment:
        
+
+
        +    namespace std {
+        template <class charT>
+        class numpunct_byname : public numpunct<charT> {
+    // this class is specialized for char and wchar_t.
+        ...
+
        
+
+
        There is no documentation of the specializations and it seems
+conceivable that an implementation will not explicitly specialize the
+template at all, but simply provide the primary template.
        
+
        Proposed resolution:
        
+
        Remove the comment from the text in 22.2.3.2 and from the proposed
+resolution of library issue 228.
        
+
        
+
        319. Storage allocation wording confuses "Required behavior", "Requires"
        
+Section: 18.4.1.1  [lib.new.delete.single], 18.4.1.2  [lib.new.delete.array]  Status: DR  Submitter: Beman Dawes  Date: 15 May 2001
        
+
        The standard specifies 17.3.1.3  [lib.structure.specifications] that "Required
+behavior" elements describe "the semantics of a function definition
+provided by either the implementation or a C++ program."
        
+
+
        The standard specifies 17.3.1.3  [lib.structure.specifications] that "Requires"
+elements describe "the preconditions for calling the function."
        
+
+
        In the sections noted below, the current wording specifies
+"Required Behavior" for what are actually preconditions, and thus
+should be specified as "Requires".
        
+
+
        Proposed resolution:
        
+
+
        In 18.4.1.1  [lib.new.delete.single] Para 12 Change:
        
+
        
+  
        Required behavior: accept a value of ptr that is null or that was
+  returned by an earlier call ...
        
+
        
+
        to:
        
+
        
+  
        Requires: the value of ptr is null or the value returned by an
+  earlier call ...
        
+
        
+
+
        In 18.4.1.2  [lib.new.delete.array] Para 11 Change:
        
+
        
+  
        Required behavior: accept a value of ptr that is null or that was
+  returned by an earlier call ...
        
+
        
+
        to:
        
+
        
+  
        Requires: the value of ptr is null or the value returned by an
+  earlier call ...
        
+
        
+
+
        
+
        321. Typo in num_get
        
+Section: 22.2.2.1.2  [lib.facet.num.get.virtuals]  Status: DR  Submitter: Kevin Djang  Date: 17 May 2001
        
+
        
+Section 22.2.2.1.2 at p7 states that "A length specifier is added to
+the conversion function, if needed, as indicated in Table 56."
+However, Table 56 uses the term "length modifier", not "length
+specifier".
+
        
+
        Proposed resolution:
        
+
        
+In 22.2.2.1.2 at p7, change the text "A length specifier is added ..."
+to be "A length modifier is added ..."
+
        
+
        Rationale:
        
+
        C uses the term "length modifier".  We should be consistent.
        
+
        
+
        322. iterator and const_iterator should have the same value type
        
+Section: 23.1  [lib.container.requirements]  Status: DR  Submitter: Matt Austern  Date: 17 May 2001
        
+
        
+It's widely assumed that, if X is a container,
+iterator_traits<X::iterator>::value_type and
+iterator_traits<X::const_iterator>::value_type should both be
+X::value_type.  However, this is nowhere stated.  The language in
+Table 65 is not precise about the iterators' value types (it predates
+iterator_traits), and could even be interpreted as saying that
+iterator_traits<X::const_iterator>::value_type should be "const
+X::value_type".
+
        
+
+
        Related issue: 279.
        
+
        Proposed resolution:
        
+
        In Table 65 ("Container Requirements"), change the return type for
+X::iterator to "iterator type whose value type is T".  Change the
+return type for X::const_iterator to "constant iterator type whose
+value type is T".
        
+
        Rationale:
        
+
        
+This belongs as a container requirement, rather than an iterator
+requirement, because the whole notion of iterator/const_iterator
+pairs is specific to containers' iterator.
+
        
+
        
+It is existing practice that (for example) 
+iterator_traits<list<int>::const_iterator>::value_type
+is "int", rather than "const int".  This is consistent with
+the way that const pointers are handled: the standard already 
+requires that iterator_traits<const int*>::value_type is int.
+
        
+
        
+
        327. Typo in time_get facet in table 52
        
+Section: 22.1.1.1.1  [lib.locale.category]  Status: DR  Submitter: Tiki Wan  Date: 06 Jul 2001
        
+
        The wchar_t versions of time_get and
+time_get_byname are listed incorrectly in table 52,
+required instantiations.  In both cases the second template
+parameter is given as OutputIterator.  It should instead be
+InputIterator, since these are input facets.
        
+
        Proposed resolution:
        
+
        
+In table 52, required instantiations, in 
+22.1.1.1.1  [lib.locale.category], change
        
+
        +    time_get<wchar_t, OutputIterator>
+    time_get_byname<wchar_t, OutputIterator>
+
        
+
        to
        
+
        +    time_get<wchar_t, InputIterator>
+    time_get_byname<wchar_t, InputIterator>
+
        
+
+
        [Redmond: Very minor change in proposed resolution.  Original had
+a typo, wchart instead of wchar_t.]
        
+
+
        
+
        328. Bad sprintf format modifier in money_put<>::do_put()
        
+Section: 22.2.6.2.2  [lib.locale.money.put.virtuals]  Status: DR  Submitter: Martin Sebor  Date: 07 Jul 2001
        
+
        The sprintf format string , "%.01f" (that's the digit one), in the
+description of the do_put() member functions of the money_put facet in
+22.2.6.2.2, p1 is incorrect. First, the f format specifier is wrong
+for values of type long double, and second, the precision of 01
+doesn't seem to make sense. What was most likely intended was
+"%.0Lf"., that is a precision of zero followed by the L length
+modifier.
        
+
        Proposed resolution:
        
+
        Change the format string to "%.0Lf".
        
+
        Rationale:
        
+
        Fixes an obvious typo
        
+
        
+
        331. bad declaration of destructor for ios_base::failure
        
+Section: 27.4.2.1.1  [lib.ios::failure]  Status: DR  Submitter: PremAnand M. Rao  Date: 23 Aug 2001
        
+
        
+With the change in 17.4.4.8  [lib.res.on.exception.handling] to state
+   "An implementation may strengthen the exception-specification for a 
+    non-virtual function by removing listed exceptions."
+(issue 119)
+and the following declaration of ~failure() in ios_base::failure
+
        
+
        +    namespace std {
+       class ios_base::failure : public exception {
+       public:
+           ...
+           virtual ~failure();
+           ...
+       };
+     }
+
        
+
        the class failure cannot be implemented since in 18.6.1  [lib.exception] the destructor of class exception has an empty
+exception specification:
        
+
        +    namespace std {
+       class exception {
+       public:
+         ...
+         virtual ~exception() throw();
+         ...
+       };
+     }
+
        
+
        Proposed resolution:
        
+
        Remove the declaration of ~failure().
        
+
        Rationale:
        
+
        The proposed resolution is consistent with the way that destructors
+of other classes derived from exception are handled.
        
+
        
+
        335. minor issue with char_traits, table 37
        
+Section: 21.1.1  [lib.char.traits.require]  Status: DR  Submitter: Andy Sawyer  Date: 06 Sep 2001
        
+
        
+Table 37, in 21.1.1  [lib.char.traits.require], descibes char_traits::assign
+as:
+
        
+
        +  X::assign(c,d)   assigns c = d.
+
        
+
+
        And para 1 says:
        
+
+
        
+ [...] c and d denote values of type CharT [...]
+
        
+
+
        
+Naturally, if c and d are values, then the assignment is
+(effectively) meaningless. It's clearly intended that (in the case of
+assign, at least), 'c' is intended to be a reference type.
+
        
+
+
        I did a quick survey of the four implementations I happened to have
+lying around, and sure enough they all have signatures:
        
+
        +    assign( charT&, const charT& );
+
        
+
+
        (or the equivalent). It's also described this way in Nico's book.
+(Not to mention the synopses of char_traits<char> in 21.1.3.1
+and char_traits<wchar_t> in 21.1.3.2...)
+
        
+
        Proposed resolution:
        
+
        Add the following to 21.1.1 para 1:
        
+
        
+ r denotes an lvalue of CharT
+
        
+
+
        and change the description of assign in the table to:
        
+
        +  X::assign(r,d)   assigns r = d
+
        
+
        
+
        337. replace_copy_if's template parameter should be InputIterator
        
+Section: 25.2.4  [lib.alg.replace]  Status: DR  Submitter: Detlef Vollmann  Date: 07 Sep 2001
        
+
        From c++std-edit-876:
        
+
+
        
+In section 25.2.4  [lib.alg.replace] before p4: The name of the first
+parameter of template replace_copy_if should be "InputIterator"
+instead of "Iterator".  According to 17.3.2.1  [lib.type.descriptions] p1 the
+parameter name conveys real normative meaning.
+
        
+
        Proposed resolution:
        
+
        Change Iterator to InputIterator.
        
+
        
+
        345. type tm in <cwchar>
        
+Section: 21.4  [lib.c.strings]  Status: DR  Submitter: Clark Nelson  Date: 19 Oct 2001
        
+
        
+C99, and presumably amendment 1 to C90, specify that <wchar.h>
+declares struct tm as an incomplete type. However, table 48 in 21.4  [lib.c.strings] does not mention the type tm as being declared in
+<cwchar>. Is this omission intentional or accidental?
+
        
+
        Proposed resolution:
        
+
        In section 21.4  [lib.c.strings], add "tm" to table 48.
        
+
        
+
        346. Some iterator member functions should be const
        
+Section: 24.1  [lib.iterator.requirements]  Status: DR  Submitter: Jeremy Siek  Date: 20 Oct 2001
        
+
        Iterator member functions and operators that do not change the state
+of the iterator should be defined as const member functions or as
+functions that take iterators either by const reference or by
+value. The standard does not explicitly state which functions should
+be const.  Since this a fairly common mistake, the following changes
+are suggested to make this explicit.
        
+
+
        The tables almost indicate constness properly through naming: r
+for non-const and a,b for const iterators. The following changes
+make this more explicit and also fix a couple problems.
        
+
        Proposed resolution:
        
+
        In 24.1  [lib.iterator.requirements] Change the first section of p9 from
+"In the following sections, a and b denote values of X..." to
+"In the following sections, a and b denote values of type const X...".
        
+
+
        In Table 73, change
        
+
        +    a->m   U&         ...
+
        
+
+
        to
        
+
+
        +    a->m   const U&   ...
+    r->m   U&         ...
+
        
+
+
        In Table 73 expression column, change
        
+
+
        +    *a = t
+
        
+
+
        to
        
+
+
        +    *r = t
+
        
+
+
        [Redmond: The container requirements should be reviewed to see if
+the same problem appears there.]
        
+
 
        ----- End of document -----
        
 
 
diff --git a/libstdc++-v3/include/bits/char_traits.h b/libstdc++-v3/include/bits/char_traits.h
index 7d14838ab26..48ca669afc4 100644
--- a/libstdc++-v3/include/bits/char_traits.h
+++ b/libstdc++-v3/include/bits/char_traits.h
@@ -46,9 +46,13 @@
 
 namespace std 
 {
-  /// 21.1.2 Basis for explicit _Traits specialization 
-  /// NB: That for any given actual character type this definition is
-  /// probably wrong.
+  // 21.1.2
+  /**
+   *  @brief  Basis for explicit traits specializations.
+   *
+   *  @note  For any given actual character type, this definition is
+   *  probably wrong.
+  */
   template
     struct char_traits
     {
diff --git a/libstdc++-v3/include/bits/deque.tcc b/libstdc++-v3/include/bits/deque.tcc
index 37cc0155838..31711bab505 100644
--- a/libstdc++-v3/include/bits/deque.tcc
+++ b/libstdc++-v3/include/bits/deque.tcc
@@ -516,7 +516,7 @@ template 
 // Nothing seems to actually use this.  According to the pattern followed by
 // the rest of the SGI code, it would be called by the deprecated insert(pos)
 // function, but that has been replaced.  We'll take our time removing this
-// anyhow; mark for 3.3.  -pme
+// anyhow; mark for 3.4.  -pme
 template 
   typename deque<_Tp,_Alloc>::iterator 
   deque<_Tp,_Alloc>::
diff --git a/libstdc++-v3/include/bits/stl_alloc.h b/libstdc++-v3/include/bits/stl_alloc.h
index 9030fcd942f..1ae80f40512 100644
--- a/libstdc++-v3/include/bits/stl_alloc.h
+++ b/libstdc++-v3/include/bits/stl_alloc.h
@@ -75,7 +75,7 @@
  *  @endif
  *
  *  @note The @c reallocate member functions have been deprecated for 3.2
- *        and will be removed in 3.3.  You must define @c _GLIBCPP_DEPRECATED
+ *        and will be removed in 3.4.  You must define @c _GLIBCPP_DEPRECATED
  *        to make this visible in 3.2; see c++config.h.
  *
  *  The canonical description of these classes is in docs/html/ext/howto.html
@@ -221,7 +221,8 @@ namespace std
   /**
    *  @if maint
    *  This is used primarily (only?) in _Alloc_traits and other places to
-   *  help provide the _Alloc_type typedef.
+   *  help provide the _Alloc_type typedef.  All it does is forward the
+   *  requests after some minimal checking.
    *
    *  This is neither "standard"-conforming nor "SGI".  The _Alloc parameter
    *  must be "SGI" style.
@@ -620,8 +621,10 @@ namespace std
 
 
   /**
-   *  This is a "standard" allocator, as per [20.4].  The private _Alloc is
-   *  "SGI" style.  (See comments at the top of stl_alloc.h.)
+   *  @brief  The "standard" allocator, as per [20.4].
+   *
+   *  The private _Alloc is "SGI" style.  (See comments at the top
+   *  of stl_alloc.h.)
    *
    *  The underlying allocator behaves as follows.
    *  - if __USE_MALLOC then
diff --git a/libstdc++-v3/include/bits/stl_deque.h b/libstdc++-v3/include/bits/stl_deque.h
index c7fab2d4fb8..711d9219eb1 100644
--- a/libstdc++-v3/include/bits/stl_deque.h
+++ b/libstdc++-v3/include/bits/stl_deque.h
@@ -1034,7 +1034,7 @@ public:
    *  of a %deque this operation can be done in constant time.  You should
    *  consider using push_front(value_type()) instead.
    *
-   *  @note This was deprecated in 3.2 and will be removed in 3.3.  You must
+   *  @note This was deprecated in 3.2 and will be removed in 3.4.  You must
    *        define @c _GLIBCPP_DEPRECATED to make this visible in 3.2; see
    *        c++config.h.
   */
@@ -1078,7 +1078,7 @@ public:
    *  of a %deque this operation can be done in constant time.  You should
    *  consider using push_back(value_type()) instead.
    *
-   *  @note This was deprecated in 3.2 and will be removed in 3.3.  You must
+   *  @note This was deprecated in 3.2 and will be removed in 3.4.  You must
    *        define @c _GLIBCPP_DEPRECATED to make this visible in 3.2; see
    *        c++config.h.
   */
@@ -1154,7 +1154,7 @@ public:
    *  specified location.  You should consider using
    *  insert(position,value_type()) instead.
    *
-   *  @note This was deprecated in 3.2 and will be removed in 3.3.  You must
+   *  @note This was deprecated in 3.2 and will be removed in 3.4.  You must
    *        define @c _GLIBCPP_DEPRECATED to make this visible in 3.2; see
    *        c++config.h.
   */
diff --git a/libstdc++-v3/include/bits/stl_iterator.h b/libstdc++-v3/include/bits/stl_iterator.h
index 6fb0d81339f..fd066cc7e1f 100644
--- a/libstdc++-v3/include/bits/stl_iterator.h
+++ b/libstdc++-v3/include/bits/stl_iterator.h
@@ -317,6 +317,8 @@ namespace std
 
   // 24.4.2.2.1 back_insert_iterator
   /**
+   *  @brief  Turns assignment into insertion.
+   *
    *  These are output iterators, constructed from a container-of-T.
    *  Assigning a T to the iterator appends it to the container using
    *  push_back.
@@ -387,6 +389,8 @@ namespace std
     { return back_insert_iterator<_Container>(__x); }
 
   /**
+   *  @brief  Turns assignment into insertion.
+   *
    *  These are output iterators, constructed from a container-of-T.
    *  Assigning a T to the iterator prepends it to the container using
    *  push_front.
@@ -456,6 +460,8 @@ namespace std
     { return front_insert_iterator<_Container>(__x); }
 
   /**
+   *  @brief  Turns assignment into insertion.
+   *
    *  These are output iterators, constructed from a container-of-T.
    *  Assigning a T to the iterator inserts it in the container at the
    *  %iterator's position, rather than overwriting the value at that
diff --git a/libstdc++-v3/include/bits/stl_iterator_base_types.h b/libstdc++-v3/include/bits/stl_iterator_base_types.h
index 5dff8fc3f44..e7f131280c3 100644
--- a/libstdc++-v3/include/bits/stl_iterator_base_types.h
+++ b/libstdc++-v3/include/bits/stl_iterator_base_types.h
@@ -68,13 +68,12 @@
 
 namespace std
 {
-  /**
+  /** @{
    *  @defgroup iterator_tags Iterator Tags
    *  These are empty types, used to distinguish different iterators.  The
    *  distinction is not made by what they contain, but simply by what they
    *  are.  Different underlying algorithms can then be used based on the
    *  different operations supporetd by different iterator types.
-   *  @{
   */
   ///  Marking input iterators.
   struct input_iterator_tag {};
@@ -90,6 +89,8 @@ namespace std
 
 
   /**
+   *  @brief  Common %iterator class.
+   *
    *  This class does nothing but define nested typedefs.  %Iterator classes
    *  can inherit from this class to save some work.  The typedefs are then
    *  used in specializations and overloading.
@@ -98,8 +99,9 @@ namespace std
    *  such as @c operator++ and the like.  (How could there be?)
   */
   template
-    struct iterator {
+           typename _Pointer = _Tp*, typename _Reference = _Tp&>
+    struct iterator
+    {
       /// One of the @link iterator_tags tag types@endlink.
       typedef _Category  iterator_category;
       /// The type "pointed to" by the iterator.
diff --git a/libstdc++-v3/include/bits/stl_list.h b/libstdc++-v3/include/bits/stl_list.h
index cb12e01075a..e55c337c7f1 100644
--- a/libstdc++-v3/include/bits/stl_list.h
+++ b/libstdc++-v3/include/bits/stl_list.h
@@ -715,7 +715,7 @@ public:
    *  of a %list this operation can be done in constant time.  You should
    *  consider using push_front(value_type()) instead.
    *
-   *  @note This was deprecated in 3.2 and will be removed in 3.3.  You must
+   *  @note This was deprecated in 3.2 and will be removed in 3.4.  You must
    *        define @c _GLIBCPP_DEPRECATED to make this visible in 3.2; see
    *        c++config.h.
   */
@@ -758,7 +758,7 @@ public:
    *  of a %list this operation can be done in constant time.  You should
    *  consider using push_back(value_type()) instead.
    *
-   *  @note This was deprecated in 3.2 and will be removed in 3.3.  You must
+   *  @note This was deprecated in 3.2 and will be removed in 3.4.  You must
    *        define @c _GLIBCPP_DEPRECATED to make this visible in 3.2; see
    *        c++config.h.
   */
@@ -810,7 +810,7 @@ public:
    *  Due to the nature of a %list this operation can be done in constant
    *  time, and does not invalidate iterators and references.
    *
-   *  @note This was deprecated in 3.2 and will be removed in 3.3.  You must
+   *  @note This was deprecated in 3.2 and will be removed in 3.4.  You must
    *        define @c _GLIBCPP_DEPRECATED to make this visible in 3.2; see
    *        c++config.h.
   */
diff --git a/libstdc++-v3/include/bits/stl_vector.h b/libstdc++-v3/include/bits/stl_vector.h
index 038aa0de84d..5f82d5d6095 100644
--- a/libstdc++-v3/include/bits/stl_vector.h
+++ b/libstdc++-v3/include/bits/stl_vector.h
@@ -253,7 +253,7 @@ public:
   explicit
   vector(size_type __n)
     : _Base(__n, allocator_type())
-    { _M_finish = uninitialized_fill_n(_M_start, __n, _Tp()); }
+    { _M_finish = uninitialized_fill_n(_M_start, __n, value_type()); }
 
   /**
    *  @brief  %Vector copy constructor.
@@ -489,7 +489,6 @@ public:
   */
   reference
   operator[](size_type __n) { return *(begin() + __n); }
-  // XXX do we need to convert to normal_iterator first?
 
   /**
    *  @brief  Subscript access to the data contained in the %vector.
@@ -545,7 +544,6 @@ public:
   */
   reference
   front() { return *begin(); }
-  // XXX do we need to convert to normal_iterator first?
 
   /**
    *  Returns a read-only (constant) reference to the data at the first
@@ -631,7 +629,7 @@ public:
    *  Note that this kind of operation could be expensive for a vector and if
    *  it is frequently used the user should consider using std::list.
    *
-   *  @note This was deprecated in 3.2 and will be removed in 3.3.  You must
+   *  @note This was deprecated in 3.2 and will be removed in 3.4.  You must
    *        define @c _GLIBCPP_DEPRECATED to make this visible in 3.2; see
    *        c++config.h.
   */
@@ -914,7 +912,7 @@ protected:
 */
 template 
   inline bool
-  operator==(const vector<_Tp, _Alloc>& __x, const vector<_Tp, _Alloc>& __y)
+  operator==(const vector<_Tp,_Alloc>& __x, const vector<_Tp,_Alloc>& __y)
   {
     return __x.size() == __y.size() &&
            equal(__x.begin(), __x.end(), __y.begin());
@@ -933,7 +931,7 @@ template 
 */
 template 
   inline bool
-  operator<(const vector<_Tp, _Alloc>& __x, const vector<_Tp, _Alloc>& __y)
+  operator<(const vector<_Tp,_Alloc>& __x, const vector<_Tp,_Alloc>& __y)
   {
     return lexicographical_compare(__x.begin(), __x.end(),
                                    __y.begin(), __y.end());
@@ -941,40 +939,34 @@ template 
 
 /// Based on operator==
 template 
-inline bool
-operator!=(const vector<_Tp, _Alloc>& __x, const vector<_Tp, _Alloc>& __y) {
-  return !(__x == __y);
-}
+  inline bool
+  operator!=(const vector<_Tp,_Alloc>& __x, const vector<_Tp,_Alloc>& __y)
+  { return !(__x == __y); }
 
 /// Based on operator<
 template 
-inline bool
-operator>(const vector<_Tp, _Alloc>& __x, const vector<_Tp, _Alloc>& __y) {
-  return __y < __x;
-}
+  inline bool
+  operator>(const vector<_Tp,_Alloc>& __x, const vector<_Tp,_Alloc>& __y)
+  { return __y < __x; }
 
 /// Based on operator<
 template 
-inline bool
-operator<=(const vector<_Tp, _Alloc>& __x, const vector<_Tp, _Alloc>& __y) {
-  return !(__y < __x);
-}
+  inline bool
+  operator<=(const vector<_Tp,_Alloc>& __x, const vector<_Tp,_Alloc>& __y)
+  { return !(__y < __x); }
 
 /// Based on operator<
 template 
-inline bool
-operator>=(const vector<_Tp, _Alloc>& __x, const vector<_Tp, _Alloc>& __y) {
-  return !(__x < __y);
-}
+  inline bool
+  operator>=(const vector<_Tp,_Alloc>& __x, const vector<_Tp,_Alloc>& __y)
+  { return !(__x < __y); }
 
 /// See std::vector::swap().
 template 
-inline void swap(vector<_Tp, _Alloc>& __x, vector<_Tp, _Alloc>& __y)
-{
-  __x.swap(__y);
-}
+  inline void
+  swap(vector<_Tp,_Alloc>& __x, vector<_Tp,_Alloc>& __y)
+  { __x.swap(__y); }
 
 } // namespace std
 
 #endif /* __GLIBCPP_INTERNAL_VECTOR_H */
-
diff --git a/libstdc++-v3/libsupc++/exception b/libstdc++-v3/libsupc++/exception
index b26cb6d887f..d76a947f7c9 100644
--- a/libstdc++-v3/libsupc++/exception
+++ b/libstdc++-v3/libsupc++/exception
@@ -41,11 +41,13 @@ extern "C++" {
 
 namespace std 
 {
-  /** This is the base class for all exceptions thrown by the standard
+  /**
+   *  @brief Base class for all library exceptions.
+   *
+   *  This is the base class for all exceptions thrown by the standard
    *  library, and by certain language expressions.  You are free to derive
    *  your own %exception classes, or use a different hierarchy, or to
    *  throw non-class data (e.g., fundamental types).
-   *  @brief Base class for all library exceptions.
    */
   class exception 
   {
diff --git a/libstdc++-v3/libsupc++/new b/libstdc++-v3/libsupc++/new
index 74f14b5a4a2..a47f4c68742 100644
--- a/libstdc++-v3/libsupc++/new
+++ b/libstdc++-v3/libsupc++/new
@@ -45,7 +45,10 @@ extern "C++" {
 
 namespace std 
 {
-  /** @c bad_alloc (or classes derived from it) is used to report allocation
+  /**
+   *  @brief  Exception possibly thrown by @c new.
+   *
+   *  @c bad_alloc (or classes derived from it) is used to report allocation
    *  errors from the throwing forms of @c new.  */
   class bad_alloc : public exception 
   {
diff --git a/libstdc++-v3/libsupc++/typeinfo b/libstdc++-v3/libsupc++/typeinfo
index 480dc4a21a1..88a2639b898 100644
--- a/libstdc++-v3/libsupc++/typeinfo
+++ b/libstdc++-v3/libsupc++/typeinfo
@@ -54,9 +54,12 @@ namespace __cxxabiv1
 
 namespace std 
 {
-  /** The @c type_info class describes type information generated by
+  /**
+   *  @brief  Part of RTTI.
+   *
+   *  The @c type_info class describes type information generated by
    *  an implementation.
-   *  @brief Used in RTTI.  */
+  */
   class type_info 
   {
   public:
@@ -124,7 +127,10 @@ namespace std
 			     void **__obj_ptr) const;
   };
 
-  /** If you attempt an invalid @c dynamic_cast expression, an instance of
+  /**
+   *  @brief  Thrown during incorrect typecasting.
+   *
+   *  If you attempt an invalid @c dynamic_cast expression, an instance of
    *  this class (or something derived from this class) is thrown.  */
   class bad_cast : public exception 
   {