From db03587b6c2a9b2f3b8c5c9da7e40000f752c621 Mon Sep 17 00:00:00 2001 From: Paolo Carlini Date: Sun, 23 Apr 2006 11:44:40 +0000 Subject: [PATCH] lwg-active.html, [...]: Import Revision 42. 2006-04-23 Paolo Carlini * docs/html/ext/lwg-active.html, lwg-defects.html: Import Revision 42. From-SVN: r113193 --- libstdc++-v3/ChangeLog | 4 + libstdc++-v3/docs/html/ext/lwg-active.html | 1638 ++++++------------- libstdc++-v3/docs/html/ext/lwg-defects.html | 846 +++++++++- 3 files changed, 1296 insertions(+), 1192 deletions(-) diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog index 08e6c3be93e..a9ed643112c 100644 --- a/libstdc++-v3/ChangeLog +++ b/libstdc++-v3/ChangeLog @@ -1,3 +1,7 @@ +2006-04-23 Paolo Carlini + + * docs/html/ext/lwg-active.html, lwg-defects.html: Import Revision 42. + 2006-04-19 Paolo Carlini PR libstdc++/26424 diff --git a/libstdc++-v3/docs/html/ext/lwg-active.html b/libstdc++-v3/docs/html/ext/lwg-active.html index bd2346fc836..3e279f4d93d 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.N1949=06-0019N2000=06-0070
Date:2006-02-242006-04-21
Project: Howard Hinnant <howard.hinnant@gmail.com>
-

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

+

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

Reference ISO/IEC IS 14882:1998(E)

Also see:

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

    Revision History

      +
    • 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. @@ -105,9 +114,9 @@ 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 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.
      • @@ -142,7 +151,7 @@ new issues 463-478. +new issues 463-478.
    • R30: Post-Sydney mailing: reflects decisions made at the Sydney meeting. @@ -179,7 +188,7 @@ Pre-Santa Cruz mailing. Added new issues 362-366. +Post-Curaçao mailing. Added new issues 362-366.
    • R21: Pre-Curaçao mailing. Added new issues 351-361. @@ -377,6 +386,12 @@ format, Tentatively Ready - The issue has + been reviewed online, but not in a meeting, and some support has been formed + for the proposed resolution. Tentatively Ready issues may be moved to Ready + and forwarded to full committee within the same meeting. Unlike Ready issues + they will be reviewed in subcommittee prior to forwarding to full committee.

      +

      Ready - The LWG has reached consensus that the issue is a defect in the Standard, the Proposed Resolution is correct, and the issue is ready to forward to the @@ -706,69 +721,6 @@ suggests so the LWG can decide between the two options.]

      feedback from Lillehammer with more information regarding performance. ]

      -
      -

      247. vector, deque::insert complexity

      Section: 23.2.4.3 [lib.vector.modifiers]  Status: Ready  Submitter: Lisa Lippincott  Date: 06 June 2000

      -

      Paragraph 2 of 23.2.4.3 [lib.vector.modifiers] describes the complexity -of vector::insert:

      - -
      - Complexity: If first and last are forward iterators, bidirectional - iterators, or random access iterators, the complexity is linear in - the number of elements in the range [first, last) plus the distance - to the end of the vector. If they are input iterators, the complexity - is proportional to the number of elements in the range [first, last) - times the distance to the end of the vector. -
      - -

      First, this fails to address the non-iterator forms of -insert.

      - -

      Second, the complexity for input iterators misses an edge case -- -it requires that an arbitrary number of elements can be added at -the end of a vector in constant time.

      - -

      I looked to see if deque had a similar problem, and was -surprised to find that deque places no requirement on the -complexity of inserting multiple elements (23.2.1.3 [lib.deque.modifiers], -paragraph 3):

      - -
      - Complexity: In the worst case, inserting a single element into a - deque takes time linear in the minimum of the distance from the - insertion point to the beginning of the deque and the distance - from the insertion point to the end of the deque. Inserting a - single element either at the beginning or end of a deque always - takes constant time and causes a single call to the copy constructor - of T. -
      -

      Proposed resolution:

      - -

      Change Paragraph 2 of 23.2.4.3 [lib.vector.modifiers] to

      -
      - Complexity: The complexity is linear in the number of elements - inserted plus the distance to the end of the vector. -
      - -

      [For input iterators, one may achieve this complexity by first - inserting at the end of the vector, and then using - rotate.]

      - -

      Change 23.2.1.3 [lib.deque.modifiers], paragraph 3, to:

      - -
      - Complexity: The complexity is linear in the number of elements - inserted plus the shorter of the distances to the beginning and - end of the deque. Inserting a single element at either the - beginning or the end of a deque causes a single call to the copy - constructor of T. -
      - -

      Rationale:

      -

      This is a real defect, and proposed resolution fixes it: some - complexities aren't specified that should be. This proposed - resolution does constrain deque implementations (it rules out the - most naive possible implementations), but the LWG doesn't see a - reason to permit that implementation.

      254. Exception types in clause 19 are constructed from std::string

      Section: 19.1 [lib.std.exceptions]  Status: Open  Submitter: Dave Abrahams  Date: 01 Aug 2000

      @@ -981,7 +933,7 @@ the second line from the bottom in table 32 already implies the desired property. This issue should be considered in light of other issues related to allocator instances.]

      -

      290. Requirements to for_each and its function object

      Section: 25.1.1 [lib.alg.foreach]  Status: Open  Submitter: Angelika Langer  Date: 03 Jan 2001

      +

      290. Requirements to for_each and its function object

      Section: 25.1.1 [lib.alg.foreach]  Status: Open  Submitter: Angelika Langer  Date: 03 Jan 2001

      The specification of the for_each algorithm does not have a "Requires" section, which means that there are no restrictions imposed on the function object whatsoever. In essence it @@ -1013,54 +965,6 @@ algorithm does not say so. saying that user code operating on a range may not invalidate iterators unless otherwise specified. Bill will provide wording.]

      -
      -

      294. User defined macros and standard headers

      Section: 17.4.3.1.1 [lib.macro.names]  Status: Ready  Submitter: James Kanze  Date: 11 Jan 2001

      -

      Paragraph 2 of 17.4.3.1.1 [lib.macro.names] reads: "A -translation unit that includes a header shall not contain any macros -that define names declared in that header." As I read this, it -would mean that the following program is legal:

      - -
        #define npos 3.14
-  #include <sstream>
-
      - -

      since npos is not defined in <sstream>. It is, however, defined -in <string>, and it is hard to imagine an implementation in -which <sstream> didn't include <string>.

      - -

      I think that this phrase was probably formulated before it was -decided that a standard header may freely include other standard -headers. The phrase would be perfectly appropriate for C, for -example. In light of 17.4.4.1 [lib.res.on.headers] paragraph 1, however, -it isn't stringent enough.

      -

      Proposed resolution:

      -

      For 17.4.3.1.1 [lib.macro.names], replace the current wording, which reads:

      -
      -

      Each name defined as a macro in a header is reserved to the - implementation for any use if the translation unit includes - the header.168)

      - -

      A translation unit that includes a header shall not contain any - macros that define names declared or defined in that header. Nor shall - such a translation unit define macros for names lexically - identical to keywords.

      - -

      168) It is not permissible to remove a library macro definition by - using the #undef directive.

      -
      - -

      with the wording:

      - -
      -

      A translation unit that includes a standard library header shall not - #define or #undef names declared in any standard library header.

      - -

      A translation unit shall not #define or #undef names lexically - identical to keywords.

      -
      - -

      [Lillehammer: Beman provided new wording]

      -

      299. Incorrect return types for iterator dereference

      Section: 24.1.4 [lib.bidirectional.iterators], 24.1.5 [lib.random.access.iterators]  Status: Open  Submitter: John Potter  Date: 22 Jan 2001

      @@ -1165,7 +1069,7 @@ with a return type of convertible to T and operational semantics of iterator redesign]

      -

      309. Does sentry catch exceptions?

      Section: 27.6 [lib.iostream.format]  Status: Open  Submitter: Martin Sebor  Date: 19 Mar 2001

      +

      309. Does sentry catch exceptions?

      Section: 27.6 [lib.iostream.format]  Status: Open  Submitter: Martin Sebor  Date: 19 Mar 2001

      The descriptions of the constructors of basic_istream<>::sentry (27.6.1.1.2 [lib.istream::sentry]) and basic_ostream<>::sentry @@ -1507,262 +1411,6 @@ In case of failure, the function calls setstate(failbit) or badbit is set, so using !fail(), rather than good(), satisfies this goal.

      -

      362. bind1st/bind2nd type safety

      Section: 20.3.6.2 [lib.bind.1st]  Status: Ready  Submitter: Andrew Demkin  Date: 26 Apr 2002

      -

      -The definition of bind1st() (20.3.6.2 [lib.bind.1st]) can result in -the construction of an unsafe binding between incompatible pointer -types. For example, given a function whose first parameter type is -'pointer to T', it's possible without error to bind an argument of -type 'pointer to U' when U does not derive from T: -

      -
         foo(T*, int);
-
-   struct T {};
-   struct U {};
-
-   U u;
-
-   int* p;
-   int* q;
-
-   for_each(p, q, bind1st(ptr_fun(foo), &u));    // unsafe binding
-
      - -

      -The definition of bind1st() includes a functional-style conversion to -map its argument to the expected argument type of the bound function -(see below): -

      -
        typename Operation::first_argument_type(x)
-
      - -

      -A functional-style conversion (5.2.3 [expr.type.conv]) is defined to be -semantically equivalent to an explicit cast expression (5.4 [expr.cast]), which may (according to 5.4, paragraph 5) be interpreted -as a reinterpret_cast, thus masking the error. -

      - -

      The problem and proposed change also apply to 20.3.6.4 [lib.bind.2nd].

      -

      Proposed resolution:

      -

      Add this sentence to the end of 20.3.6 [lib.binders]/1: - "Binders bind1st and bind2nd are deprecated in - favor of std::tr1::bind."

      - -

      (Notes to editor: (1) when and if tr1::bind is incorporated into - the standard, "std::tr1::bind" should be changed to "std::bind". (2) - 20.3.6 should probably be moved to Annex D.

      -

      Rationale:

      -

      There is no point in fixing bind1st and bind2nd. tr1::bind is a - superior solution. It solves this problem and others.

      -
      -

      369. io stream objects and static ctors

      Section: 27.3 [lib.iostream.objects]  Status: Ready  Submitter: Ruslan Abdikeev  Date: 8 Jul 2002

      -

      -Is it safe to use standard iostream objects from constructors of -static objects? Are standard iostream objects constructed and are -their associations established at that time? -

      - -

      Surpisingly enough, Standard does NOT require that.

      - -

      -27.3/2 [lib.iostream.objects] guarantees that standard iostream -objects are constructed and their associations are established before -the body of main() begins execution. It also refers to ios_base::Init -class as the panacea for constructors of static objects. -

      - -

      -However, there's nothing in 27.3 [lib.iostream.objects], -in 27.4.2 [lib.ios.base], and in 27.4.2.1.6 [lib.ios::Init], -that would require implementations to allow access to standard -iostream objects from constructors of static objects. -

      - -

      Details:

      - -

      Core text refers to some magic object ios_base::Init, which will -be discussed below:

      - -
      - "The [standard iostream] objects are constructed, and their - associations are established at some time prior to or during - first time an object of class basic_ios<charT,traits>::Init - is constructed, and in any case before the body of main - begins execution." (27.3/2 [lib.iostream.objects]) -
      - -

      -The first non-normative footnote encourages implementations -to initialize standard iostream objects earlier than required. -

      - -

      However, the second non-normative footnote makes an explicit -and unsupported claim:

      - -
      - "Constructors and destructors for static objects can access these - [standard iostream] objects to read input from stdin or write output - to stdout or stderr." (27.3/2 footnote 265 [lib.iostream.objects]) -
      - -

      -The only bit of magic is related to that ios_base::Init class. AFAIK, -the rationale behind ios_base::Init was to bring an instance of this -class to each translation unit which #included <iostream> or -related header. Such an inclusion would support the claim of footnote -quoted above, because in order to use some standard iostream object it -is necessary to #include <iostream>. -

      - -

      -However, while Standard explicitly describes ios_base::Init as -an appropriate class for doing the trick, I failed to found a -mention of an _instance_ of ios_base::Init in Standard. -

      -

      Proposed resolution:

      - -

      Add to 27.3 [lib.iostream.objects], p2, immediately before the last sentence -of the paragraph, the following two sentences:

      - -
      -If a translation unit includes <iostream>, or explicitly -constructs an ios_base::Init object, these stream objects shall -be constructed before dynamic initialization of non-local -objects defined later in that translation unit, and these stream -objects shall be destroyed after the destruction of dynamically -initialized non-local objects defined later in that translation unit. -
      - -

      [Lillehammer: Matt provided wording.]

      -

      [Mont Tremblant: Matt provided revised wording.]

      -

      Rationale:

      -

      -The original proposed resolution unconditionally required -implementations to define an ios_base::Init object of some -implementation-defined name in the header <iostream>. That's an -overspecification. First, defining the object may be unnecessary -and even detrimental to performance if an implementation can -guarantee that the 8 standard iostream objects will be initialized -before any other user-defined object in a program. Second, there -is no need to require implementations to document the name of the -object.

      - -

      -The new proposed resolution gives users guidance on what they need to -do to ensure that stream objects are constructed during startup.

      -
      -

      371. Stability of multiset and multimap member functions

      Section: 23.1 [lib.container.requirements]  Status: Ready  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], -23.3.2 [lib.multimap] and 23.3.4 [lib.multiset]) make no mention of -the stability of the required (mutating) member functions. It appears -the standard allows these functions to reorder equivalent elements of -the container at will, yet the pervasive red-black tree implementation -appears to provide stable behaviour. -

      - -

      This is of most concern when considering the behaviour of erase(). -A stability requirement would guarantee the correct working of the -following 'idiom' that removes elements based on a certain predicate -function. -

      - -
        multimap<int, int> m;
-  multimap<int, int>::iterator i = m.begin();
-  while (i != m.end()) {
-      if (pred(i))
-          m.erase (i++);
-      else
-          ++i;
-  }
-
      - -

      -Although clause 23.1.2/8 guarantees that i remains a valid iterator -througout this loop, absence of the stability requirement could -potentially result in elements being skipped. This would make -this code incorrect, and, furthermore, means that there is no way -of erasing these elements without iterating first over the entire -container, and second over the elements to be erased. This would -be unfortunate, and have a negative impact on both performance and -code simplicity. -

      - -

      -If the stability requirement is intended, it should be made explicit -(probably through an extra paragraph in clause 23.1.2). -

      -

      -If it turns out stability cannot be guaranteed, i'd argue that a -remark or footnote is called for (also somewhere in clause 23.1.2) to -warn against relying on stable behaviour (as demonstrated by the code -above). If most implementations will display stable behaviour, any -problems emerging on an implementation without stable behaviour will -be hard to track down by users. This would also make the need for an -erase_if() member function that much greater. -

      - -

      This issue is somewhat related to LWG issue 130.

      - -

      Proposed resolution:

      - -

      Add the following to the end of 23.1.2 [lib.associative.reqmts] paragraph 4: -"For multiset and multimap, insertand erase - are stable: they preserve the relative ordering of equivalent - elements.

      - -

      [Lillehammer: Matt provided wording]

      -

      [Joe Gottman points out that the provided wording does not address -multimap and multiset. N1780 also addresses this issue and suggests -wording.]

      - -

      [Mont Tremblant: Changed set and map to multiset and multimap.]

      - -

      Rationale:

      -

      The LWG agrees that this guarantee is necessary for common user - idioms to work, and that all existing implementations provide this - property. Note that this resolution guarantees stability for - multimap and multiset, not for all associative containers in - general.

      - -
      -

      376. basic_streambuf semantics

      Section: 27.7.1.3 [lib.stringbuf.virtuals]  Status: Ready  Submitter: Ray Lischner  Date: 14 Aug 2002

      -

      -In Section 27.7.1.3 [lib.stringbuf.virtuals], Table 90, the implication is that -the four conditions should be mutually exclusive, but they are not. -The first two cases, as written, are subcases of the third.

      - -

      -As written, it is unclear what should be the result if cases 1 and 2 -are both true, but case 3 is false. -

      - -

      Proposed resolution:

      - -

      Rewrite these conditions as:

      -
      -

      - (which & (ios_base::in|ios_base::out)) == ios_base::in -

      - -

      - (which & (ios_base::in|ios_base::out)) == ios_base::out -

      - -

      - (which & (ios_base::in|ios_base::out)) == -(ios_base::in|ios_base::out) - and way == either ios_base::beg or ios_base::end -

      - -

      Otherwise

      -
      - -

      Rationale:

      -

      It's clear what we wanted to say, we just failed to say it. This - fixes it.

      -

      382. codecvt do_in/out result

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

      It seems that the descriptions of codecvt do_in() and do_out() leave @@ -1874,64 +1522,6 @@ partial can only occur if (from_next != from_end)? seem sufficient for C++0x. Bill supports general N-to-M conversions; we need to make sure Martin and Howard agree.]

      -
      -

      384. equal_range has unimplementable runtime complexity

      Section: 25.3.3.3 [lib.equal.range]  Status: Ready  Submitter: Hans Bos  Date: 18 Oct 2002

      -

      -Section 25.3.3.3 [lib.equal.range] -states that at most 2 * log(last - first) + 1 -comparisons are allowed for equal_range. -

      - -

      It is not possible to implement equal_range with these constraints.

      - -

      In a range of one element as in:

      -
          int x = 1;
-    equal_range(&x, &x + 1, 1)
-
      - -

      it is easy to see that at least 2 comparison operations are needed.

      - -

      For this case at most 2 * log(1) + 1 = 1 comparison is allowed.

      - -

      I have checked a few libraries and they all use the same (nonconforming) -algorithm for equal_range that has a complexity of

      -
           2* log(distance(first, last)) + 2.
-
      -

      I guess this is the algorithm that the standard assumes for equal_range.

      - -

      -It is easy to see that 2 * log(distance) + 2 comparisons are enough -since equal range can be implemented with lower_bound and upper_bound -(both log(distance) + 1). -

      - -

      -I think it is better to require something like 2log(distance) + O(1) (or -even logarithmic as multiset::equal_range). -Then an implementation has more room to optimize for certain cases (e.g. -have log(distance) characteristics when at most match is found in the range -but 2log(distance) + 4 for the worst case). -

      - -

      Proposed resolution:

      -

      In 25.3.3.1 [lib.lower.bound]/4, change log(last - first) + 1 -to log2(last - first) + O(1).

      - -

      In 25.3.3.2 [lib.upper.bound]/4, change log(last - first) + 1 -to log2(last - first) + O(1).

      - -

      In 25.3.3.3 [lib.equal.range]/4, change 2*log(last - first) + 1 -to 2*log2(last - first) + O(1).

      - -

      [Matt provided wording]

      -

      Rationale:

      -

      The LWG considered just saying O(log n) for all three, but -Ê decided that threw away too much valuable information.Ê The fact -Ê that lower_bound is twice as fast as equal_range is important. -Ê However, it's better to allow an arbitrary additive constant than to -Ê specify an exact count.Ê An exact count would have to -Ê involve floor or ceil.Ê It would be too easy to -Ê get this wrong, and don't provide any substantial value for users.

      385. Does call by value imply the CopyConstructible requirement?

      Section: 17 [lib.library]  Status: Open  Submitter: Matt Austern  Date: 23 Oct 2002

      @@ -2257,7 +1847,7 @@ is zero. Otherwise, the element has the value 1.

      fixed the analogous problem with the extractor in issue 303.

      -

      397. ostream::sentry dtor throws exceptions

      Section: 27.6.2.3 [lib.ostream::sentry]  Status: Open  Submitter: Martin Sebor  Date: 5 Jan 2003

      +

      397. ostream::sentry dtor throws exceptions

      Section: 27.6.2.3 [lib.ostream::sentry]  Status: Open  Submitter: Martin Sebor  Date: 5 Jan 2003

      17.4.4.8, p3 prohibits library dtors from throwing exceptions.

      @@ -2971,7 +2561,7 @@ library class templates. We need to consult with CWG to make sure we use the right wording.]

      -

      423. effects of negative streamsize in iostreams

      Section: 27 [lib.input.output]  Status: Open  Submitter: Martin Sebor  Date: 18 Sep 2003

      +

      423. effects of negative streamsize in iostreams

      Section: 27 [lib.input.output]  Status: Open  Submitter: Martin Sebor  Date: 18 Sep 2003

      A third party test suite tries to exercise istream::ignore(N) with @@ -3916,131 +3506,6 @@ facet's virtuals may never call each other. We might want to do that in clause 27 too, for that matter. A review is necessary. Bill will provide wording.

      -

      475. May the function object passed to for_each modify the elements of the iterated sequence?

      Section: 25.1.1 [lib.alg.foreach]  Status: Ready  Submitter: Stephan T. Lavavej, Jaakko Jarvi  Date: 9 Jul 2004

      -

      -It is not clear whether the function object passed to for_each is allowed to -modify the elements of the sequence being iterated over. -

      - -

      -for_each is classified without explanation in [lib.alg.nonmodifying], "25.1 -Non-modifying sequence operations". 'Non-modifying sequence operation' is -never defined. -

      - -

      -25(5) says: "If an algorithm's Effects section says that a value pointed to -by any iterator passed as an argument is modified, then that algorithm has -an additional type requirement: The type of that argument shall satisfy the -requirements of a mutable iterator (24.1)." -

      - -

      for_each's Effects section does not mention whether arguments can be -modified:

      - -
      - "Effects: Applies f to the result of dereferencing every iterator in the - range [first, last), starting from first and proceeding to last - 1." -
      - -

      -Every other algorithm in [lib.alg.nonmodifying] is "really" non-modifying in -the sense that neither the algorithms themselves nor the function objects -passed to the algorithms may modify the sequences or elements in any way. -This DR affects only for_each. -

      - -

      -We suspect that for_each's classification in "non-modifying sequence -operations" means that the algorithm itself does not inherently modify the -sequence or the elements in the sequence, but that the function object -passed to it may modify the elements it operates on. -

      - -

      -The original STL document by Stepanov and Lee explicitly prohibited the -function object from modifying its argument. -The "obvious" implementation of for_each found in several standard library -implementations, however, does not impose this restriction. -As a result, we suspect that the use of for_each with function objects that modify -their arguments is wide-spread. -If the restriction was reinstated, all such code would become non-conforming. -Further, none of the other algorithms in the Standard -could serve the purpose of for_each (transform does not guarantee the order in -which its function object is called). -

      - -

      -We suggest that the standard be clarified to explicitly allow the function object -passed to for_each modify its argument.

      - -

      Proposed resolution:

      -

      Add a nonnormative note to the Effects in 25.1.1 [lib.alg.foreach]: If -the type of 'first' satisfies the requirements of a mutable iterator, -'f' may apply nonconstant functions through the dereferenced iterators -passed to it. -

      - -

      Rationale:

      -

      The LWG believes that nothing in the standard prohibits function - objects that modify the sequence elements. The problem is that - for_each is in a secion entitled "nonmutating algorithms", and the - title may be confusing. A nonnormative note should clarify that.

      -
      -

      478. Should forward iterator requirements table have a line for r->m?

      Section: 24.1.3 [lib.forward.iterators]  Status: Ready  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 second line may be unnecessary. 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. -
      - -

      -Because operators can be overloaded on an iterator's const-ness, the -current requirements allow iterators to make many of the operations -specified using the identifiers a and b invalid for non-const -iterators.

      - -

      Related issue: 477

      -

      Proposed resolution:

      - -

      Remove the "r->m" line from the Forward Iterator requirements -table. Change

      -
      - "const X" -
      - -

      to

      - -
      - "X or const X" -
      - -

      in paragraph 11 of [lib.iterator.requirements].

      - - -

      Rationale:

      -

      -This is a defect because it constrains an lvalue to returning a modifiable lvalue. -

      -

      479. Container requirements and placement new

      Section: 23.1 [lib.container.requirements]  Status: Open  Submitter: Herb Sutter  Date: 1 Aug 2004

      Nothing in the standard appears to make this program ill-formed:

      @@ -4410,118 +3875,6 @@ about this in 25/11. But (a) it should be in 17, not 25; and (b) it's not quite broad enough, because there are some arithmetic expressions it doesn't cover. Bill will provide wording.]

      -
      -

      495. Clause 22 template parameter requirements

      Section: 22 [lib.localization]  Status: Ready  Submitter: Beman Dawes  Date: 10 Jan 2005

      -

      It appears that there are no requirements specified for many of the -template parameters in clause 22. It looks like this issue has never -come up, except perhaps for Facet.

      - -

      Clause 22 isn't even listed in 17.3.2.1 [lib.type.descriptions], -either, which is the wording that allows requirements on template -parameters to be identified by name.

      - -

      So one issue is that 17.3.2.1 [lib.type.descriptions] Should be -changed to cover clause 22. A better change, which will cover us in -the future, would be to say that it applies to all the library -clauses. Then if a template gets added to any library clause we are -covered.

      - -

      charT, InputIterator, and other names with requirements defined -elsewhere are fine, assuming the 17.3.2.1 [lib.type.descriptions] fix. -But there are a few template arguments names which I don't think have -requirements given elsewhere:

      - -
        -
      • internT and externT. The fix is to add wording saying that internT -and externT must meet the same requirements as template arguments -named charT.
        • - -
      • stateT. I'm not sure about this one. There already is some wording, -but it seems a bit vague.
        • - -
      • Intl. [lib.locale.moneypunct.byname] The fix for this one is to -rename "Intl" to "International". The name is important because other -text identifies the requirements for the name International but not -for Intl.
        • -
      -

      Proposed resolution:

      -

      Change 17.3.2.1 [lib.type.descriptions], paragraph 1, from:

      -
      -The Requirements subclauses may describe names that are used to -specify constraints on template arguments.153) These names are used in -clauses 20, 23, 25, and 26 to describe the types that may be supplied -as arguments by a C++ program when instantiating template components -from the library. -
      -

      to:

      -
      -The Requirements subclauses may describe names that are used to -specify constraints on template arguments.153) These names are used in -library clauses to describe the types that may be supplied as -arguments by a C++ program when instantiating template components from -the library. -
      - -

      In the front matter of class 22, locales, add:

      -
      -Template parameter types internT and externT shall meet the -requirements of charT (described in 21 [lib.strings]). -
      -

      Rationale:

      -

      - Again, a blanket clause isn't blanket enough. Also, we've got a - couple of names that we don't have blanket requirement statements - for. The only issue is what to do about stateT. This wording is - thin, but probably adequate.

      -
      -

      497. meaning of numeric_limits::traps for floating point types

      Section: 18.2.1.2 [lib.numeric.limits.members]  Status: Ready  Submitter: Martin Sebor  Date: 2 Mar 2005

      - -

      18.2.1.2, p59 says this much about the traps member of numeric_limits:

      - -
      -

      static const bool traps;
      --59- true if trapping is implemented for the type.204) -
      -Footnote 204: Required by LIA-1. -

      -
      - -

      It's not clear what is meant by "is implemented" here.

      - -

      -In the context of floating point numbers it seems reasonable to expect -to be able to use traps to determine whether a program can "safely" use -infinity(), quiet_NaN(), etc., in arithmetic expressions, that is -without causing a trap (i.e., on UNIX without having to worry about -getting a signal). When traps is true, I would expect any of the -operations in section 7 of IEEE 754 to cause a trap (and my program -to get a SIGFPE). So, for example, on Alpha, I would expect traps -to be true by default (unless I compiled my program with the -ieee -option), false by default on most other popular architectures, -including IA64, MIPS, PA-RISC, PPC, SPARC, and x86 which require -traps to be explicitly enabled by the program. -

      - -

      -Another possible interpretation of p59 is that traps should be true -on any implementation that supports traps regardless of whether they -are enabled by default or not. I don't think such an interpretation -makes the traps member very useful, even though that is how traps is -implemented on several platforms. It is also the only way to implement -traps on platforms that allow programs to enable and disable trapping -at runtime. -

      -

      Proposed resolution:

      -

      Change p59 to read:

      -
      True if, at program startup, there exists a value of the type that - would cause an arithmetic operation using that value to trap.
      -

      Rationale:

      -

      - Real issue, since trapping can be turned on and off. Unclear what a - static query can say about a dynamic issue. The real advice we should - give users is to use cfenv for these sorts of queries. But this new - proposed resolution is at least consistent and slightly better than - nothing.

      498. Requirements for partition() and stable_partition() too strong

      Section: 25.2.12 [lib.alg.partitions]  Status: Open  Submitter: Sean Parent, Joe Gottman  Date: 4 May 2005

      @@ -4579,143 +3932,39 @@ by next meeting. Sean provided further rationale by post-meeting mailing.]

      -

      499. Std. doesn't seem to require stable_sort() to be stable!

      Section: 25.3.1.2 [lib.stable.sort]  Status: New  Submitter: Prateek Karandikar  Date: 12 Apr 2005

      -
      +

      502. Proposition: Clarification of the interaction between a facet and an iterator

      Section: 22.1.1.1.1 [lib.locale.category]  Status: Open  Submitter: Christopher Conrade Zseleghovski  Date: 7 Jun 2005

      -17.3.1.1 Summary

      +Motivation: +

      -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. +This requirement seems obvious to me, it is the essence of code modularity. +I have complained to Mr. Plauger that the Dinkumware library does not +observe this principle but he objected that this behaviour is not covered in +the standard.

      +

      Proposed resolution:

      -2 Paragraphs labelled "Note(s):" or "Example(s):" are informative, -other paragraphs are normative. +Append the following point to 22.1.1.1.1:

      -
      -

      So this means that a "Notes" paragraph wouldn't be normative.

      - -

      -25.3.1.2 stable_sort +6. The implementation of a facet of Table 52 parametrized with an +InputIterator/OutputIterator should use that iterator only as character +source/sink respectively. +For a *_get facet, it means that the value received depends only on the +sequence of input characters and not on how they are accessed. +For a *_put facet, it means that the sequence of characters output depends +only on the value to be formatted and not of how the characters are stored.

      -
      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:

      -

      -

      -
      -

      501. Proposal: strengthen guarantees of lib.comparisons

      Section: 20.3.3 [lib.comparisons]  Status: New  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.3.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.3.3/1 saying that if -A and B are similar types (4.4/4), comp<A>(a,b) returns the same value -as comp<B>(a,b) (where comp is less, less_equal, etc.). But this might -be problematic if there is some really funky operator overloading going -on that does different things based on cv (that should be undefined -behavior if somebody does that though). This at least should be -guaranteed for all POD types (especially pointers) that use the -built-in comparison operators. -

      - -
      -

      502. Proposition: Clarification of the interaction between a facet and an iterator

      Section: 22.1.1.1.1 [lib.locale.category]  Status: New  Submitter: Christopher Conrade Zseleghovski  Date: 7 Jun 2005

      -

      -Motivation: -

      - -

      -This requirement seems obvious to me, it is the essence of code modularity. -I have complained to Mr. Plauger that the Dinkumware library does not -observe this principle but he objected that this behaviour is not covered in -the standard. -

      -

      Proposed resolution:

      -

      -Append the following point to 22.1.1.1.1: -

      - -

      -6. The implementation of a facet of Table 52 parametrized with an -InputIterator/OutputIterator should use that iterator only as character -source/sink respectively. -For a *_get facet, it means that the value received depends only on the -sequence of input characters and not on how they are accessed. -For a *_put facet, it means that the sequence of characters output depends -only on the value to be formatted and not of how the characters are stored. -

      +

      [ +Berlin: Moved to Open, Need to clean up this area to make it clear +locales don't have to contain open ended sets of facets. Jack, Howard, +Bill. +]

      -

      503. more on locales

      Section: 22.2 [lib.locale.categories]  Status: New  Submitter: P.J. Plauger  Date: 20 Jun 2005

      +

      503. more on locales

      Section: 22.2 [lib.locale.categories]  Status: Open  Submitter: P.J. Plauger  Date: 20 Jun 2005

      a) In 22.2.1.1 para. 2 we refer to "the instantiations required in Table 51" to refer to the facet *objects* associated with a locale. And we @@ -4810,8 +4059,11 @@ facet, but several also need to use a codecvt facet and we don't say so.

      Proposed resolution:

      +

      [ +Berlin: Bill to provide wording. +]

      -

      504. Integer types in pseudo-random number engine requirements

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

      +

      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 ..." @@ -4842,6 +4094,11 @@ 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 @@ -4854,254 +4111,7 @@ signature. u.seed(s) is covered by its reference to X(s), same arguments.

      -

      505. Result_type in random distribution requirements

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

      -

      -Table 17: Random distribution requirements -

      -

      -Row 1 requires that each random distribution provide a nested type "input_type"; -this type denotes the type of the values that the distribution consumes. -

      -

      -Inspection of all distributions in [tr.rand.dist] reveals that each distribution -provides a second typedef ("result_type") that denotes the type of the values the -distribution produces when called. -

      -

      Proposed resolution:

      -

      -It seems to me that this is also a requirement -for all distributions and should therefore be indicated as such via a new second -row to this table 17: -

      - - - - - - - -
      X::result_typeT---compile-time
      -
      -

      506. Requirements of Distribution parameter for variate_generator

      Section: TR1 5.1.3 [tr.rand.var]  Status: Open  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. -]

      - -
      -

      507. Missing requirement for variate_generator::operator()

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

      -

      -Paragraph 11 of [tr.rand.var] equires that the member template -

      -
      template<class T> result_type operator() (T value);
-
      -

      -return -

      -
      distribution()(e, value)
-
      -

      -However, not all distributions have an operator() with a corresponding signature. -

      -

      Proposed resolution:

      -

      -We therefore recommend that we insert the following precondition before paragraph 11: -

      -
      -Precondition: distribution().operator()(e,value) is well-formed. -
      -
      -

      508. Bad parameters for ranlux64_base_01

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

      -

      -The fifth of these engines with predefined parameters, ranlux64_base_01, -appears to have an unintentional error for which there is a simple correction. -The two pre-defined subtract_with_carry_01 engines are given as: -

      -
      typedef subtract_with_carry_01<float,  24, 10, 24> ranlux_base_01;
-typedef subtract_with_carry_01<double, 48, 10, 24> ranlux64_base_01;
-
      -

      -We demonstrate below that ranlux64_base_01 fails to meet the intent of the -random number generation proposal, but that the simple correction to -

      -
      typedef subtract_with_carry_01<double, 48,  5, 12> ranlux64_base_01;
-
      -

      -does meet the intent of defining well-known good parameterizations. -

      -

      -The ranlux64_base_01 engine as presented fails to meet the intent for -predefined engines, stated in proposal N1398 (section E): -

      -

      -In order to make good random numbers available to a large number of library -users, this proposal not only defines generic random-number engines, but also -provides a number of predefined well-known good parameterizations for those. -

      -

      -The predefined ranlux_base_01 engine has been proven [1,2,3] to have a very -long period and so meets this criterion. This property makes it suitable for -use in the excellent discard_block engines defined subsequently. The proof -of long period relies on the fact (proven in [1]) that 2**(w*r) - 2**(w*s) -+ 1 is prime (w, r, and s are template parameters to subtract_with_carry_01, -as defined in [tr.rand.eng.sub1]). -

      -

      -The ranlux64_base_01 engine as presented in [tr.rand.predef] uses w=48, r=24, s=10. -For these numbers, the combination 2**(w*r)-2**(w*s)+1 is non-prime (though -explicit factorization would be a challenge). In consequence, while it is -certainly possible for some seeding states that this engine would have a very -long period, it is not at all Òwell-knownÓ that this is the case. The intent -in the N1398 proposal involved the base of the ranlux64 engine, which finds heavy -use in the physics community. This is isomorphic to the predefined ranlux_base_01, -but exploits the ability of double variables to hold (at least) 48 bits of mantissa, -to deliver 48 random bits at a time rather than 24. -

      -

      Proposed resolution:

      -

      -To achieve this intended behavior, the correct template parameteriztion would be: -

      -
      typedef subtract_with_carry_01<double, 48, 5, 12> ranlux64_base_01;
-
      -

      -The sequence of mantissa bits delivered by this is isomorphic (treating each -double as having the bits of two floats) to that delivered by ranlux_base_01. -

      -

      -References: -

      -
        -
      1. F. James, Comput. Phys. Commun. 60(1990) 329
        2. -
      2. G. Marsaglia and A. Zaman, Ann. Appl. Prob 1(1991) 462
        3. -
      3. M. Luscher, Comput. Phys. Commun. 79(1994) 100-110
        4. -
      - -
      -

      509. Uniform_int template parameters

      Section: TR1 5.1.7.1 [tr.rand.dist.iunif]  Status: Open  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;
-
      -
      -

      510. Input_type for bernoulli_distribution

      Section: TR1 5.1.7.2 [tr.rand.dist.bern]  Status: Open  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;
-
      -
      -

      511. Input_type for binomial_distribution

      Section: TR1 5.1.7.5 [tr.rand.dist.bin]  Status: Open  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;
-
      -
      -

      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: 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 @@ -5156,6 +4166,12 @@ 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 @@ -5163,70 +4179,7 @@ prose would probably not qualify for the (with issue

      513. Size of state for subtract_with_carry_01

      Section: TR1 5.1.4.4 [tr.rand.eng.sub1]  Status: Open  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. -]

      -
      -

      514. Size of state for subtract_with_carry

      Section: TR1 5.1.4.3 [tr.rand.eng.sub]  Status: Open  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. -]

      - -
      -

      515. Random number engine traits

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

      +

      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, we propose and recommend an adjunct template, engine_traits, to be declared in @@ -5275,8 +4228,14 @@ complete specialization of this new engine_traits template.

      + +

      [ +Berlin: Walter: While useful for implementation per TR1, N1932 has no need for this +feature. +]

      +
      -

      516. Seeding subtract_with_carry_01 using a generator

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

      +

      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:

      @@ -5294,27 +4253,7 @@ as the context seems to require only 32-bit quantities be used here.

      Proposed resolution:

      - -

      -
      -

      517. Should include name in external representation

      Section: TR1 5.1.1 [tr.rand.req]  Status: New  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 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

      @@ -5327,28 +4266,6 @@ The same issue applies to unordered_multiset and unordered_multimap.

      -

      519. Data() undocumented

      Section: TR1 6.2.2 [tr.array.array]  Status: Ready  Submitter: Pete Becker  Date: 3 Jul 2005

      -

      -array<>::data() is present in the class synopsis, but not documented. -

      -

      Proposed resolution:

      -

      -Add a new section, after 6.2.2.3: -

      -
      T*       data()
-const T* data() const;
-
      -

      -Returns: elems. -

      -

      -Change 6.2.2.4/2 to: -

      -
      -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: New  Submitter: Pete Becker  Date: 3 Jul 2005

      In the original proposal for binders, the return type of bind() when @@ -5365,7 +4282,7 @@ to member data. Pete and Peter will provide wording. ]

      -

      521. Garbled requirements for argument_type in reference_wrapper

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

      +

      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: @@ -5391,11 +4308,48 @@ 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: New  Submitter: Andy Koenig  Date: 3 Jul 2005

      +

      522. Tuple doesn't define swap

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

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

      +

      [ +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

      @@ -5568,15 +4522,19 @@ For what it's worth, John has also expressed his preference for option

      Proposed resolution:

      -

      525. type traits definitions not clear

      Section: TR1 4.5 [tr.meta.unary]  Status: New  Submitter: Robert Klarer  Date: 11 Jul 2005

      +

      525. type traits definitions not clear

      Section: TR1 4.5 [tr.meta.unary]  Status: Open  Submitter: Robert Klarer  Date: 11 Jul 2005

      It is not completely clear how the primary type traits deal with cv-qualified types. And several of the secondary type traits seem to be lacking a definition.

      + +

      [ +Berlin: Howard to provide wording. +]

      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: Open  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 @@ -5684,11 +4642,18 @@ Matt Austern adds that this issue also exists for the insert and erase members of the ordered and unordered associative containers.

      +

      [ +Berlin: Lots of controversey over how this should be solved. Lots of confusion +as to whether we're talking about self referencing iterators or references. +Needs a good survey as to the cases where this matters, for which +implementations, and how expensive it is to fix each case. +]

      +

      Proposed resolution:

      -

      527. tr1::bind has lost its Throws clause

      Section: TR1 3.6.3 [tr.func.bind.bind]  Status: New  Submitter: Peter Dimov  Date: 01 Oct 2005

      +

      527. tr1::bind has lost its Throws clause

      Section: TR1 3.6.3 [tr.func.bind.bind]  Status: Open  Submitter: Peter Dimov  Date: 01 Oct 2005

      The original bind proposal gives the guarantee that tr1::bind(f, t1, ..., tN) does not throw when the copy constructors of f, t1, ..., tN @@ -5702,11 +4667,16 @@ This guarantee is not present in the final version of TR1.

      I'm pretty certain that we never removed it on purpose. Editorial omission? :-)

      + +

      [ +Berlin: not quite editorial, needs proposed wording. +]

      +

      Proposed resolution:

      -

      528. TR1: issue 6.19 vs 6.3.4.3/2 (and 6.3.4.5/2)

      Section: TR1 6.3.4 [tr.unord.unord]  Status: New  Submitter: Paolo Carlini  Date: 12 Oct 2005

      +

      528. TR1: issue 6.19 vs 6.3.4.3/2 (and 6.3.4.5/2)

      Section: TR1 6.3.4 [tr.unord.unord]  Status: Open  Submitter: Paolo Carlini  Date: 12 Oct 2005

      while implementing the resolution of issue 6.19 I'm noticing the following: according to 6.3.4.3/2 (and 6.3.4.5/2), for unordered_set and @@ -5738,13 +4708,32 @@ Add to 6.3.4.3p2 (and 6.3.4.5p2):

      2 ... The iterator and const_iterator types are both const constant iterator types. -It is unspecified whether they are the same type. If they are the -same type, those signatures that become otherwise indistinguishable -collapse into a single signature. +It is unspecified whether they are the same type. +

      + +

      +Add a new subsection to 17.4.4 [lib.conforming]: +

      + +
      +

      +An implementation shall not supply an overloaded function + signature specified in any library clause if such a signature + would be inherently ambiguous during overload resolution + due to two library types referring to the same type. +

      +

      + [Note: For example, this occurs when a container's iterator + and const_iterator types are the same. -- end note]

      +
      + +

      [ +Post-Berlin: Beman supplied wording. +]

      -

      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

      +

      529. The standard encourages redundant and confusing preconditions

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

      17.4.3.8/1 says:

      @@ -5802,8 +4791,13 @@ an exception when the precondition is violated. 2. Go through and remove redundant Requires: clauses. Specifics to be provided by Dave A.

      + +

      [ +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: New  Submitter: Matt Austern  Date: 15 Nov 2005

      +

      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?

      @@ -5821,7 +4815,7 @@ an exception when the precondition is violated.   it.

      Proposed resolution:

      -

      Add the following text to the end of 23.3 [lib.associative], +

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

      @@ -5833,7 +4827,7 @@ paragraph 2.

      -

      531. array forms of unformatted input functions

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

      +

      531. array forms of unformatted input functions

      Section: 27.6.1.3 [lib.istream.unformatted]  Status: Ready  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 @@ -5885,7 +4879,7 @@ In any case, provided (n > 0) is true, it then stores a null charact

      -

      532. Tuple comparison

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

      +

      532. Tuple comparison

      Section: TR1 6.1.3.5 [tr.tuple.rel]  Status: Open  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 @@ -5934,8 +4928,14 @@ to: otherwise, returns (bool)(x < y)

      + +

      [ +Berlin: This issue is much bigger than just tuple (pair, containers, +algorithms). Dietmar will survey and work up proposed wording. +]

      +
      -

      534. Missing basic_string members

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

      +

      534. Missing basic_string members

      Section: 21.3 [lib.basic.string]  Status: Review  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 @@ -5983,9 +4983,80 @@ added to vector, or at() member added to the maps.

      Proposed resolution:

      +Add the following members to definition of class template basic_string, 21.3p7 +

      +
      void pop_back ()
+
+const charT & front() const
+charT & front()
+
+const charT & back() const
+charT & back()
+
      +

      +Add the following paragraphs to basic_string description +

      + +

      +21.3.4p5 +

      +
      +
      const charT & front() const
+charT & front()
+
      +

      +Precondition: !empty() +

      +

      +Effects: Equivalent to operator[](0). +

      +
      + +

      +21.3.4p6 +

      +
      +
      const charT & back() const
+charT & back()
+
      +

      +Precondition: !empty() +

      +

      +Effects: Equivalent to operator[]( size() - 1). +

      +
      + +

      +21.3.5.5p10 +

      +
      +
      void pop_back ()
+
      +

      +Precondition: !empty() +

      +

      +Effects: Equivalent to erase( size() - 1, 1 ).

      +
      + +

      +Update Table 71: (optional sequence operations) +Add basic_string to the list of containers for the following operations. +

      +
      a.front()
+a.back()
+a.push_back()
+a.pop_back()
+a[n]
+
      + +

      [ +Berlin: Has support. Alisdair provided wording. +]

      -

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

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

      +

      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:

      @@ -6020,7 +5091,7 @@ characters that were was in s,

      -

      536. Container iterator constructor and explicit convertibility

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

      +

      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 23.2.2 does only require that i and j be input iterators but @@ -6073,8 +5144,11 @@ int main()

      Proposed resolution:

      +

      [ +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: New  Submitter: Paolo Carlini  Date: 12 Feb 2006

      +

      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:

      @@ -6116,7 +5190,7 @@ 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: New  Submitter: Howard Hinnant  Date: 9 Feb 2006

      +

      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 @@ -6154,15 +5228,15 @@ This latter requirement does not necessarily imply that you can: -5- Requires: The ranges [first, last) and [result, result+(last-first)) shall not overlap. The expression *result = *first -shall must +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 CopyAssignable. +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.numeric.ops]  Status: New  Submitter: Marc Schoolderman  Date: 6 Feb 2006

      +

      539. partial_sum and adjacent_difference should mention requirements

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

      There are some problems in the definition of partial_sum and adjacent_difference in 26.4 [lib.numeric.ops] @@ -6304,8 +5378,12 @@ The type of *first shall meet the requirements of

      Proposed resolution:

      +

      [ +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: New  Submitter: Martin Sebor  Date: 15 Oct 2005

      +

      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: @@ -6552,7 +5630,7 @@ want. Shouldn't we be performing a conversion to a floating-point type first?

      -

      548. May random_device block?

      Section: TR1 5.1.6 [tr.rand.device]  Status: New  Submitter: Matt Austern  Date: 10 Jan 2006

      +

      548. May random_device block?

      Section: TR1 5.1.6 [tr.rand.device]  Status: Open  Submitter: Matt Austern  Date: 10 Jan 2006

      Class random_device "produces non-deterministic random numbers", using some external source of entropy. In most real-world systems, the amount of available @@ -6565,11 +5643,17 @@ the entropy pool is empty, reads to /dev/random will block until additional environmental noise is gathered." Programmers need to know whether random_device is permitted to (or possibly even required to?) behave the same way.

      + +

      [ +Berlin: Walter: N1932 considers this NAD. Does the standard specify whether std::cin +may block? +]

      +

      Proposed resolution:

      -

      549. Undefined variable in binomial_distribution

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

      +

      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 @@ -6578,6 +5662,7 @@ 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.c.math]  Status: New  Submitter: Howard Hinnant  Date: 12 Jan 2006

      @@ -7449,5 +6534,194 @@ location of the array.

      +
      +

      567. streambuf inserter and extractor should be unformatted

      Section: 27.6 [lib.iostream.format]  Status: New  Submitter: Martin Sebor  Date: 25 Feb 2006

      +

      + +Issue 60 explicitly made the extractor and inserter operators that +take a basic_streambuf* argument formatted input and output +functions, respectively. I believe that's wrong, certainly in the +case of the extractor, since formatted functions begin by extracting +and discarding whitespace. The extractor should not discard any +characters. + +

      +

      Proposed resolution:

      +

      + +I propose to change each operator to behave as unformatted input and +output function, respectively. The changes below are relative to the +working draft document number N1804. + +

      +

      + +Specifically, change 27.6.1.2.3, p14 as follows: + +

      + +

      +

      + +Effects: Behaves as an unformatted input function +(as described in 27.6.1.2.127.6.1.3, paragraph +1). + +
      +

      +

      + +And change 27.6.2.5.3, p7 as follows: + +

      + +

      +

      + +Effects: Behaves as an unformatted output function +(as described in 27.6.2.5.127.6.2.6, paragraph +1). + +
      +

      +
      +

      568. log2 overloads missing

      Section: TR1 8.16.4 [tr.c99.cmath.over]  Status: New  Submitter: Paolo Carlini  Date: 7 Mar 2006

      +

      +log2 is missing from the list of "additional overloads" in 8.16.4p1. +

      +

      Proposed resolution:

      +

      +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: New  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:

      +

      +Change 27.4.4.3p4: +

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

      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 +char_traits<> and requires the implementation provide two explicit +specializations: char_traits<char> and char_traits<wchar_t>. I feel the Standard +should require explicit specializations for all built-in character types, i.e. +char, wchar_t, unsigned char, and signed char. +

      +

      +I have put together a paper (N1985) that describes this in more detail and +includes all the necessary wording. +

      +

      Proposed resolution:

      +

      +

      +
      +

      571. Update C90 references to C99?

      Section: 1.2 [intro.refs]  Status: New  Submitter: Beman Dawes  Date: 8 Apr 2006

      +

      +1.2 Normative references [intro.refs] of the WP currently refers to ISO/IEC +9899:1990, Programming languages - C. Should that be changed to ISO/IEC +9899:1999? +

      +

      +What impact does this have on the library? +

      +

      Proposed resolution:

      +

      +In 1.2/1 [intro.refs] of the WP, change: +

      +
      +
        +
      • ISO/IEC 9899:19901999 + TC1 + TC2, Programming languages - C +
        • +
      +
      + +
      +

      572. Oops, we gave 507 WP status

      Section: TR1 5.1.3 [tr.rand.var]  Status: New  Submitter: Howard Hinnant  Date: 11 Apr 2006

      +

      +In Berlin, as a working group, we voted in favor of N1932 which makes issue 507 moot: +variate_generator has been eliminated. Then in full committee we voted to give +this issue WP status (mistakenly). +

      +

      Proposed resolution:

      +

      +Strike the proposed resolution of issue 507. +

      +
      +

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

      Section: 27.4.3 [lib.fpos]  Status: New  Submitter: Your name  Date: 29 Feb 1900

      +

      +There are two deficiencies related to file sizes: +

      +
        +
      1. It doesn't appear that the Standard Library is specified in + a way that handles modern file sizes, which are often too + large to be represented by an unsigned long.
        2. + +
      2. The std::fpos class does not currently have the ability to + set/get file positions.
        3. +
      +

      +The Dinkumware implementation of the Standard Library as shipped with the Microsoft compiler copes with these issues by: +

      +
        +
      1. Defining fpos_t be long long, which is large enough to + represent any file position likely in the foreseeable future.
        2. + +
      2. Adding member functions to class fpos. For example, +
        fpos_t seekpos() const;
+
        +
        3. +
      +

      +Because there are so many types relating to file positions and offsets (fpos_t, +fpos, pos_type, off_type, streamoff, streamsize, streampos, wstreampos, and +perhaps more), it is difficult to know if the Dinkumware extensions are +sufficient. But they seem a useful starting place for discussions, and they do +represent existing practice. +

      + +

      Proposed resolution:

      +

      +

      +
      +

      574. DR 369 Contradicts Text

      Section: 27.3 [lib.iostream.objects]  Status: New  Submitter: Pete Becker  Date: 18 Apr 2006

      +

      +lib.iostream.objects requires that the standard stream objects are never +destroyed, and it requires that they be destroyed. +

      +

      +DR 369 adds words to say that we really mean for ios_base::Init objects to force +construction of standard stream objects. It ends, though, with the phrase "these +stream objects shall be destroyed after the destruction of dynamically ...". +However, the rule for destruction is stated in the standard: "The objects are +not destroyed during program execution." +

      +

      Proposed resolution:

      +

      +

      ----- 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 8d9138589c1..1907a4a8502 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.N1950=06-0020N2001=06-0071
      Date:2006-02-242006-04-21
      Project: Howard Hinnant <howard.hinnant@gmail.com>
      -

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

      +

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

      Reference ISO/IEC IS 14882:1998(E)

      Also see:

        @@ -45,6 +45,15 @@ del {background-color:#FFFFA0} document.

        Revision History

          +
        • 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. @@ -59,9 +68,9 @@ 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 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.
          • @@ -96,7 +105,7 @@ new issues 463-478. +new issues 463-478.
        • R30: Post-Sydney mailing: reflects decisions made at the Sydney meeting. @@ -133,7 +142,7 @@ Pre-Santa Cruz mailing. Added new issues 362-366. +Post-Curaçao mailing. Added new issues 362-366.
        • R21: Pre-Curaçao mailing. Added new issues 351-361. @@ -5367,7 +5376,7 @@ not required elsewhere.

          [Kona: The LWG agreed there was a defect.]

          [Tokyo: The LWG crafted the proposed resolution.]

          -

          186. bitset::set() second parameter should be bool

          Section: 23.3.5.2 [lib.bitset.members]  Status: WP  Submitter: Darin Adler  Date: 13 Aug 1999

          +

          186. bitset::set() second parameter should be bool

          Section: 23.3.5.2 [lib.bitset.members]  Status: WP  Submitter: Darin Adler  Date: 13 Aug 1999

          In section 23.3.5.2 [lib.bitset.members], paragraph 13 defines the bitset::set operation to take a second parameter of type int. The function tests whether this value is non-zero to determine whether to @@ -7267,6 +7276,69 @@ had language that made this an unambiguous requirement; those words were moved to a place where their context made them less clear. See Jerry Schwarz's message c++std-lib-7618.

          +

          247. vector, deque::insert complexity

          Section: 23.2.4.3 [lib.vector.modifiers]  Status: WP  Submitter: Lisa Lippincott  Date: 06 June 2000

          +

          Paragraph 2 of 23.2.4.3 [lib.vector.modifiers] describes the complexity +of vector::insert:

          + +
          + Complexity: If first and last are forward iterators, bidirectional + iterators, or random access iterators, the complexity is linear in + the number of elements in the range [first, last) plus the distance + to the end of the vector. If they are input iterators, the complexity + is proportional to the number of elements in the range [first, last) + times the distance to the end of the vector. +
          + +

          First, this fails to address the non-iterator forms of +insert.

          + +

          Second, the complexity for input iterators misses an edge case -- +it requires that an arbitrary number of elements can be added at +the end of a vector in constant time.

          + +

          I looked to see if deque had a similar problem, and was +surprised to find that deque places no requirement on the +complexity of inserting multiple elements (23.2.1.3 [lib.deque.modifiers], +paragraph 3):

          + +
          + Complexity: In the worst case, inserting a single element into a + deque takes time linear in the minimum of the distance from the + insertion point to the beginning of the deque and the distance + from the insertion point to the end of the deque. Inserting a + single element either at the beginning or end of a deque always + takes constant time and causes a single call to the copy constructor + of T. +
          +

          Proposed resolution:

          + +

          Change Paragraph 2 of 23.2.4.3 [lib.vector.modifiers] to

          +
          + Complexity: The complexity is linear in the number of elements + inserted plus the distance to the end of the vector. +
          + +

          [For input iterators, one may achieve this complexity by first + inserting at the end of the vector, and then using + rotate.]

          + +

          Change 23.2.1.3 [lib.deque.modifiers], paragraph 3, to:

          + +
          + Complexity: The complexity is linear in the number of elements + inserted plus the shorter of the distances to the beginning and + end of the deque. Inserting a single element at either the + beginning or the end of a deque causes a single call to the copy + constructor of T. +
          + +

          Rationale:

          +

          This is a real defect, and proposed resolution fixes it: some + complexities aren't specified that should be. This proposed + resolution does constrain deque implementations (it rules out the + most naive possible implementations), but the LWG doesn't see a + reason to permit that implementation.

          +

          248. time_get fails to set eofbit

          Section: 22.2.5 [lib.category.time]  Status: WP  Submitter: Martin Sebor  Date: 22 June 2000

          There is no requirement that any of time_get member functions set ios::eofbit when they reach the end iterator while parsing their input. @@ -8936,6 +9008,54 @@ the corresponding member objects of rhs, except that... assigns to the member objects of *this the corresponding member objects of rhs, except that... +

          +

          294. User defined macros and standard headers

          Section: 17.4.3.1.1 [lib.macro.names]  Status: WP  Submitter: James Kanze  Date: 11 Jan 2001

          +

          Paragraph 2 of 17.4.3.1.1 [lib.macro.names] reads: "A +translation unit that includes a header shall not contain any macros +that define names declared in that header." As I read this, it +would mean that the following program is legal:

          + +
            #define npos 3.14
+  #include <sstream>
+
          + +

          since npos is not defined in <sstream>. It is, however, defined +in <string>, and it is hard to imagine an implementation in +which <sstream> didn't include <string>.

          + +

          I think that this phrase was probably formulated before it was +decided that a standard header may freely include other standard +headers. The phrase would be perfectly appropriate for C, for +example. In light of 17.4.4.1 [lib.res.on.headers] paragraph 1, however, +it isn't stringent enough.

          +

          Proposed resolution:

          +

          For 17.4.3.1.1 [lib.macro.names], replace the current wording, which reads:

          +
          +

          Each name defined as a macro in a header is reserved to the + implementation for any use if the translation unit includes + the header.168)

          + +

          A translation unit that includes a header shall not contain any + macros that define names declared or defined in that header. Nor shall + such a translation unit define macros for names lexically + identical to keywords.

          + +

          168) It is not permissible to remove a library macro definition by + using the #undef directive.

          +
          + +

          with the wording:

          + +
          +

          A translation unit that includes a standard library header shall not + #define or #undef names declared in any standard library header.

          + +

          A translation unit shall not #define or #undef names lexically + identical to keywords.

          +
          + +

          [Lillehammer: Beman provided new wording]

          +

          295. Is abs defined in <cmath>?

          Section: 26.5 [lib.c.math]  Status: WP  Submitter: Jens Maurer  Date: 12 Jan 2001

          @@ -11330,6 +11450,54 @@ prevents locale from being implemented efficiently.

          This change is reasonable becuase it clarifies the intent of this part of the standard.

          +

          362. bind1st/bind2nd type safety

          Section: 20.3.6.2 [lib.bind.1st]  Status: WP  Submitter: Andrew Demkin  Date: 26 Apr 2002

          +

          +The definition of bind1st() (20.3.6.2 [lib.bind.1st]) can result in +the construction of an unsafe binding between incompatible pointer +types. For example, given a function whose first parameter type is +'pointer to T', it's possible without error to bind an argument of +type 'pointer to U' when U does not derive from T: +

          +
             foo(T*, int);
+
+   struct T {};
+   struct U {};
+
+   U u;
+
+   int* p;
+   int* q;
+
+   for_each(p, q, bind1st(ptr_fun(foo), &u));    // unsafe binding
+
          + +

          +The definition of bind1st() includes a functional-style conversion to +map its argument to the expected argument type of the bound function +(see below): +

          +
            typename Operation::first_argument_type(x)
+
          + +

          +A functional-style conversion (5.2.3 [expr.type.conv]) is defined to be +semantically equivalent to an explicit cast expression (5.4 [expr.cast]), which may (according to 5.4, paragraph 5) be interpreted +as a reinterpret_cast, thus masking the error. +

          + +

          The problem and proposed change also apply to 20.3.6.4 [lib.bind.2nd].

          +

          Proposed resolution:

          +

          Add this sentence to the end of 20.3.6 [lib.binders]/1: + "Binders bind1st and bind2nd are deprecated in + favor of std::tr1::bind."

          + +

          (Notes to editor: (1) when and if tr1::bind is incorporated into + the standard, "std::tr1::bind" should be changed to "std::bind". (2) + 20.3.6 should probably be moved to Annex D.

          +

          Rationale:

          +

          There is no point in fixing bind1st and bind2nd. tr1::bind is a + superior solution. It solves this problem and others.

          +

          363. Missing exception specification in 27.4.2.1.1

          Section: 27.4.2.1.1 [lib.ios::failure]  Status: WP  Submitter: Walter Brown and Marc Paterno  Date: 20 May 2002

          The destructor of ios_base::failure should have an empty throw @@ -11413,6 +11581,102 @@ state exposed by the public interface is unchanged.

          Note that implementers can make this change in a binary compatible way by providing both overloads; this would be a conforming extension.

          +
          +

          369. io stream objects and static ctors

          Section: 27.3 [lib.iostream.objects]  Status: WP  Submitter: Ruslan Abdikeev  Date: 8 Jul 2002

          +

          +Is it safe to use standard iostream objects from constructors of +static objects? Are standard iostream objects constructed and are +their associations established at that time? +

          + +

          Surpisingly enough, Standard does NOT require that.

          + +

          +27.3/2 [lib.iostream.objects] guarantees that standard iostream +objects are constructed and their associations are established before +the body of main() begins execution. It also refers to ios_base::Init +class as the panacea for constructors of static objects. +

          + +

          +However, there's nothing in 27.3 [lib.iostream.objects], +in 27.4.2 [lib.ios.base], and in 27.4.2.1.6 [lib.ios::Init], +that would require implementations to allow access to standard +iostream objects from constructors of static objects. +

          + +

          Details:

          + +

          Core text refers to some magic object ios_base::Init, which will +be discussed below:

          + +
          + "The [standard iostream] objects are constructed, and their + associations are established at some time prior to or during + first time an object of class basic_ios<charT,traits>::Init + is constructed, and in any case before the body of main + begins execution." (27.3/2 [lib.iostream.objects]) +
          + +

          +The first non-normative footnote encourages implementations +to initialize standard iostream objects earlier than required. +

          + +

          However, the second non-normative footnote makes an explicit +and unsupported claim:

          + +
          + "Constructors and destructors for static objects can access these + [standard iostream] objects to read input from stdin or write output + to stdout or stderr." (27.3/2 footnote 265 [lib.iostream.objects]) +
          + +

          +The only bit of magic is related to that ios_base::Init class. AFAIK, +the rationale behind ios_base::Init was to bring an instance of this +class to each translation unit which #included <iostream> or +related header. Such an inclusion would support the claim of footnote +quoted above, because in order to use some standard iostream object it +is necessary to #include <iostream>. +

          + +

          +However, while Standard explicitly describes ios_base::Init as +an appropriate class for doing the trick, I failed to found a +mention of an _instance_ of ios_base::Init in Standard. +

          +

          Proposed resolution:

          + +

          Add to 27.3 [lib.iostream.objects], p2, immediately before the last sentence +of the paragraph, the following two sentences:

          + +
          +If a translation unit includes <iostream>, or explicitly +constructs an ios_base::Init object, these stream objects shall +be constructed before dynamic initialization of non-local +objects defined later in that translation unit, and these stream +objects shall be destroyed after the destruction of dynamically +initialized non-local objects defined later in that translation unit. +
          + +

          [Lillehammer: Matt provided wording.]

          +

          [Mont Tremblant: Matt provided revised wording.]

          +

          Rationale:

          +

          +The original proposed resolution unconditionally required +implementations to define an ios_base::Init object of some +implementation-defined name in the header <iostream>. That's an +overspecification. First, defining the object may be unnecessary +and even detrimental to performance if an implementation can +guarantee that the 8 standard iostream objects will be initialized +before any other user-defined object in a program. Second, there +is no need to require implementations to document the name of the +object.

          + +

          +The new proposed resolution gives users guidance on what they need to +do to ensure that stream objects are constructed during startup.

          370. Minor error in basic_istream::get

          Section: 27.6.1.3 [lib.istream.unformatted]  Status: WP  Submitter: Ray Lischner  Date: 15 Jul 2002

          Defect report for description of basic_istream::get (section 27.6.1.3 [lib.istream.unformatted]), paragraph 15. The description for the get function @@ -11444,6 +11708,82 @@ 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

          +

          +The requirements for multiset and multimap containers (23.1 +[lib.containers.requirements], 23.1.2 [lib.associative.reqmnts], +23.3.2 [lib.multimap] and 23.3.4 [lib.multiset]) make no mention of +the stability of the required (mutating) member functions. It appears +the standard allows these functions to reorder equivalent elements of +the container at will, yet the pervasive red-black tree implementation +appears to provide stable behaviour. +

          + +

          This is of most concern when considering the behaviour of erase(). +A stability requirement would guarantee the correct working of the +following 'idiom' that removes elements based on a certain predicate +function. +

          + +
            multimap<int, int> m;
+  multimap<int, int>::iterator i = m.begin();
+  while (i != m.end()) {
+      if (pred(i))
+          m.erase (i++);
+      else
+          ++i;
+  }
+
          + +

          +Although clause 23.1.2/8 guarantees that i remains a valid iterator +througout this loop, absence of the stability requirement could +potentially result in elements being skipped. This would make +this code incorrect, and, furthermore, means that there is no way +of erasing these elements without iterating first over the entire +container, and second over the elements to be erased. This would +be unfortunate, and have a negative impact on both performance and +code simplicity. +

          + +

          +If the stability requirement is intended, it should be made explicit +(probably through an extra paragraph in clause 23.1.2). +

          +

          +If it turns out stability cannot be guaranteed, i'd argue that a +remark or footnote is called for (also somewhere in clause 23.1.2) to +warn against relying on stable behaviour (as demonstrated by the code +above). If most implementations will display stable behaviour, any +problems emerging on an implementation without stable behaviour will +be hard to track down by users. This would also make the need for an +erase_if() member function that much greater. +

          + +

          This issue is somewhat related to LWG issue 130.

          + +

          Proposed resolution:

          + +

          Add the following to the end of 23.1.2 [lib.associative.reqmts] paragraph 4: +"For multiset and multimap, insertand erase + are stable: they preserve the relative ordering of equivalent + elements.

          + +

          [Lillehammer: Matt provided wording]

          +

          [Joe Gottman points out that the provided wording does not address +multimap and multiset. N1780 also addresses this issue and suggests +wording.]

          + +

          [Mont Tremblant: Changed set and map to multiset and multimap.]

          + +

          Rationale:

          +

          The LWG agrees that this guarantee is necessary for common user + idioms to work, and that all existing implementations provide this + property. Note that this resolution guarantees stability for + multimap and multiset, not for all associative containers in + general.

          +

          373. Are basic_istream and basic_ostream to use (exceptions()&badbit) != 0 ?

          Section: 27.6.1.2.1 [lib.istream.formatted.reqmts], 27.6.2.5.1 [lib.ostream.formatted.reqmts]  Status: WP  Submitter: Keith Baker  Date: 23 Jul 2002

          @@ -11476,6 +11816,42 @@ paragraph 14 to "ios_base".

          Rationale:

          Fixes an obvious typo.

          +

          376. basic_streambuf semantics

          Section: 27.7.1.3 [lib.stringbuf.virtuals]  Status: WP  Submitter: Ray Lischner  Date: 14 Aug 2002

          +

          +In Section 27.7.1.3 [lib.stringbuf.virtuals], Table 90, the implication is that +the four conditions should be mutually exclusive, but they are not. +The first two cases, as written, are subcases of the third.

          + +

          +As written, it is unclear what should be the result if cases 1 and 2 +are both true, but case 3 is false. +

          + +

          Proposed resolution:

          + +

          Rewrite these conditions as:

          +
          +

          + (which & (ios_base::in|ios_base::out)) == ios_base::in +

          + +

          + (which & (ios_base::in|ios_base::out)) == ios_base::out +

          + +

          + (which & (ios_base::in|ios_base::out)) == +(ios_base::in|ios_base::out) + and way == either ios_base::beg or ios_base::end +

          + +

          Otherwise

          +
          + +

          Rationale:

          +

          It's clear what we wanted to say, we just failed to say it. This + fixes it.

          +

          379. nonsensical ctype::do_widen() requirement

          Section: 22.2.1.1.2 [lib.locale.ctype.virtuals]  Status: WP  Submitter: Martin Sebor  Date: 6 Sep 2002

          The last sentence in 22.2.1.1.2, p11 below doesn't seem to make sense. @@ -11651,6 +12027,64 @@ Change the guarantee to "postcondition: r is dereferenceable."

          Rationale:

          Fixes an obvious typo

          +

          384. equal_range has unimplementable runtime complexity

          Section: 25.3.3.3 [lib.equal.range]  Status: WP  Submitter: Hans Bos  Date: 18 Oct 2002

          +

          +Section 25.3.3.3 [lib.equal.range] +states that at most 2 * log(last - first) + 1 +comparisons are allowed for equal_range. +

          + +

          It is not possible to implement equal_range with these constraints.

          + +

          In a range of one element as in:

          +
              int x = 1;
+    equal_range(&x, &x + 1, 1)
+
          + +

          it is easy to see that at least 2 comparison operations are needed.

          + +

          For this case at most 2 * log(1) + 1 = 1 comparison is allowed.

          + +

          I have checked a few libraries and they all use the same (nonconforming) +algorithm for equal_range that has a complexity of

          +
               2* log(distance(first, last)) + 2.
+
          +

          I guess this is the algorithm that the standard assumes for equal_range.

          + +

          +It is easy to see that 2 * log(distance) + 2 comparisons are enough +since equal range can be implemented with lower_bound and upper_bound +(both log(distance) + 1). +

          + +

          +I think it is better to require something like 2log(distance) + O(1) (or +even logarithmic as multiset::equal_range). +Then an implementation has more room to optimize for certain cases (e.g. +have log(distance) characteristics when at most match is found in the range +but 2log(distance) + 4 for the worst case). +

          + +

          Proposed resolution:

          +

          In 25.3.3.1 [lib.lower.bound]/4, change log(last - first) + 1 +to log2(last - first) + O(1).

          + +

          In 25.3.3.2 [lib.upper.bound]/4, change log(last - first) + 1 +to log2(last - first) + O(1).

          + +

          In 25.3.3.3 [lib.equal.range]/4, change 2*log(last - first) + 1 +to 2*log2(last - first) + O(1).

          + +

          [Matt provided wording]

          +

          Rationale:

          +

          The LWG considered just saying O(log n) for all three, but +Ê decided that threw away too much valuable information.Ê The fact +Ê that lower_bound is twice as fast as equal_range is important. +Ê However, it's better to allow an arbitrary additive constant than to +Ê specify an exact count.Ê An exact count would have to +Ê involve floor or ceil.Ê It would be too easy to +Ê get this wrong, and don't provide any substantial value for users.

          +

          386. Reverse iterator's operator[] has impossible return type

          Section: 24.4.1.3.11 [lib.reverse.iter.opindex]  Status: DR  Submitter: Matt Austern  Date: 23 Oct 2002

          In 24.4.1.3.11 [lib.reverse.iter.opindex], reverse_iterator<>::operator[] is specified as having a return type of reverse_iterator::reference, @@ -13216,7 +13650,7 @@ In section 27.6.2.3

          443. filebuf::close() inconsistent use of EOF

          Section: 27.8.1.3 [lib.filebuf.members]  Status: WP  Submitter: Vincent Leloup  Date: 20 Nov 2003

          +

          443. filebuf::close() inconsistent use of EOF

          Section: 27.8.1.3 [lib.filebuf.members]  Status: WP  Submitter: Vincent Leloup  Date: 20 Nov 2003

          In section 27.8.1.3 [lib.filebuf.members] par6, in effects description of basic_filebuf<charT, traits>::close(), overflow(EOF) is used twice; @@ -13888,6 +14322,194 @@ value of widen(c) is otherwise. I propose to strike the Footnote.

          +

          475. May the function object passed to for_each modify the elements of the iterated sequence?

          Section: 25.1.1 [lib.alg.foreach]  Status: WP  Submitter: Stephan T. Lavavej, Jaakko Jarvi  Date: 9 Jul 2004

          +

          +It is not clear whether the function object passed to for_each is allowed to +modify the elements of the sequence being iterated over. +

          + +

          +for_each is classified without explanation in [lib.alg.nonmodifying], "25.1 +Non-modifying sequence operations". 'Non-modifying sequence operation' is +never defined. +

          + +

          +25(5) says: "If an algorithm's Effects section says that a value pointed to +by any iterator passed as an argument is modified, then that algorithm has +an additional type requirement: The type of that argument shall satisfy the +requirements of a mutable iterator (24.1)." +

          + +

          for_each's Effects section does not mention whether arguments can be +modified:

          + +
          + "Effects: Applies f to the result of dereferencing every iterator in the + range [first, last), starting from first and proceeding to last - 1." +
          + +

          +Every other algorithm in [lib.alg.nonmodifying] is "really" non-modifying in +the sense that neither the algorithms themselves nor the function objects +passed to the algorithms may modify the sequences or elements in any way. +This DR affects only for_each. +

          + +

          +We suspect that for_each's classification in "non-modifying sequence +operations" means that the algorithm itself does not inherently modify the +sequence or the elements in the sequence, but that the function object +passed to it may modify the elements it operates on. +

          + +

          +The original STL document by Stepanov and Lee explicitly prohibited the +function object from modifying its argument. +The "obvious" implementation of for_each found in several standard library +implementations, however, does not impose this restriction. +As a result, we suspect that the use of for_each with function objects that modify +their arguments is wide-spread. +If the restriction was reinstated, all such code would become non-conforming. +Further, none of the other algorithms in the Standard +could serve the purpose of for_each (transform does not guarantee the order in +which its function object is called). +

          + +

          +We suggest that the standard be clarified to explicitly allow the function object +passed to for_each modify its argument.

          + +

          Proposed resolution:

          +

          Add a nonnormative note to the Effects in 25.1.1 [lib.alg.foreach]: If +the type of 'first' satisfies the requirements of a mutable iterator, +'f' may apply nonconstant functions through the dereferenced iterators +passed to it. +

          + +

          Rationale:

          +

          The LWG believes that nothing in the standard prohibits function + objects that modify the sequence elements. The problem is that + for_each is in a secion entitled "nonmutating algorithms", and the + title may be confusing. A nonnormative note should clarify that.

          +
          +

          478. Should forward iterator requirements table have a line for r->m?

          Section: 24.1.3 [lib.forward.iterators]  Status: WP  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 second line may be unnecessary. 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. +
          + +

          +Because operators can be overloaded on an iterator's const-ness, the +current requirements allow iterators to make many of the operations +specified using the identifiers a and b invalid for non-const +iterators.

          + +

          Related issue: 477

          +

          Proposed resolution:

          + +

          Remove the "r->m" line from the Forward Iterator requirements +table. Change

          +
          + "const X" +
          + +

          to

          + +
          + "X or const X" +
          + +

          in paragraph 11 of [lib.iterator.requirements].

          + + +

          Rationale:

          +

          +This is a defect because it constrains an lvalue to returning a modifiable lvalue. +

          +
          +

          495. Clause 22 template parameter requirements

          Section: 22 [lib.localization]  Status: WP  Submitter: Beman Dawes  Date: 10 Jan 2005

          +

          It appears that there are no requirements specified for many of the +template parameters in clause 22. It looks like this issue has never +come up, except perhaps for Facet.

          + +

          Clause 22 isn't even listed in 17.3.2.1 [lib.type.descriptions], +either, which is the wording that allows requirements on template +parameters to be identified by name.

          + +

          So one issue is that 17.3.2.1 [lib.type.descriptions] Should be +changed to cover clause 22. A better change, which will cover us in +the future, would be to say that it applies to all the library +clauses. Then if a template gets added to any library clause we are +covered.

          + +

          charT, InputIterator, and other names with requirements defined +elsewhere are fine, assuming the 17.3.2.1 [lib.type.descriptions] fix. +But there are a few template arguments names which I don't think have +requirements given elsewhere:

          + +
            +
          • internT and externT. The fix is to add wording saying that internT +and externT must meet the same requirements as template arguments +named charT.
            • + +
          • stateT. I'm not sure about this one. There already is some wording, +but it seems a bit vague.
            • + +
          • Intl. [lib.locale.moneypunct.byname] The fix for this one is to +rename "Intl" to "International". The name is important because other +text identifies the requirements for the name International but not +for Intl.
            • +
          +

          Proposed resolution:

          +

          Change 17.3.2.1 [lib.type.descriptions], paragraph 1, from:

          +
          +The Requirements subclauses may describe names that are used to +specify constraints on template arguments.153) These names are used in +clauses 20, 23, 25, and 26 to describe the types that may be supplied +as arguments by a C++ program when instantiating template components +from the library. +
          +

          to:

          +
          +The Requirements subclauses may describe names that are used to +specify constraints on template arguments.153) These names are used in +library clauses to describe the types that may be supplied as +arguments by a C++ program when instantiating template components from +the library. +
          + +

          In the front matter of class 22, locales, add:

          +
          +Template parameter types internT and externT shall meet the +requirements of charT (described in 21 [lib.strings]). +
          +

          Rationale:

          +

          + Again, a blanket clause isn't blanket enough. Also, we've got a + couple of names that we don't have blanket requirement statements + for. The only issue is what to do about stateT. This wording is + thin, but probably adequate.

          +

          496. Illegal use of "T" in vector<bool>

          Section: 23.2.5 [lib.vector.bool]  Status: WP  Submitter: richard@ex-parrot.com  Date: 10 Feb 2005

          In the synopsis of the std::vector<bool> specialisation in 23.2.5 [lib.vector.bool], @@ -13900,6 +14522,210 @@ the non-template assign() function has the signature

          Proposed resolution:

          Replace "T" with "value_type".

          +

          497. meaning of numeric_limits::traps for floating point types

          Section: 18.2.1.2 [lib.numeric.limits.members]  Status: WP  Submitter: Martin Sebor  Date: 2 Mar 2005

          + +

          18.2.1.2, p59 says this much about the traps member of numeric_limits:

          + +
          +

          static const bool traps;
          +-59- true if trapping is implemented for the type.204) +
          +Footnote 204: Required by LIA-1. +

          +
          + +

          It's not clear what is meant by "is implemented" here.

          + +

          +In the context of floating point numbers it seems reasonable to expect +to be able to use traps to determine whether a program can "safely" use +infinity(), quiet_NaN(), etc., in arithmetic expressions, that is +without causing a trap (i.e., on UNIX without having to worry about +getting a signal). When traps is true, I would expect any of the +operations in section 7 of IEEE 754 to cause a trap (and my program +to get a SIGFPE). So, for example, on Alpha, I would expect traps +to be true by default (unless I compiled my program with the -ieee +option), false by default on most other popular architectures, +including IA64, MIPS, PA-RISC, PPC, SPARC, and x86 which require +traps to be explicitly enabled by the program. +

          + +

          +Another possible interpretation of p59 is that traps should be true +on any implementation that supports traps regardless of whether they +are enabled by default or not. I don't think such an interpretation +makes the traps member very useful, even though that is how traps is +implemented on several platforms. It is also the only way to implement +traps on platforms that allow programs to enable and disable trapping +at runtime. +

          +

          Proposed resolution:

          +

          Change p59 to read:

          +
          True if, at program startup, there exists a value of the type that + would cause an arithmetic operation using that value to trap.
          +

          Rationale:

          +

          + Real issue, since trapping can be turned on and off. Unclear what a + static query can say about a dynamic issue. The real advice we should + give users is to use cfenv for these sorts of queries. But this new + proposed resolution is at least consistent and slightly better than + nothing.

          +
          +

          505. Result_type in random distribution requirements

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

          +

          +Table 17: Random distribution requirements +

          +

          +Row 1 requires that each random distribution provide a nested type "input_type"; +this type denotes the type of the values that the distribution consumes. +

          +

          +Inspection of all distributions in [tr.rand.dist] reveals that each distribution +provides a second typedef ("result_type") that denotes the type of the values the +distribution produces when called. +

          +

          Proposed resolution:

          +

          +It seems to me that this is also a requirement +for all distributions and should therefore be indicated as such via a new second +row to this table 17: +

          + + + + + + + +
          X::result_typeT---compile-time
          + +

          [ +Berlin: Voted to WP. N1932 adopts the proposed resolution: see Table 5 row 1. +]

          + +
          +

          507. Missing requirement for variate_generator::operator()

          Section: TR1 5.1.3 [tr.rand.var]  Status: WP  Submitter: Walter Brown  Date: 3 Jul 2005

          +

          +Paragraph 11 of [tr.rand.var] equires that the member template +

          +
          template<class T> result_type operator() (T value);
+
          +

          +return +

          +
          distribution()(e, value)
+
          +

          +However, not all distributions have an operator() with a corresponding signature. +

          + +

          [ +Berlin: As a working group we voted in favor of N1932 which makes this moot: +variate_generator has been eliminated. Then in full committee we voted to give +this issue WP status (mistakenly). +]

          + +

          Proposed resolution:

          +

          +We therefore recommend that we insert the following precondition before paragraph 11: +

          +
          +Precondition: distribution().operator()(e,value) is well-formed. +
          +
          +

          508. Bad parameters for ranlux64_base_01

          Section: TR1 5.1.5 [tr.rand.predef]  Status: WP  Submitter: Walter Brown  Date: 3 Jul 2005

          +

          +The fifth of these engines with predefined parameters, ranlux64_base_01, +appears to have an unintentional error for which there is a simple correction. +The two pre-defined subtract_with_carry_01 engines are given as: +

          +
          typedef subtract_with_carry_01<float,  24, 10, 24> ranlux_base_01;
+typedef subtract_with_carry_01<double, 48, 10, 24> ranlux64_base_01;
+
          +

          +We demonstrate below that ranlux64_base_01 fails to meet the intent of the +random number generation proposal, but that the simple correction to +

          +
          typedef subtract_with_carry_01<double, 48,  5, 12> ranlux64_base_01;
+
          +

          +does meet the intent of defining well-known good parameterizations. +

          +

          +The ranlux64_base_01 engine as presented fails to meet the intent for +predefined engines, stated in proposal N1398 (section E): +

          +

          +In order to make good random numbers available to a large number of library +users, this proposal not only defines generic random-number engines, but also +provides a number of predefined well-known good parameterizations for those. +

          +

          +The predefined ranlux_base_01 engine has been proven [1,2,3] to have a very +long period and so meets this criterion. This property makes it suitable for +use in the excellent discard_block engines defined subsequently. The proof +of long period relies on the fact (proven in [1]) that 2**(w*r) - 2**(w*s) ++ 1 is prime (w, r, and s are template parameters to subtract_with_carry_01, +as defined in [tr.rand.eng.sub1]). +

          +

          +The ranlux64_base_01 engine as presented in [tr.rand.predef] uses w=48, r=24, s=10. +For these numbers, the combination 2**(w*r)-2**(w*s)+1 is non-prime (though +explicit factorization would be a challenge). In consequence, while it is +certainly possible for some seeding states that this engine would have a very +long period, it is not at all Òwell-knownÓ that this is the case. The intent +in the N1398 proposal involved the base of the ranlux64 engine, which finds heavy +use in the physics community. This is isomorphic to the predefined ranlux_base_01, +but exploits the ability of double variables to hold (at least) 48 bits of mantissa, +to deliver 48 random bits at a time rather than 24. +

          +

          Proposed resolution:

          +

          +To achieve this intended behavior, the correct template parameteriztion would be: +

          +
          typedef subtract_with_carry_01<double, 48, 5, 12> ranlux64_base_01;
+
          +

          +The sequence of mantissa bits delivered by this is isomorphic (treating each +double as having the bits of two floats) to that delivered by ranlux_base_01. +

          +

          +References: +

          +
            +
          1. F. James, Comput. Phys. Commun. 60(1990) 329
            2. +
          2. G. Marsaglia and A. Zaman, Ann. Appl. Prob 1(1991) 462
            3. +
          3. M. Luscher, Comput. Phys. Commun. 79(1994) 100-110
            4. +
          + +

          [ +Berlin: Voted to WP. N1932 adopts the proposed resolution in 26.3.5, +just above paragraph 5. +]

          + +
          +

          519. Data() undocumented

          Section: TR1 6.2.2 [tr.array.array]  Status: WP  Submitter: Pete Becker  Date: 3 Jul 2005

          +

          +array<>::data() is present in the class synopsis, but not documented. +

          +

          Proposed resolution:

          +

          +Add a new section, after 6.2.2.3: +

          +
          T*       data()
+const T* data() const;
+
          +

          +Returns: elems. +

          +

          +Change 6.2.2.4/2 to: +

          +
          +In the case where N == 0, begin() == end(). The return value +of data() is unspecified. +
          +

          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 -- 2.30.2