From bb8a23ac3387977602c2632ad6f2b383a4c8f0c4 Mon Sep 17 00:00:00 2001 From: Paolo Carlini Date: Wed, 28 Dec 2005 14:08:07 +0000 Subject: [PATCH] lwg-active.html, [...]: Import Revision 40. 2005-12-28 Paolo Carlini * docs/html/ext/lwg-active.html, lwg-defects.html: Import Revision 40. From-SVN: r109108 --- libstdc++-v3/ChangeLog | 4 + libstdc++-v3/docs/html/ext/lwg-active.html | 330 +++++++++++++++++++- libstdc++-v3/docs/html/ext/lwg-defects.html | 57 ++-- 3 files changed, 352 insertions(+), 39 deletions(-) diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog index 7b5e58c31a3..ef546e60d77 100644 --- a/libstdc++-v3/ChangeLog +++ b/libstdc++-v3/ChangeLog @@ -1,3 +1,7 @@ +2005-12-28 Paolo Carlini + + * docs/html/ext/lwg-active.html, lwg-defects.html: Import Revision 40. + 2005-12-28 Chris Jefferson * testsuite/testsuite_allocator.h (check_deallocate_null): Return true. diff --git a/libstdc++-v3/docs/html/ext/lwg-active.html b/libstdc++-v3/docs/html/ext/lwg-active.html index f5b7662ed72..fc705efb442 100644 --- a/libstdc++-v3/docs/html/ext/lwg-active.html +++ b/libstdc++-v3/docs/html/ext/lwg-active.html @@ -1,15 +1,18 @@ -C++ Standard Library Active Issues List +C++ Standard Library Active Issues List + + - + - + @@ -20,7 +23,7 @@
Doc. no.N1908=05-0168N1926=05-0186
Date:2005-10-232005-12-16
Project:Howard Hinnant <howard.hinnant@gmail.com>
-

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

+

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

Reference ISO/IEC IS 14882:1998(E)

Also see:

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

    Revision History

      +
    • 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. @@ -901,7 +908,7 @@ intended here is that the copy constructors can't fail.

      258. Missing allocator requirement

      Section: 20.1.5 [lib.allocator.requirements]  Status: Open  Submitter: Matt Austern  Date: 22 Aug 2000

      ->From lib-7752: +From lib-7752:

      @@ -2408,7 +2415,7 @@ object throws. might reasonably swallow the exception, or call abort, or do something even more drastic.]

      -

      419. istream extractors not setting failbit if eofbit is already set

      Section: 27.6.1.1.2 [lib.istream::sentry]  Status: Open  Submitter: Martin Sebor  Date: 18 Sep 2003

      +

      419. istream extractors not setting failbit if eofbit is already set

      Section: 27.6.1.1.2 [lib.istream::sentry]  Status: Open  Submitter: Martin Sebor  Date: 18 Sep 2003

      27.6.1.1.2, p2 says that istream::sentry ctor prepares for input if is.good() @@ -2726,7 +2733,7 @@ ostream::write(). negative. Martin will do that review.]

      -

      424. normative notes

      Section: 17.3.1.1 [lib.structure.summary]  Status: Open  Submitter: Martin Sebor  Date: 18 Sep 2003

      +

      424. normative notes

      Section: 17.3.1.1 [lib.structure.summary]  Status: Open  Submitter: Martin Sebor  Date: 18 Sep 2003

      The text in 17.3.1.1, p1 says: @@ -2838,7 +2845,7 @@ object (e.g., slice (2, 1, 1) for a valarray of size 1). performance, so we don't want to require specific checking. We need wording to express this decision.]

      -

      431. Swapping containers with unequal allocators

      Section: 20.1.5 [lib.allocator.requirements], 25 [lib.algorithms]  Status: Open  Submitter: Matt Austern  Date: 20 Sep 2003

      +

      431. Swapping containers with unequal allocators

      Section: 20.1.5 [lib.allocator.requirements], 25 [lib.algorithms]  Status: Open  Submitter: Matt Austern  Date: 20 Sep 2003

      Clause 20.1.5 [lib.allocator.requirements] paragraph 4 says that implementations are permitted to supply containers that are unable to cope with allocator instances and that container implementations may assume @@ -3101,7 +3108,7 @@ operational semantics for this column to:

      -

      459. Requirement for widening in stage 2 is overspecification

      Section: 22.2.2.1.2 [lib.facet.num.get.virtuals]  Status: Open  Submitter: Martin Sebor  Date: 16 Mar 2004

      +

      459. Requirement for widening in stage 2 is overspecification

      Section: 22.2.2.1.2 [lib.facet.num.get.virtuals]  Status: Open  Submitter: Martin Sebor  Date: 16 Mar 2004

      When parsing strings of wide-character digits, the standard requires the library to widen narrow-character "atoms" and compare the widened atoms against the characters that are being parsed. @@ -3812,7 +3819,7 @@ list<double> > should not take O(1).

      provide wording.]

      -

      484. Convertible to T

      Section: 24.1.1 [lib.input.iterators]  Status: Open  Submitter: Chris  Date: 16 Sep 2004

      +

      484. Convertible to T

      Section: 24.1.1 [lib.input.iterators]  Status: Open  Submitter: Chris Jefferson  Date: 16 Sep 2004

      From comp.std.c++:

      @@ -3856,7 +3863,7 @@ class I expect?

      overloads. It's a minor problem but a real one. So leave open for now, hope we solve it as part of iterator redesign.]

      -

      485. output iterator insufficently constrained

      Section: 24.1.2 [lib.output.iterators]  Status: Open  Submitter: Chris  Date: 13 Oct 2004

      +

      485. output iterator insufficently constrained

      Section: 24.1.2 [lib.output.iterators]  Status: Open  Submitter: Chris Jefferson  Date: 13 Oct 2004

      The note on 24.1.2 Output iterators insufficently limits what can be performed on output iterators. While it requires that each iterator is @@ -4826,7 +4833,7 @@ in each case as having some real type. 

      typedef  RealType  input_type;
      -

      512. Seeding subtract_with_carry_01 from a single unsigned long

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

      +

      512. Seeding subtract_with_carry_01 from a single unsigned long

      Section: TR1 5.1.4.4 [tr.rand.eng.sub1]  Status: New  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 @@ -5117,7 +5124,7 @@ function's cv-qualifiers); the type T1 is cv T0*

      Proposed resolution:

      -

      522. Tuple doesn't define swap

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

      +

      522. Tuple doesn't define swap

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

      Tuple doesn't define swap(). It should.

      @@ -5301,7 +5308,7 @@ seem to be lacking a definition.

      Proposed resolution:

      -

      526. Is it undefined if a function in the standard changes in parameters?

      Section: 23.1.1 [lib.sequence.reqmts]  Status: New  Submitter: Chris Jefferson  Date: 14 Sep 2005

      +

      526. Is it undefined if a function in the standard changes in parameters?

      Section: 23.1.1 [lib.sequence.reqmts]  Status: New  Submitter: Chris Jefferson  Date: 14 Sep 2005

      Problem: There are a number of places in the C++ standard library where it is possible to write what appear to be sensible ways of calling @@ -5463,5 +5470,300 @@ same type, those signatures that become otherwise indistinguishable collapse into a single signature.

      +
      +

      529. The standard encourages redundant and confusing preconditions

      Section: 17.4.3.8 [lib.res.on.required]  Status: New  Submitter: David Abrahams  Date: 25 Oct 2005

      +

      +17.4.3.8/1 says: +

      + +
      +Violation of the preconditions specified in a function's +Required behavior: paragraph results in undefined behavior unless the +function's Throws: paragraph specifies throwing an exception when the +precondition is violated. +
      + +

      +This implies that a precondition violation can lead to defined +behavior. That conflicts with the only reasonable definition of +precondition: that a violation leads to undefined behavior. Any other +definition muddies the waters when it comes to analyzing program +correctness, because precondition violations may be routinely done in +correct code (e.g. you can use std::vector::at with the full +expectation that you'll get an exception when your index is out of +range, catch the exception, and continue). Not only is it a bad +example to set, but it encourages needless complication and redundancy +in the standard. For example: +

      + +
        21 Strings library 
+  21.3.3 basic_string capacity
+
+  void resize(size_type n, charT c);
+
+  5 Requires: n <= max_size()
+  6 Throws: length_error if n > max_size().
+  7 Effects: Alters the length of the string designated by *this as follows:
+
      + +

      +The Requires clause is entirely redundant and can be dropped. We +could make that simplifying change (and many others like it) even +without changing 17.4.3.8/1; the wording there just seems to encourage +the redundant and error-prone Requires: clause. +

      + +

      Proposed resolution:

      +

      +1. Change 17.4.3.8/1 to read: +

      + +
      +Violation of the preconditions specified in a function's +Required behavior: paragraph results in undefined behavior +unless the function's Throws: paragraph specifies throwing +an exception when the precondition is violated. +
      + +

      +2. Go through and remove redundant Requires: clauses. Specifics to be + provided by Dave A. +

      +
      +

      530. Must elements of a string be contiguous?

      Section: 21.3 [lib.basic.string]  Status: New  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 23.3 [lib.associative], +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: New  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 +(istream::get() and istream::getline()) are supposed to +terminate when (n - 1) characters are stored, which obviously can +never be true when (n == 0) holds to start with. See +c++std-lib-16071. +

      +

      Proposed resolution:

      +

      +I suggest changing 27.6.1.3, p7 (istream::get()), bullet 1 to read: +

      +

      +

        +
      • + (n < 1) is true or (n - 1) characters + are stored; +
        • +
      +

      +

      + +and similarly p17 (istream::getline()), bullet 3 to: + +

      +

      +

        +
      • + (n < 1) is true or (n - 1) characters + are stored (in which case the function calls + setstate(failbit)). +
        • +
      +

      + +

      + +In addition, to clarify that istream::getline() must not store the +terminating NUL character unless the the array has non-zero size, Robert +Klarer suggests in c++std-lib-16082 to change 27.6.1.3, p20 to read: + +

      +

      +

      + +In any case, provided (n > 0) is true, it then stores a null character +(using charT()) into the next successive location of the array. + +
      +

      +
      +

      532. Tuple comparison

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

      +

      +Where possible, tuple comparison operators <,<=,=>, and > ought to be +defined in terms of std::less rather than operator<, in order to +support comparison of tuples of pointers. +

      +

      Proposed resolution:

      +

      +change 6.1.3.5/5 from: +

      + +
      + Returns: The result of a lexicographical comparison between t and + u. The result is defined as: (bool)(get<0>(t) < get<0>(u)) || + (!(bool)(get<0>(u) < get<0>(t)) && ttail < utail), where rtail for + some tuple r is a tuple containing all but the first element of + r. For any two zero-length tuples e and f, e < f returns false. +
      + +

      +to: +

      + +
      +

      + Returns: The result of a lexicographical comparison between t and + u. For any two zero-length tuples e and f, e < f returns false. + Otherwise, the result is defined as: cmp( get<0>(t), get<0>(u)) || + (!cmp(get<0>(u), get<0>(t)) && ttail < utail), where rtail for some + tuple r is a tuple containing all but the first element of r, and + cmp(x,y) is an unspecified function template defined as follows. +

      +

      + Where T is the type of x and U is the type of y: +

      + +

      + if T and U are pointer types and T is convertible to U, returns + less<U>()(x,y) +

      + +

      + otherwise, if T and U are pointer types, returns less<T>()(x,y) +

      + +

      + otherwise, returns (bool)(x < y) +

      +
      +
      +

      533. typo in 2.2.3.10/1

      Section: TR1 2.2.3.10 [tr.util.smartptr.getdeleter]  Status: New  Submitter: Paolo Carlini  Date: 9 Nov 2005

      +

      +I'm seeing something that looks like a typo. The Return of get_deleter +says: +

      +
      +If *this owns a deleter d... +
      +

      +but get_deleter is a free function! +

      +

      Proposed resolution:

      +

      +Therefore, I think should be: +

      +
      +If *this p owns a deleter d... +
      +
      +

      534. Missing basic_string members

      Section: 21.3 [lib.basic.string]  Status: New  Submitter: Alisdair Meredith  Date: 16 Nov 2005

      +

      +OK, we all know std::basic_string is bloated and already has way too +many members. However, I propose it is missing 3 useful members that +are often expected by users believing it is a close approximation of the +container concept. All 3 are listed in table 71 as 'optional' +

      + +

      +i/ pop_back. +

      + +

      +This is the one I feel most strongly about, as I only just discovered it +was missing as we are switching to a more conforming standard library +<g> +

      + +

      +I find it particularly inconsistent to support push_back, but not +pop_back. +

      + +

      +ii/ back. +

      + +

      +There are certainly cases where I want to examine the last character of +a string before deciding to append, or to trim trailing path separators +from directory names etc. *rbegin() somehow feels inelegant. +

      + +

      +iii/ front +

      + +

      +This one I don't feel strongly about, but if I can get the first two, +this one feels that it should be added as a 'me too' for consistency. +

      + +

      +I believe this would be similarly useful to the data() member recently +added to vector, or at() member added to the maps. +

      +

      Proposed resolution:

      +

      +

      +
      +

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

      Section: 21.3.5.8 [lib.string::swap]  Status: New  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. +

      +

      ----- 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 380c85e70e6..01c251dc462 100644 --- a/libstdc++-v3/docs/html/ext/lwg-defects.html +++ b/libstdc++-v3/docs/html/ext/lwg-defects.html @@ -1,15 +1,18 @@ -C++ Standard Library Defect Report List +C++ Standard Library Defect Report List + + - + - + @@ -20,7 +23,7 @@
      Doc. no.N1909=05-0169N1927=05-0187
      Date:2005-10-232005-12-16
      Project:Howard Hinnant <howard.hinnant@gmail.com>
      -

      C++ Standard Library Defect Report List (Revision R39)

      +

      C++ Standard Library Defect Report List (Revision R40)

      Reference ISO/IEC IS 14882:1998(E)

      Also see: