diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog index 84f7775ea98..7b94c3b8cf7 100644 --- a/libstdc++-v3/ChangeLog +++ b/libstdc++-v3/ChangeLog @@ -1,3 +1,9 @@ +2006-11-05 Paolo Carlini + + * docs/html/ext/lwg-active.html, lwg-defects.html: Import Revision 45. + * docs/html/ext/lwg-closed.html: Add. + * docs/html/ext/howto.html: Adjust. + 2006-10-30 Paolo Carlini * include/tr1/utility (tuple_size >::value): Provide diff --git a/libstdc++-v3/docs/html/ext/howto.html b/libstdc++-v3/docs/html/ext/howto.html index a39e0fbf915..8d9bee14e60 100644 --- a/libstdc++-v3/docs/html/ext/howto.html +++ b/libstdc++-v3/docs/html/ext/howto.html @@ -580,14 +580,14 @@
Fix the parameters.
-
512: +
512: Seeding subtract_with_carry_01 from a single unsigned long
Construct a linear_congruential engine and seed with it.
-
538: - DR 538. 241 again: Does unique_copy() require CopyConstructible +
538: + 241 again: Does unique_copy() require CopyConstructible and Assignable?
In case of input_iterator/output_iterator rely on Assignability of diff --git a/libstdc++-v3/docs/html/ext/lwg-active.html b/libstdc++-v3/docs/html/ext/lwg-active.html index 7a2b949377f..a4f69b64511 100644 --- a/libstdc++-v3/docs/html/ext/lwg-active.html +++ b/libstdc++-v3/docs/html/ext/lwg-active.html @@ -8,11 +8,11 @@ del {background-color:#FFFFA0} - + - + @@ -23,7 +23,7 @@ del {background-color:#FFFFA0}
Doc. no.N2091=06-0161N2130=06-0200
Date:2006-09-082006-11-03
Project: Howard Hinnant <howard.hinnant@gmail.com>
-

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

+

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

Reference ISO/IEC IS 14882:1998(E)

Also see:

    @@ -91,6 +91,16 @@ del {background-color:#FFFFA0} directory as the issues list files.

    Revision History

      +
    • R45: +2006-11-03 post-Portland mailing. +Moved issues 520, 521, 530, 535, 537, 538, 540, 541 to WP. +Moved issues 504, 512, 516, 544, 549, 554, 555, 558 to NAD. +Moved issue 569 to Dup. +Moved issues 518, 523, 524, 542, 556, 557, 559, 597, 606 to Open. +Moved issues 543, 545, 549, 549, 598 - 603, 605 to Ready. +Moved issues 531, 551, 604 to Review. +Added new issues 593-609. +
    • R44: 2006-09-08 pre-Portland mailing. Added new issues 583-592. @@ -99,14 +109,14 @@ Added new issues 575-582. Reopened 255. -Moved issues 520, 541, 544, 569 to Tentatively Ready. +Moved issues 520, 541, 544, 569 to Tentatively Ready.
    • R42: 2006-04-21 post-Berlin mailing. Added new issues 567-572. Moved issues 499, 501, 506, 509-511, 513, 514, 517 to NAD. -Moved issues 502, 503, 515, 516, 522, 525-529, 532, 536, 539, 548 to Open. -Moved issue 504, 512, 521, 530, 531, 535, 537, 538, 540, 549 to Ready. +Moved issues 502, 503, 515, 516, 522, 525-529, 532, 536, 539, 548 to Open. +Moved issue 504, 512, 521, 530, 531, 535, 537, 538, 540, 549 to Ready. Moved issues 247, 294, 362, 369, 371, 376, 384, 475, 478, 495, 497, 505, 507, 508, 519 to WP. Moved issue 534 to Review.
      • @@ -118,21 +128,21 @@ Reopened 529-535. +Added new issues 529-535.
    • R39: 2005-10-14 post-Mont Tremblant mailing. Added new issues 526-528. Moved issues 280, 461, 464, 465, 467, 468, 474, 496 from Ready to WP as per the vote from Mont Tremblant. Moved issues 247, 294, 342, 362, 369, 371, 376, 384, 475, 478, 495, 497 from Review to Ready. -Moved issues 498, 504, 506, 509, 510, 511, 512, 513, 514 from New to Open. +Moved issues 498, 504, 506, 509, 510, 511, 512, 513, 514 from New to Open. Moved issues 505, 507, 508, 519 from New to Ready. Moved issue 500 from New to NAD. Moved issue 518 from New to Review.
    • R38: 2005-07-03 pre-Mont Tremblant mailing. -Merged open TR1 issues in 504-522. +Merged open TR1 issues in 504-522. Added new issues 523-523
    • R37: @@ -1419,6 +1429,61 @@ result of a call to strm.clear(). [Pre-Berlin] Reopened at the request of Paolo Carlini and Steve Clamage.

      +

      +[Pre-Portland] A relevant newsgroup post: +

      + +

      +The current proposed resolution of issue #309 +(http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309) is +unacceptable. I write commerical software and coding around this +makes my code ugly, non-intuitive, and requires comments referring +people to this very issue. Following is the full explanation of my +experience. +

      +

      +In the course of writing software for commercial use, I constructed +std::ifstream's based on user-supplied pathnames on typical POSIX +systems. +

      +

      +It was expected that some files that opened successfully might not read +successfully -- such as a pathname which actually refered to a +directory. Intuitively, I expected the streambuffer underflow() code +to throw an exception in this situation, and recent implementations of +libstdc++'s basic_filebuf do just that (as well as many of my own +custom streambufs). +

      +

      +I also intuitively expected that the istream code would convert these +exceptions to the "badbit' set on the stream object, because I had not +requested exceptions. I refer to 27.6.1.1. P4. +

      +

      +However, this was not the case on at least two implementations -- if +the first thing I did with an istream was call operator>>( T& ) for T +among the basic arithmetic types and std::string. Looking further I +found that the sentry's constructor was invoking the exception when it +pre-scanned for whitespace, and the extractor function (operator>>()) +was not catching exceptions in this situation. +

      +

      +So, I was in a situation where setting 'noskipws' would change the +istream's behavior even though no characters (whitespace or not) could +ever be successfully read. +

      +

      +Also, calling .peek() on the istream before calling the extractor() +changed the behavior (.peek() had the effect of setting the badbit +ahead of time). +

      +

      +I found this all to be so inconsistent and inconvenient for me and my +code design, that I filed a bugzilla entry for libstdc++. I was then +told that the bug cannot be fixed until issue #309 is resolved by the +committee. +

      +

      Proposed resolution:

      Rationale:

      The LWG agrees there is minor variation between implementations, @@ -1530,7 +1595,7 @@ In case of failure, the function calls setstate(failbit) or badbit is set, so using !fail(), rather than good(), satisfies this goal.

      -

      382. codecvt do_in/out result

      Section: 22.2.1.5 [lib.locale.codecvt.byname]  Status: Open  Submitter: Martin Sebor  Date: 30 Aug 2002

      +

      382. codecvt do_in/out result

      Section: 22.2.1.5 [lib.locale.codecvt.byname]  Status: Open  Submitter: Martin Sebor  Date: 30 Aug 2002

      It seems that the descriptions of codecvt do_in() and do_out() leave sufficient room for interpretation so that two implementations of @@ -4182,122 +4247,6 @@ facet, but several also need to use a codecvt facet and we don't say so. Berlin: Bill to provide wording. ]

      -

      504. Integer types in pseudo-random number engine requirements

      Section: TR1 5.1.1 [tr.rand.req]  Status: Ready  Submitter: Walter Brown  Date: 3 Jul 2005

      -

      -In [tr.rand.req], Paragraph 2 states that "... s is a value of integral type, -g is an ... object returning values of unsigned integral type ..." -

      -

      Proposed resolution:

      -

      -In 5.1.1 [tr.rand.req], Paragraph 2 replace -

      - -
      -... s is a value of integral type, g is an lvalue of a type other than X that -defines a zero-argument function object returning values of unsigned integral type -unsigned long int, -... -
      - -

      -In 5.1.1 [tr.rand.seq], Table 16, replace in the line for X(s) -

      - -
      -creates an engine with the initial internal state -determined by static_cast<unsigned long>(s) -
      - -

      [ -Mont Tremblant: Both s and g should be unsigned long. -This should refer to the constructor signatures. Jens provided wording post Mont Tremblant. -]

      - -

      [ -Berlin: N1932 adopts the proposed resolution: see 26.3.1.3/1e and Table 3 row 2. Moved -to Ready. -]

      - -

      Rationale:

      -

      -Jens: Just requiring X(unsigned long) still makes it possible -for an evil library writer to also supply a X(int) that does something -unexpected. The wording above requires that X(s) always performs -as if X(unsigned long) would have been called. I believe that is -sufficient and implements our intentions from Mont Tremblant. I -see no additional use in actually requiring a X(unsigned long) -signature. u.seed(s) is covered by its reference to X(s), same -arguments. -

      -
      -

      512. Seeding subtract_with_carry_01 from a single unsigned long

      Section: TR1 5.1.4.4 [tr.rand.eng.sub1]  Status: Ready  Submitter: Walter Brown  Date: 3 Jul 2005

      -

      -Paragraph 8 specifies the algorithm by which a subtract_with_carry_01 engine -is to be seeded given a single unsigned long. This algorithm is seriously -flawed in the case where the engine parameter w (also known as word_size) -exceeds 31 [bits]. The key part of the paragraph reads: -

      -
      -sets x(-r) ... x(-1) to (lcg(1)*2**(-w)) mod 1 -
      -

      -and so forth. -

      -

      -Since the specified linear congruential engine, lcg, delivers numbers with -a maximum of 2147483563 (just a shade under 31 bits), then when w is, for -example, 48, each of the x(i) will be less than 2**-17. The consequence -is that roughly the first 400 numbers delivered will be conspicuously -close to either zero or one. -

      -

      -Unfortunately, this is not an innocuous flaw: One of the predefined engines -in [tr.rand.predef], namely ranlux64_base_01, has w = 48 and would exhibit -this poor behavior, while the original N1378 proposal states that these -pre-defined engines are intended to be of "known good properties." -

      -

      Proposed resolution:

      -

      -In 5.1.4.4 [tr.rand.eng.sub1], replace the "effects" clause for -void seed(unsigned long value = 19780503) by -

      - -
      -Effects: If value == 0, sets value to 19780503. In any -case, with a linear congruential generator lcg(i) having parameters -mlcg = 2147483563, alcg = 40014, -clcg = 0, and lcg(0) = value, -sets carry(-1) and x(-r) … x(-1) -as if executing - -
      
-linear_congruential<unsigned long, 40014, 0, 2147483563> lcg(value);
-seed(lcg);
-
      - -to (lcg(1) · 2-w) mod 1 -… (lcg(r) · 2-w) mod 1, -respectively. If x(-1) == 0, sets carry(-1) = 2-w, -else sets carry(-1) = 0. -
      - -

      [ -Jens provided revised wording post Mont Tremblant. -]

      - -

      [ -Berlin: N1932 adopts the originally-proposed resolution of the issue. -Jens's supplied wording is a clearer description of what is -intended. Moved to Ready. -]

      - -

      Rationale:

      -

      -Jens: I'm using an explicit type here, because fixing the -prose would probably not qualify for the (with issue 504 even -stricter) requirements we have for seed(Gen&). -

      -

      515. Random number engine traits

      Section: TR1 5.1.2 [tr.rand.synopsis]  Status: Open  Submitter: Walter Brown  Date: 3 Jul 2005

      To accompany the concept of a pseudo-random number engine as defined in Table 17, @@ -4354,125 +4303,19 @@ feature. ]

      -

      516. Seeding subtract_with_carry_01 using a generator

      Section: TR1 5.1.4.4 [tr.rand.eng.sub1]  Status: Ready  Submitter: Walter Brown  Date: 3 Jul 2005

      -

      -Paragraph 6 says: -

      -
      -... obtained by successive invocations of g, ... -
      -

      -We recommend instead: -

      -
      -... obtained by taking successive invocations of g mod 2**32, ... -
      -

      -as the context seems to require only 32-bit quantities be used here. -

      -

      Proposed resolution:

      -

      -Berlin: N1932 adopts the proposed resultion: see 26.3.3.4/7. Moved to Ready. -

      -
      -

      518. Are insert and erase stable for unordered_multiset and unordered_multimap?

      Section: TR1 6.3 [tr.hash]  Status: Review  Submitter: Matt Austern  Date: 3 Jul 2005

      +

      518. Are insert and erase stable for unordered_multiset and unordered_multimap?

      Section: TR1 6.3 [tr.hash]  Status: Open  Submitter: Matt Austern  Date: 3 Jul 2005

      Issue 371 deals with stability of multiset/multimap under insert and erase (i.e. do they preserve the relative order in ranges of equal elements). The same issue applies to unordered_multiset and unordered_multimap.

      Proposed resolution:

      -

      -

      -
      -

      520. Result_of and pointers to data members

      Section: TR1 3.6 [tr.func.bind]  Status: Tentatively Ready  Submitter: Pete Becker  Date: 3 Jul 2005

      -

      -In the original proposal for binders, the return type of bind() when -called with a pointer to member data as it's callable object was -defined to be mem_fn(ptr); when Peter Dimov and I unified the -descriptions of the TR1 function objects we hoisted the descriptions -of return types into the INVOKE pseudo-function and into result_of. -Unfortunately, we left pointer to member data out of result_of, so -bind doesn't have any specified behavior when called with a pointer -to member data. -

      -

      Proposed resolution:

      [ -Pete and Peter will provide wording. +Moved to open (from review): There is no resolution. ]

      -In 20.5.4 [lib.func.ret] ([tr.func.ret]) p3 add the following bullet after bullet 2:

      -
        -
      1. If F is a member data pointer type R T::*, type -shall be cv R& when T1 is cv U1&, -R otherwise.
        2. -
      - -

      [ -Peter provided wording. -]

      -
      -

      521. Garbled requirements for argument_type in reference_wrapper

      Section: TR1 2.1.2 [tr.util.refwrp.refwrp]  Status: Ready  Submitter: Pete Becker  Date: 3 Jul 2005

      -

      -2.1.2/3, second bullet item currently says that reference_wrapper<T> is -derived from unary_function<T, R> if T is: -

      -
      -a pointer to member function type with cv-qualifier cv and no arguments; -the type T1 is cv T* and R is the return type of the pointer to member function; -
      -

      -The type of T1 can't be cv T*, 'cause that's a pointer to a pointer to member -function. It should be a pointer to the class that T is a pointer to member of. -Like this: -

      -
      -a pointer to a member function R T0::f() cv (where cv represents the member -function's cv-qualifiers); the type T1 is cv T0* -
      -

      -Similarly, bullet item 2 in 2.1.2/4 should be: -

      -
      -a pointer to a member function R T0::f(T2) cv (where cv represents the member -function's cv-qualifiers); the type T1 is cv T0* -
      -

      Proposed resolution:

      - -

      -Change bullet item 2 in 2.1.2/3: -

      - -
      -
        -
      • -a pointer to member function type with cv-qualifier cv and no arguments; -the type T1 is cv T* and R is the return -type of the pointer to member function R T0::f() cv -(where cv represents the member function's cv-qualifiers); -the type T1 is cv T0* -
        • -
      -
      - -

      -Change bullet item 2 in 2.1.2/4: -

      - -
      -
        -
      • -a pointer to member function with cv-qualifier cv and taking one argument -of type T2; the type T1 is cv T* and -R is the return type of the pointer to member function -R T0::f(T2) cv (where cv represents the member -function's cv-qualifiers); the type T1 is cv T0* -
        • -
      -
      -

      522. Tuple doesn't define swap

      Section: TR1 6.1 [tr.tuple]  Status: Open  Submitter: Andy Koenig  Date: 3 Jul 2005

      @@ -4484,7 +4327,7 @@ Berlin: Doug to provide wording.

      Proposed resolution:

      -

      523. regex case-insensitive character ranges are unimplementable as specified

      Section: TR1 7 [tr.re]  Status: New  Submitter: Eric Niebler  Date: 1 Jul 2005

      +

      523. regex case-insensitive character ranges are unimplementable as specified

      Section: TR1 7 [tr.re]  Status: Open  Submitter: Eric Niebler  Date: 1 Jul 2005

      A problem with TR1 regex is currently being discussed on the Boost developers list. It involves the handling of case-insensitive matching @@ -4596,9 +4439,14 @@ whether the next character pair is a valid digraph in the current locale. Hoping this doesn't make this even more complex that it was already,

      +

      [ +Portland: Alisdair: Detect as invalid, throw an exception. +Pete: Possible general problem with case insensitive ranges. +]

      +

      Proposed resolution:

      -

      524. regex named character classes and case-insensitivity don't mix

      Section: TR1 7 [tr.re]  Status: New  Submitter: Eric Niebler  Date: 1 Jul 2005

      +

      524. regex named character classes and case-insensitivity don't mix

      Section: TR1 7 [tr.re]  Status: Open  Submitter: Eric Niebler  Date: 1 Jul 2005

      This defect is also being discussed on the Boost developers list. The full discussion can be found here: @@ -4942,37 +4790,7 @@ Berlin: The LWG requests a detailed survey of part 2 of the proposed resolution. ]

      -

      530. Must elements of a string be contiguous?

      Section: 21.3 [lib.basic.string]  Status: Ready  Submitter: Matt Austern  Date: 15 Nov 2005

      -

      Issue 69, which was incorporated into C++03, mandated -   that the elements of a vector must be stored in contiguous memory. -   Should the same also apply to basic_string?

      - -

      We almost require contiguity already. Clause 23.3.4 [lib.multiset] -  defines operator[] as data()[pos]. What's missing -  is a similar guarantee if we access the string's elements via the -  iterator interface.

      - -

      Given the existence of data(), and the definition of -  operator[] and at in terms of data, -  I don't believe it's possible to write a useful and standard- -  conforming basic_string that isn't contiguous. I'm not -  aware of any non-contiguous implementation. We should just require -  it. -

      -

      Proposed resolution:

      -

      Add the following text to the end of 21.3 [lib.basic.string], -paragraph 2.

      - -
      - 

      The characters in a string are stored contiguously, meaning that if -  s is a basic_string<charT, Allocator>, then -  it obeys the identity -  &*(s.begin() + n) == &*s.begin() + n -  for all 0 <= n < s.size(). -

      -
      -
      -

      531. array forms of unformatted input functions

      Section: 27.6.1.3 [lib.istream.unformatted]  Status: Ready  Submitter: Martin Sebor  Date: 23 Nov 2005

      +

      531. array forms of unformatted input functions

      Section: 27.6.1.3 [lib.istream.unformatted]  Status: Review  Submitter: Martin Sebor  Date: 23 Nov 2005

      The array forms of unformatted input functions don't seem to have well-defined semantics for zero-element arrays in a couple of cases. The affected ones @@ -4993,6 +4811,17 @@ I suggest changing 27.6.1.3, p7 (istream::get()), bullet 1 to read:

    +

    +Change 27.6.1.3, p9: +

    + +
    +If the function stores no characters, it calls setstate(failbit) (which +may throw ios_base::failure (27.4.4.3)). In any case, if (n +> 0) is true it then stores a null character into the next +successive location of the array. +
    +

    and similarly p17 (istream::getline()), bullet 3 to: @@ -5023,6 +4852,12 @@ In any case, provided (n > 0) is true, it then stores a null charact

    + +

    [ +post-Redmond: Pete noticed that the current resolution for get requires +writing to out of bounds memory when n == 0. Martin provided fix. +]

    +

    532. Tuple comparison

    Section: TR1 6.1.3.5 [tr.tuple.rel]  Status: Open  Submitter: David Abrahams  Date: 29 Nov 2005

    @@ -5201,41 +5036,6 @@ a[n] Berlin: Has support. Alisdair provided wording. ]

    -

    535. std::string::swap specification poorly worded

    Section: 21.3.5.8 [lib.string::swap]  Status: Ready  Submitter: Beman Dawes  Date: 14 Dec 2005

    -

    -std::string::swap currently says for effects and postcondition: -

    - -
    -

    -Effects: Swaps the contents of the two strings. -

    - -

    -Postcondition: *this contains the characters that were in s, -s contains the characters that were in *this. -

    -
    - -

    -Specifying both Effects and Postcondition seems redundant, and the postcondition -needs to be made stronger. Users would be unhappy if the characters were not in -the same order after the swap. -

    -

    Proposed resolution:

    -
    -

    -Effects: Swaps the contents of the two strings. -

    - -

    -Postcondition: *this contains the same sequence of -characters that were was in s, -s contains the same sequence of characters that -were was in *this. -

    -
    -

    536. Container iterator constructor and explicit convertibility

    Section: 23.1 [lib.container.requirements]  Status: Open  Submitter: Joaquín M López Muñoz  Date: 17 Dec 2005

    The iterator constructor X(i,j) for containers as defined in 23.1.1 and @@ -5293,94 +5093,6 @@ int main() Berlin: Some support, not universal, for respecting the explicit qualifier. ]

    -

    537. Typos in the signatures in 27.6.1.3/42-43 and 27.6.2.4

    Section: 27.6.1.3 [lib.istream.unformatted]  Status: Ready  Submitter: Paolo Carlini  Date: 12 Feb 2006

    -

    -In the most recent working draft, I'm still seeing: -

    - -
    seekg(off_type& off, ios_base::seekdir dir)
-
    - -

    -and -

    - -
    seekp(pos_type& pos)
-
-seekp(off_type& off, ios_base::seekdir dir)
-
    - -

    -that is, by reference off and pos arguments. -

    -

    Proposed resolution:

    -

    -After 27.6.1.3p42 change: -

    - -
    basic_istream<charT,traits>& seekg(off_type& off, ios_base::seekdir dir);
-
    - -

    -After 27.6.2.4p1 change: -

    - -
    basic_ostream<charT,traits>& seekp(pos_type& pos);
-
    - -

    -After 27.6.2.4p3 change: -

    - -
    basic_ostream<charT,traits>& seekp(off_type& off, ios_base::seekdir dir);
-
    -
    -

    538. 241 again: Does unique_copy() require CopyConstructible and Assignable?

    Section: 25.2.8 [lib.alg.unique]  Status: Ready  Submitter: Howard Hinnant  Date: 9 Feb 2006

    -

    -I believe I botched the resolution of - -241 "Does unique_copy() require CopyConstructible and Assignable?" which now -has WP status. -

    - -

    -This talks about unique_copy requirements and currently reads: -

    - -
    --5- Requires: The ranges [first, last) and -[result, result+(last-first)) -shall not overlap. The expression *result = *first shall -be valid. If neither InputIterator nor OutputIterator meets the -requirements of forward iterator then the value type of InputIterator -must be CopyConstructible (20.1.3). Otherwise CopyConstructible is not required. -
    - -

    -The problem (which Paolo discovered) is that when the iterators are at their -most restrictive (InputIterator, OutputIterator), then we want -InputIterator::value_type to be both CopyConstructible and -CopyAssignable (for the most efficient implementation). However this -proposed resolution only makes it clear that it is CopyConstructible, -and that one can assign from *first to *result. -This latter requirement does not necessarily imply that you can: -

    - -
    *first = *first;
-
    -

    Proposed resolution:

    -
    --5- Requires: The ranges [first, last) and -[result, result+(last-first)) -shall not overlap. The expression *result = *first -shall -be valid. If neither InputIterator nor OutputIterator meets the -requirements of forward iterator then the value type -value_type of InputIterator -must be CopyConstructible (20.1.3) and Assignable. -Otherwise CopyConstructible is not required. -
    -

    539. partial_sum and adjacent_difference should mention requirements

    Section: 26.4 [lib.rand]  Status: Open  Submitter: Marc Schoolderman  Date: 6 Feb 2006

    There are some problems in the definition of partial_sum and @@ -5528,121 +5240,7 @@ Berlin: Giving output iterator's value_types very controversial. Suggestion of adding signatures to allow user to specify "accumulator". ]

    -

    540. shared_ptr<void>::operator*()

    Section: TR1 2.2.3.5 [tr.util.smartptr.shared.obs]  Status: Ready  Submitter: Martin Sebor  Date: 15 Oct 2005

    -

    -I'm trying to reconcile the note in tr.util.smartptr.shared.obs, p6 -that talks about the operator*() member function of shared_ptr: -

    - -
    - Notes: When T is void, attempting to instantiate this member function - renders the program ill-formed. [Note: Instantiating shared_ptr<void> - does not necessarily result in instantiating this member function. - --end note] -
    - -

    -with the requirement in temp.inst, p1: -

    - -
    - The implicit instantiation of a class template specialization causes - the implicit instantiation of the declarations, but not of the - definitions... -
    - -

    -I assume that what the note is really trying to say is that -"instantiating shared_ptr<void> *must not* result in instantiating -this member function." That is, that this function must not be -declared a member of shared_ptr<void>. Is my interpretation -correct? -

    -

    Proposed resolution:

    -

    -Change 2.2.3.5p6 -

    - -
    --6- Notes: When T is void, attempting to instantiate -this member function renders the program ill-formed. [Note: -Instantiating shared_ptr<void> does not necessarily result in -instantiating this member function. --end note] it is -unspecified whether this member function is declared or not, and if so, what its -return type is, except that the declaration (although not necessarily the -definition) of the function shall be well-formed. -
    - -
    -

    541. shared_ptr template assignment and void

    Section: TR1 2.2.3 [tr.util.smartptr.shared]  Status: Tentatively Ready  Submitter: Martin Sebor  Date: 16 Oct 2005

    -

    -Is the void specialization of the template assignment operator taking -a shared_ptr<void> as an argument supposed be well-formed? -

    -

    -I.e., is this snippet well-formed: -

    -
    shared_ptr<void> p;
-p.operator=<void>(p);
-
    - -

    -Gcc complains about auto_ptr<void>::operator*() returning a reference -to void. I suspect it's because shared_ptr has two template assignment -operators, one of which takes auto_ptr, and the auto_ptr template gets -implicitly instantiated in the process of overload resolution. -

    - -

    -The only way I see around it is to do the same trick with auto_ptr<void> -operator*() as with the same operator in shared_ptr<void>. -

    - -

    -PS Strangely enough, the EDG front end doesn't mind the code, even -though in a small test case (below) I can reproduce the error with -it as well. -

    - -
    template <class T>
-struct A { T& operator*() { return *(T*)0; } };
-
-template <class T>
-struct B {
-    void operator= (const B&) { }
-    template <class U>
-    void operator= (const B<U>&) { }
-    template <class U>
-    void operator= (const A<U>&) { }
-};
-
-int main ()
-{
-    B<void> b;
-    b.operator=<void>(b);
-}
-
    -

    Proposed resolution:

    -

    -In [lib.memory] change: -

    -
    template<class X> class auto_ptr;
-template<> class auto_ptr<void>;
-
    - -

    -In [lib.auto.ptr]/2 add the following before the last closing brace: -

    - -
    template<> class auto_ptr<void>
-{
-public:
-    typedef void element_type;
-};
-
    - -
    -

    542. shared_ptr observers

    Section: TR1 2.2.3.5 [tr.util.smartptr.shared.obs]  Status: New  Submitter: Martin Sebor  Date: 18 Oct 2005

    +

    542. shared_ptr observers

    Section: TR1 2.2.3.5 [tr.util.smartptr.shared.obs]  Status: Open  Submitter: Martin Sebor  Date: 18 Oct 2005

    Peter Dimov wrote: To: C++ libraries mailing list @@ -5678,7 +5276,7 @@ capture the intent.

    -

    543. valarray slice default constructor

    Section: 26.3.4 [lib.complex.members]  Status: New  Submitter: Howard Hinnant  Date: 3 Nov 2005

    +

    543. valarray slice default constructor

    Section: 26.3.4 [lib.complex.members]  Status: Ready  Submitter: Howard Hinnant  Date: 3 Nov 2005

    If one explicitly constructs a slice or glice with the default constructor, does the standard require this slice to have any usable @@ -5716,36 +5314,31 @@ There is a similar question and wording for gslice at 26.3.6.1p1.

    Proposed resolution:

    +Change 26.5.4.1 [cons.slice]:

    -
    -

    544. minor NULL problems in C.2

    Section: C.2 [diff.library]  Status: Tentatively Ready  Submitter: Martin Sebor  Date: 25 Nov 2005

    -

    -According to C.2.2.3, p1, "the macro NULL, defined in any of <clocale>, -<cstddef>, <cstdio>, <cstdlib>, <cstring>, <ctime>, -or <cwchar>." This is consistent with the C standard. -

    -

    -However, Table 95 in C.2 fails to mention <clocale> and <cstdlib>. -

    -

    -In addition, C.2, p2 claims that "The C++ Standard library provides -54 standard macros from the C library, as shown in Table 95." While -table 95 does have 54 entries, since a couple of them (including the -NULL macro) are listed more than once, the actual number of macros -defined by the C++ Standard Library may not be 54. -

    -

    Proposed resolution:

    -

    -I propose we add <clocale> and <cstdlib> to Table 96 and remove the -number of macros from C.2, p2 and reword the sentence as follows: -

    +
    -The C++ Standard library provides 54 standard macros from -defines a number macros corresponding to those defined by the C -Standard library, as shown in Table 96. +1 - The default constructor for slice creates a slice +which specifies no elements. The default constructor is equivalent to +slice(0, 0, 0). A default constructor is provided only to permit +the declaration of arrays of slices. The constructor with arguments for a slice +takes a start, length, and stride parameter.
    + +

    +Change 26.3.6.1 [gslice.cons]: +

    + +
    +1 - The default constructor creates a gslice which specifies no +elements. The default constructor is equivalent to gslice(0, +valarray<size_t>(), valarray<size_t>()). The constructor +with arguments builds a gslice based on a specification of start, +lengths, and strides, as explained in the previous section. +
    +
    -

    545. When is a deleter deleted?

    Section: TR1 2.2.3.2 [tr.util.smartptr.shared.dest]  Status: New  Submitter: Matt Austern  Date: 10 Jan 2006

    +

    545. When is a deleter deleted?

    Section: TR1 2.2.3.2 [tr.util.smartptr.shared.dest]  Status: Ready  Submitter: Matt Austern  Date: 10 Jan 2006

    The description of ~shared_ptr doesn't say when the shared_ptr's deleter, if any, is destroyed. In principle there are two possibilities: it is destroyed @@ -5826,18 +5419,6 @@ may block?

    -

    549. Undefined variable in binomial_distribution

    Section: TR1 5.1.7.5 [tr.rand.dist.bin]  Status: Ready  Submitter: Matt Austern  Date: 10 Jan 2006

    -

    -Paragraph 1 says that "A binomial distributon random distribution produces -integer values i>0 with p(i) = (n choose i) * p*i * (1-p)^(t-i), where t and -p are the parameters of the distribution. OK, that tells us what t, p, and i -are. What's n? -

    -

    Proposed resolution:

    -

    -Berlin: Typo: "n" replaced by "t" in N1932: see 26.3.7.2.2/1. -

    -

    550. What should the return type of pow(float,int) be?

    Section: 26.5 [lib.numarray]  Status: New  Submitter: Howard Hinnant  Date: 12 Jan 2006

    Assuming we adopt the @@ -5890,7 +5471,7 @@ Fortran, C and TR1 and make the return type of pow(float,int) be

    -

    551. <ccomplex>

    Section: TR1 8.2 [tr.c99.ccmplx]  Status: New  Submitter: Howard Hinnant  Date: 23 Jan 2006

    +

    551. <ccomplex>

    Section: TR1 8.2 [tr.c99.ccmplx]  Status: Review  Submitter: Howard Hinnant  Date: 23 Jan 2006

    Previously xxx.h was parsable by C++. But in the case of C99's <complex.h> it isn't. Otherwise we could model it just like <string.h>, <cstring>, <string>: @@ -5924,9 +5505,21 @@ The ? can't refer to the C API. TR1 currently says:

    Proposed resolution:

    -Strike 8.2 and 8.3 (and any other references to <ccomplex> and -<complex.h>). +Change 26.3.11 [cmplxh]:

    + +
    +

    +The header behaves as if it includes the header +<ccomplex>., and provides sufficient using +declarations to declare in the global namespace all function and type names +declared or defined in the neader <complex>. +[Note: <complex.h> does not promote any interface +into the global namespace as there is no C interface to promote. --end +note] +

    +
    +

    552. random_shuffle and its generator

    Section: 25.2.11 [lib.alg.random.shuffle]  Status: New  Submitter: Martin Sebor  Date: 25 Jan 2006

    @@ -5956,69 +5549,7 @@ probably should, consistently with C99, 7.18.1.4.

    -

    554. Problem with lwg DR 184 numeric_limits<bool>

    Section: 18.2.1.5 [lib.numeric.special]  Status: New  Submitter: Howard Hinnant  Date: 29 Jan 2006

    -

    -I believe we have a bug in the resolution of: -lwg 184 -(WP status). -

    - -

    -The resolution spells out each member of numeric_limits<bool>. -The part I'm having a little trouble with is: -

    -
    static const bool traps = false;
-
    - -

    -Should this not be implementation defined? Given: -

    - -
    int main()
-{
-     bool b1 = true;
-     bool b2 = false;
-     bool b3 = b1/b2;
-}
-
    - -

    -If this causes a trap, shouldn't numeric_limits<bool>::traps be -true? -

    -

    Proposed resolution:

    -

    -Change 18.2.1.5p3: -

    - -
    --3- The specialization for bool shall be provided as follows: -
    namespace std { 
-   template <> class numeric_limits<bool> {
-      ...
-      static const bool traps = false implementation-defined;
-      ...
-   };
-}
-
    -
    - -
    -

    555. TR1, 8.21/1: typo

    Section: TR1 8.21 [tr.c99.boolh]  Status: New  Submitter: Paolo Carlini  Date: 2 Feb 2006

    -

    -This one, if nobody noticed it yet, seems really editorial: -s/cstbool/cstdbool/ -

    -

    Proposed resolution:

    -

    -Change 8.21p1: -

    -
    --1- The header behaves as if it defines the additional macro defined in -<cstdbool> by including the header <cstdbool>. -
    -
    -

    556. is Compare a BinaryPredicate?

    Section: 25.3 [lib.alg.sorting]  Status: New  Submitter: Martin Sebor  Date: 5 Feb 2006

    +

    556. is Compare a BinaryPredicate?

    Section: 25.3 [lib.alg.sorting]  Status: Open  Submitter: Martin Sebor  Date: 5 Feb 2006

    In 25, p8 we allow BinaryPredicates to return a type that's convertible to bool but need not actually be bool. That allows predicates to return @@ -6061,7 +5592,7 @@ algorithms assuming an ordering relation. It is assumed that comp

    -

    557. TR1: div(_Longlong, _Longlong) vs div(intmax_t, intmax_t)

    Section: TR1 8.11.1 [tr.c99.cinttypes.syn]  Status: New  Submitter: Paolo Carlini  Date: 6 Feb 2006

    +

    557. TR1: div(_Longlong, _Longlong) vs div(intmax_t, intmax_t)

    Section: TR1 8.11.1 [tr.c99.cinttypes.syn]  Status: Open  Submitter: Paolo Carlini  Date: 6 Feb 2006

    I'm seeing a problem with such overloads: when, _Longlong == intmax_t == long long we end up, essentially, with the same arguments and different @@ -6091,38 +5622,13 @@ imaxdiv_t imaxdiv(intmax_t numer, intmax_t denom); imaxdiv_t div(intmax_t numer, intmax_t denom); ... + +

    [ +Portland: no consensus. +]

    +
    -

    558. lib.input.iterators Defect

    Section: 24.1.1 [lib.input.iterators]  Status: New  Submitter: David Abrahams  Date: 9 Feb 2006

    -
    -

    - 24.1.1 Input iterators [lib.input.iterators] -

    -

    - 1 A class or a built-in type X satisfies the requirements of an - input iterator for the value type T if the following expressions are - valid, where U is the type of any specified member of type T, as - shown in Table 73. -

    -
    -

    -There is no capital U used in table 73. There is a lowercase u, but -that is clearly not meant to denote a member of type T. Also, there's -no description in 24.1.1 of what lowercase a means. IMO the above -should have been...Hah, a and b are already covered in 24.1/11, so maybe it -should have just been: -

    -

    Proposed resolution:

    -

    -Change 24.1.1p1: -

    -
    --1- A class or a built-in type X satisfies the requirements of an -input iterator for the value type T if the following expressions -are valid, where U is the type of any specified member of type -T, as shown in Table 73. -
    -
    -

    559. numeric_limits<const T>

    Section: 18.2 [lib.support.limits]  Status: New  Submitter: Martin Sebor  Date: 19 Feb 2006

    +

    559. numeric_limits<const T>

    Section: 18.2 [lib.support.limits]  Status: Open  Submitter: Martin Sebor  Date: 19 Feb 2006

    18.2.1, p2 requires implementations to provide specializations of the @@ -6177,6 +5683,12 @@ specialization on a cv-qualified T is equal to the value of the same member of numeric_limits<T>.

    + +

    [ +Portland: Martin will clarify that user-defined types get cv-specializations +automatically. +]

    +

    560. User-defined allocators without default constructor

    Section: 20.1.5 [lib.default.con.req]  Status: New  Submitter: Sergey P. Derevyago  Date: 17 Feb 2006

    1. The essence of the problem.

    @@ -6767,33 +6279,6 @@ And change 27.6.2.5.3, p7 as follows: Add log2 to the list of functions in 8.16.4p1.

    -

    569. Postcondition for basic_ios::clear(iostate) incorrectly stated

    Section: 27.4.4.3 [lib.iostate.flags]  Status: Tentatively Ready  Submitter: Seungbeom Kim  Date: 10 Mar 2006

    -

    -Section: 27.4.4.3 [lib.iostate.flags] -

    -

    -Paragraph 4 says: -

    -
    -
    void clear(iostate state = goodbit);
-
    -

    -Postcondition: If rdbuf()!=0 then state == rdstate(); -otherwise rdstate()==state|ios_base::badbit. -

    -
    - -

    -The postcondition "rdstate()==state|ios_base::badbit" is parsed as -"(rdstate()==state)|ios_base::badbit", which is probably what the -committee meant. -

    -

    Proposed resolution:

    -

    Rationale:

    -

    -This is a duplicate of issue 272. -

    -

    570. Request adding additional explicit specializations of char_traits

    Section: 21.1 [lib.char.traits]  Status: New  Submitter: Jack Reeves  Date: 6 Apr 2006

    Currently, the Standard Library specifies only a declaration for template class @@ -6841,6 +6326,10 @@ this issue WP status (mistakenly).

    Strike the proposed resolution of issue 507.

    +

    [ +post-Portland: Howard recommends NAD. The proposed resolution of 507 no longer +exists in the current WD. +]

    573. C++0x file positioning should handle modern file sizes

    Section: 27.4.3 [lib.fpos]  Status: New  Submitter: Beman Dawes  Date: 12 Apr 2006

    @@ -7165,7 +6654,7 @@ functions.

    -

    581. flush() not unformatted function

    Section: 27.6.2.6 [lib.ostream.unformatted]  Status: New  Submitter: Martin Sebor  Date: 14 June 2006

    +

    581. flush() not unformatted function

    Section: 27.6.2.6 [lib.ostream.unformatted]  Status: New  Submitter: Martin Sebor  Date: 14 June 2006

    The resolution of issue 60 changed basic_ostream::flush() @@ -7359,7 +6848,7 @@ T power( T x, int n ); // requires: n >=0

    -

    585. facet error reporting

    Section: 22.2 [lib.locale.categories]  Status: New  Submitter: Martin Sebor, Paolo Carlini  Date: 22 June 2006

    +

    585. facet error reporting

    Section: 22.2 [lib.locale.categories]  Status: New  Submitter: Martin Sebor, Paolo Carlini  Date: 22 June 2006

    Section 22.2, paragraph 2 requires facet get() members @@ -7842,5 +7331,957 @@ calls setstate(failbit) (which may throw ios_base::failure (27.4.4.3)). +

    +

    593. __STDC_CONSTANT_MACROS

    Section: 18.3 [lib.cstdint]  Status: New  Submitter: Walter Brown  Date: 28 Aug 2006

    +

    +Clause 18.3 of the current Working Paper (N2009) deals with the new C++ headers +<cstdint> and <stdint.h>. These are of course based on the C99 header +<stdint.h>, and were part of TR1. +

    + +

    +Per 18.3.1/1, these headers define a number of macros and function macros. +While the WP does not mention __STDC_CONSTANT_MACROS in this context, C99 +footnotes do mention __STDC_CONSTANT_MACROS. Further, 18.3.1/2 states that "The +header defines all ... macros the same as C99 subclause 7.18." +

    + +

    +Therefore, if I wish to have the above-referenced macros and function macros +defined, must I #define __STDC_CONSTANT_MACROS before I #include <cstdint>, or +does the C++ header define these macros/function macros unconditionally? +

    +

    Proposed resolution:

    +

    +To put this issue to rest for C++0X, I propose the following addition to +18.3.1/2 of the Working Paper N2009: +

    + +
    +[Note: The macros defined by <cstdint> are provided unconditionally: in +particular, the symbols __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS +(mentioned in C99 footnotes 219, 220, and 222) play no role in C++. --end note] +
    +
    +

    594. Disadvantages of defining Swappable in terms of +CopyConstructible and Assignable

    Section: 20.1.4 [lib.swappable]  Status: New  Submitter: Niels Dekker  Date: 2 Nov 2006

    +

    +It seems undesirable to define the Swappable requirement in terms of +CopyConstructible and Assignable requirements. And likewise, once the +MoveConstructible and MoveAssignable requirements (N1860) have made it +into the Working Draft, it seems undesirable to define the Swappable +requirement in terms of those requirements. Instead, it appears +preferable to have the Swappable requirement defined exclusively in +terms of the existence of an appropriate swap function. +

    +

    +Section 20.1.4 [lib.swappable] of the current Working Draft (N2009) +says: +

    +The Swappable requirement is met by satisfying one or more of the +following conditions: +
      +
    • +T is Swappable if T satisfies the CopyConstructible requirements +(20.1.3) and the Assignable requirements (23.1); +
      • +
    • +T is Swappable if a namespace scope function named swap exists in the +same namespace as the definition of T, such that the expression +swap(t,u) is valid and has the semantics described in Table 33. +
      • +
    +
    +I can think of three disadvantages of this definition: +
      +
    1. +If a client's type T satisfies the first condition (T is both +CopyConstructible and Assignable), the client cannot stop T from +satisfying the Swappable requirement without stopping T from +satisfying the first condition. +

      +A client might want to stop T from satisfying the Swappable +requirement, because swapping by means of copy construction and +assignment might throw an exception, and she might find a throwing +swap unacceptable for her type. On the other hand, she might not feel +the need to fully implement her own swap function for this type. In +this case she would want to be able to simply prevent algorithms that +would swap objects of type T from being used, e.g., by declaring a +swap function for T, and leaving this function purposely undefined. +This would trigger a link error, if an attempt would be made to use +such an algorithm for this type. For most standard library +implementations, this practice would indeed have the effect of +stopping T from satisfying the Swappable requirement. +

      +
      2. +
    2. +A client's type T that does not satisfy the first condition can not be +made Swappable by providing a specialization of std::swap for T. +

      +While I'm aware about the fact that people have mixed feelings about +providing a specialization of std::swap, it is well-defined to do so. +It sounds rather counter-intuitive to say that T is not Swappable, if +it has a valid and semantically correct specialization of std::swap. +Also in practice, providing such a specialization will have the same +effect as satisfying the Swappable requirement. +

      +
      3. +
    3. +For a client's type T that satisfies both conditions of the Swappable +requirement, it is not specified which of the two conditions prevails. +After reading section 20.1.4 [lib.swappable], one might wonder whether +objects of T will be swapped by doing copy construction and +assignments, or by calling the swap function of T. +

      +I'm aware that the intention of the Draft is to prefer calling the +swap function of T over doing copy construction and assignments. Still +in my opinion, it would be better to make this clear in the wording of +the definition of Swappable. +

      +
      4. +
    +

    +

    +I would like to have the Swappable requirement defined in such a way +that the following code fragment will correctly swap two objects of a +type T, if and only if T is Swappable: +

       using std::swap;
+   swap(t, u);  // t and u are of type T.
+
    +This is also the way Scott Meyers recommends calling a swap function, +in Effective C++, Third Edition, item 25. +

    +

    +Most aspects of this issue have been dealt with in a discussion on +comp.std.c++ about the Swappable requirement, from 13 September to 4 +October 2006, including valuable input by David Abrahams, Pete Becker, +Greg Herlihy, Howard Hinnant and others. +

    +

    Proposed resolution:

    +

    +Change section 20.1.4 [lib.swappable] as follows: +

    +
    +The Swappable requirement is met by satisfying +one or more of the following conditions: +the following condition: +
      + +
    • +T is Swappable if T satisfies the CopyConstructible requirements +(20.1.3) and the Assignable requirements (23.1); +
      • +       +
    • + +T is Swappable if a namespace scope function named swap exists in the +same namespace as the definition of T, such that the expression +swap(t,u) is valid and has the semantics described in Table 33. + +T is Swappable if an unqualified function call swap(t,u) is valid +within the namespace std, and has the semantics described in Table 33. +
      • +
    +
    +
    +

    595. TR1/C++0x: fabs(complex<T>) redundant / wrongly specified

    Section: 26.3 [lib.complex.numbers]  Status: New  Submitter: Stefan Große Pawig  Date: 24 Sep 2006

    +

    +TR1 introduced, in the C compatibility chapter, the function +fabs(complex<T>): +

    +
    ----- SNIP -----
+8.1.1 Synopsis                                [tr.c99.cmplx.syn]
+
+  namespace std {
+  namespace tr1 {
+[...]
+  template<class T> complex<T> fabs(const complex<T>& x);
+  } // namespace tr1
+  } // namespace std
+
+[...]
+
+8.1.8 Function fabs                          [tr.c99.cmplx.fabs]
+
+1 Effects: Behaves the same as C99 function cabs, defined in
+  subclause 7.3.8.1.
+----- SNIP -----
+
    + +

    +The current C++0X draft document (n2009.pdf) adopted this +definition in chapter 26.3.1 (under the comment // 26.3.7 values) +and 26.3.7/7. +

    +

    +But in C99 (ISO/IEC 9899:1999 as well as the 9899:TC2 draft document +n1124), the referenced subclause reads +

    + +
    ----- SNIP -----
+7.3.8.1 The cabs functions
+
+  Synopsis
+
+1 #include <complex.h>
+  double cabs(double complex z);
+  float cabsf(float complex z);
+  long double cabsl(long double z);
+
+  Description
+
+2 The cabs functions compute the complex absolute value (also called
+  norm, modulus, or magnitude) of z.
+
+  Returns
+
+3 The cabs functions return the complex absolute value.
+----- SNIP -----
+
    + +

    +Note that the return type of the cabs*() functions is not a complex +type. Thus, they are equivalent to the already well established + template<class T> T abs(const complex<T>& x); +(26.2.7/2 in ISO/IEC 14882:1998, 26.3.7/2 in the current draft +document n2009.pdf). +

    +

    +So either the return value of fabs() is specified wrongly, or fabs() +does not behave the same as C99's cabs*(). +

    +

    Proposed resolution:

    +

    +This depends on the intention behind the introduction of fabs(). +

    +

    +If the intention was to provide a /complex/ valued function that +calculates the magnitude of its argument, this should be +explicitly specified. In TR1, the categorization under "C +compatibility" is definitely wrong, since C99 does not provide +such a complex valued function. +

    +

    +Also, it remains questionable if such a complex valued function +is really needed, since complex<T> supports construction and +assignment from real valued arguments. There is no difference +in observable behaviour between +

    +
      complex<double> x, y;
+  y = fabs(x);
+  complex<double> z(fabs(x));
+
    +

    +and +

    +
      complex<double> x, y;
+  y = abs(x);
+  complex<double> z(abs(x));
+
    +

    +If on the other hand the intention was to provide the intended +functionality of C99, fabs() should be either declared deprecated +or (for C++0X) removed from the standard, since the functionality +is already provided by the corresponding overloads of abs(). +

    +
    +

    596. 27.8.1.3 Table 112 omits "a+" and "a+b" modes

    Section: 27.8.1.3 [lib.filebuf.members]  Status: New  Submitter: Thomas Plum  Date: 26 Sep 2006

    +

    +In testing 27.8.1.3, Table 112 (in the latest N2009 draft), we invoke +

    +
       ostr.open("somename", ios_base::out | ios_base::in | ios_base::app)
+
    +

    +and we expect the open to fail, because out|in|app is not listed in +Table 92, and just before the table we see very specific words: +

    +
    + If mode is not some combination of flags shown in the table + then the open fails. +
    +

    +But the corresponding table in the C standard, 7.19.5.3, provides two +modes "a+" and "a+b", to which the C++ modes out|in|app and +out|in|app|binary would presumably apply. +

    +

    Proposed resolution:

    +

    +We would like to argue that the intent of Table 112 was to match the +semantics of 7.19.5.3 and that the omission of "a+" and "a+b" was +unintentional. (Otherwise there would be valid and useful behaviors +available in C file I/O which are unavailable using C++, for no +valid functional reason.) +

    +

    +We further request that the missing modes be explicitly restored to +the WP, for inclusion in C++0x. +

    +
    +

    597. Decimal: The notion of 'promotion' cannot be emulated by user-defined types.

    Section: Decimal 3.2  Status: Open  Submitter: Daveed Vandevoorde  Date: 5 April 2006

    +

    +In a private email, Daveed writes: +

    +
    +

    +I am not familiar with the C TR, but my guess is that the +class type approach still won't match a built-in type +approach because the notion of "promotion" cannot be +emulated by user-defined types. +

    +

    +Here is an example: +

    +
    +
    +		 struct S {
+		   S(_Decimal32 const&);  // Converting constructor
+		 };
+		 void f(S);
+
+		 void f(_Decimal64);
+
+		 void g(_Decimal32 d) {
+		   f(d);
+		 }
+
    + +
    +

    +If _Decimal32 is a built-in type, the call f(d) will likely +resolve to f(_Decimal64) because that requires only a +promotion, whereas f(S) requires a user-defined conversion. +

    +

    +If _Decimal32 is a class type, I think the call f(d) will be +ambiguous because both the conversion to _Decimal64 and the +conversion to S will be user-defined conversions with neither +better than the other. +

    +
    +

    +Robert comments: +

    +

    In general, a library of arithmetic types cannot exactly emulate the +behavior of the intrinsic numeric types. There are several ways to tell +whether an implementation of the decimal types uses compiler +intrinisics or a library. For example: +

    +
                     _Decimal32 d1;
+                 d1.operator+=(5);  // If d1 is a builtin type, this won't compile.
+
    +

    +In preparing the decimal TR, we have three options: +

    +
      +
    1. require that the decimal types be class types
      2. +
    2. require that the decimal types be builtin types, like float and double
      3. +
    3. specify a library of class types, but allow enough implementor +latitude that a conforming implementation could instead provide builtin +types
      4. +
    +

    +We decided as a group to pursue option #3, but that approach implies +that implementations may not agree on the semantics of certain use +cases (first example, above), or on whether certain other cases are +well-formed (second example). Another potentially important problem is +that, under the present definition of POD, the decimal classes are not +POD types, but builtins will be. +

    +

    Note that neither example above implies any problems with respect to +C-to-C++ compatibility, since neither example can be expressed in C. +

    +

    Proposed resolution:

    +
    +

    598. Decimal: Conversion to integral should truncate, not round.

    Section: Decimal 3.2  Status: Ready  Submitter: Daniel Krugler  Date: 28 May 2006

    + +

    +In a private email, Daniel writes: +

    +
    +

    +I would like to +ask, what where the reason for the decision to +define the semantics of the integral conversion of the decimal types, namely +

    +
    "operator long long() const;
+
+     Returns: Returns the result of the 
+conversion of *this to the type long long, as if 
+performed by the expression llrounddXX(*this)."
+
    +

    +where XX stands for either 32, 64, or 128, +corresponding to the proper decimal type. The +exact meaning of llrounddXX is not given in that +paper, so I compared it to the corresponding +definition given in C99, 2nd edition (ISO 9899), which says in 7.12.9.7 p. 2: +

    +

    +"The lround and llround functions round their +argument to the nearest integer value, +rounding halfway cases away from zero, regardless +of the current rounding direction. [..]" +

    +

    +Now considering the fact that integral conversion +of the usual floating-point types ("4.9 +Floating-integral conversions") has truncation +semantic I wonder why this conversion behaviour +has not been transferred for the decimal types. +

    +
    +

    +Robert comments: +

    +

    +Also, there is a further error in the Returns: clause for converting decimal::decimal128 to long long. It currently calls llroundd64, not llroundd128. +

    + +

    Proposed resolution:

    +

    +Change the Returns: clause in 3.2.2.4 to: +

    +
    +Returns: Returns the result of the conversion of *this to the type long long, as if performed by the expression llroundd32(*this) while the decimal rounding direction mode [3.5.2] FE_DEC_TOWARD_ZERO is in effect. +
    +

    +Change the Returns: clause in 3.2.3.4 to: +

    +
    +Returns: Returns the result of the conversion of *this to the type long long, as if performed by the expression llroundd64(*this) while the decimal rounding direction mode [3.5.2] FE_DEC_TOWARD_ZERO is in effect. +
    +

    +Change the Returns: clause in 3.2.4.4 to: +

    +
    +Returns: Returns the result of the conversion of *this to the type long long, as if performed by the expression llroundd64(*this) llroundd128(*this) while the decimal rounding direction mode [3.5.2] FE_DEC_TOWARD_ZERO is in effect. +
    + +
    +

    599. Decimal: Say "octets" instead of "bytes."

    Section: Decimal 3.1  Status: Ready  Submitter: Daniel Krugler  Date: 28 May 2006

    +

    +Daniel writes in a private email: +

    + +
    +

    +- 3.1 'Decimal type encodings' says in its note: +

    +

    +"this implies that +sizeof(std::decimal::decimal32) == 4, +sizeof(std::decimal::decimal64) == 8, and +sizeof(std::decimal::decimal128) == 16." +

    +

    +This is a wrong assertion, because the definition +of 'byte' in 1.7 'The C+ + memory model' of ISO +14882 (2nd edition) does not specify that a byte +must be necessarily 8 bits large, which would be +necessary to compare with the specified bit sizes +of the types decimal32, decimal64, and decimal128. +

    +
    +

    Proposed resolution:

    +

    +Change 3.1 as follows: +

    +
    +

    +The three decimal encoding formats defined in IEEE-754R correspond to the three decimal floating types as follows: +

    +
      +
    • +decimal32 is a decimal32 number, which is encoded in four consecutive bytes octets (32 bits) +
      • +
    • +decimal64 is a decimal64 number, which is encoded in eight consecutive bytes octets (64 bits) + +
      • +
    • +decimal128 is a decimal128 number, which is encoded in 16 consecutive bytes octets (128 bits) +
      • +
    +

    +[Note: this implies that sizeof(std::decimal::decimal32) == 4, sizeof(std::decimal::decimal64) == 8, and sizeof(std::decimal::decimal128) == 16. --end note] +

    +
    +
    +

    600. Decimal: Wrong parameters for wcstod* functions

    Section: Decimal 3.9  Status: Ready  Submitter: Daniel Krugler  Date: 28 May 2006

    +

    +Daniel writes: +

    +
    +- 3.9.1 'Additions to <cwchar>' provides wrong +signatures to the wcstod32, wcstod64, and +wcstod128 functions ([the parameters have type pointer-to-] char instead of wchar_t). +
    +

    Proposed resolution:

    +

    +Change "3.9.1 Additions to <cwchar> synopsis" to: +

    +
           namespace std {
+       namespace decimal {
+         // 3.9.2 wcstod functions:
+         decimal32  wcstod32  (const char wchar_t * nptr, char wchar_t ** endptr);
+         decimal64  wcstod64  (const char wchar_t * nptr, char wchar_t ** endptr);
+         decimal128 wcstod128 (const char wchar_t * nptr, char wchar_t ** endptr);
+       }
+       }
+
    +
    +

    601. Decimal: numeric_limits typos

    Section: Decimal 3.3  Status: Ready  Submitter: Daniel Krugler  Date: 28 May 2006

    +

    +Daniel writes in a private email: +

    + +
    +

    +- 3.3 'Additions to header <limits>' contains two +errors in the specialisation of numeric_limits<decimal::decimal128>: +

    +
      +
    1. The static member max() returns DEC128_MIN, this should be DEC128_MAX.
      2. +
    2. The static member digits is assigned to 384, +this should be 34 (Probably mixed up with the +max. exponent for decimal::decimal64).
      3. +
    +
    +

    Proposed resolution:

    +

    +In "3.3 Additions to header <limits>" change numeric_limits<decimal::decimal128> as follows: +

    +
            template<> class numeric_limits<decimal::decimal128> {
+          public:
+            static const bool is_specialized = true;
+
+            static decimal::decimal128 min() throw() { return DEC128_MIN; }
+            static decimal::decimal128 max() throw() { return DEC128_MIN; DEC128_MAX; }
+
+            static const int digits       = 384 34;
+            /* ... */
+
    +
    +

    602. Decimal: "generic floating type" not defined.

    Section: Decimal 3  Status: Ready  Submitter: Daniel Krugler  Date: 28 May 2006

    +

    +The document uses the term "generic floating types," but defines it nowhere. +

    +

    Proposed resolution:

    +

    +Change the first paragraph of "3 Decimal floating-point types" as follows: +

    +
    +This Technical Report introduces three decimal floating-point types, named +decimal32, decimal64, and decimal128. The set of values of type decimal32 is a +subset of the set of values of type decimal64; the set of values of the type +decimal64 is a subset of the set of values of the type decimal128. Support for +decimal128 is optional. These types supplement the Standard C++ types +float, double, and long double, which are +collectively described as the basic floating types. +
    +
    +

    603. Decimal: Trivially simplifying decimal classes.

    Section: Decimal 3  Status: Ready  Submitter: Martin Sebor  Date: 28 May 2006

    +

    In c++std-lib-17198, Martin writes:

    + +
    +Each of the three classes proposed in the paper (decimal32, decimal64, +and decimal128) explicitly declares and specifies the semantics of its +copy constructor, copy assignment operator, and destructor. Since the +semantics of all three functions are identical to the trivial versions +implicitly generated by the compiler in the absence of any declarations +it is safe to drop them from the spec. This change would make the +proposed classes consistent with other similar classes already in the +standard (e.g., std::complex). +
    +

    Proposed resolution:

    +

    +Change "3.2.2 Class decimal32" as follows: +

    +
          namespace std {
+      namespace decimal {
+        class decimal32 {
+          public:
+            // 3.2.2.1 construct/copy/destroy:
+            decimal32();
+            decimal32(const decimal32 & d32);
+            decimal32 & operator=(const decimal32 & d32);
+            ~decimal32();
+            /* ... */
+
    +

    +Change "3.2.2.1 construct/copy/destroy" as follows: +

    +
            decimal32();
+
+    Effects: Constructs an object of type decimal32 with the value 0;
+
+        decimal32(const decimal32 & d32);
+        decimal32 & operator=(const decimal32 & d32);
+
+    Effects: Copies an object of type decimal32.
+
+        ~decimal32();
+
+    Effects: Destroys an object of type decimal32.
+
+
    +

    +Change "3.2.3 Class decimal64" as follows: +

    +
          namespace std {
+      namespace decimal {
+        class decimal64 {
+          public:
+            // 3.2.3.1 construct/copy/destroy:
+            decimal64();
+            decimal64(const decimal64 & d64);
+            decimal64 & operator=(const decimal64 & d64);
+            ~decimal64();
+            /* ... */
+
    +

    +Change "3.2.3.1 construct/copy/destroy" as follows: +

    +
            decimal64();
+
+    Effects: Constructs an object of type decimal64 with the value 0;
+
+        decimal64(const decimal64 & d64);
+        decimal64 & operator=(const decimal64 & d64);
+
+    Effects: Copies an object of type decimal64.
+
+        ~decimal64();
+
+    Effects: Destroys an object of type decimal64.
+
+
    +

    +Change "3.2.4 Class decimal128" as follows: +

    +
          namespace std {
+      namespace decimal {
+        class decimal128 {
+          public:
+            // 3.2.4.1 construct/copy/destroy:
+            decimal128();
+            decimal128(const decimal128 & d128);
+            decimal128 & operator=(const decimal128 & d128);
+            ~decimal128();
+            /* ... */
+
    +

    +Change "3.2.4.1 construct/copy/destroy" as follows: +

    +
            decimal128();
+
+    Effects: Constructs an object of type decimal128 with the value 0;
+
+        decimal128(const decimal128 & d128);
+        decimal128 & operator=(const decimal128 & d128);
+
+    Effects: Copies an object of type decimal128.
+
+        ~decimal128();
+
+    Effects: Destroys an object of type decimal128.
+
+
    +
    +

    604. Decimal: Storing a reference to a facet unsafe.

    Section: Decimal 3  Status: Review  Submitter: Martin Sebor  Date: 28 May 2006

    +

    +In c++std-lib-17197, Martin writes: +

    +
    +The extended_num_get and extended_num_put facets are designed +to store a reference to a num_get or num_put facet which the +extended facets delegate the parsing and formatting of types +other than decimal. One form of the extended facet's ctor (the +default ctor and the size_t overload) obtains the reference +from the global C++ locale while the other form takes this +reference as an argument. +
    +
    +The problem with storing a reference to a facet in another +object (as opposed to storing the locale object in which the +facet is installed) is that doing so bypasses the reference +counting mechanism designed to prevent a facet that is still +being referenced (i.e., one that is still installed in some +locale) from being destroyed when another locale that contains +it is destroyed. Separating a facet reference from the locale +it comes from van make it cumbersome (and in some cases might +even make it impossible) for programs to prevent invalidating +the reference. (The danger of this design is highlighted in +the paper.) +
    +
    +This problem could be easily avoided by having the extended +facets store a copy of the locale from which they would extract +the base facet either at construction time or when needed. To +make it possible, the forms of ctors of the extended facets that +take a reference to the base facet would need to be changed to +take a locale argument instead. +
    +

    Proposed resolution:

    +

    +1. Change the extended_num_get synopsis in 3.10.2 as follows: +

    +
                extended_num_get(const std::num_get<charT, InputIterator> std::locale & b, size_t refs = 0);
+
+            /* ... */
+
+            // const std::num_get<charT, InputIterator> & base;        exposition only
+            // std::locale baseloc;                                    exposition only
+
    +

    +2. Change the description of the above constructor in 3.10.2.1: +

    +
                extended_num_get(const std::num_get<charT, InputIterator> std::locale & b, size_t refs = 0);
+
+
    +
    +

    +Effects: Constructs an extended_num_get facet as if by: +

    +
           extended_num_get(const std::num_get<charT, InputIterator> std::locale & b, size_t refs = 0)
+                : facet(refs), baseloc(b)
+                { /* ... */ }
+
+
    +

    +Notes: Care must be taken by the implementation to ensure that the lifetime of the facet referenced by base exceeds that of the resulting extended_num_get facet. +

    +
    +

    +3. Change the Returns: clause for do_get(iter_type, iter_type, ios_base &, ios_base::iostate &, bool &) const, et al to +

    +
    +Returns: base std::use_facet<std::num_get<charT, InputIterator> >(baseloc).get(in, end, str, err, val). +
    +

    +4. Change the extended_num_put synopsis in 3.10.3 as follows: +

    +
                extended_num_put(const std::num_put<charT, OutputIterator> std::locale & b, size_t refs = 0);
+
+            /* ... */
+
+            // const std::num_put<charT, OutputIterator> & base;       exposition only
+            // std::locale baseloc;                                    exposition only
+
    +

    +5. Change the description of the above constructor in 3.10.3.1: +

    +
                extended_num_put(const std::num_put<charT, OutputIterator> std::locale & b, size_t refs = 0);
+
    +
    +

    +Effects: Constructs an extended_num_put facet as if by: +

    +
           extended_num_put(const std::num_put<charT, OutputIterator> std::locale & b, size_t refs = 0)
+                : facet(refs), baseloc(b)
+                { /* ... */ }
+
+
    +

    +Notes: Care must be taken by the implementation to ensure that the lifetime of the facet referenced by base exceeds that of the resulting extended_num_put facet. +

    +
    +

    +6. Change the Returns: clause for do_put(iter_type, ios_base &, char_type, bool &) const, et al to +

    +
    +Returns: base std::use_facet<std::num_put<charT, OutputIterator> >(baseloc).put(s, f, fill, val). +
    + +

    [ +Redmond: We would prefer to rename "extended" to "decimal". +]

    + +
    +

    605. Decimal: <decfloat.h> doesn't live here anymore.

    Section: Decimal 3.4  Status: Ready  Submitter: Robert Klarer  Date: 17 October 2006

    +

    In Berlin, WG14 decided to drop the <decfloat.h> header. The +contents of that header have been moved into <float.h>. For the +sake of C compatibility, we should make corresponding changes. +

    +

    Proposed resolution:

    +

    +1. Change the heading of subclause 3.4, "Headers <cdecfloat> and <decfloat.h>" to "Additions to headers <cfloat> and <float.h>." +

    +

    +2. Change the text of subclause 3.4 as follows: +

    +
    +

    +The standard C++ headers <cfloat> and <float.h> define characteristics of the floating-point types float, double, and long double. Their contents remain unchanged by this Technical Report. +

    +

    +Headers <cdecfloat> and <decfloat.h> define characteristics of the decimal floating-point types decimal32, decimal64, and decimal128. As well, <decfloat.h> defines the convenience typedefs _Decimal32, _Decimal64, and _Decimal128, for compatibilty with the C programming language. +

    +

    +The header <cfloat> is described in [tr.c99.cfloat]. The header <float.h> +is described in [tr.c99.floath]. These headers are extended by this +Technical Report to define characteristics of the decimal +floating-point types decimal32, decimal64, and decimal128. As well, <float.h> is extended to define the convenience typedefs _Decimal32, _Decimal64, and _Decimal128 for compatibility with the C programming language. +

    +
    +

    +3. Change the heading of subclause 3.4.1, "Header <cdecfloat> synopsis" to "Additions to header <cfloat> synopsis." +

    +

    +4. Change the heading of subclause 3.4.2, "Header <decfloat.h> synopsis" to "Additions to header <float.h> synopsis." +

    +

    +5. Change the contents of 3.4.2 as follows: +

    +
          #include <cdecfloat>
+
+      // C-compatibility convenience typedefs:
+
+      typedef std::decimal::decimal32  _Decimal32;
+      typedef std::decimal::decimal64  _Decimal64;
+      typedef std::decimal::decimal128 _Decimal128;
+
    + +
    +

    606. Decimal: allow narrowing conversions

    Section: Decimal 3.2  Status: Open  Submitter: Martin Sebor  Date: 15 June 2006

    +

    +In c++std-lib-17205, Martin writes: +

    +
    +...was it a deliberate design choice to make narrowing assignments +ill-formed while permitting narrowing compound assignments? For +instance: +
    +
          decimal32 d32;
+      decimal64 d64;
+
+      d32 = 64;     // error
+      d32 += 64;    // okay
+
    +

    +In c++std-lib-17229, Robert responds: +

    +
    It is a vestige of an old idea that I forgot to remove from +the paper. Narrowing assignments should be permitted. The bug is that +the converting constructors that cause narrowing should not be +explicit. Thanks for pointing this out. +
    +

    Proposed resolution:

    +

    +1. In "3.2.2 Class decimal32" synopsis, remove the explicit specifier from the narrowing conversions: +

    +
                    // 3.2.2.2 conversion from floating-point type:
+                explicit decimal32(decimal64 d64);
+                explicit decimal32(decimal128 d128);
+
    +

    +2. Do the same thing in "3.2.2.2. Conversion from floating-point type." +

    +

    +3. In "3.2.3 Class decimal64" synopsis, remove the explicit specifier from the narrowing conversion: +

    +
                    // 3.2.3.2 conversion from floating-point type:
+                explicit decimal64(decimal128 d128);
+
    +

    +4. Do the same thing in "3.2.3.2. Conversion from floating-point type." +

    + +

    [ +Redmond: We prefer explicit conversions for narrowing and implicit for widening. +]

    + +
    +

    607. Concern about short seed vectors

    Section: 26.4.7.1 [lib.rand.dist.iunif]  Status: New  Submitter: Charles Karney  Date: 26 Oct 2006

    +

    +Short seed vectors of 32-bit quantities all result in different states. However +this is not true of seed vectors of 16-bit (or smaller) quantities. For example +these two seeds +

    + +
    unsigned short seed = {1, 2, 3};
+unsigned short seed = {1, 2, 3, 0};
+
    + +

    +both pack to +

    + +
    unsigned seed = {0x20001, 0x3};
+
    + +

    +yielding the same state. +

    +

    Proposed resolution:

    +

    +In 26.4.7.1[rand.util.seedseq]/8a, replace +

    + +
    +

    +Set begin[0] to 5489 + sN. +

    +

    +where N is the bit length of the sequence used to construct the +seed_seq in 26.4.7.1/6 [rand.util.seedseq]. (This quantity is called n +in 26.4.7.1/6 [rand.util.seedseq], but n has a different meaning in +26.4.7.1/8 [rand.util.seedseq]. We have 32^(s-1) < N <= 32^s.) Now +

    + +
    unsigned short seed = {1, 2, 3, 0};
+unsigned seed = {0x20001, 0x3};
+
    + +

    +are equivalent (N = 64), but +

    + +
    unsigned short seed = {1, 2, 3};
+
    + +

    +gives a distinct state (N = 48). +

    +
    + +
    +

    608. Unclear seed_seq construction details

    Section: 26.4.7.1 [lib.rand.dist.iunif]  Status: New  Submitter: Charles Karney  Date: 26 Oct 2006

    +

    +In 26.4.7.1 [rand.util.seedseq] /6, the order of packing the inputs into b and the +treatment of signed quantities is unclear. Better to spell it out. +

    +

    Proposed resolution:

    +
    b = sum( unsigned(begin[i]) 2^(w i), 0 <= i < end-begin )
+
    + +

    +where w is the bit-width of the InputIterator. +

    +
    +

    609. missing static const

    Section: 26.4.4.2 [lib.rand.eng.mers]  Status: New  Submitter: Walter E. Brown  Date: 2 Nov 2006

    +

    +In preparing N2111, an error on my part resulted in the omission of the +following line from the template synopsis in the cited section: +

    + +
    static const size_t word_size = w;
+
    + +

    +(This same constant is found, for example, in 26.4.3.3 [rand.eng.sub].) +

    +

    Proposed resolution:

    +

    +Add the above declaration as the first line after the comment in [rand.adapt.ibits] p4: +

    + +
    // engine characteristics
+static const size_t word_size = w;
+
    + +

    +and accept my apologies for the oversight. +

    ----- End of document -----

    \ No newline at end of file diff --git a/libstdc++-v3/docs/html/ext/lwg-closed.html b/libstdc++-v3/docs/html/ext/lwg-closed.html new file mode 100644 index 00000000000..19de85138df --- /dev/null +++ b/libstdc++-v3/docs/html/ext/lwg-closed.html @@ -0,0 +1,5669 @@ + +C++ Standard Library Closed Issues List + + + + + + + + + + + + + + + + + + + + + +
    Doc. no.N2132=06-0202
    Date:2006-11-03
    Project:Programming Language C++
    Reply to:Howard Hinnant <howard.hinnant@gmail.com>
    +

    C++ Standard Library Closed Issues List (Revision R45)

    +

    Reference ISO/IEC IS 14882:1998(E)

    +

    Also see:

    + + +

    This document contains only library issues which have been closed + by the Library Working Group as duplicates or not defects. That is, + issues which have a status of Dup or NAD. See the Library Active Issues List active issues and more + information. See the Library Defect Reports List for issues considered + defects. The introductory material in that document also applies to + this document.

    +

    Revision History

    +
      +
    • R45: +2006-11-03 post-Portland mailing. +Moved issues 520, 521, 530, 535, 537, 538, 540, 541 to WP. +Moved issues 504, 512, 516, 544, 549, 554, 555, 558 to NAD. +Moved issue 569 to Dup. +Moved issues 518, 523, 524, 542, 556, 557, 559, 597, 606 to Open. +Moved issues 543, 545, 549, 549, 598 - 603, 605 to Ready. +Moved issues 531, 551, 604 to Review. +Added new issues 593-609. +
      • +
    • R44: +2006-09-08 pre-Portland mailing. +Added new issues 583-592. +
      • +
    • R43: +2006-06-23 mid-term mailing. +Added new issues 575-582. +Reopened 255. +Moved issues 520, 541, 544, 569 to Tentatively Ready. +
      • +
    • R42: +2006-04-21 post-Berlin mailing. +Added new issues 567-572. +Moved issues 499, 501, 506, 509-511, 513, 514, 517 to NAD. +Moved issues 502, 503, 515, 516, 522, 525-529, 532, 536, 539, 548 to Open. +Moved issue 504, 512, 521, 530, 531, 535, 537, 538, 540, 549 to Ready. +Moved issues 247, 294, 362, 369, 371, 376, 384, 475, 478, 495, 497, 505, 507, 508, 519 to WP. +Moved issue 534 to Review. +
      • +
    • R41: +2006-02-24 pre-Berlin mailing. +Added new issues 536-566. +Moved 342 from Ready to Open. +Reopened 309. +
      • +
    • R40: +2005-12-16 mid-term mailing. +Added new issues 529-535. +
      • +
    • R39: +2005-10-14 post-Mont Tremblant mailing. +Added new issues 526-528. +Moved issues 280, 461, 464, 465, 467, 468, 474, 496 from Ready to WP as per the vote from Mont Tremblant. +Moved issues 247, 294, 342, 362, 369, 371, 376, 384, 475, 478, 495, 497 from Review to Ready. +Moved issues 498, 504, 506, 509, 510, 511, 512, 513, 514 from New to Open. +Moved issues 505, 507, 508, 519 from New to Ready. +Moved issue 500 from New to NAD. +Moved issue 518 from New to Review. +
      • +
    • R38: +2005-07-03 pre-Mont Tremblant mailing. +Merged open TR1 issues in 504-522. +Added new issues 523-523 +
      • +
    • R37: +2005-06 mid-term mailing. +Added new issues 498-503. +
      • +
    • R36: +2005-04 post-Lillehammer mailing. All issues in "ready" status except +for 454 were moved to "DR" status, and all issues +previously in "DR" status were moved to "WP". +
      • +
    • R35: +2005-03 pre-Lillehammer mailing. +
      • +
    • R34: +2005-01 mid-term mailing. Added new issues 488-494. +
      • +
    • R33: +2004-11 post-Redmond mailing. Reflects actions taken in Redmond. +
      • +
    • R32: +2004-09 pre-Redmond mailing: reflects new proposed resolutions and +new issues received after the 2004-07 mailing. Added +new issues 479-481. +
      • +
    • R31: +2004-07 mid-term mailing: reflects new proposed resolutions and +new issues received after the post-Sydney mailing. Added +new issues 463-478. +
      • +
    • R30: +Post-Sydney mailing: reflects decisions made at the Sydney meeting. +Voted all "Ready" issues from R29 into the working paper. +Added new issues 460-462. +
      • +
    • R29: +Pre-Sydney mailing. Added new issues 441-457. +
      • +
    • R28: +Post-Kona mailing: reflects decisions made at the Kona meeting. +Added new issues 432-440. +
      • +
    • R27: +Pre-Kona mailing. Added new issues 404-431. +
      • +
    • R26: +Post-Oxford mailing: reflects decisions made at the Oxford meeting. +All issues in Ready status were voted into DR status. All issues in +DR status were voted into WP status. +
      • +
    • R25: +Pre-Oxford mailing. Added new issues 390-402. +
      • +
    • R24: +Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz +meeting. All Ready issues from R23 with the exception of 253, which has been given a new proposed resolution, were +moved to DR status. Added new issues 383-389. (Issues 387-389 were discussed +at the meeting.) Made progress on issues 225, 226, 229: 225 and 229 have been moved to Ready status, and the only remaining +concerns with 226 involve wording. +
      • +
    • R23: +Pre-Santa Cruz mailing. Added new issues 367-382. +Moved issues in the TC to TC status. +
      • +
    • 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 +347-350 were added since Redmond, hence +not discussed at the meeting. + +All Ready issues were moved to DR status, with the exception of issues +284, 241, and 267. + +Noteworthy issues discussed at Redmond include +120 202, 226, 233, +270, 253, 254, 323. +
      • +
    • R19: +Pre-Redmond mailing. Added new issues +323-335. +
      • +
    • R18: +Post-Copenhagen mailing; reflects actions taken in Copenhagen. +Added new issues 312-317, and discussed +new issues 271-314. + +Changed status of issues +103 118 136 153 +165 171 183 184 +185 186 214 221 +234 237 243 248 +251 252 256 260 +261 262 263 265 +268 +to DR. + +Changed status of issues +49 109 117 182 +228 230 232 235 +238 241 242 250 +259 264 266 267 +271 272 273 275 +281 284 285 286 +288 292 295 297 +298 301 303 306 +307 308 312 +to Ready. + +Closed issues +111 277 279 287 +289 293 302 313 +314 +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. +
      • +
    • R16: +post-Toronto mailing; reflects actions taken in Toronto. Added new +issues 265-277. Changed status of issues +3, 8, 9, 19, +26, 31, 61, +63, 86, 108, +112, 114, 115, +122, 127, 129, +134, 137, 142, +144, 146, 147, +159, 164, 170, +181, 199, 208, +209, 210, 211, +212, 217, 220, +222, 223, 224, +227 to "DR". Reopened issue 23. Reopened +issue 187. Changed issues 2 and +4 to NAD. Fixed a typo in issue 17. Fixed +issue 70: signature should be changed both places it +appears. Fixed issue 160: previous version didn't fix +the bug in enough places. +
      • +
    • R15: +pre-Toronto mailing. Added issues +233-264. Some small HTML formatting +changes so that we pass Weblint tests. +
      • +
    • R14: +post-Tokyo II mailing; reflects committee actions taken in +Tokyo. Added issues 228 to 232. (00-0019R1/N1242) +
      • +
    • R13: +pre-Tokyo II updated: Added issues 212 to 227. +
      • +
    • R12: +pre-Tokyo II mailing: Added issues 199 to +211. Added "and paragraph 5" to the proposed resolution +of issue 29. Add further rationale to issue +178. +
      • +
    • R11: +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 +"closed" documents. Changed the proposed resolution of issue +4 to NAD, and changed the wording of proposed resolution +of issue 38. +
      • +
    • R10: +pre-Kona updated. Added proposed resolutions 83, +86, 91, 92, +109. Added issues 190 to +195. (99-0033/D1209, 14 Oct 99) +
      • +
    • R9: +pre-Kona mailing. Added issues 140 to +189. Issues list split into separate "active" and +"closed" documents. (99-0030/N1206, 25 Aug 99) +
      • +
    • R8: +post-Dublin mailing. Updated to reflect LWG and full committee actions +in Dublin. (99-0016/N1193, 21 Apr 99) +
      • +
    • R7: +pre-Dublin updated: Added issues 130, 131, +132, 133, 134, +135, 136, 137, +138, 139 (31 Mar 99) +
      • +
    • R6: +pre-Dublin mailing. Added issues 127, 128, +and 129. (99-0007/N1194, 22 Feb 99) +
      • +
    • R5: +update issues 103, 112; added issues +114 to 126. Format revisions to prepare +for making list public. (30 Dec 98) +
      • +
    • R4: +post-Santa Cruz II updated: Issues 110, +111, 112, 113 added, several +issues corrected. (22 Oct 98) +
      • +
    • R3: +post-Santa Cruz II: Issues 94 to 109 +added, many issues updated to reflect LWG consensus (12 Oct 98) +
      • +
    • R2: +pre-Santa Cruz II: Issues 73 to 93 added, +issue 17 updated. (29 Sep 98) +
      • +
    • R1: +Correction to issue 55 resolution, 60 code +format, 64 title. (17 Sep 98) +
      • +
    +

    Closed Issues

    +
    +

    2. Auto_ptr conversions effects incorrect

    Section: 20.4.5.3 [lib.meta.unary.prop]  Status: NAD  Submitter: Nathan Myers  Date: 4 Dec 1997

    +

    Paragraph 1 in "Effects", says "Calls +p->release()" where it clearly must be "Calls +p.release()". (As it is, it seems to require using +auto_ptr<>::operator-> to refer to X::release, assuming that +exists.)

    +

    Proposed resolution:

    +

    Change 20.4.5.3 [lib.meta.unary.prop] paragraph 1 Effects from +"Calls p->release()" to "Calls p.release()".

    +

    Rationale:

    +

    Not a defect: the proposed change is already found in the standard. +[Originally classified as a defect, later reclassified.]

    +
    +

    4. Basic_string size_type and difference_type should be implementation defined

    Section: 21.3 [lib.basic.string]  Status: NAD  Submitter: Beman Dawes  Date: 16 Nov 1997

    +

    In Morristown we changed the size_type and difference_type typedefs +for all the other containers to implementation defined with a +reference to 23.1 [lib.container.requirements]. This should probably also have been +done for strings.

    +

    Proposed resolution:

    +

    Rationale:

    +

    Not a defect. [Originally classified as a defect, later +reclassified.] basic_string, unlike the other standard library +template containers, is severely constrained by its use of +char_traits. Those types are dictated by the traits class, and are far +from implementation defined.

    +
    +

    6. File position not an offset unimplementable

    Section: 27.4.3 [lib.fpos]  Status: NAD  Submitter: Matt Austern  Date: 15 Dec 1997

    +

    Table 88, in I/O, is too strict; it's unimplementable on systems +where a file position isn't just an offset. It also never says just +what fpos<> is really supposed to be. [Here's my summary, which +Jerry agrees is more or less accurate. "I think I now know what +the class really is, at this point: it's a magic cookie that +encapsulates an mbstate_t and a file position (possibly represented as +an fpos_t), it has syntactic support for pointer-like arithmetic, and +implementors are required to have real, not just syntactic, support +for arithmetic." This isn't standardese, of course.]

    +

    Proposed resolution:

    +

    Rationale:

    +

    Not a defect. The LWG believes that the Standard is already clear, +and that the above summary is what the Standard in effect says.

    +
    +

    10. Codecvt<>::do unclear

    Section: 22.2.1.5 [lib.locale.codecvt.byname]  Status: Dup  Submitter: Matt Austern  Date: 14 Jan 1998

    +

    Section 22.2.1.5.2 says that codecvt<>::do_in and do_out +should return the value noconv if "no conversion was +needed". However, I don't see anything anywhere that defines what +it means for a conversion to be needed or not needed. I can think of +several circumstances where one might plausibly think that a +conversion is not "needed", but I don't know which one is +intended here.

    +

    Proposed resolution:

    +

    Rationale:

    +

    Duplicate. See issue 19.

    +
    +

    12. Way objects hold allocators unclear

    Section: 20.1.5 [lib.default.con.req]  Status: NAD  Submitter: Angelika Langer  Date: 23 Feb 1998

    +

    I couldn't find a statement in the standard saying whether the allocator object held by +a container is held as a copy of the constructor argument or whether a pointer of +reference is maintained internal. There is an according statement for compare objects and +how they are maintained by the associative containers, but I couldn't find anything +regarding allocators.

    + +

    Did I overlook it? Is it an open issue or known defect? Or is it deliberately left +unspecified?

    +

    Proposed resolution:

    +

    Rationale:

    +

    Not a defect. The LWG believes that the Standard is already +clear.  See 23.1 [lib.container.requirements], paragraph 8.

    +
    +

    43. Locale table correction

    Section: 22.2.1.5 [lib.locale.codecvt.byname]  Status: Dup  Submitter: Brendan Kehoe  Date: 1 Jun 1998

    +

    Proposed resolution:

    +

    Rationale:

    +

    Duplicate. See issue 33.

    +
    +

    45. Stringstreams read/write pointers initial position unclear

    Section: 27.7.3 [lib.ostringstream]  Status: NAD  Submitter: Matthias Mueller  Date: 27 May 1998

    +

    In a comp.lang.c++.moderated Matthias Mueller wrote:

    + +

    "We are not sure how to interpret the CD2 (see 27.2 [lib.iostream.forward], 27.7.3.1 [lib.ostringstream.cons], 27.7.1.1 [lib.stringbuf.cons]) +with respect to the question as to what the correct initial positions +of the write and  read pointers of a stringstream should +be."

    + +

    "Is it the same to output two strings or to initialize the stringstream with the +first and to output the second?"

    + +

    [PJ Plauger, Bjarne Stroustrup, Randy Smithey, Sean Corfield, and +Jerry Schwarz have all offered opinions; see reflector messages +lib-6518, 6519, 6520, 6521, 6523, 6524.]

    + +

    Proposed resolution:

    +

    Rationale:

    +

    The LWG believes the Standard is correct as written. The behavior +of stringstreams is consistent with fstreams, and there is a +constructor which can be used to obtain the desired effect. This +behavior is known to be different from strstreams.

    +
    +

    58. Extracting a char from a wide-oriented stream

    Section: 27.6.1.2.3 [lib.istream::extractors]  Status: NAD  Submitter: Matt Austern  Date: 1 Jul 1998

    +

    27.6.1.2.3 has member functions for extraction of signed char and +unsigned char, both singly and as strings. However, it doesn't say +what it means to extract a char from a +basic_streambuf<charT, Traits>.

    + +

    basic_streambuf, after all, has no members to extract a char, so +basic_istream must somehow convert from charT to signed char or +unsigned char. The standard doesn't say how it is to perform that +conversion.

    +

    Proposed resolution:

    +

    Rationale:

    +

    The Standard is correct as written. There is no such extractor and +this is the intent of the LWG.

    +
    +

    65. Underspecification of strstreambuf::seekoff

    Section: D.7.1.3 [depr.strstreambuf.virtuals]  Status: NAD  Submitter: Matt Austern  Date: 18 Aug 1998

    +

    The standard says how this member function affects the current +stream position. (gptr or pptr) However, it does not +say how this member function affects the beginning and end of the +get/put area.

    + +

    This is an issue when seekoff is used to position the get pointer +beyond the end of the current read area. (Which is legal. This is +implicit in the definition of seekhigh in D.7.1, paragraph 4.) +

    +

    Proposed resolution:

    +

    Rationale:

    +

    The LWG agrees that seekoff() is underspecified, but does not wish +to invest effort in this deprecated feature.

    +
    +

    67. Setw useless for strings

    Section: 21.3.7.9 [lib.string.io]  Status: Dup  Submitter: Steve Clamage  Date: 9 Jul 1998

    +

    In a comp.std.c++ posting Michel Michaud wrote: What +should be output by:

    + +
       string text("Hello");
+   cout << '[' << setw(10) << right << text << ']';
+
    + +

    Shouldn't it be:

    + +
       [     Hello]
    + +

    Another person replied: Actually, according to the FDIS, the width +of the field should be the minimum of width and the length of the +string, so the output shouldn't have any padding. I think that this is +a typo, however, and that what is wanted is the maximum of the +two. (As written, setw is useless for strings. If that had been the +intent, one wouldn't expect them to have mentioned using its value.) +

    + +

    It's worth pointing out that this is a recent correction anyway; +IIRC, earlier versions of the draft forgot to mention formatting +parameters whatsoever.

    +

    Proposed resolution:

    +

    Rationale:

    +

    Duplicate. See issue 25.

    +
    +

    72. Do_convert phantom member function

    Section: 22.2.1.5 [lib.locale.codecvt.byname]  Status: Dup  Submitter: Nathan Myers  Date: 24 Aug 1998

    +

    In 22.2.1.5 [lib.locale.codecvt.byname] par 3, and in 22.2.1.5.2 par 8, a nonexistent member function +"do_convert" is mentioned. This member was replaced with +"do_in" and "do_out", the proper referents in the +contexts above.

    +

    Proposed resolution:

    +

    Rationale:

    +

    Duplicate: see issue 24.

    +
    +

    73. is_open should be const

    Section: 27.8.1 [lib.fstreams]  Status: NAD  Submitter: Matt Austern  Date: 27 Aug 1998

    +

    Classes basic_ifstream, basic_ofstream, and +basic_fstream all have a member function is_open. It +should be a const member function, since it does nothing but +call one of basic_filebuf's const member functions.

    +

    Proposed resolution:

    +

    Rationale:

    +

    Not a defect. This is a deliberate feature; const streams would be +meaningless.

    +
    +

    77. Valarray operator[] const returning value

    Section: 26.5.2.3 [lib.valarray.access]  Status: NAD Future  Submitter: Levente Farkas  Date: 9 Sep 1998

    +

    valarray:
    +
    +    T operator[] (size_t) const;
    +
    +why not
    +
    +    const T& operator[] (size_t) const;
    +
    +as in vector ???
    +
    +One can't copy even from a const valarray eg:
    +
    +    memcpy(ptr, &v[0], v.size() * sizeof(double));
    +
    +[I] find this bug in valarray is very difficult.

    +

    Proposed resolution:

    +

    Rationale:

    +

    The LWG believes that the interface was deliberately designed that +way. That is what valarray was designed to do; that's where the +"value array" name comes from. LWG members further comment +that "we don't want valarray to be a full STL container." +26.5.2.3 [lib.valarray.access] specifies properties that indicate "an +absence of aliasing" for non-constant arrays; this allows +optimizations, including special hardware optimizations, that are not +otherwise possible.

    +
    +

    81. Wrong declaration of slice operations

    Section: 26.3.5 [lib.complex.member.ops], 26.3.7 [lib.complex.value.ops], 26.3.8 [lib.complex.transcendentals], 26.3.9 [lib.cmplx.over]  Status: NAD  Submitter: Nico Josuttis  Date: 29 Sep 1998

    +

    Isn't the definition of copy constructor and assignment operators wrong? +       Instead of

    + +
          slice_array(const slice_array&); 
+      slice_array& operator=(const slice_array&);
    + +

    IMHO they have to be

    + +
          slice_array(const slice_array<T>&); 
+      slice_array& operator=(const slice_array<T>&);
    + +

    Same for gslice_array.

    +

    Proposed resolution:

    +

    Rationale:

    +

    Not a defect. The Standard is correct as written.

    +
    +

    82. Missing constant for set elements

    Section: 23.1.2 [lib.associative.reqmts]  Status: NAD  Submitter: Nico Josuttis  Date: 29 Sep 1998

    +

    Paragraph 5 specifies:

    + +
    +For set and multiset the value type is the same as the key type. For +map and multimap it is equal to pair<const Key, T>. +
    + +

    Strictly speaking, this is not correct because for set and multiset +the value type is the same as the constant key type.

    +

    Proposed resolution:

    +

    Rationale:

    +

    Not a defect. The Standard is correct as written; it uses a +different mechanism (const &) for set and +multiset. See issue 103 for a related +issue.

    +
    +

    84. Ambiguity with string::insert()

    Section: 21.3.5 [lib.string.modifiers]  Status: NAD  Submitter: Nico Josuttis  Date: 29 Sep 1998

    +

    If I try

    +
        s.insert(0,1,' ');
    + +

      I get an nasty ambiguity. It might be

    +
        s.insert((size_type)0,(size_type)1,(charT)' ');
    + +

    which inserts 1 space character at position 0, or

    +
        s.insert((char*)0,(size_type)1,(charT)' ')
    + +

    which inserts 1 space character at iterator/address 0 (bingo!), or

    +
        s.insert((char*)0, (InputIterator)1, (InputIterator)' ')
    + +

    which normally inserts characters from iterator 1 to iterator ' +'. But according to 23.1.1.9 (the "do the right thing" fix) +it is equivalent to the second. However, it is still ambiguous, +because of course I mean the first!

    +

    Proposed resolution:

    +

    Rationale:

    +

    Not a defect. The LWG believes this is a "genetic +misfortune" inherent in the design of string and thus not a +defect in the Standard as such .

    +
    +

    85. String char types

    Section: 21 [lib.strings]  Status: NAD  Submitter: Nico Josuttis  Date: 29 Sep 1998

    +

    The standard seems not to require that charT is equivalent to +traits::char_type. So, what happens if charT is not equivalent to +traits::char_type?

    +

    Proposed resolution:

    +

    Rationale:

    +

    There is already wording in 21.1 [lib.char.traits] paragraph 3 that +requires them to be the same.

    +
    +

    87. Error in description of string::compare()

    Section: 21.3.6.8 [lib.string::compare]  Status: Dup  Submitter: Nico Josuttis  Date: 29 Sep 1998

    +

    The following compare() description is obviously a bug:

    + +
    int compare(size_type pos, size_type n1, 
+            charT *s, size_type n2 = npos) const;
+
    + +

    because without passing n2 it should compare up to the end of the +string instead of comparing npos characters (which throws an +exception)

    +

    Proposed resolution:

    +

    Rationale:

    +

    Duplicate; see issue 5.

    +
    +

    88. Inconsistency between string::insert() and string::append()

    Section: 21.3.5.4 [lib.string::insert], 21.3.5.2 [lib.string::append]  Status: NAD  Submitter: Nico Josuttis  Date: 29 Sep 1998

    +

    Why does

    +
      template<class InputIterator> 
+       basic_string& append(InputIterator first, InputIterator last);
    + +

    return a string, while

    +
      template<class InputIterator> 
+       void insert(iterator p, InputIterator first, InputIterator last);
    + +

    returns nothing ?

    +

    Proposed resolution:

    +

    Rationale:

    +

    The LWG believes this stylistic inconsistency is not sufficiently +serious to constitute a defect.

    +
    +

    89. Missing throw specification for string::insert() and string::replace()

    Section: 21.3.5.4 [lib.string::insert], 21.3.5.6 [lib.string::replace]  Status: Dup  Submitter: Nico Josuttis  Date: 29 Sep 1998

    +

    All insert() and replace() members for strings with an iterator as +first argument lack a throw specification. The throw +specification should probably be: length_error if size exceeds +maximum.

    +

    Proposed resolution:

    +

    Rationale:

    +

    Considered a duplicate because it will be solved by the resolution +of issue 83.

    +
    +

    93. Incomplete Valarray Subset Definitions

    Section: 26.3 [lib.complex.numbers]  Status: NAD  Submitter: Nico Josuttis  Date: 29 Sep 1998

    +

    You can easily create subsets, but you can't easily combine them +with other subsets. Unfortunately, you almost always needs an +explicit type conversion to valarray. This is because the standard +does not specify that valarray subsets provide the same operations as +valarrays.

    + +

    For example, to multiply two subsets and assign the result to a third subset, you can't +write the following:

    + +
    va[slice(0,4,3)] = va[slice(1,4,3)] * va[slice(2,4,3)];
    + +

    Instead, you have to code as follows:

    + +
    va[slice(0,4,3)] = static_cast<valarray<double> >(va[slice(1,4,3)]) * 
+                   static_cast<valarray<double> >(va[slice(2,4,3)]);
    + +

    This is tedious and error-prone. Even worse, it costs performance because each cast +creates a temporary objects, which could be avoided without the cast.

    +

    Proposed resolution:

    +

    Extend all valarray subset types so that they offer all valarray operations.

    +

    Rationale:

    +

    This is not a defect in the Standard; it is a request for an extension.

    +
    +

    94. May library implementors add template parameters to Standard Library classes?

    Section: 17.4.4 [lib.conforming]  Status: NAD  Submitter: Matt Austern  Date: 22 Jan 1998

    +

    Is it a permitted extension for library implementors to add template parameters to +standard library classes, provided that those extra parameters have defaults? For example, +instead of defining template <class T, class Alloc = allocator<T> > class +vector; defining it as template <class T, class Alloc = allocator<T>, +int N = 1> class vector;

    + +

    The standard may well already allow this (I can't think of any way that this extension +could break a conforming program, considering that users are not permitted to +forward-declare standard library components), but it ought to be explicitly permitted or +forbidden.

    + +

    comment from Steve Cleary via comp.std.c++:

    +
    +

    I disagree [with the proposed resolution] for the following reason: +consider user library code with template template parameters. For +example, a user library object may be templated on the type of +underlying sequence storage to use (deque/list/vector), since these +classes all take the same number and type of template parameters; this +would allow the user to determine the performance tradeoffs of the +user library object. A similar example is a user library object +templated on the type of underlying set storage (set/multiset) or map +storage (map/multimap), which would allow users to change (within +reason) the semantic meanings of operations on that object.

    +

    I think that additional template parameters should be forbidden in +the Standard classes. Library writers don't lose any expressive power, +and can still offer extensions because additional template parameters +may be provided by a non-Standard implementation class:

    +
     
+   template <class T, class Allocator = allocator<T>, int N = 1>
+   class __vector
+   { ... };
+   template <class T, class Allocator = allocator<T> >
+   class vector: public __vector<T, Allocator>
+   { ... };
+
    + +
    + +

    Proposed resolution:

    +

    Add a new subclause [presumably 17.4.4.9] following 17.4.4.8 [lib.res.on.exception.handling]:

    + +
    +

    17.4.4.9 Template Parameters

    A specialization of a + template class described in the C++ Standard Library behaves the + same as if the implementation declares no additional template + parameters.

    Footnote: Additional template parameters with + default values are thus permitted.

    +
    + +

    Add "template parameters" to the list of subclauses at +the end of 17.4.4 [lib.conforming] paragraph 1.

    + +

    [Kona: The LWG agreed the standard needs clarification. After +discussion with John Spicer, it seems added template parameters can be +detected by a program using template-template parameters. A straw vote +- "should implementors be allowed to add template +parameters?" found no consensus ; 5 - yes, 7 - no.]

    + +

    Rationale:

    +

    +There is no ambiguity; the standard is clear as written. Library +implementors are not permitted to add template parameters to standard +library classes. This does not fall under the "as if" rule, +so it would be permitted only if the standard gave explicit license +for implementors to do this. This would require a change in the +standard. +

    + +

    +The LWG decided against making this change, because it would break +user code involving template template parameters or specializations +of standard library class templates. +

    +
    +

    95. Members added by the implementation

    Section: 17.4.4.4 [lib.member.functions]  Status: NAD  Submitter: AFNOR  Date: 7 Oct 1998

    +

    In 17.3.4.4/2 vs 17.3.4.7/0 there is a hole; an implementation could add virtual +members a base class and break user derived classes.

    + +

    Example:

    + +
    + 
    // implementation code:
+struct _Base { // _Base is in the implementer namespace
+        virtual void foo ();
+};
+class vector : _Base // deriving from a class is allowed
+{ ... };
+
+// user code:
+class vector_checking : public vector 
+{
+        void foo (); // don't want to override _Base::foo () as the 
+                     // user doesn't know about _Base::foo ()
+};
    +
    +

    Proposed resolution:

    +

    Clarify the wording to make the example illegal.

    +

    Rationale:

    +

    This is not a defect in the Standard.  The example is already +illegal.  See 17.4.4.4 [lib.member.functions] paragraph 2.

    +
    +

    97. Insert inconsistent definition

    Section: 23 [lib.containers]  Status: NAD  Submitter: AFNOR  Date: 7 Oct 1998

    +

    insert(iterator, const value_type&) is defined both on +sequences and on set, with unrelated semantics: insert here (in +sequences), and insert with hint (in associative containers). They +should have different names (B.S. says: do not abuse overloading).

    +

    Proposed resolution:

    +

    Rationale:

    +

    This is not a defect in the Standard. It is a genetic misfortune of +the design, for better or for worse.

    +
    +

    99. Reverse_iterator comparisons completely wrong

    Section: 24.4.1.3.13 [lib.reverse.iter.op==]  Status: NAD  Submitter: AFNOR  Date: 7 Oct 1998

    +

    The <, >, <=, >= comparison operator are wrong: they +return the opposite of what they should.

    + +

    Note: same problem in CD2, these were not even defined in CD1. SGI +STL code is correct; this problem is known since the Morristown +meeting but there it was too late

    +

    Proposed resolution:

    +

    Rationale:

    +

    This is not a defect in the Standard. A careful reading shows the Standard is correct +as written. A review of several implementations show that they implement +exactly what the Standard says.

    +
    +

    100. Insert iterators/ostream_iterators overconstrained

    Section: 24.4.2 [lib.insert.iterators], 24.5.4 [lib.ostreambuf.iterator]  Status: NAD  Submitter: AFNOR  Date: 7 Oct 1998

    +

    Overspecified For an insert iterator it, the expression *it is +required to return a reference to it. This is a simple possible +implementation, but as the SGI STL documentation says, not the only +one, and the user should not assume that this is the case.

    +

    Proposed resolution:

    +

    Rationale:

    +

    The LWG believes this causes no harm and is not a defect in the +standard. The only example anyone could come up with caused some +incorrect code to work, rather than the other way around.

    +
    +

    101. No way to free storage for vector and deque

    Section: 23.2.4 [lib.container.adaptors], 23.2.1 [lib.array]  Status: NAD  Submitter: AFNOR  Date: 7 Oct 1998

    +

    Reserve can not free storage, unlike string::reserve

    +

    Proposed resolution:

    +

    Rationale:

    +

    This is not a defect in the Standard. The LWG has considered this +issue in the past and sees no need to change the Standard. Deque has +no reserve() member function. For vector, shrink-to-fit can be +expressed in a single line of code (where v is +vector<T>): +

    + +
    +

    vector<T>(v).swap(v);  // shrink-to-fit v

    +
    +
    +

    102. Bug in insert range in associative containers

    Section: 23.1.2 [lib.associative.reqmts]  Status: Dup  Submitter: AFNOR  Date: 7 Oct 1998

    +

    Table 69 of Containers say that a.insert(i,j) is linear if [i, j) is ordered. It seems +impossible to implement, as it means that if [i, j) = [x], insert in an associative +container is O(1)!

    +

    Proposed resolution:

    +

    N+log (size()) if [i,j) is sorted according to value_comp()

    +

    Rationale:

    +

    Subsumed by issue 264.

    +
    +

    104. Description of basic_string::operator[] is unclear

    Section: 21.3.4 [lib.string.access]  Status: NAD  Submitter: AFNOR  Date: 7 Oct 1998

    +

    It is not clear that undefined behavior applies when pos == size () +for the non const version.

    +

    Proposed resolution:

    +

    Rewrite as: Otherwise, if pos > size () or pos == size () and +the non-const version is used, then the behavior is undefined.

    +

    Rationale:

    +

    The Standard is correct. The proposed resolution already appears in +the Standard.

    +
    +

    105. fstream ctors argument types desired

    Section: 27.8 [lib.file.streams]  Status: NAD Future  Submitter: AFNOR  Date: 7 Oct 1998

    +

    fstream ctors take a const char* instead of string.
    +fstream ctors can't take wchar_t

    + +

    An extension to add a const wchar_t* to fstream would make the +implementation non conforming.

    +

    Proposed resolution:

    +

    Rationale:

    +

    This is not a defect in the Standard. It might be an +interesting extension for the next Standard.

    +
    +

    107. Valarray constructor is strange

    Section: 26.3.2 [lib.complex]  Status: NAD  Submitter: AFNOR  Date: 7 Oct 1998

    +

    The order of the arguments is (elem, size) instead of the normal +(size, elem) in the rest of the library. Since elem often has an +integral or floating point type, both types are convertible to each +other and reversing them leads to a well formed program.

    +

    Proposed resolution:

    +

    Inverting the arguments could silently break programs. Introduce +the two signatures (const T&, size_t) and (size_t, const T&), +but make the one we do not want private so errors result in a +diagnosed access violation. This technique can also be applied to STL +containers.

    +

    Rationale:

    +

    The LWG believes that while the order of arguments is unfortunate, +it does not constitute a defect in the standard. The LWG believes that +the proposed solution will not work for valarray<size_t> and +perhaps other cases.

    +
    +

    111. istreambuf_iterator::equal overspecified, inefficient

    Section: 24.5.3.5 [lib.istreambuf.iterator::equal]  Status: NAD Future  Submitter: Nathan Myers  Date: 15 Oct 1998

    +

    The member istreambuf_iterator<>::equal is specified to be +unnecessarily inefficient. While this does not affect the efficiency +of conforming implementations of iostreams, because they can +"reach into" the iterators and bypass this function, it does +affect users who use istreambuf_iterators.

    + +

    The inefficiency results from a too-scrupulous definition, which +requires a "true" result if neither iterator is at eof. In +practice these iterators can only usefully be compared with the +"eof" value, so the extra test implied provides no benefit, +but slows down users' code.

    + +

    The solution is to weaken the requirement on the function to return +true only if both iterators are at eof.

    +

    Proposed resolution:

    +

    Replace 24.5.3.5 [lib.istreambuf.iterator::equal], +paragraph 1,

    + +
    +

    -1- Returns: true if and only if both iterators are at end-of-stream, or neither is at + end-of-stream, regardless of what streambuf object they use.

    +
    + +

    with

    + +
    +

    -1- Returns: true if and only if both iterators are at + end-of-stream, regardless of what streambuf object they use.

    +
    + +

    Rationale:

    +

    It is not clear that this is a genuine defect. Additionally, the +LWG was reluctant to make a change that would result in +operator== not being a equivalence relation. One consequence of +this change is that an algorithm that's passed the range [i, i) +would no longer treat it as an empty range.

    +
    +

    113. Missing/extra iostream sync semantics

    Section: 27.6.1.1 [lib.istream], 27.6.1.3 [lib.istream.unformatted]  Status: NAD  Submitter: Steve Clamage  Date: 13 Oct 1998

    +

    In 27.6.1.1, class basic_istream has a member function sync, described in 27.6.1.3, +paragraph 36.

    + +

    Following the chain of definitions, I find that the various sync functions have defined +semantics for output streams, but no semantics for input streams. On the other hand, +basic_ostream has no sync function.

    + +

    The sync function should at minimum be added to basic_ostream, for internal +consistency.

    + +

    A larger question is whether sync should have assigned semantics for input streams.

    + +

    Classic iostreams said streambuf::sync flushes pending output and attempts to return +unread input characters to the source. It is a protected member function. The filebuf +version (which is public) has that behavior (it backs up the read pointer). Class +strstreambuf does not override streambuf::sync, and so sync can't be called on a +strstream.

    + +

    If we can add corresponding semantics to the various sync functions, we should. If not, +we should remove sync from basic_istream.

    +

    Proposed resolution:

    +

    Rationale:

    +

    A sync function is not needed in basic_ostream because the flush function provides the +desired functionality.

    + +

    As for the other points, the LWG finds the standard correct as written.

    +
    +

    116. bitset cannot be constructed with a const char*

    Section: 23.3.5 [lib.template.bitset]  Status: NAD Future  Submitter: Judy Ward  Date: 6 Nov 1998

    +

    The following code does not compile with the EDG compiler:

    + +
    + 
    #include <bitset>
+using namespace std;
+bitset<32> b("111111111");
    +
    + +

    If you cast the ctor argument to a string, i.e.:

    + +
    + 
    bitset<32> b(string("111111111"));
    +
    + +

    then it will compile. The reason is that bitset has the following templatized +constructor:

    + +
    + 
    template <class charT, class traits, class Allocator>
+explicit bitset (const basic_string<charT, traits, Allocator>& str, ...);
    +
    + +

    According to the compiler vendor, Steve Adamcyk at EDG, the user +cannot pass this template constructor a const char* and +expect a conversion to basic_string. The reason is +"When you have a template constructor, it can get used in +contexts where type deduction can be done. Type deduction basically +comes up with exact matches, not ones involving conversions." +

    + +

    I don't think the intention when this constructor became +templatized was for construction from a const char* to no +longer work.

    +

    Proposed resolution:

    +

    Add to 23.3.5 [lib.template.bitset] a bitset constructor declaration

    + +
    + 
    explicit bitset(const char*);
    +
    + +

    and in Section 23.3.5.1 [lib.bitset.cons] add:

    + +
    + 
    explicit bitset(const char* str);
    +

    Effects:
    +     Calls bitset((string) str, 0, string::npos);

    +
    +

    Rationale:

    +

    Although the problem is real, the standard is designed that way so +it is not a defect. Education is the immediate workaround. A future +standard may wish to consider the Proposed Resolution as an +extension.

    +
    +

    121. Detailed definition for ctype<wchar_t> specialization

    Section: 22.1.1.1.1 [lib.locale.category]  Status: NAD  Submitter: Judy Ward  Date: 15 Dec 1998

    +

    Section 22.1.1.1.1 has the following listed in Table 51: ctype<char> , +ctype<wchar_t>.

    + +

    Also Section 22.2.1.1 [lib.locale.ctype] says:

    + +
    +

    The instantiations required in Table 51 (22.1.1.1.1) namely ctype<char> and + ctype<wchar_t> , implement character classing appropriate to the implementation's + native character set.

    +
    + +

    However, Section 22.2.1.3 [lib.facet.ctype.special] +only has a detailed description of the ctype<char> specialization, not the +ctype<wchar_t> specialization.

    +

    Proposed resolution:

    +

    Add the ctype<wchar_t> detailed class description to Section +22.2.1.3 [lib.facet.ctype.special].

    +

    Rationale:

    +

    Specialization for wchar_t is not needed since the default is acceptable.

    +
    +

    128. Need open_mode() function for file stream, string streams, file buffers, and string  buffers

    Section: 27.7 [lib.string.streams], 27.8 [lib.file.streams]  Status: NAD Future  Submitter: Angelika Langer  Date: 22 Feb 1999

    +

    The following question came from Thorsten Herlemann:

    + +
    +

    You can set a mode when constructing or opening a file-stream or + filebuf, e.g. ios::in, ios::out, ios::binary, ... But how can I get + that mode later on, e.g. in my own operator << or operator + >> or when I want to check whether a file-stream or + file-buffer object passed as parameter is opened for input or output + or binary? Is there no possibility? Is this a design-error in the + standard C++ library?

    +
    + +

    It is indeed impossible to find out what a stream's or stream +buffer's open mode is, and without that knowledge you don't know +how certain operations behave. Just think of the append mode.

    + +

    Both streams and stream buffers should have a mode() function that returns the +current open mode setting.

    +

    Proposed resolution:

    +

    For stream buffers, add a function to the base class as a non-virtual function +qualified as const to 27.5.2 [lib.streambuf]:

    + +

        openmode mode() const;

    + +

        Returns the current open mode.

    + +

    With streams, I'm not sure what to suggest. In principle, the mode +could already be returned by ios_base, but the mode is only +initialized for file and string stream objects, unless I'm overlooking +anything. For this reason it should be added to the most derived +stream classes. Alternatively, it could be added to basic_ios +and would be default initialized in basic_ios<>::init().

    +

    Rationale:

    +

    This might be an interesting extension for some future, but it is +not a defect in the current standard. The Proposed Resolution is +retained for future reference.

    +
    +

    131. list::splice throws nothing

    Section: 23.2.2.4 [lib.deque.special]  Status: NAD  Submitter: Howard Hinnant  Date: 6 Mar 1999

    +

    What happens if a splice operation causes the size() of a list to grow +beyond max_size()?

    +

    Proposed resolution:

    +

    Rationale:

    +

    Size() cannot grow beyond max_size(). 

    +
    +

    135. basic_iostream doubly initialized

    Section: 27.6.1.5.1 [lib.iostream.cons]  Status: NAD  Submitter: Howard Hinnant  Date: 6 Mar 1999

    +

    -1- Effects Constructs an object of class basic_iostream, assigning +initial values to the base classes by calling +basic_istream<charT,traits>(sb) (lib.istream) and +basic_ostream<charT,traits>(sb) (lib.ostream)

    + +

    The called for basic_istream and basic_ostream constructors call +init(sb). This means that the basic_iostream's virtual base class is +initialized twice.

    +

    Proposed resolution:

    +

    Change 27.6.1.5.1, paragraph 1 to:

    + +

    -1- Effects Constructs an object of class basic_iostream, assigning +initial values to the base classes by calling +basic_istream<charT,traits>(sb) (lib.istream).

    +

    Rationale:

    +

    The LWG agreed that the init() function is called +twice, but said that this is harmless and so not a defect in the +standard.

    +
    +

    138. Class ctype_byname<char> redundant and misleading

    Section: 22.2.1.4 [lib.locale.codecvt]  Status: NAD Future  Submitter: Angelika Langer  Date: March 18, 1999

    +

    Section 22.2.1.4 [lib.locale.codecvt] specifies that +ctype_byname<char> must be a specialization of the ctype_byname +template.

    + +

    It is common practice in the standard that specializations of class templates are only +mentioned where the interface of the specialization deviates from the interface of the +template that it is a specialization of. Otherwise, the fact whether or not a required +instantiation is an actual instantiation or a specialization is left open as an +implementation detail.

    + +

    Clause 22.2.1.4 deviates from that practice and for that reason is misleading. The +fact, that ctype_byname<char> is specified as a specialization suggests that there +must be something "special" about it, but it has the exact same interface as the +ctype_byname template. Clause 22.2.1.4 does not have any explanatory value, is at best +redundant, at worst misleading - unless I am missing anything.

    + +

    Naturally, an implementation will most likely implement ctype_byname<char> as a +specialization, because the base class ctype<char> is a specialization with an +interface different from the ctype template, but that's an implementation detail and need +not be mentioned in the standard.

    +

    Proposed resolution:

    +

    Rationale:

    +

    The standard as written is mildly misleading, but the correct fix +is to deal with the underlying problem in the ctype_byname base class, +not in the specialization. See issue 228.

    +
    +

    140. map<Key, T>::value_type does not satisfy the assignable requirement

    Section: 23.3.1 [lib.map]  Status: NAD Future  Submitter: Mark Mitchell  Date: 14 Apr 1999

    +
    +

    23.1 [lib.container.requirements]
    +
    + expression         return type +      pre/post-condition
    + -------------     -----------      + -------------------
    + X::value_type    T +                    + T is assignable
    +
    + 23.3.1 [lib.map]
    +
    + A map satisfies all the requirements of a container.
    +
    + For a map<Key, T> ... the value_type is pair<const Key, T>.

    +
    + +

    There's a contradiction here. In particular, `pair<const Key, +T>' is not assignable; the `const Key' cannot be assigned +to. So,  map<Key, T>::value_type does not satisfy the +assignable requirement imposed by a container.

    + +

    [See issue 103 for the slightly related issue of +modification of set keys.]

    +

    Proposed resolution:

    +

    Rationale:

    +

    The LWG believes that the standard is inconsistent, but that this +is a design problem rather than a strict defect. May wish to +reconsider for the next standard.

    +
    +

    143. C .h header wording unclear

    Section: D.5 [depr.c.headers]  Status: NAD  Submitter: Christophe de Dinechin  Date: 4 May 1999

    +

    [depr.c.headers] paragraph 2 reads:

    + +
    + +

    Each C header, whose name has the form name.h, behaves as if each +name placed in the Standard library namespace by the corresponding +cname header is also placed within the namespace scope of the +namespace std and is followed by an explicit using-declaration +(_namespace.udecl_)

    + +
    + +

    I think it should mention the global name space somewhere...  +Currently, it indicates that name placed in std is also placed in +std...

    + +

    I don't know what is the correct wording. For instance, if struct +tm is defined in time.h, ctime declares std::tm. However, the current +wording seems ambiguous regarding which of the following would occur +for use of both ctime and time.h:

    + +
    + 
    // version 1:
+namespace std {
+        struct tm { ... };
+}
+using std::tm;
+
+// version 2:
+struct tm { ... };
+namespace std {
+        using ::tm;
+}
+
+// version 3:
+struct tm { ... };
+namespace std {
+        struct tm { ... };
+}
    +
    + +

    I think version 1 is intended.

    + +

    [Kona: The LWG agreed that the wording is not clear. It also +agreed that version 1 is intended, version 2 is not equivalent to +version 1, and version 3 is clearly not intended. The example below +was constructed by Nathan Myers to illustrate why version 2 is not +equivalent to version 1.

    + +

    Although not equivalent, the LWG is unsure if (2) is enough of +a problem to be prohibited. Points discussed in favor of allowing +(2):

    + +
    +
      +
    • It may be a convenience to implementors.
      • +
    • The only cases that fail are structs, of which the C library + contains only a few.
      • +
    +
    + +

    ]

    + +

    Example:

    + +
    + +
    #include <time.h>
+#include <utility>
+
+int main() {
+    std::tm * t;
+    make_pair( t, t ); // okay with version 1 due to Koenig lookup
+                       // fails with version 2; make_pair not found
+    return 0;
+}
    + +
    +

    Proposed resolution:

    + +

    Replace D.5 [depr.c.headers] paragraph 2 with:

    + +
    + +

    Each C header, whose name has the form name.h, behaves as if each +name placed in the Standard library namespace by the corresponding +cname header is also placed within the namespace scope of the +namespace std by name.h and is followed by an explicit +using-declaration (_namespace.udecl_) in global scope.

    + +
    + +

    Rationale:

    +

    The current wording in the standard is the result of a difficult +compromise that averted delay of the standard. Based on discussions +in Tokyo it is clear that there is no still no consensus on stricter +wording, so the issue has been closed. It is suggested that users not +write code that depends on Koenig lookup of C library functions.

    +
    +

    145. adjustfield lacks default value

    Section: 27.4.4.1 [lib.basic.ios.cons]  Status: NAD  Submitter: Angelika Langer  Date: 12 May 1999

    +

    There is no initial value for the adjustfield defined, although +many people believe that the default adjustment were right. This is a +common misunderstanding. The standard only defines that, if no +adjustment is specified, all the predefined inserters must add fill +characters before the actual value, which is "as if" the +right flag were set. The flag itself need not be set.

    + +

    When you implement a user-defined inserter you cannot rely on right +being the default setting for the adjustfield. Instead, you must be +prepared to find none of the flags set and must keep in mind that in +this case you should make your inserter behave "as if" the +right flag were set. This is surprising to many people and complicates +matters more than necessary.

    + +

    Unless there is a good reason why the adjustfield should not be +initialized I would suggest to give it the default value that +everybody expects anyway.

    + +

    Proposed resolution:

    +

    Rationale:

    +

    This is not a defect. It is deliberate that the default is no bits +set. Consider Arabic or Hebrew, for example. See 22.2.2.2.2 [lib.facet.num.put.virtuals] paragraph 19, Table 61 - Fill padding.

    +
    +

    149. Insert should return iterator to first element inserted

    Section: 23.1.1 [lib.sequence.reqmts]  Status: NAD Future  Submitter: Andrew Koenig  Date: 28 Jun 1999

    +

    Suppose that c and c1 are sequential containers and i is an +iterator that refers to an element of c. Then I can insert a copy of +c1's elements into c ahead of element i by executing

    + +
    + +
    c.insert(i, c1.begin(), c1.end());
    + +
    + +

    If c is a vector, it is fairly easy for me to find out where the +newly inserted elements are, even though i is now invalid:

    + +
    + +
    size_t i_loc = i - c.begin();
+c.insert(i, c1.begin(), c1.end());
    + +
    + +

    and now the first inserted element is at c.begin()+i_loc and one +past the last is at c.begin()+i_loc+c1.size().
    +
    +But what if c is a list? I can still find the location of one past the +last inserted element, because i is still valid. To find the location +of the first inserted element, though, I must execute something like

    + +
    + +
    for (size_t n = c1.size(); n; --n)
+   --i;
    + +
    + +

    because i is now no longer a random-access iterator.
    +
    +Alternatively, I might write something like

    + +
    + +
    bool first = i == c.begin();
+list<T>::iterator j = i;
+if (!first) --j;
+c.insert(i, c1.begin(), c1.end());
+if (first)
+   j = c.begin();
+else
+   ++j;
    + +
    + +

    which, although wretched, requires less overhead.
    +
    +But I think the right solution is to change the definition of insert +so that instead of returning void, it returns an iterator that refers +to the first element inserted, if any, and otherwise is a copy of its +first argument. 

    +

    Proposed resolution:

    +

    Rationale:

    +

    The LWG believes this was an intentional design decision and so is +not a defect. It may be worth revisiting for the next standard.

    +
    +

    157. Meaningless error handling for pword() and iword() +

    Section: 27.4.2.5 [lib.ios.base.storage]  Status: Dup  Submitter: Dietmar Kühl  Date: 20 Jul 1999

    +

    According to paragraphs 2 and 4 of 27.4.2.5 [lib.ios.base.storage], the +functions iword() and pword() "set the +badbit (which might throw an exception)" on +failure. ... but what does it mean for ios_base to set the +badbit? The state facilities of the IOStream library are +defined in basic_ios, a derived class! It would be possible +to attempt a down cast but then it would be necessary to know the +character type used...

    +

    Proposed resolution:

    +

    Rationale:

    +

    Duplicate. See issue 41.

    +
    +

    162. Really "formatted input functions"?

    Section: 27.6.1.2.3 [lib.istream::extractors]  Status: Dup  Submitter: Dietmar Kühl  Date: 20 Jul 1999

    +

    It appears to be somewhat nonsensical to consider the functions +defined in the paragraphs 1 to 5 to be "Formatted input +function" but since these functions are defined in a section +labeled "Formatted input functions" it is unclear to me +whether these operators are considered formatted input functions which +have to conform to the "common requirements" from 27.6.1.2.1 [lib.istream.formatted.reqmts]: If this is the case, all manipulators, not just +ws, would skip whitespace unless noskipws is set +(... but setting noskipws using the manipulator syntax would +also skip whitespace :-)

    + +

    See also issue 166 for the same problem in formatted +output

    +

    Proposed resolution:

    +

    Rationale:

    +

    Duplicate. See issue 60.

    +
    +

    163. Return of gcount() after a call to gcount +

    Section: 27.6.1.3 [lib.istream.unformatted]  Status: Dup  Submitter: Dietmar Kühl  Date: 20 Jul 1999

    +

    It is not clear which functions are to be considered unformatted +input functions. As written, it seems that all functions in 27.6.1.3 [lib.istream.unformatted] are unformatted input functions. However, it does not +really make much sense to construct a sentry object for +gcount(), sync(), ... Also it is unclear what +happens to the gcount() if eg. gcount(), +putback(), unget(), or sync() is called: +These functions don't extract characters, some of them even +"unextract" a character. Should this still be reflected in +gcount()? Of course, it could be read as if after a call to +gcount() gcount() return 0 (the last +unformatted input function, gcount(), didn't extract any +character) and after a call to putback() gcount() +returns -1 (the last unformatted input function +putback() did "extract" back into the +stream). Correspondingly for unget(). Is this what is +intended? If so, this should be clarified. Otherwise, a corresponding +clarification should be used.

    +

    Proposed resolution:

    +

    Rationale:

    +

    Duplicate.  See issue 60.

    +
    +

    166. Really "formatted output functions"?

    Section: 27.6.2.5.3 [lib.ostream.inserters]  Status: Dup  Submitter: Dietmar Kühl  Date: 20 Jul 1999

    +

    From 27.6.2.5.1 [lib.ostream.formatted.reqmts] it appears that all the functions +defined in 27.6.2.5.3 [lib.ostream.inserters] have to construct a +sentry object. Is this really intended?

    + +

    This is basically the same problem as issue 162 but +for output instead of input.

    +

    Proposed resolution:

    +

    Rationale:

    +

    Duplicate. See issue 60.

    +
    +

    177. Complex operators cannot be explicitly instantiated

    Section: 26.3.6 [lib.complex.ops]  Status: NAD  Submitter: Judy Ward  Date: 2 Jul 1999

    +

    A user who tries to explicitly instantiate a complex non-member operator will +get compilation errors. Below is a simplified example of the reason why. The +problem is that iterator_traits cannot be instantiated on a non-pointer type +like float, yet when the compiler is trying to decide which operator+ needs to +be instantiated it must instantiate the declaration to figure out the first +argument type of a reverse_iterator operator.

    +
    namespace std {
+template <class Iterator> 
+struct iterator_traits
+{
+    typedef typename Iterator::value_type value_type;
+};
+
+template <class T> class reverse_iterator;
+
+// reverse_iterator operator+
+template <class T> 
+reverse_iterator<T> operator+
+(typename iterator_traits<T>::difference_type, const reverse_iterator<T>&);
+
+template <class T> struct complex {};
+
+// complex operator +
+template <class T>
+complex<T> operator+ (const T& lhs, const complex<T>& rhs) 
+{ return complex<T>();} 
+}
+
+// request for explicit instantiation
+template std::complex<float> std::operator+<float>(const float&, 
+     const std::complex<float>&);
    +

    See also c++-stdlib reflector messages: lib-6814, 6815, 6816.

    +

    Proposed resolution:

    +

    Rationale:

    +

    Implementors can make minor changes and the example will +work. Users are not affected in any case.

    According to John +Spicer, It is possible to explicitly instantiate these operators using +different syntax: change "std::operator+<float>" to +"std::operator+".

    + +

    The proposed resolution of issue 120 is that users will not be able +to explicitly instantiate standard library templates. If that +resolution is accepted then library implementors will be the only ones +that will be affected by this problem, and they must use the indicated +syntax.

    +
    +

    178. Should clog and cerr initially be tied to cout?

    Section: 27.3.1 [lib.narrow.stream.objects]  Status: NAD  Submitter: Judy Ward  Date: 2 Jul 1999

    +

    +Section 27.3.1 says "After the object cerr is initialized, +cerr.flags() & unitbuf is nonzero. Its state is otherwise the same as +required for ios_base::init (lib.basic.ios.cons). It doesn't say +anything about the the state of clog. So this means that calling +cerr.tie() and clog.tie() should return 0 (see Table 89 for +ios_base::init effects). +

    +

    +Neither of the popular standard library implementations +that I tried does this, they both tie cerr and clog +to &cout. I would think that would be what users expect. +

    +

    Proposed resolution:

    +

    Rationale:

    +

    The standard is clear as written.

    +

    27.3.1/5 says that "After the object cerr is initialized, cerr.flags() +& unitbuf is nonzero. Its state is otherwise the same as required for +ios_base::init (27.4.4.1)." Table 89 in 27.4.4.1, which gives the +postconditions of basic_ios::init(), says that tie() is 0. (Other issues correct +ios_base::init to basic_ios::init().)

    +
    +

    180. Container member iterator arguments constness has unintended consequences

    Section: 23 [lib.containers]  Status: NAD Future  Submitter: Dave Abrahams  Date: 1 Jul 1999

    +

    It is the constness of the container which should control whether +it can be modified through a member function such as erase(), not the +constness of the iterators. The iterators only serve to give +positioning information.

    + +

    Here's a simple and typical example problem which is currently very +difficult or impossible to solve without the change proposed +below.

    + +

    Wrap a standard container C in a class W which allows clients to +find and read (but not modify) a subrange of (C.begin(), C.end()]. The +only modification clients are allowed to make to elements in this +subrange is to erase them from C through the use of a member function +of W.

    +

    Proposed resolution:

    +

    Change all non-const iterator parameters of standard library +container member functions to accept const_iterator parameters. +Note that this change applies to all library clauses, including +strings.

    + +

    For example, in 21.3.5.5 change:
    +
    +       iterator erase(iterator p);
    +
    +to:
    +       iterator erase(const_iterator p); +

    +

    Rationale:

    +

    The issue was discussed at length. It was generally agreed that 1) +There is no major technical argument against the change (although +there is a minor argument that some obscure programs may break), and +2) Such a change would not break const correctness. The concerns about +making the change were 1) it is user detectable (although only in +boundary cases), 2) it changes a large number of signatures, and 3) it +seems more of a design issue that an out-and-out defect.

    + +

    The LWG believes that this issue should be considered as part of a +general review of const issues for the next revision of the +standard. Also see issue 200.

    +
    +

    188. valarray helpers missing augmented assignment operators

    Section: 26.5.2.6 [lib.valarray.cassign]  Status: NAD Future  Submitter: Gabriel Dos Reis  Date: 15 Aug 1999

    +

    26.5.2.6 defines augmented assignment operators +valarray<T>::op=(const T&), but fails to provide +corresponding versions for the helper classes. Thus making the +following illegal:

    +
    +
    #include <valarray>
+
+int main()
+{
+std::valarray<double> v(3.14, 1999);
+
+v[99] *= 2.0; // Ok
+
+std::slice s(0, 50, 2);
+
+v[s] *= 2.0; // ERROR
+}
    +
    +

    I can't understand the intent of that omission. It makes the +valarray library less intuitive and less useful.

    +

    Proposed resolution:

    +

    Rationale:

    +

    Although perhaps an unfortunate +design decision, the omission is not a defect in the current +standard.  A future standard may wish to add the missing +operators.

    +
    +

    190. min() and max() functions should be std::binary_functions

    Section: 25.3.7 [lib.alg.min.max]  Status: NAD Future  Submitter: Mark Rintoul  Date: 26 Aug 1999

    +

    Both std::min and std::max are defined as template functions. This +is very different than the definition of std::plus (and similar +structs) which are defined as function objects which inherit +std::binary_function.
    +
    + This lack of inheritance leaves std::min and std::max somewhat useless in standard library algorithms which require +a function object that inherits std::binary_function.

    +

    Proposed resolution:

    +

    Rationale:

    +

    Although perhaps an unfortunate design decision, the omission is not a defect +in the current standard.  A future standard may wish to consider additional +function objects.

    +
    +

    191. Unclear complexity for algorithms such as binary search

    Section: 25.3.3 [lib.alg.binary.search]  Status: NAD  Submitter: Nico Josuttis  Date: 10 Oct 1999

    +

    The complexity of binary_search() is stated as "At most +log(last-first) + 2 comparisons", which seems to say that the +algorithm has logarithmic complexity. However, this algorithms is +defined for forward iterators. And for forward iterators, the need to +step element-by-element results into linear complexity. But such a +statement is missing in the standard. The same applies to +lower_bound(), upper_bound(), and equal_range(). 
    +
    +However, strictly speaking the standard contains no bug here. So this +might considered to be a clarification or improvement. +

    +

    Proposed resolution:

    +

    Rationale:

    +

    The complexity is expressed in terms of comparisons, and that +complexity can be met even if the number of iterators accessed is +linear. Paragraph 1 already says exactly what happens to +iterators.

    +
    +

    192. a.insert(p,t) is inefficient and overconstrained

    Section: 23.1.2 [lib.associative.reqmts]  Status: NAD  Submitter: Ed Brey  Date: 6 Jun 1999

    +

    As defined in 23.1.2, paragraph 7 (table 69), a.insert(p,t) suffers from +several problems:

    + + + + + + + + + + + + + +
    expressionreturn typepre/post-conditioncomplexity
    a.insert(p,t)iteratorinserts t if and only if there is no element with key equivalent to the key of + t in containers with unique keys; always inserts t in containers with equivalent + keys. always returns the iterator pointing to the element with key equivalent to + the key of t . iterator p is a hint pointing to where the insert should start to search.logarithmic in general, but amortized constant if t is inserted right after p .
    +

    1. For a container with unique keys, only logarithmic complexity is +guaranteed if no element is inserted, even though constant complexity is always +possible if p points to an element equivalent to t.

    +

    2. For a container with equivalent keys, the amortized constant complexity +guarantee is only useful if no key equivalent to t exists in the container. +Otherwise, the insertion could occur in one of multiple locations, at least one +of which would not be right after p.

    +

    3. By guaranteeing amortized constant complexity only when t is inserted +after p, it is impossible to guarantee constant complexity if t is inserted at +the beginning of the container. Such a problem would not exist if amortized +constant complexity was guaranteed if t is inserted before p, since there is +always some p immediately before which an insert can take place.

    +

    4. For a container with equivalent keys, p does not allow specification of +where to insert the element, but rather only acts as a hint for improving +performance. This negates the added functionality that p would provide if it +specified where within a sequence of equivalent keys the insertion should occur. +Specifying the insert location provides more control to the user, while +providing no disadvantage to the container implementation.

    +

    Proposed resolution:

    +

    In 23.1.2 [lib.associative.reqmts] paragraph 7, replace the row in table 69 +for a.insert(p,t) with the following two rows:

    + + + + + + + + + + + + + + + + + + + +
    expressionreturn typepre/post-conditioncomplexity
    a_uniq.insert(p,t)iteratorinserts t if and only if there is no element with key equivalent to the + key of t. returns the iterator pointing to the element with key equivalent + to the key of t.logarithmic in general, but amortized constant if t is inserted right + before p or p points to an element with key equivalent to t.
    a_eq.insert(p,t)iteratorinserts t and returns the iterator pointing to the newly inserted + element. t is inserted right before p if doing so preserves the container + ordering.logarithmic in general, but amortized constant if t is inserted right + before p.
    + +

    Rationale:

    +

    Too big a change.  Furthermore, implementors report checking +both before p and after p, and don't want to change this behavior.

    +
    +

    194. rdbuf() functions poorly specified

    Section: 27.4.4 [lib.ios]  Status: NAD  Submitter: Steve Clamage  Date: 7 Sep 1999

    +

    In classic iostreams, base class ios had an rdbuf function that returned a +pointer to the associated streambuf. Each derived class had its own rdbuf +function that returned a pointer of a type reflecting the actual type derived +from streambuf. Because in ARM C++, virtual function overrides had to have the +same return type, rdbuf could not be virtual.

    +

    In standard iostreams, we retain the non-virtual rdbuf function design, and +in addition have an overloaded rdbuf function that sets the buffer pointer. +There is no need for the second function to be virtual nor to be implemented in +derived classes.

    +

    Minor question: Was there a specific reason not to make the original rdbuf +function virtual?

    +

    Major problem: Friendly compilers warn about functions in derived classes +that hide base-class overloads. Any standard implementation of iostreams will +result in such a warning on each of the iostream classes, because of the +ill-considered decision to overload rdbuf only in a base class.

    +

    In addition, users of the second rdbuf function must use explicit +qualification or a cast to call it from derived classes. An explicit +qualification or cast to basic_ios would prevent access to any later overriding +version if there was one.

    +

    What I'd like to do in an implementation is add a using- declaration for the +second rdbuf function in each derived class. It would eliminate warnings about +hiding functions, and would enable access without using explicit qualification. +Such a change I don't think would change the behavior of any valid program, but +would allow invalid programs to compile:

    +
    + 
     filebuf mybuf;
+ fstream f;
+ f.rdbuf(mybuf); // should be an error, no visible rdbuf
    +
    +

    I'd like to suggest this problem as a defect, with the proposed resolution to +require the equivalent of a using-declaration for the rdbuf function that is not +replaced in a later derived class. We could discuss whether replacing the +function should be allowed.

    +

    Proposed resolution:

    +

    Rationale:

    +

    For historical reasons, the standard is correct as written. There is a subtle difference between the base +class rdbuf() and derived class rdbuf(). The derived +class rdbuf() always returns the original streambuf, whereas the base class + rdbuf() will return the "current streambuf" if that has been changed by the variant you mention.

    + +

    Permission is not required to add such an extension. See +17.4.4.4 [lib.member.functions].

    +
    +

    196. Placement new example has alignment problems

    Section: 18.5.1.3 [lib.new.delete.placement]  Status: Dup  Submitter: Herb Sutter  Date: 15 Dec 1998

    +

    The example in 18.5.1.3 [lib.new.delete.placement] paragraph 4 reads:

    + +
    + +

    [Example: This can be useful for constructing an object at a known address:
    +
    +   char place[sizeof(Something)];
    +   Something* p = new (place) Something();
    +
    +    end example]

    + +
    + +

    This example has potential alignment problems.

    +

    Proposed resolution:

    +

    Rationale:

    +

    Duplicate: see issue 114.

    +
    +

    197. max_size() underspecified

    Section: 20.1.5 [lib.default.con.req], 23.1 [lib.container.requirements]  Status: NAD  Submitter: Andy Sawyer  Date: 21 Oct 1999

    +

    Must the value returned by max_size() be unchanged from call to call?

    + +

    Must the value returned from max_size() be meaningful?

    + +

    Possible meanings identified in lib-6827:

    + +

    1) The largest container the implementation can support given "best +case" conditions - i.e. assume the run-time platform is "configured to +the max", and no overhead from the program itself. This may possibly +be determined at the point the library is written, but certainly no +later than compile time.
    +
    +2) The largest container the program could create, given "best case" +conditions - i.e. same platform assumptions as (1), but take into +account any overhead for executing the program itself. (or, roughly +"storage=storage-sizeof(program)"). This does NOT include any resource +allocated by the program. This may (or may not) be determinable at +compile time.
    +
    +3) The largest container the current execution of the program could +create, given knowledge of the actual run-time platform, but again, +not taking into account any currently allocated resource. This is +probably best determined at program start-up.
    +
    +4) The largest container the current execution program could create at +the point max_size() is called (or more correctly at the point +max_size() returns :-), given it's current environment (i.e. taking +into account the actual currently available resources). This, +obviously, has to be determined dynamically each time max_size() is +called.

    +

    Proposed resolution:

    +

    Rationale:

    +

    max_size() isn't useful for very many things, and the existing + wording is sufficiently clear for the few cases that max_size() can + be used for. None of the attempts to change the existing wording + were an improvement.

    + +

    It is clear to the LWG that the value returned by max_size() can't + change from call to call.

    + +
    +

    203. basic_istream::sentry::sentry() is uninstantiable with ctype<user-defined type>

    Section: 27.6.1.1.2 [lib.istream::sentry]  Status: NAD  Submitter: Matt McClure and Dietmar Kühl  Date: 1 Jan 2000

    +

    27.6.1.1.2 Paragraph 4 states:

    +
    +

    To decide if the character c is a whitespace character, the constructor + performs ''as if'' it executes the following code fragment: 

    + 
    const ctype<charT>& ctype = use_facet<ctype<charT> >(is.getloc());
+if (ctype.is(ctype.space,c)!=0)
+// c is a whitespace character.
    +
    + +

    But Table 51 in 22.1.1.1.1 only requires an implementation to +provide specializations for ctype<char> and +ctype<wchar_t>. If sentry's constructor is implemented using +ctype, it will be uninstantiable for a user-defined character type +charT, unless the implementation has provided non-working (since it +would be impossible to define a correct ctype<charT> specialization +for an arbitrary charT) definitions of ctype's virtual member +functions.

    + +

    +It seems the intent the standard is that sentry should behave, in +every respect, not just during execution, as if it were implemented +using ctype, with the burden of providing a ctype specialization +falling on the user. But as it is written, nothing requires the +translation of sentry's constructor to behave as if it used the above +code, and it would seem therefore, that sentry's constructor should be +instantiable for all character types. +

    + +

    +Note: If I have misinterpreted the intent of the standard with +respect to sentry's constructor's instantiability, then a note should +be added to the following effect: +

    + +
    +An implementation is forbidden from using the above code if it renders +the constructor uninstantiable for an otherwise valid character +type. +
    + +

    In any event, some clarification is needed.

    + +

    Proposed resolution:

    +

    Rationale:

    +

    It is possible but not easy to instantiate on types other than char +or wchar_t; many things have to be done first. That is by intention +and is not a defect.

    +
    +

    204. distance(first, last) when "last" is before "first"

    Section: 24.3.4 [lib.iterator.operations]  Status: NAD  Submitter: Rintala Matti  Date: 28 Jan 2000

    +

    Section 24.3.4 describes the function distance(first, last) (where first and +last are iterators) which calculates "the number of increments or +decrements needed to get from 'first' to 'last'".

    +

    The function should work for forward, bidirectional and random access +iterators, and there is a requirement 24.3.4.5 which states that "'last' +must be reachable from 'first'".

    +

    With random access iterators the function is easy to implement as "last +- first".

    +

    With forward iterators it's clear that 'first' must point to a place before +'last', because otherwise 'last' would not be reachable from 'first'.

    +

    But what about bidirectional iterators? There 'last' is reachable from +'first' with the -- operator even if 'last' points to an earlier position than +'first'. However, I cannot see how the distance() function could be implemented +if the implementation does not know which of the iterators points to an earlier +position (you cannot use ++ or -- on either iterator if you don't know which +direction is the "safe way to travel").

    +

    The paragraph 24.3.4.1 states that "for ... bidirectional iterators they +use ++ to provide linear time implementations". However, the ++ operator is +not mentioned in the reachability requirement. Furthermore 24.3.4.4 explicitly +mentions that distance() returns the number of increments _or decrements_, +suggesting that it could return a negative number also for bidirectional +iterators when 'last' points to a position before 'first'.

    +

    Is a further requirement is needed to state that for forward and +bidirectional iterators "'last' must be reachable from 'first' using the ++ +operator". Maybe this requirement might also apply to random access +iterators so that distance() would work the same way for every iterator +category?

    +

    Proposed resolution:

    +

    Rationale:

    +

    "Reachable" is defined in the standard in 24.1 [lib.iterator.requirements] paragraph 6. +The definition is only in terms of operator++(). The LWG sees no defect in +the standard.

    +
    +

    205.  numeric_limits unclear on how to determine floating point types

    Section: 18.2.1.2 [lib.numeric.limits.members]  Status: NAD  Submitter: Steve Cleary  Date: 28 Jan 2000

    +

    In several places in 18.2.1.2 [lib.numeric.limits.members], a member is +described as "Meaningful for all floating point types." +However, no clear method of determining a floating point type is +provided.

    + +

    In 18.2.1.5 [lib.numeric.special], paragraph 1 states ". . . (for +example, epsilon() is only meaningful if is_integer is +false). . ." which suggests that a type is a floating point type +if is_specialized is true and is_integer is false; however, this is +unclear.

    + +

    When clarifying this, please keep in mind this need of users: what +exactly is the definition of floating point? Would a fixed point or +rational representation be considered one? I guess my statement here +is that there could also be types that are neither integer or +(strictly) floating point.

    +

    Proposed resolution:

    +

    Rationale:

    +

    It is up to the implementor of a user define type to decide if it is a +floating point type.

    +
    +

    207. ctype<char> members return clause incomplete

    Section: 22.2.1.3.2 [lib.facet.ctype.char.members]  Status: Dup  Submitter: Robert Klarer  Date: 2 Nov 1999

    +

    +The widen and narrow member functions are described +in 22.2.1.3.2, paragraphs 9-11. In each case we have two overloaded +signatures followed by a Returns clause. The Returns +clause only describes one of the overloads. +

    +

    Proposed resolution:

    +

    Change the returns clause in 22.2.1.3.2 [lib.facet.ctype.char.members] +paragraph 10 from:

    +

        Returns: do_widen(low, high, to).

    + +

    to:

    +

        Returns: do_widen(c) or do_widen(low, high, to), +respectively.

    + +

    Change the returns clause in 22.2.1.3.2 [lib.facet.ctype.char.members] paragraph 11 +from:

    +

        Returns: do_narrow(low, high, to).

    + +

    to:

    +

        Returns: do_narrow(c) or do_narrow(low, high, to), +respectively.

    +

    Rationale:

    +

    Subsumed by issue 153, which addresses the same +paragraphs.

    +
    +

    213. Math function overloads ambiguous

    Section: 26.5 [lib.numarray]  Status: NAD  Submitter: Nico Josuttis  Date: 26 Feb 2000

    +

    Due to the additional overloaded versions of numeric functions for +float and long double according to Section 26.5, calls such as int x; +std::pow (x, 4) are ambiguous now in a standard conforming +implementation. Current implementations solve this problem very +different (overload for all types, don't overload for float and long +double, use preprocessor, follow the standard and get +ambiguities).

    This behavior should be standardized or at least +identified as implementation defined.

    +

    Proposed resolution:

    +

    Rationale:

    +

    These math issues are an +understood and accepted consequence of the design. They have +been discussed several times in the past. Users must write casts +or write floating point expressions as arguments.

    +
    +

    215. Can a map's key_type be const?

    Section: 23.1.2 [lib.associative.reqmts]  Status: NAD  Submitter: Judy Ward  Date: 29 Feb 2000

    +

    A user noticed that this doesn't compile with the Rogue Wave library because +the rb_tree class declares a key_allocator, and allocator<const int> is +not legal, I think:

    +
    + 
    map < const int, ... > // legal?
    +
    +

    which made me wonder whether it is legal for a map's key_type to be const. In +email from Matt Austern he said:

    +
    +

    I'm not sure whether it's legal to declare a map with a const key type. I +hadn't thought about that question until a couple weeks ago. My intuitive +feeling is that it ought not to be allowed, and that the standard ought to say +so. It does turn out to work in SGI's library, though, and someone in the +compiler group even used it. Perhaps this deserves to be written up as an issue +too.

    +
    +

    Proposed resolution:

    +

    Rationale:

    +

    The "key is assignable" requirement from table 69 in +23.1.2 [lib.associative.reqmts] already implies the key cannot be const.

    +
    +

    216. setbase manipulator description flawed

    Section: 27.6.3 [lib.std.manip]  Status: Dup  Submitter: Hyman Rosen  Date: 29 Feb 2000

    +

    27.6.3 [lib.std.manip] paragraph 5 says:

    +
    +
    smanip setbase(int base);
    +

    Returns: An object s of unspecified type such that if out is an +(instance of) basic_ostream then the expression out<<s behaves +as if f(s) were called, in is an (instance of) basic_istream then the +expression in>>s behaves as if f(s) were called. Where f can be +defined as:

    +
    ios_base& f(ios_base& str, int base)
+{
+  // set basefield
+  str.setf(n == 8 ? ios_base::oct :
+                n == 10 ? ios_base::dec :
+                n == 16 ? ios_base::hex :
+                  ios_base::fmtflags(0), ios_base::basefield);
+  return str;
+}
    +
    +

    There are two problems here. First, f takes two parameters, so the +description needs to say that out<<s and in>>s behave as if f(s,base) +had been called. Second, f is has a parameter named base, but is written as if +the parameter was named n.

    +

    Actually, there's a third problem. The paragraph has grammatical errors. +There needs to be an "and" after the first comma, and the "Where +f" sentence fragment needs to be merged into its preceding sentence. You +may also want to format the function a little better. The formatting above is +more-or-less what the Standard contains.

    +

    Proposed resolution:

    +

    Rationale:

    +

    The resolution of this defect is subsumed by the proposed resolution for +issue 193.

    + +

    [Tokyo: The LWG agrees that this is a defect and notes that it +occurs additional places in the section, all requiring fixes.]

    +
    +

    218. Algorithms do not use binary predicate objects for default comparisons

    Section: 25.3 [lib.alg.sorting]  Status: NAD  Submitter: Pablo Halpern  Date: 6 Mar 2000

    +

    Many of the algorithms take an argument, pred, of template parameter type +BinaryPredicate or an argument comp of template parameter type Compare. These +algorithms usually have an overloaded version that does not take the predicate +argument. In these cases pred is usually replaced by the use of operator== and +comp is replaced by the use of operator<.

    +

    This use of hard-coded operators is inconsistent with other parts of the +library, particularly the containers library, where equality is established +using equal_to<> and ordering is established using less<>. Worse, +the use of operator<, would cause the following innocent-looking code to have +undefined behavior:

    +
    + 
    vector<string*> vec;
+sort(vec.begin(), vec.end());
    +
    +

    The use of operator< is not defined for pointers to unrelated objects. If +std::sort used less<> to compare elements, then the above code would be +well-defined, since less<> is explicitly specialized to produce a total +ordering of pointers.

    +

    Proposed resolution:

    +

    Rationale:

    +

    This use of operator== and operator< was a very deliberate, conscious, and +explicitly made design decision; these operators are often more efficient. The +predicate forms are available for users who don't want to rely on operator== and +operator<.

    +
    +

    219. find algorithm missing version that takes a binary predicate argument

    Section: 25.1.2 [lib.alg.find]  Status: NAD Future  Submitter: Pablo Halpern  Date: 6 Mar 2000

    +

    The find function always searches for a value using operator== to compare the +value argument to each element in the input iterator range. This is inconsistent +with other find-related functions such as find_end and find_first_of, which +allow the caller to specify a binary predicate object to be used for determining +equality. The fact that this can be accomplished using a combination of find_if +and bind_1st or bind_2nd does not negate the desirability of a consistent, +simple, alternative interface to find.

    +

    Proposed resolution:

    +
    +

    In section 25.1.2 [lib.alg.find], add a second prototype for find +(between the existing prototype and the prototype for find_if), as +follows:

    +
        template<class InputIterator, class T, class BinaryPredicate>
+      InputIterator find(InputIterator first, InputIterator last,
+                         const T& value, BinaryPredicate bin_pred);
    +

    Change the description of the return from:

    +
    +

    Returns: The first iterator i in the range [first, last) for which the following corresponding + conditions hold: *i == value, pred(*i) != false. Returns last if no such iterator is found.

    +
    +

     to:

    +
    +

    Returns: The first iterator i in the range [first, last) for which the following  + corresponding condition holds: *i == value, bin_pred(*i,value) != false, pred(*) + != false. Return last if no such iterator is found.

    +
    +
    +

    Rationale:

    +

    This is request for a pure extension, so it is not a defect in the +current standard.  As the submitter pointed out, "this can +be accomplished using a combination of find_if and bind_1st or +bind_2nd".

    +
    +

    236. ctype<char>::is() member modifies facet

    Section: 22.2.1.3.2 [lib.facet.ctype.char.members]  Status: Dup  Submitter: Dietmar Kühl  Date: 24 Apr 2000

    +

    The description of the is() member in paragraph 4 of 22.2.1.3.2 [lib.facet.ctype.char.members] is broken: According to this description, the +second form of the is() method modifies the masks in the +ctype object. The correct semantics if, of course, to obtain +an array of masks. The corresponding method in the general case, +ie. the do_is() method as described in 22.2.1.1.2 [lib.locale.ctype.virtuals] paragraph 1 does the right thing.

    +

    Proposed resolution:

    +

    Change paragraph 4 from

    +
    + The second form, for all *p in the range [low, high), assigns + vec[p-low] to table()[(unsigned char)*p]. +
    +

    to become

    +
    + The second form, for all *p in the range [low, high), assigns + table()[(unsigned char)*p] to vec[p-low]. +
    +

    Rationale:

    +

    Duplicate. See issue 28.

    +
    +

    244. Must find's third argument be CopyConstructible?

    Section: 25.1.2 [lib.alg.find]  Status: NAD  Submitter: Andrew Koenig  Date: 02 May 2000

    +

    Is the following implementation of find acceptable?

    + +
            template<class Iter, class X>
+        Iter find(Iter begin, Iter end, const X& x)
+        {
+            X x1 = x;           // this is the crucial statement
+            while (begin != end && *begin != x1)
+                ++begin;
+            return begin;
+        }
+
    + +

    If the answer is yes, then it is implementation-dependent as to +whether the following fragment is well formed:

    + +
            vector<string> v;
+
+        find(v.begin(), v.end(), "foo");
+
    + +

    At issue is whether there is a requirement that the third argument +of find be CopyConstructible. There may be no problem here, but +analysis is necessary.

    +

    Proposed resolution:

    +

    Rationale:

    +

    There is no indication in the standard that find's third argument +is required to be Copy Constructible. The LWG believes that no such +requirement was intended. As noted above, there are times when a user +might reasonably pass an argument that is not Copy Constructible.

    +
    +

    245. Which operations on istream_iterator trigger input operations?

    Section: 24.5.1 [lib.istream.iterator]  Status: NAD  Submitter: Andrew Koenig  Date: 02 May 2000

    +

    I do not think the standard specifies what operation(s) on istream +iterators trigger input operations. So, for example:

    + +
            istream_iterator<int> i(cin);
+
+        int n = *i++;
+
    + +

    I do not think it is specified how many integers have been read +from cin. The number must be at least 1, of course, but can it be 2? +More?

    +

    Proposed resolution:

    +

    Rationale:

    +

    The standard is clear as written: the stream is read every time +operator++ is called, and it is also read either when the iterator is +constructed or when operator* is called for the first time. In the +example above, exactly two integers are read from cin.

    + +

    There may be a problem with the interaction between istream_iterator +and some STL algorithms, such as find. There are no guarantees about +how many times find may invoke operator++.

    +
    +

    246. a.insert(p,t) is incorrectly specified

    Section: 23.1.2 [lib.associative.reqmts]  Status: Dup  Submitter: Mark Rodgers  Date: 19 May 2000

    +

    Closed issue 192 raised several problems with the specification of +this function, but was rejected as Not A Defect because it was too big +a change with unacceptable impacts on existing implementations. +However, issues remain that could be addressed with a smaller change +and with little or no consequent impact.

    + +
      +
    1. +

      The specification is inconsistent with the original + proposal and with several implementations.

      + +

      The initial implementation by Hewlett Packard only ever looked + immediately before p, and I do not believe there was any + intention to standardize anything other than this behavior. + Consequently, current implementations by several leading + implementors also look immediately before p, and will only insert + after p in logarithmic time. I am only aware of one implementation + that does actually look after p, and it looks before p as well. It + is therefore doubtful that existing code would be relying on the + behavior defined in the standard, and it would seem that fixing + this defect as proposed below would standardize existing + practice.

      +
      2. + +
    2. +

      + The specification is inconsistent with insertion for sequence + containers.

      + +

      This is difficult and confusing to teach to newcomers. All + insert operations that specify an iterator as an insertion location + should have a consistent meaning for the location represented by + that iterator.

      +
      3. + +
    3. +

      As specified, there is no way to hint that the insertion + should occur at the beginning of the container, and the way to hint + that it should occur at the end is long winded and unnatural.

      + +

      For a container containing n elements, there are n+1 possible + insertion locations and n+1 valid iterators. For there to be a + one-to-one mapping between iterators and insertion locations, the + iterator must represent an insertion location immediately before + the iterator.

      +
      4. + +
    4. +

      When appending sorted ranges using insert_iterators, + insertions are guaranteed to be sub-optimal.

      + +

      In such a situation, the optimum location for insertion is + always immediately after the element previously inserted. The + mechanics of the insert iterator guarantee that it will try and + insert after the element after that, which will never be correct. + However, if the container first tried to insert before the hint, + all insertions would be performed in amortized constant + time.

      +
      5. +
    +

    Proposed resolution:

    +

    In 23.1.2 [lib.associative.reqmts] paragraph 7, table 69, make +the following changes in the row for a.insert(p,t):

    + +

    assertion/note pre/post condition: +
    Change the last sentence from

    +
    + "iterator p is a hint pointing to where the insert should + start to search." +
    +

    to

    +
    + "iterator p is a hint indicating that immediately before p + may be a correct location where the insertion could occur." +
    + +

    complexity:
    +Change the words "right after" to "immediately before".

    +

    Rationale:

    +

    Duplicate; see issue 233.

    +
    +

    249. Return Type of auto_ptr::operator= +

    Section: 20.4.5 [lib.meta.unary]  Status: NAD  Submitter: Joseph Gottman  Date: 30 Jun 2000

    +

    According to section 20.4.5, the function +auto_ptr::operator=() returns a reference to an auto_ptr. +The reason that operator=() usually returns a reference is to +facilitate code like

    + +
        int x,y,z;
+    x = y = z = 1;
+
    + +

    However, given analogous code for auto_ptrs,

    +
        auto_ptr<int> x, y, z;
+    z.reset(new int(1));
+    x = y = z;
+
    + +

    the result would be that z and y would both be set to +NULL, instead of all the auto_ptrs being set to the same value. +This makes such cascading assignments useless and counterintuitive for +auto_ptrs.

    +

    Proposed resolution:

    +

    Change auto_ptr::operator=() to return void instead +of an auto_ptr reference.

    +

    Rationale:

    +

    The return value has uses other than cascaded assignments: a user can +call an auto_ptr member function, pass the auto_ptr to a +function, etc. Removing the return value could break working user +code.

    +
    +

    257. STL functional object and iterator inheritance.

    Section: 20.3.1 [lib.tuple.tuple], 24.3.2 [lib.iterator.basic]  Status: NAD  Submitter: Robert Dick   Date: 17 Aug 2000

    +

    +According to the November 1997 Draft Standard, the results of deleting an +object of a derived class through a pointer to an object of its base class are +undefined if the base class has a non-virtual destructor. Therefore, it is +potentially dangerous to publicly inherit from such base classes. +

    + +

    Defect: +
    +The STL design encourages users to publicly inherit from a number of classes +which do nothing but specify interfaces, and which contain non-virtual +destructors. +

    + +

    Attribution: +
    +Wil Evers and William E. Kempf suggested this modification for functional +objects. +

    +

    Proposed resolution:

    +

    +When a base class in the standard library is useful only as an interface +specifier, i.e., when an object of the class will never be directly +instantiated, specify that the class contains a protected destructor. This +will prevent deletion through a pointer to the base class without performance, +or space penalties (on any implementation I'm aware of). +

    + +

    +As an example, replace... +

    + +
        template <class Arg, class Result>
+    struct unary_function {
+            typedef Arg    argument_type;
+            typedef Result result_type;
+    };
+
    + +

    +... with... +

    + +
        template <class Arg, class Result>
+    struct unary_function {
+            typedef Arg    argument_type;
+            typedef Result result_type;
+    protected:
+            ~unary_function() {}
+    };
+
    + +

    +Affected definitions: +
    +  20.3.1 [lib.function.objects] -- unary_function, binary_function +
    +  24.3.2 [lib.iterator.basic] -- iterator +

    +

    Rationale:

    +

    +The standard is clear as written; this is a request for change, not a +defect in the strict sense. The LWG had several different objections +to the proposed change. One is that it would prevent users from +creating objects of type unary_function and +binary_function. Doing so can sometimes be legitimate, if users +want to pass temporaries as traits or tag types in generic code. +

    +
    +

    267. interaction of strstreambuf::overflow() and seekoff()

    Section: D.7.1.3 [depr.strstreambuf.virtuals]  Status: NAD  Submitter: Martin Sebor  Date: 5 Oct 2000

    +

    +It appears that the interaction of the strstreambuf members overflow() +and seekoff() can lead to undefined behavior in cases where defined +behavior could reasonably be expected. The following program +demonstrates this behavior: +

    + +
        #include <strstream>
+
+    int main ()
+    {
+         std::strstreambuf sb;
+         sb.sputc ('c');
+
+         sb.pubseekoff (-1, std::ios::end, std::ios::in);
+         return !('c' == sb.sgetc ());
+    }
+
    + +

    +D.7.1.1, p1 initializes strstreambuf with a call to basic_streambuf<>(), +which in turn sets all pointers to 0 in 27.5.2.1, p1. +

    + +

    +27.5.2.2.5, p1 says that basic_streambuf<>::sputc(c) calls +overflow(traits::to_int_type(c)) if a write position isn't available (it +isn't due to the above). +

    + +

    +D.7.1.3, p3 says that strstreambuf::overflow(off, ..., ios::in) makes at +least one write position available (i.e., it allows the function to make +any positive number of write positions available). +

    + +

    +D.7.1.3, p13 computes newoff = seekhigh - eback(). In D.7.1, p4 we see +seekhigh = epptr() ? epptr() : egptr(), or seekhigh = epptr() in this +case. newoff is then epptr() - eback(). +

    + +

    +D.7.1.4, p14 sets gptr() so that gptr() == eback() + newoff + off, or +gptr() == epptr() + off holds. +

    + +

    +If strstreambuf::overflow() made exactly one write position available +then gptr() will be set to just before epptr(), and the program will +return 0. Buf if the function made more than one write position +available, epptr() and gptr() will both point past pptr() and the +behavior of the program is undefined. +

    +

    Proposed resolution:

    + + +

    Change the last sentence of D.7.1 [depr.strstreambuf] paragraph 4 from

    + +
    + Otherwise, seeklow equals gbeg and seekhigh is either pend, if + pend is not a null pointer, or gend. +
    + +

    to become

    + +
    + Otherwise, seeklow equals gbeg and seekhigh is either gend if + 0 == pptr(), or pbase() + max where max is the maximum value of + pptr() - pbase() ever reached for this stream. +
    + +

    [ + pre-Copenhagen: Dietmar provided wording for proposed resolution. +]

    + +

    [ + post-Copenhagen: Fixed a typo: proposed resolution said to fix + 4.7.1, not D.7.1. +]

    + +

    Rationale:

    +

    This is related to issue 65: it's not clear what it +means to seek beyond the current area. Without resolving issue 65 we can't resolve this. As with issue 65, +the library working group does not wish to invest time nailing down +corner cases in a deprecated feature.

    +
    +

    269. cstdarg and unnamed parameters

    Section: 18.7 [lib.support.exception]  Status: NAD  Submitter: J. Stephen Adamczyk  Date: 10 Oct 2000

    +

    +One of our customers asks whether this is valid C++: +

    + +
       #include <cstdarg>
+
+   void bar(const char *, va_list);
+
+   void
+   foo(const char *file, const char *, ...)
+   {
+     va_list ap;
+     va_start(ap, file);
+     bar(file, ap);
+     va_end(ap);
+   }
+
    + +

    +The issue being whether it is valid to use cstdarg when the final +parameter before the "..." is unnamed. cstdarg is, as far +as I can tell, inherited verbatim from the C standard. and the +definition there (7.8.1.1 in the ISO C89 standard) refers to "the +identifier of the rightmost parameter". What happens when there +is no such identifier? +

    + +

    +My personal opinion is that this should be allowed, but some tweak +might be required in the C++ standard. +

    +

    Proposed resolution:

    +

    Rationale:

    +

    +Not a defect, the C and C++ standards are clear. It is impossible to +use varargs if the parameter immediately before "..." has no +name, because that is the parameter that must be passed to va_start. +The example given above is broken, because va_start is being passed +the wrong parameter. +

    + +

    +There is no support for extending varargs to provide additional +functionality beyond what's currently there. For reasons of C/C++ +compatibility, it is especially important not to make gratuitous +changes in this part of the C++ standard. The C committee has already +been requested not to touch this part of the C standard unless +necessary. +

    +
    +

    277. Normative encouragement in allocator requirements unclear

    Section: 20.1.5 [lib.default.con.req]  Status: NAD  Submitter: Matt Austern  Date: 07 Nov 2000

    +

    +In 20.1.5, paragraph 5, the standard says that "Implementors are +encouraged to supply libraries that can accept allocators that +encapsulate more general memory models and that support non-equal +instances." This is intended as normative encouragement to +standard library implementors. However, it is possible to interpret +this sentence as applying to nonstandard third-party libraries. +

    +

    Proposed resolution:

    +

    +In 20.1.5, paragraph 5, change "Implementors" to +"Implementors of the library described in this International +Standard". +

    +

    Rationale:

    +

    The LWG believes the normative encouragement is already +sufficiently clear, and that there are no important consequences +even if it is misunderstood.

    +
    +

    279. const and non-const iterators should have equivalent typedefs

    Section: 23.1 [lib.container.requirements]  Status: NAD  Submitter: Steve Cleary  Date: 27 Nov 2000

    + +

    +This came from an email from Steve Cleary to Fergus in reference to +issue 179. The library working group briefly discussed +this in Toronto and believes it should be a separate issue. +

    + +

    +Steve said: "We may want to state that the const/non-const iterators must have +the same difference type, size_type, and category." +

    + +

    +(Comment from Judy) +I'm not sure if the above sentence should be true for all +const and non-const iterators in a particular container, or if it means +the container's iterator can't be compared with the container's +const_iterator unless the above it true. I suspect the former. +

    +

    Proposed resolution:

    +

    +In Section: 23.1 [lib.container.requirements], +table 65, in the assertion/note pre/post condition for X::const_iterator, +add the following: +

    + +
    +

    +typeid(X::const_iterator::difference_type) == typeid(X::iterator::difference_type) +

    + +

    +typeid(X::const_iterator::size_type) == typeid(X::iterator::size_type) +

    + +

    +typeid(X::const_iterator::category) == typeid(X::iterator::category) +

    +
    +

    Rationale:

    +

    Going through the types one by one: Iterators don't have a +size_type. We already know that the difference types are +identical, because the container requirements already say that the +difference types of both X::iterator and X::const_iterator are both +X::difference_type. The standard does not require that X::iterator +and X::const_iterator have the same iterator category, but the LWG +does not see this as a defect: it's possible to imagine cases in which +it would be useful for the categories to be different.

    + +

    It may be desirable to require X::iterator and X::const_iterator to +have the same value type, but that is a new issue. (Issue 322.)

    + +
    +

    287. conflicting ios_base fmtflags

    Section: 27.4.2.2 [lib.fmtflags.state]  Status: NAD  Submitter: Judy Ward  Date: 30 Dec 2000

    +

    +The Effects clause for ios_base::setf(fmtflags fmtfl) says +"Sets fmtfl in flags()". What happens if the user first calls +ios_base::scientific and then calls ios_base::fixed or vice-versa? +This is an issue for all of the conflicting flags, i.e. ios_base::left +and ios_base::right or ios_base::dec, ios_base::hex and ios_base::oct. +

    + +

    +I see three possible solutions: +

    + +
      +
    1. Set ios_base::failbit whenever the user specifies a conflicting +flag with one previously explicitly set. If the constructor is +supposed to set ios_base::dec (see discussion below), then +the user setting hex or oct format after construction will not +set failbit.
      2. +
    2. The last call to setf "wins", i.e. it clears any conflicting +previous setting.
      3. +
    3. All the flags that the user specifies are set, but when actually +interpreting them, fixed always override scientific, right always +overrides left, dec overrides hex which overrides oct.
      4. +
    + +

    +Most existing implementations that I tried seem to conform to resolution #3, +except that when using the iomanip manipulator hex or oct then that always +overrides dec, but calling setf(ios_base::hex) doesn't. +

    + +

    +There is a sort of related issue, which is that although the ios_base +constructor says that each ios_base member has an indeterminate value +after construction, all the existing implementations I tried explicitly set +ios_base::dec. +

    +

    Proposed resolution:

    +

    Rationale:

    +

    +adjustfield, basefield, and floatfield +are each multi-bit fields. It is possible to set multiple bits within +each of those fields. (For example, dec and +oct). These fields are used by locale facets. The LWG +reviewed the way in which each of those three fields is used, and +believes that in each case the behavior is well defined for any +possible combination of bits. See for example Table 58, in 22.2.2.2.2 [lib.facet.num.put.virtuals], noting the requirement in paragraph 6 of that +section. +

    +

    +Users are advised to use manipulators, or else use the two-argument +version of setf, to avoid unexpected behavior. +

    +
    +

    289. <cmath> requirements missing C float and long double versions

    Section: 26.5 [lib.numarray]  Status: NAD  Submitter: Judy Ward  Date: 30 Dec 2000

    +

    + In ISO/IEC 9899:1990 Programming Languages C we find the following + concerning <math.h>: +

    + +
    + 7.13.4 Mathematics <math.h> +
    + The names of all existing functions declared in the <math.h> + header, suffixed with f or l, are reserved respectively for + corresponding functions with float and long double arguments + are return values. +
    + +

    + For example, float sinf(float) + is reserved. +

    + +

    + In the C99 standard, <math.h> must contain declarations + for these functions. +

    + +

    +So, is it acceptable for an implementor to add these prototypes to the +C++ versions of the math headers? Are they required? +

    +

    Proposed resolution:

    +

    +Add these Functions to Table 80, section 26.5 and to Table 99, +section C.2: +

    + +
        acosf asinf atanf atan2f ceilf cosf coshf 
+    expf fabsf floorf fmodf frexpf ldexpf 
+    logf log10f modff powf sinf sinhf sqrtf 
+    tanf tanhf 
+    acosl asinl atanl atan2l ceill cosl coshl 
+    expl fabsl floorl fmodl frexpl ldexpl 
+    logl log10l modfl powl sinl sinhl sqrtl 
+    tanl tanhl
+
    + +

    +There should probably be a note saying that these functions +are optional and, if supplied, should match the description in +the 1999 version of the C standard. In the next round +of C++ standardization they can then become mandatory. +

    +

    Rationale:

    +

    The C90 standard, as amended, already permits (but does not +require) these functions, and the C++ standard incorporates the +C90 standard by reference. C99 is not an issue, because it is +never referred to by the C++ standard.

    +
    +

    293. Order of execution in transform algorithm

    Section: 25.2.3 [lib.alg.transform]  Status: NAD  Submitter: Angelika Langer  Date: 04 Jan 2001

    +

    This issue is related to issue 242. In case that the resolution +proposed for issue 242 is accepted, we have have the following +situation: The 4 numeric algorithms (accumulate and consorts) as well +as transform would allow a certain category of side effects. The +numeric algorithms specify that they invoke the functor "for +every iterator i in the range [first, last) in order". transform, +in contrast, would not give any guarantee regarding order of +invocation of the functor, which means that the functor can be invoked +in any arbitrary order. +

    + +

    Why would that be a problem? Consider an example: say the +transformator that is a simple enumerator ( or more generally +speaking, "is order-sensitive" ). Since a standard +compliant implementation of transform is free to invoke the enumerator +in no definite order, the result could be a garbled enumeration. +Strictly speaking this is not a problem, but it is certainly at odds +with the prevalent understanding of transform as an algorithms that +assigns "a new _corresponding_ value" to the output +elements. +

    + +

    All implementations that I know of invoke the transformator in +definite order, namely starting from first and proceeding to last - +1. Unless there is an optimization conceivable that takes advantage of +the indefinite order I would suggest to specify the order, because it +eliminate the uncertainty that users would otherwise have regarding +the order of execution of their potentially order-sensitive function +objects. +

    +

    Proposed resolution:

    +

    In section 25.2.3 - Transform [lib.alg.transform] change:

    +
    +-1- Effects: Assigns through every iterator i in the range [result, +result + (last1 - first1)) a new corresponding +value equal to op(*(first1 + (i - result)) or binary_op(*(first1 + +(i - result), *(first2 + (i - result))). +
    +

    to:

    +
    +-1- Effects: Computes values by invoking the operation op or binary_op +for every iterator in the range [first1, last1) in order. Assigns through +every iterator i in the range [result, result + (last1 - first1)) a new +corresponding +value equal to op(*(first1 + (i - result)) or binary_op(*(first1 + +(i - result), *(first2 + (i - result))). +
    +

    Rationale:

    +

    For Input Iterators an order is already guaranteed, because +only one order is possible. If a user who passes a Forward +Iterator to one of these algorithms really needs a specific +order of execution, it's possible to achieve that effect by +wrapping it in an Input Iterator adaptor.

    +
    +

    296. Missing descriptions and requirements of pair operators

    Section: 20.2.2 [lib.pairs]  Status: NAD  Submitter: Martin Sebor  Date: 14 Jan 2001

    +

    The synopsis of the header <utility> in 20.2 [lib.utility] +lists the complete set of equality and relational operators for pair +but the section describing the template and the operators only describes +operator==() and operator<(), and it fails to mention +any requirements on the template arguments. The remaining operators are +not mentioned at all. +

    +

    Proposed resolution:

    +

    Rationale:

    +

    20.2.1 [lib.operators] paragraph 10 already specifies the semantics. +That paragraph says that, if declarations of operator!=, operator>, +operator<=, and operator>= appear without definitions, they are +defined as specified in 20.2.1 [lib.operators]. There should be no user +confusion, since that paragraph happens to immediately precede the +specification of pair.

    +
    +

    302. Need error indication from codecvt<>::do_length

    Section: 22.2.1.5 [lib.locale.codecvt.byname]  Status: NAD  Submitter: Gregory Bumgardner  Date: 25 Jan 2001

    +

    +The effects of codecvt<>::do_length() are described in +22.2.1.5.2, paragraph 10. As implied by that paragraph, and clarified +in issue 75, codecvt<>::do_length() must +process the source data and update the stateT argument just +as if the data had been processed by codecvt<>::in(). +However, the standard does not specify how do_length() would +report a translation failure, should the source sequence contain +untranslatable or illegal character sequences. +

    + +

    +The other conversion methods return an "error" result value +to indicate that an untranslatable character has been encountered, but +do_length() already has a return value (the number of source +characters that have been processed by the method). +

    +

    Proposed resolution:

    +

    +This issue cannot be resolved without modifying the interface. An exception +cannot be used, as there would be no way to determine how many characters +have been processed and the state object would be left in an indeterminate +state. +

    + +

    +A source compatible solution involves adding a fifth argument to length() +and do_length() that could be used to return position of the offending +character sequence. This argument would have a default value that would +allow it to be ignored: +

    + +
      int length(stateT& state, 
+             const externT* from, 
+             const externT* from_end, 
+             size_t max,
+             const externT** from_next = 0);
+
+  virtual
+  int do_length(stateT& state, 
+                const externT* from, 
+                const externT* from_end, 
+                size_t max,
+                const externT** from_next);
+
    + +

    +Then an exception could be used to report any translation errors and +the from_next argument, if used, could then be used to retrieve the +location of the offending character sequence. +

    +

    Rationale:

    +

    The standard is already clear: the return value is the number of +"valid complete characters". If it encounters an invalid sequence of +external characters, it stops.

    +
    +

    304. Must *a return an lvalue when a is an input iterator?

    Section: 24.1 [lib.iterator.requirements]  Status: NAD  Submitter: Dave Abrahams  Date: 5 Feb 2001

    +

    +We all "know" that input iterators are allowed to produce +values when dereferenced of which there is no other in-memory copy. +

    + +

    +But: Table 72, with a careful reading, seems to imply that this can only be +the case if the value_type has no members (e.g. is a built-in type). +

    + +

    The problem occurs in the following entry:

    + +
      a->m     pre: (*a).m is well-defined
+           Equivalent to (*a).m
+
    + +

    +*a.m can be well-defined if *a is not a reference +type, but since operator->() must return a pointer for +a->m to be well-formed, it needs something to return a +pointer to. This seems to indicate that *a must be +buffered somewhere to make a legal input iterator. +

    + +

    I don't think this was intentional.

    +

    Proposed resolution:

    +

    Rationale:

    +

    The current standard is clear and consistent. Input iterators that + return rvalues are in fact implementable. They may in some cases + require extra work, but it is still possible to define an operator-> + in such cases: it doesn't have to return a T*, but may return a + proxy type. No change to the standard is justified.

    +
    +

    313. set_terminate and set_unexpected question

    Section: 18.7.3.3 [lib.terminate]  Status: NAD  Submitter: Judy Ward  Date: 3 Apr 2001

    +

    +According to section 18.7.3.3 of the standard, std::terminate() is +supposed to call the terminate_handler in effect immediately after +evaluating the throw expression. +

    + +

    +Question: what if the terminate_handler in effect is itself +std::terminate? +

    + +

    For example:

    + +
      #include <exception>
+
+  int main () {
+      std::set_terminate(std::terminate);
+      throw 5;
+      return 0;
+  }
+
    + +

    +Is the implementation allowed to go into an infinite loop? +

    + +

    +I think the same issue applies to std::set_unexpected. +

    +

    Proposed resolution:

    +

    Rationale:

    +

    Infinite recursion is to be expected: users who set the terminate +handler to terminate are explicitly asking for terminate +to call itself.

    +
    +

    314. Is the stack unwound when terminate() is called?

    Section: 18.7.3.3 [lib.terminate]  Status: NAD  Submitter: Detlef Vollmann  Date: 11 Apr 2001

    + +

    +The standard appears to contradict itself about whether the stack is +unwound when the implementation calls terminate(). +

    + +

    From 18.7.3.3p2:

    +
    + Calls the terminate_handler function in effect immediately + after evaluating the throw-expression (lib.terminate.handler), + if called by the implementation [...] +
    + +

    So the stack is guaranteed not to be unwound.

    + +

    But from 15.3p9:

    +
    + [...]whether or not the stack is unwound before this call + to terminate() is implementation-defined (except.terminate). +
    + +

    +And 15.5.1 actually defines that in most cases the stack is unwound. +

    +

    Proposed resolution:

    +

    Rationale:

    +

    There is definitely no contradiction between the core and library +clauses; nothing in the core clauses says that stack unwinding happens +after terminate is called. 18.7.3.3p2 does not say anything +about when terminate() is called; it merely specifies which +terminate_handler is used.

    +
    +

    323. abs() overloads in different headers

    Section: 26.5 [lib.numarray]  Status: NAD Future  Submitter: Dave Abrahams  Date: 4 June 2001

    +

    Currently the standard mandates the following overloads of +abs():

    + +
        abs(long), abs(int) in <cstdlib>
+
+    abs(float), abs(double), abs(long double) in <cmath>
+
+    template<class T> T abs(const complex<T>&) in <complex>
+
+    template<class T> valarray<T> abs(const valarray<T>&); in <valarray>
+
    + +

    +The problem is that having only some overloads visible of a function +that works on "implicitly inter-convertible" types is dangerous in +practice. The headers that get included at any point in a translation +unit can change unpredictably during program +development/maintenance. The wrong overload might be unintentionally +selected. +

    + +

    +Currently, there is nothing that mandates the simultaneous visibility +of these overloads. Indeed, some vendors have begun fastidiously +reducing dependencies among their (public) headers as a QOI issue: it +helps people to write portable code by refusing to compile unless all +the correct headers are #included. +

    + +

    The same issue may exist for other functions in the library.

    + +

    Redmond: PJP reports that C99 adds two new kinds of abs: complex, +and int_max_abs.

    + +

    Related issue: 343.

    + +

    Proposed resolution:

    +

    Rationale:

    +

    The programs that could potentially be broken by this situation are + already fragile, and somewhat contrived: For example, a user-defined + class that has conversion overloads both to long and + to float. If x is a value of such a class, then + abs(x) would give the long version if the user + included <cstdlib>, the float version if the user + included <cmath>, and would be diagnosed as ambiguous at + compile time if the user included both headers. The LWG couldn't + find an example of a program whose meaning would be changed (as + opposed to changing it from well-formed to ill-formed) simply by + adding another standard header.

    + +

    Since the harm seems minimal, and there don't seem to be any simple + and noninvasive solutions, this is being closed as NAD. It is + marked as "Future" for two reasons. First, it might be useful to + define an <all> header that would include all + Standard Library headers. Second, we should at least make sure that + future library extensions don't make this problem worse.

    +
    +

    326. Missing typedef in moneypunct_byname

    Section: 22.2.6.4 [lib.locale.moneypunct.byname]  Status: NAD  Submitter: Martin Sebor  Date: 05 Jul 2001

    +

    The definition of the moneypunct facet contains the typedefs char_type +and string_type. Only one of these names, string_type, is defined in +the derived facet, moneypunct_byname.

    +

    Proposed resolution:

    +

    For consistency with the numpunct facet, add a typedef for +char_type to the definition of the moneypunct_byname facet in +22.2.6.4 [lib.locale.moneypunct.byname].

    +

    Rationale:

    +

    The absence of the typedef is irrelevant. Users can still access +the typedef, because it is inherited from the base class.

    +
    +

    330. Misleading "exposition only" value in class locale definition

    Section: 22.1.1 [lib.locale]  Status: NAD  Submitter: Martin Sebor  Date: 15 Jul 2001

    +

    +The "exposition only" value of the std::locale::none constant shown in +the definition of class locale is misleading in that it on many +systems conflicts with the value assigned to one if the LC_XXX +constants (specifically, LC_COLLATE on AIX, LC_ALL on HP-UX, LC_CTYPE +on Linux and SunOS). This causes incorrect behavior when such a +constant is passed to one of the locale member functions that accept a +locale::category argument and interpret it as either the C LC_XXX +constant or a bitmap of locale::category values. At least three major +implementations adopt the suggested value without a change and +consequently suffer from this problem. +

    + +

    +For instance, the following code will (presumably) incorrectly copy facets +belonging to the collate category from the German locale on AIX: +

    + +
      std::locale l (std::locale ("C"), "de_DE", std::locale::none);
+
    +

    Proposed resolution:

    +

    Rationale:

    +

    The LWG agrees that it may be difficult to implement locale member +functions in such a way that they can take either category +arguments or the LC_ constants defined in <cctype>. In light of +this requirement (22.1.1.1.1 [lib.locale.category], paragraph 2), and in light +of the requirement in the preceding paragraph that it is possible to +combine category bitmask elements with bitwise operations, +defining the category elements is delicate, +particularly if an implementor is constrained to work with a +preexisting C library. (Just using the existing LC_ constants would +not work in general.) There's no set of "exposition only" values that +could give library implementors proper guidance in such a delicate +matter. The non-normative example we're giving is no worse than +any other choice would be.

    + +

    See issue 347.

    +
    +

    332. Consider adding increment and decrement operators to std::fpos< T >

    Section: 27.4.3 [lib.fpos]  Status: NAD  Submitter: PremAnand M. Rao  Date: 27 Aug 2001

    +

    +Increment and decrement operators are missing from +Table 88 -- Position type requirements in 27.4.3 [lib.fpos]. +

    +

    Proposed resolution:

    +

    +Table 88 (section 27.4.3) -- Position type requirements +be updated to include increment and decrement operators. +

    + +
    expression        return type     operational    note
+
+++p               fpos&           p += O(1)
+p++               fpos            { P tmp = p;
+                                    ++p;
+                                    return tmp; }
+--p               fpos&           p -= O(1)
+p--               fpos            { P tmp = p;
+                                    --p;
+                                    return tmp; }
+
    + +

    Rationale:

    +

    The LWG believes this is a request for extension, not a defect +report. Additionally, nobody saw a clear need for this extension; +fpos is used only in very limited ways.

    +
    +

    344. grouping + showbase

    Section: 22.2.2 [lib.category.numeric]  Status: NAD  Submitter: Howard Hinnant  Date: 13 Oct 2001

    +

    +When both grouping and showbase are active and the basefield is octal, +does the leading 0 participate in the grouping or not? For example, +should one format as: 0,123,456 or 0123,456? +

    +

    +An analogy can be drawn with hexadecimal. It appears that 0x123,456 is +preferred over 0x,123,456. However, this analogy is not universally +accepted to apply to the octal base. The standard is not clear on how +to format (or parse) in this manner. +

    +

    Proposed resolution:

    +

    +Insert into 22.2.3.1.2 [lib.facet.numpunct.virtuals] paragraph 3, just before the last +sentence: +

    +
    +The leading hexadecimal base specifier "0x" does not participate in +grouping. The leading '0' octal base specifier may participate in +grouping. It is unspecified if the leading '0' participates in +formatting octal numbers. In parsing octal numbers, the implementation +is encouraged to accept both the leading '0' participating in the +grouping, and not participating (e.g. 0123,456 or 0,123,456). +
    +

    Rationale:

    +

    +The current behavior may be unspecified, but it's not clear that it +matters. This is an obscure corner case, since grouping is usually +intended for the benefit of humans and oct/hex prefixes are usually +intended for the benefit of machines. There is not a strong enough +consensus in the LWG for action. +

    +
    +

    348. Minor issue with std::pair operator<

    Section: 20.2.2 [lib.pairs]  Status: NAD Future  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. +

    +

    Proposed resolution:

    +

    In 20.2.2 [lib.pairs] paragraph 6, replace:

    +
        Returns: x.first < y.first || (!(y.first < x.first) && x.second <
+        y.second).
+
    +

    With:

    +
        Returns: std::less<T1>()( x.first, y.first ) ||
+             (!std::less<T1>()( y.first, x.first) && 
+             std::less<T2>()( x.second, y.second ) )
+
    + +

    Rationale:

    +

    This is an instance of a much more general problem. If we want + operator< to translate to std::less for pairs of pointers, where + do we draw the line? The same issue applies to individual + pointers, smart pointer wrappers, std::vector<T*>, and so + on.

    + +

    Andy Koenig suggests that the real issue here is that we aren't + distinguishing adequately between two different orderings, a + "useful ordering" and a "canonical ordering" that's used just + because we sometimes need some ordering without caring much + which ordering it is. Another example of the later is typeinfo's + before.

    + +
    +

    350. allocator<>::address

    Section: 20.6.1.1 [lib.allocator.members], 20.1.6 [lib.allocator.requirements], 17.4.1.1 [lib.contents]  Status: NAD Future  Submitter: Nathan Myers  Date: 25 Oct 2001

    +

    See c++std-lib-9006 and c++std-lib-9007. This issue is taken +verbatim from -9007.

    + +

    +The core language feature allowing definition of operator&() applied +to any non-builtin type makes that operator often unsafe to use in +implementing libraries, including the Standard Library. The result +is that many library facilities fail for legal user code, such as +the fragment

    +
      class A { private: A* operator&(); };
+  std::vector<A> aa;
+
+  class B { };
+  B* operator&(B&) { return 0; }
+  std::vector<B> ba;
+
    + +

    +In particular, the requirements table for Allocator (Table 32) specifies +no semantics at all for member address(), and allocator<>::address is +defined in terms of unadorned operator &. +

    + +

    Proposed resolution:

    +

    +In 20.6.1.1, Change the definition of allocator<>::address from:

    +
    + Returns: &x +
    + +

    to:

    + +

    + Returns: The value that the built in operator&(x) would return if not + overloaded. +

    + +

    +In 20.1.6, Table 32, add to the Notes column of the a.address(r) and +a.address(s) lines, respectively: +

    + +
      allocator<T>::address(r)
+  allocator<T>::address(s)
+
    + +

    In addition, in clause 17.4.1.1, add a statement:

    + +
    + The Standard Library does not apply operator& to any type for which + operator& may be overloaded. +
    + +

    Rationale:

    +

    The LWG believes both examples are ill-formed. The contained type +is required to be CopyConstructible (20.1.3 [lib.copyconstructible]), and that +includes the requirement that &t return the usual types and +values. Since allocators are intended to be used in conjunction with +containers, and 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.

    + +

    It may well be that the CopyConstructible requirements are too + restrictive and that either the container requirements or the + CopyConstructive requirements should be relaxed, but that's a far + larger issue. Marking this issue as "future" as a pointer to that + larger issue.

    +
    +

    351. unary_negate and binary_negate: struct or class?

    Section: 20.3 [lib.tuple]  Status: NAD  Submitter: Dale Riley  Date: 12 Nov 2001

    +

    +In 20.3 [lib.tuple] the header <functional> synopsis declares +the unary_negate and binary_negate function objects as struct. +However in 20.3.5 the unary_negate and binary_negate +function objects are defined as class. Given the context, they are +not "basic function objects" like negate, so this is either a typo or +an editorial oversight. +

    + +

    [Taken from comp.std.c++]

    +

    Proposed resolution:

    +

    Change the synopsis to reflect the useage in 20.3.5

    + +

    [Curaçao: Since the language permits "struct", the LWG +views this as NAD. They suggest, however, that the Project Editor +might wish to make the change as editorial.]

    + +
    +

    353. std::pair missing template assignment

    Section: 20.2.2 [lib.pairs]  Status: NAD Future  Submitter: Martin Sebor  Date: 2 Dec 2001

    +

    +The class template std::pair defines a template ctor (20.2.2, p4) but +no template assignment operator. This may lead to inefficient code since +assigning an object of pair<C, D> to pair<A, B> +where the types C and D are distinct from but convertible to +A and B, respectively, results in a call to the template copy +ctor to construct an unnamed temporary of type pair<A, B> +followed by an ordinary (perhaps implicitly defined) assignment operator, +instead of just a straight assignment. +

    +

    Proposed resolution:

    +

    +Add the following declaration to the definition of std::pair: +

    +
        template<class U, class V>
+    pair& operator=(const pair<U, V> &p);
+
    +

    +And also add a paragraph describing the effects of the function template to the +end of 20.2.2: +

    +
        template<class U, class V>
+    pair& operator=(const pair<U, V> &p);
+
    +

    + Effects: first = p.first; + second = p.second; + Returns: *this +

    + +

    [Curaçao: There is no indication this is was anything other than +a design decision, and thus NAD.  May be appropriate for a future +standard.]

    + +
    +

    356. Meaning of ctype_base::mask enumerators

    Section: 22.2.1 [lib.category.ctype]  Status: NAD  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.

    + +

    More comments from Benjamin Kosnik, who believes that +that C99 compatibility essentially requires what we're +calling option 1 below.

    + +
    +
    I think the C99 standard is clear, that isspace -> !isalpha.
+--------
+
+#include <locale>
+#include <iostream>
+
+class my_ctype : public std::ctype<char>
+{
+private:
+  typedef std::ctype<char> base;
+  mask my_table[base::table_size];
+
+public:
+  my_ctype(std::size_t refs = 0) : base(my_table, false, refs)
+  {
+    std::copy(base::classic_table(), base::classic_table() + base::table_size,
+              my_table);
+    mask both = base::print | base::space;
+    my_table[static_cast<mask>('_')] = both;
+  }
+};
+
+int main()
+{
+  using namespace std;
+  my_ctype ct;
+  cout << "isspace: " << ct.is(ctype_base::space, '_') << endl;
+  cout << "isprint: " << ct.is(ctype_base::print, '_') << endl;
+
+  // ISO C99, isalpha iff upper | lower set, and !space.
+  // 7.5, p 193
+  // -> looks like g++ behavior is correct.
+  // 356 -> bitmask elements are required for ctype_base
+  // 339 -> bitmask type required for mask
+  cout << "isalpha: " << ct.is(ctype_base::alpha, '_') << endl;
+}
+
    +
    + +

    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.

    +

    Rationale:

    +

    The LWG agrees that this is a real ambiguity, and that both +interpretations are conforming under the existing standard. However, +there's no evidence that it's causing problems for real users. Users +who want to define ctype facets portably can test the ctype_base masks +to see which interpretation is being used.

    +
    +

    357. <cmath> float functions cannot return HUGE_VAL

    Section: 26.5 [lib.numarray]  Status: NAD  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.

    +

    Rationale:

    +

    Will be fixed as part of more general work in the TR.

    +
    +

    361. num_get<>::do_get (..., void*&) checks grouping

    Section: 22.2.2.2.2 [lib.facet.num.put.virtuals]  Status: NAD  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... +
    + +

    Rationale:

    +

    This would be a change: as it stands, the standard clearly + specifies that grouping applies to void*. A survey of existing + practice shows that most existing implementations do that, as they + should.

    +
    +

    366. Excessive const-qualification

    Section: 27 [lib.input.output]  Status: NAD  Submitter: Walter Brown, Marc Paterno  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. +

    + +

    [Santa Cruz: the real issue is that we've got const member +functions that return pointers to non-const, and N1360 proposes +replacing them by overloaded pairs. There isn't a consensus about +whether this is a real issue, since we've never said what our +constness policy is for iostreams. N1360 relies on a distinction +between physical constness and logical constness; that distinction, or +those terms, does not appear in the standard.]

    + +

    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;
+
    +

    Rationale:

    +

    The existing specification is a bit sloppy, but there's no + particular reason to change this other than tidiness, and there are + a number of ways in which streams might have been designed + differently if we were starting today. There's no evidence that the + existing constness policy is harming users. We might consider + a different constness policy as part of a full stream redesign.

    +
    +

    367. remove_copy/remove_copy_if and Input Iterators

    Section: 25.2.7 [lib.alg.remove]  Status: NAD  Submitter: Anthony Williams  Date: 13 May 2002

    +

    +remove_copy and remove_copy_if (25.2.7 [lib.alg.remove]) permit their +input range to be marked with Input Iterators. However, since two +operations are required against the elements to copy (comparison and +assigment), when the input range uses Input Iterators, a temporary +copy must be taken to avoid dereferencing the iterator twice. This +therefore requires the value type of the InputIterator to be +CopyConstructible. If the iterators are at least Forward Iterators, +then the iterator can be dereferenced twice, or a reference to the +result maintained, so the temporary is not required. +

    +

    Proposed resolution:

    +

    +Add "If InputIterator does not meet the requirements of forward +iterator, then the value type of InputIterator must be copy +constructible. Otherwise copy constructible is not required." to +25.2.7 [lib.alg.remove] paragraph 6. +

    +

    Rationale:

    +

    The assumption is that an input iterator can't be dereferenced + twice. There's no basis for that assumption in the Standard.

    +
    +

    368. basic_string::replace has two "Throws" paragraphs

    Section: 21.3.5.6 [lib.string::replace]  Status: NAD  Submitter: Beman Dawes  Date: 3 Jun 2002

    +

    +21.3.5.6 [lib.string::replace] basic_string::replace, second +signature, given in paragraph 1, has two "Throws" paragraphs (3 and +5). +

    + +

    +In addition, the second "Throws" paragraph (5) includes specification +(beginning with "Otherwise, the function replaces ...") that should be +part of the "Effects" paragraph. +

    +

    Proposed resolution:

    +

    Rationale:

    +

    This is editorial. Both "throws" statements are true. The bug is + just that the second one should be a sentence, part of the "Effects" + clause, not a separate "Throws". The project editor has been + notified.

    +
    +

    372. Inconsistent description of stdlib exceptions

    Section: 17.4.4.8 [lib.res.on.exception.handling], 18.6.1 [lib.type.info],   Status: NAD  Submitter: Randy Maddox  Date: 22 Jul 2002

    + +

    Paragraph 3 under clause 17.4.4.8 [lib.res.on.exception.handling], Restrictions on +Exception Handling, states that "Any other functions defined in the +C++ Standard Library that do not have an exception-specification may +throw implementation-defined exceptions unless otherwise specified." +This statement is followed by a reference to footnote 178 at the +bottom of that page which states, apparently in reference to the C++ +Standard Library, that "Library implementations are encouraged (but +not required) to report errors by throwing exceptions from (or derived +from) the standard exceptions."

    + +

    These statements appear to be in direct contradiction to clause +18.6.1 [lib.type.info], which states "The class exception defines the +base class for the types of objects thrown as exceptions by the C++ +Standard library components ...".

    + +

    Is this inconsistent?

    + +

    Proposed resolution:

    +

    Rationale:

    +

    Clause 17 is setting the overall library requirements, and it's + clear and consistent. This sentence from Clause 18 is descriptive, + not setting a requirement on any other class. +

    +
    +

    374. moneypunct::frac_digits returns int not unsigned

    Section: 22.2.6.3.1 [lib.locale.moneypunct.members], 22.2.6.3.2 [lib.locale.moneypunct.virtuals]  Status: NAD  Submitter: Ray Lischner  Date: 8 Aug 2002

    +

    +In section 22.2.6.3.1 [lib.locale.moneypunct.members], frac_digits() returns type +"int". This implies that frac_digits() might return a negative value, +but a negative value is nonsensical. It should return "unsigned". +

    + +

    +Similarly, in section 22.2.6.3.2 [lib.locale.moneypunct.virtuals], do_frac_digits() +should return "unsigned". +

    + +

    Proposed resolution:

    +

    Rationale:

    +

    Regardless of whether the return value is int or unsigned, it's +always conceivable that frac_digits might return a nonsensical +value. (Is 4294967295 really any better than -1?) The clients of +moneypunct, the get and put facets, can and do perform range +checks.

    +
    +

    377. basic_string::insert and length_error

    Section: 21.3.5.4 [lib.string::insert]  Status: NAD  Submitter: Ray Lischner  Date: 16 Aug 2002

    +

    +Section 21.3.5.4 [lib.string::insert], paragraph 4, contains the following, +"Then throws length_error if size() >= npos - rlen." +

    + +

    +Related to DR 83, this sentence should probably be removed. +

    +

    Proposed resolution:

    +

    Rationale:

    +

    This requirement is redundant but correct. No change is +needed.

    +
    +

    378. locale immutability and locale::operator=()

    Section: 22.1.1 [lib.locale]  Status: Dup  Submitter: Martin Sebor  Date: 6 Sep 2002

    +

    +I think there is a problem with 22.1.1, p6 which says that +

    +
        -6- An instance of locale is immutable; once a facet reference
+        is obtained from it, that reference remains usable as long
+        as the locale value itself exists.
+
    +

    +and 22.1.1.2, p4: +

    +
        const locale& operator=(const locale& other) throw();
+
+    -4- Effects: Creates a copy of other, replacing the current value.
+
    +

    +How can a reference to a facet obtained from a locale object remain +valid after an assignment that clearly must replace all the facets +in the locale object? Imagine a program such as this +

    +
        std::locale loc ("de_DE");
+    const std::ctype<char> &r0 = std::use_facet<std::ctype<char> >(loc);
+    loc = std::locale ("en_US");
+    const std::ctype<char> &r1 = std::use_facet<std::ctype<char> >(loc);
+
    +

    +Is r0 really supposed to be preserved and destroyed only when loc goes +out of scope? +

    +

    Proposed resolution:

    +

    [Summer '04 mid-meeting mailing: Martin and Dietmar believe this + is a duplicate of issue 31 and recommend that it be + closed. +]

    + +
    +

    388. Use of complex as a key in associative containers

    Section: 26.2 [lib.cfenv]  Status: NAD Future  Submitter: Gabriel Dos Reis  Date: 8 Nov 2002

    +

    +Practice with std::complex<> and the associative containers +occasionally reveals artificial and distracting issues with constructs +resembling: std::set<std::complex<double> > s; +

    + +

    +The main reason for the above to fail is the absence of an approriate +definition for std::less<std::complex<T> >. That in turn comes from +the definition of the primary template std::less<> in terms of +operator<. +

    + +

    +The usual argument goes as follows: Since there is no ordering over +the complex field compatible with field operations it makes little +sense to define a function operator< operating on the datatype +std::complex<T>. That is fine. However, that reasoning does not carry +over to std::less<T> which is used, among other things, by associative +containers as an ordering useful to meet complexity requirements. +

    + +

    Related issue: 348.

    + +

    Proposed resolution:

    +

    Informally: Add a specialization of std::less for std::complex.

    +

    Rationale:

    +

    Discussed in Santa Cruz. An overwhelming majority of the LWG +believes this should not be treated a DR: it's a request for a design +change, not a defect in the existing standard. Most people (10-3) +believed that we probably don't want this change, period: as with +issue 348, it's hard to know where to draw the line. +The LWG noted that users who want to put objects into an associative +container for which operator< isn't defined can simply +provide their own comparison function object.

    +
    +

    390. CopyConstructible requirements too strict

    Section: 20.1.3 [lib.copyconstructible]  Status: NAD Future  Submitter: Doug Gregor  Date: 24 Oct 2002

    +

    +The CopyConstructible requirements in Table 30 state that for an +object t of type T (where T is CopyConstructible), the expression &t +returns the address of t (with type T*). This requirement is overly +strict, in that it disallows types that overload operator& to not +return a value of type T*. This occurs, for instance, in the Boost.Lambda library, where +operator& is overloaded for a Boost.Lambda function object to return +another function object. +

    + +

    Example:

    + +
      std::vector<int> u, v;
+  int x;
+  // ...
+  std::transform(u.begin(), u.end(), std::back_inserter(v), _1 * x);
+
    + +

    +_1 * x returns an unnamed function object with operator& overloaded to +not return T* , therefore rendering the std::transform call ill-formed. +However, most standard library implementations will compile this code +properly, and the viability of such binder libraries is severely hindered +by the unnecessary restriction in the CopyConstructible requirements. +

    + +

    +For reference, the address of an object can be retrieved without using +the address-of operator with the following function template: +

    + +
      template <typename T> T* addressof(T& v)
+  {
+    return reinterpret_cast<T*>(
+         &const_cast<char&>(reinterpret_cast<const volatile char &>(v)));
+  }
+
    + +

    +Note: this relates directly to library issue 350, which +will need to be reexamined if the CopyConstructible requirements +change. +

    +

    Proposed resolution:

    +

    +Remove the last two rows of Table 30, eliminating the requirements +that &t and &u return the address of t and u, respectively. +

    +

    Rationale:

    +

    This was a deliberate design decision. Perhaps it should be + reconsidered for C++0x.

    +
    +

    392. 'equivalence' for input iterators

    Section: 24.1.1 [lib.input.iterators]  Status: NAD  Submitter: Corwin Joy  Date: 11 Dec 2002

    + +

    +In section 24.1.1 [lib.input.iterators] table 72 - +'Input Iterator Requirements' we have as a postcondition of *a: +"If a==b and (a, b) is in the domain of == then *a is equivalent to *b". +

    + +

    +In section 24.5.3.5 [lib.istreambuf.iterator::equal] it states that +"istreambuf_iterator::equal returns true if and only if both iterators +are at end-of-stream, or neither is at end-of-stream, regardless of +what streambuf object they use." (My emphasis). +

    + +

    +The defect is that either 'equivalent' needs to be more precisely +defined or the conditions for equality in 24.5.3.5 [lib.istreambuf.iterator::equal] +are incorrect. (Or both). +

    + +

    Consider the following example:

    +
       #include <iostream>
+   #include <fstream>
+   #include <iterator>
+   using namespace std;
+
+   int main() {
+    ifstream file1("file1.txt"), file2("file2.txt");
+    istreambuf_iterator<char> f1(file1), f2(file2);
+    cout << "f1 == f2 : " << boolalpha << (f1 == f2) << endl;
+    cout << "f1 = " << *f1 << endl;
+    cout << "f2 = " << *f2 << endl;
+    return 0;
+   }
+
    + +

    Now assuming that neither f1 or f2 are at the end-of-stream then +f1 == f2 by 24.5.3.5 [lib.istreambuf.iterator::equal].

    + +

    However, it is unlikely that *f1 will give the same value as *f2 except +by accident.

    + +

    So what does *f1 'equivalent' to *f2 mean? I think the standard should +be clearer on this point, or at least be explicit that this does not +mean that *f1 and *f2 are required to have the same value in the case +of input iterators.

    +

    Proposed resolution:

    +

    Rationale:

    +

    The two iterators aer not in the domain of ==

    +
    +

    399. volations of unformatted input function requirements

    Section: 27.6.1.3 [lib.istream.unformatted]  Status: NAD  Submitter: Martin Sebor  Date: 5 Jan 2003

    +

    +The Effects clauses for the two functions below violate the +general requirements on unformatted input functions outlined +in 27.6.1.3: they do not begin by constructing a sentry object. +Instead, they begin by calling widen ('\n'), which may throw +an exception. The exception is then allowed to propagate from +the unformatted input function irrespective of the setting of +exceptions(). +

    +

    +Note that in light of 27.6.1.1, p3 and p4, the fact that the +functions allow exceptions thrown from widen() to propagate +may not strictly speaking be a defect (but the fact that the +functions do not start by constructing a sentry object still +is). However, since an exception thrown from ctype<charT> +::widen() during any other input operation (say, from within +a call to num_get<charT>::get()) will be caught and cause +badbit to be set, these two functions should not be treated +differently for the sake of consistency. +

    +

    Proposed resolution:

    +

    Rationale:

    +

    +Not a defect. The standard is consistent, and the behavior required +by the standard is unambiguous. Yes, it's theoretically possible for +widen to throw. (Not that this will happen for the default ctype +facet or for most real-world replacement ctype facets.) Users who +define ctype facets that can throw, and who care about this behavior, +can use alternative signatures that don't call widen. +

    +
    +

    429. typo in basic_ios::clear(iostate)

    Section: 27.4.4.3 [lib.iostate.flags]  Status: Dup  Submitter: Martin Sebor  Date: 18 Sep 2003

    +

    + +The Effects clause in 27.4.4.3, p5 describing the effects of a call to +the ios_base member function clear(iostate state) says that the function +only throws if the respective bits are already set prior to the function +call. That's obviously not the intent. If it was, a call to clear(badbit) +on an object for which (rdstate() == goodbit && exceptions() == badbit) +holds would not result in an exception being thrown. + +

    +

    Proposed resolution:

    +

    + +The text ought to be changed from +
    + +"If (rdstate() & exceptions()) == 0, returns. ..." +
    + +to +
    + +"If (state & exceptions()) == 0, returns. ..." +

    +

    Rationale:

    +

    This is a duplicate of issue 412.

    +
    +

    433. Contradiction in specification of unexpected()

    Section: 18.7.2.4 [lib.unexpected]  Status: NAD  Submitter: Vyatcheslav Sysoltsev  Date: 29 Sep 2003

    +

    +Clause 15.5.2 [except.unexpected] paragraph 1 says that "void unexpected(); +is called (18.7.2) immediately after completing the stack unwinding +for the former function", but 18.7.2.4 (Effects) says that "void +unexpected(); . . . Calls the unexpected_handler function in effect +immediately after evaluating the throwexpression (18.7.2.2),". Isn't +here a contradiction: 15.5.2 requires stack have been unwound when in +void unexpected() and therefore in unexpected_handler but 18.7.2.4 +claims that unexpected_handler is called "in effect immediately" after +evaluation of throw expression is finished, so there is no space left +for stack to be unwound therefore? I think the phrase "in effect +immediately" should be removed from the standard because it brings +ambiguity in understanding. +

    +

    Proposed resolution:

    +

    Rationale:

    +

    There is no contradiction. The phrase "in effect immediately" is + just to clarify which handler is to be called.

    +
    +

    437. Formatted output of function pointers is confusing

    Section: 27.6.2.5.2 [lib.ostream.inserters.arithmetic]  Status: NAD  Submitter: Ivan Godard  Date: 24 Oct 2003

    +

    +Given: +

    +
    void f(int) {}
+void(*g)(int) = f;
+cout << g;
+
    + +

    +(with the expected #include and usings), the value printed is a rather +surprising "true". Rather useless too. +

    + +

    The standard defines:

    + +
    ostream& operator<<(ostream&, void*);
    + +

    which picks up all data pointers and prints their hex value, but does +not pick up function pointers because there is no default conversion +from function pointer to void*. Absent that, we fall back to legacy +conversions from C and the function pointer is converted to bool. +

    + +

    There should be an analogous inserter that prints the address of a + function pointer.

    +

    Proposed resolution:

    +

    Rationale:

    +

    This is indeed a wart, but there is no good way to solve it. C + doesn't provide a portable way of outputting the address of a + function point either.

    +
    +

    439. Should facets be copyable?

    Section: 22.2 [lib.locale.categories]  Status: NAD  Submitter: Matt Austern  Date: 2 Nov 2003

    +

    The following facets classes have no copy constructors described in + the standard, which, according to the standard, means that they are + supposed to use the compiler-generated defaults. Default copy + behavior is probably inappropriate. We should either make these + classes uncopyable or else specify exactly what their constructors do.

    + +

    Related issue: 421.

    + +
            ctype_base
+        ctype
+        ctype_byname
+        ctype<char>
+        ctype_byname<char>
+        codecvt_base
+        codecvt
+        codecvt_byname
+        num_get
+        num_put
+        numpunct
+        numpunct_byname
+        collate
+        collate_byname
+        time_base
+        time_get
+        time_get_byname
+        time_put
+        time_put_byname
+        money_get
+        money_put
+        money_base
+        moneypunct
+        moneypunct_byname
+        messages_base
+        messages
+        messages_byname
+
    + +

    Proposed resolution:

    +

    Rationale:

    +

    The copy constructor in the base class is private.

    +
    +

    440. Should std::complex use unqualified transcendentals?

    Section: 26.3.8 [lib.complex.transcendentals]  Status: NAD  Submitter: Matt Austern  Date: 5 Nov 2003

    +

    +Operations like pow and exp on +complex<T> are typically implemented in terms of +operations like sin and cos on T. +Should implementations write this as std::sin, or as plain +unqualified sin? +

    + +

    The issue, of course, is whether we want to use +argument-dependent lookup in the case where T is a +user-defined type. This is similar to the issue of valarray +transcendentals, as discussed in issue 226.

    + +

    This issue differs from valarray transcendentals in two important +ways. First, "the effect of instantiating the template +complex for types other than float, double or long double is +unspecified." (26.3.1 [lib.complex.synopsis]) Second, the standard does not +dictate implementation, so there is no guarantee that a particular +real math function is used in the implementation of a particular +complex function.

    + +

    Proposed resolution:

    +

    Rationale:

    +

    If you instantiate std::complex for user-defined types, all bets +are off.

    +
    +

    447. Wrong template argument for time facets

    Section: 22.1.1.1.1 [lib.locale.category]  Status: Dup  Submitter: Pete Becker  Date: 26 Dec 2003

    +

    +22.1.1.1.1/4, table 52, "Required Instantiations", lists, among others: +

    +
        time_get<char,InputIterator>
+    time_get_byname<char,InputIterator>
+    time_get<wchar_t,OutputIterator>
+    time_get_byname<wchar_t,OutputIterator>
+
    + +

    +The second argument to the last two should be InputIterator, not +OutputIterator. +

    +

    Proposed resolution:

    +

    +Change the second template argument to InputIterator. +

    +

    Rationale:

    +Duplicate of issue 327 +
    +

    450. set::find is inconsistent with associative container requirements

    Section: 23.3.3 [lib.set]  Status: Dup  Submitter: Bill Plauger  Date: 30 Jan 2004

    +

    map/multimap have:

    + +
    	iterator find(const key_type& x) const;
+	const_iterator find(const key_type& x) const;
+
    + +

    +which is consistent with the table of associative container requirements. +But set/multiset have: +

    +
    	iterator find(const key_type&) const;
+
    + +

    +set/multiset should look like map/multimap, and honor the requirements +table, in this regard. +

    +

    Proposed resolution:

    +

    Rationale:

    +

    Duplicate of issue 214.

    +
    +

    451. Associative erase should return an iterator

    Section: 23.1.2 [lib.associative.reqmts], 23.3 [lib.associative]  Status: Dup  Submitter: Bill Plauger  Date: 30 Jan 2004

    +

    map/multimap/set/multiset have:

    +
    	void erase(iterator);
+	void erase(iterator, iterator);
+
    + +

    But there's no good reason why these can't return an iterator, as for +vector/deque/list:

    +
    	iterator erase(iterator);
+	iterator erase(iterator, iterator);
+
    + +

    Proposed resolution:

    +

    +Informally: The table of associative container requirements, and the +relevant template classes, should return an iterator designating the +first element beyond the erased subrange. +

    +

    Rationale:

    +

    Duplicate of 130

    +
    +

    452.  locale::combine should be permitted to generate a named locale

    Section: 22.1.1.3 [lib.locale.members]  Status: NAD  Submitter: Bill Plauger  Date: 30 Jan 2004

    +
    template<class Facet>
+	locale::combine(const locale&) const;
+
    +

    +is obliged to create a locale that has no name. This is overspecification +and overkill. The resulting locale should follow the usual rules -- it +has a name if the locale argument has a name and Facet is one of the +standard facets. +

    + +

    [ + Sydney and post-Sydney (see c++std-lib-13439, c++std-lib-13440, + c++std-lib-13443): agreed that it's overkill to say that the locale + is obligated to be nameless. However, we also can't require it to + have a name. At the moment, locale names are based on categories + and not on individual facets. If a locale contains two different + facets of different names from the same category, then this would + not fit into existing naming schemes. We need to give + implementations more freedom. Bill will provide wording. +]

    + +

    Proposed resolution:

    +

    Rationale:

    +

    After further discussion the LWG decided to close this as NAD. + The fundamental problem is that names right now are per-category, + not per-facet. The combine member function works at the + wrong level of granularity.

    +
    +

    472. Missing "Returns" clause in std::equal_range

    Section: 25.3.3.3 [lib.equal.range]  Status: Dup  Submitter: Prateek R Karandikar  Date: 29 Feb 1900

    +

    +There is no "Returns:" clause for std::equal_range, which returns non-void. +

    +

    Proposed resolution:

    +

    Rationale:

    +

    Fixed as part of issue 270.

    +
    +

    476. Forward Iterator implied mutability

    Section: 24.1.3 [lib.forward.iterators]  Status: NAD  Submitter: Dave Abrahams  Date: 9 Jul 2004

    + +

    24.1/3 says:

    +
    + Forward iterators satisfy all the requirements of the input and + output iterators and can be used whenever either kind is specified +
    + +

    +The problem is that satisfying the requirements of output iterator +means that you can always assign *something* into the result of +dereferencing it. That makes almost all non-mutable forward +iterators non-conforming. I think we need to sever the refinement +relationship between forward iterator and output iterator. +

    + +

    Related issue: 200. But this is not a dup.

    + +

    Proposed resolution:

    +

    Rationale:

    +

    Yes, 24.1/3 does say that. But it's introductory material. The +precise specification is in 24.1.3, and the requrements table there is +right. We don't need to fine-tune introductory wording. (Especially +since this wording is likely to be changed as part of the iterator +overhaul.)

    +
    +

    477. Operator-> for const forward iterators

    Section: 24.1.3 [lib.forward.iterators]  Status: Dup  Submitter: Dave Abrahams  Date: 11 Jul 2004

    +

    +The Forward Iterator requirements table contains the following: +

    +
     expression  return type         operational  precondition
+                                  semantics
+  ==========  ==================  ===========  ==========================
+  a->m        U& if X is mutable, (*a).m       pre: (*a).m is well-defined.
+              otherwise const U&
+
+  r->m        U&                  (*r).m       pre: (*r).m is well-defined.
+
    + +

    +The first line is exactly right. The second line is wrong. Basically +it implies that the const-ness of the iterator affects the const-ness +of referenced members. But Paragraph 11 of [lib.iterator.requirements] says: +

    + +
    + In the following sections, a and b denote values of type const X, n + denotes a value of the difference type Distance, u, tmp, and m + denote identifiers, r denotes a value of X&, t denotes a value of + value type T, o denotes a value of some type that is writable to + the output iterator. +
    + +

    AFAICT if we need the second line at all, it should read the same +as the first line.

    + +

    Related issue: 478

    +

    Proposed resolution:

    +

    Rationale:

    +

    The LWG agrees that this is a real problem. Marked as a DUP + because the LWG chose to adopt the solution proposed in + 478. +

    +
    +

    480. unary_function and binary_function should have protected nonvirtual destructors

    Section: 20.3.1 [lib.tuple.tuple]  Status: NAD  Submitter: Joe Gottman  Date: 19 Aug 2004

    +

    The classes std::unary_function and std::binary_function are both +designed to be inherited from but contain no virtual functions. This +makes it too easy for a novice programmer to write code like +binary_function<int, int, int> *p = new plus<int>; delete p;

    + +

    There are two common ways to prevent this source of undefined +behavior: give the base class a public virtual destructor, or give it +a protected nonvirtual destructor. Since unary_function and +binary_function have no other virtual functions, (note in particular +the absence of an operator()() ), it would cost too much to give them +public virtual destructors. Therefore, they should be given protected +nonvirtual destructors.

    +

    Proposed resolution:

    +

    Change Paragraph 20.3.1 of the Standard from

    +
        template <class Arg, class Result>
+    struct unary_function {
+        typedef Arg argument_type;
+        typedef Result result_type;
+    };
+
+    template <class Arg1, class Arg2, class Result>
+    struct binary_function {
+        typedef Arg1 first_argument_type;
+        typedef Arg2 second_argument_type;
+        typedef Result result_type;
+    };
+
    + +

    to

    +
        template <class Arg, class Result>
+        struct unary_function {
+        typedef Arg argument_type;
+        typedef Result result_type;
+    protected:
+        ~unary_function() {}
+    };
+
+    template <class Arg1, class Arg2, class Result>
+    struct binary_function {
+        typedef Arg1 first_argument_type;
+        typedef Arg2 second_argument_type;
+        typedef Result result_type;
+    protected:
+        ~binary_function() {}
+    };
+
    +

    Rationale:

    +

    The LWG doesn't believe the existing definition causes anybody any + concrete harm.

    +
    +

    481. unique's effects on the range [result, last)

    Section: 25.2.8 [lib.alg.unique]  Status: NAD  Submitter: Andrew Koenig  Date: 30 Aug 2004

    +

    +The standard says that unique(first, last) "eliminates all but the +first element from every consecutive group of equal elements" in +[first, last) and returns "the end of the resulting range". So a +postcondition is that [first, result) is the same as the old [first, +last) except that duplicates have been eliminated. +

    + +

    What postconditions are there on the range [result, last)? One + might argue that the standard says nothing about those values, so + they can be anything. One might also argue that the standard + doesn't permit those values to be changed, so they must not be. + Should the standard say something explicit one way or the other?

    + +

    Proposed resolution:

    +

    +

    +

    Rationale:

    +

    We don't want to make many guarantees about what's in [result, +end). Maybe we aren't being quite explicit enough about not being +explicit, but it's hard to think that's a major problem.

    +
    +

    483. Heterogeneous equality and EqualityComparable

    Section: 25.1 [lib.alg.nonmodifying], 25.2 [lib.alg.modifying.operations]  Status: Dup  Submitter: Peter Dimov  Date: 20 Sep 2004

    +

    c++std-lib-14262

    + +

    [lib.alg.find] requires T to be EqualityComparable:

    + +
    template <class InputIterator, class T>
+   InputIterator find(InputIterator first, InputIterator last,
+                      const T& value);
+
    + +

    +However the condition being tested, as specified in the Effects +clause, is actually *i == value, where i is an InputIterator. +

    + +

    +The two clauses are in agreement only if the type of *i is T, but this +isn't necessarily the case. *i may have a heterogeneous comparison +operator that takes a T, or a T may be convertible to the type of *i. +

    + +

    Further discussion (c++std-lib-14264): this problem affects a + number of algorithsm in clause 25, not just find. We + should try to resolve this problem everywhere it appears.

    +

    Proposed resolution:

    + +

    [lib.alg.find]:

    +
    + Remove [lib.alg.find]/1. +
    + +

    [lib.alg.count]:

    +
    + Remove [lib.alg.count]/1. +
    + +

    [lib.alg.search]:

    +
    + Remove "Type T is EqualityComparable (20.1.1), " from [lib.alg.search]/4. +
    + +

    [lib.alg.replace]:

    + +
    +

    + Remove [lib.alg.replace]/1. + Replace [lb.alg.replace]/2 with: +

    + +
    + For every iterator i in the range [first, last) for which *i == value + or pred(*i) holds perform *i = new_value. +
    + +

    + Remove the first sentence of /4. + Replace the beginning of /5 with: +

    + +
    + For every iterator i in the range [result, result + (last - + first)), assign to *i either... +
    + +

    (Note the defect here, current text says assign to i, not *i).

    +
    + +

    [lib.alg.fill]:

    + +
    +

    + Remove "Type T is Assignable (23.1), " from /1. + Replace /2 with: +

    + +
    + For every iterator i in the range [first, last) or [first, first + n), + perform *i = value. +
    +
    + +

    [lib.alg.remove]:

    +
    + Remove /1. + Remove the first sentence of /6. +
    + +

    Rationale:

    +

    Duplicate of (a subset of) issue 283.

    +
    +

    486. min/max CopyConstructible requirement is too strict

    Section: 25.3.7 [lib.alg.min.max]  Status: Dup  Submitter: Dave Abrahams  Date: 13 Oct 2004

    +

    A straightforward implementation of these algorithms does not need to +copy T.

    +

    Proposed resolution:

    +

    drop the the words "and CopyConstructible" from paragraphs 1 and 4

    +

    Rationale:

    +

    Dup of 281.

    +
    +

    487. Allocator::construct is too limiting

    Section: 20.1.5 [lib.default.con.req]  Status: NAD  Submitter: Dhruv Matani  Date: 17 Oct 2004

    +

    +The standard's version of allocator::construct(pointer, +const_reference) severely limits what you can construct using this +function. Say you can construct a socket from a file descriptor. Now, +using this syntax, I first have to manually construct a socket from +the fd, and then pass the constructed socket to the construct() +function so it will just to an uninitialized copy of the socket I +manually constructed. Now it may not always be possible to copy +construct a socket eh! So, I feel that the changes should go in the +allocator::construct(), making it: +

    +
        template<typename T>
+    struct allocator{
+      template<typename T1>
+      void construct(pointer T1 const& rt1);
+    };
+
    + +

    +Now, the ctor of the class T which matches the one that takes a T1 can +be called! Doesn't that sound great? +

    +

    Proposed resolution:

    +

    Rationale:

    +

    NAD. STL uses copying all the time, and making it possible for + allocators to construct noncopyable objects is useless in the + absence of corresponding container changes. We might consider this + as part of a larger redesign of STL.

    +
    +

    489. std::remove / std::remove_if wrongly specified

    Section: 25.2.7 [lib.alg.remove]  Status: NAD  Submitter: Thomas Mang  Date: 12 Dec 2004

    +

    In Section 25.2.7 [lib.alg.remove], paragraphs 1 to 5 describe the +behavior of the mutating sequence operations std::remove and +std::remove_if. However, the wording does not reflect the intended +behavior [Note: See definition of intended behavior below] of these +algorithms, as it is known to the C++ community [1]. +

    + + + +

    1) Analysis of current wording:

    + + +

    25.2.7 [lib.alg.remove], paragraph 2:

    + +

    Current wording says: +"Effects: Eliminates all the elements referred to by iterator i in the +range [first, last) for which the following corresponding conditions +hold: *i == value, pred(*i) != false."

    + +

    +This sentences expresses specifically that all elements denoted by the +(original) range [first, last) for which the corresponding condition +hold will be eliminated. Since there is no formal definition of the term +"eliminate" provided, the meaning of "eliminate" in everyday language +implies that as postcondition, no element in the range denoted by +[first, last) will hold the corresponding condition on reiteration over +the range [first, last). +

    + +

    +However, this is neither the intent [Note: See definition of intended +behavior below] nor a general possible approach. It can be easily proven +that if all elements of the original range[first, last) will hold the +condition, it is not possible to substitute them by an element for which +the condition will not hold. +

    + + +

    25.2.7 [lib.alg.remove], paragraph 3:

    + +

    +Current wording says: +"Returns: The end of the resulting range." +

    + +

    +The resulting range is not specified. In combination with 25.2.7 +[lib.alg.remove], paragraph 2, the only reasonable interpretation of +this so-called resulting range is the range [first,last) - thus +returning always the ForwardIterator 'last' parameter. +

    + + +

    +25.2.7 [lib.alg.remove], paragraph 4: +

    + +

    +Current wording says: +"Notes: Stable: the relative order of the elements that are not removed +is the same as their relative order in the original range" +

    + +

    +This sentences makes use of the term "removed", which is neither +specified, nor used in a previous paragraph (which uses the term +"eliminate"), nor unamgiuously separated from the name of the algorithm. +

    + + +

    2) Description of intended behavior:

    + +

    +For the rest of this Defect Report, it is assumed that the intended +behavior was that all elements of the range [first, last) which do not +hold the condition *i == value (std::remove) or pred(*i) != false +(std::remove_if)], call them s-elements [Note: s...stay], will be placed +into a contiguous subrange of [first, last), denoted by the iterators +[first, return value). The number of elements in the resulting range +[first, return value) shall be equal to the number of s-elements in the +original range [first, last). The relative order of the elements in the +resulting subrange[first, return value) shall be the same as the +relative order of the corresponding elements in the original range. It +is undefined whether any elements in the resulting subrange [return +value, last) will hold the corresponding condition, or not. +

    + +

    +All implementations known to the author of this Defect Report comply +with this intent. Since the intent of the behavior (contrary to the +current wording) is also described in various utility references serving +the C++ community [1], it is not expected that fixing the paragraphs +will influence current code - unless the code relies on the behavior as +it is described by current wording and the implementation indeed +reflects the current wording, and not the intent. +

    + + + +

    3) Proposed fixes:

    + + +

    Change 25.2.7 [lib.alg.remove], paragraph 2 to:

    + +

    +"Effect: Places all the elements referred to by iterator i in the range +[first, last) for which the following corresponding conditions hold : +!(*i == value), pred(*i) == false into the subrange [first, k) of the +original range, where k shall denote a value of type ForwardIterator. It +is undefined whether any elements in the resulting subrange [k, last) +will hold the corresponding condition, or not." +

    + +

    Comments to the new wording:

    + +

    +a) "Places" has no special meaning, and the everyday language meaning +should fit. +b) The corresponding conditions were negated compared to the current +wording, becaue the new wording requires it. +c) The wording "of the original range" might be redundant, since any +subrange starting at 'first' and containing no more elements than the +original range is implicitly a subrange of the original range [first, +last). +d) The iterator k was introduced instead of "return value" in order to +avoid a cyclic dependency on 25.2.7/3. The wording ", where k shall +denote a value of type ForwardIterator" might be redundant, because it +follows implicitly by 25.2.7/3. +e) "Places" does, in the author's opinion, explicitly forbid duplicating +any element holding the corresponding condition in the original range +[first, last) within the resulting range [first, k). If there is doubt +this term might be not unambiguous regarding this, it is suggested that +k is specified more closely by the following wording: "k shall denote a +value of type ForwardIterator [Note: see d)] so that k - first is equal +to the number of elements in the original range [first, last) for which +the corresponding condition did hold". This could also be expressed as a +separate paragraph "Postcondition:" +f) The senctence "It is undefined whether any elements in the resulting +subrange [k, last) will hold the corresponding condition, or not." was +added consciously so the term "Places" does not imply if the original +range [first, last) contains n elements holding the corresponding +condition, the identical range[first, last) will also contain exactly n +elements holding the corresponding condition after application of the +algorithm. +

    + +

    +Change 25.2.7 [lib.alg.remove], paragraph 3 to: + +"Returns: The iterator k." +

    + +

    +Change 25.2.7 [lib.alg.remove], paragraph 4 to: + +"Notes: Stable: the relative order of the elements that are placed into +the subrange [first, return value) shall be the same as their relative +order was in the original range [first, last) prior to application of +the algorithm." +

    + +

    +Comments to the new wording: +

    + +

    +a) the wording "was ... prior to application of the algorithm" is used +to explicitly distinguish the original range not only by means of +iterators, but also by a 'chronological' factor from the resulting range +[first, return value). It might be redundant. +

    + +

    +[1]: +The wording of these references is not always unambiguous, and provided +examples partially contradict verbal description of the algorithms, +because the verbal description resembles the problematic wording of +ISO/IEC 14882:2003. +

    +

    Proposed resolution:

    +

    Rationale:

    +

    The LWG believes that the standard is sufficiently clear, and that + there is no evidence of any real-world confusion about this point.

    +
    +

    490. std::unique wrongly specified

    Section: 25.2.8 [lib.alg.unique]  Status: NAD  Submitter: Thomas Mang  Date: 12 Dec 2004

    +

    In Section 25.2.8 [lib.alg.unique], paragraphs 1 to 3 describe the +behavior of the mutating sequence operation std::unique. However, the +wording does not reflect the intended behavior [Note: See definition of +intended behavior below] of these algorithms, as it is known to the C++ +community [1].

    + + + +

    1) Analysis of current wording:

    + + +

    25.2.8 [lib.alg.unique], paragraph 1:

    + +

    +Current wording says: +"Effects: Eliminates all but the first element from every consecutive +group of equal elements referred to by the iterator i in the range +[first, last) for which the following corresponding conditions hold: *i +== *(i - 1) or pred(*i, *(i -1)) != false" +

    + +

    +This sentences expresses specifically that all elements denoted by the +(original) range [first, last) which are not but the first element from +a consecutive group of equal elements (where equality is defined as *i +== *(i - 1) or pred(*i, *(i - 1)) ! = false) [Note: See DR 202], call +them r-elements [Note: r...remove], will be eliminated. Since there is +no formal definition of the term "eliminate" provided, it is undefined +how this "elimination" takes place. But the meaning of "eliminate" in +everyday language seems to disallow explicitly that after application of +the algorithm, any r-element will remain at any position of the range +[first, last) [2]. +

    + +

    +Another defect in the current wording concerns the iterators used to +compare two elements for equality: The current wording contains the +expression "(i - 1)", which is not covered by 25/9 [Note: See DR +submitted by Thomas Mang regarding invalid iterator arithmetic +expressions]. +

    + + +

    +25.2.8 [lib.alg.unique], paragraph 2: +

    +

    Current wording says: +"Returns: The end of the resulting range."

    + +

    +The resulting range is not specified. In combination with 25.2.8 +[lib.alg.unique], paragraph 1, one reasonable interpretation (in the +author's opinion even the only possible interpretation) of this +so-called resulting range is the range [first, last) - thus returning +always the ForwardIterator 'last' parameter. +

    + +

    2) Description of intended behavior:

    + +

    +For the rest of this Defect Report, it is assumed that the intended +behavior was that all elements denoted by the original range [first, +last) which are the first element from a consecutive group of elements +for which the corresponding conditions: *(i-1) == *i (for the version of +unique without a predicate argument) or pred(*(i-1), *i) ! = false (for +the version of unique with a predicate argument) [Note: If such a group +of elements consists of only a single element, this is also considered +the first element] [Note: See resolutions of DR 202], call them +s-elements [Note: s...stay], will be placed into a contiguous subrange +of [first, last), denoted by the iterators [first, return value). The +number of elements in the resulting range [first, return value) shall be +equal to the number of s-elements in the original range [first, last). +Invalid iterator arithmetic expressions are expected to be resolved as +proposed in DR submitted by Thomas Mang regarding invalid iterator +arithmetic expressions. It is also assumed by the author that the +relative order of the elements in the resulting subrange [first, return +value) shall be the same as the relative order of the corresponding +elements (the s-elements) in the original range [Note: If this was not +intended behavior, the additional proposed paragraph about stable order +will certainly become obsolete]. +Furthermore, the resolutions of DR 202 are partially considered. +

    + +

    +All implementations known to the author of this Defect Report comply +with this intent [Note: Except possible effects of DR 202]. Since this +intent of the behavior (contrary to the current wording) is also +described in various utility references serving the C++ community [1], +it is not expected that fixing the paragraphs will influence current +code [Note: Except possible effects of DR 202] - unless the code relies +on the behavior as it is described by current wording and the +implementation indeed reflects the current wording, and not the intent. +

    + + + +

    3) Proposed fixes:

    + +

    +Change 25.2.8 [lib.alg.unique], paragraph 1 to: +

    + +

    +"Effect: Places the first element from every consecutive group of +elements, referred to by the iterator i in the range [first, last), for +which the following conditions hold: *(i-1) == *i (for the version of +unique without a predicate argument) or pred(*(i -1), *i) != false (for +the version of unique with a predicate argument), into the subrange +[first, k) of the original range, where k shall denote a value of type +ForwardIterator." +

    + +

    Comments to the new wording:

    + +

    +a) The new wording was influenced by the resolutions of DR 202. If DR +202 is resolved in another way, the proposed wording need also +additional review. +b) "Places" has no special meaning, and the everyday language meaning +should fit. +c) The expression "(i - 1)" was left, but is expected that DR submitted +by Thomas Mang regarding invalid iterator arithmetic expressions will +take this into account. +d) The wording "(for the version of unique without a predicate +argument)" and "(for the version of unique with a predicate argument)" +was added consciously for clarity and is in resemblence with current +23.2.2.4 [lib.list.ops], paragraph 19. It might be considered redundant. +e) The wording "of the original range" might be redundant, since any +subrange starting at first and containing no more elements than the +original range is implicitly a subrange of the original range [first, +last). +f) The iterator k was introduced instead of "return value" in order to +avoid a cyclic dependency on 25.2.8 [lib.alg.unique], paragraph 2. The +wording ", where k shall denote a value of type ForwardIterator" might +be redundant, because it follows implicitly by 25.2.8 [lib.alg.unique], +paragraph 2. +g) "Places" does, in the author's opinion, explicitly forbid duplicating +any s-element in the original range [first, last) within the resulting +range [first, k). If there is doubt this term might be not unambiguous +regarding this, it is suggested that k is specified more closely by the +following wording: "k shall denote a value of type ForwardIterator +[Note: See f)] so that k - first is equal to the number of elements in +the original range [first, last) being the first element from every +consecutive group of elements for which the corresponding condition did +hold". This could also be expressed as a separate paragraph +"Postcondition:". +h) If it is considered that the wording is unclear whether it declares +the element of a group which consists of only a single element +implicitly to be the first element of this group [Note: Such an +interpretation could eventually arise especially in case last - first == +1] , the following additional sentence is proposed: "If such a group of +elements consists of only a single element, this element is also +considered the first element." +

    + +

    +Change 25.2.8 [lib.alg.unique], paragraph 2 to: +"Returns: The iterator k." +

    + +

    +Add a separate paragraph "Notes:" as 25.2.8 [lib.alg.unique], paragraph +2a or 3a, or a separate paragraph "Postcondition:" before 25.2.8 +[lib.alg.unique], paragraph 2 (wording inside {} shall be eliminated if +the preceding expressions are used, or the preceding expressions shall +be eliminated if wording inside {} is used): +

    + +

    +"Notes:{Postcondition:} Stable: the relative order of the elements that +are placed into the subrange [first, return value {k}) shall be the same +as their relative order was in the original range [first, last) prior to +application of the algorithm." +

    + +

    Comments to the new wording:

    + +

    +a) It is assumed by the author that the algorithm was intended to be +stable. +In case this was not the intent, this paragraph becomes certainly +obsolete. +b) The wording "was ... prior to application of the algorithm" is used +to explicitly distinguish the original range not only by means of +iterators, but also by a 'chronological' factor from the resulting range +[first, return value). It might be redundant. +

    + +

    +25.2.8 [lib.alg.unique], paragraph 3: +

    +

    See DR 239.

    + +

    +4) References to other DRs: +

    + +

    +See DR 202, but which does not address any of the problems described in +this Defect Report [Note: This DR is supposed to complement DR 202]. +See DR 239. +See DR submitted by Thomas Mang regarding invalid iterator arithmetic +expressions. +

    + +

    +[1]: +The wording of these references is not always unambiguous, and provided +examples partially contradict verbal description of the algorithms, +because the verbal description resembles the problematic wording of +ISO/IEC 14882:2003. +

    + +

    +[2]: +Illustration of conforming implementations according to current wording: +

    + +

    +One way the author of this DR considers how this "elimination" could be +achieved by a conforming implementation according to current wording is +by substituting each r-element by _any_ s-element [Note: s...stay; any +non-r-element], since all r-elements are "eliminated". +

    + +

    +In case of a sequence consisting of elements being all 'equal' [Note: +See DR 202], substituting each r-element by the single s-element is the +only possible solution according to current wording. +

    +

    Proposed resolution:

    +

    Rationale:

    +

    The LWG believes the standard is sufficiently clear. No +implementers get it wrong, and changing it wouldn't cause any code to +change, so there is no real-world harm here.

    +
    +

    491. std::list<>::unique incorrectly specified

    Section: 23.2.2.4 [lib.deque.special]  Status: NAD  Submitter: Thomas Mang  Date: 12 Dec 2004

    +

    In Section 23.2.2.4 [lib.list.ops], paragraphs 19 to 21 describe the +behavior of the std::list<T, Allocator>::unique operation. However, the +current wording is defective for various reasons.

    + + + +

    +1) Analysis of current wording: +

    + +

    23.2.2.4 [lib.list.ops], paragraph 19:

    + +

    +Current wording says: +"Effects: Eliminates all but the first element from every consecutive +group of equal elements referred to by the iterator i in the range +[first + 1, last) for which *i == *(i - 1) (for the version of unique +with no argument) or pred(*i, *(i -1)) (for the version of unique with a +predicate argument) holds."

    + +

    +This sentences makes use of the undefined term "Eliminates". Although it +is, to a certain degree, reasonable to consider the term "eliminate" +synonymous with "erase", using "Erase" in the first place, as the +wording of 23.2.2.4 [lib.list.ops], paragraph 15 does, would be clearer.

    + +

    +The range of the elements referred to by iterator i is "[first + 1, +last)". However, neither "first" nor "last" is defined.

    + +

    +The sentence makes three times use of iterator arithmetic expressions ( +"first + 1", "*i == *(i - 1)", "pred(*i, *(i -1))" ) which is not +defined for bidirectional iterator [see DR submitted by Thomas Mang +regarding invalid iterator arithmetic expressions].

    + +

    +The same problems as pointed out in DR 202 (equivalence relation / order +of arguments for pred()) apply to this paragraph.

    + +

    +23.2.2.4 [lib.list.ops], paragraph 20: +

    + +

    +Current wording says: +"Throws: Nothing unless an exception in thrown by *i == *(i-1) or +pred(*i, *(i - 1))"

    + +

    +The sentence makes two times use of invalid iterator arithmetic +expressions ( "*i == *(i - 1)", "pred(*i, *(i -1))" ). +

    +

    +[Note: Minor typos: "in" / missing dot at end of sentence.] +

    + +

    +23.2.2.4 [lib.list.ops], paragraph 21:

    + +

    +Current wording says: +"Complexity: If the range (last - first) is not empty, exactly (last - +first) - 1 applications of the corresponding predicate, otherwise no +application of the predicate.

    + +

    +See DR 315 regarding "(last - first)" not yielding a range.

    + +

    +Invalid iterator arithmetic expression "(last - first) - 1" left .

    + + +

    2) Description of intended behavior:

    + +

    +For the rest of this Defect Report, it is assumed that "eliminate" is +supposed to be synonymous to "erase", that "first" is equivalent to an +iterator obtained by a call to begin(), "last" is equivalent to an +iterator obtained by a call to end(), and that all invalid iterator +arithmetic expressions are resolved as described in DR submitted by +Thomas Mang regarding invalid iterator arithmetic expressions.

    + +

    +Furthermore, the resolutions of DR 202 are considered regarding +equivalence relation and order of arguments for a call to pred.

    + +

    +All implementations known to the author of this Defect Report comply +with these assumptions, apart from the impact of the alternative +resolution of DR 202. Except for the changes implied by the resolutions +of DR 202, no impact on current code is expected.

    + +

    +3) Proposed fixes:

    + +

    +Change 23.2.2.4 [lib.list.ops], paragraph 19 to:

    + +

    +"Effect: Erases all but the first element from every consecutive group +of elements, referred to by the iterator i in the range [begin(), +end()), for which the following conditions hold: *(i-1) == *i (for the +version of unique with no argument) or pred(*(i-1), *i) != false (for +the version of unique with a predicate argument)."

    + +

    +Comments to the new wording:

    + +

    +a) The new wording was influenced by DR 202 and the resolutions +presented there. If DR 202 is resolved in another way, the proposed +wording need also additional review. +b) "Erases" refers in the author's opinion unambiguously to the member +function "erase". In case there is doubt this might not be unamgibuous, +a direct reference to the member function "erase" is suggested [Note: +This would also imply a change of 23.2.2.4 [lib.list.ops], paragraph +15.]. +c) The expression "(i - 1)" was left, but is expected that DR submitted +by Thomas Mang regarding invalid iterator arithmetic expressions will +take this into account. +d) The wording "(for the version of unique with no argument)" and "(for +the version of unique with a predicate argument)" was kept consciously +for clarity. +e) "begin()" substitutes "first", and "end()" substitutes "last". The +range need adjustment from "[first + 1, last)" to "[begin(), end())" to +ensure a valid range in case of an empty list. +f) If it is considered that the wording is unclear whether it declares +the element of a group which consists of only a single element +implicitly to be the first element of this group [Note: Such an +interpretation could eventually arise especially in case size() == 1] , +the following additional sentence is proposed: "If such a group of +elements consists of only a single element, this element is also +considered the first element."

    + +

    +Change 23.2.2.4 [lib.list.ops], paragraph 20 to:

    + +

    +"Throws: Nothing unless an exception is thrown by *(i-1) == *i or +pred(*(i-1), *i)."

    + +

    +Comments to the new wording:

    + +

    +a) The wording regarding the conditions is identical to proposed +23.2.2.4 [lib.list.ops], paragraph 19. If 23.2.2.4 [lib.list.ops], +paragraph 19 is resolved in another way, the proposed wording need also +additional review. +b) The expression "(i - 1)" was left, but is expected that DR submitted +by Thomas Mang regarding invalid iterator arithmetic expressions will +take this into account. +c) Typos fixed.

    + +

    +Change 23.2.2.4 [lib.list.ops], paragraph 21 to:

    + +

    +"Complexity: If empty() == false, exactly size() - 1 applications of the +corresponding predicate, otherwise no applications of the corresponding +predicate."

    + +

    +Comments to the new wording:

    + +

    +a) The new wording is supposed to also replace the proposed resolution +of DR 315, which suffers from the problem of undefined "first" / "last". +

    + +

    +5) References to other DRs:

    + +

    See DR 202. +See DR 239. +See DR 315. +See DR submitted by Thomas Mang regarding invalid iterator arithmetic +expressions.

    + +

    Proposed resolution:

    +

    Rationale:

    +

    "All implementations known to the author of this Defect Report +comply with these assumption", and "no impact on current code is +expected", i.e. there is no evidence of real-world confusion or +harm.

    +
    +

    493. Undefined Expression in Input Iterator Note Title

    Section: 24.1.1 [lib.input.iterators]  Status: NAD  Submitter: Chris Jefferson  Date: 13 Dec 2004

    +

    1) In 24.1.1/3, the following text is currently present.

    + +

    "Note: For input iterators, a==b does not imply ++a=++b (Equality does +not guarantee the substitution property or referential transparency)."

    + +

    However, when in Table 72, part of the definition of ++r is given as:

    + +

    "pre: r is dereferenceable. +post: any copies of the previous value of r are no longer required +either to be dereferenceable ..."

    + +

    While a==b does not imply that b is a copy of a, this statement should +perhaps still be made more clear.

    + +

    2) There are no changes to intended behaviour

    + +

    +3) This Note should be altered to say "Note: For input iterators a==b, +when its behaviour is defined ++a==++b may still be false (Equality does +not guarantee the substitution property or referential transparency).

    + +

    Proposed resolution:

    +

    Rationale:

    +

    This is descriptive text, not normative, and the meaning is clear.

    +
    +

    494. Wrong runtime complexity for associative container's insert and delete

    Section: 23.1.2 [lib.associative.reqmts]  Status: NAD  Submitter: Hans B os  Date: 19 Dec 2004

    +

    According to [lib.associative.reqmts] table 69, the runtime comlexity +of insert(p, t) and erase(q) can be done in amortized constant time.

    + +

    It was my understanding that an associative container could be +implemented as a balanced binary tree.

    + +

    For inser(p, t), you 'll have to iterate to p's next node to see if t +can be placed next to p. Furthermore, the insertion usually takes +place at leaf nodes. An insert next to the root node will be done at +the left of the root next node

    + +

    So when p is the root node you 'll have to iterate from the root to +its next node, which takes O(log(size)) time in a balanced tree.

    + +

    If you insert all values with insert(root, t) (where root is the +root of the tree before insertion) then each insert takes O(log(size)) +time. The amortized complexity per insertion will be O(log(size)) +also.

    + +

    For erase(q), the normal algorithm for deleting a node that has no +empty left or right subtree, is to iterate to the next (or previous), +which is a leaf node. Then exchange the node with the next and delete +the leaf node. Furthermore according to DR 130, erase should return +the next node of the node erased. Thus erasing the root node, +requires iterating to the next node.

    + +

    Now if you empty a map by deleting the root node until the map is +empty, each operation will take O(log(size)), and the amortized +complexity is still O(log(size)).

    + +

    The operations can be done in amortized constant time if iterating +to the next node can be done in (non amortized) constant time. This +can be done by putting all nodes in a double linked list. This +requires two extra links per node. To me this is a bit overkill since +you can already efficiently insert or erase ranges with erase(first, +last) and insert(first, last).

    + +

    Proposed resolution:

    +

    Rationale:

    +

    Only "amortized constant" in special circumstances, and we believe + that's implementable. That is: doing this N times will be O(N), not + O(log N).

    +
    +

    499. Std. doesn't seem to require stable_sort() to be stable!

    Section: 25.3.1.2 [lib.stable.sort]  Status: NAD  Submitter: Prateek Karandikar  Date: 12 Apr 2005

    +
    +

    +17.3.1.1 Summary

    + +

    +1 The Summary provides a synopsis of the category, and introduces the +first-level subclauses. Each subclause also provides a summary, listing +the headers specified in the subclause and the library entities +provided in each header. +

    +

    +2 Paragraphs labelled "Note(s):" or "Example(s):" are informative, +other paragraphs are normative. +

    +
    + +

    So this means that a "Notes" paragraph wouldn't be normative.

    + +
    +

    +25.3.1.2 stable_sort +

    +
    template<class RandomAccessIterator> 
+void stable_sort(RandomAccessIterat or first, RandomAccessIterator last); 
+
+template<class RandomAccessIterator, class Compare> 
+void stable_sort(RandomAccessIterat or first, RandomAccessIterator last, Compare comp);
+
    +

    +1 Effects: Sorts the elements in the range [first, last). +

    +

    +2 Complexity: It does at most N(log N)^2 (where N == last - first) +comparisons; if enough extra memory is available, it is N log N. +

    +

    +3 Notes: Stable: the relative order of the equivalent elements is +preserved. +

    +
    + +

    +The Notes para is informative, and nowhere else is stability mentioned above. +

    + +

    +Also, I just searched for the word "stable" in my copy of the Standard. +and the phrase "Notes: Stable: the relative order of the elements..." +is repeated several times in the Standard library clauses for +describing various functions. How is it that stability is talked about +in the informative paragraph? Or am I missing something obvious? +

    +

    Proposed resolution:

    +

    +

    +

    Rationale:

    +

    +This change has already been made. +

    +
    +

    500. do_length cannot be implemented correctly

    Section: 22.2.1.5 [lib.locale.codecvt.byname]  Status: NAD  Submitter: Krzysztof ¯elechowski  Date: 24 May 2005

    +
      +
    1. codecvt::do_length is of type int;
      2. +
    2. it is assumed to be sort-of returning from_next - from of type ptrdiff_t;
      3. +
    3. ptrdiff_t cannot be cast to an int without data loss.
      4. +
    +

    +Contradiction. +

    +

    Proposed resolution:

    +

    +

    +
    +

    501. Proposal: strengthen guarantees of lib.comparisons

    Section: 20.5.3 [lib.base]  Status: NAD  Submitter: Me <anti_spam_email2003@yahoo.com>  Date: 7 Jun 2005

    +
    +"For templates greater, less, greater_equal, and less_equal, +the specializations for any pointer type yield a total order, even if +the built-in operators <, >, <=, >= do not." +
    + +

    +The standard should do much better than guarantee that these provide a +total order, it should guarantee that it can be used to test if memory +overlaps, i.e. write a portable memmove. You can imagine a platform +where the built-in operators use a uint32_t comparison (this tests for +overlap on this platform) but the less<T*> functor is allowed to be +defined to use a int32_t comparison. On this platform, if you use +std::less with the intent of making a portable memmove, comparison on +an array that straddles the 0x7FFFFFFF/0x8000000 boundary can give +incorrect results. +

    +

    Proposed resolution:

    +

    +Add a footnote to 20.5.3/8 saying: +

    + +
    +Given a p1 and p2 such that p1 points to N objects of type T and p2 +points to M objects of type T. If [p1,p1+N) does not overlap [p2,p2+M), +less returns the same value when comparing all pointers in [p1,p1+N) to +all pointers in [p2,p2+M). Otherwise, there is a value Q and a value R +such that less returns the same value when comparing all pointers in +[p1,p1+Q) to all pointers in [p2,p2+R) and an opposite value when +comparing all pointers in [p1+Q,p1+N) to all pointers in [p2+R,p2+M). +For the sake of completeness, the null pointer value (4.10) for T is +considered to be an array of 1 object that doesn't overlap with any +non-null pointer to T. less_equal, greater, greater_equal, equal_to, +and not_equal_to give the expected results based on the total ordering +semantics of less. For T of void, treat it as having similar semantics +as T of char i.e. less<cv T*>(a, b) gives the same results as less<cv +void*>(a, b) which gives the same results as less<cv char*>((cv +char*)(cv void*)a, (cv char*)(cv void*)b). +
    + +

    +I'm also thinking there should be a footnote to 20.5.3/1 saying that if +A and B are similar types (4.4/4), comp<A>(a,b) returns the same value +as comp<B>(a,b) (where comp is less, less_equal, etc.). But this might +be problematic if there is some really funky operator overloading going +on that does different things based on cv (that should be undefined +behavior if somebody does that though). This at least should be +guaranteed for all POD types (especially pointers) that use the +built-in comparison operators. +

    + +

    Rationale:

    +less is already required to provide a strict weak ordering which is good enough +to detect overlapping memory situations. +
    +

    504. Integer types in pseudo-random number engine requirements

    Section: TR1 5.1.1 [tr.rand.req]  Status: NAD  Submitter: Walter Brown  Date: 3 Jul 2005

    +

    +In [tr.rand.req], Paragraph 2 states that "... s is a value of integral type, +g is an ... object returning values of unsigned integral type ..." +

    +

    Proposed resolution:

    +

    +In 5.1.1 [tr.rand.req], Paragraph 2 replace +

    + +
    +... s is a value of integral type, g is an lvalue of a type other than X that +defines a zero-argument function object returning values of unsigned integral type +unsigned long int, +... +
    + +

    +In 5.1.1 [tr.rand.seq], Table 16, replace in the line for X(s) +

    + +
    +creates an engine with the initial internal state +determined by static_cast<unsigned long>(s) +
    + +

    [ +Mont Tremblant: Both s and g should be unsigned long. +This should refer to the constructor signatures. Jens provided wording post Mont Tremblant. +]

    + +

    [ +Berlin: N1932 adopts the proposed resolution: see 26.3.1.3/1e and Table 3 row 2. Moved +to Ready. +]

    + +

    Rationale:

    +

    +Jens: Just requiring X(unsigned long) still makes it possible +for an evil library writer to also supply a X(int) that does something +unexpected. The wording above requires that X(s) always performs +as if X(unsigned long) would have been called. I believe that is +sufficient and implements our intentions from Mont Tremblant. I +see no additional use in actually requiring a X(unsigned long) +signature. u.seed(s) is covered by its reference to X(s), same +arguments. +

    +
    +

    506. Requirements of Distribution parameter for variate_generator

    Section: TR1 5.1.3 [tr.rand.var]  Status: NAD  Submitter: Walter Brown  Date: 3 Jul 2005

    +

    +Paragraph 3 requires that template argument U (which corresponds to template +parameter Engine) satisfy all uniform random number generator requirements. +However, there is no analogous requirement regarding the template argument +that corresponds to template parameter Distribution. We believe there should +be, and that it should require that this template argument satisfy all random +distribution requirements. +

    +

    Proposed resolution:

    +

    +Consequence 1: Remove the precondition clauses [tr.rand.var]/16 and /18. +

    +

    +Consequence 2: Add max() and min() functions to those distributions that +do not already have them. +

    + +

    [ +Mont Tremblant: Jens reccommends NAD, min/max not needed everywhere. +Marc supports having min and max to satisfy generic programming interface. +]

    + +

    Rationale:

    +Berlin: N1932 makes this moot: variate_generator has been eliminated. +
    +

    509. Uniform_int template parameters

    Section: TR1 5.1.7.1 [tr.rand.dist.iunif]  Status: NAD  Submitter: Walter Brown  Date: 3 Jul 2005

    +

    +In [tr.rand.dist.iunif] the uniform_int distribution currently has a single +template parameter, IntType, used as the input_type and as the result_type +of the distribution. We believe there is no reason to conflate these types +in this way. +

    +

    Proposed resolution:

    +

    +We recommend that there be a second template parameter to +reflect the distributionÕs input_type, and that the existing first template +parameter continue to reflect (solely) the result_type: +

    +
    template< class IntType = int, UIntType = unsigned int >
+class uniform_int
+{
+public:
+  // types
+  typedef  UIntType  input_type;
+  typedef  IntType   result_type;
+
    + +

    [ +Berlin: Moved to NAD. N1932 makes this moot: the input_type template parameter has been +eliminated. +]

    + +
    +

    510. Input_type for bernoulli_distribution

    Section: TR1 5.1.7.2 [tr.rand.dist.bern]  Status: NAD  Submitter: Walter Brown  Date: 3 Jul 2005

    +

    +In [tr.rand.dist.bern] the distribution currently requires; +

    +
    typedef  int  input_type;
+
    +

    Proposed resolution:

    +

    +We believe this is an unfortunate choice, and recommend instead: +

    +
    typedef  unsigned int  input_type;
+
    + +

    [ +Berlin: Moved to NAD. N1932 makes this moot: the input_type template parameter has been +eliminated. +]

    + +
    +

    511. Input_type for binomial_distribution

    Section: TR1 5.1.7.5 [tr.rand.dist.bin]  Status: NAD  Submitter: Walter Brown  Date: 3 Jul 2005

    +

    +Unlike all other distributions in TR1, this binomial_distribution has an +implementation-defined input_type. We believe this is an unfortunate choice, +because it hinders users from writing portable code. It also hinders the +writing of compliance tests. We recommend instead: +

    +
    typedef  RealType  input_type;
+
    +

    +While this choice is somewhat arbitrary (as it was for some of the other +distributions), we make this particular choice because (unlike all other +distributions) otherwise this template would not publish its RealType +argument and so users could not write generic code that accessed this +second template parameter. In this respect, the choice is consistent with +the other distributions in TR1. +

    +

    +We have two reasons for recommending that a real type be specified instead. +One reason is based specifically on characteristics of binomial distribution +implementations, while the other is based on mathematical characteristics of +probability distribution functions in general. +

    +

    +Implementations of binomial distributions commonly use Stirling approximations +for values in certain ranges. It is far more natural to use real values to +represent these approximations than it would be to use integral values to do +so. In other ranges, implementations reply on the Bernoulli distribution to +obtain values. While TR1Õs bernoulli_distribution::input_type is specified as +int, we believe this would be better specified as double. +

    +

    +This brings us to our main point: The notion of a random distribution rests +on the notion of a cumulative distribution function, which in turn mathematically +depends on a continuous dependent variable. Indeed, such a distribution function +would be meaningless if it depended on discrete values such as integersÑand this +remains true even if the distribution function were to take discrete steps. +

    +

    +Although this note is specifically about binomial_distribution::input_type, +we intend to recommend that all of the random distributionsÕ input_types be +specified as a real type (either a RealType template parameter, or double, +as appropriate). +

    +

    +Of the nine distributions in TR1, four already have this characteristic +(uniform_real, exponential_distribution, normal_distribution, and +gamma_distribution). We have already argued the case for the binomial the +remaining four distributions. +

    +

    +In the case of uniform_int, we believe that the calculations to produce an +integer result in a specified range from an integer in a different specified +range is best done using real arithmetic. This is because it involves a +product, one of whose terms is the ratio of the extents of the two ranges. +Without real arithmetic, the results become less uniform: some numbers become +more (or less) probable that they should be. This is, of course, undesireable +behavior in a uniform distribution. +

    +

    +Finally, we believe that in the case of the bernoulli_distribution (briefly +mentioned earlier), as well as the cases of the geometric_distribution and the +poisson_distribution, it would be far more natural to have a real input_type. +This is because the most natural computation involves the random number +delivered and the distributionÕs parameter p (in the case of bernoulli_distribution, +for example, the computation is a comparison against p), and p is already specified +in each case as having some real type. +

    +

    Proposed resolution:

    +
    typedef  RealType  input_type;
+
    + +

    [ +Berlin: Moved to NAD. N1932 makes this moot: the input_type template parameter has been +eliminated. +]

    +
    +

    512. Seeding subtract_with_carry_01 from a single unsigned long

    Section: TR1 5.1.4.4 [tr.rand.eng.sub1]  Status: NAD  Submitter: Walter Brown  Date: 3 Jul 2005

    +

    +Paragraph 8 specifies the algorithm by which a subtract_with_carry_01 engine +is to be seeded given a single unsigned long. This algorithm is seriously +flawed in the case where the engine parameter w (also known as word_size) +exceeds 31 [bits]. The key part of the paragraph reads: +

    +
    +sets x(-r) ... x(-1) to (lcg(1)*2**(-w)) mod 1 +
    +

    +and so forth. +

    +

    +Since the specified linear congruential engine, lcg, delivers numbers with +a maximum of 2147483563 (just a shade under 31 bits), then when w is, for +example, 48, each of the x(i) will be less than 2**-17. The consequence +is that roughly the first 400 numbers delivered will be conspicuously +close to either zero or one. +

    +

    +Unfortunately, this is not an innocuous flaw: One of the predefined engines +in [tr.rand.predef], namely ranlux64_base_01, has w = 48 and would exhibit +this poor behavior, while the original N1378 proposal states that these +pre-defined engines are intended to be of "known good properties." +

    +

    Proposed resolution:

    +

    +In 5.1.4.4 [tr.rand.eng.sub1], replace the "effects" clause for +void seed(unsigned long value = 19780503) by +

    + +
    +Effects: If value == 0, sets value to 19780503. In any +case, with a linear congruential generator lcg(i) having parameters +mlcg = 2147483563, alcg = 40014, +clcg = 0, and lcg(0) = value, +sets carry(-1) and x(-r) … x(-1) +as if executing + +
    
+linear_congruential<unsigned long, 40014, 0, 2147483563> lcg(value);
+seed(lcg);
+
    + +to (lcg(1) · 2-w) mod 1 +… (lcg(r) · 2-w) mod 1, +respectively. If x(-1) == 0, sets carry(-1) = 2-w, +else sets carry(-1) = 0. +
    + +

    [ +Jens provided revised wording post Mont Tremblant. +]

    + +

    [ +Berlin: N1932 adopts the originally-proposed resolution of the issue. +Jens's supplied wording is a clearer description of what is +intended. Moved to Ready. +]

    + +

    Rationale:

    +

    +Jens: I'm using an explicit type here, because fixing the +prose would probably not qualify for the (with issue 504 even +stricter) requirements we have for seed(Gen&). +

    + +

    [ +Portland: Subsumed by N2111. +]

    +
    +

    513. Size of state for subtract_with_carry_01

    Section: TR1 5.1.4.4 [tr.rand.eng.sub1]  Status: NAD  Submitter: Walter Brown  Date: 3 Jul 2005

    +

    +Paragraph 3 begins: +

    +
    +The size of the state is r. +
    +

    +However, this is not quite consistent with the remainder of the paragraph +which specifies a total of nr+1 items in the textual representation of +the state. We recommend the sentence be corrected to match: +

    +
    +The size of the state is nr+1. +
    +

    +To give meaning to the coefficient n, it may be also desirable to move +nÕs definition from later in the paragraph. Either of the following +seem reasonable formulations: +

    +
    +With n=..., the size of the state is nr+1. +
    +
    +The size of the state is nr+1, where n=... . +
    +

    +

    +

    Proposed resolution:

    +

    [ +Jens: I plead for "NAD" on the grounds that "size of state" is only +used as an argument for big-O complexity notation, thus +constant factors and additions don't count. +]

    + +

    [ +Berlin: N1932 adopts the proposed NAD. +]

    + +
    +

    514. Size of state for subtract_with_carry

    Section: TR1 5.1.4.3 [tr.rand.eng.sub]  Status: NAD  Submitter: Walter Brown  Date: 3 Jul 2005

    +

    +Paragraph 2 begins: +

    +
    +The size of the state is r. +
    +

    +However, the next sentence specifies a total of r+1 items in the textual +representation of the state, r specific xÕs as well as a specific carry. +This makes a total of r+1 items that constitute the size of the state, +rather than r. +

    +

    Proposed resolution:

    +

    +We recommend the sentence be corrected to match: +

    +
    + The size of the state is r+1. +
    + +

    [ +Jens: I plead for "NAD" on the grounds that "size of state" is only +used as an argument for big-O complexity notation, thus +constant factors and additions don't count. +]

    + +

    [ +Berlin: N1932 adopts the proposed NAD. +]

    + +
    +

    516. Seeding subtract_with_carry_01 using a generator

    Section: TR1 5.1.4.4 [tr.rand.eng.sub1]  Status: NAD  Submitter: Walter Brown  Date: 3 Jul 2005

    +

    +Paragraph 6 says: +

    +
    +... obtained by successive invocations of g, ... +
    +

    +We recommend instead: +

    +
    +... obtained by taking successive invocations of g mod 2**32, ... +
    +

    +as the context seems to require only 32-bit quantities be used here. +

    +

    Proposed resolution:

    +

    +Berlin: N1932 adopts the proposed resultion: see 26.3.3.4/7. Moved to Ready. +

    + +

    [ +Portland: Subsumed by N2111. +]

    +
    +

    517. Should include name in external representation

    Section: TR1 5.1.1 [tr.rand.req]  Status: NAD  Submitter: Walter Brown  Date: 3 Jul 2005

    +

    +The last two rows of Table 16 deal with the i/o requirements of an engine, +specifying that the textual representation of an engineÕs state, +appropriately formatted, constitute the engineÕs external representation. +

    +

    +This seems adequate when an engineÕs type is known. However, it seems +inadequate in the context of generic code, where it becomes useful and +perhaps even necessary to determine an engineÕs type via input. +

    +

    +

    +

    Proposed resolution:

    +

    +We therefore recommend that, in each of these two rows of Table 16, the +text "textual representation" be expanded so as to read "engine name +followed by the textual representation." +

    + +

    [ +Berlin: N1932 considers this NAD. This is a QOI issue. +]

    + +
    +

    544. minor NULL problems in C.2

    Section: C.2 [diff.library]  Status: NAD  Submitter: Martin Sebor  Date: 25 Nov 2005

    +

    +According to C.2.2.3, p1, "the macro NULL, defined in any of <clocale>, +<cstddef>, <cstdio>, <cstdlib>, <cstring>, <ctime>, +or <cwchar>." This is consistent with the C standard. +

    +

    +However, Table 95 in C.2 fails to mention <clocale> and <cstdlib>. +

    +

    +In addition, C.2, p2 claims that "The C++ Standard library provides +54 standard macros from the C library, as shown in Table 95." While +table 95 does have 54 entries, since a couple of them (including the +NULL macro) are listed more than once, the actual number of macros +defined by the C++ Standard Library may not be 54. +

    +

    Proposed resolution:

    +

    +I propose we add <clocale> and <cstdlib> to Table 96 and remove the +number of macros from C.2, p2 and reword the sentence as follows: +

    +
    +The C++ Standard library provides 54 standard macros from +defines a number macros corresponding to those defined by the C +Standard library, as shown in Table 96. +
    + +

    [ +Portland: Resolution is considered editorial. It will be incorporated into the WD. +]

    + +
    +

    549. Undefined variable in binomial_distribution

    Section: TR1 5.1.7.5 [tr.rand.dist.bin]  Status: NAD  Submitter: Matt Austern  Date: 10 Jan 2006

    +

    +Paragraph 1 says that "A binomial distributon random distribution produces +integer values i>0 with p(i) = (n choose i) * p*i * (1-p)^(t-i), where t and +p are the parameters of the distribution. OK, that tells us what t, p, and i +are. What's n? +

    +

    Proposed resolution:

    +

    +Berlin: Typo: "n" replaced by "t" in N1932: see 26.3.7.2.2/1. +

    + +

    [ +Portland: Subsumed by N2111. +]

    +
    +

    554. Problem with lwg DR 184 numeric_limits<bool>

    Section: 18.2.1.5 [lib.numeric.special]  Status: NAD  Submitter: Howard Hinnant  Date: 29 Jan 2006

    +

    +I believe we have a bug in the resolution of: +lwg 184 +(WP status). +

    + +

    +The resolution spells out each member of numeric_limits<bool>. +The part I'm having a little trouble with is: +

    +
    static const bool traps = false;
+
    + +

    +Should this not be implementation defined? Given: +

    + +
    int main()
+{
+     bool b1 = true;
+     bool b2 = false;
+     bool b3 = b1/b2;
+}
+
    + +

    +If this causes a trap, shouldn't numeric_limits<bool>::traps be +true? +

    +

    Proposed resolution:

    +

    +Change 18.2.1.5p3: +

    + +
    +-3- The specialization for bool shall be provided as follows: +
    namespace std { 
+   template <> class numeric_limits<bool> {
+      ...
+      static const bool traps = false implementation-defined;
+      ...
+   };
+}
+
    +
    + +

    [ +Redmond: NAD because traps refers to values, not operations. There is no bool +value that will trap. +]

    + +
    +

    555. TR1, 8.21/1: typo

    Section: TR1 8.21 [tr.c99.boolh]  Status: NAD  Submitter: Paolo Carlini  Date: 2 Feb 2006

    +

    +This one, if nobody noticed it yet, seems really editorial: +s/cstbool/cstdbool/ +

    +

    Proposed resolution:

    +

    +Change 8.21p1: +

    +
    +-1- The header behaves as if it defines the additional macro defined in +<cstdbool> by including the header <cstdbool>. +
    + +

    [ +Redmond: Editorial. +]

    + +
    +

    558. lib.input.iterators Defect

    Section: 24.1.1 [lib.input.iterators]  Status: NAD  Submitter: David Abrahams  Date: 9 Feb 2006

    +
    +

    + 24.1.1 Input iterators [lib.input.iterators] +

    +

    + 1 A class or a built-in type X satisfies the requirements of an + input iterator for the value type T if the following expressions are + valid, where U is the type of any specified member of type T, as + shown in Table 73. +

    +
    +

    +There is no capital U used in table 73. There is a lowercase u, but +that is clearly not meant to denote a member of type T. Also, there's +no description in 24.1.1 of what lowercase a means. IMO the above +should have been...Hah, a and b are already covered in 24.1/11, so maybe it +should have just been: +

    +

    Proposed resolution:

    +

    +Change 24.1.1p1: +

    +
    +-1- A class or a built-in type X satisfies the requirements of an +input iterator for the value type T if the following expressions +are valid, where U is the type of any specified member of type +T, as shown in Table 73. +
    + +

    [ +Portland: Editorial. +]

    + +
    +

    569. Postcondition for basic_ios::clear(iostate) incorrectly stated

    Section: 27.4.4.3 [lib.iostate.flags]  Status: Dup  Submitter: Seungbeom Kim  Date: 10 Mar 2006

    +

    +Section: 27.4.4.3 [lib.iostate.flags] +

    +

    +Paragraph 4 says: +

    +
    +
    void clear(iostate state = goodbit);
+
    +

    +Postcondition: If rdbuf()!=0 then state == rdstate(); +otherwise rdstate()==state|ios_base::badbit. +

    +
    + +

    +The postcondition "rdstate()==state|ios_base::badbit" is parsed as +"(rdstate()==state)|ios_base::badbit", which is probably what the +committee meant. +

    +

    Proposed resolution:

    +

    Rationale:

    +

    +This is a duplicate of issue 272. +

    +

    ----- End of document -----

    + \ No newline at end of file diff --git a/libstdc++-v3/docs/html/ext/lwg-defects.html b/libstdc++-v3/docs/html/ext/lwg-defects.html index ab3fe6bc622..94e4cb0a5d4 100644 --- a/libstdc++-v3/docs/html/ext/lwg-defects.html +++ b/libstdc++-v3/docs/html/ext/lwg-defects.html @@ -8,11 +8,11 @@ del {background-color:#FFFFA0} - + - + @@ -23,7 +23,7 @@ del {background-color:#FFFFA0}
    Doc. no.N2092=06-0162N2131=06-0201
    Date:2006-09-082006-11-03
    Project: Howard Hinnant <howard.hinnant@gmail.com>
    -

    C++ Standard Library Defect Report List (Revision R44)

    +

    C++ Standard Library Defect Report List (Revision R45)

    Reference ISO/IEC IS 14882:1998(E)

    Also see:

      @@ -45,6 +45,16 @@ del {background-color:#FFFFA0} document.

      Revision History

        +
      • R45: +2006-11-03 post-Portland mailing. +Moved issues 520, 521, 530, 535, 537, 538, 540, 541 to WP. +Moved issues 504, 512, 516, 544, 549, 554, 555, 558 to NAD. +Moved issue 569 to Dup. +Moved issues 518, 523, 524, 542, 556, 557, 559, 597, 606 to Open. +Moved issues 543, 545, 549, 549, 598 - 603, 605 to Ready. +Moved issues 531, 551, 604 to Review. +Added new issues 593-609. +
      • R44: 2006-09-08 pre-Portland mailing. Added new issues 583-592. @@ -53,14 +63,14 @@ Added new issues 575-582. Reopened 255. -Moved issues 520, 541, 544, 569 to Tentatively Ready. +Moved issues 520, 541, 544, 569 to Tentatively Ready.
      • R42: 2006-04-21 post-Berlin mailing. Added new issues 567-572. Moved issues 499, 501, 506, 509-511, 513, 514, 517 to NAD. -Moved issues 502, 503, 515, 516, 522, 525-529, 532, 536, 539, 548 to Open. -Moved issue 504, 512, 521, 530, 531, 535, 537, 538, 540, 549 to Ready. +Moved issues 502, 503, 515, 516, 522, 525-529, 532, 536, 539, 548 to Open. +Moved issue 504, 512, 521, 530, 531, 535, 537, 538, 540, 549 to Ready. Moved issues 247, 294, 362, 369, 371, 376, 384, 475, 478, 495, 497, 505, 507, 508, 519 to WP. Moved issue 534 to Review.
        • @@ -72,21 +82,21 @@ Reopened 529-535. +Added new issues 529-535.
      • R39: 2005-10-14 post-Mont Tremblant mailing. Added new issues 526-528. Moved issues 280, 461, 464, 465, 467, 468, 474, 496 from Ready to WP as per the vote from Mont Tremblant. Moved issues 247, 294, 342, 362, 369, 371, 376, 384, 475, 478, 495, 497 from Review to Ready. -Moved issues 498, 504, 506, 509, 510, 511, 512, 513, 514 from New to Open. +Moved issues 498, 504, 506, 509, 510, 511, 512, 513, 514 from New to Open. Moved issues 505, 507, 508, 519 from New to Ready. Moved issue 500 from New to NAD. Moved issue 518 from New to Review.
      • R38: 2005-07-03 pre-Mont Tremblant mailing. -Merged open TR1 issues in 504-522. +Merged open TR1 issues in 504-522. Added new issues 523-523
      • R37: @@ -876,7 +886,7 @@ Change the entry for noconv in the table under paragraph 4 in section unchanged, and there are no changes to the values in [to, to_limit).

        -

        20. Thousands_sep returns wrong type

        Section: 22.2.3.1.2 [lib.facet.numpunct.virtuals]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        20. Thousands_sep returns wrong type

        Section: 22.2.3.1.2 [lib.facet.numpunct.virtuals]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998

        The synopsis for numpunct<>::do_thousands_sep, and the definition of numpunct<>::thousands_sep which calls it, specify that it returns a value of type char_type. Here it is erroneously @@ -1665,7 +1675,7 @@ base class, exception, with exception(msg). Class exception (see

        EFFECTS: Constructs an object of class failure.

        -

        49. Underspecification of ios_base::sync_with_stdio

        Section: 27.4.2.4 [lib.ios.members.static]  Status: WP  Submitter: Matt Austern  Date: 21 Jun 1998

        +

        49. Underspecification of ios_base::sync_with_stdio

        Section: 27.4.2.4 [lib.ios.members.static]  Status: WP  Submitter: Matt Austern  Date: 21 Jun 1998

        Two problems

        (1) 27.4.2.4 doesn't say what ios_base::sync_with_stdio(f) @@ -3990,7 +4000,7 @@ This requirement is a bit weird. There's no similar requirement for basic_streambuf<>::seekpos, or for basic_filebuf<>::seekoff or basic_filebuf<>::seekpos.]

        -

        137. Do use_facet and has_facet look in the global locale?

        Section: 22.1.1 [lib.locale]  Status: TC  Submitter: Angelika Langer  Date: 17 Mar 1999

        +

        137. Do use_facet and has_facet look in the global locale?

        Section: 22.1.1 [lib.locale]  Status: TC  Submitter: Angelika Langer  Date: 17 Mar 1999

        Section 22.1.1 [lib.locale] says:

        -4- In the call to use_facet<Facet>(loc), the type argument @@ -4060,7 +4070,7 @@ proposed resolution.]


        — xpos <= pos and xpos < size();

        -

        142. lexicographical_compare complexity wrong

        Section: 25.3.8 [lib.alg.lex.comparison]  Status: TC  Submitter: Howard Hinnant  Date: 20 Jun 1999

        +

        142. lexicographical_compare complexity wrong

        Section: 25.3.8 [lib.alg.lex.comparison]  Status: TC  Submitter: Howard Hinnant  Date: 20 Jun 1999

        The lexicographical_compare complexity is specified as:

             "At most min((last1 - first1), (last2 - first2)) @@ -4198,7 +4208,7 @@ follows an "all-or-none" rule.

        For inserters, the LWG believes there is no defect; the standard is correct as written.

        -

        147. Library Intro refers to global functions that aren't global

        Section: 17.4.4.3 [lib.global.functions]  Status: TC  Submitter: Lois Goldthwaite  Date: 4 Jun 1999

        +

        147. Library Intro refers to global functions that aren't global

        Section: 17.4.4.3 [lib.global.functions]  Status: TC  Submitter: Lois Goldthwaite  Date: 4 Jun 1999

        The library had many global functions until 17.4.1.1 [lib.contents] paragraph 2 was added:

        @@ -4716,8 +4726,8 @@ paragraph 14 from:

        [Kona: Dietmar is working on a proposed resolution.]

        [Post-Tokyo: Dietmar supplied the above wording.]

        -

        172. Inconsistent types for basic_istream::ignore() -

        Section: 27.6.1.3 [lib.istream.unformatted]  Status: TC  Submitter: Greg Comeau, Dietmar Kühl  Date: 23 Jul 1999

        +

        172. Inconsistent types for basic_istream::ignore() +

        Section: 27.6.1.3 [lib.istream.unformatted]  Status: TC  Submitter: Greg Comeau, Dietmar Kühl  Date: 23 Jul 1999

        In 27.6.1.1 [lib.istream] the function ignore() gets an object of type streamsize as first argument. However, in 27.6.1.3 [lib.istream.unformatted] @@ -5249,7 +5259,7 @@ error. The full text was supplied by Bill Plauger; it was cross checked against changes supplied by Andy Sawyer. It should be further checked by the LWG.]

        -

        184. numeric_limits<bool> wording problems

        Section: 18.2.1.5 [lib.numeric.special]  Status: WP  Submitter: Gabriel Dos Reis  Date: 21 Jul 1999

        +

        184. numeric_limits<bool> wording problems

        Section: 18.2.1.5 [lib.numeric.special]  Status: WP  Submitter: Gabriel Dos Reis  Date: 21 Jul 1999

        bools are defined by the standard to be of integer types, as per 3.9.1 [basic.fundamental] paragraph 7. However "integer types" seems to have a special meaning for the author of 18.2. The net effect @@ -7804,7 +7814,7 @@ Change the following sentence in 21.3 paragraph 5 from or rend().

        -

        264. Associative container insert(i, j) complexity requirements are not feasible.

        Section: 23.1.2 [lib.associative.reqmts]  Status: WP  Submitter: John Potter  Date: 07 Sep 2000

        +

        264. Associative container insert(i, j) complexity requirements are not feasible.

        Section: 23.1.2 [lib.associative.reqmts]  Status: WP  Submitter: John Potter  Date: 07 Sep 2000

        Table 69 requires linear time if [i, j) is sorted. Sorted is necessary but not sufficient. Consider inserting a sorted range of even integers into a set<int> containing the odd @@ -8321,7 +8331,7 @@ the arguments it was given. ios_base::iostate& err, float& val) const;

        -

        276. Assignable requirement for container value type overly strict

        Section: 23.1 [lib.container.requirements]  Status: WP  Submitter: Peter Dimov  Date: 07 Nov 2000

        +

        276. Assignable requirement for container value type overly strict

        Section: 23.1 [lib.container.requirements]  Status: WP  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, @@ -10983,7 +10993,7 @@ declares struct tm as an incomplete type. However, table 48 in 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: WP  Submitter: Jeremy Siek  Date: 20 Oct 2001

        +

        346. Some iterator member functions should be const

        Section: 24.1 [lib.iterator.requirements]  Status: WP  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 @@ -11719,7 +11729,7 @@ with the following signature:

        Rationale:

        Fixes an obvious typo.

        -

        371. Stability of multiset and multimap member functions

        Section: 23.1 [lib.container.requirements]  Status: WP  Submitter: Frank Compagner  Date: 20 Jul 2002

        +

        371. Stability of multiset and multimap member functions

        Section: 23.1 [lib.container.requirements]  Status: WP  Submitter: Frank Compagner  Date: 20 Jul 2002

        The requirements for multiset and multimap containers (23.1 [lib.containers.requirements], 23.1.2 [lib.associative.reqmnts], @@ -12386,7 +12396,7 @@ In 21.3.5.8

        404. May a replacement allocation function be declared inline?

        Section: 17.4.3.4 [lib.replacement.functions], 18.5.1 [lib.new.delete]  Status: WP  Submitter: Matt Austern  Date: 24 Apr 2003

        +

        404. May a replacement allocation function be declared inline?

        Section: 17.4.3.4 [lib.replacement.functions], 18.5.1 [lib.new.delete]  Status: WP  Submitter: Matt Austern  Date: 24 Apr 2003

        The eight basic dynamic memory allocation functions (single-object and array versions of ::operator new and ::operator delete, in the @@ -13910,7 +13920,7 @@ to a field that is a static data member or a function member is undefined."

        -

        453. basic_stringbuf::seekoff need not always fail for an empty stream

        Section: 27.7.1.3 [lib.stringbuf.virtuals]  Status: DR  Submitter: Bill Plauger  Date: 30 Jan 2004

        +

        453. basic_stringbuf::seekoff need not always fail for an empty stream

        Section: 27.7.1.3 [lib.stringbuf.virtuals]  Status: DR  Submitter: Bill Plauger  Date: 30 Jan 2004

          pos_type basic_stringbuf::seekoff(off_type, ios_base::seekdir,
                                     ios_base::openmode);
        @@ -14736,6 +14746,125 @@ In the case where N == 0, begin() == end(). The return value of data() is unspecified.
        +

        520. Result_of and pointers to data members

        Section: TR1 3.6 [tr.func.bind]  Status: WP  Submitter: Pete Becker  Date: 3 Jul 2005

        +

        +In the original proposal for binders, the return type of bind() when +called with a pointer to member data as it's callable object was +defined to be mem_fn(ptr); when Peter Dimov and I unified the +descriptions of the TR1 function objects we hoisted the descriptions +of return types into the INVOKE pseudo-function and into result_of. +Unfortunately, we left pointer to member data out of result_of, so +bind doesn't have any specified behavior when called with a pointer +to member data. +

        +

        Proposed resolution:

        +

        [ +Pete and Peter will provide wording. +]

        + +

        +In 20.5.4 [lib.func.ret] ([tr.func.ret]) p3 add the following bullet after bullet 2: +

        +
          +
        1. If F is a member data pointer type R T::*, type +shall be cv R& when T1 is cv U1&, +R otherwise.
          2. +
        + +

        [ +Peter provided wording. +]

        +
        +

        521. Garbled requirements for argument_type in reference_wrapper

        Section: TR1 2.1.2 [tr.util.refwrp.refwrp]  Status: WP  Submitter: Pete Becker  Date: 3 Jul 2005

        +

        +2.1.2/3, second bullet item currently says that reference_wrapper<T> is +derived from unary_function<T, R> if T is: +

        +
        +a pointer to member function type with cv-qualifier cv and no arguments; +the type T1 is cv T* and R is the return type of the pointer to member function; +
        +

        +The type of T1 can't be cv T*, 'cause that's a pointer to a pointer to member +function. It should be a pointer to the class that T is a pointer to member of. +Like this: +

        +
        +a pointer to a member function R T0::f() cv (where cv represents the member +function's cv-qualifiers); the type T1 is cv T0* +
        +

        +Similarly, bullet item 2 in 2.1.2/4 should be: +

        +
        +a pointer to a member function R T0::f(T2) cv (where cv represents the member +function's cv-qualifiers); the type T1 is cv T0* +
        +

        Proposed resolution:

        + +

        +Change bullet item 2 in 2.1.2/3: +

        + +
        +
          +
        • +a pointer to member function type with cv-qualifier cv and no arguments; +the type T1 is cv T* and R is the return +type of the pointer to member function R T0::f() cv +(where cv represents the member function's cv-qualifiers); +the type T1 is cv T0* +
          • +
        +
        + +

        +Change bullet item 2 in 2.1.2/4: +

        + +
        +
          +
        • +a pointer to member function with cv-qualifier cv and taking one argument +of type T2; the type T1 is cv T* and +R is the return type of the pointer to member function +R T0::f(T2) cv (where cv represents the member +function's cv-qualifiers); the type T1 is cv T0* +
          • +
        +
        + +
        +

        530. Must elements of a string be contiguous?

        Section: 21.3 [lib.basic.string]  Status: WP  Submitter: Matt Austern  Date: 15 Nov 2005

        +

        Issue 69, which was incorporated into C++03, mandated +   that the elements of a vector must be stored in contiguous memory. +   Should the same also apply to basic_string?

        + +

        We almost require contiguity already. Clause 23.3.4 [lib.multiset] +  defines operator[] as data()[pos]. What's missing +  is a similar guarantee if we access the string's elements via the +  iterator interface.

        + +

        Given the existence of data(), and the definition of +  operator[] and at in terms of data, +  I don't believe it's possible to write a useful and standard- +  conforming basic_string that isn't contiguous. I'm not +  aware of any non-contiguous implementation. We should just require +  it. +

        +

        Proposed resolution:

        +

        Add the following text to the end of 21.3 [lib.basic.string], +paragraph 2.

        + +
        + 

        The characters in a string are stored contiguously, meaning that if +  s is a basic_string<charT, Allocator>, then +  it obeys the identity +  &*(s.begin() + n) == &*s.begin() + n +  for all 0 <= n < s.size(). +

        +
        +

        533. typo in 2.2.3.10/1

        Section: TR1 2.2.3.10 [tr.util.smartptr.getdeleter]  Status: DR  Submitter: Paolo Carlini  Date: 9 Nov 2005

        I'm seeing something that looks like a typo. The Return of get_deleter @@ -14754,5 +14883,242 @@ Therefore, I think should be:

        If *this p owns a deleter d...
        +
        +

        535. std::string::swap specification poorly worded

        Section: 21.3.5.8 [lib.string::swap]  Status: WP  Submitter: Beman Dawes  Date: 14 Dec 2005

        +

        +std::string::swap currently says for effects and postcondition: +

        + +
        +

        +Effects: Swaps the contents of the two strings. +

        + +

        +Postcondition: *this contains the characters that were in s, +s contains the characters that were in *this. +

        +
        + +

        +Specifying both Effects and Postcondition seems redundant, and the postcondition +needs to be made stronger. Users would be unhappy if the characters were not in +the same order after the swap. +

        +

        Proposed resolution:

        +
        +

        +Effects: Swaps the contents of the two strings. +

        + +

        +Postcondition: *this contains the same sequence of +characters that were was in s, +s contains the same sequence of characters that +were was in *this. +

        +
        +
        +

        537. Typos in the signatures in 27.6.1.3/42-43 and 27.6.2.4

        Section: 27.6.1.3 [lib.istream.unformatted]  Status: WP  Submitter: Paolo Carlini  Date: 12 Feb 2006

        +

        +In the most recent working draft, I'm still seeing: +

        + +
        seekg(off_type& off, ios_base::seekdir dir)
+
        + +

        +and +

        + +
        seekp(pos_type& pos)
+
+seekp(off_type& off, ios_base::seekdir dir)
+
        + +

        +that is, by reference off and pos arguments. +

        +

        Proposed resolution:

        +

        +After 27.6.1.3p42 change: +

        + +
        basic_istream<charT,traits>& seekg(off_type& off, ios_base::seekdir dir);
+
        + +

        +After 27.6.2.4p1 change: +

        + +
        basic_ostream<charT,traits>& seekp(pos_type& pos);
+
        + +

        +After 27.6.2.4p3 change: +

        + +
        basic_ostream<charT,traits>& seekp(off_type& off, ios_base::seekdir dir);
+
        +
        +

        538. 241 again: Does unique_copy() require CopyConstructible and Assignable?

        Section: 25.2.8 [lib.alg.unique]  Status: WP  Submitter: Howard Hinnant  Date: 9 Feb 2006

        +

        +I believe I botched the resolution of + +241 "Does unique_copy() require CopyConstructible and Assignable?" which now +has WP status. +

        + +

        +This talks about unique_copy requirements and currently reads: +

        + +
        +-5- Requires: The ranges [first, last) and +[result, result+(last-first)) +shall not overlap. The expression *result = *first shall +be valid. If neither InputIterator nor OutputIterator meets the +requirements of forward iterator then the value type of InputIterator +must be CopyConstructible (20.1.3). Otherwise CopyConstructible is not required. +
        + +

        +The problem (which Paolo discovered) is that when the iterators are at their +most restrictive (InputIterator, OutputIterator), then we want +InputIterator::value_type to be both CopyConstructible and +CopyAssignable (for the most efficient implementation). However this +proposed resolution only makes it clear that it is CopyConstructible, +and that one can assign from *first to *result. +This latter requirement does not necessarily imply that you can: +

        + +
        *first = *first;
+
        +

        Proposed resolution:

        +
        +-5- Requires: The ranges [first, last) and +[result, result+(last-first)) +shall not overlap. The expression *result = *first +shall +be valid. If neither InputIterator nor OutputIterator meets the +requirements of forward iterator then the value type +value_type of InputIterator +must be CopyConstructible (20.1.3) and Assignable. +Otherwise CopyConstructible is not required. +
        +
        +

        540. shared_ptr<void>::operator*()

        Section: TR1 2.2.3.5 [tr.util.smartptr.shared.obs]  Status: WP  Submitter: Martin Sebor  Date: 15 Oct 2005

        +

        +I'm trying to reconcile the note in tr.util.smartptr.shared.obs, p6 +that talks about the operator*() member function of shared_ptr: +

        + +
        + Notes: When T is void, attempting to instantiate this member function + renders the program ill-formed. [Note: Instantiating shared_ptr<void> + does not necessarily result in instantiating this member function. + --end note] +
        + +

        +with the requirement in temp.inst, p1: +

        + +
        + The implicit instantiation of a class template specialization causes + the implicit instantiation of the declarations, but not of the + definitions... +
        + +

        +I assume that what the note is really trying to say is that +"instantiating shared_ptr<void> *must not* result in instantiating +this member function." That is, that this function must not be +declared a member of shared_ptr<void>. Is my interpretation +correct? +

        +

        Proposed resolution:

        +

        +Change 2.2.3.5p6 +

        + +
        +-6- Notes: When T is void, attempting to instantiate +this member function renders the program ill-formed. [Note: +Instantiating shared_ptr<void> does not necessarily result in +instantiating this member function. --end note] it is +unspecified whether this member function is declared or not, and if so, what its +return type is, except that the declaration (although not necessarily the +definition) of the function shall be well-formed. +
        + +
        +

        541. shared_ptr template assignment and void

        Section: TR1 2.2.3 [tr.util.smartptr.shared]  Status: WP  Submitter: Martin Sebor  Date: 16 Oct 2005

        +

        +Is the void specialization of the template assignment operator taking +a shared_ptr<void> as an argument supposed be well-formed? +

        +

        +I.e., is this snippet well-formed: +

        +
        shared_ptr<void> p;
+p.operator=<void>(p);
+
        + +

        +Gcc complains about auto_ptr<void>::operator*() returning a reference +to void. I suspect it's because shared_ptr has two template assignment +operators, one of which takes auto_ptr, and the auto_ptr template gets +implicitly instantiated in the process of overload resolution. +

        + +

        +The only way I see around it is to do the same trick with auto_ptr<void> +operator*() as with the same operator in shared_ptr<void>. +

        + +

        +PS Strangely enough, the EDG front end doesn't mind the code, even +though in a small test case (below) I can reproduce the error with +it as well. +

        + +
        template <class T>
+struct A { T& operator*() { return *(T*)0; } };
+
+template <class T>
+struct B {
+    void operator= (const B&) { }
+    template <class U>
+    void operator= (const B<U>&) { }
+    template <class U>
+    void operator= (const A<U>&) { }
+};
+
+int main ()
+{
+    B<void> b;
+    b.operator=<void>(b);
+}
+
        +

        Proposed resolution:

        +

        +In [lib.memory] change: +

        +
        template<class X> class auto_ptr;
+template<> class auto_ptr<void>;
+
        + +

        +In [lib.auto.ptr]/2 add the following before the last closing brace: +

        + +
        template<> class auto_ptr<void>
+{
+public:
+    typedef void element_type;
+};
+
        +

        ----- End of document -----

        \ No newline at end of file