From f50e1d8436260c7fceff35cf62fe5fe0d03fc216 Mon Sep 17 00:00:00 2001 From: Paolo Carlini Date: Thu, 23 Jul 2009 15:50:16 +0000 Subject: [PATCH] lwg-closed.html: Update to R65. 2009-07-23 Paolo Carlini * doc/html/ext/lwg-closed.html: Update to R65. * doc/html/ext/lwg-defects.html: Likewise. * doc/html/ext/lwg-active.html: Likewise. * doc/xml/manual/intro.xml: Update DRs entries. From-SVN: r150016 --- libstdc++-v3/doc/html/ext/lwg-active.html | 36482 ++++++++++++++----- libstdc++-v3/doc/html/ext/lwg-closed.html | 6819 +++- libstdc++-v3/doc/html/ext/lwg-defects.html | 10048 +++-- libstdc++-v3/doc/xml/manual/intro.xml | 16 +- 4 files changed, 40816 insertions(+), 12549 deletions(-) diff --git a/libstdc++-v3/doc/html/ext/lwg-active.html b/libstdc++-v3/doc/html/ext/lwg-active.html index 94b57c0a6aa..24130482298 100644 --- a/libstdc++-v3/doc/html/ext/lwg-active.html +++ b/libstdc++-v3/doc/html/ext/lwg-active.html @@ -14,11 +14,11 @@ del {background-color:#FFA0A0} - + - + @@ -29,9 +29,9 @@ del {background-color:#FFA0A0}
Doc. no.N2727=08-0237N2894=09-0084
Date:2008-08-242009-06-21
Project:Howard Hinnant <howard.hinnant@gmail.com>
-

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

+

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

-

Reference ISO/IEC IS 14882:1998(E)

+

Reference ISO/IEC IS 14882:2003(E)

Also see:

  • Details:
      -
    • Added the following New issues: 862, 863, 864, 865, 866, 867, 868, 869.
      • +
    • Added the following New issues: 862, 863, 864, 865, 866, 867, 868, 869.
    • Changed the following issues from Pending NAD Editorial to NAD Editorial: 393, 557, 592, 754, 757.
    • Changed the following issues from Pending WP to Open: 644.
      • -
    • Changed the following issues from WP to Ready: 387, 629.
      • -
    • Changed the following issues from Pending NAD Editorial to Review: 709.
      • +
    • Changed the following issues from WP to Ready: 387, 629.
      • +
    • Changed the following issues from Pending NAD Editorial to Review: 709.
    • @@ -136,24 +267,24 @@ del {background-color:#FFA0A0}
  • Details:
    • @@ -166,7 +297,7 @@ del {background-color:#FFA0A0}
  • 838 issues total, up by 25.
  • Details:
    • @@ -182,8 +313,8 @@ del {background-color:#FFA0A0}
  • Details:
  • Details:
  • Details:
    • @@ -249,16 +380,16 @@ del {background-color:#FFA0A0}
  • 754 issues total, up by 31.
  • Details:
  • Details:
    • @@ -287,13 +418,13 @@ del {background-color:#FFA0A0}
  • 708 issues total, up by 12.
  • Details:
      -
    • Added the following New issues: 697, 698, 699, 700, 701, 702, 703, 704, 705, 706, 707, 708.
      • +
    • Added the following New issues: 697, 698, 699, 700, 701, 702, 703, 704, 705, 706, 707, 708.
    • Changed the following issues from New to NAD: 583, 584, 662.
    • Changed the following issues from Open to NAD: 528.
    • Changed the following issues from New to NAD Editorial: 637, 647, 658, 690.
    • Changed the following issues from Open to NAD Editorial: 525.
    • Changed the following issues from Pending NAD Editorial to NAD Editorial: 553, 571, 591, 633, 636, 641, 642, 648, 649, 656.
      • -
    • Changed the following issues from New to Open: 579, 631, 680.
      • +
    • Changed the following issues from New to Open: 579, 631, 680.
    • Changed the following issues from Pending WP to Open: 258.
    • Changed the following issues from Ready to Pending WP: 644.
    • Changed the following issues from New to Ready: 577, 660.
      • @@ -314,7 +445,7 @@ del {background-color:#FFA0A0}
    • 696 issues total, up by 20.
  • Details:
  • Details:
  • Details:
    • @@ -376,7 +507,7 @@ del {background-color:#FFA0A0}
  • 619 issues total, up by 10.
  • Details:
    • @@ -392,10 +523,10 @@ del {background-color:#FFA0A0}
  • Moved issues 520, 521, 530, 535, 537, 538, 540, 541 to WP.
  • Moved issues 504, 512, 516, 544, 549, 554, 555, 558 to NAD.
  • Moved issue 569 to Dup.
    • -
  • Moved issues 518, 523, 524, 542, 556, 557, 559, 597, 606 to Open.
    • +
  • Moved issues 518, 523, 524, 542, 556, 557, 559, 597, 606 to Open.
  • Moved issues 543, 545, 549, 549, 598 - 603, 605 to Ready.
  • Moved issues 531, 551, 604 to Review.
    • -
  • Added new issues 593-609.
    • +
  • Added new issues 593, 594, 595, 596, 597, 598, 599, 600, 601, 602, 603, 604, 605, 606, 607, 608, 609.
    • @@ -408,7 +539,7 @@ del {background-color:#FFA0A0}
  • 592 issues total, up by 5.
  • Details:
    • @@ -421,7 +552,7 @@ del {background-color:#FFA0A0}
  • 587 issues total, up by 13.
  • Details:
    • @@ -436,9 +567,9 @@ del {background-color:#FFA0A0}
  • 574 issues total, up by 8.
  • Details:
  • Details:
    • @@ -469,7 +600,7 @@ del {background-color:#FFA0A0}
  • 535 issues total.
  • Details:
    • @@ -485,7 +616,7 @@ Moved issue 504-522. +Merged open TR1 issues in 504-522. Added new issues 523-523
  • R37: @@ -494,7 +625,7 @@ Added new issues 454 were moved to "DR" status, and all issues +for 454 were moved to "DR" status, and all issues previously in "DR" status were moved to "WP".
  • R35: @@ -542,7 +673,7 @@ Pre-Oxford mailing. Added new issues 253, which has been given a new proposed resolution, were -moved to DR status. Added new issues 383-389. (Issues 387-389 were discussed +moved to DR status. Added new issues 383-389. (Issues 387-389 were discussed at the meeting.) Made progress on issues 225, 226, 229: 225 and 229 have been moved to Ready status, and the only remaining concerns with 226 involve wording.
    • @@ -601,7 +732,7 @@ Changed status of issues to Ready. Closed issues -111 277 279 287 +111 277 279 287 289 293 302 313 314 as NAD. @@ -627,7 +758,7 @@ issues 209, 210, 211, 212, 217, 220, 222, 223, 224, -227 to "DR". Reopened issue 23. Reopened +227 to "DR". Reopened issue 23. Reopened issue 187. Changed issues 2 and 4 to NAD. Fixed a typo in issue 17. Fixed issue 70: signature should be changed both places it @@ -680,7 +811,7 @@ in Dublin. (99-0016/N1193, 21 Apr 99) pre-Dublin updated: Added issues 130, 131, 132, 133, 134, 135, 136, 137, -138, 139 (31 Mar 99) +138, 139 (31 Mar 99)
  • R6: pre-Dublin mailing. Added issues 127, 128, @@ -693,7 +824,7 @@ for making list public. (30 Dec 98)
  • R4: post-Santa Cruz II updated: Issues 110, -111, 112, 113 added, several +111, 112, 113 added, several issues corrected. (22 Oct 98)
  • R3: @@ -756,12 +887,6 @@ 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 @@ -775,11 +900,15 @@ format, TC - (Technical Corrigenda) - The full +

    TC1 - (Technical Corrigenda 1) - The full WG21 committee has voted to accept the Defect Report's Proposed Resolution as a Technical Corrigenda. Action on this issue is thus complete and no further action is possible under ISO rules.

    +

    CD1 - (Committee Draft 2008) - The full + WG21 committee has voted to accept the Defect Report's Proposed + Resolution into the Fall 2008 Committee Draft.

    +

    TRDec - (Decimal TR defect) - The LWG has voted to accept the Defect Report's Proposed Resolution into the Decimal TR. Action on this issue is thus @@ -790,6 +919,13 @@ format, Active Issues -

    -

    23. Num_get overflow result

    -

    Section: 22.2.2.1.2 [facet.num.get.virtuals] Status: Review - Submitter: Nathan Myers Date: 1998-08-06

    -

    View other active issues in [facet.num.get.virtuals].

    -

    View all other issues in [facet.num.get.virtuals].

    -

    View all issues with Review status.

    -

    Discussion:

    -

    The current description of numeric input does not account for the -possibility of overflow. This is an implicit result of changing the -description to rely on the definition of scanf() (which fails to -report overflow), and conflicts with the documented behavior of -traditional and current implementations.

    - -

    Users expect, when reading a character sequence that results in a -value unrepresentable in the specified type, to have an error -reported. The standard as written does not permit this.

    - -

    Further comments from Dietmar:

    - -

    -I don't feel comfortable with the proposed resolution to issue 23: It -kind of simplifies the issue to much. Here is what is going on: -

    - -

    -Currently, the behavior of numeric overflow is rather counter intuitive -and hard to trace, so I will describe it briefly: -

    - -
      -
    • - According to 22.2.2.1.2 [facet.num.get.virtuals] - paragraph 11 failbit is set if scanf() would - return an input error; otherwise a value is converted to the rules - of scanf. -
      • -
    • - scanf() is defined in terms of fscanf(). -
      • -
    • - fscanf() returns an input failure if during conversion no - character matching the conversion specification could be extracted - before reaching EOF. This is the only reason for fscanf() - to fail due to an input error and clearly does not apply to the case - of overflow. -
      • -
    • - Thus, the conversion is performed according to the rules of - fscanf() which basically says that strtod, - strtol(), etc. are to be used for the conversion. -
      • -
    • - The strtod(), strtol(), etc. functions consume as - many matching characters as there are and on overflow continue to - consume matching characters but also return a value identical to - the maximum (or minimum for signed types if there was a leading minus) - value of the corresponding type and set errno to ERANGE. -
      • -
    • - Thus, according to the current wording in the standard, overflows - can be detected! All what is to be done is to check errno - after reading an element and, of course, clearing errno - before trying a conversion. With the current wording, it can be - detected whether the overflow was due to a positive or negative - number for signed types. -
      • -
    - -

    Further discussion from Redmond:

    - -

    The basic problem is that we've defined our behavior, -including our error-reporting behavior, in terms of C90. However, -C90's method of reporting overflow in scanf is not technically an -"input error". The strto_* functions are more precise.

    - -

    There was general consensus that failbit should be set -upon overflow. We considered three options based on this:

    -
      -
    1. Set failbit upon conversion error (including overflow), and - don't store any value.
      2. -
    2. Set failbit upon conversion error, and also set errno to - indicated the precise nature of the error.
      3. -
    3. Set failbit upon conversion error. If the error was due to - overflow, store +-numeric_limits<T>::max() as an - overflow indication.
      4. -
    - -

    Straw poll: (1) 5; (2) 0; (3) 8.

    - - -

    Discussed at Lillehammer. General outline of what we want the - solution to look like: we want to say that overflow is an error, and - provide a way to distinguish overflow from other kinds of errors. - Choose candidate field the same way scanf does, but don't describe - the rest of the process in terms of format. If a finite input field - is too large (positive or negative) to be represented as a finite - value, then set failbit and assign the nearest representable value. - Bill will provide wording.

    - -

    -Discussed at Toronto: -N2327 -is in alignment with the direction we wanted to go with in Lillehammer. Bill -to work on. -

    - - - -

    Proposed resolution:

    - -

    -Change 22.2.2.1.2 [facet.num.get.virtuals], end of p3: -

    - -
    -

    -Stage 3: The result of stage 2 processing can be one of -The sequence of chars accumulated in stage 2 (the field) is -converted to a numeric value by the rules of one of the functions declared -in the header <cstdlib>: -

    -
      -
    • -A sequence of chars has been accumulated in stage 2 that is -converted (according to the rules of scanf) to a value of the -type of val. This value is stored in val and ios_base::goodbit is -stored in err. -For a signed integer value, the function strtoll. -
      • -
    • -The sequence of chars accumulated in stage 2 would have caused -scanf to report an input failure. ios_base::failbit is -assigned to err. -For an unsigned integer value, the function strtoull. -
      • -
    • -For a floating-point value, the function strtold. -
      • -
    -

    -The numeric value to be stored can be one of: -

    -
      -
    • zero, if the conversion function fails to convert the entire field. -ios_base::failbit is assigned to err.
      • -
    • the most positive representable value, if the field represents a value -too large positive to be represented in val. ios_base::failbit is assigned -to err.
      • -
    • the most negative representable value (zero for unsigned integer), if -the field represents a value too large negative to be represented in val. -ios_base::failbit is assigned to err.
      • -
    • the converted value, otherwise.
      • -
    - -

    -The resultant numeric value is stored in val. -

    -
    - -

    -Change 22.2.2.1.2 [facet.num.get.virtuals], p6-p7: -

    - -
    -
    iter_type do_get(iter_type in, iter_type end, ios_base& str, 
-                 ios_base::iostate& err, bool& val) const;
-
    -
    -

    --6- Effects: If -(str.flags()&ios_base::boolalpha)==0 then input -proceeds as it would for a long except that if a value is being -stored into val, the value is determined according to the -following: If the value to be stored is 0 then false is stored. -If the value is 1 then true is stored. Otherwise -err|=ios_base::failbit is performed and no value true is -stored. and ios_base::failbit is assigned to err. -

    -

    --7- Otherwise target sequences are determined "as if" by calling the -members falsename() and truename() of the facet -obtained by use_facet<numpunct<charT> ->(str.getloc()). Successive characters in the range -[in,end) (see 23.1.1) are obtained and matched -against corresponding positions in the target sequences only as -necessary to identify a unique match. The input iterator in is -compared to end only when necessary to obtain a character. If and -only if a target sequence is uniquely matched, val is set to the -corresponding value. Otherwise false is stored and ios_base::failbit -is assigned to err. -

    -
    -
    - - - - -

    96. Vector<bool> is not a container

    -

    Section: 23.2.6 [vector] Status: Open - Submitter: AFNOR Date: 1998-10-07

    +

    Section: 23.3.6 [vector] Status: Tentatively NAD Future + Submitter: AFNOR Opened: 1998-10-07 Last modified: 2009-05-25

    View all other issues in [vector].

    -

    View all issues with Open status.

    Discussion:

    vector<bool> is not a container as its reference and pointer types are not references and pointers.

    @@ -1086,7 +1022,61 @@ over-my-dead-body positions.]

    We need a paper for the new bit_vector class.

    +

    [ +Batavia: +]

    +
    +The LWG feels we need something closer to SGI's bitvector to ease migration +from vector<bool>. Although some of the funcitonality from +N2050 +could well be used in such a template. The concern is easing the API migration for those +users who want to continue using a bit-packed container. Alan and Beman to work. +
    + +

    [ +Post Summit Alisdair adds: +]

    + + +
    +

    +vector<bool> is now a conforming container under the revised terms of C++0x, +which supports containers of proxies. +

    +

    +Recommend NAD. +

    +

    +Two issues remain: +

    +

    +i/ premature optimization in the specification. +There is still some sentiment that deprecation is the correct way to go, +although it is still not clear what it would mean to deprecate a single +specialization of a template. +

    +

    +Recommend: Create a new issue for the discussion, leave as Open. +

    +

    +ii/ Request for a new bitvector class to guarantee the optimization, perhaps +with a better tuned interface. +

    +

    +This is a clear extension request that may be handled via a future TR. +

    +
    + +

    [ +Batavia (2009-05): +]

    + +
    +We note that most of this issue has become moot over time, +and agree with Alisdair's recommendations. +Move to NAD Future for reconsideration of part (ii). +

    Proposed resolution:

    @@ -1097,23 +1087,99 @@ and N2160.

    + + + + + +
    +

    111. istreambuf_iterator::equal overspecified, inefficient

    +

    Section: 24.6.3.5 [istreambuf.iterator::equal] Status: Open + Submitter: Nathan Myers Opened: 1998-10-15 Last modified: 2009-03-13

    +

    View other active issues in [istreambuf.iterator::equal].

    +

    View all other issues in [istreambuf.iterator::equal].

    +

    View all issues with Open status.

    +

    Discussion:

    +

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

    + +

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

    + +

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

    +

    [ -Batavia: The LWG feels we need something closer to SGI's bitvector to ease migration -from vector<bool>. Although some of the funcitonality from -N2050 -could well be used in such a template. The concern is easing the API migration for those -users who want to continue using a bit-packed container. Alan and Beman to work. +Summit: ]

    +
    +Reopened by Alisdair. +
    + +

    [ +Post Summit Daniel adds: +]

    + + +
    +

    +Recommend NAD. The proposed wording would violate the axioms of +concept requirement EqualityComparable axioms as part of concept InputIterator +and more specifically it would violate the explicit wording of +24.2.2 [input.iterators]/7: +

    + +
    +If two iterators a and b of the same type are equal, then either a +and b are both +dereferenceable or else neither is dereferenceable. +
    + +
    + + + +

    Proposed resolution:

    +

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

    + +
    +

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

    +
    + +

    with

    + +
    +

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

    +
    + + + +

    Rationale:

    +

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

    +

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

    -

    Section: 27.7 [string.streams], 27.8 [file.streams] Status: Open - Submitter: Angelika Langer Date: 1999-02-22

    +

    Section: 27.8 [string.streams], 27.9 [file.streams] Status: Open + Submitter: Angelika Langer Opened: 1999-02-22 Last modified: 2008-03-14

    View all other issues in [string.streams].

    View all issues with Open status.

    Discussion:

    @@ -1145,7 +1211,7 @@ post Bellevue: Alisdair requested to re-Open.

    Proposed resolution:

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

    +qualified as const to 27.6.2 [streambuf]:

        openmode mode() const;

    @@ -1169,70 +1235,142 @@ retained for future reference.

    -

    180. Container member iterator arguments constness has unintended consequences

    -

    Section: 21.3 [basic.string] Status: Ready - Submitter: Dave Abrahams Date: 1999-07-01

    -

    View other active issues in [basic.string].

    -

    View all other issues in [basic.string].

    -

    View all issues with Ready status.

    +

    138. Class ctype_byname<char> redundant and misleading

    +

    Section: 22.4.1.4 [locale.codecvt] Status: Open + Submitter: Angelika Langer Opened: 1999-03-18 Last modified: 2009-03-09

    +

    View other active issues in [locale.codecvt].

    +

    View all other issues in [locale.codecvt].

    +

    View all issues with Open status.

    Discussion:

    -

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

    +

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

    -

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

    +

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

    -

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

    +

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

    + +

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

    [ -post Bellevue, Alisdair adds: +Summit: ]

    -

    -This issue was implemented by -N2350 -for everything but basic_string. -

    +Reopened by Alisdair. +
    -

    -Note that the specific example in this issue (basic_string) is the one place -we forgot to amend in -N2350, -so we might open this issue for that -single container? -

    + + +

    Rationale:

    +

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

    + + + + +
    +

    149. Insert should return iterator to first element inserted

    +

    Section: 23.2.3 [sequence.reqmts] Status: Open + Submitter: Andrew Koenig Opened: 1999-06-28 Last modified: 2009-05-01

    +

    View other active issues in [sequence.reqmts].

    +

    View all other issues in [sequence.reqmts].

    +

    View all issues with Open status.

    +

    Discussion:

    +

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

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

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

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

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

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

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

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

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

    + +

    [ +Summit: +]

    + + +
    +Reopened by Alisdair.

    [ -Sophia Antipolis: +Post Summit Alisdair adds: ]

    -This was a fix that was intended for all standard library containers, -and has been done for other containers, but string was missed. +In addition to the original rationale for C++03, this change also gives a +consistent interface for all container insert operations i.e. they all +return an iterator to the (first) inserted item.

    +

    -The wording updated. -

    -

    -We did not make the change in replace, because this change would affect -the implementation because the string may be written into. This is an -issue that should be taken up by concepts. -

    -

    -We note that the supplied wording addresses the initializer list provided in -N2679. +Proposed wording provided.

    @@ -1240,74 +1378,385 @@ We note that the supplied wording addresses the initializer list provided in

    Proposed resolution:

    -Update the following signature in the basic_string class template definition in -21.3 [basic.string], p5: + Table 83 +change return type from void to iterator for the following rows: +

    + +
    + + + + + + + + + + + + + + + + + + + + + + + + +
    Table 83 -- Sequence container requirements (in addition to container)
    ExpressionReturn typeAssertion/note pre-/post-condition
    +a.insert(p,n,t) + +void iterator + +Inserts n copies of t before p. +
    +a.insert(p,i,j) + +void iterator + +Each iterator in the range [i,j) shall be +dereferenced exactly once. +pre: i and j are not iterators into a. +Inserts copies of elements in [i, j) before p +
    +a.insert(p,il) + +void iterator + +a.insert(p, il.begin(), il.end()). +
    +
    + +

    +Add after p6 23.2.3 [sequence.reqmts]:

    -
    namespace std {
-  template<class charT, class traits = char_traits<charT>,
-    class Allocator = allocator<charT> >
-  class basic_string {
 
-    ...
+
    
+
    -6- ...
    
 
-    iterator insert(const_iterator p, charT c);
-    void insert(const_iterator p, size_type n, charT c);
-    template<class InputIterator>
-      void insert(const_iterator p, InputIterator first, InputIterator last);
-    void insert(const_iterator p, initializer_list<charT>);
+
    
+The iterator returned from a.insert(p,n,t) points to the copy of the
+first element inserted into a, or p if n == 0.
+
    
 
-    ...
+
    
+The iterator returned from a.insert(p,i,j) points to the copy of the
+first element inserted into a, or p if i == j.
+
    
 
-    iterator erase(const_iterator const_position);
-    iterator erase(const_iterator first, const_iterator last);
+
    
+The iterator returned from a.insert(p,il) points to the copy of the
+first element inserted into a, or p if il is empty.
+
    
 
-    ...
+
    
 
-  };
+
    
+p9 23.2.6.1 [container.concepts.free] change return type from
+void to iterator:
+
    
+
+
    concept RangeInsertionContainer<typename C, typename Iter> : InsertionContainer<C> {
+  requires InputIterator<Iter>;
+  void iterator insert(C&, const_iterator position, Iter first, Iter last);
 }
 
    
 
 
    
-Update the following signatures in 21.3.6.4 [string::insert]:
+p9 23.2.6.2 [container.concepts.member] change return type from
+void to iterator:
 
    
 
-
    iterator insert(const_iterator p, charT c);
-void insert(const_iterator p, size_type n, charT c);
-template<class InputIterator>
-  void insert(const_iterator p, InputIterator first, InputIterator last);
-void insert(const_iterator p, initializer_list<charT>);
+
    auto concept MemberRangeInsertionContainer<typename C, typename Iter> : MemberInsertionContainer<C> {
+  requires InputIterator<Iter>;
+  void iterator C::insert(const_iterator position, Iter first, Iter last);
+}
 
    
 
 
    
-Update the following signatures in 21.3.6.5 [string::erase]:
+p8 23.2.6.3 [container.concepts.maps] change return type from
+void to iterator, add return statement:
 
    
 
-
    iterator erase(const_iterator const_position);
-iterator erase(const_iterator first, const_iterator last);
+
    template <MemberRangeInsertionContainer C, InputIterator Iter>
+concept_map RangeInsertionContainer<C, Iter> {
+  void iterator insert(C& c, Container<C>::const_iterator i, Iter first, Iter last)
+  { return c.insert(i, first, last); }
+}
 
    
 
+
    
+p2 23.3.2 [deque] Update class definition, change return type
+from void to iterator:
+
    
+
+
    requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
+  void iterator insert(const_iterator position, size_type n, const T& x);
+template <InputIterator Iter>
+  requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T>
+  void iterator insert(const_iterator position, Iter first, Iter last);
+requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
+  void iterator insert(const_iterator position, initializer_list<T>);
+
    
+
+
    
+23.3.2.3 [deque.modifiers] change return type from void to iterator on following declarations:
+
    
+
+
    requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
+  void iterator insert(const_iterator position, size_type n, const T& x);
+template <InputIterator Iter>
+  requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T>
+  void iterator insert(const_iterator position, Iter first, Iter last);
+
    
+
+
    
+Add the following (missing) declaration
+
    
+
+
    requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
+  iterator insert(const_iterator position, initializer_list<T>);
+
    
+
+
    
+23.3.3 [forwardlist] Update class definition, change return type
+from void to iterator:
+
    
+
+
    requires AllocatableElement<Alloc, T, const T&>
+  void iterator insert_after(const_iterator position, initializer_list<T> il);
+requires AllocatableElement<Alloc, T, const T&>
+  void iterator insert_after(const_iterator position, size_type n, const T& x);
+template <InputIterator Iter>
+  requires AllocatableElement<Alloc, T, Iter::reference>
+  void iterator insert_after(const_iterator position, Iter first, Iter last);
+
    
+
+
    
+p8 23.3.3.4 [forwardlist.modifiers] change return type from void to iterator:
+
    
+
+
    requires AllocatableElement<Alloc, T, const T&>
+  void iterator insert_after(const_iterator position, size_type n, const T& x);
+
    
+
+
    
+Add paragraph:
+
    
+
+
    
+Returns: position.
+
    
+
+
    
+p10 23.3.3.4 [forwardlist.modifiers] change return type from void to iterator:
+
    
+
+
    template <InputIterator Iter>
+  requires AllocatableElement<Alloc, T, Iter::reference>
+  void iterator insert_after(const_iterator position, Iter first, Iter last);
+
    
+
+
    
+Add paragraph:
+
    
+
+
    
+Returns: position.
+
    
+
+
    
+p12 23.3.3.4 [forwardlist.modifiers] change return type from void to iterator on following declarations:
+
    
+
+
    requires AllocatableElement<Alloc, T, const T&>
+  void iterator insert_after(const_iterator position, initializer_list<T> il);
+
    
+
+
    
+change return type from void to iterator on following declarations:
+
    
+
+
    
+p2 23.3.4 [list] Update class definition, change return type from void to iterator:
+
    
+
+
    requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
+  void iterator insert(const_iterator position, size_type n, const T& x);
+
+template <InputIterator Iter>
+  requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T>
+  void iterator insert(const_iterator position, Iter first, Iter last);
+
+requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
+  void iterator insert(const_iterator position, initializer_list<T>);
+
    
+
+
+
    
+23.3.4.3 [list.modifiers] change return type from void to iterator on following declarations:
+
    
+
+
    requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
+  void iterator insert(const_iterator position, size_type n, const T& x);
+
+template <InputIterator Iter>
+  requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T>
+  void iterator insert(const_iterator position, Iter first, Iter last);
+
    
+
+
    
+Add the following (missing) declaration
+
    
+
+
    requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
+  iterator insert(const_iterator position, initializer_list<T>);
+
    
+
+
    
+p2 23.3.6 [vector]
+
    
+
+
    
+Update class definition, change return type from void to iterator:
+
    
+
+
    requires AllocatableElement<Alloc, T, T&&> && MoveAssignable<T>
+  void iterator insert(const_iterator position, T&& x);
+
+requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
+  void iterator insert(const_iterator position, size_type n, const T& x);
+
+template <InputIterator Iter>
+  requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T>
+  void iterator insert(const_iterator position, Iter first, Iter last);
+
+requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
+  void iterator insert(const_iterator position, initializer_list<T>);
+
    
+
+
    
+23.3.6.4 [vector.modifiers] change return type from void to iterator on following declarations:
+
    
+
+
    requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
+  void iterator insert(const_iterator position, size_type n, const T& x);
+
+template <InputIterator Iter>
+  requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T>
+  void iterator insert(const_iterator position, Iter first, Iter last);
+
    
+
+
    
+Add the following (missing) declaration
+
    
+
+
    requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
+  iterator insert(const_iterator position, initializer_list<T>);
+
    
+
+
+
    
+p1 23.3.7 [vector.bool] Update class definition, change return type from void to iterator:
+
    
+
+
    void iterator insert (const_iterator position, size_type n, const bool& x);
+
+template <InputIterator Iter>
+  requires Convertible<Iter::reference, bool>
+  void iterator insert(const_iterator position, Iter first, Iter last);
+
+  void iterator insert(const_iterator position, initializer_list<bool> il);
+
    
+
+
    
+p5 21.4 [basic.string] Update class definition, change return type from void to iterator:
+
    
+
+
    void iterator insert(const_iterator p, size_type n, charT c);
+
+template<class InputIterator>
+  void iterator insert(const_iterator p, InputIterator first, InputIterator last);
+
+void iterator insert(const_iterator p, initializer_list<charT>);
+
    
+
+
    
+p13 21.4.6.4 [string::insert] change return type from void to iterator:
+
    
+
+
    void iterator insert(const_iterator p, size_type n, charT c);
+
    
+
+
    
+Add paragraph:
+
    
+
+
    
+Returns: an iterator which refers to the copy of the first inserted
+character, or p if n == 0.
+
    
+
+
    
+p15 21.4.6.4 [string::insert] change return type from void to iterator:
+
    
+
+
    template<class InputIterator>
+  void iterator insert(const_iterator p, InputIterator first, InputIterator last);
+
    
+
+
    
+Add paragraph:
+
    
+
+
    
+Returns: an iterator which refers to the copy of the first inserted
+character, or p if first == last.
+
    
+
+
    
+p17 21.4.6.4 [string::insert] change return type from void to iterator:
+
    
+
+
    void iterator insert(const_iterator p, initializer_list<charT> il);
+
    
+
+
    
+Add paragraph:
+
    
+
+
    
+Returns: an iterator which refers to the copy of the first inserted
+character, or p if il is empty.
+
    
+
 
 
 
    Rationale:
    
-
    The issue was discussed at length. It was generally agreed that 1)
-There is no major technical argument against the change (although
-there is a minor argument that some obscure programs may break), and
-2) Such a change would not break const correctness. The concerns about
-making the change were 1) it is user detectable (although only in
-boundary cases), 2) it changes a large number of signatures, and 3) it
-seems more of a design issue that an out-and-out defect.
    
 
-
    The LWG believes that this issue should be considered as part of a
-general review of const issues for the next revision of the
-standard. Also see issue 200.
    
+
    [
+The following was the C++98/03 rationale and does not necessarily apply to the
+proposed resolution in the C++0X time frame:
+]
    
+
+
+
    
+
    The LWG believes this was an intentional design decision and so is
+not a defect. It may be worth revisiting for the next standard.
    
+
    
 
 
 
 
 
    
 
    190. min() and max() functions should be std::binary_functions
    
-
    Section: 25.3.7 [alg.min.max] Status: Open
- Submitter: Mark Rintoul Date: 1999-08-26
    
+
    Section: 25.5.7 [alg.min.max] Status: Open
+ Submitter: Mark Rintoul Opened: 1999-08-26  Last modified: 2008-03-14
    
+
    View other active issues in [alg.min.max].
    
 
    View all other issues in [alg.min.max].
    
 
    View all issues with Open status.
    
 
    Discussion:
    
@@ -1334,10 +1783,67 @@ function objects.
    
 
 
 
+
    
+
    219. find algorithm missing version that takes a binary predicate argument
    
+
    Section: 25.3.5 [alg.find] Status: Open
+ Submitter: Pablo Halpern Opened: 2000-03-06  Last modified: 2009-03-09
    
+
    View all other issues in [alg.find].
    
+
    View all issues with Open status.
    
+
    Discussion:
    
+
    The find function always searches for a value using operator== to compare the
+value argument to each element in the input iterator range. This is inconsistent
+with other find-related functions such as find_end and find_first_of, which
+allow the caller to specify a binary predicate object to be used for determining
+equality. The fact that this can be accomplished using a combination of find_if
+and bind_1st or bind_2nd does not negate the desirability of a consistent,
+simple, alternative interface to find.
    
+
+
    [
+Summit:
+]
    
+
+
+
    
+Reopened by Alisdair.
+
    
+
+
+
+
    Proposed resolution:
    
+
    
+
    In section 25.3.5 [alg.find], add a second prototype for find
+(between the existing prototype and the prototype for find_if), as
+follows:
    
+
        template<class InputIterator, class T, class BinaryPredicate>
+      InputIterator find(InputIterator first, InputIterator last,
+                         const T& value, BinaryPredicate bin_pred);
    
+
    Change the description of the return from:
    
+
    
+  
    Returns: The first iterator i in the range [first, last) for which the following corresponding
+  conditions hold: *i == value, pred(*i) != false. Returns last if no such iterator is found.
    
+
    
+
     to:
    
+
    
+  
    Returns: The first iterator i in the range [first, last) for which the following 
+  corresponding condition holds: *i == value, bin_pred(*i,value) != false, pred(*)
+  != false. Return last if no such iterator is found.
    
+
    
+
    
+
+
+
    Rationale:
    
+
    This is request for a pure extension, so it is not a defect in the
+current standard.  As the submitter pointed out, "this can
+be accomplished using a combination of find_if and bind_1st or
+bind_2nd".
    
+
+
+
+
 
    
 
    255. Why do basic_streambuf<>::pbump() and gbump() take an int?
    
-
    Section: 27.5.2 [streambuf] Status: Open
- Submitter: Martin Sebor Date: 2000-08-12
    
+
    Section: 27.6.2 [streambuf] Status: Open
+ Submitter: Martin Sebor Opened: 2000-08-12  Last modified: 2007-01-15
    
 
    View all other issues in [streambuf].
    
 
    View all issues with Open status.
    
 
    Discussion:
    
@@ -1415,8 +1921,9 @@ signature.
    
 
 
    
 
    290. Requirements to for_each and its function object
    
-
    Section: 25.1.4 [alg.foreach] Status: Open
- Submitter: Angelika Langer Date: 2001-01-03
    
+
    Section: 25.3.4 [alg.foreach] Status: Open
+ Submitter: Angelika Langer Opened: 2001-01-03  Last modified: 2006-12-27
    
+
    View other active issues in [alg.foreach].
    
 
    View all other issues in [alg.foreach].
    
 
    View all issues with Open status.
    
 
    Discussion:
    
@@ -1459,134 +1966,17 @@ algorithm does not say so.
 
 
 
-
    
-
    299. Incorrect return types for iterator dereference
    
-
    Section: 24.1.4 [bidirectional.iterators], 24.1.5 [random.access.iterators] Status: Open
- Submitter: John Potter Date: 2001-01-22
    
-
    View all other issues in [bidirectional.iterators].
    
-
    View all issues with Open status.
    
-
    Discussion:
    
-
    
-In section 24.1.4 [bidirectional.iterators],
-Table 75 gives the return type of *r-- as convertible to T.  This is
-not consistent with Table 74 which gives the return type of *r++ as
-T&.  *r++ = t is valid while *r-- = t is invalid.
-
    
-
-
    
-In section 24.1.5 [random.access.iterators],
-Table 76 gives the return type of a[n] as convertible to T.  This is
-not consistent with the semantics of *(a + n) which returns T& by
-Table 74.  *(a + n) = t is valid while a[n] = t is invalid.
-
    
-
-
    
-Discussion from the Copenhagen meeting: the first part is
-uncontroversial.  The second part, operator[] for Random Access
-Iterators, requires more thought.  There are reasonable arguments on
-both sides.  Return by value from operator[] enables some potentially
-useful iterators, e.g. a random access "iota iterator" (a.k.a
-"counting iterator" or "int iterator").  There isn't any obvious way
-to do this with return-by-reference, since the reference would be to a
-temporary.  On the other hand, reverse_iterator takes an
-arbitrary Random Access Iterator as template argument, and its
-operator[] returns by reference.  If we decided that the return type
-in Table 76 was correct, we would have to change
-reverse_iterator.  This change would probably affect user
-code.
-
    
-
-
    
-History: the contradiction between reverse_iterator and the
-Random Access Iterator requirements has been present from an early
-stage.  In both the STL proposal adopted by the committee
-(N0527==94-0140) and the STL technical report (HPL-95-11 (R.1), by
-Stepanov and Lee), the Random Access Iterator requirements say that
-operator[]'s return value is "convertible to T".  In N0527
-reverse_iterator's operator[] returns by value, but in HPL-95-11
-(R.1), and in the STL implementation that HP released to the public,
-reverse_iterator's operator[] returns by reference.  In 1995, the
-standard was amended to reflect the contents of HPL-95-11 (R.1).  The
-original intent for operator[] is unclear.
-
    
-
-
    
-In the long term it may be desirable to add more fine-grained 
-iterator requirements, so that access method and traversal strategy
-can be decoupled.  (See "Improved Iterator Categories and
-Requirements", N1297 = 01-0011, by Jeremy Siek.)  Any decisions
-about issue 299 should keep this possibility in mind.
-
    
-
-
    Further discussion: I propose a compromise between John Potter's
-resolution, which requires T& as the return type of
-a[n], and the current wording, which requires convertible to
-T. The compromise is to keep the convertible to T
-for the return type of the expression a[n], but to also add
-a[n] = t as a valid expression. This compromise "saves" the
-common case uses of random access iterators, while at the same time
-allowing iterators such as counting iterator and caching file
-iterators to remain random access iterators (iterators where the
-lifetime of the object returned by operator*() is tied to the
-lifetime of the iterator).
-
    
-
-
    
-Note that the compromise resolution necessitates a change to
-reverse_iterator. It would need to use a proxy to support
-a[n] = t.
-
    
-
-
    
-Note also there is one kind of mutable random access iterator that
-will no longer meet the new requirements. Currently, iterators that
-return an r-value from operator[] meet the requirements for a
-mutable random access iterartor, even though the expression a[n] =
-t will only modify a temporary that goes away. With this proposed
-resolution, a[n] = t will be required to have the same
-operational semantics as *(a + n) = t.
-
    
-
-
-
-
    Proposed resolution:
    
-
-
    
-In section 24.1.4 [lib.bidirectdional.iterators], change the return
-type in table 75 from "convertible to T" to
-T&.
-
    
-
-
    
-In section 24.1.5 [lib.random.access.iterators], change the
-operational semantics for a[n] to " the r-value of
-a[n] is equivalent to the r-value of *(a +
-n)". Add a new row in the table for the expression a[n] = t
-with a return type of convertible to T and operational semantics of
-*(a + n) = t.
-
    
-
-
    [Lillehammer: Real problem, but should be addressed as part of
-  iterator redesign]
    
-
-
-
-
-
-
-
-
 
    
 
    309. Does sentry catch exceptions?
    
-
    Section: 27.6 [iostream.format] Status: Open
- Submitter: Martin Sebor Date: 2001-03-19
    
+
    Section: 27.7 [iostream.format] Status: Open
+ Submitter: Martin Sebor Opened: 2001-03-19  Last modified: 2006-12-27
    
 
    View all other issues in [iostream.format].
    
 
    View all issues with Open status.
    
 
    Discussion:
    
 
    
 The descriptions of the constructors of basic_istream<>::sentry
-(27.6.1.1.3 [istream::sentry]) and basic_ostream<>::sentry
-(27.6.2.4 [ostream::sentry]) do not explain what the functions do in
+(27.7.1.1.3 [istream::sentry]) and basic_ostream<>::sentry
+(27.7.2.4 [ostream::sentry]) do not explain what the functions do in
 case an exception is thrown while they execute. Some current
 implementations allow all exceptions to propagate, others catch them
 and set ios_base::badbit instead, still others catch some but let
@@ -1599,14 +1989,14 @@ The text also mentions that the functions may call setstate(failbit)
 argument is meant).  That may have been fine for
 basic_istream<>::sentry prior to issue 195, since
 the function performs an input operation which may fail. However,
-issue 195 amends 27.6.1.1.3 [istream::sentry], p2 to
+issue 195 amends 27.7.1.1.3 [istream::sentry], p2 to
 clarify that the function should actually call setstate(failbit |
 eofbit), so the sentence in p3 is redundant or even somewhat
 contradictory.
 
    
 
 
    
-The same sentence that appears in 27.6.2.4 [ostream::sentry], p3
+The same sentence that appears in 27.7.2.4 [ostream::sentry], p3
 doesn't seem to be very meaningful for basic_istream<>::sentry
 which performs no input. It is actually rather misleading since it
 would appear to guide library implementers to calling
@@ -1886,15 +2276,15 @@ committee.
 
 
    
 
    342. seek and eofbit
    
-
    Section: 27.6.1.3 [istream.unformatted] Status: Open
- Submitter: Howard Hinnant Date: 2001-10-09
    
+
    Section: 27.7.1.3 [istream.unformatted] Status: Open
+ Submitter: Howard Hinnant Opened: 2001-10-09  Last modified: 2007-01-15
    
 
    View all other issues in [istream.unformatted].
    
 
    View all issues with Open status.
    
 
    Discussion:
    
 
    I think we have a defect.
    
 
 
    According to lwg issue 60 which is now a dr, the
-description of seekg in 27.6.1.3 [istream.unformatted] paragraph 38 now looks
+description of seekg in 27.7.1.3 [istream.unformatted] paragraph 38 now looks
 like:
    
 
 
    
@@ -1972,7 +2362,7 @@ you can never seek away from the end of stream.

    • Proposed resolution:

    -

    Change 27.6.1.3 [istream.unformatted] to:

    +

    Change 27.7.1.3 [istream.unformatted] to:

    Behaves as an unformatted input function (as described in 27.6.1.3, paragraph 1), except that it does not count the number of characters @@ -2004,9 +2394,10 @@ In case of failure, the function calls setstate(failbit)

    343. Unspecified library header dependencies

    -

    Section: 21 [strings], 23 [containers], 27 [input.output] Status: Open - Submitter: Martin Sebor Date: 2001-10-09

    -

    View all other issues in [strings].

    +

    Section: 17 [library] Status: Open + Submitter: Martin Sebor Opened: 2001-10-09 Last modified: 2009-03-11

    +

    View other active issues in [library].

    +

    View all other issues in [library].

    View all issues with Open status.

    Discussion:

    @@ -2242,8 +2633,9 @@ Hinnant: It's time we dealt with this issue for C++0X. Reopened.

    382. codecvt do_in/out result

    -

    Section: 22.2.1.4 [locale.codecvt] Status: Open - Submitter: Martin Sebor Date: 2002-08-30

    +

    Section: 22.4.1.4 [locale.codecvt] Status: Open + Submitter: Martin Sebor Opened: 2002-08-30 Last modified: 2007-01-15

    +

    View other active issues in [locale.codecvt].

    View all other issues in [locale.codecvt].

    View all issues with Open status.

    Discussion:

    @@ -2271,7 +2663,7 @@ the following seems less than adequately specified:
    1. - 22.2.1.4.2 [locale.codecvt.virtuals], p2 says this about the effects of the + 22.4.1.4.2 [locale.codecvt.virtuals], p2 says this about the effects of the function: ...Stops if it encounters a character it cannot convert... This assumes that there *is* a character to convert. What happens when there is a sequence that doesn't form a @@ -2304,7 +2696,7 @@ the following seems less than adequately specified:

    -Finally, the conditions described at the end of 22.2.1.4.2 [locale.codecvt.virtuals], p4 don't seem to be possible: +Finally, the conditions described at the end of 22.4.1.4.2 [locale.codecvt.virtuals], p4 don't seem to be possible:

    "A return value of partial, if (from_next == from_end), @@ -2318,7 +2710,7 @@ If the value is partial, it's not clear to me that (from_next ==from_end) could ever hold if there isn't enough room in the destination buffer. In order for (from_next==from_end) to hold, all characters in that range must have been successfully -converted (according to 22.2.1.4.2 [locale.codecvt.virtuals], p2) and since there are no +converted (according to 22.4.1.4.2 [locale.codecvt.virtuals], p2) and since there are no further source characters to convert, no more room in the destination buffer can be needed.

    @@ -2362,167 +2754,10 @@ partial can only occur if (from_next != from_end)? -
    -

    387. std::complex over-encapsulated

    -

    Section: 26.3 [complex.numbers] Status: Ready - Submitter: Gabriel Dos Reis Date: 2002-11-08

    -

    View all other issues in [complex.numbers].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -The absence of explicit description of std::complex<T> layout -makes it imposible to reuse existing software developed in traditional -languages like Fortran or C with unambigous and commonly accepted -layout assumptions. There ought to be a way for practitioners to -predict with confidence the layout of std::complex<T> whenever T -is a numerical datatype. The absence of ways to access individual -parts of a std::complex<T> object as lvalues unduly promotes -severe pessimizations. For example, the only way to change, -independently, the real and imaginary parts is to write something like -

    - -
    complex<T> z;
-// ...
-// set the real part to r
-z = complex<T>(r, z.imag());
-// ...
-// set the imaginary part to i
-z = complex<T>(z.real(), i);
-
    - -

    -At this point, it seems appropriate to recall that a complex number -is, in effect, just a pair of numbers with no particular invariant to -maintain. Existing practice in numerical computations has it that a -complex number datatype is usually represented by Cartesian -coordinates. Therefore the over-encapsulation put in the specification -of std::complex<> is not justified. -

    - - - -

    Proposed resolution:

    -

    Add the following requirements to 26.3 [complex.numbers] as 26.3/4:

    -
    -

    If z is an lvalue expression of type cv std::complex<T> then

    - -
      -
    • the expression reinterpret_cast<cv T(&)[2]>(z) -is well-formed; and
      • -
    • reinterpret_cast<cv T(&)[2]>(z)[0]designates the -real part of z; and
      • -
    • reinterpret_cast<cv T(&)[2]>(z)[1]designates the -imaginary part of z.
      • -
    - -

    -Moreover, if a is an expression of pointer type cv complex<T>* -and the expression a[i] is well-defined for an integer expression -i then: -

    - -
      -
    • reinterpret_cast<cv T*>(a)[2*i] designates the real -part of a[i]; and
      • -
    • reinterpret_cast<cv T*>(a)[2*i+1] designates the -imaginary part of a[i].
      • -
    -
    - -

    -In 26.3.2 [complex] and 26.3.3 [complex.special] add the following member functions -(changing T to concrete types as appropriate for the specializations). -

    - -
    void real(T);
-void imag(T);
-
    - -

    -Add to 26.3.4 [complex.members] -

    - -
    -
    T real() const;
-
    -
    -Returns: the value of the real component -
    -
    void real(T val);
-
    -
    -Assigns val to the real component. -
    -
    T imag() const;
-
    -
    -Returns: the value of the imaginary component -
    -
    void imag(T val);
-
    -
    -Assigns val to the imaginary component. -
    -
    - -

    [Kona: The layout guarantee is absolutely necessary for C - compatibility. However, there was disagreement about the other part - of this proposal: retrieving elements of the complex number as - lvalues. An alternative: continue to have real() and imag() return - rvalues, but add set_real() and set_imag(). Straw poll: return - lvalues - 2, add setter functions - 5. Related issue: do we want - reinterpret_cast as the interface for converting a complex to an - array of two reals, or do we want to provide a more explicit way of - doing it? Howard will try to resolve this issue for the next - meeting.]

    - - -

    [pre-Sydney: Howard summarized the options in n1589.]

    - - -

    [ -Bellevue: -]

    - - -
    -Second half of proposed wording replaced and moved to Ready. -
    - -

    [ -Pre-Sophia Antipolis, Howard adds: -]

    - - -
    -Added the members to 26.3.3 [complex.special] and changed from Ready to Review. -
    - -

    [ -Post-Sophia Antipolis: -]

    - - -
    -Moved from WP back to Ready so that the "and 26.3.3 [complex.special]" in the proposed -resolution can be officially applied. -
    - - - -

    Rationale:

    -

    The LWG believes that C99 compatibility would be enough -justification for this change even without other considerations. All -existing implementations already have the layout proposed here.

    - - - - -

    394. behavior of formatted output on failure

    -

    Section: 27.6.2.6.1 [ostream.formatted.reqmts] Status: Open - Submitter: Martin Sebor Date: 2002-12-27

    +

    Section: 27.7.2.6.1 [ostream.formatted.reqmts] Status: Open + Submitter: Martin Sebor Opened: 2002-12-27 Last modified: 2007-01-15

    View all issues with Open status.

    Discussion:

    @@ -2624,144 +2859,10 @@ functions should be changed as proposed below. -

    -

    396. what are characters zero and one

    -

    Section: 23.3.5.1 [bitset.cons] Status: Ready - Submitter: Martin Sebor Date: 2003-01-05

    -

    View all other issues in [bitset.cons].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -23.3.5.1, p6 [lib.bitset.cons] talks about a generic character -having the value of 0 or 1 but there is no definition of what -that means for charT other than char and wchar_t. And even for -those two types, the values 0 and 1 are not actually what is -intended -- the values '0' and '1' are. This, along with the -converse problem in the description of to_string() in 23.3.5.2, -p33, looks like a defect remotely related to DR 303. -

    -

    -http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#303 -

    - 
    23.3.5.1:
-  -6-  An element of the constructed string has value zero if the
-       corresponding character in str, beginning at position pos,
-       is 0. Otherwise, the element has the value one.
-
    - 
    23.3.5.2:
-  -33-  Effects: Constructs a string object of the appropriate
-        type and initializes it to a string of length N characters.
-        Each character is determined by the value of its
-        corresponding bit position in *this. Character position N
-        ?- 1 corresponds to bit position zero. Subsequent decreasing
-        character positions correspond to increasing bit positions.
-        Bit value zero becomes the character 0, bit value one becomes
-        the character 1.
-
    -

    -Also note the typo in 23.3.5.1, p6: the object under construction -is a bitset, not a string. -

    - -

    [ -Sophia Antipolis: -]

    - - -
    -

    -We note that bitset has been moved from section 23 to section 20, by -another issue (842) previously resolved at this meeting. -

    -

    -Disposition: move to ready. -

    -

    -We request that Howard submit a separate issue regarding the three to_string overloads. -

    -
    - - - -

    Proposed resolution:

    -

    Change the constructor's function declaration immediately before -23.3.5.1 [bitset.cons] p3 to:

    -
        template <class charT, class traits, class Allocator>
-    explicit
-    bitset(const basic_string<charT, traits, Allocator>& str,
-           typename basic_string<charT, traits, Allocator>::size_type pos = 0,
-           typename basic_string<charT, traits, Allocator>::size_type n =
-             basic_string<charT, traits, Allocator>::npos,
-           charT zero = charT('0'), charT one = charT('1'))
-
    -

    Change the first two sentences of 23.3.5.1 [bitset.cons] p6 to: "An -element of the constructed string has value 0 if the corresponding -character in str, beginning at position pos, -is zero. Otherwise, the element has the value 1.

    - -

    Change the text of the second sentence in 23.3.5.1, p5 to read: - "The function then throws invalid_argument if any of the rlen - characters in str beginning at position pos is other than zero - or one. The function uses traits::eq() to compare the character - values." -

    - -

    Change the declaration of the to_string member function - immediately before 23.3.5.2 [bitset.members] p33 to:

    -
        template <class charT, class traits, class Allocator>
-    basic_string<charT, traits, Allocator> 
-    to_string(charT zero = charT('0'), charT one = charT('1')) const;
-
    -

    Change the last sentence of 23.3.5.2 [bitset.members] p33 to: "Bit - value 0 becomes the character zero, bit value 1 becomes the - character one.

    -

    Change 23.3.5.3 [bitset.operators] p8 to:

    -

    Returns:

    -
      os << x.template to_string<charT,traits,allocator<charT> >(
-      use_facet<ctype<charT> >(os.getloc()).widen('0'),
-      use_facet<ctype<charT> >(os.getloc()).widen('1'));
-
    - - -

    Rationale:

    -

    There is a real problem here: we need the character values of '0' - and '1', and we have no way to get them since strings don't have - imbued locales. In principle the "right" solution would be to - provide an extra object, either a ctype facet or a full locale, - which would be used to widen '0' and '1'. However, there was some - discomfort about using such a heavyweight mechanism. The proposed - resolution allows those users who care about this issue to get it - right.

    -

    We fix the inserter to use the new arguments. Note that we already - fixed the analogous problem with the extractor in issue 303.

    - - - -

    [ -post Bellevue: -]

    - - -
    -We are happy with the resolution as proposed, and we move this to Ready. -
    - -

    [ -Howard adds: -]

    - - -
    -The proposed wording neglects the 3 newer to_string overloads. -
    - - - -

    397. ostream::sentry dtor throws exceptions

    -

    Section: 27.6.2.4 [ostream::sentry] Status: Open - Submitter: Martin Sebor Date: 2003-01-05

    +

    Section: 27.7.2.4 [ostream::sentry] Status: Open + Submitter: Martin Sebor Opened: 2003-01-05 Last modified: 2007-07-25

    View other active issues in [ostream::sentry].

    View all other issues in [ostream::sentry].

    View all issues with Open status.

    @@ -2812,8 +2913,8 @@ See 41

    398. effects of end-of-file on unformatted input functions

    -

    Section: 27.6.2.4 [ostream::sentry] Status: Open - Submitter: Martin Sebor Date: 2003-01-05

    +

    Section: 27.7.2.4 [ostream::sentry] Status: Open + Submitter: Martin Sebor Opened: 2003-01-05 Last modified: 2007-01-15

    View other active issues in [ostream::sentry].

    View all other issues in [ostream::sentry].

    View all issues with Open status.

    @@ -2915,10 +3016,10 @@ end-of-file):

    408. Is vector<reverse_iterator<char*> > forbidden?

    -

    Section: 24.1 [iterator.requirements] Status: Open - Submitter: Nathan Myers Date: 2003-06-03

    -

    View other active issues in [iterator.requirements].

    -

    View all other issues in [iterator.requirements].

    +

    Section: 24.2 [iterator.concepts] Status: Open + Submitter: Nathan Myers Opened: 2003-06-03 Last modified: 2009-05-10

    +

    View other active issues in [iterator.concepts].

    +

    View all other issues in [iterator.concepts].

    View all issues with Open status.

    Discussion:

    @@ -2927,7 +3028,7 @@ surprise has popped up. I don't think this has been discussed before.

    -24.1 [iterator.requirements] says that the only operation that can be performed on "singular" +24.2 [iterator.concepts] says that the only operation that can be performed on "singular" iterator values is to assign a non-singular value to them. (It doesn't say they can be destroyed, and that's probably a defect.) Some implementations have taken this to imply that there is no need @@ -3025,7 +3126,7 @@ are default-initialized, and it should explicitly allow destroying any iterator value, singular or not, default-initialized or not.

    -

    Related issue: 407

    +

    Related issues: 407, 1012

    [ We don't want to require all singular iterators to be copyable, because that is not the case for pointers. However, default @@ -3037,9 +3138,31 @@ wrong to impose so strict a requirement for iterators. ]

    +

    [ +2009-05-10 Alisdair provided wording. +]

    + + +
    +The comments regarding destroying singular iterators have already been +resolved. That just leaves copying (with moving implied). +
    +

    Proposed resolution:

    +

    +Add to the end of Iterator concepts 24.2 [iterator.concepts] para 6 (the one +describing singular iterators) +

    +
    +Any Iterator that satisfies the DefaultConstructible concept shall +be safely copyable after value-initialization, even if it would otherwise be +singular. [Note: This guarantee is not offered for default-initialization +(8.5 [dcl.init]), although the distinction only matters for types with +trivial default constructors such as pointers. — end note] +
    + @@ -3047,8 +3170,8 @@ wrong to impose so strict a requirement for iterators.

    417. what does ctype::do_widen() return on failure

    -

    Section: 22.2.1.1.2 [locale.ctype.virtuals] Status: Open - Submitter: Martin Sebor Date: 2003-09-18

    +

    Section: 22.4.1.1.2 [locale.ctype.virtuals] Status: Open + Submitter: Martin Sebor Opened: 2003-09-18 Last modified: 2006-12-27

    View all other issues in [locale.ctype.virtuals].

    View all issues with Open status.

    Discussion:

    @@ -3081,8 +3204,10 @@ and iostream to reliably detect this failure.

    418. exceptions thrown during iostream cleanup

    -

    Section: 27.4.2.1.6 [ios::Init] Status: Open - Submitter: Martin Sebor Date: 2003-09-18

    +

    Section: 27.5.2.1.6 [ios::Init] Status: Open + Submitter: Martin Sebor Opened: 2003-09-18 Last modified: 2007-07-25

    +

    View other active issues in [ios::Init].

    +

    View all other issues in [ios::Init].

    View all issues with Open status.

    Discussion:

    @@ -3124,16 +3249,16 @@ See 39

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

    -

    Section: 27.6.1.1.3 [istream::sentry] Status: Open - Submitter: Martin Sebor Date: 2003-09-18

    +

    Section: 27.7.1.1.3 [istream::sentry] Status: Open + Submitter: Martin Sebor Opened: 2003-09-18 Last modified: 2007-01-30

    View all other issues in [istream::sentry].

    View all issues with Open status.

    Discussion:

    -27.6.1.1.3 [istream::sentry], p2 says that istream::sentry ctor prepares for input if is.good() +27.7.1.1.3 [istream::sentry], p2 says that istream::sentry ctor prepares for input if is.good() is true. p4 then goes on to say that the ctor sets the sentry::ok_ member to -true if the stream state is good after any preparation. 27.6.1.2.1 [istream.formatted.reqmts], p1 then +true if the stream state is good after any preparation. 27.7.1.2.1 [istream.formatted.reqmts], p1 then says that a formatted input function endeavors to obtain the requested input if the sentry's operator bool() returns true. @@ -3213,7 +3338,7 @@ you can never seek away from the end of stream.

    Proposed resolution:

    -Change 27.6.1.1.3 [istream::sentry], p2 to: +Change 27.7.1.1.3 [istream::sentry], p2 to:

    @@ -3232,8 +3357,8 @@ Otherwise prepares for formatted or unformatted input. ...

    421. is basic_streambuf copy-constructible?

    -

    Section: 27.5.2.1 [streambuf.cons] Status: Open - Submitter: Martin Sebor Date: 2003-09-18

    +

    Section: 27.6.2.1 [streambuf.cons] Status: Open + Submitter: Martin Sebor Opened: 2003-09-18 Last modified: 2007-01-15

    View all other issues in [streambuf.cons].

    View all issues with Open status.

    Discussion:

    @@ -3434,7 +3559,8 @@ basic_filebuf.

    423. effects of negative streamsize in iostreams

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

    + Submitter: Martin Sebor Opened: 2003-09-18 Last modified: 2006-12-27

    +

    View other active issues in [input.output].

    View all other issues in [input.output].

    View all issues with Open status.

    Discussion:

    @@ -3473,10 +3599,121 @@ ostream::write(). +
    +

    424. normative notes

    +

    Section: 17.5.1.2 [structure.summary] Status: Tentatively NAD Editorial + Submitter: Martin Sebor Opened: 2003-09-18 Last modified: 2009-05-23

    +

    View all issues with Tentatively NAD Editorial status.

    +

    Discussion:

    + +

    +The text in 17.3.1.1, p1 says: +
    + +"Paragraphs labelled "Note(s):" or "Example(s):" are informative, other +paragraphs are normative." +
    + +The library section makes heavy use of paragraphs labeled "Notes(s)," +some of which are clearly intended to be normative (see list 1), while +some others are not (see list 2). There are also those where the intent +is not so clear (see list 3). +

    + +List 1 -- Examples of (presumably) normative Notes: +
    + +20.8.6.1 [allocator.members], p3,
    +20.8.6.1 [allocator.members], p10,
    +21.4.2 [string.cons], p11,
    +22.3.1.2 [locale.cons], p11,
    +23.3.2.3 [deque.modifiers], p2,
    +25.5.7 [alg.min.max], p3,
    +26.4.6 [complex.ops], p15,
    +27.6.2.4.3 [streambuf.virt.get], p7.
    +
    + +List 2 -- Examples of (presumably) informative Notes: +
    + +18.6.1.3 [new.delete.placement], p3,
    +21.4.6.6 [string::replace], p14,
    +22.4.1.4.2 [locale.codecvt.virtuals], p3,
    +25.3.4 [alg.foreach], p4,
    +26.4.5 [complex.member.ops], p1,
    +27.5.2.5 [ios.base.storage], p6.
    +
    + +List 3 -- Examples of Notes that are not clearly either normative +or informative: +
    + +22.3.1.2 [locale.cons], p8,
    +22.3.1.5 [locale.statics], p6,
    +27.6.2.4.5 [streambuf.virt.put], p4.
    +
    + +None of these lists is meant to be exhaustive. +

    + +

    [Definitely a real problem. The big problem is there's material + that doesn't quite fit any of the named paragraph categories + (e.g. Effects). Either we need a new kind of named + paragraph, or we need to put more material in unnamed paragraphs + jsut after the signature. We need to talk to the Project Editor + about how to do this. +]

    + + +

    [ +Bellevue: Specifics of list 3: First 2 items correct in std (22.1.1.2, +22.1.1.5) Third item should be non-normative (27.5.2.4.5), which Pete +will handle editorially. +]

    + + +

    [ +post San Francisco: Howard: reopened, needs attention. +]

    + + +

    [Pete: I changed the paragraphs marked "Note" and "Notes" to use "Remark" and "Remarks". +Fixed as editorial. This change has been in the WD since the post-Redmond mailing, in 2004. +Recommend NAD.]

    + + +

    [ +Batavia: We feel that the references in List 2 above should be changed from Remarks +to Notes. We also feel that those items in List 3 need to be double checked for +the same change. Alan and Pete to review. +]

    + + +

    [ +Batavia (2009-05): +]

    + +
    +

    +A spot-check of List 2 suggests the issue is still relevant, +and a review of List 3 still seems called-for. +

    +

    +Move to NAD Editorial. +

    +
    + + + +

    Proposed resolution:

    + + + +

    427. stage 2 and rationale of DR 221

    -

    Section: 22.2.2.1.2 [facet.num.get.virtuals] Status: Open - Submitter: Martin Sebor Date: 2003-09-18

    +

    Section: 22.4.2.1.2 [facet.num.get.virtuals] Status: Open + Submitter: Martin Sebor Opened: 2003-09-18 Last modified: 2007-01-15

    View other active issues in [facet.num.get.virtuals].

    View all other issues in [facet.num.get.virtuals].

    View all issues with Open status.

    @@ -3535,8 +3772,8 @@ use char_traits<charT>.

    430. valarray subset operations

    -

    Section: 26.5.2.4 [valarray.sub] Status: Open - Submitter: Martin Sebor Date: 2003-09-18

    +

    Section: 26.6.2.4 [valarray.sub] Status: Open + Submitter: Martin Sebor Opened: 2003-09-18 Last modified: 2009-05-01

    View all issues with Open status.

    Discussion:

    @@ -3571,7 +3808,7 @@ post-Bellevue: Bill provided wording.

    Proposed resolution:

    -Insert after 26.5.2.4 [valarray.sub], paragraph 1: +Insert after 26.6.2.4 [valarray.sub], paragraph 1:

    @@ -3674,7 +3911,7 @@ const size_t lv[] = {2, 3}; const size_t dv[] = {7, 2}; const valarray<size_t> len(lv, 2), str(dv, 2); // v0[gslice(3, len, str)] returns -//    valarray<char>("dfhkmo", 6) +// valarray<char>("dfhkmo", 6)

    @@ -3685,7 +3922,7 @@ designated by boolarr. For example: 

    valarray<char> v0("abcdefghijklmnop", 16);
 const bool vb[] = {false, false, true, true, false, true};
 // v0[valarray<bool>(vb, 6)] returns
-//    valarray<char>("cdf", 3)
+//    valarray<char>("cdf", 3)

    @@ -3707,13 +3944,13 @@ const size_t vi[] = {7, 5, 2, 3, 8};

    431. Swapping containers with unequal allocators

    -

    Section: 20.1.2 [allocator.requirements], 25 [algorithms] Status: Open - Submitter: Matt Austern Date: 2003-09-20

    +

    Section: X [allocator.requirements], 25 [algorithms] Status: Open + Submitter: Matt Austern Opened: 2003-09-20 Last modified: 2009-05-01

    View other active issues in [allocator.requirements].

    View all other issues in [allocator.requirements].

    View all issues with Open status.

    Discussion:

    -

    Clause 20.1.2 [allocator.requirements] paragraph 4 says that implementations +

    Clause X [allocator.requirements] paragraph 4 says that implementations are permitted to supply containers that are unable to cope with allocator instances and that container implementations may assume that all instances of an allocator type compare equal. We gave @@ -3774,6 +4011,29 @@ swap allocators, else it will perform a "slow swap" using copy construction and ]

    +

    [ +2009-04-28 Pablo adds: +]

    + +
    +Fixed in +N2525. +I argued for marking this Tentatively-Ready right after Bellevue, +but there was a concern that +N2525 +would break in the presence of the RVO. (That breakage had nothing to do with +swap, but never-the-less). I addressed that breakage in in +N2840 +(Summit) my means of a non-normative reference: + +
    +[Note: in situations where the copy constructor for a container is elided, +this function is not called. The behavior in these cases is as if +select_on_container_copy_construction returned x — end note] +
    + +
    +

    Proposed resolution:

    @@ -3784,10 +4044,10 @@ swap allocators, else it will perform a "slow swap" using copy construction and

    446. Iterator equality between different containers

    -

    Section: 24.1 [iterator.requirements], 23.1 [container.requirements] Status: Open - Submitter: Andy Koenig Date: 2003-12-16

    -

    View other active issues in [iterator.requirements].

    -

    View all other issues in [iterator.requirements].

    +

    Section: 24.2 [iterator.concepts], 23.2 [container.requirements] Status: Open + Submitter: Andy Koenig Opened: 2003-12-16 Last modified: 2008-09-30

    +

    View other active issues in [iterator.concepts].

    +

    View all other issues in [iterator.concepts].

    View all issues with Open status.

    Discussion:

    @@ -3820,200 +4080,19 @@ reachability. -

    -

    454. basic_filebuf::open should accept wchar_t names

    -

    Section: 27.8.1.4 [filebuf.members] Status: Open - Submitter: Bill Plauger Date: 2004-01-30

    -

    View all other issues in [filebuf.members].

    -

    View all issues with Open status.

    -

    Duplicate of: 105

    -

    Discussion:

    -
        basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode);
-
    - -

    should be supplemented with the overload:

    - -
        basic_filebuf *basic_filebuf::open(const wchar_t *, ios_base::open_mode);
-
    - -

    -Depending on the operating system, one of these forms is fundamental and -the other requires an implementation-defined mapping to determine the -actual filename. -

    - -

    [Sydney: Yes, we want to allow wchar_t filenames. Bill will - provide wording.]

    - - -

    [ -In Toronto we noted that this is issue 5 from -N1569. -]

    - -

    -How does this interact with the newly-defined character types, and how -do we avoid interface explosion considering std::string overloads that -were added? Propose another solution that is different than the -suggestion proposed by PJP. -

    -

    -Suggestion is to make a member template function for basic_string (for -char, wchar_t, u16char, u32char instantiations), and then just keep a -const char* member. -

    -

    -Goal is to do implicit conversion between character string literals to -appropriate basic_string type. Not quite sure if this is possible. -

    -

    -Implementors are free to add specific overloads for non-char character -types. -

    - -

    [ -Martin adds pre-Sophia Antipolis: -]

    - - -
    -Please see issue 454: problems and solutions. -
    - -

    [ -Sophia Antipolis: -]

    - - -
    -

    -Beman is concerned that making these changes to basic_filebuf is not -usefully changed unless fstream is also changed; this also only handles -wchar_t and not other character types. -

    -

    -The TR2 filesystem library is a more complete solution, but is not available soon. -

    -
    - -

    [ -Martin adds: please reference -N2683 for -problems and solutions. -]

    - - - - -

    Proposed resolution:

    - -

    Change from:

    -
    -
    basic_filebuf<charT,traits>* open(
-	const char* s,
-	ios_base::openmode mode );
-
    - -

    -Effects: If is_open() != false, returns a null pointer. -Otherwise, initializes the filebuf as required. It then -opens a file, if possible, whose name is the NTBS s ("as if" -by calling std::fopen(s,modstr)).

    -
    - -

    to:

    - -
    -
    basic_filebuf<charT,traits>* open(
-	const char* s,
-	ios_base::openmode mode );
-
-basic_filebuf<charT,traits>* open(
-	const wchar_t* ws,
-	ios_base::openmode mode );
-
    - -

    -Effects: If is_open() != false, returns a null pointer. -Otherwise, initializes the filebuf as required. It then -opens a file, if possible, whose name is the NTBS s ("as if" -by calling std::fopen(s,modstr)). -For the second signature, the NTBS s is determined from the -WCBS ws in an implementation-defined manner. -

    - -

    -(NOTE: For a system that "naturally" represents a filename -as a WCBS, the NTBS s in the first signature may instead -be mapped to a WCBS; if so, it follows the same mapping -rules as the first argument to open.) -

    -
    - - - -

    Rationale:

    -

    -Slightly controversial, but by a 7-1 straw poll the LWG agreed to move -this to Ready. The controversy was because the mapping between wide -names and files in a filesystem is implementation defined. The -counterargument, which most but not all LWG members accepted, is that -the mapping between narrow files names and files is also -implemenation defined.

    - -

    [Lillehammer: Moved back to "open" status, at Beman's urging. -(1) Why just basic_filebuf, instead of also basic_fstream (and -possibly other things too). (2) Why not also constructors that take -std::basic_string? (3) We might want to wait until we see Beman's -filesystem library; we might decide that it obviates this.]

    - - -

    [ -post Bellevue: -]

    - - -
    -

    -Move again to Ready. -

    -

    -There is a timing issue here. Since the filesystem library will not be -in C++0x, this should be brought forward. This solution would remain -valid in the context of the proposed filesystem. -

    -

    -This issue has been kicking around for a while, and the wchar_t addition -alone would help many users. Thus, we suggest putting this on the -reflector list with an invitation for someone to produce proposed -wording that covers basic_fstream. In the meantime, we suggest that the -proposed wording be adopted as-is. -

    -

    -If more of the Lillehammer questions come back, they should be -introduced as separate issues. -

    -
    - - - - - - - -

    458. 24.1.5 contains unintented limitation for operator-

    -

    Section: 24.1.5 [random.access.iterators] Status: Open - Submitter: Daniel Frey Date: 2004-02-27

    +

    Section: 24.2.6 [random.access.iterators] Status: Tentatively NAD + Submitter: Daniel Frey Opened: 2004-02-27 Last modified: 2009-05-23

    +

    View other active issues in [random.access.iterators].

    View all other issues in [random.access.iterators].

    -

    View all issues with Open status.

    +

    View all issues with Tentatively NAD status.

    Discussion:

    In 24.1.5 [lib.random.access.iterators], table 76 the operational semantics for the expression "r -= n" are defined as "return r += -n". This means, that the expression -n must be valid, which is not the case -for unsigned types. +for unsigned types.

    [ @@ -4023,6 +4102,34 @@ be less clear than we would like. ]

    +

    [ +Post Summit Alisdair adds: +]

    + + +
    +

    +This issue refers to a requirements table we have removed. +

    +

    +The issue might now relate to 24.2.6 [random.access.iterators] p5. +However, the rationale in the issue already recognises that the +difference_type must be signed, so this really looks NAD. +

    +
    + +

    [ +Batavia (2009-05): +]

    + +
    +

    +We agree with Alisdair's observations. +

    +

    +Move to NAD. +

    +

    Proposed resolution:

    @@ -4030,10 +4137,10 @@ be less clear than we would like. To remove this limitation, I suggest to change the operational semantics for this column to:

    -
        { Distance m = n; 
-      if (m >= 0) 
-        while (m--) --r; 
-      else 
+
        { Distance m = n;
+      if (m >= 0)
+        while (m--) --r;
+      else
         while (m++) ++r;
       return r; }
 
    
@@ -4045,8 +4152,8 @@ operational semantics for this column to:
 
 
    
 
    459. Requirement for widening in stage 2 is overspecification
    
-
    Section: 22.2.2.1.2 [facet.num.get.virtuals] Status: Open
- Submitter: Martin Sebor Date: 2004-03-16
    
+
    Section: 22.4.2.1.2 [facet.num.get.virtuals] Status: Open
+ Submitter: Martin Sebor Opened: 2004-03-16  Last modified: 2006-12-27
    
 
    View other active issues in [facet.num.get.virtuals].
    
 
    View all other issues in [facet.num.get.virtuals].
    
 
    View all issues with Open status.
    
@@ -4099,7 +4206,7 @@ to
 their narrow equivalents (i.e., the portable source characters '0'
 through '9'), the change does not necessarily imply that these
 alternate digits would be treated as ordinary digits and accepted as
-part of numbers during parsing. In fact, the requirement in 22.2.1.1.2
+part of numbers during parsing. In fact, the requirement in 22.4.1.1.2
 [locale.ctype.virtuals], p13 forbids narrow() to translate an alternate
 digit character, wc, to an ordinary digit in the basic source
 character set unless the expression
@@ -4139,7 +4246,8 @@ technique to perform the comparison:
    
 
    
 
    463. auto_ptr usability issues
    
 
    Section: D.9.1 [auto.ptr] Status: Open
- Submitter: Rani Sharoni Date: 2003-12-07
    
+ Submitter: Rani Sharoni Opened: 2003-12-07  Last modified: 2007-11-15
    
+
    View other active issues in [auto.ptr].
    
 
    View all other issues in [auto.ptr].
    
 
    View all issues with Open status.
    
 
    Discussion:
    
@@ -4539,10 +4647,77 @@ The expression delete get() is well formed.
 
 
 
+
    
+
    466. basic_string ctor should prevent null pointer error
    
+
    Section: 21.4.1 [string.require] Status: Open
+ Submitter: Daniel Frey Opened: 2004-06-10  Last modified: 2009-05-23
    
+
    View other active issues in [string.require].
    
+
    View all other issues in [string.require].
    
+
    View all issues with Open status.
    
+
    Discussion:
    
+
    
+Today, my colleagues and me wasted a lot of time. After some time, I
+found the problem. It could be reduced to the following short example:
+
    
+
+
      #include <string>
+  int main() { std::string( 0 ); }
+
    
+
+
    The problem is that the tested compilers (GCC 2.95.2, GCC 3.3.1 and
+Comeau online) compile the above without errors or warnings! The
+programs (at least for the GCC) resulted in a SEGV.
    
+
+
    I know that the standard explicitly states that the ctor of string
+requires a char* which is not zero. STLs could easily detect the above
+case with a private ctor for basic_string which takes a single 'int'
+argument. This would catch the above code at compile time and would not
+ambiguate any other legal ctors.
    
+
+
    [Redmond: No great enthusiasm for doing this.  If we do,
+  however, we want to do it for all places that take charT*
+  pointers, not just the single-argument constructor.  The other
+  question is whether we want to catch this at compile time (in which
+  case we catch the error of a literal 0, but not an expression whose
+  value is a null pointer), at run time, or both.
+  Recommend NAD.  Relegate this functionality to debugging implementations.]
    
+
+
+
    [
+Post Summit: Alisdair requests this be re-opened as several new language facilities are
+designed to solve exactly this kind of problem.
+]
    
+
+
+
    [
+Batavia (2009-05):
+]
    
+
+
    
+We are unable to achieve consensus on an approach to a resolution.
+There is some sentiment for treating this as a QOI matter.
+It is also possible
+that when string is brought into the concepts world,
+this issue might be addressed in that context.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Add to the synopsis in 21.4 [basic.string]
+
    
+
+
    basic_string( nullptr_t ) = delete;
+
    
+
+
+
+
+
 
    
 
    471. result of what() implementation-defined
    
-
    Section: 18.6.1 [type.info] Status: Open
- Submitter: Martin Sebor Date: 2004-06-28
    
+
    Section: 18.7.1 [type.info] Status: Open
+ Submitter: Martin Sebor Opened: 2004-06-28  Last modified: 2009-05-23
    
 
    View all other issues in [type.info].
    
 
    View all issues with Open status.
    
 
    Discussion:
    
@@ -4625,16 +4800,34 @@ Sophia Antipolis:
 
 
    
 The issue was pulled from Ready.  It needs to make clear that only homogenous copying
-is intended to be supported.  Not coping from a dervied to a base.
+is intended to be supported, not coping from a derived to a base.
 
    
 
+
    [
+Batavia (2009-05):
+]
    
 
+
    
+
    
+Howard supplied the following replacement wording
+for paragraph 7 of the proposed resolution:
+
    
+
    
+-7- Postcondition: what() shall return the same NTBS
+  as would be obtained by using static_cast
+  to cast the rhs to the same types as the lhs
+  and then calling what() on that possibly sliced object.
+
    
+
    
+Pete asks what "the same NTBS" means.
+
    
+
    
 
 
 
    Proposed resolution:
    
 
 
    
-Change 18.7.1 [exception] to:
+Change 18.8.1 [exception] to:
 
    
 
 
    
@@ -4664,8 +4857,8 @@ to all standard library-defined classes that derive from exception.
 
    473. underspecified ctype calls
    
-
    Section: 22.2.1.1 [locale.ctype] Status: Open
- Submitter: Martin Sebor Date: 2004-07-01
    
+
    Section: 22.4.1.1 [locale.ctype] Status: Open
+ Submitter: Martin Sebor Opened: 2004-07-01  Last modified: 2006-12-27
    
 
    View all issues with Open status.
    
 
    Discussion:
    
 
    
@@ -4746,67 +4939,10 @@ provide wording.
    
 
 
 
-
    
-
    484. Convertible to T
    
-
    Section: 24.1.1 [input.iterators] Status: Open
- Submitter: Chris Jefferson Date: 2004-09-16
    
-
    View all other issues in [input.iterators].
    
-
    View all issues with Open status.
    
-
    Discussion:
    
-
    From comp.std.c++:
    
-
-
    
-I note that given an input iterator a for type T, 
-then *a only has to be "convertable to T", not actually of type T.
-
    
-
-
    Firstly, I can't seem to find an exact definition of "convertable to T". 
-While I assume it is the obvious definition (an implicit conversion), I 
-can't find an exact definition. Is there one?
    
-
-
    Slightly more worryingly, there doesn't seem to be any restriction on 
-the this type, other than it is "convertable to T". Consider two input 
-iterators a and b. I would personally assume that most people would 
-expect *a==*b would perform T(*a)==T(*b), however it doesn't seem that 
-the standard requires that, and that whatever type *a is (call it U) 
-could have == defined on it with totally different symantics and still 
-be a valid inputer iterator.
    
-
-
    Is this a correct reading? When using input iterators should I write 
-T(*a) all over the place to be sure that the object i'm using is the 
-class I expect?
    
-
-
    This is especially a nuisance for operations that are defined to be
-  "convertible to bool".  (This is probably allowed so that
-  implementations could return say an int and avoid an unnessary
-  conversion. However all implementations I have seen simply return a
-  bool anyway.  Typical implemtations of STL algorithms just write
-  things like while(a!=b && *a!=0).  But strictly
-  speaking, there are lots of types that are convertible to T but
-  that also overload the appropriate operators so this doesn't behave
-  as expected.
    
-
-
    If we want to make code like this legal (which most people seem to
-  expect), then we'll need to tighten up what we mean by "convertible
-  to T".
    
-
-
    [Lillehammer: The first part is NAD, since "convertible" is
- well-defined in core. The second part is basically about pathological
- overloads. It's a minor problem but a real one. So leave open for
- now, hope we solve it as part of iterator redesign.]
    
-
-
-
-
    Proposed resolution:
    
-
-
-
-
-
 
    
 
    485. output iterator insufficently constrained
    
-
    Section: 24.1.2 [output.iterators] Status: Open
- Submitter: Chris Jefferson Date: 2004-10-13
    
+
    Section: 24.2.3 [output.iterators] Status: Open
+ Submitter: Chris Jefferson Opened: 2004-10-13  Last modified: 2006-12-27
    
 
    View all other issues in [output.iterators].
    
 
    View all issues with Open status.
    
 
    Discussion:
    
@@ -4850,10 +4986,10 @@ wording (I believe) x,a,b,c could be written to in any order.
 
 
    
 
    492. Invalid iterator arithmetic expressions
    
-
    Section: 23 [containers], 24 [iterators], 25 [algorithms] Status: Open
- Submitter: Thomas Mang Date: 2004-12-12
    
-
    View other active issues in [containers].
    
-
    View all other issues in [containers].
    
+
    Section: 17.5.1.4 [structure.specifications] Status: Open
+ Submitter: Thomas Mang Opened: 2004-12-12  Last modified: 2009-05-10
    
+
    View other active issues in [structure.specifications].
    
+
    View all other issues in [structure.specifications].
    
 
    View all issues with Open status.
    
 
    Discussion:
    
 
    Various clauses other than clause 25 make use of iterator arithmetic not
@@ -5024,6 +5160,16 @@ Bellevue:
 Keep open and ask Bill to provide wording.
 
    
 
+
    [
+2009-05-09 Alisdair adds:
+]
    
+
+
+
    
+This issue is related to 997.
+
    
+
+
 
 
    Proposed resolution:
    
 
@@ -5040,8 +5186,8 @@ it doesn't cover. Bill will provide wording.]
    
 
 
    
 
    498. Requirements for partition() and stable_partition() too strong
    
-
    Section: 25.2.13 [alg.partitions] Status: Open
- Submitter: Sean Parent, Joe Gottman Date: 2005-05-04
    
+
    Section: 25.4.13 [alg.partitions] Status: Open
+ Submitter: Sean Parent, Joe Gottman Opened: 2005-05-04  Last modified: 2009-05-01
    
 
    View all issues with Open status.
    
 
    Discussion:
    
 
    
@@ -5055,6 +5201,62 @@ and
 http://www.sgi.com/tech/stl/stable_partition.html).
 
    
 
+
    [
+2009-04-30 Alisdair adds:
+]
    
+
+
+
    
+
    
+Now we have concepts this is easier to express!
+
    
+
    
+Proposed resolution:
+
    
+
    
+Add the following signature to:
+
    
+
    
+Header <algorithm> synopsis 25.2 [algorithms.syn]
    
+p3 Partitions 25.4.13 [alg.partitions]
+
    
+
     template<ForwardIterator Iter, Predicate<auto, Iter::value_type> Pred>
+   requires ShuffleIterator<Iter>
+         && CopyConstructible<Pred>
+   Iter partition(Iter first, Iter last, Pred pred);
+
    
+
+
    
+Update p3 Partitions 25.4.13 [alg.partitions]:
+
    
+
+
    
+
    
+Complexity: At most (last - first)/2 swaps. Exactly last - first
+applications of the predicate
+are done.
+
+If Iter satisfies BidirectionalIterator, at most (last -
+first)/2 swaps. Exactly last - first applications of the predicate
+are done.
+
+
    
+
    
+If Iter merely satisfied ForwardIterator at most (last - first) swaps
+are done. Exactly (last - first) applications of the predicate are done.
+
    
+
    
+
+
    
+[Editorial note: I looked for existing precedent in how we might call out
+distinct overloads overloads from a set of constrained templates, but there
+is not much existing practice to lean on.   advance/distance were the only
+algorithms I could find, and that wording is no clearer.]
+
    
+
+
    
+
+
 
 
    Proposed resolution:
    
 
    
@@ -5091,7 +5293,7 @@ swaps are done; otherwise at most (last - first) swaps are done. Exactly
 
    
 Partition is a "foundation" algorithm useful in many contexts (like sorting
 as just one example) - my motivation for extending it to include forward
-iterators is slist - without this extension you can't partition an slist
+iterators is foward_list - without this extension you can't partition an foward_list
 (without writing your own partition). Holes like this in the standard
 library weaken the argument for generic programming (ideally I'd be able
 to provide a library that would refine std::partition() to other concepts
@@ -5112,8 +5314,8 @@ mailing.]
    
 
 
    
 
    502. Proposition: Clarification of the interaction between a facet and an iterator
    
-
    Section: 22.1.1.1.1 [locale.category] Status: Open
- Submitter: Christopher Conrade Zseleghovski Date: 2005-06-07
    
+
    Section: 22.3.1.1.1 [locale.category] Status: Open
+ Submitter: Christopher Conrade Zseleghovski Opened: 2005-06-07  Last modified: 2008-03-13
    
 
    View all other issues in [locale.category].
    
 
    View all issues with Open status.
    
 
    Discussion:
    
@@ -5158,8 +5360,8 @@ Bill.
 
 
    
 
    503. more on locales
    
-
    Section: 22.2 [locale.categories] Status: Open
- Submitter: P.J. Plauger Date: 2005-06-20
    
+
    Section: 22.4 [locale.categories] Status: Open
+ Submitter: P.J. Plauger Opened: 2005-06-20  Last modified: 2008-03-13
    
 
    View other active issues in [locale.categories].
    
 
    View all other issues in [locale.categories].
    
 
    View all issues with Open status.
    
@@ -5269,112 +5471,11 @@ Berlin: Bill to provide wording.
 
 
 
-
    
-
    522. Tuple doesn't define swap
    
-
    Section: 20.4 [tuple], TR1 6.1 [tr.tuple] Status: Ready
- Submitter: Andy Koenig Date: 2005-07-03
    
-
    View other active issues in [tuple].
    
-
    View all other issues in [tuple].
    
-
    View all issues with Ready status.
    
-
    Discussion:
    
-
    
-Tuple doesn't define swap().  It should.
-
    
-
    [
-Berlin: Doug to provide wording.
-]
    
-
-
    [
-Batavia: Howard to provide wording.
-]
    
-
-
    [
-Toronto: Howard to provide wording (really this time).
-]
    
-
-
-
    [
-Bellevue:  Alisdair provided wording.
-]
    
-
-
-
-
-
    Proposed resolution:
    
-
-
    
-Add these signatures to 20.4 [tuple]
-
    
-
-
    template <class... Types>
-  void swap(tuple<Types...>& x, tuple<Types...>& y);
-template <class... Types>
-  void swap(tuple<Types...>&& x, tuple<Types...>& y);
-template <class... Types>
-  void swap(tuple<Types...>& x, tuple<Types...>&& y); 
-
    
-
-
    
-Add this signature to 20.4.1 [tuple.tuple]
-
    
-
-
    void swap(tuple&&);
-
    
-
-
    
-Add the following two sections to the end of the tuple clauses
-
    
-
-
    
-
    
-20.3.1.7 tuple swap [tuple.swap]
-
    
-
-
    void swap(tuple&& rhs); 
-
    
-
-
    
-
    
-Requires: Each type in Types shall be Swappable.
-
    
-
    
-Effects: Calls swap for each element in *this and its corresponding element
-in rhs.
-
    
-
    
-Throws: Nothing, unless one of the element-wise swap calls throw an
-exception. 
-
    
-
    
-
-
    
-20.3.1.8 tuple specialized algorithms [tuple.special]
-
    
-
-
    template <class... Types>
-  void swap(tuple<Types...>& x, tuple<Types...>& y);
-template <class... Types>
-  void swap(tuple<Types...>&& x, tuple<Types...>& y);
-template <class... Types>
-  void swap(tuple<Types...>& x, tuple<Types...>&& y); 
-
    
-
-
    
-
    
-Effects: x.swap(y)
-
    
-
    
-
    
-
-
-
-
-
-
 
    
 
    523. regex case-insensitive character ranges are unimplementable as specified
    
 
    Section: 28 [re] Status: Open
- Submitter: Eric Niebler Date: 2005-07-01
    
+ Submitter: Eric Niebler Opened: 2005-07-01  Last modified: 2008-03-13
    
+
    View other active issues in [re].
    
 
    View all other issues in [re].
    
 
    View all issues with Open status.
    
 
    Discussion:
    
@@ -5506,8 +5607,8 @@ Pete: Possible general problem with case insensitive ranges.
 
 
    
 
    539. partial_sum and adjacent_difference should mention requirements
    
-
    Section: 26.6.3 [partial.sum] Status: Open
- Submitter: Marc Schoolderman Date: 2006-02-06
    
+
    Section: 26.7.3 [partial.sum] Status: Open
+ Submitter: Marc Schoolderman Opened: 2006-02-06  Last modified: 2009-05-10
    
 
    View all issues with Open status.
    
 
    Discussion:
    
 
    
@@ -5678,11 +5779,38 @@ the accumulator must be the input_iterator's value_type, the w
 should specify it.
    +

    [ +2009-05-09 Alisdair adds: +]

    + + +
    +

    +Now that we have the facility, the 'best' accumulator type could probably be +deduced as: +

    +
    std::common_type<InIter::value_type, OutIter::reference>::type
+
    +

    +This type would then have additional requirements of constructability and +incrementability/assignability. +

    +

    +If this extracting an accumulator type from a pair/set of iterators (with +additional requirements on that type) is a problem for multiple functions, +it might be worth extracting into a SharedAccumulator concept or similar. +

    +

    +I'll go no further in writing up wording now, until the group gives a +clearer indication of preferred direction. +

    +
    +

    Proposed resolution:

    -Add to section 26.6.3 [partial.sum] paragraph 4 the following two sentences: +Add to section 26.7.3 [partial.sum] paragraph 4 the following two sentences:

    @@ -5692,7 +5820,7 @@ The type of *first shall meet the requirements of CopyConstructible

    -Add to section 26.6.4 [adjacent.difference] paragraph 2 the following sentence: +Add to section 26.7.4 [adjacent.difference] paragraph 2 the following sentence:

    @@ -5708,7 +5836,7 @@ The type of *first shall meet the requirements of CopyConstructible

    546. _Longlong and _ULonglong are integer types

    Section: TR1 5.1.1 [tr.rand.req] Status: Open - Submitter: Matt Austern Date: 2006-01-10

    + Submitter: Matt Austern Opened: 2006-01-10 Last modified: 2007-10-09

    View all issues with Open status.

    Discussion:

    @@ -5732,71 +5860,10 @@ list, so that people may use long long as a hash key. -

    -

    556. is Compare a BinaryPredicate?

    -

    Section: 25.3 [alg.sorting] Status: Open - Submitter: Martin Sebor Date: 2006-02-05

    -

    View all other issues in [alg.sorting].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -In 25, p8 we allow BinaryPredicates to return a type that's convertible -to bool but need not actually be bool. That allows predicates to return -things like proxies and requires that implementations be careful about -what kinds of expressions they use the result of the predicate in (e.g., -the expression in if (!pred(a, b)) need not be well-formed since the -negation operator may be inaccessible or return a type that's not -convertible to bool). -

    -

    -Here's the text for reference: -

    -

    - ...if an algorithm takes BinaryPredicate binary_pred as its argument - and first1 and first2 as its iterator arguments, it should work - correctly in the construct if (binary_pred(*first1, first2)){...}. -

    - -

    -In 25.3, p2 we require that the Compare function object return true -of false, which would seem to preclude such proxies. The relevant text -is here: -

    -

    - Compare is used as a function object which returns true if the first - argument is less than the second, and false otherwise... -

    - - -

    Proposed resolution:

    -

    -I think we could fix this by rewording 25.3, p2 to read somthing like: -

    -

    --2- Compare is used as a function object which returns -true if the first argument a BinaryPredicate. The -return value of the function call operator applied to an object of type -Compare, when converted to type bool, yields true -if the first argument of the call is less than the second, and -false otherwise. Compare comp is used throughout for -algorithms assuming an ordering relation. It is assumed that comp -will not apply any non-constant function through the dereferenced iterator. -

    - - -

    [ -Portland: Jack to define "convertible to bool" such that short circuiting isn't -destroyed. -]

    - - - - -

    564. stringbuf seekpos underspecified

    -

    Section: 27.7.1.4 [stringbuf.virtuals] Status: Open - Submitter: Martin Sebor Date: 2006-02-23

    +

    Section: 27.8.1.4 [stringbuf.virtuals] Status: Open + Submitter: Martin Sebor Opened: 2006-02-23 Last modified: 2007-10-10

    View all other issues in [stringbuf.virtuals].

    View all issues with Open status.

    Discussion:

    @@ -5857,8 +5924,8 @@ plugs the hole by specifying seekpos() in terms of seekoff().

    565. xsputn inefficient

    -

    Section: 27.5.2.4.5 [streambuf.virt.put] Status: Open - Submitter: Martin Sebor Date: 2006-02-23

    +

    Section: 27.6.2.4.5 [streambuf.virt.put] Status: Open + Submitter: Martin Sebor Opened: 2006-02-23 Last modified: 2007-10-09

    View all issues with Open status.

    Discussion:

    @@ -5929,9 +5996,9 @@ proposed wording doesn't accomplish that. Proposed Disposition: Open

    568. log2 overloads missing

    -

    Section: TR1 8.16.4 [tr.c99.cmath.over] Status: New - Submitter: Paolo Carlini Date: 2006-03-07

    -

    View all issues with New status.

    +

    Section: TR1 8.16.4 [tr.c99.cmath.over] Status: Tentatively NAD + Submitter: Paolo Carlini Opened: 2006-03-07 Last modified: 2009-05-23

    +

    View all issues with Tentatively NAD status.

    Discussion:

    log2 is missing from the list of "additional overloads" in TR1 8.16.4 [tr.c99.cmath.over] p1. @@ -5941,6 +6008,15 @@ proposed wording doesn't accomplish that. Proposed Disposition: Open Hinnant: This is a TR1 issue only. It is fixed in the current (N2135) WD.

    +

    [ +Batavia (2009-05): +]

    + +
    +We agree this has been fixed in the Working Draft. +Move to NAD. +
    +

    Proposed resolution:

    @@ -5953,8 +6029,8 @@ Add log2 to the list of functions in TR1 8.16.4 [tr.c99.cmath.over] p1.

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

    -

    Section: 27.4.3 [fpos] Status: Open - Submitter: Beman Dawes Date: 2006-04-12

    +

    Section: 27.5.3 [fpos] Status: Open + Submitter: Beman Dawes Opened: 2006-04-12 Last modified: 2007-10-09

    View all other issues in [fpos].

    View all issues with Open status.

    Discussion:

    @@ -6007,10 +6083,10 @@ these definitions are horrible. Proposed Disposition: Open

    580. unused allocator members

    -

    Section: 20.1.2 [allocator.requirements] Status: Open - Submitter: Martin Sebor Date: 2006-06-14

    -

    View other active issues in [allocator.requirements].

    -

    View all other issues in [allocator.requirements].

    +

    Section: 23.2.1 [container.requirements.general] Status: Open + Submitter: Martin Sebor Opened: 2006-06-14 Last modified: 2009-05-01

    +

    View other active issues in [container.requirements.general].

    +

    View all other issues in [container.requirements.general].

    View all issues with Open status.

    Duplicate of: 479

    Discussion:

    @@ -6051,12 +6127,29 @@ Batavia: We support this resolution. Martin to provide wording. pre-Oxford: Martin provided wording. ]

    + +

    [ +2009-04-28 Pablo adds: +]

    + + +
    +N2554 +(scoped allocators), +N2768 +(allocator concepts), and +N2810 +(allocator defects), address all of these points EXCEPT max_size(). +So, I would add a note to that affect and re-class the defect as belonging +to section 23.2.1 [container.requirements.general]. +
    +

    Proposed resolution:

    -Specifically, I propose to change 23.1 [container.requirements], +Specifically, I propose to change 23.2 [container.requirements], p9 as follows:

    @@ -6146,11 +6239,13 @@ post Oxford: This would be rendered NAD Editorial by acceptance of

    582. specialized algorithms and volatile storage

    -

    Section: 20.7.10.1 [uninitialized.copy] Status: Open - Submitter: Martin Sebor Date: 2006-06-14

    +

    Section: 20.8.11.2 [uninitialized.copy] Status: Open + Submitter: Martin Sebor Opened: 2006-06-14 Last modified: 2009-03-14

    View all other issues in [uninitialized.copy].

    View all issues with Open status.

    Discussion:

    + +

    Related to 1029

    The specialized algorithms [lib.specialized.algorithms] are specified @@ -6271,8 +6366,8 @@ effect by means of function template overloading.

    585. facet error reporting

    -

    Section: 22.2 [locale.categories] Status: Open - Submitter: Martin Sebor, Paolo Carlini Date: 2006-06-22

    +

    Section: 22.4 [locale.categories] Status: Open + Submitter: Martin Sebor, Paolo Carlini Opened: 2006-06-22 Last modified: 2007-10-09

    View other active issues in [locale.categories].

    View all other issues in [locale.categories].

    View all issues with Open status.

    @@ -6393,8 +6488,8 @@ Proposed Disposition: Open

    588. requirements on zero sized tr1::arrays and other details

    -

    Section: 23.2.1 [array] Status: Open - Submitter: Gennaro Prota Date: 2006-07-18

    +

    Section: 23.3.1 [array] Status: Open + Submitter: Gennaro Prota Opened: 2006-07-18 Last modified: 2009-05-30

    View other active issues in [array].

    View all other issues in [array].

    View all issues with Open status.

    @@ -6527,6 +6622,37 @@ it relies on table 80: "size() of the largest possible container" which, again, doesn't seem to consider fixed size containers

    +

    [ +2009-05-29 Daniel adds: +]

    + + +
    +
      +
    1. +

      +star bullet 1 ("what's the effect of calling assign(T&) on a +zero-sized array?[..]"); +

      +
      +assign has been renamed to fill and the semantic of fill is now +defined in terms of +the free algorithm fill_n, which is well-defined for this situation. +
      +
      2. +
    2. +

      +star bullet 3 ("it would be desiderable to have a static const data +member..."): +

      +
      +It seems that tuple_size<array<T, N> >::value as of 23.3.1.7 [array.tuple] does +provide this functionality now. +
      +
      3. +
    +
    +

    Proposed resolution:

    @@ -6546,7 +6672,7 @@ requirements? Alisdair will prepare a paper. Proposed Disposition: Open

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

    Section: TRDecimal 3.2 [trdec.types.types] Status: Open - Submitter: Daveed Vandevoorde Date: 2006-04-05

    + Submitter: Daveed Vandevoorde Opened: 2006-04-05 Last modified: 2009-05-01

    View other active issues in [trdec.types.types].

    View all other issues in [trdec.types.types].

    View all issues with Open status.

    @@ -6566,16 +6692,16 @@ Here is an example: 

    -		 struct S {
-		   S(_Decimal32 const&);  // Converting constructor
-		 };
-		 void f(S);
+         struct S {
+           S(_Decimal32 const&);  // Converting constructor
+         };
+         void f(S);
 
-		 void f(_Decimal64);
+         void f(_Decimal64);
 
-		 void g(_Decimal32 d) {
-		   f(d);
-		 }
+         void g(_Decimal32 d) {
+           f(d);
+         }
    @@ -6635,7 +6761,7 @@ C-to-C++ compatibility, since neither example can be expressed in C.

    606. Decimal: allow narrowing conversions

    Section: TRDecimal 3.2 [trdec.types.types] Status: Open - Submitter: Martin Sebor Date: 2006-06-15

    + Submitter: Martin Sebor Opened: 2006-06-15 Last modified: 2007-01-15

    View other active issues in [trdec.types.types].

    View all other issues in [trdec.types.types].

    View all issues with Open status.

    @@ -6694,8 +6820,8 @@ Redmond: We prefer explicit conversions for narrowing and implicit for widening.

    614. std::string allocator requirements still inconsistent

    -

    Section: 21.3 [basic.string] Status: Open - Submitter: Bo Persson Date: 2006-12-05

    +

    Section: 21.4 [basic.string] Status: Open + Submitter: Bo Persson Opened: 2006-12-05 Last modified: 2008-03-12

    View other active issues in [basic.string].

    View all other issues in [basic.string].

    View all issues with Open status.

    @@ -6737,7 +6863,7 @@ rules (substr, operator+, etc.). Howard to supply wording.

    [ Bo adds: The new container constructor which takes only a size_type is not -consistent with 23.1 [container.requirements], p9 which says in part: +consistent with 23.2 [container.requirements], p9 which says in part:

    All other constructors for these container types take an @@ -6766,24 +6892,24 @@ post Bellevue: We re-confirm that the issue is real. Pablo will provide wording.

    617. std::array is a sequence that doesn't satisfy the sequence requirements?

    -

    Section: 23.2.1 [array] Status: Open - Submitter: Bo Persson Date: 2006-12-30

    +

    Section: 23.3.1 [array] Status: Open + Submitter: Bo Persson Opened: 2006-12-30 Last modified: 2008-03-14

    View other active issues in [array].

    View all other issues in [array].

    View all issues with Open status.

    Discussion:

    -The <array> header is given under 23.2 [sequences]. -23.2.1 [array]/paragraph 3 says: +The <array> header is given under 23.3 [sequences]. +23.3.1 [array]/paragraph 3 says:

    "Unless otherwise specified, all array operations are as described in -23.1 [container.requirements]". +23.2 [container.requirements]".

    -However, array isn't mentioned at all in section 23.1 [container.requirements]. +However, array isn't mentioned at all in section 23.2 [container.requirements]. In particular, Table 82 "Sequence requirements" lists several operations (insert, erase, clear) -that std::array does not have in 23.2.1 [array]. +that std::array does not have in 23.3.1 [array].

    Also, Table 83 "Optional sequence operations" lists several operations that @@ -6800,110 +6926,154 @@ std::array does have, but array isn't mentioned.

    -

    629. complex insertion and locale dependence

    -

    Section: 26.3.6 [complex.ops] Status: Ready - Submitter: Gabriel Dos Reis Date: 2007-01-28

    -

    View all other issues in [complex.ops].

    -

    View all issues with Ready status.

    +

    625. mixed up Effects and Returns clauses

    +

    Section: 17 [library] Status: Open + Submitter: Martin Sebor Opened: 2007-01-20 Last modified: 2009-05-23

    +

    View other active issues in [library].

    +

    View all other issues in [library].

    +

    View all issues with Open status.

    Discussion:

    -

    -is there an issue opened for (0,3) as complex number with -the French local? With the English local, the above parses as an -imaginery complex number. With the French locale it parses as a -real complex number. +

    + +Many member functions of basic_string are overloaded, +with some of the overloads taking a string argument, +others value_type*, others size_type, and +others still iterators. Often, the requirements on one of +the overloads are expressed in the form of Effects, +Throws, and in the Working Paper +(N2134) +also Remark clauses, while those on the rest of the overloads +via a reference to this overload and using a Returns clause.

    -Further notes/ideas from the lib-reflector, messages 17982-17984: +The difference between the two forms of specification is that per +17.5.1.4 [structure.specifications], p3, an Effects clause specifies +"actions performed by the functions," i.e., its observable +effects, while a Returns clause is "a description of the +return value(s) of a function" that does not impose any +requirements on the function's observable effects.

    -

    -Add additional entries in num_punct to cover the complex separator (French would be ';'). +Since only Notes are explicitly defined to be informative and +all other paragraphs are explicitly defined to be normative, like +Effects and Returns, the new Remark clauses also +impose normative requirements.

    +

    -Insert a space before the comma, which should eliminate the ambiguity. +So by this strict reading of the standard there are some member +functions of basic_string that are required to throw an +exception under some conditions or use specific traits members while +many other otherwise equivalent overloads, while obliged to return the +same values, aren't required to follow the exact same requirements +with regards to the observable effects.

    +

    -Solve the problem for ordered sequences in general, perhaps with a -dedicated facet. Then complex should use that solution. +Here's an example of this problem that was precipitated by the change +from informative Notes to normative Remarks (presumably made to +address 424):

    -
    + +

    +In the Working Paper, find(string, size_type) contains a +Remark clause (which is just a Note in the current +standard) requiring it to use traits::eq(). +

    + +

    +find(const charT *s, size_type pos) is specified to +return find(string(s), pos) by a Returns clause +and so it is not required to use traits::eq(). However, +the Working Paper has replaced the original informative Note +about the function using traits::length() with a +normative requirement in the form of a Remark. Calling +traits::length() may be suboptimal, for example when the +argument is a very long array whose initial substring doesn't appear +anywhere in *this. +

    + +

    +Here's another similar example, one that existed even prior to the +introduction of Remarks: +

    + +

    + insert(size_type pos, string, size_type, size_type) is +required to throw out_of_range if pos > +size(). +

    + +

    +insert(size_type pos, string str) is specified to return +insert(pos, str, 0, npos) by a Returns clause and +so its effects when pos > size() are strictly speaking +unspecified. +

    + +

    +I believe a careful review of the current Effects and +Returns clauses is needed in order to identify all such +problematic cases. In addition, a review of the Working Paper should +be done to make sure that the newly introduced normative Remark +clauses do not impose any undesirable normative requirements in place +of the original informative Notes. +

    [ -Bellevue: +Batavia: Alan and Pete to work. ]

    -
    -

    -After much discussion, we agreed on the following: Add a footnote: -

    -

    -[In a locale in which comma is being used as a decimal point character, -inserting "showbase" into the output stream forces all outputs to show -an explicit decimal point character; then all inserted complex sequences -will extract unambiguously.] -

    -

    -And move this to READY status. -

    -
    -

    [ -Pre-Sophia Antipolis, Howard adds: +Bellevue: Marked as NAD Editorial. ]

    -
    -Changed "showbase" to "showpoint" and changed from Ready to Review. -
    -

    [ Post-Sophia Antipolis: +Martin indicates there is still work to be done on this issue. +Reopened. ]

    -
    -

    -I neglected to pull this issue from the formal motions page after the "showbase" to "showpoint" change. -In Sophia Antipolis this change was reviewed by the LWG and the issue was set to Ready. We subsequently -voted the footnote into the WP with "showbase". -

    -

    -I'm changing from WP back to Ready to pick up the "showbase" to "showpoint" change. -

    -
    +

    [ +Batavia (2009-05): +]

    +
    +Tom proposes we say that, unless specified otherwise, +it is always the caller's responsibility to verify that supplied arguments +meet the called function's requirements. +If further semantics are specified +(e.g., that the function throws under certain conditions), +then it is up to the implementer to check those conditions. +Alan feels strongly that our current use of Requires in this context +is confusing, especially now that requires is a new keyword. +

    Proposed resolution:

    -Add a footnote to 26.3.6 [complex.ops] p16:

    -
    -[In a locale in which comma is being used as a decimal point character, -inserting showpoint into the output stream forces all outputs to show -an explicit decimal point character; then all inserted complex sequences -will extract unambiguously.] -
    -

    630. arrays of valarray

    -

    Section: 26.5.2.1 [valarray.cons] Status: Open - Submitter: Martin Sebor Date: 2007-01-28

    +

    Section: 26.6.2.1 [valarray.cons] Status: Open + Submitter: Martin Sebor Opened: 2007-01-28 Last modified: 2008-06-02

    View other active issues in [valarray.cons].

    View all other issues in [valarray.cons].

    View all issues with Open status.

    Discussion:

    -Section 26.1 [numeric.requirements], p1 suggests that a +Section 26.2 [numeric.requirements], p1 suggests that a valarray specialization on a type T that satisfies the requirements enumerated in the paragraph is itself a valid type on which valarray may be instantiated @@ -6930,7 +7100,7 @@ Stated more generally, the problem is that valarray<valarray<T> >::resize(size_t) isn't required or guaranteed to have well-defined semantics for every type T that satisfies all requirements in -26.1 [numeric.requirements]. +26.2 [numeric.requirements].

    @@ -6982,7 +7152,7 @@ If no proposed wording by June meeting, this issue should be closed NAD.

    Proposed resolution:

    -Change 26.5.2.2 [valarray.assign], p1 as follows: +Change 26.6.2.2 [valarray.assign], p1 as follows:

    @@ -7020,7 +7190,7 @@ text:

    -Also add the following paragraph to 26.5.2.2 [valarray.assign], immediately after p4: +Also add the following paragraph to 26.6.2.2 [valarray.assign], immediately after p4:

    @@ -7042,7 +7212,7 @@ prefers the original proposed resolution:

    -Change 26.5.2.2 [valarray.assign], p1 as follows: +Change 26.6.2.2 [valarray.assign], p1 as follows:

    @@ -7060,7 +7230,7 @@ Change 26.5.2.2 [valarray.assign], p1 as follows:

    -Add the following paragraph to 26.5.2.2 [valarray.assign], immediately after +Add the following paragraph to 26.6.2.2 [valarray.assign], immediately after p4:

    @@ -7086,96 +7256,10 @@ which you can assign to a valarray of size 0, but not to any other -
    -

    631. conflicting requirements for BinaryPredicate

    -

    Section: 25 [algorithms] Status: Open - Submitter: James Kanze Date: 2007-01-31

    -

    View all other issues in [algorithms].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -The general requirements for BinaryPredicate (in 25 [algorithms]/8) contradict the implied specific requirements for -some functions. In particular, it says that: -

    - -

    -[...] if an algorithm takes BinaryPredicate binary_pred -as its argument and first1 and first2 as its -iterator arguments, it should work correctly in the construct if -(binary_pred (*first1 , *first2 )){...}. -BinaryPredicate always takes the first iterator type as its -first argument, that is, in those cases when T value is -part of the signature, it should work correctly in the context of if -(binary_pred (*first1 , value)){...}. -

    - -

    -In the description of upper_bound (25.3.3.2 [upper.bound]/2), however, the use is described as -"!comp(value, e)", where e is an -element of the sequence (a result of dereferencing -*first). -

    - -

    -In the description of lexicographical_compare, we have both -"*first1 < *first2" and "*first2 -< *first1" (which presumably implies "comp( -*first1, *first2 )" and "comp( *first2, -*first1 )". -

    - -

    [ -Toronto: Moved to Open. ConceptGCC seems to get lower_bound -and upper_bound to work withoutt these changes. -]

    - - - - -

    Proposed resolution:

    -

    -Logically, the BinaryPredicate is used as an ordering -relationship, with the semantics of "less than". Depending on the -function, it may be used to determine equality, or any of the inequality -relationships; doing this requires being able to use it with either -parameter first. I would thus suggest that the requirement be: -

    - -

    -[...] BinaryPredicate always takes the first iterator -value_type as one of its arguments, it is unspecified which. If -an algorithm takes BinaryPredicate binary_pred as its -argument and first1 and first2 as its -iterator arguments, it should work correctly both in the construct -if (binary_pred (*first1 , *first2 )){...} and -if (binary_pred (*first2, *first1)){...}. In -those cases when T value is part of the signature, it -should work correctly in the context of if (binary_pred -(*first1 , value)){...} and of if (binary_pred -(value, *first1)){...}. [Note: if the two -types are not identical, and neither is convertable to the other, this -may require that the BinaryPredicate be a functional object -with two overloaded operator()() functions. --end note] -

    - -

    -Alternatively, one could specify an order for each function. IMHO, this -would be more work for the committee, more work for the implementors, -and of no real advantage for the user: some functions, such as -lexicographical_compare or equal_range, will still require both -functions, and it seems like a much easier rule to teach that both -functions are always required, rather than to have a complicated list of -when you only need one, and which one. -

    - - - - -

    632. Time complexity of size() for std::set

    -

    Section: 23.1 [container.requirements] Status: Open - Submitter: Lionel B Date: 2007-02-01

    +

    Section: 23.2 [container.requirements] Status: Open + Submitter: Lionel B Opened: 2007-02-01 Last modified: 2009-05-23

    View other active issues in [container.requirements].

    View all other issues in [container.requirements].

    View all issues with Open status.

    @@ -7221,13 +7305,6 @@ for std::set is not documented... but if it is it's certainly well hidden away.

    - - -

    Proposed resolution:

    -

    -

    - -

    [ Kona (2007): This issue affects all the containers. We'd love to see a paper dealing with the broad issue. We think that the complexity of the @@ -7247,19 +7324,36 @@ invalidated. Alan to provide wording that toughens wording, but that does not absolutely mandate O(1).

    +

    [ +Batavia (2009-05): +]

    + +
    +We observed that the wording "should" (in note a) has no effect. +Howard prefers that O(1) size be mandated. +It is not clear that this issue can be resolved to everyone's satisfaction, +but Alan will provide wording nonetheless. +
    + + +

    Proposed resolution:

    +

    +

    + +

    635. domain of allocator::address

    -

    Section: 20.1.2 [allocator.requirements] Status: Open - Submitter: Howard Hinnant Date: 2007-02-08

    +

    Section: X [allocator.requirements] Status: Open + Submitter: Howard Hinnant Opened: 2007-02-08 Last modified: 2009-05-01

    View other active issues in [allocator.requirements].

    View all other issues in [allocator.requirements].

    View all issues with Open status.

    Discussion:

    -The table of allocator requirements in 20.1.2 [allocator.requirements] describes +The table of allocator requirements in X [allocator.requirements] describes allocator::address as: 

    a.address(r)
@@ -7299,11 +7393,31 @@ Mandating that allocator::address can only be called for values which t
 allocator allocated seems overly restrictive.
 
    
 
+
    [
+post San Francisco:
+]
    
+
+
+
    
+Pablo recommends NAD Editorial, solved by
+N2768.
+
    
+
+
    [
+2009-04-28 Pablo adds:
+]
    
+
+
+
    
+Tentatively-ready NAD Editorial as fixed by
+N2768.
+
    
+
 
 
 
    Proposed resolution:
    
 
    
-Change 20.1.2 [allocator.requirements]:
+Change X [allocator.requirements]:
 
    
 
 
    
@@ -7335,15 +7449,17 @@ no resolution to this issue was recorded.  Moved to Open.
 
 
    
 
    644. Possible typos in 'function' description
    
-
    Section: X [func.wrap.func.undef] Status: Open
- Submitter: Bo Persson Date: 2007-02-25
    
-
    View all issues with Open status.
    
+
    Section: 20.7.16.2 [func.wrap.func] Status: Tentatively NAD
+ Submitter: Bo Persson Opened: 2007-02-25  Last modified: 2009-05-23
    
+
    View other active issues in [func.wrap.func].
    
+
    View all other issues in [func.wrap.func].
    
+
    View all issues with Tentatively NAD status.
    
 
    Discussion:
    
 
    
-X [func.wrap.func.undef]
+20.7.16.2 [func.wrap.func]
 
    
 
    
-The note in paragraph 2 refers to 'undefined void operators', while the 
+The note in paragraph 2 refers to 'undefined void operators', while the
 section declares a pair of operators returning bool.
 
    
 
@@ -7358,23 +7474,65 @@ changed from private to deleted.  The two issues stepped on each other.  What do
 type of these deleted functions to be?
 
    
 
+
    [
+2009-05-02 Daniel adds:
+]
    
+
+
+
    
+
    
+I suggest harmonizing this issue with similar classes. E.g. in
+20.8.13.3 [util.smartptr.weak] bool return values for
+
    
+
    template <class Y> bool operator<(weak_ptr<Y> const&) const = delete;
+template <class Y> bool operator<=(weak_ptr<Y> const&) const = delete;
+template <class Y> bool operator>(weak_ptr<Y> const&) const = delete;
+template <class Y> bool operator>=(weak_ptr<Y> const&) const = delete;
+
    
+
+
    
+are used and basically all newer provided deleted copy assignment operators
+of type X use the canonical return type X& instead of void. Since the note
+mentioned in the issue description has now already been changed to
+
    
+
    
+deleted overloads close possible hole in the type system
+
    
+
    
+it seems to be of even lesser need to perform the change. Therefore
+I recommend declaring the issue as NAD.
+
    
+
    
+
+
    [
+Batavia (2009-05):
+]
    
+
+
    
+
    
+We agree with Daniel's recommendation.
+
    
+
    
+Move to NAD.
+
    
+
    
 
 
 
    Proposed resolution:
    
 
    
-Change 20.6.15.2 [func.wrap.func]
+Change 20.7.16.2 [func.wrap.func]
 
    
 
 
    ...
 private:
-   // X [func.wrap.func.undef], undefined operators:
+   // 20.7.16.2 [func.wrap.func], undefined operators:
    template<class Function2> bool void operator==(const function<Function2>&);
    template<class Function2> bool void operator!=(const function<Function2>&);
 };
 
    
 
 
    
-Change X [func.wrap.func.undef]
+Change 20.7.16.2 [func.wrap.func]
 
    
 
 
    template<class Function2> bool void operator==(const function<Function2>&);
@@ -7387,8 +7545,8 @@ template<class Function2> bool void operator!=(const
 
 
    
 
    659. istreambuf_iterator should have an operator->()
    
-
    Section: 24.5.3 [istreambuf.iterator] Status: Open
- Submitter: Niels Dekker Date: 2007-03-25
    
+
    Section: 24.6.3 [istreambuf.iterator] Status: Open
+ Submitter: Niels Dekker Opened: 2007-03-25  Last modified: 2009-05-30
    
 
    View all other issues in [istreambuf.iterator].
    
 
    View all issues with Open status.
    
 
    Discussion:
    
@@ -7433,37 +7591,6 @@ I hope that the resolution of this issue will contribute to getting a
 clear and consistent definition of iterator concepts.
 
    
 
-
-
    Proposed resolution:
    
-
    
-Add to the synopsis in 24.5.3 [istreambuf.iterator]:
-
    
-
-
    charT operator*() const;
-pointer operator->() const;
-istreambuf_iterator<charT,traits>& operator++();
-
    
-
-
    
-Change 24.5.3 [istreambuf.iterator], p1:
-
    
-
-
    
-The class template istreambuf_iterator reads successive
-characters from the streambuf for which it was constructed.
-operator* provides access to the current input character, if
-any. operator-> may return a proxy. Each time
-operator++ is evaluated, the iterator advances to the next
-input character. If the end of stream is reached
-(streambuf_type::sgetc() returns traits::eof()), the
-iterator becomes equal to the end of stream iterator value. The default
-constructor istreambuf_iterator() and the constructor
-istreambuf_iterator(0) both construct an end of stream iterator
-object suitable for use as an end-of-range.
-
    
-
-
-
 
    [
 Kona (2007): The proposed resolution is inconsistent because the return
 type of istreambuf_iterator::operator->() is specified to be pointer,
@@ -7498,25 +7625,112 @@ is just: istreambuf_iterator should have an operator->()!
 
    
 
    
 
+
    [
+2009-04-30 Alisdair adds:
+]
    
+
+
+
    
+Note that operator-> is now a requirement in the InputIterator concept, so
+this issue cannot be ignored or existing valid programs will break when
+compiled with an 0x library.
+
    
+
+
    [
+2009-05-29 Alisdair adds:
+]
    
+
+
+
    
+
    
+I agree with the observation that in principle the type 'pointer' may be a
+proxy, and the words highlighting this are redundant.
+
    
+
    
+However, in the current draught pointer is required to be exactly 'charT *'
+by the derivation from std::iterator.  At a minimum, the 4th parameter of
+this base class template should become unspecified.  That permits the
+introduction of a proxy as a nested class in some further undocumented (not
+even exposition-only) base.
+
    
+
    
+It also permits the istream_iterator approach where the cached value is
+stored in the iterator itself, and the iterator serves as its own proxy for
+post-increment operator++ - removing the need for the existing
+exposition-only nested class proxy.
+
    
+
    
+Note that the current proxy class also has exactly the right properties to
+serve as the pointer proxy too.  This is likely to be a common case where an
+InputIterator does not hold internal state but delegates to another class.
+
    
+
    
+Proposed Resolution:
+
    
+
    
+In addition to the current proposal:
+
    
+
    
+24.6.3 [istreambuf.iterator]
+
    
+
    template<class charT, class traits = char_traits<charT> >
+class istreambuf_iterator
+  : public iterator<input_iterator_tag, charT,
+                    typename traits::off_type, charT* unspecified, charT> {
+
    
+
    
+
+
+
    Proposed resolution:
    
+
    
+Add to the synopsis in 24.6.3 [istreambuf.iterator]:
+
    
+
+
    charT operator*() const;
+pointer operator->() const;
+istreambuf_iterator<charT,traits>& operator++();
+
    
+
+
    
+Change 24.6.3 [istreambuf.iterator], p1:
+
    
+
+
    
+The class template istreambuf_iterator reads successive
+characters from the streambuf for which it was constructed.
+operator* provides access to the current input character, if
+any. operator-> may return a proxy. Each time
+operator++ is evaluated, the iterator advances to the next
+input character. If the end of stream is reached
+(streambuf_type::sgetc() returns traits::eof()), the
+iterator becomes equal to the end of stream iterator value. The default
+constructor istreambuf_iterator() and the constructor
+istreambuf_iterator(0) both construct an end of stream iterator
+object suitable for use as an end-of-range.
+
    
+
+
+
+
 
 
 
 
    
 
    667. money_get's widened minus sign
    
-
    Section: 22.2.6.1.2 [locale.money.get.virtuals] Status: Open
- Submitter: Thomas Plum Date: 2007-04-16
    
+
    Section: 22.4.6.1.2 [locale.money.get.virtuals] Status: Tentatively NAD
+ Submitter: Thomas Plum Opened: 2007-04-16  Last modified: 2009-05-23
    
 
    View other active issues in [locale.money.get.virtuals].
    
 
    View all other issues in [locale.money.get.virtuals].
    
-
    View all issues with Open status.
    
+
    View all issues with Tentatively NAD status.
    
 
    Discussion:
    
 
    
-22.2.6.1.2 [locale.money.get.virtuals], para 1 says:
+22.4.6.1.2 [locale.money.get.virtuals], para 1 says:
 
    
 
 
    
-The result is returned as an integral value 
-stored in units or as a sequence of digits possibly preceded by a 
-minus sign (as produced by ct.widen(c) where c is '-' or in the range 
+The result is returned as an integral value
+stored in units or as a sequence of digits possibly preceded by a
+minus sign (as produced by ct.widen(c) where c is '-' or in the range
 from '0' through '9', inclusive) stored in digits.
 
    
 
@@ -7561,6 +7775,16 @@ which are translated by ct.widen(c) calls before being stored in di
 the widened characters are not relevant to the parsing of the subject string.
    +

    [ +Batavia (2009-05): +]

    + +
    +We agree with Bill's comment above, +in line with the first of the interpretations offered in the issue. +Move to NAD. +
    +

    Proposed resolution:

    @@ -7572,30 +7796,29 @@ the widened characters are not relevant to the parsing of the subject string.

    668. money_get's empty minus sign

    -

    Section: 22.2.6.1.2 [locale.money.get.virtuals] Status: Open - Submitter: Thomas Plum Date: 2007-04-16

    +

    Section: 22.4.6.1.2 [locale.money.get.virtuals] Status: Tentatively NAD + Submitter: Thomas Plum Opened: 2007-04-16 Last modified: 2009-05-23

    View other active issues in [locale.money.get.virtuals].

    View all other issues in [locale.money.get.virtuals].

    -

    View all issues with Open status.

    +

    View all issues with Tentatively NAD status.

    Discussion:

    -22.2.6.1.2 [locale.money.get.virtuals], para 3 says: +22.4.6.1.2 [locale.money.get.virtuals], para 3 says:

    If pos or neg is empty, the sign component is -optional, and if no sign is detected, the result is given the sign +optional, and if no sign is detected, the result is given the sign that corresponds to the source of the empty string.

    -The following -objection has been raised: +The following objection has been raised:

    -A negative_sign of "" means "there is no -way to write a negative sign" not "any null sequence is a negative +A negative_sign of "" means "there is no +way to write a negative sign" not "any null sequence is a negative sign, so it's always there when you look for it".

    @@ -7608,6 +7831,109 @@ Kona (2007): Bill to provide proposed wording and interpretation of existing wor ]

    +

    +Related to 669. +

    + +

    [ +2009-05-17 Howard adds: +]

    + + +
    +

    +I disagree that a negative_sign of "" means "there is no +way to +write a negative sign". The meaning requires the sentences of +22.4.6.1.2 [locale.money.get.virtuals] p3 following that quoted above +to be +taken into account: +

    + +
    +-3- ... If pos or neg is empty, the sign component is +optional, and if no sign is detected, the result is given the sign that +corresponds to the source of the empty string. Otherwise, the character +in the indicated position must match the first character of pos +or neg, and the result is given the corresponding sign. If the +first character of pos is equal to the first character of +neg, or if both strings are empty, the result is given a +positive sign. +
    + +

    +So a negative_sign of "" means "there is no way to write a +negative sign" only when positive_sign is also "". However +when negative_sign is "" and postive_sign.size() > +0, then one writes a negative value by not writing the +postive_sign in the position indicated by +money_base::sign. +For example: +

    + +
    pattern = {symbol, sign, value, none}
+positive_sign = "+"
+negative_sign = ""
+$123   // a negative value, using optional sign
+$+123  // a positive value
+$-123  // a parse error
+
    + +

    +And: +

    + +
    pattern = {symbol, sign, value, none}
+positive_sign = ""
+negative_sign = ""
+$123   // a positive value, no sign possible
+$+123  // a parse error
+$-123  // a parse error
+
    + + +

    +And (regarding 669): +

    + +
    pattern = {symbol, sign, value, none}
+positive_sign = "-"
+negative_sign = "-"
+$123   // a parse error, sign is mandatory
+$+123  // a parse error
+$-123  // a positive value
+
    + + +

    +The text seems both unambiguous and clear to me. I recommend NAD for +both this issue and 669. However I would have no +objection to adding examples such as those above. +

    +
    + +

    [ +Batavia (2009-05): +]

    + +
    +

    +This discussion applies equally to issue 669 (q.v.). +Howard has added examples above, +and recommends either NAD or a resolution that adds his (or similar) examples +to the Working Paper. +

    +

    +Alan would like to rewrite paragraph 3. +

    +

    +We recommend moving to NAD. +Anyone who feels strongly about adding the examples +is invited to submit corresponding wording. +We further recommend issue 669 be handled identically. +

    +
    +

    Proposed resolution:

    @@ -7620,14 +7946,14 @@ Kona (2007): Bill to provide proposed wording and interpretation of existing wor

    669. Equivalent postive and negative signs in money_get

    -

    Section: 22.2.6.1.2 [locale.money.get.virtuals] Status: Open - Submitter: Thomas Plum Date: 2007-04-16

    +

    Section: 22.4.6.1.2 [locale.money.get.virtuals] Status: Tentatively NAD + Submitter: Thomas Plum Opened: 2007-04-16 Last modified: 2009-05-23

    View other active issues in [locale.money.get.virtuals].

    View all other issues in [locale.money.get.virtuals].

    -

    View all issues with Open status.

    +

    View all issues with Tentatively NAD status.

    Discussion:

    -22.2.6.1.2 [locale.money.get.virtuals], para 3 sentence 4 says: +22.4.6.1.2 [locale.money.get.virtuals], para 3 sentence 4 says:

    @@ -7655,53 +7981,29 @@ Bill to provide proposed wording and interpretation of existing wording. ]

    - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    670. money_base::pattern and space

    -

    Section: 22.2.6.3 [locale.moneypunct] Status: Open - Submitter: Thomas Plum Date: 2007-04-16

    -

    View all issues with Open status.

    -

    Duplicate of: 836

    -

    Discussion:

    - - -

    -22.2.6.3 [locale.moneypunct], para 2 says: -

    - -

    -The value space indicates that at least one space is required at -that position. -

    - -

    -The following objection has been raised: -

    - -

    -Whitespace is optional when matching space. (See 22.2.6.1.2 [locale.money.get.virtuals], para 2.) -

    - -

    -[Plum ref _22263Y22] -

    -

    [ -Kona (2007): Bill to provide proposed wording. We agree that C++03 is -ambiguous, and that we want C++0X to say "space" means 0 or more -whitespace characters on input. +2009-05-17 See Howard's comments in related issue 668. ]

    +

    [ +Batavia (2009-05): +]

    + +
    +

    +This discussion applies equally to issue 668 (q.v.). +Howard has added examples there, +and recommends either NAD or a resolution that adds his (or similar) examples +to the Working Paper. +

    +

    +We recommend moving to NAD. +Anyone who feels strongly about adding the examples +is invited to submit corresponding wording. +We further recommend issue 668 be handled identically. +

    +

    Proposed resolution:

    @@ -7714,8 +8016,8 @@ whitespace characters on input.

    671. precision of hexfloat

    -

    Section: 22.2.2.2.2 [facet.num.put.virtuals] Status: Open - Submitter: John Salmon Date: 2007-04-20

    +

    Section: 22.4.2.2.2 [facet.num.put.virtuals] Status: Open + Submitter: John Salmon Opened: 2007-04-20 Last modified: 2009-03-12

    View all other issues in [facet.num.put.virtuals].

    View all issues with Open status.

    Discussion:

    @@ -7729,7 +8031,7 @@ As far as I can tell, it does so via the following: 8.15 Additions to header <locale> [tr.c99.locale]

    -In subclause 22.2.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after +In subclause 22.4.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after the line: floatfield == ios_base::scientific %E

    @@ -7744,10 +8046,10 @@ floatfield == ios_base::fixed | ios_base::scientific %A 2 in this clause, ensure that the print functions generate hexadecimal floating-point fields with a %a or %A conversion specifier, and that the scan functions match hexadecimal floating-point fields with a %g -conversion specifier.  end note] +conversion specifier. end note]

    -Following the thread, in 22.2.2.2.2 [facet.num.put.virtuals], we find: +Following the thread, in 22.4.2.2.2 [facet.num.put.virtuals], we find:

    For conversion from a floating-point type, if (flags & fixed) != 0 or @@ -7757,16 +8059,16 @@ conversion specification.

    This would seem to imply that when floatfield == fixed|scientific, the precision of the conversion specifier is to be taken from -str.precision().  Is this really what's intended?  I sincerely hope -that I'm either missing something or this is an oversight.  Please +str.precision(). Is this really what's intended? I sincerely hope +that I'm either missing something or this is an oversight. Please tell me that the committee did not intend to mandate that hex floats (and doubles) should by default be printed as if by %.6a.

    [ Howard: I think the fundamental issue we overlooked was that with %f, -%e, %g, the default precision was always 6.  With %a the default -precision is not 6, it is infinity.  So for the first time, we need to +%e, %g, the default precision was always 6. With %a the default +precision is not 6, it is infinity. So for the first time, we need to distinguish between the default value of precision, and the precision value 6. ]

    @@ -7787,760 +8089,12 @@ Kona (2007): Robert volunteers to propose wording. -
    -

    675. Move assignment of containers

    -

    Section: 23.1 [container.requirements] Status: Review - Submitter: Howard Hinnant Date: 2007-05-05

    -

    View other active issues in [container.requirements].

    -

    View all other issues in [container.requirements].

    -

    View all issues with Review status.

    -

    Discussion:

    -

    -James Hopkin pointed out to me that if vector<T> move assignment is O(1) -(just a swap) then containers such as vector<shared_ptr<ostream>> might have -the wrong semantics under move assignment when the source is not truly an rvalue, but a -moved-from lvalue (destructors could run late). -

    - -
    vector<shared_ptr<ostream>> v1;
-vector<shared_ptr<ostream>> v2;
-...
-v1 = v2;               // #1
-v1 = std::move(v2);    // #2
-
    - -

    -Move semantics means not caring what happens to the source (v2 in this example). -It doesn't mean not caring what happens to the target (v1). In the above example -both assignments should have the same effect on v1. Any non-shared ostream's -v1 owns before the assignment should be closed, whether v1 is undergoing -copy assignment or move assignment. -

    - -

    -This implies that the semantics of move assignment of a generic container should be -clear, swap instead of just swap. An alternative which could achieve the same -effect would be to move assign each element. In either case, the complexity of move -assignment needs to be relaxed to O(v1.size()). -

    - -

    -The performance hit of this change is not nearly as drastic as it sounds. -In practice, the target of a move assignment has always just been move constructed -or move assigned from. Therefore under clear, swap semantics (in -this common use case) we are still achieving O(1) complexity. -

    - - - -

    Proposed resolution:

    -

    -Change 23.1 [container.requirements]: -

    - -
    - - - - - - - - - - - - -
    Table 89: Container requirements
    expressionreturn typeoperational semanticsassertion/note pre/post-conditioncomplexity
    a = rv;X&All existing elements of a are either move assigned or destructeda shall be equal to the -value that rv had -before this construction -(Note C) linear
    - -

    -Notes: the algorithms swap(), equal() and -lexicographical_compare() are defined in clause 25. Those -entries marked "(Note A)" should have constant complexity. Those entries -marked "(Note B)" have constant complexity unless -allocator_propagate_never<X::allocator_type>::value is -true, in which case they have linear complexity. -Those entries -marked "(Note C)" have constant complexity if a.get_allocator() == -rv.get_allocator() or if either -allocator_propagate_on_move_assignment<X::allocator_type>::value -is true or -allocator_propagate_on_copy_assignment<X::allocator_type>::value -is true and linear complexity otherwise. -

    -
    - - - -

    [ -post Bellevue Howard adds: -]

    - - -
    -

    -This issue was voted to WP in Bellevue, but accidently got stepped on by -N2525 -which was voted to WP simulataneously. Moving back to Open for the purpose of getting -the wording right. The intent of this issue and N2525 are not in conflict. -

    -
    - -

    [ -post Sophia Antipolis Howard updated proposed wording: -]

    - - - - - -
    -

    676. Moving the unordered containers

    -

    Section: 23.4 [unord] Status: Open - Submitter: Howard Hinnant Date: 2007-05-05

    -

    View other active issues in [unord].

    -

    View all other issues in [unord].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -Move semantics are missing from the unordered containers. The proposed -resolution below adds move-support consistent with -N1858 -and the current working draft. -

    - -

    -The current proposed resolution simply lists the requirements for each function. -These might better be hoisted into the requirements table for unordered associative containers. -Futhermore a mild reorganization of the container requirements could well be in order. -This defect report is purposefully ignoring these larger issues and just focusing -on getting the unordered containers "moved". -

    - - - -

    Proposed resolution:

    - -

    -Add to 23.4 [unord]: -

    - -
    template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>& y); 
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>&& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
-
-...
-
-template <class Value, class Hash, class Pred, class Alloc> 
-  void swap(unordered_set<Value, Hash, Pred, Alloc>& x, 
-            unordered_set<Value, Hash, Pred, Alloc>& y); 
-
-template <class Value, class Hash, class Pred, class Alloc> 
-  void swap(unordered_set<Value, Hash, Pred, Alloc>& x, 
-            unordered_set<Value, Hash, Pred, Alloc>&& y);
-
-template <class Value, class Hash, class Pred, class Alloc> 
-  void swap(unordered_set<Value, Hash, Pred, Alloc>&& x, 
-            unordered_set<Value, Hash, Pred, Alloc>& y);
-
-template <class Value, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multiset<Value, Hash, Pred, Alloc>& x, 
-            unordered_multiset<Value, Hash, Pred, Alloc>& y);
-
-template <class Value, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multiset<Value, Hash, Pred, Alloc>& x, 
-            unordered_multiset<Value, Hash, Pred, Alloc>&& y);
-
-template <class Value, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multiset<Value, Hash, Pred, Alloc>&& x, 
-            unordered_multiset<Value, Hash, Pred, Alloc>& y);
-
    - -

    unordered_map

    - -

    -Change 23.4.1 [unord.map]: -

    - -
    class unordered_map
-{
-    ...
-    unordered_map(const unordered_map&);
-    unordered_map(unordered_map&&);
-    ~unordered_map();
-    unordered_map& operator=(const unordered_map&);
-    unordered_map& operator=(unordered_map&&);
-    ...
-    // modifiers 
-    std::pair<iterator, bool> insert(const value_type& obj); 
-    template <class P> pair<iterator, bool> insert(P&& obj);
-    iterator       insert(iterator hint, const value_type& obj);
-    template <class P> iterator       insert(iterator hint, P&& obj);
-    const_iterator insert(const_iterator hint, const value_type& obj);
-    template <class P> const_iterator insert(const_iterator hint, P&& obj);
-    ...
-    void swap(unordered_map&&);
-    ...
-    mapped_type& operator[](const key_type& k);
-    mapped_type& operator[](key_type&& k);
-    ...
-};
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>&& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>& y);
-
    - -

    -Add to 23.4.1.1 [unord.map.cnstr]: -

    - -
    -
    template <class InputIterator>
-  unordered_map(InputIterator f, InputIterator l, 
-                size_type n = implementation-defined, 
-                const hasher& hf = hasher(), 
-                const key_equal& eql = key_equal(), 
-                const allocator_type& a = allocator_type());
-
    - -

    - -Requires: If the iterator's dereference operator returns an -lvalue or a const rvalue pair<key_type, mapped_type>, -then both key_type and mapped_type shall be -CopyConstructible. - -

    -
    - -

    -Add to 23.4.1.2 [unord.map.elem]: -

    - -
    - -
    mapped_type& operator[](const key_type& k);
    - -
    -

    ...

    -

    -Requires: key_type shall be CopyConstructible -and mapped_type shall be DefaultConstructible. -

    -
    - -
    mapped_type& operator[](key_type&& k);
    - -
    -

    -Effects: If the unordered_map does not already contain an -element whose key is equivalent to k , inserts the value -std::pair<const key_type, mapped_type>(std::move(k), mapped_type()). -

    - -

    -Requires: mapped_type shall be DefaultConstructible. -

    - -

    -Returns: A reference to x.second, where x is the -(unique) element whose key is equivalent to k. -

    - -
    - -
    - -

    -Add new section [unord.map.modifiers]: -

    - -
    -
    pair<iterator, bool> insert(const value_type& x);
-template <class P> pair<iterator, bool> insert(P&& x);
-iterator       insert(iterator hint, const value_type& x);
-template <class P> iterator       insert(iterator hint, P&& x);
-const_iterator insert(const_iterator hint, const value_type& x);
-template <class P> const_iterator insert(const_iterator hint, P&& x);
-template <class InputIterator>
-  void insert(InputIterator first, InputIterator last);
-
    - -
    -

    -Requires: Those signatures taking a const value_type& parameter -requires both the key_type and the mapped_type to be -CopyConstructible. -

    - -

    -P shall be convertible to value_type. - If P is instantiated as a reference -type, then the argument x is copied from. Otherwise x -is considered to be an rvalue as it is converted to value_type -and inserted into the unordered_map. Specifically, in such -cases CopyConstructible is not required of key_type or -mapped_type unless the conversion from P specifically -requires it (e.g. if P is a tuple<const key_type, -mapped_type>, then key_type must be -CopyConstructible). -

    - -

    -The signature taking InputIterator -parameters requires CopyConstructible of both -key_type and mapped_type if the dereferenced -InputIterator returns an lvalue or const rvalue -value_type. -

    - -
    - -
    - -

    -Add to 23.4.1.3 [unord.map.swap]: -

    - -
    -
    template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>& y);
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>&& y);
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>& y);
-
    -
    - -

    unordered_multimap

    - -

    -Change 23.4.2 [unord.multimap]: -

    - -
    class unordered_multimap
-{
-    ...
-    unordered_multimap(const unordered_multimap&);
-    unordered_multimap(unordered_multimap&&);
-    ~unordered_multimap();
-    unordered_multimap& operator=(const unordered_multimap&);
-    unordered_multimap& operator=(unordered_multimap&&);
-    ...
-    // modifiers 
-    iterator insert(const value_type& obj); 
-    template <class P> iterator insert(P&& obj);
-    iterator       insert(iterator hint, const value_type& obj);
-    template <class P> iterator       insert(iterator hint, P&& obj);
-    const_iterator insert(const_iterator hint, const value_type& obj);
-    template <class P> const_iterator insert(const_iterator hint, P&& obj);
-    ...
-    void swap(unordered_multimap&&);
-    ...
-};
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
-
    - -

    -Add to 23.4.2.1 [unord.multimap.cnstr]: -

    - -
    -
    template <class InputIterator>
-  unordered_multimap(InputIterator f, InputIterator l, 
-                size_type n = implementation-defined, 
-                const hasher& hf = hasher(), 
-                const key_equal& eql = key_equal(), 
-                const allocator_type& a = allocator_type());
-
    - -

    - -Requires: If the iterator's dereference operator returns an -lvalue or a const rvalue pair<key_type, mapped_type>, -then both key_type and mapped_type shall be -CopyConstructible. - -

    -
    - -

    -Add new section [unord.multimap.modifiers]: -

    - -
    -
    iterator insert(const value_type& x);
-template <class P> iterator       insert(P&& x);
-iterator       insert(iterator hint, const value_type& x);
-template <class P> iterator       insert(iterator hint, P&& x);
-const_iterator insert(const_iterator hint, const value_type& x);
-template <class P> const_iterator insert(const_iterator hint, P&& x);
-template <class InputIterator>
-  void insert(InputIterator first, InputIterator last);
-
    - -
    -

    -Requires: Those signatures taking a const value_type& parameter -requires both the key_type and the mapped_type to be -CopyConstructible. -

    - -

    -P shall be convertible to value_type. - If P is instantiated as a reference -type, then the argument x is copied from. Otherwise x -is considered to be an rvalue as it is converted to value_type -and inserted into the unordered_multimap. Specifically, in such -cases CopyConstructible is not required of key_type or -mapped_type unless the conversion from P specifically -requires it (e.g. if P is a tuple<const key_type, -mapped_type>, then key_type must be -CopyConstructible). -

    - -

    -The signature taking InputIterator -parameters requires CopyConstructible of both -key_type and mapped_type if the dereferenced -InputIterator returns an lvalue or const rvalue -value_type. -

    -
    - -
    - -

    -Add to 23.4.2.2 [unord.multimap.swap]: -

    - -
    -
    template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
-
    -
    - -

    unordered_set

    - -

    -Change 23.4.3 [unord.set]: -

    - -
    class unordered_set
-{
-    ...
-    unordered_set(const unordered_set&);
-    unordered_set(unordered_set&&);
-    ~unordered_set();
-    unordered_set& operator=(const unordered_set&);
-    unordered_set& operator=(unordered_set&&);
-    ...
-    // modifiers 
-    std::pair<iterator, bool> insert(const value_type& obj); 
-    pair<iterator, bool> insert(value_type&& obj);
-    iterator       insert(iterator hint, const value_type& obj);
-    iterator       insert(iterator hint, value_type&& obj);
-    const_iterator insert(const_iterator hint, const value_type& obj);
-    const_iterator insert(const_iterator hint, value_type&& obj);
-    ...
-    void swap(unordered_set&&);
-    ...
-};
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_set<Key, T, Hash, Pred, Alloc>& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_set<Key, T, Hash, Pred, Alloc>&& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_set<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_set<Key, T, Hash, Pred, Alloc>& y);
-
    - -

    -Add to 23.4.3.1 [unord.set.cnstr]: -

    - -
    -
    template <class InputIterator>
-  unordered_set(InputIterator f, InputIterator l, 
-                size_type n = implementation-defined, 
-                const hasher& hf = hasher(), 
-                const key_equal& eql = key_equal(), 
-                const allocator_type& a = allocator_type());
-
    - -

    - -Requires: If the iterator's dereference operator returns an -lvalue or a const rvalue value_type, then the -value_type shall be CopyConstructible. - -

    -
    - -

    -Add new section [unord.set.modifiers]: -

    - -
    -
    pair<iterator, bool> insert(const value_type& x);
-pair<iterator, bool> insert(value_type&& x);
-iterator       insert(iterator hint, const value_type& x);
-iterator       insert(iterator hint, value_type&& x);
-const_iterator insert(const_iterator hint, const value_type& x);
-const_iterator insert(const_iterator hint, value_type&& x);
-template <class InputIterator>
-  void insert(InputIterator first, InputIterator last);
-
    - -
    - -

    -Requires: Those signatures taking a const -value_type& parameter requires the value_type to -be CopyConstructible. -

    - -

    -The signature taking InputIterator parameters requires -CopyConstructible of value_type if the dereferenced -InputIterator returns an lvalue or const rvalue -value_type. -

    - -
    - -
    - -

    -Add to 23.4.3.2 [unord.set.swap]: -

    - -
    -
    template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_set<Key, T, Hash, Pred, Alloc>& y);
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_set<Key, T, Hash, Pred, Alloc>&& y);
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_set<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_set<Key, T, Hash, Pred, Alloc>& y);
-
    -
    - -

    unordered_multiset

    - -

    -Change 23.4.4 [unord.multiset]: -

    - -
    class unordered_multiset
-{
-    ...
-    unordered_multiset(const unordered_multiset&);
-    unordered_multiset(unordered_multiset&&);
-    ~unordered_multiset();
-    unordered_multiset& operator=(const unordered_multiset&);
-    unordered_multiset& operator=(unordered_multiset&&);
-    ...
-    // modifiers 
-    iterator insert(const value_type& obj); 
-    iterator insert(value_type&& obj);
-    iterator       insert(iterator hint, const value_type& obj);
-    iterator       insert(iterator hint, value_type&& obj);
-    const_iterator insert(const_iterator hint, const value_type& obj);
-    const_iterator insert(const_iterator hint, value_type&& obj);
-    ...
-    void swap(unordered_multiset&&);
-    ...
-};
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multiset<Key, T, Hash, Pred, Alloc>&& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
-
    - -

    -Add to 23.4.4.1 [unord.multiset.cnstr]: -

    - -
    -
    template <class InputIterator>
-  unordered_multiset(InputIterator f, InputIterator l, 
-                size_type n = implementation-defined, 
-                const hasher& hf = hasher(), 
-                const key_equal& eql = key_equal(), 
-                const allocator_type& a = allocator_type());
-
    - -

    - -Requires: If the iterator's dereference operator returns an -lvalue or a const rvalue value_type, then the -value_type shall be CopyConstructible. - -

    -
    - -

    -Add new section [unord.multiset.modifiers]: -

    - -
    -
    iterator insert(const value_type& x);
-iterator insert(value_type&& x);
-iterator       insert(iterator hint, const value_type& x);
-iterator       insert(iterator hint, value_type&& x);
-const_iterator insert(const_iterator hint, const value_type& x);
-const_iterator insert(const_iterator hint, value_type&& x);
-template <class InputIterator>
-  void insert(InputIterator first, InputIterator last);
-
    - -
    - -

    -Requires: Those signatures taking a const -value_type& parameter requires the value_type to -be CopyConstructible. -

    - -

    -The signature taking InputIterator parameters requires -CopyConstructible of value_type if the dereferenced -InputIterator returns an lvalue or const rvalue -value_type. -

    - -
    - -
    - -

    -Add to 23.4.4.2 [unord.multiset.swap]: -

    - -
    -
    template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multiset<Key, T, Hash, Pred, Alloc>&& y);
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
-
    -
    - - - -

    [ -Voted to WP in Bellevue. -]

    - - -

    [ -post Bellevue, Pete notes: -]

    - - -
    -

    -Please remind people who are reviewing issues to check that the text -modifications match the current draft. Issue 676, for example, adds two -overloads for unordered_map::insert taking a hint. One takes a -const_iterator and returns a const_iterator, and the other takes an -iterator and returns an iterator. This was correct at the time the issue -was written, but was changed in Toronto so there is only one hint -overload, taking a const_iterator and returning an iterator. -

    -

    -This issue is not ready. In addition to the relatively minor signature -problem I mentioned earlier, it puts requirements in the wrong places. -Instead of duplicating requirements throughout the template -specifications, it should put them in the front matter that talks about -requirements for unordered containers in general. This presentation -problem is editorial, but I'm not willing to do the extensive rewrite -that it requires. Please put it back into Open status. -

    -
    - - - -

    688. reference_wrapper, cref unsafe, allow binding to rvalues

    -

    Section: 20.6.5.1 [refwrap.const] Status: Open - Submitter: Peter Dimov Date: 2007-05-10

    +

    Section: 20.7.5.1 [refwrap.const] Status: Tentatively Ready + Submitter: Peter Dimov Opened: 2007-05-10 Last modified: 2009-05-23

    View all other issues in [refwrap.const].

    -

    View all issues with Open status.

    +

    View all issues with Tentatively Ready status.

    Discussion:

    A reference_wrapper can be constructed from an rvalue, either by using @@ -8554,11 +8108,93 @@ disallow this source of undefined behavior. Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.

    +

    [ +2009-05-09 Alisdair adds: +]

    + + +
    +

    +Now that ref/cref are constained that T must be an ObjectType, I do not +believe there is any risk of binding ref to a temporary (which would rely on +deducing T to be an rvalue reference type) +

    +

    +However, the problem for cref remains, so I recommend retaining that deleted +overload. +

    +
    + +

    [ +2009-05-10 Howard adds: +]

    + + +
    +

    +Without: +

    + +
    template <class T> void ref(const T&& t) = delete;
+
    +

    +I believe this program will compile: +

    + +
    #include <functional>
+
+struct A {};
+
+const A source() {return A();}
+
+int main()
+{
+   std::reference_wrapper<const A> r = std::ref(source());
+}
+
    +

    +I.e. in: +

    +
    template <ObjectType T> reference_wrapper<T> ref(T& t);
+
    + +

    +this: +

    + +
    ref(source())
+
    +

    +deduces T as const A, and so: +

    + +
    ref(const A& t)
+
    + +

    +will bind to a temporary (tested with a pre-concepts rvalue-ref enabled compiler). +

    +

    +Therefore I think we still need the ref-protection. I respectfully disagree with Alisdair's +comment and am in favor of the proposed wording as it stands. Also, CWG 606 +(noted below) has now been "favorably" resolved. +

    + +
    + +

    [ +Batavia (2009-05): +]

    + +
    +We agree with the proposed resolution. +Move to Tentatively Ready. +

    Proposed resolution:

    -In 20.6 [function.objects], add the following two signatures to the synopsis: +In 20.7 [function.objects], add the following two signatures to the synopsis: 

    template <class T> void ref(const T&& t) = delete;
@@ -8592,292 +8228,212 @@ the "special deduction rule" is disabled with the const T&& pattern.
 
 
 
-
    
-
    691. const_local_iterator cbegin, cend missing from TR1
    
-
    Section: 23.4 [unord], TR1 6.3 [tr.hash] Status: Ready
- Submitter: Joaquín M López Muńoz Date: 2007-06-14
    
-
    View other active issues in [unord].
    
-
    View all other issues in [unord].
    
-
    View all issues with Ready status.
    
-
    Discussion:
    
-
    
-The last version of TR1 does not include the following member
-functions
-for unordered containers:
-
    
-
-
    const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;
-
    
-
-
    
-which looks like an oversight to me. I've checked th TR1 issues lists
-and the latest working draft of the C++0x std (N2284) and haven't
-found any mention to these menfuns or to their absence.
-
    
-
    
-Is this really an oversight, or am I missing something?
-
    
-
-
-
-
    Proposed resolution:
    
-
    
-Add the following two rows to table 93 (unordered associative container
-requirements) in section 23.1.5 [unord.req]:
-
    
-
-
    
-
-
-
-
-
-
- 
-
-
- 
-
-
    Unordered associative container requirements (in addition to container)
    expression return type assertion/note pre/post-condition complexity
    b.cbegin(n) const_local_iterator n shall be in the range [0, bucket_count()). Note: [b.cbegin(n), b.cend(n)) is a valid range containing all of the elements in the nth bucket. Constant
    b.cend(n) const_local_iterator n shall be in the range [0, bucket_count()). Constant
    
-
    
-
-
    
-Add to the synopsis in 23.4.1 [unord.map]:
-
    
-
-
    const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;
-
    
-
-
    
-Add to the synopsis in 23.4.2 [unord.multimap]:
-
    
-
-
    const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;
-
    
-
-
    
-Add to the synopsis in 23.4.3 [unord.set]:
-
    
-
-
    const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;
-
    
-
-
    
-Add to the synopsis in 23.4.4 [unord.multiset]:
-
    
-
-
    const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;
-
    
-
-
-
-
-
-
-
    
-
    692. get_money and put_money should be formatted I/O functions
    
-
    Section: 27.6.4 [ext.manip] Status: Review
- Submitter: Martin Sebor Date: 2007-06-22
    
-
    View other active issues in [ext.manip].
    
-
    View all other issues in [ext.manip].
    
-
    View all issues with Review status.
    
-
    Discussion:
    
-
    
-In a private email Bill Plauger notes:
-
    
-
    
-I  believe that  the function  that  implements get_money
-[from N2072]
-should behave  as a  formatted input function,  and the  function that
-implements put_money should  behave as a formatted output
-function. This  has implications regarding the  skipping of whitespace
-and the handling of errors, among other things.
-
    
-
    
-The words  don't say that  right now and  I'm far from  convinced that
-such a change is editorial.
-
    
-
    
-Martin's response:
-
    
-
    
-I agree that the manipulators should handle exceptions the same way as
-formatted I/O functions do. The text in N2072 assumes so but the
-Returns clause explicitly omits exception handling for the sake
-of brevity. The spec should be clarified to that effect.
-
    
-
    
-As for dealing  with whitespace, I also agree it  would make sense for
-the extractors  and inserters involving the new  manipulators to treat
-it the same way as formatted I/O.
-
    
-
-
-
    Proposed resolution:
    
-
    
-Add  a new  paragraph immediately  above  p4 of 27.6.4 [ext.manip] with  the
-following text:
-
    
-
    
-Effects:  The   expression  in >> get_money(mon, intl)
-described below behaves as a formatted input function (as
-described in 27.6.1.2.1 [istream.formatted.reqmts]).
-
    
-
    
-Also change p4 of 27.6.4 [ext.manip] as follows:
-
    
-
    
-Returns: An object s of unspecified type such that
-if in is  an object of type basic_istream<charT,
-traits>    then    the    expression   in >> get_money(mon, intl) behaves as a formatted input function
-that    calls    f(in, mon, intl)    were
-called. The function f can be defined as...
-
    
-
-
-
    [
-post Bellevue:
-]
    
-
-
-
    
-We recommend moving immediately to Review. We've looked at the issue and
-have a consensus that the proposed resolution is correct, but want an
-iostream expert to sign off. Alisdair has taken the action item to putt
-this up on the reflector for possible movement by Howard to Tenatively
-Ready.
-
    
-
-
-
-
 
    
 
    696. istream::operator>>(int&) broken
    
-
    Section: 27.6.1.2.2 [istream.formatted.arithmetic] Status: New
- Submitter: Martin Sebor Date: 2007-06-23
    
+
    Section: 27.7.1.2.2 [istream.formatted.arithmetic] Status: Open
+ Submitter: Martin Sebor Opened: 2007-06-23  Last modified: 2009-05-28
    
 
    View all other issues in [istream.formatted.arithmetic].
    
-
    View all issues with New status.
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
 From message c++std-lib-17897:
 
    
 
    
-The  code  shown  in  27.6.1.2.2 [istream.formatted.arithmetic] as  the  "as  if"
-implementation  of the  two arithmetic  extractors that  don't  have a
-corresponding     num_get     interface    (i.e.,     the
-short and int  overloads) is subtly buggy in
-how  it  deals  with  EOF, overflow,  and  other  similar
+The code shown in 27.7.1.2.2 [istream.formatted.arithmetic] as the "as if"
+implementation of the two arithmetic extractors that don't have a
+corresponding num_get interface (i.e., the
+short and int overloads) is subtly buggy in
+how it deals with EOF, overflow, and other similar
 conditions (in addition to containing a few typos).
 
    
 
    
-One  problem is  that if  num_get::get() reaches  the EOF
-after reading in  an otherwise valid value that  exceeds the limits of
-the    narrower    type     (but    not    LONG_MIN    or
-LONG_MAX),   it  will   set   err  to
-eofbit.   Because   of  the  if   condition  testing  for
-(err == 0),    the   extractor    won't   set
-failbit  (and presumably,  return  a bogus  value to  the
+One problem is that if num_get::get() reaches the EOF
+after reading in an otherwise valid value that exceeds the limits of
+the narrower type (but not LONG_MIN or
+LONG_MAX), it will set err to
+eofbit. Because of the if condition testing for
+(err == 0), the extractor won't set
+failbit (and presumably, return a bogus value to the
 caller).
 
    
 
    
-Another  problem with  the code  is that  it never  actually  sets the
-argument to  the extracted  value. It can't  happen after the  call to
-setstate() since  the function may  throw, so we  need to
-show when  and how it's done (we  can't just punt as  say: "it happens
-afterwards"). However, it  turns out that showing how  it's done isn't
-quite so  easy since  the argument is  normally left unchanged  by the
-facet on error  except when the error is due  to a misplaced thousands
-separator,  which causes  failbit to  be set  but doesn't
+Another problem with the code is that it never actually sets the
+argument to the extracted value. It can't happen after the call to
+setstate() since the function may throw, so we need to
+show when and how it's done (we can't just punt as say: "it happens
+afterwards"). However, it turns out that showing how it's done isn't
+quite so easy since the argument is normally left unchanged by the
+facet on error except when the error is due to a misplaced thousands
+separator, which causes failbit to be set but doesn't
 prevent the facet from storing the value.
 
    
 
+
    [
+Batavia (2009-05):
+]
    
 
-
    Proposed resolution:
    
+
    
 
    
-
    
-
-
-
-
-
-
    
-
    698. system_error needs const char* constructors
    
-
    Section: 19.4.5.1 [syserr.syserr.overview] Status: Review
- Submitter: Daniel Krügler Date: 2007-06-24
    
-
    View all issues with Review status.
    
-
    Discussion:
    
-
    
-In 19.4.5.1 [syserr.syserr.overview] we have the class definition of
-std::system_error. In contrast to all exception classes, which
-are constructible with a what_arg string (see 19.1 [std.exceptions],
-or ios_base::failure in 27.4.2.1.1 [ios::failure]), only overloads with with
-const string& are possible. For consistency with the re-designed
-remaining exception classes this class should also provide
-c'tors which accept a const char* what_arg string.
+We believe this part of the Standard has been recently adjusted
+and that this issue was addressed during that rewrite.
 
    
 
    
-Please note that this proposed addition makes sense even
-considering the given implementation hint for what(), because
-what_arg is required to be set as what_arg of the base class
-runtime_error, which now has the additional c'tor overload
-accepting a const char*.
+Move to NAD.
 
    
+
    
+
+
    [
+2009-05-28 Howard adds:
+]
    
+
+
+
    
+
    
+I've moved this issue from Tentatively NAD to Open.
+
    
+
+
    
+The current wording of
+N2857
+in 22.4.2.1.2 [facet.num.get.virtuals] p3, stage 3 appears to indicate that
+in parsing arithmetic types, the value is always set, but sometimes in addition
+to setting failbit.
+
    
+
+
      
+
    • 
+If there is a range error, the value is set to min or max, else
+
      • 
+
    • 
+if there is a conversion error, the value is set to 0, else
+
      • 
+
    • 
+if there is a grouping error, the value is set to whatever it would be if grouping were ignored, else
+
      • 
+
    • 
+the value is set to its error-free result.
+
      • 
+
    
+
+
    
+However there is a contradictory sentence in 22.4.2.1.2 [facet.num.get.virtuals] p1.
+
    
+
+
    
+27.7.1.2.2 [istream.formatted.arithmetic] should mimic the behavior of 22.4.2.1.2 [facet.num.get.virtuals]
+(whatever we decide that behavior is) for
+int and short, and currently does not.  I believe that the
+correct code fragment should look like:
+
    
+
+
    typedef num_get<charT,istreambuf_iterator<charT,traits> > numget;
+iostate err = ios_base::goodbit;
+long lval;
+use_facet<numget>(loc).get(*this, 0, *this, err, lval);
+if (lval < numeric_limits<int>::min())
+{
+  err |= ios_base::failbit;
+  val = numeric_limits<int>::min();
+}
+else if (lval > numeric_limits<int>::max())
+{
+  err |= ios_base::failbit;
+  val = numeric_limits<int>::max();
+}
+else
+  val = static_cast<int>(lval);
+setstate(err);
+
    
+
    
 
 
 
    Proposed resolution:
    
 
    
-This proposed wording assumes issue 832 has been accepted and applied to the working paper.
+Change 22.4.2.1.2 [facet.num.get.virtuals], p1:
 
    
 
+
    
+-1- Effects: Reads characters from in, interpreting them
+according to str.flags(), use_facet<ctype<charT>
+>(loc), and use_facet< numpunct<charT>
+>(loc), where loc is str.getloc(). If an error
+occurs, val is unchanged; otherwise it is set to the resulting value.
+
    
+
 
    
-Change 19.4.5.1 [syserr.syserr.overview] Class system_error overview, as indicated:
+Change 27.7.1.2.2 [istream.formatted.arithmetic], p2 and p3:
 
    
 
-
    public:
-  system_error(error_code ec, const string& what_arg);
-  system_error(error_code ec, const char* what_arg);
-  system_error(error_code ec);
-  system_error(int ev, const error_category* ecat,
-      const string& what_arg);
-  system_error(int ev, const error_category* ecat,
-      const char* what_arg);
-  system_error(int ev, const error_category* ecat);
+
    
+
    operator>>(short& val);
+
    
+
    
+
    
+-2- The conversion occurs as if performed by the following code fragment (using the same notation as for 
+the preceding code fragment):
+
    
+
+
    typedef num_get<charT,istreambuf_iterator<charT,traits> > numget;
+iostate err = iostate_base::goodbit;
+long lval;
+use_facet<numget>(loc).get(*this, 0, *this, err, lval);
+if (err != 0)
+  ;
+else if (lval < numeric_limits<short>::min()
+  || numeric_limits<short>::max() < lval)
+     err = ios_base::failbit;
+if (lval < numeric_limits<short>::min())
+{
+  err |= ios_base::failbit;
+  val = numeric_limits<short>::min();
+}
+else if (lval > numeric_limits<short>::max())
+{
+  err |= ios_base::failbit;
+  val = numeric_limits<short>::max();
+}
+else
+  val = static_cast<short>(lval);
+setstate(err);
 
    
 
-
    
-To 19.4.5.2 [syserr.syserr.members] Class system_error members add:
-
    
+
    
 
-
    
-
    system_error(error_code ec, const char* what_arg);
+
    operator>>(int& val);
 
    
 
    
 
    
-Effects: Constructs an object of class system_error.
-
    
-
    
-Postconditions: code() == ec and strcmp(runtime_error::what(), what_arg) == 0.
+-3- The conversion occurs as if performed by the following code fragment (using the same notation as for 
+the preceding code fragment):
 
    
+
+
    typedef num_get<charT,istreambuf_iterator<charT,traits> > numget;
+iostate err = iostate_base::goodbit;
+long lval;
+use_facet<numget>(loc).get(*this, 0, *this, err, lval);
+if (err != 0)
+  ;
+else if (lval < numeric_limits<int>::min()
+  || numeric_limits<int>::max() < lval)
+     err = ios_base::failbit;
+if (lval < numeric_limits<int>::min())
+{
+  err |= ios_base::failbit;
+  val = numeric_limits<int>::min();
+}
+else if (lval > numeric_limits<int>::max())
+{
+  err |= ios_base::failbit;
+  val = numeric_limits<int>::max();
+}
+else
+  val = static_cast<int>(lval);
+setstate(err);
+
    
+
 
    
 
-
    system_error(int ev, const error_category* ecat, const char* what_arg);
-
    
-
-
    
-
    
-Effects: Constructs an object of class system_error.
-
    
-
    
-Postconditions: code() == error_code(ev, ecat) and strcmp(runtime_error::what(), what_arg) == 0.
-
    
 
    
-
    
-
 
 
 
@@ -8885,9 +8441,9 @@ To 19.4.5.2 [syserr.syserr.members] Class system_error members add:
 
 
    
 
    701. assoc laguerre poly's
    
-
    Section: TR1 5.2.1.1 [tr.num.sf.Lnm] Status: New
- Submitter: Christopher Crawford Date: 2007-06-30
    
-
    View all issues with New status.
    
+
    Section: TR1 5.2.1.1 [tr.num.sf.Lnm] Status: Tentatively NAD
+ Submitter: Christopher Crawford Opened: 2007-06-30  Last modified: 2009-05-23
    
+
    View all issues with Tentatively NAD status.
    
 
    Discussion:
    
 
    
 I see that the definition the associated Laguerre
@@ -8912,6 +8468,19 @@ standard, either adding extra functions for real m or switching the
 current ones to double.
 
    
 
+
    [
+Batavia (2009-05):
+]
    
+
+
    
+
    
+We understand the issue, and have opted not to extend as recommended.
+
    
+
    
+Move to NAD.
+
    
+
    
+
 
 
    Proposed resolution:
    
 
    
@@ -8923,14 +8492,27 @@ current ones to double.
 
 
    
 
    702. Restriction in associated Legendre functions
    
-
    Section: TR1 5.2.1.2 [tr.num.sf.Plm] Status: New
- Submitter: Christopher Crawford Date: 2007-06-30
    
-
    View all issues with New status.
    
+
    Section: TR1 5.2.1.2 [tr.num.sf.Plm] Status: Tentatively NAD
+ Submitter: Christopher Crawford Opened: 2007-06-30  Last modified: 2009-05-23
    
+
    View all issues with Tentatively NAD status.
    
 
    Discussion:
    
 
    
 One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should  be
 |x| <= 1, not x >= 0.
    
 
+
    [
+Batavia (2009-05):
+]
    
+
+
    
+
    
+The error has been corrected in the pending IS.
+
    
+
    
+Move to NAD.
+
    
+
    
+
 
 
    Proposed resolution:
    
 
    
@@ -8940,160 +8522,11 @@ One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should  b
 
 
 
-
    
-
    704. MoveAssignable requirement for container value type overly strict
    
-
    Section: 23.1 [container.requirements] Status: Open
- Submitter: Howard Hinnant Date: 2007-05-20
    
-
    View other active issues in [container.requirements].
    
-
    View all other issues in [container.requirements].
    
-
    View all issues with Open status.
    
-
    Discussion:
    
-
    
-The move-related changes inadvertently overwrote the intent of 276.
-Issue 276 removed the requirement of CopyAssignable from
-most of the member functions of node-based containers.  But the move-related changes
-unnecessarily introduced the MoveAssignable requirement for those members which used to
-require CopyAssignable.
-
    
-
-
    
-We also discussed (c++std-lib-18722) the possibility of dropping MoveAssignable
-from some of the sequence requirements.  Additionally the in-place construction
-work may further reduce requirements.  For purposes of an easy reference, here are the
-minimum sequence requirements as I currently understand them.  Those items in requirements
-table in the working draft which do not appear below have been purposefully omitted for
-brevity as they do not have any requirements of this nature.  Some items which do not
-have any requirements of this nature are included below just to confirm that they were
-not omitted by mistake.
-
    
-
-
-
-
-
-
-
-
-
    Container Requirements
    X u(a)value_type must be CopyConstructible
    X u(rv)array and containers with a propagate_never allocator require value_type to be MoveConstructible
    a = uSequences require value_type to be CopyConstructible and CopyAssignable.
-                               Associative containers require value_type to be CopyConstructible.
    a = rvarray requires value_type to be MoveAssignable.
-                                Sequences and Associative containers with propagate_never and propagate_on_copy_construction allocators require value_type to be MoveConstructible.
    swap(a,u)array and containers with propagate_never and
-                  propagate_on_copy_construction allocators require value_type to be Swappable.
    
-
-
    
-
    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
    Sequence Requirements
    X(n)value_type must be DefaultConstructible
    X(n, t)value_type must be CopyConstructible
    X(i, j)If the iterators return an lvalue the value_type must be CopyConstructible.
-                                 If the iterators return an rvalue the value_type must be MoveConstructible.
    a.insert(p, t)The value_type must be CopyConstructible.
-                                        The sequences vector and deque also require the value_type to be CopyAssignable.
    a.insert(p, rv)The value_type must be MoveConstructible.
-                                        The sequences vector and deque also require the value_type to be MoveAssignable.
    a.insert(p, n, t)The value_type must be CopyConstructible.
-                                        The sequences vector and deque also require the value_type to be CopyAssignable.
    a.insert(p, i, j)If the iterators return an lvalue the value_type must be CopyConstructible.
-                                        The sequences vector and deque also require the value_type to be CopyAssignable when the iterators return an lvalue.
-                                        If the iterators return an rvalue the value_type must be MoveConstructible.
-                                        The sequences vector and deque also require the value_type to be MoveAssignable when the iterators return an rvalue.
    a.erase(p)The sequences vector and deque require the value_type to be MoveAssignable.
    a.erase(q1, q2)The sequences vector and deque require the value_type to be MoveAssignable.
    a.clear()
    a.assign(i, j)If the iterators return an lvalue the value_type must be CopyConstructible and CopyAssignable.
-                                        If the iterators return an rvalue the value_type must be MoveConstructible and MoveAssignable.
    a.assign(n, t)The value_type must be CopyConstructible and CopyAssignable.
    a.resize(n)The value_type must be DefaultConstructible.
-                                     The sequence vector also requires the value_type to be MoveConstructible.
    a.resize(n, t)The value_type must be CopyConstructible.
    
-
-
    
-
    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
    Optional Sequence Requirements
    a.front()
    a.back()
    a.push_front(t)The value_type must be CopyConstructible.
    a.push_front(rv)The value_type must be MoveConstructible.
    a.push_back(t)The value_type must be CopyConstructible.
    a.push_back(rv)The value_type must be MoveConstructible.
    a.pop_front()
    a.pop_back()
    a[n]
    a.at[n]
    
-
-
    
-
    
-
-
-
-
-
-
-
-
-
-
-
-
    Associative Container Requirements
    X(i, j)If the iterators return an lvalue the value_type must be CopyConstructible.
-                                 If the iterators return an rvalue the value_type must be MoveConstructible.
    a_uniq.insert(t)The value_type must be CopyConstructible.
    a_uniq.insert(rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
    a_eq.insert(t)The value_type must be CopyConstructible.
    a_eq.insert(rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
    a.insert(p, t)The value_type must be CopyConstructible.
    a.insert(p, rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
    a.insert(i, j)If the iterators return an lvalue the value_type must be CopyConstructible.
-                                        If the iterators return an rvalue the key_type and the mapped_type (if it exists) must be MoveConstructible..
    
-
-
    
-
    
-
-
-
-
-
-
-
-
-
-
-
-
    Unordered Associative Container Requirements
    X(i, j, n, hf, eq)If the iterators return an lvalue the value_type must be CopyConstructible.
-                                 If the iterators return an rvalue the value_type must be MoveConstructible.
    a_uniq.insert(t)The value_type must be CopyConstructible.
    a_uniq.insert(rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
    a_eq.insert(t)The value_type must be CopyConstructible.
    a_eq.insert(rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
    a.insert(p, t)The value_type must be CopyConstructible.
    a.insert(p, rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
    a.insert(i, j)If the iterators return an lvalue the value_type must be CopyConstructible.
-                                        If the iterators return an rvalue the key_type and the mapped_type (if it exists) must be MoveConstructible..
    
-
-
    
-
    
-
-
-
-
-
-
    Miscellaneous Requirements
    map[lvalue-key]The key_type must be CopyConstructible.
-                                         The mapped_type must be DefaultConstructible and MoveConstructible.
    map[rvalue-key]The key_type must be MoveConstructible.
-                                         The mapped_type must be DefaultConstructible and MoveConstructible.
    
-
-
    [
-Kona (2007): Howard and Alan to update requirements table in issue with emplace signatures.
-]
    
-
-
-
    [
-Bellevue: This should be handled as part of the concepts work.
-]
    
-
-
-
-
-
    Proposed resolution:
    
-
-
-
-
-
-
 
    
 
    708. Locales need to be per thread and updated for POSIX changes
    
 
    Section: 22 [localization] Status: Open
- Submitter: Peter Dimov Date: 2007-07-28
    
+ Submitter: Peter Dimov Opened: 2007-07-28  Last modified: 2008-09-17
    
+
    View other active issues in [localization].
    
 
    View all other issues in [localization].
    
 
    View all issues with Open status.
    
 
    Discussion:
    
@@ -9130,6 +8563,13 @@ Kona (2007): Bill and Nick to provide wording.
 ]
    
 
 
+
    [
+San Francisco: Bill and Nick still intend to provide wording, but this
+is a part of the task to be addressed by the group that will look into
+issue 860.
+]
    
+
+
 
 
 
    Proposed resolution:
    
@@ -9140,76 +8580,10 @@ Kona (2007): Bill and Nick to provide wording.
 
 
 
-
    
-
    709. char_traits::not_eof has wrong signature
    
-
    Section: 21.1.3 [char.traits.specializations] Status: Review
- Submitter: Bo Persson Date: 2007-08-13
    
-
    View all other issues in [char.traits.specializations].
    
-
    View all issues with Review status.
    
-
    Discussion:
    
-
    
-The changes made for constexpr in 21.1.3 [char.traits.specializations] have 
-not only changed the not_eof function from pass by const reference to 
-pass by value, it has also changed the parameter type from int_type to 
-char_type.
-
    
-
    
-This doesn't work for type char, and is inconsistent with the 
-requirements in Table 56, Traits requirements, 21.1.1 [char.traits.require].
-
    
-
-
    
-Pete adds:
-
    
-
-
    
-For what it's worth, that may not have been an intentional change. 
-N2349, which detailed the changes for adding constant expressions to 
-the library, has strikeout bars through the const and the & that 
-surround the char_type argument, but none through char_type itself. 
-So the intention may have been just to change to pass by value, with 
-text incorrectly copied from the standard.
-
    
-
-
-
-
    Proposed resolution:
    
-
    
-Change the signature in 21.1.3.1 [char.traits.specializations.char],
-21.1.3.2 [char.traits.specializations.char16_t], 21.1.3.3 [char.traits.specializations.char32_t],
-and 21.1.3.4 [char.traits.specializations.wchar.t] to
-
    
-
-
    static constexpr int_type not_eof(char_type int_type c);
-
    
-
-
-
-
    [
-Bellevue:
-]
    
-
-
-
    
-Resolution: NAD editorial - up to Pete's judgment
-
    
-
-
    [
-Post Sophia Antipolis
-]
    
-
-
-
    
-Moved from Pending NAD Editorial to Review.  The proposed wording appears to be correct but non-editorial.
-
    
-
-
-
-
 
    
 
    711. Contradiction in empty shared_ptr
    
-
    Section: 20.7.12.2.5 [util.smartptr.shared.obs] Status: Open
- Submitter: Peter Dimov Date: 2007-08-24
    
+
    Section: 20.8.13.2.5 [util.smartptr.shared.obs] Status: Open
+ Submitter: Peter Dimov Opened: 2007-08-24  Last modified: 2008-06-18
    
 
    View all other issues in [util.smartptr.shared.obs].
    
 
    View all issues with Open status.
    
 
    Discussion:
    
@@ -9240,7 +8614,7 @@ with a non-NULL stored pointer.
 
    
 
 
    
-This is contradicted by the second sentence in the Returns clause of 20.7.12.2.5 [util.smartptr.shared.obs]:
+This is contradicted by the second sentence in the Returns clause of 20.8.13.2.5 [util.smartptr.shared.obs]:
 
    
 
 
    
@@ -9316,7 +8690,7 @@ that Peter's description above is supporting an undesirable behavior.
 
 
    Proposed resolution:
    
 
    
-In keeping the N2351 spirit and obviously my preference, change 20.7.12.2.5 [util.smartptr.shared.obs]:
+In keeping the N2351 spirit and obviously my preference, change 20.8.13.2.5 [util.smartptr.shared.obs]:
 
    
 
 
    
@@ -9332,7 +8706,7 @@ Alternative proposed resolution: (I won't be happy if we do this, but it's possi
 
    
 
 
    
-Change 20.7.12.2.1 [util.smartptr.shared.const]:
+Change 20.8.13.2.1 [util.smartptr.shared.const]:
 
    
 
 
    
@@ -9355,104 +8729,14 @@ instance with a non-NULL stored pointer.
 
 
 
-
    
-
    713. sort() complexity is too lax
    
-
    Section: 25.3.1.1 [sort] Status: Ready
- Submitter: Matt Austern Date: 2007-08-30
    
-
    View all issues with Ready status.
    
-
    Discussion:
    
-
    
-The complexity of sort() is specified as "Approximately N
-log(N) (where N == last - first ) comparisons on the
-average", with no worst case complicity specified. The intention was to
-allow a median-of-three quicksort implementation, which is usually O(N
-log N) but can be quadratic for pathological inputs. However, there is
-no longer any reason to allow implementers the freedom to have a
-worst-cast-quadratic sort algorithm. Implementers who want to use
-quicksort can use a variant like David Musser's "Introsort" (Software
-Practice and Experience 27:983-993, 1997), which is guaranteed to be O(N
-log N) in the worst case without incurring additional overhead in the
-average case. Most C++ library implementers already do this, and there
-is no reason not to guarantee it in the standard.
-
    
-
-
-
    Proposed resolution:
    
-
    
-In 25.3.1.1 [sort], change the complexity to "O(N log N)", and remove footnote 266:
-
    
-
-
    
-
    
-Complexity: Approximately O(N log(N)) (where N == last - first )
-comparisons on the average.266)
-
    
-
    
-266)
-If the worst case behavior is important stable_sort() (25.3.1.2) or partial_sort()
-(25.3.1.3) should be used.
-
    
-
    
-
-
-
-
-
-
-
    
-
    714. search_n complexity is too lax
    
-
    Section: 25.1.12 [alg.search] Status: Ready
- Submitter: Matt Austern Date: 2007-08-30
    
-
    View all other issues in [alg.search].
    
-
    View all issues with Ready status.
    
-
    Discussion:
    
-
    
-The complexity for search_n (25.1.12 [alg.search] par 7) is specified as "At most
-(last - first ) * count applications of the corresponding predicate if
-count is positive, or 0 otherwise." This is unnecessarily pessimistic.
-Regardless of the value of count, there is no reason to examine any
-element in the range more than once.
-
    
-
-
-
    Proposed resolution:
    
-
    
-Change the complexity to "At most (last - first) applications of the corresponding predicate".
-
    
-
-
    
-
    template<class ForwardIterator, class Size, class T> 
-  ForwardIterator 
-    search_n(ForwardIterator first , ForwardIterator last , Size count , 
-             const T& value ); 
-
-template<class ForwardIterator, class Size, class T, 
-         class BinaryPredicate> 
-  ForwardIterator 
-    search_n(ForwardIterator first , ForwardIterator last , Size count , 
-             const T& value , BinaryPredicate pred );
-
    
-
    
-
    
-Complexity: At most (last - first ) * count applications of the corresponding predicate
-if count is positive, or 0 otherwise.
-
    
-
    
-
    
-
-
-
-
-
-
 
    
 
    716. Production in [re.grammar] not actually modified
    
-
    Section: 28.13 [re.grammar] Status: New
- Submitter: Stephan T. Lavavej Date: 2007-08-31
    
-
    View all issues with New status.
    
+
    Section: 28.14 [re.grammar] Status: Open
+ Submitter: Stephan T. Lavavej Opened: 2007-08-31  Last modified: 2009-05-23
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
-TR1 7.13 [tr.re.grammar]/3 and C++0x WP 28.13 [re.grammar]/3 say:
+TR1 7.13 [tr.re.grammar]/3 and C++0x WP 28.14 [re.grammar]/3 say:
 
    
 
 
    
@@ -9475,6 +8759,22 @@ This definition for CharacterClass appears to be exactly identical to t
 Was an actual modification intended here and accidentally omitted, or was this production accidentally included?
 
    
 
+
    [
+Batavia (2009-05):
+]
    
+
+
    
+
    
+We agree that what is specified is identical to what ECMA-262 specifies.
+Pete would like to take a bit of time to assess whether we had intended,
+but failed, to make a change.
+It would also be useful to hear from John Maddock on the issue.
+
    
+
    
+Move to Open.
+
    
+
    
+
 
 
    Proposed resolution:
    
 
    
@@ -9493,14 +8793,14 @@ Remove this mention of the CharacterClass production.
 
 
    
 
    718. basic_string is not a sequence
    
-
    Section: 21.3 [basic.string] Status: Open
- Submitter: Bo Persson Date: 2007-08-18
    
+
    Section: 21.4 [basic.string] Status: Open
+ Submitter: Bo Persson Opened: 2007-08-18  Last modified: 2008-03-12
    
 
    View other active issues in [basic.string].
    
 
    View all other issues in [basic.string].
    
 
    View all issues with Open status.
    
 
    Discussion:
    
 
    
-Paragraph 21.3 [basic.string]/3 states:
+Paragraph 21.4 [basic.string]/3 states:
 
    
 
 
    
@@ -9511,7 +8811,7 @@ Sequence (23.1.1) and for a Reversible Container (23.1).
 
    
 
 
    
-First of all, 23.1.3 [sequence.reqmts] is no longer "Sequence" but "Sequence container". 
+First of all, 23.2.3 [sequence.reqmts] is no longer "Sequence" but "Sequence container". 
 Secondly, after the resent changes to containers (emplace, push_back, 
 const_iterator parameters to insert and erase), basic_string is not 
 even close to conform to the current requirements.
@@ -9558,8 +8858,9 @@ different, a string abstraction in its own right.
 
 
    
 
    719. std::is_literal type traits should be provided
    
-
    Section: 20.5 [meta] Status: Open
- Submitter: Daniel Krügler Date: 2007-08-25
    
+
    Section: 20.6 [meta] Status: Open
+ Submitter: Daniel Krügler Opened: 2007-08-25  Last modified: 2009-03-14
    
+
    View other active issues in [meta].
    
 
    View all other issues in [meta].
    
 
    View all issues with Open status.
    
 
    Discussion:
    
@@ -9589,7 +8890,7 @@ a new type category "literal", which is defined in 3.9 [basic.types]/p.11:
 
 
    
 I strongly suggest that the standard provides a type traits for
-literal types in 20.5.4.3 [meta.unary.prop] for several reasons:
+literal types in 20.6.4.3 [meta.unary.prop] for several reasons:
 
    
 
 
      
@@ -9612,32 +8913,7 @@ way to portably test the condition for literal class types:
 
 
    
 
-
    
-Here follows a simply example to demonstrate it's usefulness:
-
    
 
-
    template <typename T>
-constexpr typename std::enable_if<std::is_literal<T>::value, T>::type
-abs(T x) {
-  return x < T() ? -x : x;
-}
-
-template <typename T>
-typename std::enable_if<!std::is_literal<T>::value, T>::type
-abs(const T& x) {
-  return x < T() ? -x : x;
-}
-
    
-
-
    
-Here we have the possibility to provide a general abs function
-template that can be used in ICE's if it's argument is a literal
-type which's value is a constant expression, otherwise we
-have an optimized version for arguments which are expensive
-to copy and therefore need the usage of arguments of
-reference type (instead of const T& we could decide to
-use T&&, but that is another issue).
-
    
 
 
    [
 Alisdair is considering preparing a paper listing a number of missing
@@ -9651,7 +8927,7 @@ These two issues should move to OPEN pending AM paper on type traits.
 
 
    Proposed resolution:
    
 
    
-In 20.5.2 [meta.type.synop] in the group "type properties",
+In 20.6.2 [meta.type.synop] in the group "type properties",
 just below the line
 
    
 
@@ -9666,7 +8942,7 @@ add a new one:
 
    
 
 
    
-In 20.5.4.3 [meta.unary.prop], table Type Property Predicates, just
+In 20.6.4.3 [meta.unary.prop], table Type Property Predicates, just
 below the line for the is_pod property add a new line:
 
    
 
@@ -9688,94 +8964,13 @@ array of unknown bound, or
 
 
 
-
    
-
    720. Omissions in constexpr usages
    
-
    Section: 23.2.1 [array], 23.3.5 [template.bitset] Status: Ready
- Submitter: Daniel Krügler Date: 2007-08-25
    
-
    View other active issues in [array].
    
-
    View all other issues in [array].
    
-
    View all issues with Ready status.
    
-
    Discussion:
    
-
      
-
    1. 
-The member function bool array<T,N>::empty() const should be a
-constexpr because this is easily to proof and to implement following it's operational
-semantics defined by Table 87 (Container requirements) which says: a.size() == 0.
-
      2. 
-
    2. 
-The member function bool bitset<N>::test() const must be a
-constexpr (otherwise it would violate the specification of constexpr
-bitset<N>::operator[](size_t) const, because it's return clause delegates to test()).
-
      3. 
-
    3. 
-I wonder how the constructor bitset<N>::bitset(unsigned long) can
-be declared as a constexpr. Current implementations usually have no such bitset
-c'tor which would fulfill the requirements of a constexpr c'tor because they have a
-non-empty c'tor body that typically contains for-loops or memcpy to compute the
-initialisation. What have I overlooked here?
-
      4. 
-
    
-
-
    [
-Sophia Antipolis:
-]
    
-
-
-
    
-
    
-We handle this as two parts
-
    
-
      
-
    1. 
-The proposed resolution is correct; move to ready.
-
      2. 
-
    2. 
-The issue points out a real problem, but the issue is larger than just
-this solution. We believe a paper is needed, applying the full new
-features of C++ (including extensible literals) to update std::bitset.
-We note that we do not consider this new work, and that is should be
-handled by the Library Working Group.
-
      3. 
-
    
-
    
-In order to have a consistent working paper, Alisdair and Daniel produced a new wording for the resolution.
-
    
-
    
-
-
-
-
    Proposed resolution:
    
-
      
-
    1. 
-
      In the class template definition of 23.2.1 [array]/p. 3 change
      
-
      constexpr bool empty() const;
-
      
-
      2. 
-
-
    2. 
-
      In the class template definition of 23.3.5 [template.bitset]/p. 1 change
      
-
      constexpr bool test(size_t pos ) const;
-
      
-
-
      
-and in 23.3.5.2 [bitset.members] change
-
      
-
-
      constexpr bool test(size_t pos ) const;
-
      
-
-
      3. 
-
    
-
-
-
-
-
 
    
 
    721. wstring_convert inconsistensies
    
-
    Section: 22.1.3.2.2 [conversions.string] Status: New
- Submitter: Bo Persson Date: 2007-08-27
    
-
    View all issues with New status.
    
+
    Section: 22.3.3.2.2 [conversions.string] Status: Open
+ Submitter: Bo Persson Opened: 2007-08-27  Last modified: 2008-09-18
    
+
    View other active issues in [conversions.string].
    
+
    View all other issues in [conversions.string].
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
 Paragraph 3 says that the Codecvt template parameter shall meet the 
@@ -9802,6 +8997,14 @@ void main()
 }
    +

    [ +San Francisco: +]

    + + +
    +Bill will propose a resolution. +

    Proposed resolution:

    @@ -9814,14 +9017,17 @@ void main()

    723. basic_regex should be moveable

    -

    Section: 28.8 [re.regex] Status: Open - Submitter: Daniel Krügler Date: 2007-08-29

    +

    Section: 28.9 [re.regex] Status: Open + Submitter: Daniel Krügler Opened: 2007-08-29 Last modified: 2009-03-13

    View all other issues in [re.regex].

    View all issues with Open status.

    Discussion:

    + +

    Addresses UK 316

    +

    According to the current state of the standard draft, the class -template basic_regex, as described in 28.8 [re.regex]/3, is +template basic_regex, as described in 28.9 [re.regex]/3, is neither MoveConstructible nor MoveAssignable. IMO it should be, because typical regex state machines tend to have a rather large data quantum and I have seen several @@ -9838,187 +9044,101 @@ Sophia Antipolis: Needs wording for the semantics, the idea is agreed upon.

    - -

    Proposed resolution:

    -
      -
    1. -

      -In the header <regex> synopsis 28.4 [re.syn], just below the function -template swap add two further overloads: -

      -
      template <class charT, class traits> 
-  void swap(basic_regex<charT, traits>& e1,  basic_regex<charT, traits>& e2);
-template <class charT, class traits>
-  void swap(basic_regex<charT, traits>&& e1, basic_regex<charT, traits>& e2);
-template <class charT, class traits>
-  void swap(basic_regex<charT, traits>& e1,  basic_regex<charT, traits>&& e2);
-
      -

      -In the class definition of basic_regex, just below 28.8 [re.regex]/3, -perform the following changes: -

      -
      2. - -
    2. -

      Just after the copy c'tor:

      -
      basic_regex(basic_regex&&);
-
      -
      3. - -
    3. -

      Just after the copy-assignment op.:

      -
      basic_regex& operator=(basic_regex&&);
-
      -
      4. - -
    4. -

      Just after the first assign overload insert:

      -
      basic_regex& assign(basic_regex&& that);
-
      -
      5. - -
    5. -

      Change the current swap function to read:

      -
      void swap(basic_regex&&);
-
      -
      6. - -
    6. -

      In 28.8.2 [re.regex.construct], just below the copy c'tor add a -corresponding member definition of:

      -
      basic_regex(basic_regex&&);
-
      -
      7. - -
    7. -

      Also in 28.8.2 [re.regex.construct], just below the copy assignment -c'tor add a corresponding member definition of:

      -
      basic_regex& operator=(basic_regex&&);
-
      -
      8. - -
    8. -

      In 28.8.3 [re.regex.assign], just below the first assign overload add -a corresponding member definition of:

      -
      basic_regex& assign(basic_regex&& that);
-
      -
      9. - -
    9. -

      In 28.8.6 [re.regex.swap], change the signature of swap to -say:

      -
      void swap(basic_regex&& e);
-
      -
      10. - -
    10. -

      In 28.8.7.1 [re.regex.nmswap], just below the single binary swap -function, add the two missing overloads:

      -
      template <class charT, class traits>
-  void swap(basic_regex<charT, traits>&& e1, basic_regex<charT, traits>& e2);
-template <class charT, class traits>
-  void swap(basic_regex<charT, traits>& e1, basic_regex<charT, traits>&& e2);
-
      -
      11. -
    - -

    -Of course there would be need of corresponding proper standardese -to describe these additions. -

    - - - - - - -
    -

    724. DefaultConstructible is not defined

    -

    Section: 20.1.1 [utility.arg.requirements] Status: Open - Submitter: Pablo Halpern Date: 2007-09-12

    -

    View other active issues in [utility.arg.requirements].

    -

    View all other issues in [utility.arg.requirements].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -The DefaultConstructible requirement is referenced in -several places in the August 2007 working draft -N2369, -but is not defined anywhere. -

    -

    [ -Bellevue: +Post Summit Daniel updated wording to reflect new "swap rules". ]

    -
    -

    -Walking into the default/value-initialization mess... -

    -

    -Why two lines? Because we need both expressions to be valid. -

    -

    -AJM not sure what the phrase "default constructed" means. This is -unfortunate, as the phrase is already used 24 times in the library! -

    -

    -Example: const int would not accept first line, but will accept the second. -

    -

    -This is an issue that must be solved by concepts, but we might need to solve it independantly first. -

    -

    -It seems that the requirements are the syntax in the proposed first -column is valid, but not clear what semantics we need. -

    -

    -A table where there is no post-condition seems odd, but appears to sum up our position best. -

    -

    -At a minimum an object is declared and is destuctible. -

    -

    -Move to open, as no-one happy to produce wording on the fly. -

    -
    -

    Proposed resolution:

    -In section 20.1.1 [utility.arg.requirements], before table 33, add the -following table: +In the class definition of basic_regex, just below 28.9 [re.regex]/3, +perform the following changes:

    -

    Table 33: DefaultConstructible requirements

    +
      +
    1. +

      +Just after basic_regex(const basic_regex&); insert: +

      -
      - - - - - - - - - - -
      -

      expression

      -       		-

      post-condition

      -
      -

      T - t;
      - T()

      -       		-

      T - is default constructed.

      -
      - -
      +
      basic_regex(basic_regex&&);
+
      +
      2. +
    2. +

      +Just after basic_regex& operator=(const basic_regex&); insert: +

      +
      basic_regex& operator=(basic_regex&&);
+
      +
      3. +
    3. +

      +Just after basic_regex& assign(const basic_regex& that); insert: +

      +
      basic_regex& assign(basic_regex&& that);
+
      +
      4. +
    4. +

      +In 28.9.2 [re.regex.construct], just after p.11 add the following +new member definition: +

      +
      basic_regex(basic_regex&& e);
+
      +
      +

      +Effects: Move-constructs a basic_regex instance from e. +

      +

      +Postconditions: flags() and mark_count() return e.flags() and +e.mark_count(), respectively, +that e had before construction, leaving +e in a valid state with an unspecified value. +

      +

      +Throws: nothing. +

      +
      +
      +
      5. +
    5. +

      +Also in 28.9.2 [re.regex.construct], just after p.18 add the +following new member definition: +

      +
      basic_regex& operator=(basic_regex&& e);
+
      +
      +Effects: Returns the result of assign(std::move(e)). +
      +
      +
      6. +
    6. +

      +In 28.9.3 [re.regex.assign], just after p. 2 add the following new +member definition: +

      +
      basic_regex& assign(basic_regex&& rhs);
+
      +
      +

      +Effects: Move-assigns a basic_regex instance from rhs and returns *this. +

      +

      +Postconditions: flags() and mark_count() return rhs.flags() +and rhs.mark_count(), respectively, that +rhs had before assignment, leaving rhs +in a valid state with an unspecified value. +

      +

      +Throws: nothing. +

      +
      +
      +
      7. +
    @@ -10026,8 +9146,8 @@ following table:

    726. Missing regex_replace() overloads

    -

    Section: 28.11.4 [re.alg.replace] Status: Open - Submitter: Stephan T. Lavavej Date: 2007-09-22

    +

    Section: 28.12.4 [re.alg.replace] Status: Open + Submitter: Stephan T. Lavavej Opened: 2007-09-22 Last modified: 2008-06-18

    View other active issues in [re.alg.replace].

    View all other issues in [re.alg.replace].

    View all issues with Open status.

    @@ -10109,7 +9229,7 @@ Sophia Antipolis:
    We note that Boost already has these overloads. However, the proposed -wording is provided only for 28.11.4 [re.alg.replace]; wording is needed for the synopsis +wording is provided only for 28.12.4 [re.alg.replace]; wording is needed for the synopsis as well. We also note that this has impact on match_results::format, which may require further overloads.
    @@ -10122,7 +9242,7 @@ Provide additional overloads for regex_replace(): one additional overload of the iterator-based form (taking const charT* fmt), and three additional overloads of the convenience form (one taking const charT* str, another taking const charT* fmt, and the third taking both const -charT* str and const charT* fmt). 28.11.4 [re.alg.replace]: +charT* str     and const charT* fmt). 28.12.4 [re.alg.replace]:

    @@ -10188,11 +9308,11 @@ charT* str and const charT* fmt). 28.11.4 [re.alg.replace]:

    727. regex_replace() doesn't accept basic_strings with custom traits and allocators

    -

    Section: 28.11.4 [re.alg.replace] Status: New - Submitter: Stephan T. Lavavej Date: 2007-09-22

    +

    Section: 28.12.4 [re.alg.replace] Status: Open + Submitter: Stephan T. Lavavej Opened: 2007-09-22 Last modified: 2009-05-23

    View other active issues in [re.alg.replace].

    View all other issues in [re.alg.replace].

    -

    View all issues with New status.

    +

    View all issues with Open status.

    Discussion:

    regex_match() and regex_search() take const basic_string<charT, ST, @@ -10201,6 +9321,23 @@ SA>&. regex_replace() takes const basic_string<char allocators.

    +

    [ +Batavia (2009-05): +]

    + +
    +

    +Bill comments, "We need to look at the depth of this change." +

    +

    +Pete remarks that we are here dealing with a convenience function +that saves a user from calling the iterato-based overload. +

    +

    +Move to Open. +

    +
    +

    Proposed resolution:

    @@ -10217,481 +9354,11 @@ arguments. -

    -

    728. Problem in [rand.eng.mers]/6

    -

    Section: 26.4.3.2 [rand.eng.mers] Status: Ready - Submitter: Stephan Tolksdorf Date: 2007-09-21

    -

    View all other issues in [rand.eng.mers].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -The mersenne_twister_engine is required to use a seeding method that is given -as an algorithm parameterized over the number of bits W. I doubt whether the given generalization -of an algorithm that was originally developed only for unsigned 32-bit integers is appropriate -for other bit widths. For instance, W could be theoretically 16 and UIntType a 16-bit integer, in -which case the given multiplier would not fit into the UIntType. Moreover, T. Nishimura and M. -Matsumoto have chosen a dif ferent multiplier for their 64 bit Mersenne Twister -[reference]. -

    - -

    -I see two possible resolutions: -

    - -
      -
    1. Restrict the parameter W of the mersenne_twister_template to values of 32 or 64 and use the -multiplier from [the above reference] for the 64-bit case (my preference)
      2. -
    2. Interpret the state array for any W as a 32-bit array of appropriate length (and a specified byte -order) and always employ the 32-bit algorithm for seeding -
      3. -
    - -

    -See N2424 -for further discussion. -

    - -

    [ -Bellevue: -]

    - - -
    -

    -Stephan Tolksdorf has additional comments on N2424. He comments: "there -is a typo in the required behaviour for mt19937_64: It should be the -10000th (not 100000th) invocation whose value is given, and the value -should be 9981545732273789042 (not 14002232017267485025)." These values -need checking. -

    -

    -Take the proposed recommendation in N2424 and move to REVIEW. -

    -
    - - - - -

    Proposed resolution:

    - -

    -See N2424 -for the proposed resolution. -

    - -

    [ -Stephan Tolksdorf adds pre-Bellevue: -]

    - - -
    -I support the proposed resolution in -N2424, -but there is a typo in the -required behaviour for mt19937_64: It should be the 10000th (not -100000th) invocation whose value is given, and the value should be -9981545732273789042 (not 14002232017267485025). The change to para. 8 -proposed by Charles Karney should also be included in the proposed -wording. -
    - -

    [ -Sophia Antipolis: -]

    - - -
    -Note the main part of the issue is resolved by -N2424. -
    - - - - - - -
    -

    732. Defect in [rand.dist.samp.genpdf]

    -

    Section: 26.4.8.5.3 [rand.dist.samp.genpdf] Status: Open - Submitter: Stephan Tolksdorf Date: 2007-09-21

    -

    View all other issues in [rand.dist.samp.genpdf].

    -

    View all issues with Open status.

    -

    Duplicate of: 795

    -

    Discussion:

    -

    -26.4.8.5.3 [rand.dist.samp.genpdf] describes the interface for a distribution template that is -meant to simulate random numbers from any general distribution given only the density and the -support of the distribution. I'm not aware of any general purpose algorithm that would be capable -of correctly and efficiently implementing the described functionality. From what I know, this is -essentially an unsolved research problem. Existing algorithms either require more knowledge -about the distribution and the problem domain or work only under very limited circumstances. -Even the state of the art special purpose library UNU.RAN does not solve the problem in full -generality, and in any case, testing and customer support for such a library feature would be a -nightmare. -

    - -

    -Possible resolution: For these reasons, I propose to delete section 26.4.8.5.3 [rand.dist.samp.genpdf]. -

    - -

    [ -Bellevue: -]

    - - -
    -

    -Disagreement persists. -

    -

    -Objection to this issue is that this function takes a general functor. -The general approach would be to normalize this function, integrate it, -and take the inverse of the integral, which is not possible in general. -An example function is sin(1+n*x) -- for any spatial frequency that the -implementor chooses, there is a value of n that renders that choice -arbitrarily erroneous. -

    -

    -Correction: The formula above should instead read 1+sin(n*x). -

    -

    -Objector proposes the following possible compromise positions: -

    -
      -
    • -rand.dist.samp.genpdf takes an number of points so that implementor need not guess. -
      • -
    • replace rand.disk.samp.genpdf with an extension to either or both -of the discrete functions to take arguments that take a functor and -number of points in place of the list of probabilities. Reference -issues 793 and 794. -
      • -
    -
    - - - -

    Proposed resolution:

    -

    -See N2424 -for the proposed resolution. -

    - - - - - -
    -

    734. Unnecessary restriction in [rand.dist.norm.chisq]

    -

    Section: 26.4.8.4.3 [rand.dist.norm.chisq] Status: Review - Submitter: Stephan Tolksdorf Date: 2007-09-21

    -

    View all issues with Review status.

    -

    Discussion:

    -

    -chi_squared_distribution, fisher_f_distribution and student_t_distribution -have parameters for the "degrees of freedom" n and m that are specified as integers. For the -following two reasons this is an unnecessary restriction: First, in many applications such as -Bayesian inference or Monte Carlo simulations it is more convenient to treat the respective param- -eters as continuous variables. Second, the standard non-naive algorithms (i.e. -O(1) algorithms) -for simulating from these distributions work with floating-point parameters anyway (all three -distributions could be easily implemented using the Gamma distribution, for instance). -

    - -

    -Similar arguments could in principle be made for the parameters t and k of the discrete -binomial_distribution and negative_binomial_distribution, though in both cases continuous -parameters are less frequently used in practice and in case of the binomial_distribution -the implementation would be significantly complicated by a non-discrete parameter (in most -implementations one would need an approximation of the log-gamma function instead of just the -log-factorial function). -

    - -

    -Possible resolution: For these reasons, I propose to change the type of the respective parameters -to double. -

    - -

    [ -Bellevue: -]

    - - -
    -In N2424. Not wildly enthusiastic, not really felt necessary. Less -frequently used in practice. Not terribly bad either. Move to OPEN. -
    - -

    [ -Sophia Antipolis: -]

    - - -
    -

    -Marc Paterno: The generalizations were explicitly left out when designing the facility. It's harder to test. -

    -

    -Marc Paterno: Ask implementers whether floating-point is a significant burden. -

    -

    -Alisdair: It's neater to do it now, do ask Bill Plauger. -

    -

    -Disposition: move to review with the option for "NAD" if it's not straightforward to implement; unanimous consent. -

    -
    - - - -

    Proposed resolution:

    -

    -See N2424 -for the proposed resolution. -

    - -

    [ -Stephan Tolksdorf adds pre-Bellevue: -]

    - - -
    -

    -In 26.4.8.4.3 [rand.dist.norm.chisq]: -

    - -
    -

    -Delete ", where n is a positive integer" in the first paragraph. -

    - -

    -Replace both occurrences of "explicit chi_squared_distribution(int n = 1);" -with "explicit chi_squared_distribution(RealType n = 1);". -

    - -

    -Replace both occurrences of "int n() const;" with "RealType n() const;". -

    - -
    - -

    -In 26.4.8.4.5 [rand.dist.norm.f]: -

    -
    -

    -Delete ", where m and n are positive integers" in the first paragraph. -

    - -

    -Replace both occurrences of -

    -
    explicit fisher_f_distribution(int m = 1, int n = 1);
-
    -

    -with -

    -
    explicit fisher_f_distribution(RealType m = 1, RealType n = 1);
-
    - -

    -Replace both occurrences of "int m() const;" with "RealType m() const;". -

    - -

    -Replace both occurrences of "int n() const;" with "RealType n() const;". -

    -
    - -

    -In 26.4.8.4.6 [rand.dist.norm.t]: -

    - -
    -

    -Delete ", where n is a positive integer" in the first paragraph. -

    - -

    -Replace both occurrences of "explicit student_t_distribution(int n = 1);" -with "explicit student_t_distribution(RealType n = 1);". -

    - -

    -Replace both occurrences of "int n() const;" with "RealType n() const;". -

    -
    - -
    - - - - - -
    -

    742. Enabling swap for proxy iterators

    -

    Section: 20.1.1 [utility.arg.requirements] Status: Open - Submitter: Howard Hinnant Date: 2007-10-10

    -

    View other active issues in [utility.arg.requirements].

    -

    View all other issues in [utility.arg.requirements].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -This issue was split from 672. 672 now just -deals with changing the requirements of T in the Swappable -requirement from CopyConstructible and CopyAssignable to -MoveConstructible and MoveAssignable. -

    - -

    -This issue seeks to widen the Swappable requirement to support proxy iterators. Here -is example code: -

    - -
    namespace Mine {
-
-template <class T>
-struct proxy {...};
-
-template <class T>
-struct proxied_iterator
-{
-   typedef T value_type;
-   typedef proxy<T> reference;
-   reference operator*() const;
-   ...
-};
-
-struct A
-{
-   // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
-   void swap(A&);
-   ...
-};
-
-void swap(A&, A&);
-void swap(proxy<A>, A&);
-void swap(A&, proxy<A>);
-void swap(proxy<A>, proxy<A>);
-
-}  // Mine
-
-...
-
-Mine::proxied_iterator<Mine::A> i(...)
-Mine::A a;
-swap(*i1, a);
-
    - -

    -The key point to note in the above code is that in the call to swap, *i1 -and a are different types (currently types can only be Swappable with the -same type). A secondary point is that to support proxies, one must be able to pass rvalues -to swap. But note that I am not stating that the general purpose std::swap -should accept rvalues! Only that overloaded swaps, as in the example above, be allowed -to take rvalues. -

    - -

    -That is, no standard library code needs to change. We simply need to have a more flexible -definition of Swappable. -

    - -

    [ -Bellevue: -]

    - - -
    -

    -While we believe Concepts work will define a swappable concept, we -should still resolve this issue if possible to give guidance to the -Concepts work. -

    -

    -Would an ambiguous swap function in two namespaces found by ADL break -this wording? Suggest that the phrase "valid expression" means such a -pair of types would still not be swappable. -

    -

    -Motivation is proxy-iterators, but facility is considerably more -general. Are we happy going so far? -

    -

    -We think this wording is probably correct and probably an improvement on -what's there in the WP. On the other hand, what's already there in the -WP is awfully complicated. Why do we need the two bullet points? They're -too implementation-centric. They don't add anything to the semantics of -what swap() means, which is there in the post-condition. What's wrong -with saying that types are swappable if you can call swap() and it -satisfies the semantics of swapping? -

    -
    - - - -

    Proposed resolution:

    -

    -Change 20.1.1 [utility.arg.requirements]: -

    - -
    - -

    --1- The template definitions in the C++ Standard Library refer to various -named requirements whose details are set out in tables 31-38. In these -tables, T and V are is a types to be supplied by a C++ program -instantiating a template; a, b, and c are -values of type const T; s and t are modifiable -lvalues of type T; u is a value of type (possibly -const) T; and rv is a non-const -rvalue of type T; w is a value of type T; and v is a value of type V. -

    - - - - - - - -
    Table 37: Swappable requirements [swappable]
    expressionreturn typepost-condition
    swap(sw,tv)voidtw has the value originally -held by uv, and -uv has the value originally held -by tw
    -

    -The Swappable requirement is met by satisfying one or more of the following conditions: -

    -
      -
    • -T is Swappable if T and V are -the same type and T satisfies the -CopyConstructible -MoveConstructible requirements (Table 34 -33) and the CopyAssignable -MoveAssignable requirements (Table 36 -35); -
      • -
    • -T is Swappable with V if a namespace scope function named -swap exists in the same namespace as the definition of -T or V, such that the expression -swap(tw,u v) is valid and has the -semantics described in this table. -
      • -
    -
    -
    - - - - - -

    747. We have 3 separate type traits to identify classes supporting no-throw operations

    -

    Section: 20.5.4.3 [meta.unary.prop] Status: Open - Submitter: Alisdair Meredith Date: 2007-10-10

    +

    Section: 20.6.4.3 [meta.unary.prop] Status: Open + Submitter: Alisdair Meredith Opened: 2007-10-10 Last modified: 2008-03-11

    +

    View other active issues in [meta.unary.prop].

    View all other issues in [meta.unary.prop].

    View all issues with Open status.

    Discussion:

    @@ -10765,8 +9432,10 @@ Move to OPEN. Need to talk to Core about this.

    750. The current definition for is_convertible requires that the type be implicitly convertible, so explicit constructors are ignored.

    -

    Section: 20.5.5 [meta.rel] Status: Open - Submitter: Alisdair Meredith Date: 2007-10-10

    +

    Section: 20.6.5 [meta.rel] Status: Open + Submitter: Alisdair Meredith Opened: 2007-10-10 Last modified: 2008-03-11

    +

    View other active issues in [meta.rel].

    +

    View all other issues in [meta.rel].

    View all issues with Open status.

    Discussion:

    @@ -10797,11 +9466,11 @@ These two issues should move to OPEN pending AM paper on type traits.

    751. change pass-by-reference members of vector<bool> to pass-by-value?

    -

    Section: 23.2.7 [vector.bool] Status: New - Submitter: Alisdair Meredith Date: 2007-10-10

    +

    Section: 23.3.7 [vector.bool] Status: Open + Submitter: Alisdair Meredith Opened: 2007-10-10 Last modified: 2008-09-22

    View other active issues in [vector.bool].

    View all other issues in [vector.bool].

    -

    View all issues with New status.

    +

    View all issues with Open status.

    Discussion:

    A number of vector<bool> members take const bool& as arguments. @@ -10841,447 +9510,38 @@ as-if rule.

    - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    752. Allocator complexity requirement

    -

    Section: 20.1.2 [allocator.requirements] Status: Review - Submitter: Hans Boehm Date: 2007-10-11

    -

    View other active issues in [allocator.requirements].

    -

    View all other issues in [allocator.requirements].

    -

    View all issues with Review status.

    -

    Discussion:

    -

    -Did LWG recently discuss 20.1.2 [allocator.requirements]-2, which states that "All the operations -on the allocators are expected to be amortized constant time."? -

    -

    -As I think I pointed out earlier, this is currently fiction for -allocate() if it has to obtain memory from the OS, and it's unclear to -me how to interpret this for construct() and destroy() if they deal with -large objects. Would it be controversial to officially let these take -time linear in the size of the object, as they already do in real life? -

    -

    -Allocate() more blatantly takes time proportional to the size of the -object if you mix in GC. But it's not really a new problem, and I think -we'd be confusing things by leaving the bogus requirements there. The -current requirement on allocate() is generally not important anyway, -since it takes O(size) to construct objects in the resulting space. -There are real performance issues here, but they're all concerned with -the constants, not the asymptotic complexity. -

    - - -

    Proposed resolution:

    -

    -Change 20.1.2 [allocator.requirements]/2: -

    - -
    -

    --2- Table 39 describes the requirements on types manipulated through -allocators. All the operations on the allocators are expected to be -amortized constant time. Table 40 describes the -requirements on allocator types. -

    -
    - - - - - -
    -

    753. Move constructor in draft

    -

    Section: 20.1.1 [utility.arg.requirements] Status: Open - Submitter: Yechezkel Mett Date: 2007-10-14

    -

    View other active issues in [utility.arg.requirements].

    -

    View all other issues in [utility.arg.requirements].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -The draft standard n2369 uses the term move constructor in a few -places, but doesn't seem to define it. -

    - -

    -MoveConstructible requirements are defined in Table 33 in 20.1.1 [utility.arg.requirements] as -follows: -

    - -
    - - - - - - - - - - - -
    MoveConstructible requirements
    expression post-condition
    T t = rv t is equivalent to the value of rv before the construction
    [Note: There is no requirement on the value of rv after the -construction. -- end note]
    -
    - -

    -(where rv is a non-const rvalue of type T). -

    - -

    -So I assume the move constructor is the constructor that would be used -in filling the above requirement. -

    - -

    -For vector::reserve, vector::resize and the vector modifiers given in -23.2.6.4 [vector.modifiers] we have -

    - -
    -Requires: If value_type has a move constructor, that constructor shall -not throw any exceptions. -
    - -

    -Firstly "If value_type has a move constructor" is superfluous; every -type which can be put into a vector has a move constructor (a copy -constructor is also a move constructor). Secondly it means that for -any value_type which has a throwing copy constructor and no other move -constructor these functions cannot be used -- which I think will come -as a shock to people who have been using such types in vector until -now! -

    - -

    -I can see two ways to correct this. The simpler, which is presumably -what was intended, is to say "If value_type has a move constructor and -no copy constructor, the move constructor shall not throw any -exceptions" or "If value_type has a move constructor which changes the -value of its parameter,". -

    - -

    -The other alternative is add to MoveConstructible the requirement that -the expression does not throw. This would mean that not every type -that satisfies the CopyConstructible requirements also satisfies the -MoveConstructible requirements. It would mean changing requirements in -various places in the draft to allow either MoveConstructible or -CopyConstructible, but I think the result would be clearer and -possibly more concise too. -

    - - -

    Proposed resolution:

    -

    -Add new defintions to 17.1 [definitions]: -

    - -
    -

    -move constructor -

    -

    -a constructor which accepts only rvalue arguments of that type, and modifies the rvalue as a -side effect during the construction. -

    -

    -move assignment operator -

    -

    -an assignment operator which accepts only rvalue arguments of that type, and modifies the rvalue as a -side effect during the assignment. -

    -

    -move assignment -

    -

    -use of the move assignment operator. -

    -
    -

    [ -Howard adds post-Bellevue: +San Francisco: ]

    -Unfortunately I believe the wording recommended by the LWG in Bellevue is incorrect. reserve et. al. will use a move constructor -if one is available, else it will use a copy constructor. A type may have both. If the move constructor is -used, it must not throw. If the copy constructor is used, it can throw. The sentence in the proposed wording -is correct without the recommended insertion. The Bellevue LWG recommended moving this issue to Ready. I am -unfortunately pulling it back to Open. But I'm drafting wording to atone for this egregious action. :-) +This is really a clause 17 issue, rather than something specific to vector<bool>. +

    +

    +Move to Open. Alisdair to provide a resolution. Alternately, Howard can +close this as NAD and then open a new issue to handle the general issue +(rather than the vector<bool> one). +

    +

    +Howard: Haven't yet opened new issue. Lacking wording for it.

    - - - - -
    -

    758. shared_ptr and nullptr

    -

    Section: 20.7.12.2 [util.smartptr.shared] Status: Review - Submitter: Joe Gottman Date: 2007-10-31

    -

    View other active issues in [util.smartptr.shared].

    -

    View all other issues in [util.smartptr.shared].

    -

    View all issues with Review status.

    -

    Discussion:

    -

    -Consider the following program: -

    - -
    int main() {
-   shared_ptr<int> p(nullptr); 
-   return 0;
-}
-
    - -

    -This program will fail to compile because shared_ptr uses the following -template constructor to construct itself from pointers: -

    - -
    template <class Y> shared_ptr(Y *);
-
    - -

    -According -to N2431, -the conversion from nullptr_t to Y * is not -deducible, so the above constructor will not be found. There are similar problems with the -constructors that take a pointer and a deleter or a -pointer, a deleter and an allocator, as well as the -corresponding forms of reset(). Note that N2435 -will solve this problem for constructing from just nullptr, but not for constructors that use -deleters or allocators or for reset(). -

    - -

    -In the case of the functions that take deleters, there is the additional -question of what argument should be passed to the deleter when it is -eventually called. There are two reasonable possibilities: nullptr or -static_cast<T *>(0), where T is the template argument of the -shared_ptr. It is not immediately clear which of these is better. If -D::operator() is a template function similar to shared_ptr's -constructor, then d(static_cast<T*>(0)) will compile and d(nullptr) -will not. On the other hand, if D::operator()() takes a parameter that -is a pointer to some type other that T (for instance U* where U derives -from T) then d(nullptr) will compile and d(static_cast<T *>(0)) may not. -

    - -

    [ -Bellevue: -]

    - - -
    -

    -The general idea is right, we need to be able to pass a nullptr to a -shared_ptr, but there are a few borderline editorial issues here. (For -example, the single-argument nullptr_t constructor in the class synopsis -isn't marked explicit, but it is marked explicit in the proposed wording -for 20.6.6.2.1. There is a missing empty parenthesis in the form that -takes a nullptr_t, a deleter, and an allocator.) -

    -

    -More seriously: this issue says that a shared_ptr constructed from a -nullptr is empty. Since "empty" is undefined, it's hard to know whether -that's right. This issue is pending on handling that term better. -

    -

    -Peter suggests definition of empty should be "does not own anything" -

    -

    -Is there an editorial issue that post-conditions should refer to get() = -nullptr, rather than get() = 0? -

    -

    -No strong feeling towards accept or NAD, but prefer to make a decision than leave it open. -

    -

    -Seems there are no technical merits between NAD and Ready, comes down to -"Do we intentially want to allow/disallow null pointers with these -functions". Staw Poll - support null pointers 5 - No null pointers 0 -

    -

    -Move to Ready, modulo editorial comments -

    -
    - -

    [ -post Bellevue Peter adds: -]

    - - -
    -

    -The following wording changes are less intrusive: -

    - -

    -In 20.7.12.2.1 [util.smartptr.shared.const], add: -

    - -
    shared_ptr(nullptr_t);
-
    - -

    -after: -

    - -
    shared_ptr();
-
    - -

    -(Absence of explicit intentional.) -

    - -

    -px.reset( nullptr ) seems a somewhat contrived way to write px.reset(), so -I'm not convinced of its utility. -

    -

    -It's similarly not clear to me whether the deleter constructors need to be -extended to take nullptr, but if they need to: -

    -

    -Add -

    - -
    template<class D> shared_ptr(nullptr_t p, D d);
-template<class D, class A> shared_ptr(nullptr_t p, D d, A a);
-
    - -

    -after -

    - -
    template<class Y, class D> shared_ptr(Y* p, D d);
-template<class Y, class D, class A> shared_ptr(Y* p, D d, A a);
-
    - -

    -Note that this changes the semantics of the new constructors such that they -consistently call d(p) instead of d((T*)0) when p is nullptr. -

    -

    -The ability to be able to pass 0/NULL to a function that takes a shared_ptr -has repeatedly been requested by users, but the other additions that the -proposed resolution makes are not supported by real world demand or -motivating examples. -

    -

    -It might be useful to split the obvious and non-controversial nullptr_t -constructor into a separate issue. Waiting for "empty" to be clarified is -unnecessary; this is effectively an alias for the default constructor. -

    -
    - -

    [ -Sophia Antipolis: -]

    - - -
    -

    -We want to remove the reset functions from the proposed resolution. -

    -

    -The remaining proposed resolution text (addressing the constructors) are wanted. -

    -

    -Disposition: move to review. The review should check the wording in the then-current working draft. -

    -
    - - -

    Proposed resolution:

    -Add the following constructors to 20.7.12.2 [util.smartptr.shared]:

    -
    shared_ptr(nullptr_t);
-template <class D> shared_ptr(nullptr_t, D d);
-template <class D, class A> shared_ptr(nullptr_t, D d, A a);
-
    - - - -

    -Add the following constructor definitions to 20.7.12.2.1 [util.smartptr.shared.const]: -

    - -
    -
     explicit shared_ptr(nullptr_t);
-
    -
    -

    -Effects: Constructs an empty shared_ptr object. -

    -

    -Postconditions: use_count() == 0 && get() == 0. -

    -

    -Throws: nothing. -

    -
    -
    - -
    -
    template <class D> shared_ptr(nullptr_t, D d);
-template <class D, class A> shared_ptr<nullptr_t, D d, A a);
-
    -
    -

    -Requires: D shall be CopyConstructible. The copy constructor and -destructor of D shall not throw exceptions. The expression -d(static_cast<T *>(0)) shall be well-formed, shall have well defined behavior, -and shall not throw exceptions. A shall be an allocator (20.1.2 [allocator.requirements]). -The copy constructor and destructor of A shall not throw -exceptions. -

    -

    -Effects: Constructs a shared_ptr object that owns a null pointer of type T * -and deleter d. The -second constructor shall use a copy of a to allocate memory for -internal use. -

    -

    -Postconditions: use_count() == 1 and get() == 0. -

    -

    -Throws: bad_alloc, or an implementation-defined exception when a -resource other than memory could not be obtained. -

    -

    -Exception safety: If an exception is thrown, d(static_cast<Y *>(nullptr)) is called. -

    -
    -
    - - - -

    760. The emplace issue

    -

    Section: 23.1 [container.requirements] Status: Open - Submitter: Paolo Carlini Date: 2007-11-11

    +

    Section: 23.2 [container.requirements] Status: Open + Submitter: Paolo Carlini Opened: 2007-11-11 Last modified: 2008-06-02

    View other active issues in [container.requirements].

    View all other issues in [container.requirements].

    View all issues with Open status.

    @@ -11290,9 +9550,9 @@ resource other than memory could not be obtained. In an emplace member function the function parameter pack may be bound to a priori unlimited number of objects: some or all of them can be elements of the container itself. Apparently, in order to conform to the -blanket statement 23.1 [container.requirements]/11, the implementation must check all of them for +blanket statement 23.2 [container.requirements]/11, the implementation must check all of them for that possibility. A possible solution can involve extending the -exception in 23.1 [container.requirements]/12 also to the emplace member. As a side note, the +exception in 23.2 [container.requirements]/12 also to the emplace member. As a side note, the push_back and push_front member functions are luckily not affected by this problem, can be efficiently implemented anyway

    @@ -11322,7 +9582,7 @@ Resolution: Alan Talbot to rework language, then set state to Review.

    Proposed resolution:

    -Add after 23.1 [container.requirements]/12: +Add after 23.2 [container.requirements]/12:

    @@ -11344,318 +9604,13 @@ sub-objects of elements of the container. No diagnostic required. -
    -

    762. std::unique_ptr requires complete type?

    -

    Section: 20.7.11 [unique.ptr] Status: Ready - Submitter: Daniel Krügler Date: 2007-11-30

    -

    View all other issues in [unique.ptr].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -In contrast to the proposed std::shared_ptr, std::unique_ptr -does currently not support incomplete types, because it -gives no explicit grant - thus instantiating unique_ptr with -an incomplete pointee type T automatically belongs to -undefined behaviour according to 17.4.3.7 [res.on.functions]/2, last -bullet. This is an unnecessary restriction and prevents -many well-established patterns - like the bridge pattern - -for std::unique_ptr. -

    - -

    [ -Bellevue: -]

    - - -
    -Move to open. The LWG is comfortable with the intent of allowing -incomplete types and making unique_ptr more like shared_ptr, but we are -not comfortable with the wording. The specification for unique_ptr -should be more like that of shared_ptr. We need to know, for individual -member functions, which ones require their types to be complete. The -shared_ptr specification is careful to say that for each function, and -we need the same level of care here. We also aren't comfortable with the -"part of the operational semantic" language; it's not used elsewhere in -the standard, and it's not clear what it means. We need a volunteer to -produce new wording. -
    - - -

    Proposed resolution:

    -

    -The proposed changes in the following revision refers to the current state of -N2521 including the assumption that 20.7.11.4 [unique.ptr.compiletime] will be removed -according to the current state of 740. -

    -

    -The specialization unique_ptr<T[]> has some more restrictive constraints on -type-completeness on T than unique_ptr<T>. The following proposed wordings -try to cope with that. If the committee sees less usefulness on relaxed -constraints on unique_ptr<T[]>, the alternative would be to stop this relaxation -e.g. by adding one further bullet to 20.7.11.3 [unique.ptr.runtime]/1: -"T shall be a complete type, if used as template argument of -unique_ptr<T[], D> -

    -

    -This issue has some overlap with 673, but it seems not to cause any -problems with this one, -because 673 adds only optional requirements on D that do not conflict -with the here discussed -ones, provided that D::pointer's operations (including default -construction, copy construction/assignment, -and pointer conversion) are specified not to throw, otherwise this -would have impact on the -current specification of unique_ptr. -

    - -
      -
    1. -

      -In 20.7.11 [unique.ptr]/2 add as the last sentence to the existing para: -

      - -
      -The unique_ptr provides a semantics of strict ownership. A -unique_ptr owns the object it holds a pointer to. A -unique_ptr is not CopyConstructible, nor -CopyAssignable, however it is MoveConstructible and -MoveAssignable. The template parameter T of -unique_ptr may be an incomplete type. [ Note: The -uses of unique_ptr include providing exception safety for -dynamically allcoated memory, passing ownership of dynamically allocated -memory to a function, and returning dynamically allocated memory from a -function. -- end note ] -
      -
      2. - -
    2. -

      -20.7.11.2.1 [unique.ptr.single.ctor]/1: No changes necessary. -

      - -
      -

      [ -N.B.: We only need the requirement that D is DefaultConstructible. -The current wording says just this. -]

      - -
      -
      3. - -
    3. -

      -In 20.7.11.2.1 [unique.ptr.single.ctor]/5 change the requires clause to say: -

      - -
      -

      -Requires: The expression D()(p) shall be well formed. The default constructor -of D shall not throw an exception. -D must not be a reference type. - -D shall be default constructible, and that construction -shall not throw an exception. - -

      -

      [ -N.B.: There is no need that the expression D()(p) is well-formed at -this point. I assume that the current wording is based on the -corresponding shared_ptr wording. In case of shared_ptr this -requirement is necessary, because the corresponding c'tor *can* fail -and must invoke delete p/d(p) in this case. Unique_ptr is simpler in -this regard. The *only* functions that must insist on well-formedness -and well-definedness of the expression get_deleter()(get()) are (1) -the destructor and (2) reset. The reasoning for the wording change to -explicitly require DefaultConstructible of D is to guarantee that -invocation of -D's default c'tor is both well-formed and well-defined. Note also that -we do *not* need the -requirement that T must be complete, also in contrast to shared_ptr. -Shared_ptr needs this, because it's c'tor is a template c'tor which -potentially requires Convertible<Y*, X*>, which -again requires Completeness of Y, if !SameType<X, Y> -]

      - -
      -
      4. - -
    4. -

      -Merge 20.7.11.2.1 [unique.ptr.single.ctor]/12+13 thereby removing the sentence -of 12, but transferring the "requires" to 13: -

      - -
      -

      -Requires: If D is not an lvalue-reference type then[..] -

      -

      [ -N.B.: For the same reasons as for (3), there is no need that d(p) is -well-formed/well-defined at this point. The current wording guarantees -all what we need, namely that the initialization of both the T* -pointer and the D deleter are well-formed and well-defined. -]

      - -
      -
      5. - -
    5. -20.7.11.2.1 [unique.ptr.single.ctor]/17: No changes necessary. -
      6. -
    6. -

      20.7.11.2.1 [unique.ptr.single.ctor]/21:

      - -
      -Requires: If D is not a reference type, construction of -the deleter D from an rvalue of type E shall be well -formed and shall not throw an exception. If D is a reference -type, then E shall be the same type as D (diagnostic -required). U* shall be implicitly convertible to T*. -[Note: These requirements imply that T and U -be complete types. -- end note] -
      - -

      [ -N.B.: The current wording of 21 already implicitly guarantees that U -is completely defined, because it requires that Convertible<U*, T*> is -true. If the committee wishes this explicit requirement can be added, -e.g. "U shall be a complete type." -]

      - -
      7. - -
    7. -

      -20.7.11.2.2 [unique.ptr.single.dtor]: Just before p1 add a new paragraph: -

      -
      -

      -Requires: The expression get_deleter()(get()) shall be well-formed, -shall have well-defined behavior, and shall not throw exceptions. -[Note: The use of default_delete requires T to -be a complete type. -- end note] -

      -

      [ -N.B.: This requirement ensures that the whole responsibility on -type-completeness of T is delegated to this expression. -]

      - -
      -
      8. - -
    8. -

      -20.7.11.2.3 [unique.ptr.single.asgn]/1: No changes necessary, except the -current editorial issue, that "must shall" has to be changed to -"shall", but this change is not a special part of this resolution. -

      - -

      [ -N.B. The current wording is sufficient, because we can delegate all -further requirements on the requirements of the effects clause -]

      - -
      9. - -
    9. -

      -20.7.11.2.3 [unique.ptr.single.asgn]/6: -

      - -
      -Requires: Assignment of the deleter D from an rvalue -D shall not throw an exception. U* shall be implicitly -convertible to T*. -[Note: These requirements imply that T and U -be complete types. -- end note] -
      - -

      [ -N.B.: The current wording of p. 6 already implicitly guarantees that -U is completely defined, because it requires that Convertible<U*, T*> -is true, see (6)+(8). -]

      - -
      10. - -
    10. -

      -20.7.11.2.3 [unique.ptr.single.asgn]/11: No changes necessary. -

      -

      [ -N.B.: Delegation to requirements of effects clause is sufficient. -]

      - -
      11. - -
    11. -20.7.11.2.4 [unique.ptr.single.observers]/1+4+7+9+11: -
      12. - -
      -
      T* operator->() const;
      -
      -Note: Use typically requires T shall be complete. -- end note] -
      -
      - -
    12. -20.7.11.2.5 [unique.ptr.single.modifiers]/1: No changes necessary. -
      13. - -
    13. -

      -20.7.11.2.5 [unique.ptr.single.modifiers]/4: Just before p. 4 add a new paragraph: -

      -
      -Requires: The expression get_deleter()(get()) shall be well-formed, -shall have well-defined behavior, and shall not throw exceptions. -
      -
      14. - -
    14. -20.7.11.2.5 [unique.ptr.single.modifiers]/7: No changes necessary. -
      15. - -
    15. -

      -20.7.11.3 [unique.ptr.runtime]: Add one additional bullet on paragraph 1: -

      - -
      -

      -A specialization for array types is provided with a slightly altered interface. -

      - -
        -
      • -... -
        • -
      • -T shall be a complete type. -
        • -
      -
      -
      16. -
    - -

    [ -post Bellevue: Daniel provided revised wording. -]

    - - - - - - -

    765. more on iterator validity

    -

    Section: 24.1 [iterator.requirements] Status: New - Submitter: Martin Sebor Date: 2007-12-14

    -

    View other active issues in [iterator.requirements].

    -

    View all other issues in [iterator.requirements].

    -

    View all issues with New status.

    +

    Section: 24.2 [iterator.concepts] Status: Tentatively Ready + Submitter: Martin Sebor Opened: 2007-12-14 Last modified: 2009-03-09

    +

    View other active issues in [iterator.concepts].

    +

    View all other issues in [iterator.concepts].

    +

    View all issues with Tentatively Ready status.

    Discussion:

    @@ -11724,247 +9679,77 @@ well-defined. Expert opinions on this differ as does the behavior of popular implementations for some standard Containers.

    +

    [ +San Francisco: +]

    -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    769. std::function should use nullptr_t instead of "unspecified-null-pointer-type"

    -

    Section: 20.6.15.2 [func.wrap.func] Status: Ready - Submitter: Daniel Krügler Date: 2008-01-10

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -N2461 already replaced in 20.6.15.2 [func.wrap.func] it's originally proposed -(implicit) conversion operator to "unspecified-bool-type" by the new -explicit bool conversion, but the inverse conversion should also -use the new std::nullptr_t type instead of "unspecified-null-pointer- -type". -

    - - -

    Proposed resolution:

    - -

    -In 20.6 [function.objects], header <functional> synopsis replace: -

    - -
    template<class R, class... ArgTypes>
-  bool operator==(const function<R(ArgTypes...)>&, unspecified-null-pointer-type nullptr_t);
-template<class R, class... ArgTypes>
-  bool operator==(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>&);
-template<class R, class... ArgTypes>
-  bool operator!=(const function<R(ArgTypes...)>&, unspecified-null-pointer-type nullptr_t);
-template<class R, class... ArgTypes>
-  bool operator!=(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>&);
-
    - -

    -In the class function synopsis of 20.6.15.2 [func.wrap.func] replace -

    - -
    function(unspecified-null-pointer-type nullptr_t);
-...
-function& operator=(unspecified-null-pointer-type nullptr_t);
-
    - -

    -In 20.6.15.2 [func.wrap.func], "Null pointer comparisons" replace: -

    - -
    template <class R, class... ArgTypes>
-  bool operator==(const function<R(ArgTypes...)>&, unspecified-null-pointer-type nullptr_t);
-template <class R, class... ArgTypes>
-  bool operator==(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>&);
-template <class R, class... ArgTypes>
-  bool operator!=(const function<R(ArgTypes...)>&, unspecified-null-pointer-type nullptr_t);
-template <class R, class... ArgTypes>
-  bool operator!=(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>&);
-
    - -

    -In 20.6.15.2.1 [func.wrap.func.con], replace -

    - -
    function(unspecified-null-pointer-type nullptr_t);
-...
-function& operator=(unspecified-null-pointer-type nullptr_t);
-
    - -

    -In 20.6.15.2.6 [func.wrap.func.nullptr], replace -

    - -
    template <class R, class... ArgTypes>
-  bool operator==(const function<R(ArgTypes...)>& f, unspecified-null-pointer-type nullptr_t);
-template <class R, class... ArgTypes>
-  bool operator==(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>& f);
-
    - -

    -and replace -

    - -
    template <class R, class... ArgTypes>
-  bool operator!=(const function<R(ArgTypes...)>& f, unspecified-null-pointer-type nullptr_t);
-template <class R, class... ArgTypes>
-  bool operator!=(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>& f);
-
    - - - - - - -
    -

    771. Impossible throws clause in [string.conversions]

    -

    Section: 21.4 [string.conversions] Status: Ready - Submitter: Daniel Krügler Date: 2008-01-13

    -

    View other active issues in [string.conversions].

    -

    View all other issues in [string.conversions].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -The new to_string and to_wstring functions described in 21.4 [string.conversions] -have throws clauses (paragraphs 8 and 16) which say: -

    -
    -Throws: nothing +

    Pablo: add a note to the last bullet of paragraph 11 of 23.1.1 +clarifying that the end() iterator doesn't refer to an element and that +it can therefore be invalidated. +

    +

    +Proposed wording: +

    +
    +[Note: The end() iterator does not refer to any element and can +therefore be invalidated. -- end note] +
    +

    +Howard will add this proposed wording to the issue and then move it to Review. +

    -

    -Since all overloads return either a std::string or a std::wstring by value -this throws clause is impossible to realize in general, since the basic_string -constructors can fail due to out-of-memory conditions. Either these throws -clauses should be removed or should be more detailled like: -

    +

    [ +Post Summit: +]

    +
    -Throws: Nothing if the string construction throws nothing -
    -

    -Further there is an editorial issue in p. 14: All three to_wstring -overloads return a string, which should be wstring instead (The -header <string> synopsis of 21.2 [string.classes] is correct in this -regard). +Lawrence: suggestion: "Note: The end() iterator does not refer to any element"

    +

    +Walter: "Note: The end() iterator can nevertheless be invalidated, +because it does not refer to any element." +

    +

    +Nick: "The end() iterator does not refer to any element. It is therefore +subject to being invalidated." +

    +

    +Consensus: go with Nick +

    +

    +With that update, Recommend Tentatively Ready. +

    +

    Proposed resolution:

    -In 21.4 [string.conversions], remove the paragraphs 8 and 16. +Add to 23.2.1 [container.requirements.general], p11:

    -
    string to_string(long long val); 
-string to_string(unsigned long long val); 
-string to_string(long double val); 
-
    -
    -Throws: nothing -
    -
    - -
    -
    wstring to_wstring(long long val); 
-wstring to_wstring(unsigned long long val); 
-wstring to_wstring(long double val); 
-
    -
    -Throws: nothing -
    -
    - - - - - - -
    -

    772. Impossible return clause in [string.conversions]

    -

    Section: 21.4 [string.conversions] Status: Ready - Submitter: Daniel Krügler Date: 2008-01-13

    -

    View other active issues in [string.conversions].

    -

    View all other issues in [string.conversions].

    -

    View all issues with Ready status.

    -

    Discussion:

    -The return clause 21.4 [string.conversions]/paragraph 15 of the new to_wstring -overloads says: +Unless otherwise specified (see 23.1.4.1, 23.1.5.1, 23.2.2.3, and +23.2.6.4) all container types defined in this Clause meet the following +additional requirements:

    - -
    -Returns: each function returns a wstring object holding the character -representation of the value of its argument that would be generated by -calling wsprintf(buf, fmt, val) with a format specifier of L"%lld", L"%ulld", -or L"%f", respectively. +
      +
    • ...
      • +
    • +no swap() function invalidates any references, pointers, or +iterators referring to the elements of the containers being swapped. +[Note: The end() iterator does not refer to any element. It is therefore +subject to being invalidated. -- end note] +
      • +
    -

    -Problem is: There does not exist any wsprintf function in C99 (I checked -the 2nd edition of ISO 9899, and the first and the second corrigenda from -2001-09-01 and 2004-11-15). What probably meant here is the function -swprintf from <wchar.h>/<cwchar>, but this has the non-equivalent -declaration: -

    - -
    int swprintf(wchar_t * restrict s, size_t n,
-const wchar_t * restrict format, ...);
-
    - -

    -therefore the paragraph needs to mention the size_t parameter n. -

    - - - -

    Proposed resolution:

    -

    -Change the current wording of 21.4 [string.conversions]/p. 15 to: -

    - -
    -Returns: eEach function returns a -wstring object holding the character representation of the -value of its argument that would be generated by calling -wsswprintf(buf, bufsz, fmt, -val) with a format specifier fmt of L"%lld", -L"%ulld", or L"%f", respectively, where buf -designates an internal character buffer of sufficient size bufsz. -
    - -

    -[Hint to the editor: The resolution also adds to mention the name of -the format specifier "fmt"] -

    - -

    -I also would like to remark that the current wording of it's equivalent -paragraph 7 should also mention the meaning of buf and fmt. -

    - -

    -Change the current wording of 21.4 [string.conversions]/p. 7 to: -

    - -
    -Returns: eEach function returns a string object holding the -character representation of the value of its argument that would be -generated by calling sprintf(buf, fmt, val) with a format specifier fmt of -"%lld", "%ulld", or "%f", respectively, where buf designates an internal -character buffer of sufficient size. -
    - - @@ -11972,7 +9757,7 @@ character buffer of sufficient size.

    774. Member swap undefined for most containers

    Section: 23 [containers] Status: Open - Submitter: Alisdair Meredith Date: 2008-01-14

    + Submitter: Alisdair Meredith Opened: 2008-01-14 Last modified: 2008-05-11

    View other active issues in [containers].

    View all other issues in [containers].

    View all issues with Open status.

    @@ -12050,142 +9835,18 @@ Wording provided in -
    -

    776. Undescribed assign function of std::array

    -

    Section: 23.2.1 [array] Status: Ready - Submitter: Daniel Krügler Date: 2008-01-20

    -

    View other active issues in [array].

    -

    View all other issues in [array].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -The class template array synopsis in 23.2.1 [array]/3 declares a member -function -

    - -
    void assign(const T& u);
-
    - -

    -which's semantic is no-where described. Since this signature is -not part of the container requirements, such a semantic cannot -be derived by those. -

    - -

    -I found only one reference to this function in the issue list, -588 where the question is raised: -

    - -
    -what's the effect of calling assign(T&) on a zero-sized array? -
    - -

    -which does not answer the basic question of this issue. -

    - -

    -If this function shall be part of the std::array, it's probable -semantic should correspond to that of boost::array, but of -course such wording must be added. -

    - - -

    Proposed resolution:

    -

    -Just after the section 23.2.1.4 [array.data] add the following new section: -

    - -

    -23.2.1.5 array::fill [array.fill] -

    - -
    -
    void fill(const T& u);
-
    - -

    -1: Effects: fill_n(begin(), N, u) -

    -
    - -

    -[N.B: I wonder, why class array does not have a "modifiers" -section. If it had, then assign would naturally belong to it] -

    - -

    -Change the synopsis in 23.2.1 [array]/3: -

    - -
    template <class T, size_t N>
-struct array { 
-  ...
-  void assign fill(const T& u);
-  ...
-
    - - -

    [ -Bellevue: -]

    - - -
    -

    -Suggest substituting "fill" instead of "assign". -

    -

    -Set state to Review given substitution of "fill" for "assign". -

    -
    - - - - -
    -

    779. Resolution of #283 incomplete

    -

    Section: 25.2.8 [alg.remove] Status: Ready - Submitter: Daniel Krügler Date: 2008-01-25

    -

    View all other issues in [alg.remove].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -The resolution of 283 did not resolve similar necessary changes for algorithm -remove_copy[_if], -which seems to be an oversight. -

    - - -

    Proposed resolution:

    -

    -In 25.2.8 [alg.remove]/p.6, replace the N2461 requires clause with: -

    - -
    -Requires: Type T is EqualityComparable (31). The ranges [first,last) -and [result,result + (last - first)) shall not overlap. The expression *result = *first shall be -valid. -
    - - - - - -

    780. std::merge() specification incorrect/insufficient

    -

    Section: 25.3.4 [alg.merge] Status: New - Submitter: Daniel Krügler Date: 2008-01-25

    -

    View all issues with New status.

    +

    Section: 25.5.4 [alg.merge] Status: Review + Submitter: Daniel Krügler Opened: 2008-01-25 Last modified: 2009-05-23

    +

    View all issues with Review status.

    Discussion:

    Though issue 283 has fixed many open issues, it seems that some are still open:

    -Both 25.3.4 [lib.alg.merge] in 14882:2003 and 25.3.4 [alg.merge] in N2461 +Both 25.3.4 [lib.alg.merge] in 14882:2003 and 25.5.4 [alg.merge] in N2461 have no Requires element and the Effects element contains some requirements, which is probably editorial. Worse is that:

    @@ -12214,11 +9875,62 @@ clause mentions comp again) +

    [ +Post Summit Alisdair adds: +]

    + + +
    +

    +Suggest: +

    +
    +(where last is equal to next(result, distance(first1, last1) + +distance(first2, last2)), such that resulting range will be sorted in +non-decreasing order; that is, for every iterator i in [result,last) other +than result, the condition *i < *prev(i) or, respectively, comp(*i, +*prev(i)) will be false. +
    + +

    +Note that this might still not be technically accurate in the case of +InputIterators, depending on other resolutions working their way through the +system (1011). +

    +
    + +

    [ +Post Summit Daniel adds: +]

    + + +
    +If we want to use prev and next here (Note: merge +is sufficiently satisfied with InputIterator) we should instead *add* more to +25 [algorithms]/6, but I can currently not propose any good wording for this. +
    + +

    [ +Batavia (2009-05): +]

    + +
    +

    +Pete points out the existing wording in [algorithms]/4 +that permits the use of + in algorithm specifications. +

    +

    +Alisdair points out that that wording may not apply to input iterators. +

    +

    +Move to Review. +

    +

    Proposed resolution:

    -In 25.3.4 [alg.merge] replace p.1+ 2: +In 25.5.4 [alg.merge] replace p.1+ 2:

    @@ -12237,8 +9949,7 @@ respectively, comp(*i, *(i - 1)) will be false. Requires: The resulting range shall not overlap with either of the original ranges. The list will be sorted in non-decreasing order according to the ordering defined by comp; that is, for every iterator i in [first,last) other than first, the condition *i < *(i - 1) or -comp(*i, *(i - 1)) will be false. The results of the expressions *first1 and *first2 -shall be writable to the output iterator. +comp(*i, *(i - 1)) will be false.

    @@ -12257,9 +9968,9 @@ other parts of <algorithm> show, just a matter of consistency]

    785. Random Number Requirements in TR1

    -

    Section: TR1 5.1.4.5 [tr.rand.eng.disc], TR1 5.1.4.6 [tr.rand.eng.xor] Status: New - Submitter: John Maddock Date: 2008-01-15

    -

    View all issues with New status.

    +

    Section: TR1 5.1.4.5 [tr.rand.eng.disc], TR1 5.1.4.6 [tr.rand.eng.xor] Status: Tentatively NAD + Submitter: John Maddock Opened: 2008-01-15 Last modified: 2009-05-23

    +

    View all issues with Tentatively NAD status.

    Discussion:

    Table 16 of TR1 requires that all Pseudo Random Number generators have a @@ -12308,78 +10019,62 @@ constructor, therefore the omission of the seed() member functions appears to be an oversight.

    - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    787. complexity of binary_search

    -

    Section: 25.3.3.4 [binary.search] Status: Ready - Submitter: Daniel Krügler Date: 2007-09-08

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -In 25.3.3.4 [binary.search]/3 the complexity of binary_search is described as -

    - -
    -At most log(last - first) + 2 comparisons. -
    - -

    -This should be precised and brought in line with the nomenclature used for -lower_bound, upper_bound, and equal_range. -

    - -

    -All existing libraries I'm aware of, delegate to -lower_bound (+ one further comparison). Since -issue 384 -has now WP status, the resolution of #787 should -be brought in-line with 384 by changing the + 2 -to + O(1). -

    -

    [ -Sophia Antipolis: +Post Summit Daniel adds: ]

    -Alisdair prefers to apply an upper bound instead of O(1), but that would -require fixing for lower_bound, upper_bound etc. as well. If he really -cares about it, he'll send an issue to Howard. +Recommend NAD: xor_combine does no longer exist and discard_block[_engine] +has now the required seed overload accepting a result_type, which shall be an +unsigned integral type.
    +

    [ +Batavia (2009-05): +]

    + +
    +Move to NAD as recommended. +

    Proposed resolution:

    -Change 25.3.3.4 [binary.search]/3 +NAD Recommended.

    -
    -Complexity: At most log2(last - first) + 2 O(1) comparisons. -
    -

    788. ambiguity in [istream.iterator]

    -

    Section: 24.5.1 [istream.iterator] Status: New - Submitter: Martin Sebor Date: 2008-02-06

    +

    Section: 24.6.1 [istream.iterator] Status: Open + Submitter: Martin Sebor Opened: 2008-02-06 Last modified: 2009-03-14

    View other active issues in [istream.iterator].

    View all other issues in [istream.iterator].

    -

    View all issues with New status.

    +

    View all issues with Open status.

    Discussion:

    + +

    Addresses UK 287

    + +
    +

    +It is not clear what the initial state of an istream_iterator should be. Is +_value_ initialized by reading the stream, or default/value initialized? If +it is initialized by reading the stream, what happens if the initialization +is deferred until first dereference, when ideally the iterator value should +have been that of an end-of-stream iterator which is not safely +dereferencable? +

    + +

    +Recommendation: Specify _value_ is initialized by reading the stream, or +the iterator takes on the end-of-stream value if the stream is empty. +

    +
    +

    The description of how an istream_iterator object becomes an end-of-stream iterator is a) ambiguous and b) out of date WRT @@ -12419,10 +10114,20 @@ Also I would prefer to be explicit about calling fail() here (there is no operator void*() anymore.)

    +

    [ +Summit: +]

    + + +
    +Moved from Ready to Open for the purposes of using this issue to address NB UK 287. +Martin to handle. +
    +

    Proposed resolution:

    -Change 24.5.1 [istream.iterator]/1: +Change 24.6.1 [istream.iterator]/1:

    @@ -12448,424 +10153,10 @@ is used a new value is read. -
    -

    793. discrete_distribution missing constructor

    -

    Section: 26.4.8.5.1 [rand.dist.samp.discrete] Status: Open - Submitter: P.J. Plauger Date: 2008-02-09

    -

    View other active issues in [rand.dist.samp.discrete].

    -

    View all other issues in [rand.dist.samp.discrete].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -discrete_distribution should have a constructor like: -

    - -
    template<class _Fn>
-  discrete_distribution(result_type _Count, double _Low, double _High,
-                        _Fn& _Func);
-
    - -

    -(Makes it easier to fill a histogram with function values over a range.) -

    - -

    [ -Bellevue: -]

    - - -
    -How do you specify the function so that it does not return negative -values? If you do it is a bad construction. This requirement is already -there. Where in each bin does one evaluate the function? In the middle. -Need to revisit tomorrow. -
    - -

    [ -Sophia Antipolis: -]

    - - -
    -

    -Bill is not requesting this. -

    -

    -Marc Paterno: _Fn cannot return negative values at the points where the -function is sampled. It is sampled in the middle of each bin. _Fn cannot -return 0 everywhere it is sampled. -

    -

    -Jens: lambda expressions are rvalues -

    -

    -Add a library issue to provide an -initializer_list<double> constructor for -discrete_distribution. -

    -

    -Marc Paterno: dislikes reference for _Fn parameter. Make it pass-by-value (to use lambda), -use std::ref to wrap giant-state function objects. -

    -

    -Daniel: See random_shuffle, pass-by-rvalue-reference. -

    -

    -Daniel to draft wording. -

    -
    - -

    [ -Pre San Francisco, Daniel provided wording: -]

    - - -
    -The here proposed changes of the WP refer to the current state of -N2691. -During the Sophia Antipolis meeting two different proposals came up -regarding the functor argument type, either by value or by rvalue-reference. -For consistence with existing conventions (state-free algorithms and the -general_pdf_distribution c'tor signature) the author decided to propose a -function argument that is provided by value. If severe concerns exists that -stateful functions would be of dominant relevance, it should be possible to -replace the two occurrences of Func by Func&& in this proposal as part -of an editorial process. -
    - - - -

    Proposed resolution:

    -
      -
    1. -

      -In 26.4.8.5.1 [rand.dist.samp.discrete]/1, class discrete_distribution, just -before the member declaration -

      - -
      explicit discrete_distribution(const param_type& parm);
-
      - -

      -insert: -

      - - -
      template<typename Func>
-discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
-
      -
      2. - -
    2. -

      -Between p.4 and p.5 insert a series of new paragraphs as part of the -new member description:: -

      -
      template<typename Func>
-discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
-
      - -

      -Complexity: Exactly nf invocations of fw. -

      -

      -Requires: -

      -
        -
      1. -fw shall be callable with one argument of type double, and shall -return values of a type convertible to double;
        2. - -
      2. If nf > 0, the relation xmin < xmax shall hold, and for all sample values -xk, fw(xk) shall return a weight value wk that is non-negative, non-NaN, -and non-infinity;
        3. - -
      3. The following relations shall hold: nf ≥ 0, and 0 < S = w0+. . .+wn-1.
        4. - -
      - -

      -Effects: -

      -
        -
      1. If nf == 0, sets n = 1 and lets the sequence w have length n = 1 and - consist of the single value w0 = 1.
        2. - -
      2. -

        Otherwise, sets n = nf, deltax = (xmax - xmin)/n and xcent = xmin + -0.5 * deltax.

        -
        For each k = 0, . . . ,n-1, calculates:
-  xk = xcent + k * deltax
-  wk = fw(xk)
-
        -
        3. -
      3. -

        Constructs a discrete_distribution object with probabilities:

        -
        pk = wk/S  for k = 0, . . . , n-1.
-
        -
        4. -
      -
      -
      3. -
    - - - - - -
    -

    794. piecewise_constant_distribution missing constructor

    -

    Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: Open - Submitter: P.J. Plauger Date: 2008-02-09

    -

    View other active issues in [rand.dist.samp.pconst].

    -

    View all other issues in [rand.dist.samp.pconst].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -piecewise_constant_distribution should have a constructor like: -

    - -
    template<class _Fn>
-   piecewise_constant_distribution(size_t _Count,
-            _Ty _Low, _Ty _High, _Fn& _Func);
-
    - -

    -(Makes it easier to fill a histogram with function values over a range. -The two (reference 793) make a sensible replacement for -general_pdf_distribution.) -

    - -

    [ -Sophia Antipolis: -]

    - - -
    -

    -Marc: uses variable width of bins and weight for each bin. This is not -giving enough flexibility to control both variables. -

    -

    -Add a library issue to provide an constructor taking an -initializer_list<double> and _Fn for piecewise_constant_distribution. -

    -

    -Daniel to draft wording. -

    -
    - -

    [ -Pre San Francisco, Daniel provided wording. -]

    - - -
    -The here proposed changes of the WP refer to the current state of -N2691. -For reasons explained in 793, the author decided to propose a function -argument that is provided by value. The issue proposes a c'tor signature, -that does not take advantage of the full flexibility of -piecewise_constant_distribution, -because it restricts on a constant bin width, but the use-case seems to -be popular enough to justify it's introduction. -
    - - - -

    Proposed resolution:

    - -
      -
    1. -

      -In 26.4.8.5.2 [rand.dist.samp.pconst]/1, class piecewise_constant_distribution, -just before the member declaration -

      - -
      explicit piecewise_constant_distribution(const param_type& parm);
-
      -

      -insert: -

      -
      template<typename Func>
-piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
-
      -
      2. - -
    2. -

      -Between p.4 and p.5 insert a new sequence of paragraphs nominated -below as [p5_1], [p5_2], -[p5_3], and [p5_4] as part of the new member description: -

      - -
      template<typename Func>
-piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
-
      -
      -

      -[p5_1] Complexity: Exactly nf invocations of fw. -

      -

      -[p5_2] Requires: -

      -
        -
      1. fw shall be callable with one argument of type RealType, and shall -return values of a type convertible to double; -
        2. -
      2. -For all sample values xk defined below, fw(xk) shall return a weight -value wk that is non-negative, non-NaN, and non-infinity; -
        3. -
      3. -The following relations shall hold: xmin < xmax, and -0 < S = w0+. . .+wn-1. -
        4. -
      -

      -[p5_3] Effects: -

      -
        -
      1. -

        If nf == 0,

        -
          -
        1. -sets deltax = xmax - xmin, and
          2. -
        2. lets the sequence w have length n = 1 and consist of the single - value w0 = 1, and
          3. -
        3. lets the sequence b have length n+1 with b0 = xmin and - b1 = xmax -
          4. -
        -
        2. -
      2. -

        Otherwise,

        -
          -
        1. sets n = nf, deltax = (xmax - xmin)/n, - xcent = xmin + 0.5 * deltax, and -
          2. -

        2. lets the sequences w and b have length n and n+1, resp. and

          -
          for each k = 0, . . . ,n-1, calculates:
-  dxk = k * deltax
-  bk = xmin + dxk
-  xk = xcent + dxk
-  wk = fw(xk),
-
          -

          and

          -
          3. -
        3. sets bn = xmax
          4. -
        -
        3. -
      3. -

        -Constructs a piecewise_constant_distribution object with -the above computed sequence b as the interval boundaries -and with the probability densities: -

        -
        ρk = wk/(S * deltax)  for k = 0, . . . , n-1.
-
        -
        4. -
      -

      -[p5_4] Remarks: In this context, the subintervals [bk, bk+1) are commonly - known as the bins of a histogram. -

      -
      -
      -
      3. -
    - - - - - - -
    -

    800. Issues in 26.4.7.1 [rand.util.seedseq](6)

    -

    Section: 26.4.7.1 [rand.util.seedseq] Status: Open - Submitter: Stephan Tolksdorf Date: 2008-02-18

    -

    View other active issues in [rand.util.seedseq].

    -

    View all other issues in [rand.util.seedseq].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -The for-loop in the algorithm specification has n iterations, where n is -defined to be end - begin, i.e. the number of supplied w-bit quantities. -Previous versions of this algorithm and the general logic behind it -suggest that this is an oversight and that in the context of the -for-loop n should be the number of full 32-bit quantities in b (rounded -upwards). If w is 64, the current algorithm throws away half of all bits -in b. If w is 16, the current algorithm sets half of all elements in v -to 0. -

    - -

    -There are two more minor issues: -

    - -
      -
    • -Strictly speaking end - begin is not defined since -InputIterator is not required to be a random access iterator. -
      • -
    • -Currently all integral types are allowed as input to the seed_seq -constructor, including bool. IMHO allowing bools unnecessarily -complicates the implementation without any real benefit to the user. -I'd suggest to exclude bools as input. -
      • -
    - -

    [ -Bellevue: -]

    - - -
    -Move to OPEN Bill will try to propose a resolution by the next meeting. -
    - -

    [ -post Bellevue: Bill provided wording. -]

    - - -

    -This issue is made moot if 803 is accepted. -

    - - - -

    Proposed resolution:

    -

    -Replace 26.4.7.1 [rand.util.seedseq] paragraph 6 with: -

    - -
    -

    -Effects: Constructs a seed_seq object by effectively concatenating the -low-order u bits of each of the elements of the supplied sequence [begin, -end) -in ascending order of significance to make a (possibly very large) unsigned -binary number b having a total of n bits, and then carrying out the -following -algorithm: -

    - -
    for( v.clear(); n > 0; n -= 32 )
-   v.push_back(b mod 232), b /= 232;
-
    -
    - - - - -

    801. tuple and pair trivial members

    -

    Section: 20.4 [tuple] Status: Open - Submitter: Lawrence Crowl Date: 2008-02-18

    -

    View other active issues in [tuple].

    +

    Section: 20.5 [tuple] Status: Open + Submitter: Lawrence Crowl Opened: 2008-02-18 Last modified: 2009-05-30

    View all other issues in [tuple].

    View all issues with Open status.

    Discussion:

    @@ -12959,1126 +10250,35 @@ tabled until Alisdair's proposals are disposed of.

    - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    803. Simplification of seed_seq::seq_seq

    -

    Section: 26.4.7.1 [rand.util.seedseq] Status: Review - Submitter: Charles Karney Date: 2008-02-22

    -

    View other active issues in [rand.util.seedseq].

    -

    View all other issues in [rand.util.seedseq].

    -

    View all issues with Review status.

    -

    Discussion:

    -

    -seed_seq(InputIterator begin, InputIterator end); constructs a seed_seq -object repacking the bits of supplied sequence [begin, end) into a -32-bit vector. -

    -

    -This repacking triggers several problems: -

    -
      -
    1. -Distinctness of the output of seed_seq::generate required the -introduction of the initial "if (w < 32) v.push_back(n);" (Otherwise -the unsigned short vectors [1, 0] and [1] generate the same sequence.) -
      2. -
    2. -Portability demanded the introduction of the template parameter u. -(Otherwise some sequences could not be obtained on computers where no -integer types are exactly 32-bits wide.) -
      3. -
    3. -The description and algorithm have become unduly complicated. -
      4. -
    -

    -I propose simplifying this seed_seq constructor to be "32-bit only". -Despite it's being simpler, there is NO loss of functionality (see -below). -

    -

    -Here's how the description would read -

    -
    -

    -26.4.7.1 [rand.util.seedseq] Class seed_seq -

    - -
    -
    template<class InputIterator>
-  seed_seq(InputIterator begin, InputIterator end);
-
    -
    -

    -5 Requires: NO CHANGE -

    -

    -6 Effects: Constructs a seed_seq object by -

    -
    -
    for (InputIterator s = begin; s != end; ++s)
-   v.push_back((*s) mod 2^32);
-
    -
    -
    -
    -
    - -

    -Discussion: -

    -

    -The chief virtues here are simplicity, portability, and generality. -

    -
      -
    • -Simplicity -- compare the above specification with the -n2461 proposal. -
      • -
    • -Portability -- with iterator_traits<InputIterator>::value_type = -uint_least32_t the user is guaranteed to get the same behavior across -platforms. -
      • -
    • -Generality -- any behavior that the -n2461 -proposal can achieve can be -obtained with this simpler proposal (albeit with a shuffling of bits -in the input sequence). -
      • -
    -

    -Arguments (and counter-arguments) against making this change (and -retaining the -n2461 -behavior) are: -

    -
      -
    • -

      -The user can pass an array of unsigned char and seed_seq will nicely - repack it. -

      -

      - Response: So what? Consider the seed string "ABC". The - n2461 - proposal results in -

      -
      v = { 0x3, 0x434241 };
-
      -

      -while the simplified proposal yields -

      -
      v = { 0x41, 0x42, 0x43 };
-
      -

      -The results produced by seed_seq::generate with the two inputs are -different but nevertheless equivalently "mixed up" and this remains -true even if the seed string is long. -

      -
      • -
    • -

      -With long strings (e.g., with bit-length comparable to the number of - bits in the state), v is longer (by a factor of 4) with the simplified - proposal and seed_seq::generate will be slower. -

      -

      -Response: It's unlikely that the efficiency of seed_seq::generate will - be a big issue. If it is, the user is free to repack the seed vector - before constructing seed_seq. -

      -
      • -
    • -

      -A user can pass an array of 64-bit integers and all the bits will be - used. -

      -

      - Response: Indeed. However, there are many instances in the - n2461 - where integers are silently coerced to a narrower width and this - should just be a case of the user needing to read the documentation. - The user can of course get equivalent behavior by repacking his seed - into 32-bit pieces. Furthermore, the unportability of the - n2461 - proposal with -

      -
      unsigned long s[] = {1, 2, 3, 4};
-seed_seq q(s, s+4);
-
      -

      - which typically results in v = {1, 2, 3, 4} on 32-bit machines and in -v = {1, 0, 2, 0, 3, 0, 4, 0} on 64-bit machines is a major pitfall for - unsuspecting users. -

      -
      • -
    - -

    -Note: this proposal renders moot issues 782 and 800. -

    -

    [ -Bellevue: +2009-05-27 Daniel adds: ]

    -Walter needs to ask Fermilab for guidance. Defer till tomorrow. Bill likes the proposed resolution. -
    - -

    [ -Sophia Antipolis: -]

    - - -
    -

    -Marc Paterno wants portable behavior between 32bit and 64bit machines; -we've gone to significant trouble to support portability of engines and -their values. -

    -

    -Jens: the new algorithm looks perfectly portable -

    -

    -Marc Paterno to review off-line. -

    -

    -Modify the proposed resolution to read "Constructs a seed_seq object by the following algorithm ..." -

    -

    -Disposition: move to review; unanimous consent. -

    -

    -(moots 782 and 800) -

    -
    - - - -

    Proposed resolution:

    -

    -Change 26.4.7.1 [rand.util.seedseq]: -

    - -
    -
    template<class InputIterator, 
-  size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>
-  seed_seq(InputIterator begin, InputIterator end);
-
    -
    -

    --5- Requires: InputIterator shall satisfy the requirements of an input iterator (24.1.1) -such that iterator_traits<InputIterator>::value_type shall denote an integral type. -

    -

    --6- Constructs a seed_seq object by the following algorithm rearranging some or all of the bits of the supplied sequence -[begin,end) of w-bit quantities into 32-bit units, as if by the following: -

    -

    -First extract the rightmost u bits from each of the n = end -- begin elements of the supplied sequence and concatenate all the -extracted bits to initialize a single (possibly very large) unsigned -binary number, b = ∑n-1i=0 (begin[i] -mod 2u) ˇ 2wˇi (in which the bits of each begin[i] -are treated as denoting an unsigned quantity). Then carry out -the following algorithm: -

    -
    
-v.clear(); 
-if ($w$ < 32) 
-  v.push_back($n$); 
-for( ; $n$ > 0; --$n$) 
-  v.push_back(b mod 232), b /= 232;
-
    -
    -
    
-for (InputIterator s = begin; s != end; ++s)
-   v.push_back((*s) mod 232);
-
    -
    -
    -
    - - - - - -
    -

    804. Some problems with classes error_code/error_condition

    -

    Section: 19.4 [syserr] Status: Review - Submitter: Daniel Krügler Date: 2008-02-24

    -

    View other active issues in [syserr].

    -

    View all other issues in [syserr].

    -

    View all issues with Review status.

    -

    Discussion:

    -
      -
    1. -

      -19.4.2.1 [syserr.errcode.overview]/1, class error_code and -19.4.3.1 [syserr.errcondition.overview]/, class error_condition synopses -declare an expository data member cat_: -

      -
      const error_category& cat_; // exposition only
-
      -

      -which is used to define the semantics of several members. The decision -to use a member of reference type lead to several problems: -

      -
        -
      1. -The classes are not (Copy)Assignable, which is probably not the intent. -
        2. -
      2. -The post conditions of all modifiers from -19.4.2.3 [syserr.errcode.modifiers] and 19.4.3.3 [syserr.errcondition.modifiers], resp., -cannot be fulfilled. -
        3. -
      -

      -The simple fix would be to replace the reference by a pointer member. -

      -
      2. - -
    2. -I would like to give the editorial remark that in both classes the -constrained operator= -overload (template with ErrorCodeEnum argument) makes in invalid -usage of std::enable_if: By using the default value for the second enable_if -parameter the return type would be defined to be void& even in otherwise -valid circumstances - this return type must be explicitly provided (In -error_condition the first declaration uses an explicit value, but of wrong -type). -
      3. - -
    3. -The member function message throws clauses ( -19.4.1.2 [syserr.errcat.virtuals]/10, 19.4.2.4 [syserr.errcode.observers]/8, and -19.4.3.4 [syserr.errcondition.observers]/6) guarantee "throws nothing", -although -they return a std::string by value, which might throw in out-of-memory -conditions (see related issue 771). -
      4. -
    - -

    [ -Sophia Antipolis: -]

    - - -
    -

    -Part A: NAD (editorial), cleared by the resolution of issue 832. -

    -

    -Part B: Technically correct, save for typo. Rendered moot by the concept proposal -(N2620) NAD (editorial). -

    -

    -Part C: We agree; this is consistent with the resolution of issue 721. -

    -

    -Howard: please ping Beman, asking him to clear away parts A and B from -the wording in the proposed resolution, so it is clear to the editor -what needs to be applied to the working paper. -

    -

    -Beman provided updated wording. Since issue 832 is not going -forward, the provided wording includes resolution of part A. -

    -
    - - - -

    Proposed resolution:

    - -

    -Resolution of part A: -

    -
    -

    -Change 19.4.2.1 [syserr.errcode.overview] Class error_code overview synopsis as indicated: -

    - -
    private:
-  int val_;                    // exposition only
-  const error_category&* cat_; // exposition only
-
    - -

    -Change 19.4.2.2 [syserr.errcode.constructors] Class error_code constructors as indicated: -

    - -
    -
    error_code();
-
    -
    -

    -Effects: Constructs an object of type error_code. -

    -

    -Postconditions: val_ == 0 and cat_ == &system_category. -

    -

    -Throws: Nothing. -

    -
    -
    error_code(int val, const error_category& cat);
-
    -
    -

    -Effects: Constructs an object of type error_code. -

    -

    -Postconditions: val_ == val and cat_ == &cat. -

    -

    -Throws: Nothing. -

    -
    -
    - -

    -Change 19.4.2.3 [syserr.errcode.modifiers] Class error_code modifiers as indicated: -

    - -
    -
    void assign(int val, const error_category& cat);
-
    -
    -

    -Postconditions: val_ == val and cat_ == &cat. -

    -

    -Throws: Nothing. -

    -
    -
    - -

    -Change 19.4.2.4 [syserr.errcode.observers] Class error_code observers as indicated: -

    - -
    -const error_category& category() const; -
    -

    -Returns: *cat_. -

    -

    -Throws: Nothing. -

    -
    -
    - -

    -Change 19.4.3.1 [syserr.errcondition.overview] Class error_condition overview synopsis as indicated: -

    - -
    private:
-  int val_;                    // exposition only
-  const error_category&* cat_; // exposition only
-
    - -

    -Change 19.4.3.2 [syserr.errcondition.constructors] Class error_condition constructors as indicated: -

    -

    [ -(If the proposed resolution of issue 805 has already been applied, the -name posix_category will have been changed to generic_category. That has -no effect on this resolution.) -]

    - - -
    -
    error_condition();
-
    -
    -

    -Effects: Constructs an object of type error_condition. -

    -

    -Postconditions: val_ == 0 and cat_ == &posix_category. -

    -

    -Throws: Nothing. -

    -
    -
    error_condition(int val, const error_category& cat);
-
    -
    -

    -Effects: Constructs an object of type error_condition. -

    -

    -Postconditions: val_ == val and cat_ == &cat. -

    -

    -Throws: Nothing. -

    -
    -
    - -

    -Change 19.4.3.3 [syserr.errcondition.modifiers] Class error_condition modifiers as indicated: -

    - -
    -void assign(int val, const error_category& cat); -
    -

    -Postconditions: val_ == val and cat_ == &cat. -

    -

    -Throws: Nothing. -

    -
    -
    - -

    -Change 19.4.3.4 [syserr.errcondition.observers] Class error_condition observers as indicated: -

    - -
    -const error_category& category() const; -
    -

    -Returns: *cat_. -

    -

    -Throws: Nothing. -

    -
    -
    -
    - -

    -Resolution of part C: -

    - -
    - -

    -In 19.4.1.2 [syserr.errcat.virtuals], remove the throws clause p. 10. -

    - -
    -
    virtual string message(int ev) const = 0;
-
    - -
    -

    -Returns: A string that describes the error condition denoted by ev. -

    -

    -Throws: Nothing. -

    -
    -
    - -

    -In 19.4.2.4 [syserr.errcode.observers], remove the throws clause p. 8. -

    - -
    -
    string message() const;
-
    -
    -

    -Returns: category().message(value()). -

    -

    -Throws: Nothing. -

    -
    -
    - -

    -In 19.4.3.4 [syserr.errcondition.observers], remove the throws clause p. 6. -

    - -
    -
    string message() const;
-
    -
    -

    -Returns: category().message(value()). -

    -

    -Throws: Nothing. -

    -
    -
    - -
    - - - - - - -
    -

    805. posix_error::posix_errno concerns

    -

    Section: 19.4 [syserr] Status: Ready - Submitter: Jens Maurer Date: 2008-02-24

    -

    View other active issues in [syserr].

    -

    View all other issues in [syserr].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -19.4 [syserr] -

    - -
    namespace posix_error {
-  enum posix_errno {
-    address_family_not_supported, // EAFNOSUPPORT
-    ...
-
    - -

    -should rather use the new scoped-enum facility (7.2 [dcl.enum]), -which would avoid the necessity for a new posix_error -namespace, if I understand correctly. -

    - -

    [ -Further discussion: -]

    - - -
    -

    -See N2347, -Strongly Typed Enums, since renamed Scoped Enums. -

    -

    -Alberto Ganesh Barbati also raised this issue in private email, and also proposed the scoped-enum solution. -

    -

    -Nick Stoughton asked in Bellevue that posix_error and posix_errno not be used as names. The LWG agreed. -

    -

    -The wording for the Proposed resolution was provided by Beman Dawes. -

    +This is partly solved by 1117.

    Proposed resolution:

    -Change System error support 19.4 [syserr] as indicated:

    -
    namespace posix_error {
-  enum posix_errno class errc {
-    address_family_not_supported, // EAFNOSUPPORT
-    ...
-    wrong_protocol_type, // EPROTOTYPE
-  };
-} // namespace posix_error
-
-template <> struct is_error_condition_enum<posix_error::posix_errno errc>
-  : public true_type {}
-
-namespace posix_error {
-  error_code make_error_code(posix_errno errc e);
-  error_condition make_error_condition(posix_errno errc e);
-} // namespace posix_error
-
    - -

    -Change System error support 19.4 [syserr] : -

    - -
    -The is_error_code_enum and is_error_condition_enum templates may be -specialized for user-defined types to indicate that such a type is -eligible for class error_code and class error_condition automatic -conversions, respectively. -
    - -

    -Change System error support 19.4 [syserr] and its subsections: -

    - -
    -
      -
    • -remove all occurrences of posix_error:: -
      • -
    • -change all instances of posix_errno to errc -
      • -
    • -change all instances of posix_category to generic_category -
      • -
    • -change all instances of get_posix_category to get_generic_category -
      • -
    -
    - -

    -Change Error category objects 19.4.1.5 [syserr.errcat.objects], paragraph 2: -

    - -
    -Remarks: The object's default_error_condition and equivalent virtual -functions shall behave as specified for the class error_category. The -object's name virtual function shall return a pointer to the string -"POSIX" "GENERIC". -
    - -

    -Change 19.4.2.5 [syserr.errcode.nonmembers] Class error_code non-member functions as indicated: -

    - -
    -
    error_code make_error_code(posix_errno errc e);
-
    - -
    -Returns: error_code(static_cast<int>(e), posixgeneric_category). -
    -
    - -

    -Change 19.4.3.5 [syserr.errcondition.nonmembers] Class error_condition non-member functions as indicated: -

    - -
    -
    error_condition make_error_condition(posix_errno errc e);
-
    - -
    -Returns: error_condition(static_cast<int>(e), posixgeneric_category). -
    -
    - - - -

    Rationale:

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Names Considered
    portable -Too non-specific. Did not wish to reserve such a common word in -namespace std. Not quite the right meaning, either. -
    portable_error -Too long. Explicit qualification is always required for scoped enums, so -a short name is desirable. Not quite the right meaning, either. May be -misleading because *_error in the std lib is usually an exception class -name. -
    std_error -Fairly short, yet explicit. But in fully qualified names like -std::std_error::not_enough_memory, the std_ would be unfortunate. Not -quite the right meaning, either. May be misleading because *_error in -the std lib is usually an exception class name. -
    generic -Short enough. The category could be generic_category. Fully qualified -names like std::generic::not_enough_memory read well. Reserving in -namespace std seems dicey. -
    generic_error -Longish. The category could be generic_category. Fully qualified names -like std::generic_error::not_enough_memory read well. Misleading because -*_error in the std lib is usually an exception class name. -
    generic_err -A bit less longish. The category could be generic_category. Fully -qualified names like std::generic_err::not_enough_memory read well. -
    gen_err -Shorter still. The category could be generic_category. Fully qualified -names like std::gen_err::not_enough_memory read well. -
    generr -Shorter still. The category could be generic_category. Fully qualified -names like std::generr::not_enough_memory read well. -
    error -Shorter still. The category could be generic_category. Fully qualified -names like std::error::not_enough_memory read well. Do we want to use -this general a name? -
    err -Shorter still. The category could be generic_category. Fully qualified -names like std::err::not_enough_memory read well. Although alone it -looks odd as a name, given the existing errno and namespace std names, -it seems fairly intuitive. -Problem: err is used throughout the standard library as an argument name -and in examples as a variable name; it seems too confusing to add yet -another use of the name. -
    errc -Short enough. The "c" stands for "constant". The category could be -generic_category. Fully qualified names like -std::errc::not_enough_memory read well. Although alone it looks odd as a -name, given the existing errno and namespace std names, it seems fairly -intuitive. There are no uses of errc in the current C++ standard. -
    - - - - - -
    -

    806. unique_ptr::reset effects incorrect, too permissive

    -

    Section: 20.7.11.2.5 [unique.ptr.single.modifiers] Status: Ready - Submitter: Peter Dimov Date: 2008-03-13

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -void unique_ptr::reset(T* p = 0) is currently specified as: -

    - -
    -Effects: If p == get() there are no effects. Otherwise get_deleter()(get()). -
    - -

    -There are two problems with this. One, if get() == 0 and p != 0, the -deleter is called with a NULL pointer, and this is probably not what's -intended (the destructor avoids calling the deleter with 0.) -

    - -

    -Two, the special check for get() == p is generally not needed and such a -situation usually indicates an error in the client code, which is being -masked. As a data point, boost::shared_ptr was changed to assert on such -self-resets in 2001 and there were no complaints. -

    - -

    -One might think that self-resets are necessary for operator= to work; it's specified to perform -

    - -
    reset( u.release() );
-
    - -

    -and the self-assignment -

    - -
    p = move(p);
-
    - -

    -might appear to result in a self-reset. But it doesn't; the release() is -performed first, zeroing the stored pointer. In other words, p.reset( -q.release() ) works even when p and q are the same unique_ptr, and there -is no need to special-case p.reset( q.get() ) to work in a similar -scenario, as it definitely doesn't when p and q are separate. -

    - - - -

    Proposed resolution:

    - -

    -Change 20.7.11.2.5 [unique.ptr.single.modifiers]: -

    - -
    -
    void reset(T* p = 0);
-
    -
    --4- Effects: If p == get() == 0 there are no effects. Otherwise get_deleter()(get()). -
    -
    - -

    -Change 20.7.11.3.3 [unique.ptr.runtime.modifiers]: -

    - -
    -
    void reset(T* p = 0);
-
    -
    -

    ...

    -

    --2- Effects: If p == get() == 0 there are no effects. Otherwise get_deleter()(get()). -

    -
    -
    - - - - - - -
    -

    807. tuple construction should not fail unless its element's construction fails

    -

    Section: 20.4.1.2 [tuple.cnstr] Status: Ready - Submitter: Howard Hinnant Date: 2008-03-13

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -527 Added a throws clause to bind constructors. I believe the same throws clause -should be added to tuple except it ought to take into account move constructors as well. -

    - - -

    Proposed resolution:

    -

    -Add to 20.4.1.2 [tuple.cnstr]: -

    - -
    -

    -For each tuple constructor and assignment operator, an exception is thrown only if the construction -or assignment of one of the types in Types throws an exception. -

    -
    - - - - - -
    -

    808. [forward] incorrect redundant specification

    -

    Section: 20.2.2 [forward] Status: Ready - Submitter: Jens Maurer Date: 2008-03-13

    -

    View other active issues in [forward].

    -

    View all other issues in [forward].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -p4 (forward) says: -

    -
    -Return type: If T is an lvalue-reference type, an lvalue; otherwise, an rvalue. -
    - -

    -First of all, lvalue-ness and rvalue-ness are properties of an expression, -not of a type (see 3.10 [basic.lval]). Thus, the phrasing "Return type" is wrong. -Second, the phrase says exactly what the core language wording says for -folding references in 14.3.1 [temp.arg.type]/p4 and for function return values -in 5.2.2 [expr.call]/p10. (If we feel the wording should be retained, it should -at most be a note with cross-references to those sections.) -

    -

    -The prose after the example talks about "forwarding as an int& (an lvalue)" etc. -In my opinion, this is a category error: "int&" is a type, "lvalue" is a -property of an expression, orthogonal to its type. (Btw, expressions cannot -have reference type, ever.) -

    -

    -Similar with move: -

    -
    -Return type: an rvalue. -
    -

    -is just wrong and also redundant. -

    - - -

    Proposed resolution:

    -

    -Change 20.2.2 [forward] as indicated: -

    - -
    -
    template <class T> T&& forward(typename identity<T>::type&& t);
-
    - -
    -

    ...

    -

    -Return type: If T is an lvalue-reference type, an lvalue; otherwise, an rvalue. -

    -

    ...

    -

    --7- In the first call to factory, A1 is deduced as int, so 2 is forwarded to A's constructor -as an int&& (an rvalue). In the second call to factory, A1 is deduced -as int&, so i is forwarded to A's constructor as an int& (an lvalue). -In both cases, A2 is deduced as double, so 1.414 is forwarded to A's constructor as -double&& (an rvalue). -

    -
    - -
    template <class T> typename remove_reference<T>::type&& move(T&& t);
-
    - -
    -

    ...

    -

    -Return type: an rvalue. -

    -
    - -
    - - - - - - -
    -

    809. std::swap should be overloaded for array types

    -

    Section: 25.2.3 [alg.swap] Status: Ready - Submitter: Niels Dekker Date: 2008-02-28

    -

    View all other issues in [alg.swap].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -For the sake of generic programming, the header <algorithm> should provide an -overload of std::swap for array types: -

    template<class T, size_t N> void swap(T (&a)[N], T (&b)[N]);
-
    - - -

    -It became apparent to me that this overload is missing, when I considered how to write a swap -function for a generic wrapper class template. -(Actually I was thinking of Boost's value_initialized.) -Please look at the following template, W, and suppose that is intended to be a very -generic wrapper: -

    template<class T> class W {
-public:
-   T data;
-};
-
    -Clearly W<T> is CopyConstructible and CopyAssignable, and therefore -Swappable, whenever T is CopyConstructible and CopyAssignable. -Moreover, W<T> is also Swappable when T is an array type -whose element type is CopyConstructible and CopyAssignable. -Still it is recommended to add a custom swap function template to such a class template, -for the sake of efficiency and exception safety. -(E.g., Scott Meyers, Effective C++, Third Edition, item 25: Consider support for a non-throwing -swap.) -This function template is typically written as follows: -
    template<class T> void swap(W<T>& x, W<T>& y) {
-  using std::swap;
-  swap(x.data, y.data);
-}
-
    -Unfortunately, this will introduce an undesirable inconsistency, when T is an array. -For instance, W<std::string[8]> is Swappable, but the current Standard does not -allow calling the custom swap function that was especially written for W! -
    W<std::string[8]> w1, w2;  // Two objects of a Swappable type.
-std::swap(w1, w2);  // Well-defined, but inefficient.
-using std::swap;
-swap(w1, w2);  // Ill-formed, just because ADL finds W's swap function!!!
-
    - -W's swap function would try to call std::swap for an array, -std::string[8], which is not supported by the Standard Library. -This issue is easily solved by providing an overload of std::swap for array types. -This swap function should be implemented in terms of swapping the elements of the arrays, so that -it would be non-throwing for arrays whose element types have a non-throwing swap. - - -

    -Note that such an overload of std::swap should also support multi-dimensional -arrays. Fortunately that isn't really an issue, because it would do so automatically, by -means of recursion. -

    - -

    -For your information, there was a discussion on this issue at comp.lang.c++.moderated: [Standard -Library] Shouldn't std::swap be overloaded for C-style arrays? -

    - - -

    Proposed resolution:

    -

    -Add an extra condition to the definition of Swappable requirements [swappable] in 20.1.1 [utility.arg.requirements]: -

    -
    -- T is Swappable if T is an array type whose element type is Swappable. -
    -

    -Add the following to 25.2.3 [alg.swap]: -

    -
    -
    template<class T, size_t N> void swap(T (&a)[N], T (&b)[N]);
-
    -
    -Requires: Type T shall be Swappable. -
    -
    -Effects: swap_ranges(a, a + N, b); -
    -
    -

    810. Missing traits dependencies in operational semantics of extended manipulators

    -

    Section: 27.6.4 [ext.manip] Status: New - Submitter: Daniel Krügler Date: 2008-03-01

    -

    View other active issues in [ext.manip].

    +

    Section: 27.7.4 [ext.manip] Status: Tentatively Ready + Submitter: Daniel Krügler Opened: 2008-03-01 Last modified: 2009-05-23

    View all other issues in [ext.manip].

    -

    View all issues with New status.

    +

    View all issues with Tentatively Ready status.

    Discussion:

    The recent draft (as well as the original proposal n2072) uses an operational semantic -for get_money ([ext.manip]/3) and put_money ([ext.manip]/5), which uses +for get_money ([ext.manip]/4) and put_money ([ext.manip]/6), which uses 

    istreambuf_iterator<charT>
@@ -14098,17 +10298,30 @@ dependent). This is an obvious oversight because both *stream_buf
 c'tors expect a basic_streambuf<charT,traits> as argument.
 
    
 
    
-The same problem occurs within the get_time and put_time semantic (p.
-7 and p. 9)
-of n2071 incorporated in N2521, where additional to the problem we
+The same problem occurs within the get_time and put_time semantic 
+where additional to the problem we
 have an editorial issue in get_time (streambuf_iterator instead of
 istreambuf_iterator).
 
    
 
+
    [
+Batavia (2009-05):
+]
    
+
+
    
+
    
+This appears to be an issue of presentation.
+
    
+
    
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
    
+
    
+
 
 
    Proposed resolution:
    
 
    
-In 27.6.4 [ext.manip]/3 within function f replace the first line
+In 27.7.4 [ext.manip]/4 within function f replace the first line
 
    
 
 
    template <class charT, class traits, class moneyT> 
@@ -14118,14 +10331,14 @@ void f(basic_ios<charT, traits>& str, moneyT& mon, bool intl) {
 
    
 
 
    
-In 27.6.4 [ext.manip]/4 remove the first template charT parameter:
+In 27.7.4 [ext.manip]/5 remove the first template charT parameter:
 
    
 
 
    template <class charT, class moneyT> unspecified put_money(const moneyT& mon, bool intl = false);
 
    
 
 
    
-In 27.6.4 [ext.manip]/5 within function f replace the first line
+In 27.7.4 [ext.manip]/6 within function f replace the first line
 
    
 
 
    template <class charT, class traits, class moneyT> 
@@ -14135,7 +10348,7 @@ void f(basic_ios<charT, traits>& str, const moneyT& mon, bool intl
 
    
 
 
    
-In 27.6.4 [ext.manip]/7 within function f replace the first line
+In 27.7.4 [ext.manip]/8 within function f replace the first line
 
    
 
 
    template <class charT, class traits> 
@@ -14145,14 +10358,7 @@ void f(basic_ios<charT, traits>& str, struct tm *tmb, const charT *fmt
 
    
 
 
    
-In 27.6.4 [ext.manip]/8 add const:
-
    
-
-
    template <class charT> unspecified put_time(const struct tm *tmb, const charT *fmt);
-
    
-
-
    
-In 27.6.4 [ext.manip]/9 within function f replace the first line
+In 27.7.4 [ext.manip]/10 within function f replace the first line
 
    
 
 
    template <class charT, class traits> 
@@ -14162,280 +10368,81 @@ void f(basic_ios<charT, traits>& str, const struct tm *tmb, const char
 
    
 
 
    
-Add to the <iomanip> synopsis in 27.6 [iostream.format]
+In 27.7 [iostream.format], Header <iomanip> synopsis change:
 
    
 
-
    template <class moneyT> unspecified get_money(moneyT& mon, bool intl = false);
-template <class moneyT> unspecified put_money(const moneyT& mon, bool intl = false);
-template <class charT> unspecified get_time(struct tm *tmb, const charT *fmt);
-template <class charT> unspecified put_time(const struct tm *tmb, const charT *fmt);
+
    template <class charT, class moneyT> T8 put_money(const moneyT& mon, bool intl = false);
 
    
 
 
 
 
 
-
-
    
-
    811. pair of pointers no longer works with literal 0
    
-
    Section: 20.2.3 [pairs] Status: New
- Submitter: Doug Gregor Date: 2008-03-14
    
-
    View all other issues in [pairs].
    
-
    View all issues with New status.
    
-
    Discussion:
    
-
    #include <utility>
-
-int main()
-{
-   std::pair<char *, char *> p (0,0);
-}
-
    
-
-
    
-I just got a bug report about that, because it's valid C++03, but not
-C++0x. The important realization, for me, is that the emplace
-proposal---which made push_back variadic, causing the push_back(0)
-issue---didn't cause this break in backward compatibility. The break
-actually happened when we added this pair constructor as part of adding
-rvalue references into the language, long before variadic templates or
-emplace came along:
-
    
-
-
    template<class U, class V> pair(U&& x, V&& y);
-
    
-
-
    
-Now, concepts will address this issue by constraining that pair
-constructor to only U's and V's that can properly construct "first" and
-"second", e.g. (from
-N2322):
-
    
-
-
    template<class U , class V >
-requires Constructible<T1, U&&> && Constructible<T2, V&&>
-pair(U&& x , V&& y );
-
    
-
-
-
-
    Proposed resolution:
    
-
    
-
    
-
-
-
-
-
-
    
-
    812. unsolicited multithreading considered harmful?
    
-
    Section: 25.3.1 [alg.sort] Status: New
- Submitter: Paul McKenney Date: 2008-02-27
    
-
    View all issues with New status.
    
-
    Discussion:
    
-
    
-Multi-threading is a good thing, but unsolicited multi-threading can
-potentially be harmful.  For example, sort() performance might be
-greatly increased via a multithreaded implementation.  However, such
-a multithreaded implementation could result in concurrent invocations
-of the user-supplied comparator.  This would in turn result in problems
-given a caching comparator that might be written for complex sort keys.
-Please note that this is not a theoretical issue, as multithreaded
-implementations of sort() already exist.
-
    
-
    
-Having a multithreaded sort() available is good, but it should not
-be the default for programs that are not explicitly multithreaded.
-Users should not be forced to deal with concurrency unless they have
-asked for it.
-
    
-
-
    [
-This may be covered by
-N2410
-Thread-Safety in the Standard Library (Rev 1).
-]
    
-
-
-
-
    Proposed resolution:
    
-
    
-
    
-
-
-
-
-
-
    
-
    813. "empty" undefined for shared_ptr
    
-
    Section: 20.7.12.2 [util.smartptr.shared] Status: Ready
- Submitter: Matt Austern Date: 2008-02-26
    
-
    View other active issues in [util.smartptr.shared].
    
-
    View all other issues in [util.smartptr.shared].
    
-
    View all issues with Ready status.
    
-
    Discussion:
    
-
    
-Several places in 20.7.12.2 [util.smartptr.shared] refer to an "empty" shared_ptr.
-However, that term is nowhere defined. The closest thing we have to a
-definition is that the default constructor creates an empty shared_ptr
-and that a copy of a default-constructed shared_ptr is empty. Are any
-other shared_ptrs empty? For example, is shared_ptr((T*) 0) empty? What
-are the properties of an empty shared_ptr? We should either clarify this
-term or stop using it.
-
    
-
    
-One reason it's not good enough to leave this term up to the reader's
-intuition is that, in light of
-N2351
-and issue 711, most readers'
-intuitive understanding is likely to be wrong. Intuitively one might
-expect that an empty shared_ptr is one that doesn't store a pointer,
-but, whatever the definition is, that isn't it.
-
-
-
    [
-Peter adds:
-]
    
-
-
-
    
-
    
-Or, what is an "empty" shared_ptr?
-
    
-
-
      
-
    • 
-
      
-Are any other shared_ptrs empty?
-
      
-
      
-Yes. Whether a given shared_ptr instance is empty or not is (*)
-completely specified by the last mutating operation on that instance.
-Give me an example and I'll tell you whether the shared_ptr is empty or
-not.
-
      
-
      
-(*) If it isn't, this is a legitimate defect.
-
      
-
      • 
-
-
    • 
-
      
-For example, is shared_ptr((T*) 0) empty?
-
      
-
      
-No. If it were empty, it would have a use_count() of 0, whereas it is
-specified to have an use_count() of 1.
-
      
-
      • 
-
-
    • 
-
      
-What are the properties of an empty shared_ptr?
-
      
-
      
-The properties of an empty shared_ptr can be derived from the
-specification. One example is that its destructor is a no-op. Another is
-that its use_count() returns 0. I can enumerate the full list if you
-really like.
-
      
-
      • 
-
-
    • 
-
      
-We should either clarify this term or stop using it.
-
      
-
      
-I don't agree with the imperative tone
-
      
-
      
-A clarification would be either a no-op - if it doesn't contradict the
-existing wording - or a big mistake if it does.
-
      
-
      
-I agree that a clarification that is formally a no-op may add value.
-
      
-
      • 
-
-
    • 
-
      
-However, that term is nowhere defined.
-
      
-
      
-Terms can be useful without a definition. Consider the following
-simplistic example. We have a type X with the following operations
-defined:
-
      
-
      X x;
-X x2(x);
-X f(X x);
-X g(X x1, X x2);
-
      
-
      
-A default-constructed value is green.
      
-A copy has the same color as the original.
      
-f(x) returns a red value if the argument is green, a green value otherwise.
      
-g(x1,x2) returns a green value if the arguments are of the same color, a red value otherwise.
-
      
-
-
      
-Given these definitions, you can determine the color of every instance
-of type X, even if you have absolutely no idea what green and red mean.
-
      
-
-
      
-Green and red are "nowhere defined" and completely defined at the same time.
-
      
-
      • 
-
    
-
-
    
-Alisdair's wording is fine.
-
    
-
    
-
-
-
    Proposed resolution:
    
-
    
-Append the following sentance to 20.7.12.2 [util.smartptr.shared]
-
    
-
    
-The shared_ptr class template stores a pointer, usually obtained
-via new. shared_ptr implements semantics of
-shared ownership; the last remaining owner of the pointer is responsible for
-destroying the object, or otherwise releasing  the resources associated with
-the stored pointer. A shared_ptr object that does not own
-a pointer is said to be empty.
-
    
-
-
-
-
-
 
    
 
    814. vector<bool>::swap(reference, reference) not defined
    
-
    Section: 23.2.7 [vector.bool] Status: New
- Submitter: Alisdair Meredith Date: 2008-03-17
    
+
    Section: 23.3.7 [vector.bool] Status: Tentatively Ready
+ Submitter: Alisdair Meredith Opened: 2008-03-17  Last modified: 2009-05-23
    
 
    View other active issues in [vector.bool].
    
 
    View all other issues in [vector.bool].
    
-
    View all issues with New status.
    
+
    View all issues with Tentatively Ready status.
    
 
    Discussion:
    
 
    
 vector<bool>::swap(reference, reference) has no definition.
 
    
 
+
    [
+San Francisco:
+]
    
+
+
+
    
+Move to Open. Alisdair to provide a resolution.
+
    
+
+
    [
+Post Summit Daniel provided wording.
+]
    
+
+
+
    [
+Batavia (2009-05):
+]
    
+
+
    
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
    
+
 
 
    Proposed resolution:
    
 
    
+Just after 23.3.7 [vector.bool]/5 add the following prototype and description:
 
    
 
+
    
+
    
+static void swap(reference x, reference y);
+
    
+
    
+
    
+-6- Effects: Exchanges the contents of x and y as-if by:
+
    
+
    
+bool b = x;
+x = y;
+y = b;
+
    
+
    
+
    
+
 
 
 
 
 
    
 
    815. std::function and reference_closure do not use perfect forwarding
    
-
    Section: 20.6.15.2.4 [func.wrap.func.inv] Status: Open
- Submitter: Alisdair Meredith Date: 2008-03-16
    
+
    Section: 20.7.16.2.4 [func.wrap.func.inv] Status: Open
+ Submitter: Alisdair Meredith Opened: 2008-03-16  Last modified: 2009-06-01
    
 
    View all issues with Open status.
    
 
    Discussion:
    
 
    
@@ -14454,6 +10461,153 @@ forwarding can not be obtained because of type erasure. Not everyone
 agreed with this diagnosis of forwarding.
 
    
 
+
    [
+2009-05-01 Howard adds:
+]
    
+
+
+
    
+
    
+Sebastian Gesemann brought to my attention that the CopyConstructible
+requirement on function's ArgTypes... is an unnecessary
+restriction.
+
    
+
+
    template<Returnable R, CopyConstructible... ArgTypes>
+class function<R(ArgTypes...)>
+...
+
    
+
+
    
+On further investigation, this complaint seemed to be the same
+issue as this one.  I believe the reason CopyConstructible was put
+on ArgTypes in the first place was because of the nature of the
+invoke member:
+
    
+
+
    template<class R, class ...ArgTypes>
+R
+function<R(ArgTypes...)>::operator()(ArgTypes... arg) const
+{
+    if (f_ == 0)
+        throw bad_function_call();
+    return (*f_)(arg...);
+}
+
    
+
+
    
+However now with rvalue-refs, "by value" no longer implies CopyConstructible
+(as Sebastian correctly points out).  If rvalue arguments are supplied, MoveConstructible
+is sufficient.  Furthermore, the constraint need not be applied in function
+if I understand correctly.  Rather the client must apply the proper constraints
+at the call site.  Therefore, at the very least, I recommend that CopyConstructible
+be removed from the template class function.
+
    
+
+
    
+Furthermore we need to mandate that the invoker is coded as:
+
    
+
+
    template<class R, class ...ArgTypes>
+R
+function<R(ArgTypes...)>::operator()(ArgTypes... arg) const
+{
+    if (f_ == 0)
+        throw bad_function_call();
+    return (*f_)(std::forward<ArgTypes>(arg)...);
+}
+
    
+
+
    
+Note that ArgTypes&& (the "perfect forwarding signature") is not 
+appropriate here as this is not a deduced context for ArgTypes.  Instead
+the client's arguments must implicitly convert to the non-deduced ArgType
+type.  Catching these arguments by value makes sense to enable decay.
+
    
+
+
    
+Next forward is used to move the ArgTypes as efficiently as
+possible, and also with minimum requirements (not CopyConstructible)
+to the type-erased functor.  For object types, this will be a move.  For
+reference type ArgTypes, this will be a copy.  The end result must be
+that the following is a valid program:
+
    
+
+
    #include <functional>
+#include <memory>
+#include <cassert>
+
+std::unique_ptr<int>
+f(std::unique_ptr<int> p, int& i)
+{
+    ++i;
+    return std::move(p);
+}
+
+int main()
+{
+    int i = 2;
+    std::function<std::unique_ptr<int>(std::unique_ptr<int>,
+                                       int&> g(f);
+    std::unique_ptr<int> p = g(std::unique_ptr<int>(new int(1)), i);
+    assert(*p == 1);
+    assert(i == 3);
+}
+
    
+
+
    [
+Tested in pre-concepts rvalue-ref-enabled compiler.
+]
    
+
+
+
    
+In the example above, the first ArgType is unique_ptr<int>
+and the second ArgType is int&.  Both must work!
+
    
+
+
    
+
+
    [
+2009-05-27 Daniel adds:
+]
    
+
+
+
    
+
    
+in the 2009-05-01 comment of above mentioned issue Howard
+
    
+
+
      
+
    1. 
+Recommends to replace the CopyConstructible requirement by a
+MoveConstructible requirement
+
      2. 
+
    2. 
+Says: "Furthermore, the constraint need not be applied in function if I
+understand correctly. Rather the client must apply the proper constraints
+at the call site"
+
      3. 
+
    
+
    
+I'm fine with (a), but I think comment (b) is incorrect, at least in the
+sense I read these sentences. Let's look at Howard's example code:
+
    
+
+
    function<R(ArgTypes...)>::operator()(ArgTypes... arg) const
+{
+   if (f_ == 0)
+       throw bad_function_call();
+   return (*f_)(std::forward<ArgTypes>(arg)...);
+}
+
    
+
+
    
+In the constrained scope of this operator() overload the expression
+"(*f_)(std::forward<ArgTypes>(arg)...)" must be valid. How can it
+do so, if ArgTypes aren't at least MoveConstructible?
+
    
+
    
+
 
 
 
    Proposed resolution:
    
@@ -14466,11 +10620,11 @@ agreed with this diagnosis of forwarding.
 
 
    
 
    816. Should bind()'s returned functor have a nofail copy ctor when bind() is nofail?
    
-
    Section: 20.6.11.1.3 [func.bind.bind] Status: New
- Submitter: Stephan T. Lavavej Date: 2008-02-08
    
+
    Section: 20.7.12.1.3 [func.bind.bind] Status: Open
+ Submitter: Stephan T. Lavavej Opened: 2008-02-08  Last modified: 2009-05-23
    
 
    View other active issues in [func.bind.bind].
    
 
    View all other issues in [func.bind.bind].
    
-
    View all issues with New status.
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
 Library Issue 527 notes that bind(f, t1, ..., tN)
@@ -14481,7 +10635,7 @@ However, no guarantees are provided for the copy ctor of the functor
 returned by bind().  (It's guaranteed to have a copy ctor, which can
 throw implementation-defined exceptions: bind() returns a forwarding
 call wrapper, TR1 3.6.3/2.  A forwarding call wrapper is a call wrapper,
-TR1 3.3/4.  Every call wrapper shall be CopyConstructible, TR1 3.3/4. 
+TR1 3.3/4.  Every call wrapper shall be CopyConstructible, TR1 3.3/4.
 Everything without an exception-specification may throw
 implementation-defined exceptions unless otherwise specified, C++03
 17.4.4.8/3.)
@@ -14500,26 +10654,77 @@ Howard adds:
 tuple construction should probably have a similar guarantee.
    +

    [ +San Francisco: +]

    + + +
    +Howard to provide wording. +
    + +

    [ +Post Summit, Anthony provided wording. +]

    + + +

    [ +Batavia (2009-05): +]

    + +
    +Part of all of this issue appears to be rendered moot +by the proposed resolution to issue 817 (q.v.). +We recommend the issues be considered simultaneously +(or possibly even merged) +to ensure there is no overlap. +Move to Open, and likewise for issue 817. +

    Proposed resolution:

    +Add a new sentence to the end of paragraphs 2 and 4 of 20.7.12.1.3 [func.bind.bind]:

    +
    +

    +-2- Returns: A forwarding call wrapper g with a weak result type (20.6.2). The effect of g(u1, u2, +..., uM) shall be INVOKE(f, v1, v2, ..., vN, Callable<F cv,V1, V2, ..., VN>::result_type), where cv +represents the cv-qualifiers of g and the values and types of the bound arguments +v1, v2, ..., vN are determined as specified below. +The copy constructor and move constructor of the forwarding call wrapper shall throw an +exception if and only if the corresponding constructor of F or any of the types +in BoundArgs... throw an exception. +

    +

    ...

    +

    +-4- Returns: A forwarding call wrapper g with a nested type result_type defined as a synonym +for R. The effect of g(u1, u2, ..., uM) shall be INVOKE(f, v1, v2, ..., vN, R), where the +values and types of the bound arguments v1, v2, ..., vN are determined as specified below. +The copy constructor and move constructor of the forwarding call wrapper shall throw an +exception if and only if the corresponding constructor of F or any of the types +in BoundArgs... throw an exception. +

    + +
    +

    817. bind needs to be moved

    -

    Section: 20.6.11.1.3 [func.bind.bind] Status: New - Submitter: Howard Hinnant Date: 2008-03-17

    +

    Section: 20.7.12.1.3 [func.bind.bind] Status: Open + Submitter: Howard Hinnant Opened: 2008-03-17 Last modified: 2009-05-23

    View other active issues in [func.bind.bind].

    View all other issues in [func.bind.bind].

    -

    View all issues with New status.

    +

    View all issues with Open status.

    Discussion:

    +

    Addresses US 72, JP 38 and DE 21

    +

    -The functor retureed by bind() should have a move constructor that +The functor returned by bind() should have a move constructor that requires only move construction of its contained functor and bound arguments. That way move-only functors can be passed to objects such as thread.

    @@ -14527,190 +10732,206 @@ That way move-only functors can be passed to objects such as thread. This issue is related to issue 816.

    - -

    Proposed resolution:

    -

    - - - - - -
    -

    818. wording for memory ordering

    -

    Section: 29.1 [atomics.order] Status: New - Submitter: Jens Maurer Date: 2008-03-22

    -

    View all issues with New status.

    -

    Discussion:

    -

    -29.1 [atomics.order] p1 says in the table that +US 72:

    - - - - - - - - -
    ElementMeaning
    memory_order_acq_relthe operation has both acquire and release semantics
    +bind should support move-only functors and bound arguments.

    -To my naked eye, that seems to imply that even an atomic read has both -acquire and release semantics. -

    - -

    -Then, p1 says in the table: +JP 38:

    - - - - - - - - -
    ElementMeaning
    memory_order_seq_cstthe operation has both acquire and release semantics, - and, in addition, has sequentially-consistent operation ordering
    +

    +add the move requirement for bind's return type. +

    +

    +For example, assume following th1 and th2, +

    + +
    void f(vector<int> v) { }
+
+vector<int> v{ ... };
+thread th1([v]{ f(v); });
+thread th2(bind(f, v));
+
    + +

    +When function object are set to thread, v is moved to th1's lambda +expression in a Move Constructor of lambda expression because th1's lambda +expression has a Move Constructor. But bind of th2's +return type doesn't have the requirement of Move, so it may not +moved but copied. +

    +

    +Add the requirement of move to get rid of this useless copy. +

    +

    +And also, add the MoveConstructible as well as CopyConstructible. +

    -So that seems to be "the same thing" as memory_order_acq_rel, with additional -constraints. -

    - -

    -I'm then reading p2, where it says: +DE 21

    -The memory_order_seq_cst operations that load a value are acquire operations -on the affected locations. The memory_order_seq_cst operations that store a value -are release operations on the affected locations. +The specification for bind claims twice that "the values and types for +the bound arguments v1, v2, ..., vN are determined as specified below". +No such specification appears to exist.
    -

    -That seems to imply that atomic reads only have acquire semantics. If that -is intended, does this also apply to memory_order_acq_rel and the individual -load/store operations as well? -

    - -

    -Also, the table in p1 contains phrases with "thus" that seem to indicate -consequences of normative wording in 1.10 [intro.multithread]. That shouldn't be in -normative text, for the fear of redundant or inconsistent specification with -the other normative text. -

    - -

    -Double-check 29.4 [atomics.types.operations] that each -operation clearly says whether it's a load or a store operation, or -both. (It could be clearer, IMO. Solution not in current proposed resolution.) -

    - -

    -29.1 [atomics.order] p2: What's a "consistent execution"? It's not defined in -1.10 [intro.multithread], it's just used in notes there. -

    - -

    -And why does 29.4 [atomics.types.operations] p9 for "load" say: -

    +

    [ +San Francisco: +]

    -Requires: The order argument shall not be memory_order_acquire -nor memory_order_acq_rel. +Howard to provide wording.
    -

    -(Since this is exactly the same restriction as for "store", it seems to be a typo.) -

    +

    [ +Post Summit Alisdair and Howard provided wording. +]

    -

    -And then: 29.4 [atomics.types.operations] p12: -

    -These operations are read-modify-write operations in the sense of the -"synchronizes with" definition (1.10 [intro.multithread]), so both such an operation and the -evaluation that produced the input value synchronize with any evaluation -that reads the updated value. +

    +Several issues are being combined in this resolution. They are all touching the +same words so this is an attempt to keep one issue from stepping on another, and +a place to see the complete solution in one place. +

    + +
      +
    1. +bind needs to be "moved". +
      2. +
    2. +20.7.12.1.3 [func.bind.bind]/p3, p6 and p7 were accidently removed from N2798. +
      3. +
    3. +Issue 929 argues for a way to pass by && for +efficiency but retain the decaying behavior of pass by value for the +thread constructor. That same solution is applicable here. +
      4. +
    +

    [ +Batavia (2009-05): +]

    + +

    -This is redundant with 1.10 [intro.multithread], see above for the reasoning. +We were going to recommend moving this issue to Tentatively Ready +until we noticed potential overlap with issue 816 (q.v.).

    +

    +Move to Open, +and recommend both issues be considered together +(and possibly merged). +

    +

    Proposed resolution:

    -Replace the cross-reference in p1 to refer to 1.1 [intro.scope] instead of -1.7 [intro.memory]. -Rephrase the table in as follows (maybe don't use a table): +Change 20.7 [function.objects] p2:

    +
    template<CopyConstructible MoveConstructible Fn, CopyConstructible MoveConstructible... Types>
+  unspecified bind(Fn&&, Types&&...);
+template<Returnable R, CopyConstructible MoveConstructible Fn, CopyConstructible MoveConstructible... Types>
+  unspecified bind(Fn&&, Types&&...);
+
    + +

    +Change 20.7.12.1.3 [func.bind.bind]: +

    + +
    template<CopyConstructible MoveConstructible F, CopyConstructible MoveConstructible... BoundArgs>
+  unspecified bind(F&& f, BoundArgs&&... bound_args);
+
    +

    -For memory_order_relaxed, no operation orders memory. +Requires: unspecified return type shall be MoveConstructible.

    -

    -For memory_order_release, memory_order_acq_rel, and memory_order_seq_cst, -a store operation performs a release operation on the affected memory location. +-1- Requires: INVOKE(f, w1, w2, ..., wN) (20.6.2) shall be a valid expression for some values +w1, w2, ..., wN, where N == sizeof...(bound_args).

    -

    -For memory_order_acquire, memory_order_acq_rel, and memory_order_seq_cst, -a load operation performs an acquire operation on the affected memory location. +-2- Returns: A forwarding call wrapper g with a weak result type (20.6.2). The effect of g(u1, u2, +..., uM) shall be INVOKE(f, v1, v2, ..., vN, Callable<F cv,V1, V2, ..., VN>::result_type), where cv +represents the cv-qualifiers of g and the values and types of the bound arguments +v1, v2, ..., vN are determined as specified below.

    +

    +Throws: Nothing unless the constructor of F or of one of the types in the BoundArgs... pack expansion +throws an exception. +

    -

    -Rephrase 29.1 [atomics.order] p2: -

    +
    template<Returnable R, CopyConstructible MoveConstructible F, CopyConstructible MoveConstructible... BoundArgs>
+  unspecified bind(F&& f, BoundArgs&&... bound_args);
+
    -The memory_order_seq_cst operations that load a value are -acquire operations on the affected locations. The -memory_order_seq_cst operations that store a value are release -operations on the affected locations. -In addition, in a consistent -execution, tThere must be is a single -total order S on all -memory_order_seq_cst operations, consistent with the happens before -order and modification orders for all affected locations, such that each -memory_order_seq_cst operation observes either the last preceding -modification according to this order S, or the result of an operation -that is not memory_order_seq_cst. [Note: Although it is not explicitly -required that S include locks, it can always be extended to an order -that does include lock and unlock operations, since the ordering between -those is already included in the happens before ordering. -- end note] +

    +Requires: unspecified return type shall be MoveConstructible. +

    +

    +-3- Requires: INVOKE(f, w1, w2, ..., wN) shall be a valid expression for some values w1, w2, ..., +wN, where N == sizeof...(bound_args). +

    +

    +-4- Returns: A forwarding call wrapper g with a nested type result_type defined as a synonym +for R. The effect of g(u1, u2, ..., uM) shall be INVOKE(f, v1, v2, ..., vN, R), where the +values and types of the bound arguments v1, v2, ..., vN are determined as specified below. +

    +

    +

    +Throws: Nothing unless the constructor of F or of one of the types in the BoundArgs... pack expansion +throws an exception. +

    +
    -

    -Rephrase 29.4 [atomics.types.operations] p12 as: -

    +

    +Let the values of bound arguments v1, v2, ..., vN and +their corresponding types V1, V2, ..., VN depend on the type of +the corresponding argument ti in bound_args in the +call to bind and the cv-qualifiers cv of the call +wrapper g as follows. Let Ti be an alias for the ith +element of the pack expansion decay<BoundArgs>::type..., +and let ti be an alias for the ith element in the function +parameter pack expansion bound_args...: +

    + +
      +
    • +if ti is of type reference_wrapper<T> the argument is +ti.get() and its type Vi is T&; +
      • +
    • +if the value of std::is_bind_expression<Ti>::value is true the argument is ti(u1, u2, ..., uM) and +its type Vi is result_of<Ti cv (U1&, U2&, ..., UM&)>::type; +
      • +
    • +if the value j of std::is_placeholder<Ti>::value is not zero the argument is std::forward<Uj>(uj) and +its type Vi is Uj&&; +
      • +
    • +otherwise the value is ti and its type Vi is Ti cv &. +
      • +
    -
    -Effects: Atomically replaces the value pointed to by object or by -this with desired. Memory is affected according to the value of order. -These operations are read-modify-write operations in the sense of the -"synchronizes with" definition (1.10 [intro.multithread]), so both such an operation and the -evaluation that produced the input value synchronize with any evaluation -that reads the updated value.
    -

    -Same in p15, p20, p22. -

    - @@ -14718,9 +10939,11 @@ Same in p15, p20, p22.

    819. rethrow_if_nested

    -

    Section: 18.7.6 [except.nested] Status: New - Submitter: Alisdair Meredith Date: 2008-03-25

    -

    View all issues with New status.

    +

    Section: 18.8.6 [except.nested] Status: Open + Submitter: Alisdair Meredith Opened: 2008-03-25 Last modified: 2008-09-17

    +

    View other active issues in [except.nested].

    +

    View all other issues in [except.nested].

    +

    View all issues with Open status.

    Discussion:

    Looking at the wording I submitted for rethrow_if_nested, I don't think I @@ -14749,174 +10972,17 @@ required to be sure. Unfortunately, if e is dynamically but not static derived from nested_exception, e.rethrow_nested() is ill-formed.

    - -

    Proposed resolution:

    - - - - - -
    -

    820. current_exception()'s interaction with throwing copy ctors

    -

    Section: 18.7.5 [propagation] Status: New - Submitter: Stephan T. Lavavej Date: 2008-03-26

    -

    View other active issues in [propagation].

    -

    View all other issues in [propagation].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -As of N2521, the Working Paper appears to be silent about what -current_exception() should do if it tries to copy the currently handled -exception and its copy constructor throws. 18.7.5 [propagation]/7 says "If the -function needs to allocate memory and the attempt fails, it returns an -exception_ptr object that refers to an instance of bad_alloc.", but -doesn't say anything about what should happen if memory allocation -succeeds but the actual copying fails. -

    - -

    -I see three alternatives: (1) return an exception_ptr object that refers -to an instance of some fixed exception type, (2) return an exception_ptr -object that refers to an instance of the copy ctor's thrown exception -(but if that has a throwing copy ctor, an infinite loop can occur), or -(3) call terminate(). -

    - -

    -I believe that terminate() is the most reasonable course of action, but -before we go implement that, I wanted to raise this issue. -

    -

    [ -Peter's summary: +San Francisco: ]

    -

    -The current practice is to not have throwing copy constructors in -exception classes, because this can lead to terminate() as described in -15.5.1 [except.terminate]. Thus calling terminate() in this situation seems -consistent and does not introduce any new problems. -

    - -

    -However, the resolution of core issue 475 may relax this requirement: -

    - -
    -The CWG agreed with the position that std::uncaught_exception() should -return false during the copy to the exception object and that std::terminate() -should not be called if that constructor exits with an exception. -
    - -

    -Since throwing copy constructors will no longer call terminate(), option -(3) doesn't seem reasonable as it is deemed too drastic a response in a -recoverable situation. -

    - -

    -Option (2) cannot be adopted by itself, because a potential infinite -recursion will need to be terminated by one of the other options. -

    - +Alisdair was volunteered to provide wording.

    Proposed resolution:

    -

    -Add the following paragraph after 18.7.5 [propagation]/7: -

    - -
    -

    -Returns (continued): If the attempt to copy the current exception -object throws an exception, the function returns an exception_ptr that -refers to the thrown exception or, if this is not possible, to an -instance of bad_exception. -

    -

    -[Note: The copy constructor of the thrown exception may also fail, so -the implementation is allowed to substitute a bad_exception to avoid -infinite recursion. -- end note.] -

    -
    - - - - - - -
    -

    821. Minor cleanup : unique_ptr

    -

    Section: 20.7.11.3.3 [unique.ptr.runtime.modifiers] Status: New - Submitter: Alisdair Meredith Date: 2008-03-30

    -

    View all issues with New status.

    -

    Discussion:

    -

    -Reading resolution of LWG issue 673 I noticed the following: -

    - -
    -
    void reset(T* pointer p = 0 pointer());
-
    - -

    --1- Requires: Does not accept pointer types which are convertible -to T* pointer (diagnostic -required). [Note: One implementation technique is to create a private -templated overload. -- end note] -

    -
    - -

    -This could be cleaned up by mandating the overload as a public deleted -function. In addition, we should probably overload reset on nullptr_t -to be a stronger match than the deleted overload. Words... -

    - - -

    Proposed resolution:

    -

    -Add to class template definition in 20.7.11.3 [unique.ptr.runtime] -

    - -
    -
    // modifiers 
-T* release(); 
-void reset(T* p = 0); 
-void reset( nullptr_t );
-template< typename T > void reset( T ) = delete;
-void swap(unique_ptr&& u);
-
    -
    - -

    -Update 20.7.11.3.3 [unique.ptr.runtime.modifiers] -

    - -
    -
    void reset(pointer p = pointer());
-void reset(nullptr_t);
-
    - -

    --1- Requires: Does not accept pointer types which are convertible -to pointer (diagnostic -required). [Note: One implementation technique is to create a private -templated overload. -- end note] -

    -

    -Effects: If get() == nullptr there are no effects. Otherwise get_deleter()(get()). -

    -

    ...

    -
    - -

    [ -Note this wording incorporates resolutions for 806 (New) and 673 (Ready). -]

    - @@ -14924,11 +10990,10 @@ Note this wording incorporates resolutions for 822. Object with explicit copy constructor no longer CopyConstructible -

    Section: 20.1.1 [utility.arg.requirements] Status: New - Submitter: James Kanze Date: 2008-04-01

    -

    View other active issues in [utility.arg.requirements].

    +

    Section: X [utility.arg.requirements] Status: Tentatively NAD + Submitter: James Kanze Opened: 2008-04-01 Last modified: 2009-05-23

    View all other issues in [utility.arg.requirements].

    -

    View all issues with New status.

    +

    View all issues with Tentatively NAD status.

    Discussion:

    I just noticed that the following program is legal in C++03, but @@ -14959,11 +11024,22 @@ justification? I wouldn't call such code good, but I don't see any reason to break it unless we get something else in return.)

    +

    [ +San Francisco: +]

    -

    Proposed resolution:

    +
    +The subgroup that looked at this felt this was a good change, but it may +already be handled by incoming concepts (we're not sure). +
    + + +Original Proposed resolution: + +

    -In 20.1.1 [utility.arg.requirements] change Table 33: MoveConstructible requirements [moveconstructible]: +In X [utility.arg.requirements] change Table 33: MoveConstructible requirements [moveconstructible]:

    @@ -14981,7 +11057,7 @@ In 20.1.1 [utility.arg.requirements] change Table 33: MoveConstructible

    -In 20.1.1 [utility.arg.requirements] change Table 34: CopyConstructible requirements [copyconstructible]: +In X [utility.arg.requirements] change Table 34: CopyConstructible requirements [copyconstructible]:

    @@ -14998,148 +11074,44 @@ In 20.1.1 [utility.arg.requirements] change Table 34: CopyConstructible
    - - - - -
    -

    823. identity<void> seems broken

    -

    Section: 20.2.2 [forward] Status: Review - Submitter: Walter Brown Date: 2008-04-09

    -

    View other active issues in [forward].

    -

    View all other issues in [forward].

    -

    View all issues with Review status.

    -

    Discussion:

    -

    -N2588 seems to have added an operator() member function to the -identity<> helper in 20.2.2 [forward]. I believe this change makes it no -longer possible to instantiate identity<void>, as it would require -forming a reference-to-void type as this operator()'s parameter type. -

    - -

    -Suggested resolution: Specialize identity<void> so as not to require -the member function's presence. -

    -

    [ -Sophia Antipolis: +Post Summit: ]

    -Jens: suggests to add a requires clause to avoid specializing on void. +Alisdair: Proposed resolution kinda funky as these tables no longer +exist. Move from direct init to copy init. Clarify with Doug, recommends +NAD.

    -Alisdair: also consider cv-qualified void. +Walter: Suggest NAD via introduction of concepts.

    -Alberto provided proposed wording. +Recommend close as NAD.

    -

    Proposed resolution:

    -

    -Change definition of identity in 20.2.2 [forward], paragraph 2, to: -

    - -
    template <class T>  struct identity {
-    typedef T type;
-
-    requires ReferentType<T>
-      const T& operator()(const T& x) const;
-  };
-
    -

    ...

    -
      requires ReferentType<T>
-    const T& operator()(const T& x) const;
-
    - - -

    Rationale:

    -

    -The point here is to able to write T& given T and ReferentType is -precisely the concept that guarantees so, according to N2677 -(Foundational concepts). Because of this, it seems preferable than an -explicit check for cv void using SameType/remove_cv as it was suggested -in Sophia. In particular, Daniel remarked that there may be types other -than cv void which aren't referent types (int[], perhaps?). -

    - - - - - -
    -

    824. rvalue ref issue with basic_string inserter

    -

    Section: 21.3.8.9 [string.io] Status: Ready - Submitter: Alisdair Meredith Date: 2008-04-10

    -

    View all other issues in [string.io].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -In the current working paper, the <string> header synopsis at the end of -21.2 [string.classes] lists a single operator<< overload -for basic_string. -

    - -
    template<class charT, class traits, class Allocator>
- basic_ostream<charT, traits>&
-   operator<<(basic_ostream<charT, traits>&& os,
-              const basic_string<charT,traits,Allocator>& str);
-
    - -

    -The definition in 21.3.8.9 [string.io] lists two: -

    - -
    template<class charT, class traits, class Allocator>
- basic_ostream<charT, traits>&
-   operator<<(basic_ostream<charT, traits>& os,
-              const basic_string<charT,traits,Allocator>& str);
-
-template<class charT, class traits, class Allocator>
- basic_ostream<charT, traits>&
-   operator<<(basic_ostream<charT, traits>&& os,
-              const basic_string<charT,traits,Allocator>& str);
-
    - -

    -I believe the synopsis in 21.2 [string.classes] is correct, and the first of the two -signatures in 21.3.8.9 [string.io] should be deleted. -

    -

    Proposed resolution:

    -Delete the first of the two signatures in 21.3.8.9 [string.io]: +Recommend close as NAD.

    -
    template<class charT, class traits, class Allocator>
- basic_ostream<charT, traits>&
-   operator<<(basic_ostream<charT, traits>& os,
-              const basic_string<charT,traits,Allocator>& str);
-
-template<class charT, class traits, class Allocator>
- basic_ostream<charT, traits>&
-   operator<<(basic_ostream<charT, traits>&& os,
-              const basic_string<charT,traits,Allocator>& str);
-
    -

    825. Missing rvalues reference stream insert/extract operators?

    -

    Section: 19.4.2.1 [syserr.errcode.overview], 20.7.12.2.8 -[util.smartptr.shared.io], 22.2.8 [facets.examples], 23.3.5.3 -[bitset.operators], 26.3.6 [complex.ops], 27.5 [stream.buffers], 28.9 -[re.submatch] Status: Open - Submitter: Alisdair Meredith Date: 2008-04-10

    -

    View all issues with Open status.

    +

    Section: 19.5.2.2 [syserr.errcode.overview], 20.8.13.2.8 +[util.smartptr.shared.io], 22.4.8 [facets.examples], 20.3.6.3 +[bitset.operators], 26.4.6 [complex.ops], 27.6 [stream.buffers], 28.10 +[re.submatch] Status: Tentatively NAD Editorial + Submitter: Alisdair Meredith Opened: 2008-04-10 Last modified: 2009-05-23

    +

    View all issues with Tentatively NAD Editorial status.

    Discussion:

    Should the following use rvalues references to stream in insert/extract @@ -15147,15 +11119,15 @@ operators?

      -
    • 19.4.2.1 [syserr.errcode.overview]
      • -
    • 20.7.12.2.8 [util.smartptr.shared.io]
      • -
    • 22.2.8 [facets.examples]
      • -
    • 23.3.5.3 [bitset.operators]
      • -
    • 26.3.6 [complex.ops]
      • -
    • Doubled signatures in 27.5 [stream.buffers] for character inserters -(ref 27.6.2.6.4 [ostream.inserters.character]) -+ definition 27.6.2.6.4 [ostream.inserters.character]
      • -
    • 28.9 [re.submatch]
      • +
    • 19.5.2.2 [syserr.errcode.overview]
      • +
    • 20.8.13.2.8 [util.smartptr.shared.io]
      • +
    • 22.4.8 [facets.examples]
      • +
    • 20.3.6.3 [bitset.operators]
      • +
    • 26.4.6 [complex.ops]
      • +
    • Doubled signatures in 27.6 [stream.buffers] for character inserters +(ref 27.7.2.6.4 [ostream.inserters.character]) ++ definition 27.7.2.6.4 [ostream.inserters.character]
      • +
    • 28.10 [re.submatch]

    [ @@ -15167,6 +11139,35 @@ Sophia Antipolis Agree with the idea in the issue, Alisdair to provide wording.

    +

    [ +Daniel adds 2009-02-14: +]

    + + +
    +The proposal given in the paper +N2831 +apparently resolves this issue. +
    + +

    [ +Batavia (2009-05): +]

    + +
    +

    +The cited paper is an earlier version of +N2844, +which changed the rvalue reference binding rules. +That paper includes generic templates +operator<< and operator>> +that adapt rvalue streams. +

    +

    +We therefore agree with Daniel's observation. +Move to NAD Editorial. +

    +

    Proposed resolution:

    @@ -15179,10 +11180,11 @@ Agree with the idea in the issue, Alisdair to provide wording.

    827. constexpr shared_ptr::shared_ptr()?

    -

    Section: 20.7.12.2.1 [util.smartptr.shared.const] Status: New - Submitter: Peter Dimov Date: 2008-04-11

    +

    Section: 20.8.13.2.1 [util.smartptr.shared.const] Status: Open + Submitter: Peter Dimov Opened: 2008-04-11 Last modified: 2009-05-30

    +

    View other active issues in [util.smartptr.shared.const].

    View all other issues in [util.smartptr.shared.const].

    -

    View all issues with New status.

    +

    View all issues with Open status.

    Discussion:

    Would anyone object to making the default constructor of shared_ptr (and @@ -15191,6 +11193,55 @@ static initialization for shared_ptr variables, eliminating another unfair advantage of raw pointers.

    +

    [ +San Francisco: +]

    + + +
    +

    +It's not clear to us that you can initialize a pointer with the literal +0 in a constant expression. We need to ask CWG to make sure this works. +Bjarne has been appointed to do this. +

    +

    +Core got back to us and assured as that nullptr would do the job +nicely here. +

    +
    + +

    [ +2009-05-01 Alisdair adds: +]

    + + +
    +

    +I don't believe that constexpr will buy anything in this case. +shared_ptr/weak_ptr/enable_shared_from_this cannot be literal types as they +have a non-trivial copy constructor. As they do not produce literal types, +then the constexpr default constructor will not guarantee constant +initialization, and so not buy the hoped for optimization. +

    +

    +I recommend referring this back to Core to see if we can get static +initialization for types with constexpr constructors, even if they are not +literal types. Otherwise this should be closed as NAD. +

    +
    + +

    [ +2009-05-26 Daniel adds: +]

    + + +
    +If Alisdair's 2009-05-01 comment is correct, wouldn't that also make +constexpr mutex() useless, because this class has a non-trivial +destructor? (828) + +
    +

    Proposed resolution:

    @@ -15202,8 +11253,10 @@ unfair advantage of raw pointers.

    828. Static initialization for std::mutex?

    -

    Section: 30.3.1.1 [thread.mutex.class] Status: Review - Submitter: Peter Dimov Date: 2008-04-18

    +

    Section: 30.4.1.1 [thread.mutex.class] Status: Review + Submitter: Peter Dimov Opened: 2008-04-18 Last modified: 2009-05-30

    +

    View other active issues in [thread.mutex.class].

    +

    View all other issues in [thread.mutex.class].

    View all issues with Review status.

    Discussion:

    @@ -15234,20 +11287,60 @@ non-POSIX systems for implementability.

    If ubiquitous implementability cannot be assured, plan B is to introduce another constructor, make this constexpr, which is -conditionally-supported. To avod ambiguities, this new constructor needs +conditionally-supported. To avoid ambiguities, this new constructor needs to have an additional parameter.

    +

    [ +Post Summit: +]

    + + +
    +

    +Jens: constant initialization seems to be ok core-language wise +

    +

    +Consensus: Defer to threading experts, in particular a Microsoft platform expert. +

    +

    +Lawrence to send e-mail to Herb Sutter, Jonathan Caves, Anthony Wiliams, +Paul McKenney, Martin Tasker, Hans Boehm, Bill Plauger, Pete Becker, +Peter Dimov to alert them of this issue. +

    +

    +Lawrence: What about header file shared with C? The initialization +syntax is different in C and C++. +

    +

    +Recommend Keep in Review +

    +
    + +

    [ +Batavia (2009-05): +]

    + +
    +Keep in Review status pending feedback from members of the Concurrency subgroup. +
    + +

    [ +See related comments from Alisdiar and Daniel in 827. +]

    + + +

    Proposed resolution:

    -Change 30.3.1.1 [thread.mutex.class]: +Change 30.4.1.1 [thread.mutex.class]:

    -
    class mutex { 
-public: 
-  constexpr mutex(); 
+
    class mutex {
+public:
+  constexpr mutex();
   ...
 
    
 
@@ -15255,112 +11348,15 @@ public:
 
 
 
-
    
-
    829. current_exception wording unclear about exception type
    
-
    Section: 18.7.5 [propagation] Status: Ready
- Submitter: Beman Dawes Date: 2008-04-20
    
-
    View other active issues in [propagation].
    
-
    View all other issues in [propagation].
    
-
    View all issues with Ready status.
    
-
    Discussion:
    
-
    Consider this code:
    
-
-
    
-
    exception_ptr xp;
    
-
    try {do_something(); }
-
-catch (const runtime_error& ) {xp = current_exception();}
-
-...
-
-rethrow_exception(xp);
    
-
    
-
-
    
-Say do_something() throws an exception object of type 
-range_error. What is the type of the exception object thrown by 
-rethrow_exception(xp) above? It must have a type of range_error; 
-if it were of type runtime_error it still isn't possible to 
-propagate an exception and the exception_ptr/current_exception/rethrow_exception 
-machinery serves no useful purpose.
-
    
-
-
    
-Unfortunately, the current wording does not explicitly say that. Different 
-people read the current wording and come to different conclusions. While it may 
-be possible to deduce the correct type from the current wording, it would be 
-much clearer to come right out and explicitly say what the type of the referred 
-to exception is.
-
    
-
-
    [
-Peter adds:
-]
    
-
-
-
    
-
    
-I don't like the proposed resolution of 829. The normative text is
-unambiguous that the exception_ptr refers to the currently handled
-exception. This term has a standard meaning, see 15.3 [except.handle]/8; this is the
-exception that throw; would rethrow, see 15.1 [except.throw]/7.
-
    
-
    
-A better way to address this is to simply add the non-normative example
-in question as a clarification. The term currently handled exception
-should be italicized and cross-referenced. A [Note: the currently
-handled exception is the exception that a throw expression without an
-operand (15.1 [except.throw]/7) would rethrow. --end note] is also an option.
-
    
-
    
-
-
-
-
    Proposed resolution:
    
-
-
    
-After 18.7.5 [propagation] , paragraph 7, add the indicated text:
-
    
-
-
    
-
    exception_ptr current_exception();
    
-
-
    
-
    
-Returns: exception_ptr object that refers 
-to the currently handled exception (15.3 [except.handle]) or a copy of the currently handled 
-exception, or a null exception_ptr object if no exception is being handled. If 
-the function needs to allocate memory and the attempt fails, it returns an
-exception_ptr object that refers to an instance of bad_alloc. 
-It is unspecified whether the return values of two successive calls to
-current_exception refer to the same exception object. 
-[Note: that is, it 
-is unspecified whether current_exception
-creates a new copy each time it is called.
--- end note]
-
    
-
-
    
-Throws: nothing.
-
    
-
-
    
-
    
-
-
-
-
-
-
 
    
 
    830. Incomplete list of char_traits specializations
    
-
    Section: 21.1 [char.traits] Status: Open
- Submitter: Dietmar Kühl Date: 2008-04-23
    
+
    Section: 21.2 [char.traits] Status: Tentatively NAD Editorial
+ Submitter: Dietmar Kühl Opened: 2008-04-23  Last modified: 2009-05-23
    
 
    View all other issues in [char.traits].
    
-
    View all issues with Open status.
    
+
    View all issues with Tentatively NAD Editorial status.
    
 
    Discussion:
    
 
    
-  Paragraph 4 of 21.1 [char.traits] mentions that this
+  Paragraph 4 of 21.2 [char.traits] mentions that this
   section specifies two specializations (char_traits<char>
   and (char_traits<wchar_t>). However, there are actually
   four specializations provided, i.e. in addition to the two above also
@@ -15375,7 +11371,7 @@ Alisdair adds:
 
 
    
 char_traits< char16/32_t >
-should also be added to <ios_fwd> in 27.2 [iostream.forward], and all the specializations
+should also be added to <ios_fwd> in 27.3 [iostream.forward], and all the specializations
 taking a char_traits parameter in that header.
 
    
 
@@ -15391,13 +11387,42 @@ Idea of the issue is ok.
 
    
 Alisdair to provide wording, once that wording arrives, move to review.
 
    
+
    +

    [ +2009-05-04 Alisdair adds: +]

    -

    Proposed resolution:

    +

    - Replace paragraph 4 of 21.1 [char.traits] by: +The main point of the issue was resolved editorially in +N2723, +so we are +close to NAD Editorial. +However, exploring the issue we found a second tweak was necessary for +<iosfwd> and that is still outstanding, so here are the words I am long +overdue delivering: +

    + +

    [ +Howard: I've put Alisdair's words into the proposed wording section and +moved the issue to Review. +]

    + + +
    + +

    [ +Original proposed wording. +]

    + + +
    + +

    + Replace paragraph 4 of 21.2 [char.traits] by:

    @@ -15408,361 +11433,103 @@ Alisdair to provide wording, once that wording arrives, move to review. <string> and satisfy the requirements below.

    - - - - - -
    -

    832. Applying constexpr to System error support

    -

    Section: 19.4 [syserr] Status: Open - Submitter: Beman Dawes Date: 2008-05-14

    -

    View other active issues in [syserr].

    -

    View all other issues in [syserr].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -Initialization of objects of class error_code -(19.4.2 [syserr.errcode]) and class -error_condition (19.4.3 [syserr.errcondition]) can be made simpler and more reliable by use of -the new constexpr feature -[N2349] -of C++0x. Less code will need to be -generated for both library implementations and user programs when -manipulating constant objects of these types. -

    - -

    -This was not proposed originally because the constant expressions -proposal was moving into the standard at about the same time as the -Diagnostics Enhancements proposal -[N2241], -and it wasn't desirable to -make the later depend on the former. There were also technical concerns -as to how constexpr would apply to references. Those concerns are now -resolved; constexpr can't be used for references, and that fact is -reflected in the proposed resolution. -

    - -

    -Thanks to Jens Maurer, Gabriel Dos Reis, and Bjarne Stroustrup for clarification of constexpr requirements. -

    - -

    -LWG issue 804 is related in that it raises the question of whether the -exposition only member cat_ of class error_code (19.4.2 [syserr.errcode]) and class -error_condition (19.4.3 [syserr.errcondition]) should be presented as a reference or pointer. -While in the context of 804 that is arguably an editorial question, -presenting it as a pointer becomes more or less required with this -proposal, given constexpr does not play well with references. The -proposed resolution thus changes the private member to a pointer, which -also brings it in sync with real implementations. -

    - -

    [ -Sophia Antipolis: -]

    - - -
    -On going question of extern pointer vs. inline functions for interface.

    [ -Pre-San Francisco: +Batavia (2009-05): ]

    -
    -

    -Beman Dawes reports that this proposal is unimplementable, and thus NAD. -

    -

    -Implementation would require constexpr objects of classes derived -from class error_category, which has virtual functions, and that is -not allowed by the core language. This was determined when trying to -implement the proposal using a constexpr enabled compiler provided -by Gabriel Dos Reis, and subsequently verified in discussions with -Gabriel and Jens Maurer. -

    - +We agree. Move to NAD Editorial.

    Proposed resolution:

    -The proposed wording assumes the LWG 805 proposed wording has been -applied to the WP, resulting in the former posix_category being renamed -generic_category. If 805 has not been applied, the names in this -proposal must be adjusted accordingly. -

    - -

    -Change 19.4.1.1 [syserr.errcat.overview] Class -error_category overview error_category synopsis as -indicated: -

    - -
    const error_category& get_generic_category();
-const error_category& get_system_category();
-
-static extern const error_category&* const generic_category = get_generic_category();
-static extern const error_category&* const native_category system_category = get_system_category();
-
    - -

    -Change 19.4.1.5 [syserr.errcat.objects] Error category objects as indicated: +Change Forward declarations 27.3 [iostream.forward]:

    -
    extern const error_category&* const get_generic_category();
-

    -Returns: A reference generic_category shall point -to an a statically initialized object of a type derived from -class error_category. +Header <iosfwd> synopsis

    - -

    -Remarks: The object's default_error_condition and equivalent virtual -functions shall behave as specified for the class error_category. The -object's name virtual function shall return a pointer to the string -"GENERIC". -

    - -
    extern const error_category&* const get_system_category();
-
    - -

    -Returns: A reference system_category shall point -to an a statically -initialized object of a type derived from class error_category. -

    - -

    -Remarks: The object's equivalent virtual functions shall behave as -specified for class error_category. The object's name virtual function -shall return a pointer to the string "system". The object's -default_error_condition virtual function shall behave as follows: -

    - -

    -If the argument ev corresponds to a POSIX errno value posv, the function -shall return error_condition(posv, generic_category). Otherwise, the -function shall return error_condition(ev, system_category). What -constitutes correspondence for any given operating system is -unspecified. [Note: The number of potential system error codes is large -and unbounded, and some may not correspond to any POSIX errno value. -Thus implementations are given latitude in determining correspondence. --- end note] -

    -
    - -

    -Change 19.4.2.1 [syserr.errcode.overview] Class error_code overview as indicated: -

    - -
    class error_code {
-public:
-  ...;
-  constexpr error_code(int val, const error_category&* cat);
-  ...
-  void assign(int val, const error_category&* cat);
-  ...
-  const error_category&* category() const;
-  ...
-private:
-  int val_;                    // exposition only
-  const error_category&* cat_; // exposition only
-
    - -

    -Change 19.4.2.2 [syserr.errcode.constructors] Class error_code constructors as indicated: -

    - -
    -
    constexpr error_code(int val, const error_category&* cat);
-
    -

    -Effects: Constructs an object of type error_code. -

    -

    -Postconditions: val_ == val and cat_ == cat. -

    -

    -Throws: Nothing. -

    -
    - -

    -Change 19.4.2.3 [syserr.errcode.modifiers] Class error_code modifiers as indicated: -

    - -
    -
    void assign(int val, const error_category&* cat);
-
    -

    -Postconditions: val_ == val and cat_ == cat. -

    -

    -Throws: Nothing. -

    -
    - -

    -Change 19.4.2.4 [syserr.errcode.observers] Class error_code observers as indicated: -

    - -
    -
    const error_category&* category() const;
-
    - -

    -Returns: cat_. -

    -

    -Throws: Nothing. -

    -
    - -

    -Change 19.4.3.1 [syserr.errcondition.overview] Class error_condition overview as indicated: -

    - -
    -
    class error_condition {
-public:
-  ...;
-  constexpr error_condition(int val, const error_category&* cat);
-  ...
-  void assign(int val, const error_category&* cat);
-  ...
-  const error_category&* category() const;
-  ...
-private:
-  int val_;                    // exposition only
-  const error_category&* cat_; // exposition only
+
    namespace std {
+   template<class charT> class char_traits;
+   template<> class char_traits<char>;
+   template<> class char_traits<char16_t>;
+   template<> class char_traits<char32_t>;
+   template<> class char_traits<wchar_t>;
+...
+}
    -

    -Change 19.4.3.2 [syserr.errcondition.constructors] Class error_condition constructors as indicated: -

    - -
    -
    constexpr error_condition(int val, const error_category&* cat);
-
    -

    -Effects: Constructs an object of type error_condition. -

    -

    -Postconditions: val_ == val and cat_ == cat. -

    -

    -Throws: Nothing. -

    -
    - -

    -Change 19.4.3.3 [syserr.errcondition.modifiers] Class error_condition modifiers as indicated: -

    - -
    -
    void assign(int val, const error_category&* cat);
-
    -

    -Postconditions: val_ == val and cat_ == cat. -

    -

    -Throws: Nothing. -

    -
    - -

    -Change 19.4.3.4 [syserr.errcondition.observers] Class error_condition observers as indicated: -

    - -
    -
    const error_category&* category() const;
-
    -

    -Returns: cat_. -

    -

    -Throws: Nothing. -

    -
    - -

    -Throughout 19.4 [syserr] System error support, change "category()." to "category()->". -Appears approximately six times. -

    - -

    -[Partially Editorial] In 19.4.4 [syserr.compare] Comparison operators, -paragraphs 2 and 4, change "category.equivalent(" to -"category()->equivalent(". -

    - -

    -Change 19.4.5.1 [syserr.syserr.overview] Class system_error overview as indicated: -

    - -
    public:
-  system_error(error_code ec, const string& what_arg);
-  system_error(error_code ec);
-  system_error(int ev, const error_category&* ecat,
-      const string& what_arg);
-  system_error(int ev, const error_category&* ecat);
-
    - -

    -Change 19.4.5.2 [syserr.syserr.members] Class system_error members as indicated: -

    - -
    -
    system_error(int ev, const error_category&* ecat, const string& what_arg);
-
    -
    -

    -Effects: Constructs an object of class system_error. -

    -

    -Postconditions: code() == error_code(ev, ecat) and -strcmp(runtime_error::what(), what_arg.c_str()) == 0. -

    -
    - -
    system_error(int ev, const error_category&* ecat);
-
    -
    -

    -Effects: Constructs an object of class system_error. -

    -

    -Postconditions: code() == error_code(ev, ecat) and -strcmp(runtime_error::what(), "") == 0. -

    -
    -
    - -

    833. Freestanding implementations header list needs review for C++0x

    -

    Section: 17.4.1.3 [compliance] Status: Open - Submitter: Beman Dawes Date: 2008-05-14

    +

    Section: 17.6.1.3 [compliance] Status: Open + Submitter: Beman Dawes Opened: 2008-05-14 Last modified: 2009-03-11

    +

    View other active issues in [compliance].

    +

    View all other issues in [compliance].

    View all issues with Open status.

    Discussion:

    Once the C++0x standard library is feature complete, the LWG needs to -review 17.4.1.3 [compliance] Freestanding implementations header list to +review 17.6.1.3 [compliance] Freestanding implementations header list to ensure it reflects LWG consensus.

    +

    [ +San Francisco: +]

    + + +
    +

    +This is a placeholder defect to remind us to review the table once we've +stopped adding headers to the library. +

    +

    +Three new headers that need to be added to the list: +

    +
    <initializer_list> <concept> <iterator_concepts>
+
    +

    +<iterator_concepts>, in particular, has lots of stuff +that isn't needed, so maybe the stuff that is needed should be broken +out into a separate header. +

    +

    +Robert: What about reference_closure? It's currently in +<functional>. +

    +
    + +

    [ +Post Summit Daniel adds: +]

    + + +
    +
      +
    1. +The comment regarding reference_closure seems moot since it was just +recently decided to remove that. +
      2. +
    2. +A reference to proposal +N2814 +("Fixing freestanding") should be added. This +paper e.g. proposes to add only <initializer_list> to the include list +of freestanding. +
      3. +
    +
    + +

    Proposed resolution:

    @@ -15772,12 +11539,14 @@ ensure it reflects LWG consensus.

    834. Unique_ptr::pointer requirements underspecified

    -

    Section: 20.7.11.2 [unique.ptr.single] Status: Open - Submitter: Daniel Krügler Date: 2008-05-14

    +

    Section: 20.8.12.2 [unique.ptr.single] Status: Open + Submitter: Daniel Krügler Opened: 2008-05-14 Last modified: 2008-06-19

    +

    View other active issues in [unique.ptr.single].

    +

    View all other issues in [unique.ptr.single].

    View all issues with Open status.

    Discussion:

    -Issue 673 (including recent updates by 821) proposes a useful +Issue 673 (including recent updates by 821) proposes a useful extension point for unique_ptr by granting support for an optional deleter_type::pointer to act as pointer-like replacement for element_type* (In the following: pointer). @@ -15806,7 +11575,7 @@ fail and thus strongly favor the second choice. Also, the alternative position would make it much harder to write safe and simple template code for unique_ptr. Additionally, I assume that a general statement need to be given that all of the expressions of pointer used to define semantics are required to -be well-formed and well-defined (also as back-end for 762). +be well-formed and well-defined (also as back-end for 762).

    [ @@ -15829,7 +11598,7 @@ Howard will go through and enumerate the individual requirements wrt. pointe

    Proposed resolution:

    Add the following sentence just at the end of the newly proposed -20.7.11.2 [unique.ptr.single]/p. 3: +20.8.12.2 [unique.ptr.single]/p. 3:

    @@ -15843,11 +11612,11 @@ defined behavior, and shall not throw exceptions.

    835. tying two streams together (correction to DR 581)

    -

    Section: 27.4.4.2 [basic.ios.members] Status: New - Submitter: Martin Sebor Date: 2008-05-17

    +

    Section: 27.5.4.2 [basic.ios.members] Status: Review + Submitter: Martin Sebor Opened: 2008-05-17 Last modified: 2009-05-30

    View other active issues in [basic.ios.members].

    View all other issues in [basic.ios.members].

    -

    View all issues with New status.

    +

    View all issues with Review status.

    Discussion:

    @@ -15888,11 +11657,64 @@ int main () std::cout << "cout\n"; std::cerr << "cerr\n"; } - -

    - -

    Proposed resolution:

    -

    + +

    + +

    [ +Batavia (2009-05): +]

    + +
    +We agree with the proposed resolution. +Move to Review. +
    + +

    [ +2009-05-26 Daniel adds: +]

    + + +
    +

    +I think that the most recently suggested change in +27.7.2.4 [ostream::sentry] need some further word-smithing. As +written, it would make the behavior undefined, if under +conditions when pubsync() should be called, but when +in this scenario os.rdbuf() returns 0. +

    +

    +This case is explicitly handled in flush() and needs to be +taken care of. My suggested fix is: +

    + +
    +If ((os.flags() & ios_base::unitbuf) && !uncaught_exception() +&& os.rdbuf() != 0) is true, calls os.flush() +os.rdbuf()->pubsync(). +
    + +

    +Two secondary questions are: +

    + +
      +
    1. +Should pubsync() be invoked in any case or shouldn't a +base requirement for this trial be that os.good() == true +as required in the original flush() case? +
      2. +
    2. +Since uncaught_exception() is explicitly tested, shouldn't +a return value of -1 of pubsync() produce setstate(badbit) +(which may throw ios_base::failure)? +
      3. +
    +
    + + + +

    Proposed resolution:

    +

    I think an easy way to plug the first hole is to add a requires clause to ostream::tie(ostream *tiestr) requiring the this @@ -15905,7 +11727,7 @@ although I think we could since the list is unlikely to be very long.

    -Add a Requires clause to 27.4.4.2 [basic.ios.members] withethe following +Add a Requires clause to 27.5.4.2 [basic.ios.members] withethe following text:

    @@ -15921,7 +11743,7 @@ from tiestr->tie(). In addition, to prevent the infinite recursion that Bo writes about in his comp.lang.c++.moderated post, I propose to change -27.6.2.4 [ostream::sentry], p2 like so: +27.7.2.4 [ostream::sentry], p2 like so:

    @@ -15940,16 +11762,17 @@ calls os.flush() os.rdbuf()->pubsync(). effects of money_base::space and money_base::none on money_get -

    Section: 22.2.6.1.2 [locale.money.get.virtuals] Status: New - Submitter: Martin Sebor Date: 2008-05-17

    +

    Section: 22.4.6.1.2 [locale.money.get.virtuals] Status: Open + Submitter: Martin Sebor Opened: 2008-05-17 Last modified: 2008-09-22

    View other active issues in [locale.money.get.virtuals].

    View all other issues in [locale.money.get.virtuals].

    -

    View all issues with New status.

    -

    Duplicate of: 670

    +

    View all issues with Open status.

    +

    Duplicate of: 670

    Discussion:

    +

    -In paragraph 2, 22.2.6.1.2 [locale.money.get.virtuals] specifies the following: +In paragraph 2, 22.4.6.1.2 [locale.money.get.virtuals] specifies the following:

    @@ -15992,6 +11815,15 @@ The other is that: where either money_base::space or money_base::none appears in the format, white space is optional.
    + +

    [ +San Francisco: +]

    + + +
    +Martin will revise the proposed resolution. +

    Proposed resolution:

    @@ -15999,7 +11831,7 @@ where either money_base::space or money_base::none app I propose to change the text to make it clear that the first interpretation is intended, that is, to make following change to -22.2.6.1.2 [locale.money.get.virtuals], p2: +22.4.6.1.2 [locale.money.get.virtuals], p2:

    @@ -16027,15 +11859,15 @@ If (str.flags() & str.showbase) is false, ...

    837. basic_ios::copyfmt() overly loosely specified

    -

    Section: 27.4.4.2 [basic.ios.members] Status: New - Submitter: Martin Sebor Date: 2008-05-17

    +

    Section: 27.5.4.2 [basic.ios.members] Status: Tentatively NAD Editorial + Submitter: Martin Sebor Opened: 2008-05-17 Last modified: 2009-05-23

    View other active issues in [basic.ios.members].

    View all other issues in [basic.ios.members].

    -

    View all issues with New status.

    +

    View all issues with Tentatively NAD Editorial status.

    Discussion:

    -The basic_ios::copyfmt() member function is specified in 27.4.4.2 [basic.ios.members] to have the following effects: +The basic_ios::copyfmt() member function is specified in 27.5.4.2 [basic.ios.members] to have the following effects:

    @@ -16069,11 +11901,20 @@ and iword are copied not the pointers themselves Since the rest of the text doesn't specify what the member objects of basic_ios are this seems a little too loose. -

    - +

    -

    Proposed resolution:

    -

    +

    [ +Batavia (2009-05): +]

    + +
    +We agree with the proposed resolution. +Move to NAD Editorial. +
    + + +

    Proposed resolution:

    +

    I propose to tighten things up by adding a Postcondition clause to the function like so: @@ -16154,11 +11995,11 @@ already there.

    838. can an end-of-stream iterator become a non-end-of-stream one?

    -

    Section: 24.5.1 [istream.iterator] Status: New - Submitter: Martin Sebor Date: 2008-05-17

    +

    Section: 24.6.1 [istream.iterator] Status: Open + Submitter: Martin Sebor Opened: 2008-05-17 Last modified: 2008-10-27

    View other active issues in [istream.iterator].

    View all other issues in [istream.iterator].

    -

    View all issues with New status.

    +

    View all issues with Open status.

    Discussion:

    @@ -16168,9 +12009,9 @@ From message c++std-lib-20003...

    The description of istream_iterator in -24.5.1 [istream.iterator], p1 specifies that objects of the +24.6.1 [istream.iterator], p1 specifies that objects of the class become the end-of-stream (EOS) iterators under the -following condition (see also issue 836 another problem +following condition (see also issue 788 another problem with this paragraph):

    @@ -16245,6 +12086,23 @@ the end of its lifetime?

    +

    [ +San Francisco: +]

    + + +
    +

    +We like the direction of the proposed resolution. We're not sure about +the wording, and we need more time to reflect on it, +

    +

    +Move to Open. Detlef to rewrite the proposed resolution in such a way +that no reference is made to exposition only members of +istream_iterator. +

    +
    +

    Proposed resolution:

    @@ -16260,7 +12118,7 @@ iterators whose behavior is in this case undefined.

    -To this end we propose to change 24.5.1 [istream.iterator], p1, +To this end we propose to change 24.6.1 [istream.iterator], p1, as follows:

    @@ -16318,8 +12176,10 @@ return tmp;

    839. Maps and sets missing splice operation

    -

    Section: 23.3 [associative], 23.4 [unord] Status: Open - Submitter: Alan Talbot Date: 2008-05-18

    +

    Section: 23.4 [associative], 23.5 [unord] Status: Open + Submitter: Alan Talbot Opened: 2008-05-18 Last modified: 2008-09-22

    +

    View other active issues in [associative].

    +

    View all other issues in [associative].

    View all issues with Open status.

    Discussion:

    @@ -16401,552 +12261,29 @@ Daniel: For unordered_map, we can't guarantee nothrow.

    - - -

    Proposed resolution:

    - - - - - -
    -

    841. cstdint.syn inconsistent with C99

    -

    Section: 18.3.1 [cstdint.syn] Status: New - Submitter: Martin Sebor Date: 2008-05-17

    -

    View all other issues in [cstdint.syn].

    -

    View all issues with New status.

    -

    Discussion:

    -

    - -In specifying the names of macros and types defined in -header <stdint.h>, C99 makes use of the -symbol N to accommodate unusual platforms with -word sizes that aren't powers of two. C99 -permits N to take on any positive integer value -(including, for example, 24). - -

    -

    - -In cstdint.syn Header <cstdint> -synopsis, C++ on the other hand, fixes the value -of N to 8, 16, 32, and 64, and specifies only -types with these exact widths. - -

    -

    -

    - -In addition, paragraph 1 of the same section makes use of a rather -informal shorthand notation to specify sets of macros. When -interpreted strictly, the notation specifies macros such -as INT_8_MIN that are not intended to be specified. - -

    - -Finally, the section is missing the usual table of symbols defined -in that header, making it inconsistent with the rest of the -specification. - -

    - -

    Proposed resolution:

    -

    - -I propose to use the same approach in the C++ spec as C99 uses, that -is, to specify the header synopsis in terms of "exposition only" types -that make use of the symbol N to denote one or -more of a theoretically unbounded set of widths. - -

    -

    - -Further, I propose to add a new table to section listing the symbols -defined in the header using a more formal notation that avoids -introducing inconsistencies. - -

    -

    - -To this effect, in cstdint.syn -Header <cstdint> synopsis, replace both the -synopsis and paragraph 1 with the following text: - -

    -
    -

    -

      -
    1. - -In the names defined in the <cstdint> header, the -symbol N represents a positive decimal integer -with no leading zeros (e.g., 8 or 24, but not 0, 04, or 048). With the -exception of exact-width types, macros and types for values -of N in the set of 8, 16, 32, and 64 are -required. Exact-width types, and any macros and types for values -of N other than 8, 16, 32, and 64 are -optional. However, if an implementation provides integer types with -widths of 8, 16, 32, or 64 bits, the corresponding exact-width types -and macros are required. - -
      2. -
    - - 
    namespace std {
-
-   // required types
-
-   // Fastest minimum-width integer types
-   typedef signed integer type   int_fast8_t;
-   typedef signed integer type   int_fast16_t;
-   typedef signed integer type   int_fast32_t;
-   typedef signed integer type   int_fast64_t;
-
-   typedef unsigned integer type uint_fast8_t;
-   typedef unsigned integer type uint_fast16_t;
-   typedef unsigned integer type uint_fast32_t;
-   typedef unsigned integer type uint_fast64_t;
-
-   // Minimum-width integer types
-   typedef signed integer type   int_least8_t;
-   typedef signed integer type   int_least16_t;
-   typedef signed integer type   int_least32_t;
-   typedef signed integer type   int_least64_t;
-
-   typedef unsigned integer type uint_least8_t;
-   typedef unsigned integer type uint_least16_t;
-   typedef unsigned integer type uint_least32_t;
-   typedef unsigned integer type uint_least64_t;
-
-   // Greatest-width integer types
-   typedef signed integer type   intmax_t;
-   typedef unsigned integer type uintmax_t;
-
-   // optionally defined types
-
-   // Exact-width integer types
-   typedef signed integer type   intN_t;
-   typedef unsigned integer type uintN_t;
-
-   // Fastest minimum-width integer types for values
-   // of N other than 8, 16, 32, and 64
-   typedef signed integer type   uint_fastN_t;
-   typedef unsigned integer type uint_fastN_t;
-
-   // Minimum-width integer types for values
-   // of N other than 8, 16, 32, and 64
-   typedef signed integer type   uint_leastN_t;
-   typedef unsigned integer type uint_leastN_t;
-
-   // Integer types capable of holding object pointers
-   typedef signed integer type   intptr_t;
-   typedef signed integer type   intptr_t;
-
-}
    -
    -

    - -[Note to editor: Remove all of the existing paragraph 1 from cstdint.syn.] - -

    -
    - Table ??: Header <cstdint> synopsis - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    TypeName(s)
    Macros:INTN_MININTN_MAXUINTN_MAX
    INT_FASTN_MININT_FASTN_MAXUINT_FASTN_MAX
    INT_LEASTN_MININT_LEASTN_MAXUINT_LEASTN_MAX
    INTPTR_MININTPTR_MAXUINTPTR_MAX
    INTMAX_MININTMAX_MAXUINTMAX_MAX
    PTRDIFF_MINPTRDIFF_MAXPTRDIFF_MAX
    SIG_ATOMIC_MINSIG_ATOMIC_MAXSIZE_MAX
    WCHAR_MINWCHAR_MAX
    WINT_MINWINT_MAX
    INTN_C()UINTN_C()
    INTMAX_C()UINTMAX_C()
    Types:intN_tuintN_t
    int_fastN_tuint_fastN_t
    int_leastN_tuint_leastN_t
    intptr_tuintptr_t
    intmax_tuintmax_t
    -
    - - - - - -
    -

    842. ConstructibleAsElement and bit containers

    -

    Section: 23.1 [container.requirements], 23.2.7 [vector.bool], 23.3.5 [template.bitset] Status: Ready - Submitter: Howard Hinnant Date: 2008-06-03

    -

    View other active issues in [container.requirements].

    -

    View all other issues in [container.requirements].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -23.1 [container.requirements]/p3 says: -

    - -
    -Objects stored in these components shall be constructed using -construct_element (20.6.9). For each operation that inserts an -element of type T into a container (insert, -push_back, push_front, emplace, etc.) with -arguments args... T shall be ConstructibleAsElement, -as described in table 88. [Note: If the component is instantiated -with a scoped allocator of type A (i.e., an allocator for which -is_scoped_allocator<A>::value is true), then -construct_element may pass an inner allocator argument to -T's constructor. -- end note] -
    - -

    -However vector<bool, A> (23.2.7 [vector.bool]) and bitset<N> -(23.3.5 [template.bitset]) store bits, not bools, and bitset<N> -does not even have an allocator. But these containers are governed by this clause. Clearly this -is not implementable. -

    - - -

    Proposed resolution:

    -

    -Change 23.1 [container.requirements]/p3: -

    - -
    -Objects stored in these components shall be constructed using -construct_element (20.6.9), unless otherwise specified. -For each operation that inserts an -element of type T into a container (insert, -push_back, push_front, emplace, etc.) with -arguments args... T shall be ConstructibleAsElement, -as described in table 88. [Note: If the component is instantiated -with a scoped allocator of type A (i.e., an allocator for which -is_scoped_allocator<A>::value is true), then -construct_element may pass an inner allocator argument to -T's constructor. -- end note] -
    - -

    -Change 23.2.7 [vector.bool]/p2: -

    - -
    -Unless described below, all operations have the same requirements and semantics as the primary vector template, -except that operations dealing with the bool value type map to bit values in the container storage, -and construct_element (23.1 [container.requirements]) is not used to construct these values. -
    - -

    -Move 23.3.5 [template.bitset] to clause 20. -

    - - - - - - -
    -

    843. Reference Closure

    -

    Section: 20.6.17.1 [func.referenceclosure.cons] Status: New - Submitter: Lawrence Crowl Date: 2008-06-02

    -

    View all issues with New status.

    -

    Discussion:

    -

    -The std::reference_closure type has a deleted copy assignment operator -under the theory that references cannot be assigned, and hence the -assignment of its reference member must necessarily be ill-formed. -

    -

    -However, other types, notably std::reference_wrapper and std::function -provide for the "copying of references", and thus the current definition -of std::reference_closure seems unnecessarily restrictive. In particular, -it should be possible to write generic functions using both std::function -and std::reference_closure, but this generality is much harder when -one such type does not support assignment. -

    -

    -The definition of reference_closure does not necessarily imply direct -implementation via reference types. Indeed, the reference_closure is -best implemented via a frame pointer, for which there is no standard -type. -

    -

    -The semantics of assignment are effectively obtained by use of the -default destructor and default copy assignment operator via -

    - -
    x.~reference_closure(); new (x) reference_closure(y);
-
    - -

    -So the copy assignment operator generates no significant real burden -to the implementation. -

    - - -

    Proposed resolution:

    -

    -In 20.6.17 [func.referenceclosure] Class template reference_closure, -replace the =delete in the copy assignment operator in the synopsis -with =default. -

    - -
    template<class R , class... ArgTypes > 
-  class reference_closure<R (ArgTypes...)> { 
-  public:
-     ...
-     reference_closure& operator=(const reference_closure&) = delete default;
-     ...
-
    - -

    -In 20.6.17.1 [func.referenceclosure.cons] Construct, copy, destroy, -add the member function description -

    - -
    -
    reference_closure& operator=(const reference_closure& f)
-
    -
    -

    -Postcondition: *this is a copy of f. -

    -

    -Returns: *this. -

    -
    -
    - - - - - - - -
    -

    844. complex pow return type is ambiguous

    -

    Section: 26.3.9 [cmplx.over] Status: Ready - Submitter: Howard Hinnant Date: 2008-06-03

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -The current working draft is in an inconsistent state. -

    - -

    -26.3.8 [complex.transcendentals] says that: -

    - -
    -pow(complex<float>(), int()) returns a complex<float>. -
    - -

    -26.3.9 [cmplx.over] says that: -

    - -
    -pow(complex<float>(), int()) returns a complex<double>. -
    -

    [ -Sophia Antipolis: +San Francisco: ]

    -Since int promotes to double, and C99 doesn't have an int-based -overload for pow, the C99 result is complex<double>, see also C99 -7.22, see also library issue 550. +Martin: this would possibly outlaw an implementation technique that is +currently in use; caching nodes in containers.

    -Special note: ask P.J. Plauger. +Alan: if you cache in the allocator, rather than the individual +container, this proposal doesn't interfere with that. +

    +

    +Martin: I'm not opposed to this, but I'd like to see an implementation +that demonstrates that it works.

    -
    -Looks fine. -
    +

    Proposed resolution:

    -

    -Strike this pow overload in 26.3.1 [complex.synopsis] and in 26.3.8 [complex.transcendentals]: -

    - -
    template<class T> complex<T> pow(const complex<T>& x, int y);
-
    - - - - - -
    -

    845. atomics cannot support aggregate initialization

    -

    Section: 29.3 [atomics.types] Status: New - Submitter: Alisdair Meredith Date: 2008-06-03

    -

    View other active issues in [atomics.types].

    -

    View all other issues in [atomics.types].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -The atomic classes (and class templates) are required to support aggregate -initialization (29.3.1 [atomics.types.integral]p2 / 29.3.2 [atomics.types.address]p1) -yet also have user declared constructors, so cannot be aggregates. -

    -

    -This problem might be solved with the introduction of the proposed -initialization syntax at Antipolis, but the wording above should be altered. -Either strike the sentence as redundant with new syntax, or refer to 'brace -initialization'. -

    - -

    [ -Jens adds: -]

    - - -
    -

    -Note that -

    -
    atomic_itype a1 = { 5 };
-
    -

    -would be aggregate-initialization syntax (now coming under the disguise -of brace initialization), but would be ill-formed, because the corresponding -constructor for atomic_itype is explicit. This works, though: -

    -
    atomic_itype a2 { 6 };
-
    - -
    - - -

    Proposed resolution:

    -

    -In 29.3.1 [atomics.types.integral], strike the following sentence from paragraph 2: -

    - -
    -The atomic integral types shall have standard layout. They shall each have a trivial default constructor, a constexpr -explicit value constructor, a deleted copy constructor, a deleted copy assignment operator, and a trivial destructor. -They shall each support aggregate initialization syntax. -
    - -

    [ -2008-08-18, Lawrence adds: -]

    - -
    -The syntactic compatibility of initialization with C is important. -I suggest a different resolution; remove the explicit from the -constructor. For the same reasons we can have implicit conversions, -we can also have implicit constructors. -
    - - - - - -
    -

    846. No definition for constructor

    -

    Section: 29.3 [atomics.types] Status: New - Submitter: Alisdair Meredith Date: 2008-06-03

    -

    View other active issues in [atomics.types].

    -

    View all other issues in [atomics.types].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -The atomic classes and class templates (29.3.1 [atomics.types.integral] / -29.3.2 [atomics.types.address]) have a constexpr -constructor taking a value of the appropriate type for that atomic. -However, neither clause provides semantics or a definition for this -constructor. I'm not sure if the initialization is implied by use of -constexpr keyword (which restricts the form of a constructor) but even if -that is the case, I think it is worth spelling out explicitly as the -inference would be far too subtle in that case. -

    - - -

    Proposed resolution:

    -

    -

    @@ -16954,10 +12291,11 @@ inference would be far too subtle in that case.

    847. string exception safety guarantees

    -

    Section: 21.3.1 [string.require] Status: New - Submitter: Hervé Brönnimann Date: 2008-06-05

    +

    Section: 21.4.1 [string.require] Status: Open + Submitter: Hervé Brönnimann Opened: 2008-06-05 Last modified: 2009-02-14

    +

    View other active issues in [string.require].

    View all other issues in [string.require].

    -

    View all issues with New status.

    +

    View all issues with Open status.

    Discussion:

    In March, on comp.lang.c++.moderated, I asked what were the @@ -16965,7 +12303,7 @@ string exception safety guarantees are, because I cannot see *any* in the working paper, and any implementation I know offers the strong exception safety guarantee (string unchanged if a member throws exception). The closest the current draft comes to -offering any guarantees is 21.3 [basic.string], para 3: +offering any guarantees is 21.4 [basic.string], para 3:

    @@ -16976,7 +12314,7 @@ and for an Allocator-aware container (91). The iterators supported by

    -However, the chapter 23 only says, on the topic of exceptions: 23.1 [container.requirements], +However, the chapter 23 only says, on the topic of exceptions: 23.2 [container.requirements], para 10:

    @@ -16996,7 +12334,7 @@ I take it as saying that this paragraph has *no* implication on std::basic_string, as basic_string isn't defined in Clause 23 and this paragraph does not define a *requirement* of Sequence nor Reversible Container, just of the models defined in Clause 23. -In addition, LWG Issue 718 proposes to remove 23.1 [container.requirements], para 3. +In addition, LWG Issue 718 proposes to remove 23.2 [container.requirements], para 3.

    @@ -17013,15 +12351,35 @@ Bo Persson, was all that this would be worth an LWG issue.

    A related issue is that erase() does not throw. This should be -stated somewhere (and again, I don't think that the 23.1 [container.requirements], para 1 +stated somewhere (and again, I don't think that the 23.2 [container.requirements], para 1 applies here).

    +

    [ +San Francisco: +]

    + + +
    +Implementors will study this to confirm that it is actually possible. +
    + +

    [ +Daniel adds 2009-02-14: +]

    + + +
    +The proposed resolution of paper +N2815 +interacts with this issue (the paper does not refer to this issue). +
    +

    Proposed resolution:

    -Add a blanket statement in 21.3.1 [string.require]: +Add a blanket statement in 21.4.1 [string.require]:

    @@ -17046,208 +12404,17 @@ or add paragraphs to Effects clauses wherever appropriate. -
    -

    848. missing std::hash specializations for std::bitset/std::vector<bool>

    -

    Section: 20.6.16 [unord.hash] Status: Ready - Submitter: Thorsten Ottosen Date: 2008-06-05

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -In the current working draft, std::hash<T> is specialized for builtin -types and a few other types. Bitsets seems like one that is missing from -the list, not because it cannot not be done by the user, but because it -is hard or impossible to write an efficient implementation that works on -32bit/64bit chunks at a time. For example, std::bitset is too much -encapsulated in this respect. -

    - - -

    Proposed resolution:

    -

    -Add the following to the synopsis in 20.6 [function.objects]/2: -

    - -
    template<class Allocator> struct hash<std::vector<bool,Allocator>>;
-template<size_t N> struct hash<std::bitset<N>>;
-
    - -

    -Modify the last sentence of 20.6.16 [unord.hash]/1 to end with: -

    - -
    -... and std::string, std::u16string, std::u32string, std::wstring, -std::error_code, std::thread::id, std::bitset, and std::vector<bool>. -
    - - - - - - -
    -

    849. missing type traits to compute root class and derived class of types in a class hierachy

    -

    Section: 20.5.7 [meta.trans.other] Status: New - Submitter: Thorsten Ottosen Date: 2008-06-05

    -

    View other active issues in [meta.trans.other].

    -

    View all other issues in [meta.trans.other].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -The type traits library contains various traits to dealt with -polymorphic types, e.g. std::has_virtual_destructor, std::is_polymorphic -and std::is_base_of. However, there is no way to compute the unique -public base class of a type if such one exists. Such a trait could be -very useful if one needs to instantiate a specialization made for the -root class whenever a derived class is passed as parameter. For example, -imagine that you wanted to specialize std::hash for a class -hierarchy---instead of specializing each class, you could specialize the -std::hash<root_class> and provide a partial specialization that worked -for all derived classes. -

    - -

    -This ability---to specify operations in terms of their equivalent in the -root class---can be done with e.g. normal functions, but there is, -AFAIK, no way to do it for class templates. Being able to access -compile-time information about the type-hierachy can be very powerful, -and I therefore also suggest traits that computes the directly derived -class whenever that is possible. -

    - -

    -If the computation can not be done, the traits should fall back on an -identity transformation. I expect this gives the best overall usability. -

    - - -

    Proposed resolution:

    -

    -Add the following to the synopsis in 20.5.2 [meta.type.synop] under "other transformations": -

    - -
    template< class T > struct direct_base_class;
-template< class T > struct direct_derived_class;
-template< class T > struct root_base_class;
-
    - -

    -Add three new entries to table 51 (20.5.7 [meta.trans.other]) with the following content -

    - -
    - - - - - - - - - - - - - - - - - - - -
    TemplateConditionComments
    template< class T > struct direct_base_class;T shall be a complete type.The member typedef type shall equal the accessible unambiguous direct base class of T. -If no such type exists, the member typedef type shall equal T.
    template< class T > struct direct_derived_class;T shall be a complete type.The member typedef type shall equal the unambiguous type which has T -as an accessible unambiguous direct base class. If no such type exists, the member typedef -type shall equal T.
    template< class T > struct root_base_class;T shall be a complete type.The member typedef type shall equal the accessible unambiguous most indirect base class of -T. If no such type exists, the member typedef type shall equal T.
    -
    - - - - - - -
    -

    850. Should shrink_to_fit apply to std::deque?

    -

    Section: 23.2.2.2 [deque.capacity] Status: Ready - Submitter: Niels Dekker Date: 2008-06-05

    -

    View other active issues in [deque.capacity].

    -

    View all other issues in [deque.capacity].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -Issue 755 added a shrink_to_fit function to std::vector and std::string. -It did not yet deal with std::deque, because of the fundamental -difference between std::deque and the other two container types. The -need for std::deque may seem less evident, because one might think that -for this container, the overhead is a small map, and some number of -blocks that's bounded by a small constant. -

    -

    -The container overhead can in fact be arbitrarily large (i.e. is not -necessarily O(N) where N is the number of elements currently held by the -deque). As Bill Plauger noted in a reflector message, unless the map of -block pointers is shrunk, it must hold at least maxN/B pointers where -maxN is the maximum of N over the lifetime of the deque since its -creation. This is independent of how the map is implemented -(vector-like circular buffer and all), and maxN bears no relation to N, -the number of elements it currently holds. -

    -

    -Hervé Brönnimann reports a situation where a deque of requests grew very -large due to some temporary backup (the front request hanging), and the -map of the deque grew quite large before getting back to normal. Just -to put some color on it, assuming a deque with 1K pointer elements in -steady regime, that held, at some point in its lifetime, maxN=10M -pointers, with one block holding 128 elements, the spine must be at -least (maxN / 128), in that case 100K. In that case, shrink-to-fit -would allow to reuse about 100K which would otherwise never be reclaimed -in the lifetime of the deque. -

    -

    -An added bonus would be that it *allows* implementations to hang on to -empty blocks at the end (but does not care if they do or not). A -shrink_to_fit would take care of both shrinks, and guarantee that at -most O(B) space is used in addition to the storage to hold the N -elements and the N/B block pointers. -

    - - -

    Proposed resolution:

    -

    -To Class template deque 23.2.2 [deque] synopsis, add: -

    -
    void shrink_to_fit();
-
    - -

    -To deque capacity 23.2.2.2 [deque.capacity], add: -

    -
    void shrink_to_fit();
-
    - -
    -Remarks: shrink_to_fit is a non-binding request to reduce memory -use. [Note: The request is non-binding to allow latitude for -implementation-specific optimizations. -- end note] -
    -
    - - - - -

    851. simplified array construction

    -

    Section: 23.2.1 [array] Status: Review - Submitter: Benjamin Kosnik Date: 2008-06-05

    +

    Section: 23.3.1 [array] Status: Open + Submitter: Benjamin Kosnik Opened: 2008-06-05 Last modified: 2009-06-10

    View other active issues in [array].

    View all other issues in [array].

    -

    View all issues with Review status.

    +

    View all issues with Open status.

    Discussion:

    This is an issue that came up on the libstdc++ list, where a -discrepency between "C" arrays and C++0x's std::array was pointed +discrepancy between "C" arrays and C++0x's std::array was pointed out.

    @@ -17291,21 +12458,196 @@ Then, the way to build an array from a list of unknown size is: 
    auto a = make_array<T>(1, 4, 6);
    +

    [ +San Francisco: +]

    + + +
    +

    +Benjamin: Move to Ready? +

    +

    +Bjarne: I'm not convinced this is useful enough to add, so I'd like us +to have time to reflect on it. +

    +

    +Alisdair: the constraints are wrong, they should be +

    +
    template<ValueType T, ValueType... Args>
+requires Convertible<Args, T>...
+array<T, sizeof...(Args)> make_array(Args&&... args);
+
    +

    +Alidair: this would be useful if we had a constexpr version. +

    +

    +Bjarne: this is probably useful for arrays with a small number of +elements, but it's not clearly useful otherwise. +

    +

    +Consensus is to move to Open. +

    +
    + +

    [ +2009-06-07 Daniel adds: +]

    + + +
    +

    +I suggest a fix and a simplification of the current proposal: Recent +prototyping by +Howard showed, that a fix is required because narrowing conversion +8.5.4 [dcl.init.list]/6 b.3 +would severely limit the possible distribution of argument types, e.g. +the expression +make_array<double>(1, 2.0) is ill-formed, because the narrowing +happens inside the +function body where no constant expressions exist anymore. Furthermore +given e.g. +

    +
    int f();
+double g();
+
    +

    +we probably want to support +

    +
    make_array<double>(f(), g());
+
    + +

    +as well. To make this feasible, the currently suggested expansion +

    + +
    { std::forward<Args>(args)... }
+
    + +

    +needs to be replaced by +

    + +
    { static_cast<T>(std::forward<Args>(args))... }
+
    + +

    +which is safe, because we already ensure convertibility via the +element-wise Convertible<Args, T> requirement. Some other fixes are +necessary: The ValueType requirement for the function parameters +is invalid, because all lvalue arguments will deduce to an lvalue-reference, +thereby no longer satisfying this requirement. +

    + +

    +The suggested simplification is to provide a default-computed effective +type for the result array based on common_type and decay, in +unconstrained form: +

    + +
    template<typename... Args>
+array<typename decay<typename common_type<Args...>::type>::type,
+sizeof...(Args)>
+make_array(Args&&... args);
+
    + +

    +The approach used below is similar to that of make_pair and make_tuple +using a symbol C to represent the decayed common type [Note: Special +handling of reference_wrapper types is intentionally not provided, because +our target has so satisfy ValueType, thus under the revised proposal only +an all-reference_wrapper-arguments would be well-formed and an array of +reference_wrapper will be constructed]. I do currently not suggest to +add new concepts reflecting decay and common_type, but an implementor will +need something like this to succeed. Note that we use a similar fuzziness for +make_pair and make_tuple currently. This fuzziness is not related to +the currently +missing Constructible<Vi, Ti&&> requirement for those functions. The following +proposal fixes that miss for make_array. If the corresponding C type +deduction is +explicitly wanted for standardization, here the implementation +

    + +
    auto concept DC<typename... T> {
+  typename type = typename decay<typename common_type<T...>::type>::type;
+}
+
    + +

    +where C is identical to DC<Args...>::type in the proposed resolution below. +

    +

    +I intentionally added no further type relation between type and the concept +template parameters, but instead added this requirement below to make +the specification as transparent as possible. As written this concept is +satisfied, if the corresponding associated type exists. +

    + +

    Suggested Resolution:

    + +
      +
    1. +

      +Add to the array synopsis in 23.3 [sequences]: +

      +
      
+template<ReferentType... Args>
+requires ValueType<C> && Constructible<C, Args&&>...
+array<C, sizeof...(Args)>
+make_array(Args&&... args);
+
+
      +
      2. + +
    2. +

      +Append after 23.3.1.7 [array.tuple] Tuple interface to class template array +the following new section: +

      +
      +

      +23.4.1.7 Array creation functions [array.creation] +

      + +
      
+template<ReferentType... Args>
+requires ValueType<C> && Constructible<C, Args&&>...
+array<C, sizeof...(Args)>
+make_array(Args&&... args);
+
      + +
      +

      +Let C be decay<common_type<Args...>::type>::type. +

      +

      +Returns: an array<C, sizeof...(Args)> initialized with +{ static_cast<C>(std::forward<Args>(args))... }. +

      +
      +
      + +
      3. + +
    + +
    +

    Proposed resolution:

    -Add to the array synopis in 23.2 [sequences]: +Add to the array synopsis in 23.3 [sequences]:

    -
    template<typename T, typename... Args>
+
    template<ValueType T, ValueType... Args>
   requires Convertible<Args, T>...
   array<T, sizeof...(Args)> 
   make_array(Args&&... args);
 
    
 
 
    
-Append after 23.2.1.6 [array.tuple] Tuple interface to class template array the
+Append after 23.3.1.7 [array.tuple] Tuple interface to class template array the
 following new section.
 
    
 
@@ -17314,7 +12656,7 @@ following new section.
 23.2.1.7 Convenience interface to class template array [array.tuple]
 
    
 
-
    template<typename T, typename... Args>
+
    template<ValueType T, ValueType... Args>
   requires Convertible<Args, T>...
   array<T, sizeof...(Args)> 
   make_array(Args&&... args);
@@ -17322,7 +12664,7 @@ following new section.
 
 
    
 
    
-Returns: {std::forward<Args>(args)...}
+Returns: an array<T, sizeof...(Args)> initialized with {std::forward<T>(args)...}.
    @@ -17331,58 +12673,117 @@ following new section. -
    -

    852. unordered containers begin(n) mistakenly const

    -

    Section: 23.4 [unord] Status: Ready - Submitter: Robert Klarer Date: 2008-06-12

    -

    View other active issues in [unord].

    -

    View all other issues in [unord].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -In 3 of the four unordered containers the local begin member is mistakenly declared const: -

    - -
    local_iterator begin(size_type n) const;
-
    - - -

    Proposed resolution:

    -

    -Change the synopsis in 23.4.1 [unord.map], 23.4.2 [unord.multimap], and 23.4.4 [unord.multiset]: -

    - -
    local_iterator begin(size_type n) const;
-
    - - - - -

    853. to_string needs updating with zero and one

    -

    Section: 23.3.5 [template.bitset] Status: New - Submitter: Howard Hinnant Date: 2008-06-18

    +

    Section: 20.3.6 [template.bitset] Status: Tentatively Ready + Submitter: Howard Hinnant Opened: 2008-06-18 Last modified: 2009-05-10

    +

    View other active issues in [template.bitset].

    View all other issues in [template.bitset].

    -

    View all issues with New status.

    +

    View all issues with Tentatively Ready status.

    Discussion:

    -Issue 396 adds defaulted arguments to the to_string member, but neglects to update +Issue 396 adds defaulted arguments to the to_string member, but neglects to update the three newer to_string overloads.

    +

    [ +post San Francisco: +]

    + + +
    +Daniel found problems with the wording and provided fixes. Moved from Ready +to Review. +
    + +

    [ +Post Summit: +]

    + + +
    +

    +Alisdair: suggest to not repeat the default arguments in B, C, D +(definition of to_string members) +

    +

    +Walter: This is not really a definition. +

    +

    +Consensus: Add note to the editor: Please apply editor's judgement +whether default arguments should be repeated for B, C, D changes. +

    +

    +Recommend Tentatively Ready. +

    +
    + +

    [ +2009-05-09: See alternative solution in issue 1113. +]

    + + +

    Proposed resolution:

    +
      +
    1. +

      replace in 20.3.6 [template.bitset]/1 (class bitset) +

      +
      template <class charT, class traits>
+  basic_string<charT, traits, allocator<charT> >
+  to_string(charT zero = charT('0'), charT one = charT('1')) const;
+template <class charT>
+  basic_string<charT, char_traits<charT>, allocator<charT> >
+  to_string(charT zero = charT('0'), charT one = charT('1')) const;
+basic_string<char, char_traits<char>, allocator<char> >
+  to_string(char zero = '0', char one = '1') const;
+
      +
      2. +

    2. -Change the synopsis in 23.3.5 [template.bitset], and the signatures in 23.3.5.2 [bitset.members] to: +replace in 20.3.6.2 [bitset.members]/37 +

      +
      template <class charT, class traits>
+  basic_string<charT, traits, allocator<charT> >
+  to_string(charT zero = charT('0'), charT one = charT('1')) const;
+
      +
      +37 Returns: to_string<charT, traits, allocator<charT> >(zero, one). +
      +
      +
      3. +
    3. +

      +replace in 20.3.6.2 [bitset.members]/38

      -
      template <class charT, class traits> 
-  basic_string<charT, traits, allocator<charT> > to_string(charT zero = charT('0'), charT one = charT('1')) const; 
-template <class charT> 
-  basic_string<charT, char_traits<charT>, allocator<charT> > to_string(charT zero = charT('0'), charT one = charT('1')) const; 
-basic_string<char, char_traits<char>, allocator<char> > to_string(char zero = '0', char one = '1') const; 
-
      +
      template <class charT>
+  basic_string<charT, char_traits<charT>, allocator<charT> >
+  to_string(charT zero = charT('0'), charT one = charT('1')) const;
+
      +
      +38 Returns: to_string<charT, char_traits<charT>, allocator<charT> >(zero, one). +
      +
      +
      4. + +
    4. +

      +replace in 20.3.6.2 [bitset.members]/39 +

      + +
      basic_string<char, char_traits<char>, allocator<char> >
+  to_string(char zero = '0', char one = '1') const;
+
      +
      +39 Returns: to_string<char, char_traits<char>, allocator<char> >(zero, one). +
      +
      +
      5. + +
    + @@ -17390,9 +12791,9 @@ basic_string<char, char_traits<char>, allocator<char> > to_str

    854. default_delete converting constructor underspecified

    -

    Section: 20.7.11.1.1 [unique.ptr.dltr.dflt] Status: New - Submitter: Howard Hinnant Date: 2008-06-18

    -

    View all issues with New status.

    +

    Section: 20.8.12.1.1 [unique.ptr.dltr.dflt] Status: Review + Submitter: Howard Hinnant Opened: 2008-06-18 Last modified: 2009-05-23

    +

    View all issues with Review status.

    Discussion:

    No relationship between U and T in the converting constructor for default_delete template. @@ -17408,20 +12809,77 @@ Rules out cross-casting. The requirements for unique_ptr conversions should be the same as those on the deleter.

    +

    [ +Howard adds 2008-11-26: +]

    + + +
    +

    +I believe we need to be careful to not outlaw the following use case, and +I believe the current proposed wording +(requires Convertible<U*, T*> && HasVirtualDestructor<T>) does so: +

    + +
    #include <memory>
+
+int main()
+{
+    std::unique_ptr<int> p1(new int(1));
+    std::unique_ptr<const int> p2(move(p1));
+    int i = *p2;
+//    *p2 = i;  // should not compile
+}
+
    + +

    +I've removed "&& HasVirtualDestructor<T>" from the +requires clause in the proposed wording. +

    + +
    + +

    [ +Post Summit: +]

    + + +
    +

    +Alisdair: This issue has to stay in review pending a paper constraining +unique_ptr. +

    +

    +Consensus: We agree with the resolution, but unique_ptr needs +to be constrained, too. +

    +

    +Recommend Keep in Review. +

    +
    + +

    [ +Batavia (2009-05): +]

    + +
    +Keep in Review status for the reasons cited. +
    +

    Proposed resolution:

    -Change 20.7.11.1.1 [unique.ptr.dltr.dflt]: +Change 20.8.12.1.1 [unique.ptr.dltr.dflt]:

    -
    namespace std { 
-  template <class T> struct default_delete { 
-    default_delete(); 
+
    namespace std {
+  template <class T> struct default_delete {
+    default_delete();
     template <class U>
-      requires Convertible<U*, T*> && HasVirtualDestructor<T>
-      default_delete(const default_delete<U>&); 
-    void operator()(T*) const; 
-  }; 
+      requires Convertible<U*, T*>
+      default_delete(const default_delete<U>&);
+    void operator()(T*) const;
+  };
 }
 
    
 
@@ -17430,7 +12888,7 @@ Change 20.7.11.1.1 [unique.ptr.dltr.dflt]:
 
    
 
 
    template <class U>
-  requires Convertible<U*, T*> && HasVirtualDestructor<T>
+  requires Convertible<U*, T*>
   default_delete(const default_delete<U>& other);
 
    
 
@@ -17439,199 +12897,13 @@ Change 20.7.11.1.1 [unique.ptr.dltr.dflt]:
 
 
 
-
    
-
    855. capacity() and reserve() for deque?
    
-
    Section: 23.2.2.2 [deque.capacity] Status: New
- Submitter: Hervé Brönnimann Date: 2008-06-11
    
-
    View other active issues in [deque.capacity].
    
-
    View all other issues in [deque.capacity].
    
-
    View all issues with New status.
    
-
    Discussion:
    
-
    
-The main point is that capacity can be viewed as a mechanism to  
-guarantee the validity of iterators when only push_back/pop_back
-operations are used.  For vector, this goes with reallocation.  For  
-deque, this is a bit more subtle:  capacity() of a deque may shrink,  
-whereas that of vector doesn't.   In a circular buffer impl. of the  
-map, as Howard did, there is very similar notion of capacity: as long  
-as size() is less than B * (total size of the map - 2), it is  
-guaranteed that no iterator is invalidated after any number of  
-push_front/back and pop_front/back operations.  But this does not  
-hold for other implementations.
-
    
-
    
-Still, I believe, capacity() can be defined by size() +  how many  
-push_front/back minus pop_front/back that can be performed before  
-terators are invalidated.  In a classical impl., capacity() = size()
-+  the min distance to either "physical" end of the deque (i.e.,  
-counting the empty space in the last block plus all the blocks until  
-the end of the map of block pointers).  In Howard's circular buffer  
-impl., capacity() = B * (total size of the map - 2) still works with  
-this definition, even though the guarantee could be made stronger.
-
    
-
    
-A simple picture of a deque:
-
    
-
    A-----|----|-----|---F+|++++|++B--|-----|-----Z
-
    
-
    
-(A,Z mark the beginning/end, | the block boundaries, F=front, B=back,  
-and - are uninitialized, + are initialized)
-In that picture:  capacity = size() + min(dist(A,F),dist(B,Z)) = min 
-(dist(A,B),dist(F,Z)).
-
    
-
    
-Reserve(n) can grow the map of pointers and add possibly a number of  
-empty blocks to it, in order to guarantee that the next n-size()
-push_back/push_front operations will not invalidate iterators, and  
-also will not allocate (i.e. cannot throw).  The second guarantee is  
-not essential and can be left as a QoI.  I know well enough existing  
-implementations of deque (sgi/stl, roguewave, stlport, and  
-dinkumware) to know that either can be implemented with no change to  
-the existing class layout and code, and only a few modifications if  
-blocks are pre-allocated (instead of always allocating a new block,  
-check if the next entry in the map of block pointers is not zero).
-
    
-
    
-Due to the difference with vector, wording is crucial.  Here's a  
-proposed wording to make things concrete;  I tried to be reasonably  
-careful but please double-check me:
-
    
-
-
-
-
    Proposed resolution:
    
-
-
    
-Add new signatures to synopsis in 23.2.2 [deque]:
-
    
-
-
    size_type capacity() const;
-bool reserve(size_type n);
-
    
-
-
    
-Add new signatures to 23.2.2.2 [deque.capacity]:
-
    
-
-
    
-
    size_type capacity() const;
-
    
-
    
-
    
-1 Returns: An upper bound on n + max(n_f - m_f, n_b - m_b)  such  
-that, for any sequence of n_f push_front, m_f pop_front, n_b  
-push_back, and m_b pop_back operations, interleaved in any order,  
-starting with the current deque of size n, the deque does not  
-invalidate any of its iterators except to the erased elements.
-
    
-
    
-2 Remarks:  Unlike a vector's capacity, the capacity of a deque can  
-decrease after a sequence of insertions at both ends, even if none of  
-the operations caused the deque to invalidate any of its iterators  
-except to the erased elements.
-
    
-
    
-
    
-
-
    
-
    bool reserve(size_type n);
-
    
-
    
-
    
-2 Effects: A directive that informs a deque of a planned sequence of  
-push_front, pop_front, push_back, and pop_back operations, so that it  
-can manage iterator invalidation accordingly. After reserve(),  
-capacity() is greater or equal to the argument of reserve if this  
-operation returns true; and equal to the previous value of capacity()
-otherwise.  If an exception is thrown, there are no effects.
-
    
-
    
-3 Returns: true if iterators are invalidated as a result of this  
-operation, and false otherwise.
-
    
-
    
-4 Complexity: It does not change the size of the sequence and takes  
-at most linear time in n.
-
    
-
    
-5 Throws: length_error if n > max_size().
-
    
-
    
-6 Remarks: It is guaranteed that no invalidation takes place during a  
-sequence of insert or erase operations at either end that happens  
-after a call to reserve() except to the erased elements, until the  
-time when an insertion would make max(n_f-m_f, n_b-m_b) larger than  
-capacity(), where n_f is the number of push_front, m_f of pop_front,  
-n_b of push_back, and m_b of pop_back operations since the call to  
-reserve().
-
    
-
    
-7        An implementation is free to pre-allocate buffers so as to  
-offer the additional guarantee that no exception will be thrown  
-during such a sequence other than by the element constructors.
-
    
-
    
-
    
-
-
    
-And 23.2.2.3 [deque.modifiers] para 1, can be enhanced:
-
    
-
-
    
-1 Effects: An insertion in the middle of the deque invalidates all the iterators and references to elements of the
-deque. An insertion at either end of the deque invalidates all the iterators to the deque,
-unless provisions have been made with reserve,
-but has no effect on the validity of references to elements of the deque.
-
    
-
-
-
-
-
-
    
-
    856. Removal of aligned_union
    
-
    Section: 20.5.7 [meta.trans.other] Status: New
- Submitter: Jens Maurer Date: 2008-06-12
    
-
    View other active issues in [meta.trans.other].
    
-
    View all other issues in [meta.trans.other].
    
-
    View all issues with New status.
    
-
    Discussion:
    
-
    
-With the arrival of extended unions 
-(N2544),
-there is no
-known use of aligned_union that couldn't be handled by
-the "extended unions" core-language facility.
-
    
-
-
-
    Proposed resolution:
    
-
    
-Remove the following signature from 20.5.2 [meta.type.synop]:
-
    
-
    template <std::size_t Len, class... Types> struct aligned_union;
-
    
-
-
    
-Remove the second row from table 51 in 20.5.7 [meta.trans.other],
-starting with:
-
    
-
-
    template <std::size_t Len,
-class... Types>
-struct aligned_union;
-
    
-
-
-
-
-
 
    
 
    857. condition_variable::time_wait return bool error prone
    
-
    Section: 30.4.1 [thread.condition.condvar] Status: New
- Submitter: Beman Dawes Date: 2008-06-13
    
-
    View all issues with New status.
    
+
    Section: 30.5.1 [thread.condition.condvar] Status: Open
+ Submitter: Beman Dawes Opened: 2008-06-13  Last modified: 2009-06-14
    
+
    View other active issues in [thread.condition.condvar].
    
+
    View all other issues in [thread.condition.condvar].
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
 The meaning of the bool returned by condition_variable::timed_wait is so
@@ -17657,62 +12929,353 @@ Beman to supply exact wording.
 ]
    
 
 
-
-
    Proposed resolution:
    
+
    [
+San Francisco:
+]
    
 
 
-
-
-
-
    
-
    858. Wording for Minimal Support for Garbage Collection
    
-
    Section: X [garbage.collection] Status: New
- Submitter: Pete Becker  Date: 2008-06-21
    
-
    View all issues with New status.
    
-
    Discussion:
    
-
    
-The first sentence of the Effects clause for undeclare_reachable seems
-to be missing some words. I can't parse
-
    
 
    
-... for all non-null p referencing the argument is no longer declared reachable...
+
    
+There is concern that the enumeration names are just as confusing, if
+not more so, as the bool. You might have awoken because of a signal or a
+spurious wakeup, for example.
+
    
+
    
+Group feels that this is a defect that needs fixing.
+
    
+
    
+Group prefers returning an enum over a void return.
+
    
+
    
+Howard to provide wording.
+
    
 
    
-
    
-I take it the intent is that undeclare_reachable should be called only
-when there has been a corresponding call to declare_reachable. In
-particular, although the wording seems to allow it, I assume that code
-shouldn't call declare_reachable once then call undeclare_reachable
-twice.
-
    
-
    
-I don't know what "shall be live" in the Requires clause means.
-
    
-
    
-In the final Note for undeclare_reachable, what does "cannot be
-deallocated" mean? Is this different from "will not be able to collect"?
-
    
 
-
    
-For the wording on nesting of declare_reachable and
-undeclare_reachable, the words for locking and unlocking recursive
-mutexes probably are a good model.
-
    
+
    [
+2009-06-14 Beman provided wording.
+]
    
+
 
 
 
    Proposed resolution:
    
 
    
+Change Condition variables 30.5 [thread.condition], Header
+condition_variable synopsis, as indicated:
 
    
 
+
    namespace std {
+  class condition_variable;
+  class condition_variable_any;
+
+  enum class cv_status { no_timeout, timeout };
+}
+
    
+
+
    
+Change Class condition_variable 30.5.1 [thread.condition.condvar] as indicated:
+
    
+
+
    class condition_variable { 
+public:
+  ...
+  template <class Clock, class Duration>
+    bool cv_status wait_until(unique_lock<mutex>& lock,
+                    const chrono::time_point<Clock, Duration>& abs_time);
+  template <class Clock, class Duration, class Predicate>
+    bool wait_until(unique_lock<mutex>& lock,
+                    const chrono::time_point<Clock, Duration>& abs_time,
+                    Predicate pred);
+
+  template <class Rep, class Period>
+    bool cv_status wait_for(unique_lock<mutex>& lock,
+                  const chrono::duration<Rep, Period>& rel_time);
+  template <class Rep, class Period, class Predicate>
+    bool wait_for(unique_lock<mutex>& lock,
+                  const chrono::duration<Rep, Period>& rel_time,
+                  Predicate pred);
+  ...
+};
+
+...
+
+template <class Clock, class Duration>
+  bool cv_status wait_until(unique_lock<mutex>& lock,
+                  const chrono::time_point<Clock, Duration>& abs_time);
+
    
+
    
+
    
+-15- Precondition: lock is locked by the calling thread, and either
+
    
+
      
+
    • 
+no other thread is waiting on this condition_variable object or
+
      • 
+
    • 
+lock.mutex() returns the same value for each of the lock
+arguments supplied by all concurrently waiting threads (via wait,
+wait_for or wait_until.).
+
      • 
+
    
+
+
    
+-16- Effects:
+
    
+
+
      
+
    • 
+Atomically calls lock.unlock() and blocks on *this.
+
      • 
+
    • 
+When unblocked, calls lock.lock() (possibly blocking on the lock) and returns.
+
      • 
+
    • 
+The function will unblock when signaled by a call to notify_one(),
+a call to notify_all(), by 
+the current time exceeding abs_time if Clock::now() >= abs_time,
+or spuriously.
+
      • 
+
    • 
+If the function exits via an exception, lock.unlock() shall be called prior
+to exiting the function scope.
+
      • 
+
    
+
+
    
+-17- Postcondition: lock is locked by the calling thread.
+
    
+
+
    
+-18- Returns: Clock::now() < abs_time
+cv_status::timeout if the function unblocked because abs_time
+was reached, otherwise cv_status::no_timeout.
+
    
+
+
    
+-19- Throws: std::system_error when the effects or postcondition
+cannot be achieved.
+
    
+
+
    
+-20- Error conditions:
+
    
+
+
      
+
    • 
+operation_not_permitted — if the thread does not own the lock.
+
      • 
+
    • 
+equivalent error condition from lock.lock() or lock.unlock().
+
      • 
+
    
+
    
+
+
    template <class Rep, class Period>
+  bool cv_status wait_for(unique_lock<mutex>& lock,
+                const chrono::duration<Rep, Period>& rel_time);
+
+
    
+
    
+
    
+-21- Effects Returns:
+
    
+
    wait_until(lock, chrono::monotonic_clock::now() + rel_time)
+
    
+
    
+-22- Returns: false if the call is returning because the time
+duration specified by rel_time has elapsed, 
+otherwise true.
+
    
+
+
    [
+This part of the wording may conflict with 859 in detail, but does
+not do so in spirit.  If both issues are accepted, there is a logical merge.
+]
    
+
+
    
+
+
    template <class Clock, class Duration, class Predicate> 
+  bool wait_until(unique_lock<mutex>& lock, 
+                  const chrono::time_point<Clock, Duration>& abs_time, 
+                  Predicate pred);
+
    
+
+
    
+
    
+-23- Effects:
+
    
+
    while (!pred()) 
+  if (!wait_until(lock, abs_time) == cv_status::timeout) 
+    return pred(); 
+return true;
+
    
+
+
    
+-24- Returns: pred().
+
    
+
+
    
+-25- [Note:
+The returned value indicates whether the predicate evaluates to
+true regardless of whether the timeout was triggered.
+— end note].
+
    
+
    
+
    
+
+
    
+Change Class condition_variable_any 30.5.2 [thread.condition.condvarany] as indicated:
+
    
+
+
    class condition_variable_any {
+public:
+  ...
+  template <class Lock, class Clock, class Duration>
+    bool cv_status wait_until(Lock& lock,
+                    const chrono::time_point<Clock, Duration>& abs_time);
+  template <class Lock, class Clock, class Duration, class Predicate>
+    bool wait_until(Lock& lock,
+                    const chrono::time_point<Clock, Duration>& abs_time,
+                    Predicate pred);
+
+  template <class Lock, class Rep, class Period>
+    bool cv_status wait_for(Lock& lock,
+                  const chrono::duration<Rep, Period>& rel_time);
+  template <class Lock, class Rep, class Period, class Predicate>
+    bool wait_for(Lock& lock,
+                  const chrono::duration<Rep, Period>& rel_time,
+                  Predicate pred);
+  ...
+};
+
+...
+
+template <class Lock, class Clock, class Duration>
+  bool cv_status wait_until(Lock& lock,
+                  const chrono::time_point<Clock, Duration>& abs_time);
+
    
+
+
    
+
+
    
+-13- Effects:
+
    
+
+
      
+
    • 
+Atomically calls lock.unlock() and blocks on *this.
+
      • 
+
    • 
+When unblocked, calls lock.lock() (possibly blocking on the lock) and returns.
+
      • 
+
    • 
+The function will unblock when signaled by a call to notify_one(),
+a call to notify_all(), by 
+the current time exceeding abs_time if Clock::now() >= abs_time,
+or spuriously.
+
      • 
+
    • 
+If the function exits via an exception, lock.unlock() shall be called prior
+to exiting the function scope.
+
      • 
+
    
+
+
    
+-14- Postcondition: lock is locked by the calling thread.
+
    
+
+
    
+-15- Returns: Clock::now() < abs_time
+cv_status::timeout if the function unblocked because abs_time
+was reached, otherwise cv_status::no_timeout.
+
    
+
+
    
+-16- Throws: std::system_error when the effects or postcondition
+cannot be achieved.
+
    
+
+
    
+-17- Error conditions:
+
    
+
+
      
+
    • 
+equivalent error condition from lock.lock() or lock.unlock().
+
      • 
+
    
+
    
+
+
    template <class Lock, class Rep, class Period>
+  bool cv_status wait_for(Lock& lock,
+                const chrono::duration<Rep, Period>& rel_time);
+
+
    
+
+
    
+
    
+-18- Effects Returns:
+
    
+
    wait_until(lock, chrono::monotonic_clock::now() + rel_time)
+
    
+
+
    
+-19- Returns: false if the call is returning because the time
+duration specified by rel_time has elapsed, 
+otherwise true.
+
    
+
+
    [
+This part of the wording may conflict with 859 in detail, but does
+not do so in spirit.  If both issues are accepted, there is a logical merge.
+]
    
+
+
+
    
+
+
    template <class Lock, class Clock, class Duration, class Predicate> 
+  bool wait_until(Lock& lock, 
+                  const chrono::time_point<Clock, Duration>& rel_time abs_time, 
+                  Predicate pred);
+
    
+
+
    
+
    
+-20- Effects:
+
    
+
    while (!pred()) 
+  if (!wait_until(lock, abs_time) == cv_status::timeout) 
+    return pred(); 
+return true;
+
    
+
+
    
+-21- Returns: pred().
+
    
+
+
    
+-22- [Note:
+The returned value indicates whether the predicate evaluates to
+true regardless of whether the timeout was triggered.
+— end note].
+
    
+
    
+
+
    
+
+
 
 
 
 
 
    
 
    859. Monotonic Clock is Conditionally Supported?
    
-
    Section: X [datetime] Status: New
- Submitter: Pete Becker Date: 2008-06-23
    
-
    View all issues with New status.
    
+
    Section: 30.5 [thread.condition] Status: Open
+ Submitter: Pete Becker Opened: 2008-06-23  Last modified: 2009-06-14
    
+
    View all issues with Open status.
    
 
    Discussion:
    
+
+
    Related to 958, 959.
    
+
 
    
 N2661
 says that there is a class named monotonic_clock. It also says that this
@@ -17735,20 +13298,414 @@ meaning of an effects clause that says
 when monotonic_clock is not required to exist?
 
    
 
+
    [
+San Francisco:
+]
    
+
+
+
    
+
    
+Nick: maybe instead of saying that chrono::monotonic_clock is
+conditionally supported, we could say that it's always there, but not
+necessarily supported..
+
    
+
    
+Beman: I'd prefer a typedef that identifies the best clock to use for
+wait_for locks.
+
    
+
    
+Tom: combine the two concepts; create a duration clock type, but keep
+the is_monotonic test.
+
    
+
    
+Howard: if we create a duration_clock type, is it a typedef or an
+entirely true type?
+
    
+
    
+There was broad preference for a typedef.
+
    
+
    
+Move to Open. Howard to provide wording to add a typedef for
+duration_clock and to replace all uses of monotonic_clock in function
+calls and signatures with duration_clock.
+
    
+
    
+
+
    [
+Howard notes post-San Francisco:
+]
    
+
+
+
    
+
    
+After further thought I do not believe that creating a duration_clock typedef
+is the best way to proceed.  An implementation may not need to use a
+time_point to implement the wait_for functions.
+
    
+
+
    
+For example, on POSIX systems sleep_for can be implemented in terms of
+nanosleep which takes only a duration in terms of nanoseconds.  The current
+working paper does not describe sleep_for in terms of sleep_until.
+And paragraph 2 of 30.2.4 [thread.req.timing] has the words strongly encouraging
+implementations to use monotonic clocks for sleep_for:
+
    
+
+
    
+2 The member functions whose names end in _for take an argument that
+specifies a relative time. Implementations should use a monotonic clock to
+measure time for these functions.
+
    
+
+
    
+I believe the approach taken in describing the effects of sleep_for
+and try_lock_for is also appropriate for wait_for.  I.e. these
+are not described in terms of their _until variants.
+
    
+
+
    
+
+
 
 
    Proposed resolution:
    
 
    
+Change 30.5.1 [thread.condition.condvar], p21-22:
 
    
 
+
    
+
    template <class Rep, class Period> 
+  bool wait_for(unique_lock<mutex>& lock, 
+                const chrono::duration<Rep, Period>& rel_time);
+
    
+
    
+
    
+Precondition: lock is locked by the calling thread, and either
+
    
+
      
+
    • no other thread is waiting on this condition_variable object or
      • 
+
    • lock.mutex() returns the same value for each of the lock
+arguments supplied by all concurrently waiting threads (via wait,
+wait_for or wait_until).
      • 
+
    
+
    
+21 Effects:
+
    
+
    wait_until(lock, chrono::monotonic_clock::now() + rel_time)
+
    
+
      
+
    • 
+Atomically calls lock.unlock() and blocks on *this.
+
      • 
+
+
    • 
+When unblocked, calls lock.lock() (possibly blocking on the lock) and returns.
+
      • 
+
+
    • 
+The function will unblock when signaled by a call to notify_one(), a call
+to notify_all(), by 
+the elapsed time rel_time passing (30.2.4 [thread.req.timing]),
+or spuriously.
+
      • 
+
+
    • 
+If the function exits via an exception, lock.unlock() shall be called 
+prior to exiting the function scope.
+
      • 
+
    
+
+
    
+Postcondition: lock is locked by the calling thread.
+
    
+
+
+
    
+22 Returns: false if the call is returning because the time
+duration specified by rel_time has elapsed, otherwise true.
+
    
+
+
    [
+This part of the wording may conflict with 857 in detail, but does
+not do so in spirit.  If both issues are accepted, there is a logical merge.
+]
    
+
+
+
    
+Throws: std::system_error when the effects or postcondition cannot be achieved.
+
    
+
+
    
+Error conditions:
+
    
+
+
      
+
    • 
+operation_not_permitted -- if the thread does not own the lock.
+
      • 
+
    • 
+equivalent error condition from lock.lock() or lock.unlock().
+
      • 
+
    
+
+
    
+
    
+
+
    
+Change 30.5.1 [thread.condition.condvar], p26-p29:
+
    
+
+
    
+
    template <class Rep, class Period, class Predicate> 
+  bool wait_for(unique_lock<mutex>& lock, 
+                const chrono::duration<Rep, Period>& rel_time, 
+                Predicate pred);
+
    
+
    
+
    
+Precondition: lock is locked by the calling thread, and either
+
    
+
      
+
    • no other thread is waiting on this condition_variable object or
      • 
+
    • lock.mutex() returns the same value for each of the lock
+arguments supplied by all concurrently waiting threads (via wait,
+wait_for or wait_until).
      • 
+
    
+
    
+26 Effects:
+
    
+
    wait_until(lock, chrono::monotonic_clock::now() + rel_time, std::move(pred))
+
    
+
      
+
    • 
+Executes a loop:  Within the loop the function first evaluates pred()
+and exits the loop if the result of pred() is true.
+
      • 
+
    • 
+Atomically calls lock.unlock()
+and blocks on *this.
+
      • 
+
    • 
+When unblocked, calls lock.lock() (possibly blocking on the lock).
+
      • 
+
    • 
+The function will unblock when signaled by a call to notify_one(), a
+call to notify_all(), by the elapsed time rel_time passing (30.1.4
+[thread.req.timing]), or spuriously.
+
      • 
+
    • 
+If the function exits via an exception, lock.unlock() shall be called
+prior to exiting the function scope.
+
      • 
+
    • 
+The loop terminates when pred() returns true or when the time
+duration specified by rel_time has elapsed.
+
      • 
+
    
+
    
+
+
    
+27 [Note: There is no blocking if pred() is initially true,
+even if the timeout has already expired. -- end note]
+
    
+
+
    
+Postcondition: lock is locked by the calling thread.
+
    
+
+
    
+28 Returns: pred()
+
    
+
+
    
+29 [Note: The returned value indicates whether the predicate evaluates to
+true regardless of whether the timeout was triggered. -- end note]
+
    
+
+
    
+Throws: std::system_error when the effects or postcondition cannot be achieved.
+
    
+
+
    
+Error conditions:
+
    
+
+
      
+
    • 
+operation_not_permitted -- if the thread does not own the lock.
+
      • 
+
    • 
+equivalent error condition from lock.lock() or lock.unlock().
+
      • 
+
    
+
+
    
+
    
+
+
    
+Change 30.5.2 [thread.condition.condvarany], p18-19:
+
    
+
+
    
+
    template <class Lock, class Rep, class Period> 
+  bool wait_for(Lock& lock, const chrono::duration<Rep, Period>& rel_time);
+
    
+
    
+
    
+18 Effects:
+
    
+
    wait_until(lock, chrono::monotonic_clock::now() + rel_time)
+
    
+
+
      
+
    • 
+Atomically calls lock.unlock() and blocks on *this.
+
      • 
+
+
    • 
+When unblocked, calls lock.lock() (possibly blocking on the lock) and returns.
+
      • 
+
+
    • 
+The function will unblock when signaled by a call to notify_one(), a call to
+notify_all(), by
+the elapsed time rel_time passing (30.2.4 [thread.req.timing]),
+or spuriously.
+
      • 
+
+
    • 
+If the function exits via an exception, lock.unlock() shall be called
+prior to exiting the function scope.
+
      • 
+
    
+
+
    
+Postcondition: lock is locked by the calling thread.
+
    
+
+
    
+19 Returns: false if the call is returning because the time duration
+specified by rel_time has elapsed, otherwise true.
+
    
+
+
    
+Throws: std::system_error when the returned value, effects,
+or postcondition cannot be achieved.
+
    
+
+
    
+Error conditions:
+
    
+
+
      
+
    • 
+equivalent error condition from lock.lock() or lock.unlock().
+
      • 
+
    
+
    
+
    
+
+
    
+Change 30.5.2 [thread.condition.condvarany], p23-p26:
+
    
+
+
    
+
    template <class Lock, class Rep, class Period, class Predicate> 
+  bool wait_for(Lock& lock, const chrono::duration<Rep, Period>& rel_time, Predicate pred);
+
    
+
    
+
    
+Precondition: lock is locked by the calling thread, and either
+
    
+
      
+
    • no other thread is waiting on this condition_variable object or
      • 
+
    • lock.mutex() returns the same value for each of the lock
+arguments supplied by all concurrently waiting threads (via wait,
+wait_for or wait_until).
      • 
+
    
+
    
+23 Effects:
+
    
+
    wait_until(lock, chrono::monotonic_clock::now() + rel_time, std::move(pred))
+
    
+
      
+
    • 
+Executes a loop:  Within the loop the function first evaluates pred()
+and exits the loop if the result of pred() is true.
+
      • 
+
    • 
+Atomically calls lock.unlock()
+and blocks on *this.
+
      • 
+
    • 
+When unblocked, calls lock.lock() (possibly blocking on the lock).
+
      • 
+
    • 
+The function will unblock when signaled by a call to notify_one(), a
+call to notify_all(), by the elapsed time rel_time passing (30.1.4
+[thread.req.timing]), or spuriously.
+
      • 
+
    • 
+If the function exits via an exception, lock.unlock() shall be called
+prior to exiting the function scope.
+
      • 
+
    • 
+The loop terminates when pred() returns true or when the time
+duration specified by rel_time has elapsed.
+
      • 
+
    
+
    
+
+
    
+24 [Note: There is no blocking if pred() is initially true,
+even if the timeout has already expired. -- end note]
+
    
+
+
    
+Postcondition: lock is locked by the calling thread.
+
    
+
+
    
+25 Returns: pred()
+
    
+
+
    
+26 [Note: The returned value indicates whether the predicate evaluates to
+true regardless of whether the timeout was triggered. -- end note]
+
    
+
+
    
+Throws: std::system_error when the effects or postcondition cannot be achieved.
+
    
+
+
    
+Error conditions:
+
    
+
+
      
+
    • 
+operation_not_permitted -- if the thread does not own the lock.
+
      • 
+
    • 
+equivalent error condition from lock.lock() or lock.unlock().
+
      • 
+
    
+
+
    
+
    
+
+
+
 
 
 
 
 
    
 
    860. Floating-Point State
    
-
    Section: 26 [numerics] Status: New
- Submitter: Lawrence Crowl Date: 2008-06-23
    
-
    View all issues with New status.
    
+
    Section: 26 [numerics] Status: Open
+ Submitter: Lawrence Crowl Opened: 2008-06-23  Last modified: 2009-03-09
    
+
    View other active issues in [numerics].
    
+
    View all other issues in [numerics].
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
 There are a number of functions that affect the floating point state.
@@ -17756,6 +13713,75 @@ These function need to be thread-safe, but I'm unsure of the right
 approach in the standard, as we inherit them from C.
 
    
 
+
    [
+San Francisco:
+]
    
+
+
+
    
+
    
+Nick: I think we already say that these functions do not introduce data
+races; see 17.6.5.6/20
+
    
+
    
+Pete: there's more to it than not introducing data races; are these
+states maintained per thread?
+
    
+
    
+Howard: 21.5/14 says that strtok and strerror are not required to avoid
+data races, and 20.9/2 says the same about asctime, gmtime, ctime, and
+gmtime.
+
    
+
    
+Nick: POSIX has a list of not-safe functions. All other functions are
+implicitly thread safe.
+
    
+
    
+Lawrence is to form a group between meetings to attack this issue. Nick
+and Tom volunteered to work with Lawrence.
+
    
+
    
+Move to Open.
+
    
+
    
+
+
    [
+Post Summit:
+]
    
+
+
+
    
+
    
+Hans: Sane oses seem ok. Sensible thing is implementable and makes sense.
+
    
+
    
+Nick: Default wording seems to cover this? Hole in POSIX, these
+functions need to be added to list of thread-unsafe functions.
+
    
+
    
+Lawrence: Not sufficient, not "thread-safe" per our definition, but
+think of state as a thread-local variable. Need something like "these
+functions only affect state in the current thread."
+
    
+
    
+Hans: Suggest the following wording: "The floating point environment is
+maintained per-thread."
+
    
+
    
+Walter: Any other examples of state being thread safe that are not
+already covered elsewhere?
+
    
+
    
+Have thread unsafe functions paper which needs to be updated. Should
+just fold in 26.3 [cfenv] functions.
+
    
+
    
+Recommend Open. Lawrence instead suggests leaving it open until we have
+suitable wording that may or may not include the thread local
+commentary.
+
    
+
    
+
 
 
    Proposed resolution:
    
 
    
@@ -17767,11 +13793,11 @@ approach in the standard, as we inherit them from C.
 
 
    
 
    861. Incomplete specification of EqualityComparable for std::forward_list
    
-
    Section: 23.1 [container.requirements] Status: New
- Submitter: Daniel Krügler Date: 2008-06-24
    
+
    Section: 23.2 [container.requirements] Status: Open
+ Submitter: Daniel Krügler Opened: 2008-06-24  Last modified: 2008-11-11
    
 
    View other active issues in [container.requirements].
    
 
    View all other issues in [container.requirements].
    
-
    View all issues with New status.
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
 Table 89, Container requirements, defines operator== in terms of the container
@@ -17815,6 +13841,33 @@ Both proposal choices are discussed, the preferred choice of the author is
 to apply (A).
 
    
 
+
    [
+San Francisco:
+]
    
+
+
+
    
+
    
+There's an Option C: change the requirements table to use distance().
+
    
+
    
+LWG found Option C acceptable.
+
    
+
    
+Martin will draft the wording for Option C.
+
    
+
    
+
+
    [
+post San Francisco:
+]
    
+
+
+
    
+Martin provided wording for Option C.
+
    
+
+
 
 
    Proposed resolution:
    
 
    
@@ -17823,11 +13876,11 @@ Common part:
 
      
 
    • 
 
      
-Just betwen 23.2.3.5 [forwardlist.ops] and 23.2.3.6 [forwardlist.spec]
+Just betwen 23.3.3.5 [forwardlist.ops] and 23.3.3.6 [forwardlist.spec]
 add a new
 section "forwardlist comparison operators" [forwardlist.compare] (and
 also add the
-new section number to 23.2.3 [forwardlist]/2 in front of "Comparison operators"):
+new section number to 23.3.3 [forwardlist]/2 in front of "Comparison operators"):
 
      
 
      
 forwardlist comparison operators [forwardlist.compare]
@@ -17922,6 +13975,71 @@ bool operator!=(const forward_list<T,Allocator>& x, const forward_list
    + + +
    + +

    +Option (C): +

    +
    +
      +
    • +

      +Change Table 91 - Container Requirements in 23.2.1 [container.requirements.general] +(N2798) like so: +

      + +
        +
      1. +

        +Change the text in the Operational Semantics column in + the row for a == b as follows: +

        +
        +== is an equivalence relation. + distance(a.begin(), a.end()) + a.size() == + distance(b.begin(), b.end()) b.size() && + equal(a.begin(), a.end(), b.begin()) +
        +
        2. + +
      2. +

        +Change the text in the Operational Semantics column in + the row for a.max_size() as follows: +

        +
        +distance(a.begin(), a.end()) + a.size() of the largest possible container +
        +
        3. + +
      3. +

        +Change the text in the Operational Semantics column in + the row for a.empty() as follows: +

        +
        +a.begin() == a.end() + a.size() == 0 +
        +
        4. + +
      4. +

        +In addition, for consistency, change the text in the + Operational Semantics column in the row for a.size() + as follows: +

        +
        +distance(a.begin(), a.end()) + a.end() - a.begin() +
        +
        5. +
      +
    @@ -17931,12 +14049,14 @@ bool operator!=(const forward_list<T,Allocator>& x, const forward_list

    862. Impossible complexity for 'includes'

    -

    Section: 25.3.5.1 [includes] Status: New - Submitter: Alisdair Meredith Date: 2008-07-02

    -

    View all issues with New status.

    +

    Section: 25.5.5.1 [includes] Status: Tentatively NAD Editorial + Submitter: Alisdair Meredith Opened: 2008-07-02 Last modified: 2009-05-23

    +

    View other active issues in [includes].

    +

    View all other issues in [includes].

    +

    View all issues with Tentatively NAD Editorial status.

    Discussion:

    -In 25.3.5.1 [includes] the complexity is "at most -1 comparisons" if passed +In 25.5.5.1 [includes] the complexity is "at most -1 comparisons" if passed two empty ranges. I don't know how to perform a negative number of comparisions!

    @@ -17953,9 +14073,50 @@ This same issue also applies to:
  • merge
    • +

    [ +2009-03-30 Beman adds: +]

    + + +
    +Suggest NAD. The complexity of empty ranges is -1 in other places in the +standard. See 25.5.4 [alg.merge] merge and +inplace_merge, and forward_list merge, for example. +The time and effort to find and fix all places in the standard where +empty range[s] result in negative complexity isn't worth the very +limited benefit. +
    + +

    [ +2009-05-09 Alisdair adds: +]

    + + +
    +

    +I'm not happy with NAD if we can find a simple solution. +

    +

    +How about adding a rider somewhere in clause 17 suggesting that complexities +that specify a negative number of operations are treated as specifying zero +operations? That should generically solve the issue without looking for +further cases. +

    +
    + +

    [ +Batavia (2009-05): +]

    + +
    +Pete to provide "straightforward" wording. +Move to NAD Editorial. +
    +

    Proposed resolution:

    +Recommend NAD.

    @@ -17964,10 +14125,10 @@ This same issue also applies to:

    863. What is the state of a stream after close() succeeds

    -

    Section: 27.8.1 [fstreams] Status: New - Submitter: Steve Clamage Date: 2008-07-08

    +

    Section: 27.9.1 [fstreams] Status: Tentatively NAD + Submitter: Steve Clamage Opened: 2008-07-08 Last modified: 2009-05-23

    View all other issues in [fstreams].

    -

    View all issues with New status.

    +

    View all issues with Tentatively NAD status.

    Discussion:

    Suppose writing to an [o]fstream fails and you later close the stream. @@ -17984,105 +14145,41 @@ fail), and fclose succeeds. The close() function reports succe what is the state of the stream?

    - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    864. Defect in atomic wording

    -

    Section: 29.4 [atomics.types.operations] Status: New - Submitter: Anthony Williams Date: 2008-07-10

    -

    View all other issues in [atomics.types.operations].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -There's an error in 29.4 [atomics.types.operations]/p9: -

    +

    [ +Batavia (2009-05): +]

    -
    -
    C atomic_load(const volatile A * object);
-C atomic_load_explicit(const volatile A * object, memory_order);
-C A ::load(memory_order order = memory_order_seq_cst) const volatile;
-

    -Requires: The order argument shall not be memory_order_acquire nor -memory_order_acq_rel. +Tom's impression is that the issue is about the failbit, etc.

    -
    -
    -

    -I believe that this should state +Bill responds that the stream is now closed, +and any status bits remain unchanged.

    -
    -shall not be memory_order_release. -
    -

    -There's also an error in 29.4 [atomics.types.operations]/p17: +See the description of close() in 27.9.1.17 [fstream.members].

    - -
    -... When only one memory_order argument is supplied, the value of success -is order, and -the value of failure is order except that a value of -memory_order_acq_rel shall be replaced by the value -memory_order_require ... -

    -I believe this should state +We prefer not to add wording to say that nothing changes. +Move to NAD.

    -
    -shall be replaced by the value memory_order_acquire ...

    Proposed resolution:

    -Change 29.4 [atomics.types.operations]/p9:

    -
    -
    C atomic_load(const volatile A * object);
-C atomic_load_explicit(const volatile A * object, memory_order);
-C A ::load(memory_order order = memory_order_seq_cst) const volatile;
-
    -
    -

    -Requires: The order argument shall not be memory_order_acquire -memory_order_release nor memory_order_acq_rel. -

    -
    -
    - -

    -Change 29.4 [atomics.types.operations]/p17: -

    - -
    -... When only one memory_order argument is supplied, the value of success -is order, and -the value of failure is order except that a value of -memory_order_acq_rel shall be replaced by the value -memory_order_require memory_order_acquire ... -
    - -

    865. More algorithms that throw away information

    -

    Section: 25.2.6 [alg.fill], 25.2.7 [alg.generate] Status: New - Submitter: Daniel Krügler Date: 2008-07-13

    -

    View all issues with New status.

    +

    Section: 25.4.6 [alg.fill], 25.4.7 [alg.generate] Status: Open + Submitter: Daniel Krügler Opened: 2008-07-13 Last modified: 2009-05-23

    +

    View all issues with Open status.

    Discussion:

    In regard to library defect 488 I found some more algorithms which @@ -18103,44 +14200,75 @@ void generate_n(OutputIterator first, Size n, Generator gen);

    In both cases the minimum requirements on the iterator are OutputIterator, which means according to the requirements of -24.1.2 [output.iterators]/2 that only single-pass iterations are guaranteed. +24.2.3 [output.iterators]/2 that only single-pass iterations are guaranteed. So, if users of fill_n and generate_n have *only* an OutputIterator available, they have no chance to continue pushing further values into it, which seems to be a severe limitation to me.

    +

    [ +Post Summit Daniel "conceptualized" the wording. +]

    + + +

    [ +Batavia (2009-05): +]

    + +
    +

    +Alisdair likes the idea, but has concerns about the specific wording +about the returns clauses. +

    +

    +Alan notes this is a feature request. +

    +

    +Bill notes we have made similar changes to other algorithms. +

    +

    +Move to Open. +

    +
    +

    Proposed resolution:

    1. Replace the current declaration of fill_n in 25 [algorithms]/2, header -<algorithm> synopsis and in 25.2.6 [alg.fill] by +<algorithm> synopsis and in 25.4.6 [alg.fill] by

      -
      template<class OutputIterator, class Size, class T>
-void OutputIterator fill_n(OutputIterator first, Size n, const T& value);
+
      template<class Iter, IntegralLike Size, class T>
+  requires OutputIterator<Iter, const T&>
+  voidIter fill_n(Iter first, Size n, const T& value);
 
      
+
 
      
-Just after the effects clause p.2 add a new returns clause saying:
+Just after the effects clause p.1 add a new returns clause saying:
 
      
 
      
-Returns: first + n for fill_n.
+Returns: For fill_n and n > Size(0), returns first + n. Otherwise
+returns first for fill_n.

    2. Replace the current declaration of generate_n in 25 [algorithms]/2, header -<algorithm> synopsis and in 25.2.7 [alg.generate] by +<algorithm> synopsis and in 25.4.7 [alg.generate] by

      -
      template<class OutputIterator, class Size, class Generator>
-void OutputIterator generate_n(OutputIterator first, Size n, Generator gen);
+
      template<class Iter, IntegralLike Size, Callable Generator>
+  requires OutputIterator<Iter, Generator::result_type>
+        && CopyConstructible<Generator>
+  voidIter generate_n(Iter first, Size n, Generator gen);
 
      
 
      
 Just after the effects clause p.1 add a new returns clause saying:
 
      
 
      
-Returns: first + n for generate_n.
+Returns: For generate_n and n > Size(0), returns first + n.
+Otherwise returns first for generate_n.
    @@ -18149,85 +14277,16 @@ Just after the effects clause p.1 add a new returns clause saying: -
    -

    866. Qualification of placement new-expressions

    -

    Section: 20.7.10 [specialized.algorithms], 20.7.12.2.6 [util.smartptr.shared.create] Status: New - Submitter: Alberto Ganesh Barbati Date: 2008-07-14

    -

    View all issues with New status.

    -

    Discussion:

    -

    -LWG issue 402 replaced "new" with "::new" in the placement -new-expression in 20.7.5.1 [allocator.members]. I believe the rationale -given in 402 applies also to the following other contexts: -

    -
      -
    • -

      -in 20.7.10 [specialized.algorithms], all four algorithms unitialized_copy, -unitialized_copy_n, unitialized_fill and unitialized_fill_n use -the unqualified placement new-expression in some variation of the form: -

      -
      new  (static_cast<void*>(&*result)) typename  iterator_traits<ForwardIterator>::value_type(*first);
-
      -
      • -
    • -

      -in 20.7.12.2.6 [util.smartptr.shared.create] there is a reference to the unqualified placement new-expression: -

      -
      new  (pv)  T(std::forward<Args>(args)...),
-
      -
      • -
    -

    -I suggest to add qualification in all those places. As far as I know, -these are all the remaining places in the whole library that explicitly -use a placement new-expression. Should other uses come out, they should -be qualified as well. -

    -

    -As an aside, a qualified placement new-expression does not need -additional requirements to be compiled in a constrained context. By -adding qualification, the HasPlacementNew concept introduced recently in -N2677 (Foundational Concepts) -would no longer be needed by library and -should therefore be removed. -

    - - -

    Proposed resolution:

    -

    -Replace "new" with "::new" in: -

    -
      -
    • -20.7.10.1 [uninitialized.copy], paragraphs 1 and 3 -
      • -
    • -20.7.10.2 [uninitialized.fill] paragraph 1 -
      • -
    • -20.7.10.3 [uninitialized.fill.n] paragraph 1 -
      • -
    • -20.7.12.2.6 [util.smartptr.shared.create] once in paragraph 1 and twice in paragraph 2. -
      • -
    - - - - - -

    867. Valarray and value-initialization

    -

    Section: 26.5.2.1 [valarray.cons] Status: New - Submitter: Alberto Ganesh Barbati Date: 2008-07-20

    +

    Section: 26.6.2.1 [valarray.cons] Status: Tentatively NAD Editorial + Submitter: Alberto Ganesh Barbati Opened: 2008-07-20 Last modified: 2009-05-23

    View other active issues in [valarray.cons].

    View all other issues in [valarray.cons].

    -

    View all issues with New status.

    +

    View all issues with Tentatively NAD Editorial status.

    Discussion:

    -From 26.5.2.1 [valarray.cons], paragraph 2: +From 26.6.2.1 [valarray.cons], paragraph 2: 

    explicit  valarray(size_t);
@@ -18260,10 +14319,19 @@ That reference should also be replaced. (The normative wording in paragraph 8 re
 and so it doesn't need changes).
 
    
 
+
    [
+Batavia (2009-05):
+]
    
+
+
    
+We agree with the proposed resolution.
+Move to NAD Editorial.
+
    
+
 
 
    Proposed resolution:
    
 
    
-Change 26.5.2.1 [valarray.cons], paragraph 2:
+Change 26.6.2.1 [valarray.cons], paragraph 2:
 
    
 
 
    
@@ -18277,7 +14345,7 @@ of the array are constructed using the default constructor for the instanti
 
    
 
 
    
-Change 26.5.2.7 [valarray.members], paragraph 9:
+Change 26.6.2.7 [valarray.members], paragraph 9:
 
    
 
 
    
@@ -18294,11 +14362,11 @@ the third element of the result will be assigned the value of the first element
 
 
    
 
    868. default construction and value-initialization
    
-
    Section: 23 [containers] Status: New
- Submitter: Alberto Ganesh Barbati Date: 2008-07-22
    
+
    Section: 23 [containers] Status: Open
+ Submitter: Alberto Ganesh Barbati Opened: 2008-07-22  Last modified: 2008-09-22
    
 
    View other active issues in [containers].
    
 
    View all other issues in [containers].
    
-
    View all issues with New status.
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
 The term "default constructed" is often used in wording that predates
@@ -18311,13 +14379,29 @@ non-controversial changes in the attempt of being approved more quickly.
 A few other occurrences (for example in std::tuple,
 std::reverse_iterator and std::move_iterator) are left to separate
 issues. For std::reverse_iterator, see also issue 408. This issue is
-related with issue 724.
+related with issue 724.
 
    
 
+
    [
+San Francisco:
+]
    
+
+
+
    
+
    
+The list provided in the proposed resolution is not complete. James
+Dennett will review the library and provide a complete list and will
+double-check the vocabulary.
+
    
+
    
+This issue relates to Issue 886 tuple construction
+
    
+
    
+
 
 
    Proposed resolution:
    
 
    
-Change 20.1.1 [utility.arg.requirements], paragraph 2:
+Change X [utility.arg.requirements], paragraph 2:
 
    
 
 
    
@@ -18334,14 +14418,14 @@ In all the following paragraphs in clause 23 [containers], replace "default cons
 
    
 
 
      
-
    • 23.2.2.1 [deque.cons] para 2
      • 
-
    • 23.2.2.2 [deque.capacity] para 1
      • 
-
    • 23.2.3.1 [forwardlist.cons] para 3
      • 
-
    • 23.2.3.4 [forwardlist.modifiers] para 21
      • 
-
    • 23.2.4.1 [list.cons] para 3
      • 
-
    • 23.2.4.2 [list.capacity] para 1
      • 
-
    • 23.2.6.1 [vector.cons] para 3
      • 
-
    • 23.2.6.2 [vector.capacity] para 10
      • 
+
    • 23.3.2.1 [deque.cons] para 2
      • 
+
    • 23.3.2.2 [deque.capacity] para 1
      • 
+
    • 23.3.3.1 [forwardlist.cons] para 3
      • 
+
    • 23.3.3.4 [forwardlist.modifiers] para 21
      • 
+
    • 23.3.4.1 [list.cons] para 3
      • 
+
    • 23.3.4.2 [list.capacity] para 1
      • 
+
    • 23.3.6.1 [vector.cons] para 3
      • 
+
    • 23.3.6.2 [vector.capacity] para 10
      • 
 
    
 
 
@@ -18350,11 +14434,11 @@ In all the following paragraphs in clause 23 [containers], replace "default cons
 
 
    
 
    869. Bucket (local) iterators and iterating past end
    
-
    Section: 23.1.5 [unord.req] Status: New
- Submitter: Sohail Somani Date: 2008-07-22
    
+
    Section: 23.2.5 [unord.req] Status: Tentatively Ready
+ Submitter: Sohail Somani Opened: 2008-07-22  Last modified: 2009-03-09
    
 
    View other active issues in [unord.req].
    
 
    View all other issues in [unord.req].
    
-
    View all issues with New status.
    
+
    View all issues with Tentatively Ready status.
    
 
    Discussion:
    
 
    
 Is there any language in the current draft specifying the behaviour of the following snippet?
@@ -18372,10 +14456,30 @@ I don't think there is anything about s.end(n) being considered an
 iterator for the past-the-end value though (I think) it should be.
 
    
 
+
    [
+San Francisco:
+]
    
+
+
+
    
+We believe that this is not a substantive change, but the proposed
+change to the wording is clearer than what we have now.
+
    
+
+
    [
+Post Summit:
+]
    
+
+
+
    
+Recommend Tentatively Ready.
+
    
+
+
 
 
    Proposed resolution:
    
 
    
-Change Table 97 "Unordered associative container requirements" in 23.1.5 [unord.req]:
+Change Table 97 "Unordered associative container requirements" in 23.2.5 [unord.req]:
 
    
 
 
    
@@ -18408,215 +14512,11 @@ If the bucket is empty, then b.begin(n) == b.end(n).
 
 
 
-
    
-
    870. Do unordered containers not support function pointers for predicate/hasher?
    
-
    Section: 23.1.5 [unord.req] Status: New
- Submitter: Daniel Krügler Date: 2008-08-17
    
-
    View other active issues in [unord.req].
    
-
    View all other issues in [unord.req].
    
-
    View all issues with New status.
    
-
    Discussion:
    
-
    
-Good ol' associative containers allow both function pointers and
-function objects as feasible
-comparators, as described in 23.1.4 [associative.reqmts]/2:
-
    
-
-
    
-Each associative container is parameterized on Key and an ordering
-relation Compare that
-induces a strict weak ordering (25.3) on elements of Key. [..]. The
-object of type Compare is
-called the comparison object of a container. This comparison object
-may be a pointer to
-function or an object of a type with an appropriate function call operator.[..]
-
    
-
-
    
-The corresponding wording for unordered containers is not so clear,
-but I read it to disallow
-function pointers for the hasher and I miss a clear statement for the
-equality predicate, see
-23.1.5 [unord.req]/3+4+5:
-
    
-
-
    
-
    
-Each unordered associative container is parameterized by Key, by a
-function object Hash that
-acts as a hash function for values of type Key, and by a binary
-predicate Pred that induces an
-equivalence relation on values of type Key.[..]
-
    
-
    
-A hash function is a function object that takes a single argument of
-type Key and returns a
-value of type std::size_t.
-
    
-
    
-Two values k1 and k2 of type Key are considered equal if the
-container's equality function object
-returns true when passed those values.[..]
-
    
-
    
-
-
    
-and table 97 says in the column "assertion...post-condition" for the
-expression X::hasher:
-
    
-
-
    
-Hash shall be a unary function object type such that the expression
-hf(k) has type std::size_t.
-
    
-
-
    
-Note that 20.6 [function.objects]/1 defines as "Function objects are
-objects with an operator() defined.[..]"
-
    
-
    
-Does this restriction exist by design or is it an oversight? If an
-oversight, I suggest that to apply
-the following
-
    
-
-
-
    Proposed resolution:
    
-
    
-In 23.1.5 [unord.req]/3, just after the second sentence which is written as
-
    
-
-
    
-Additionally, unordered_map and unordered_multimap associate an
-arbitrary mapped type T with the Key.
-
    
-
-
    
-add one further sentence:
-
    
-
-
    
-Both Hash and Pred may be pointers to function or objects of a type
-with an appropriate function call operator.
-
    
-
-
    
-[Note1: Since the detailed requirements for Pred and Hash are given in
-p.4 and p.5, it an alternative resolution
-would be to insert a new paragraph just after p.5, which contains the
-above proposed sentence]
-
    
-
    
-[Note2: I do not propose a change of above quoted element in table 97,
-because the mis-usage of the
-notion of "function object" seems already present in the standard at
-several places, even if it includes
-function pointers, see e.g. 25 [algorithms]/7. The important point is
-that in those places a statement is
-given that the actually used symbol, like "Predicate" applies for
-function pointers as well]
-
    
-
-
-
-
-
-
    
-
    871. Iota's requirements on T are too strong
    
-
    Section: 26.6.5 [numeric.iota] Status: New
- Submitter: Daniel Krügler Date: 2008-08-20
    
-
    View all issues with New status.
    
-
    Discussion:
    
-
    
-According to the recent WP
-N2691,
-26.6.5 [numeric.iota]/1, the requires clause
-of std::iota says:
-
    
-
-
    
-T shall meet the requirements of CopyConstructible and Assignable types, and
-shall be convertible to ForwardIterator's value type.[..]
-
    
-
-
    
-Neither CopyConstructible nor Assignable is needed, instead MoveConstructible
-seems to be the correct choice. I guess the current wording resulted as an
-artifact from comparing it with similar numerical algorithms like accumulate.
-
    
-
-
    
-Note: If this function will be conceptualized, the here proposed
-MoveConstructible
-requirement can be removed, because this is an implied requirement of
-function arguments, see
-N2710/[temp.req.impl]/3, last bullet.
-
    
-
-
-
-
    Proposed resolution:
    
-
-
    
-Change the first sentence of 26.6.5 [numeric.iota]/1:
-
    
-
-
    
-Requires: T shall meet the requirements of
-CopyConstructible and Assignable types,
-
-be MoveConstructible (Table 34)
-
-and shall be
-convertible to ForwardIterator's value type. [..]
-
    
-
-
-
-
-
-
-
    
-
    872. move_iterator::operator[] has wrong return type
    
-
    Section: 24.4.3.3.12 [move.iter.op.index] Status: New
- Submitter: Doug Gregor Date: 2008-08-21
    
-
    View all issues with New status.
    
-
    Discussion:
    
-
    
-move_iterator's operator[] is declared as:
-
    
-
-
    reference operator[](difference_type n) const;
-
    
-
-
    
-This has the same problem that reverse_iterator's operator[] used to
-have: if the underlying iterator's operator[] returns a proxy, the
-implicit conversion to value_type&& could end up referencing a temporary
-that has already been destroyed. This is essentially the same issue that
-we dealt with for reverse_iterator in DR 386.
-
    
-
-
-
    Proposed resolution:
    
-
    
-In 24.4.3.1 [move.iterator] and 24.4.3.3.12 [move.iter.op.index], change the declaration of
-move_iterator's operator[] to:
-
    
-
-
    reference unspecified operator[](difference_type n) const;
-
    
-
-
-
-
-
-
 
    
 
    873. signed integral type and unsigned integral type are not clearly defined
    
-
    Section: 3.9.1 [basic.fundamental] Status: New
- Submitter: Travis Vitek Date: 2008-06-30
    
-
    View all issues with New status.
    
+
    Section: 3.9.1 [basic.fundamental] Status: Open
+ Submitter: Travis Vitek Opened: 2008-06-30  Last modified: 2009-03-21
    
+
    View all issues with Open status.
    
 
    Discussion:
    
     
    
       Neither the term "signed integral type" nor the term "unsigned
@@ -18647,6 +14547,31 @@ In 24.4.3.1 [move.iterator] and 24.4.3.3.12 [move.iter.op.index], change the dec
       satisfy this requirement, namely signed char and
       char (assuming CHAR_MIN < 0).
     
    
+
+
    [
+San Francisco:
+]
    
+
+
+
    
+Plum, Sebor to review.
+
    
+
+
    [
+Post Summit Daniel adds:
+]
    
+
+
+
    
+The proposed resolution needs to be "conceptualized". Currently we have
+in 14.10.4 [concept.support] only concept IntegralType
+for all "integral types", thus indeed the current Container
+concept and Iterator concepts are sufficiently satisfied with "integral
+types". If the changes are applied, we might ask core for concept
+BilateralIntegerType and add proper restrictions to the library
+concepts.
+
    
+
   
 
   
    Proposed resolution:
    
@@ -18683,7 +14608,7 @@ In 24.4.3.1 [move.iterator] and 24.4.3.3.12 [move.iter.op.index], change the dec
       X::difference_type cannot be char or
       wchar_t, but could be one of the signed or unsigned integer
       types as appropriate.
-      20.1.2 [allocator.requirements] table 40...
+      X [allocator.requirements] table 40...
     
    
     
    
       Table 40: Allocator requirements
@@ -18722,7 +14647,7 @@ In 24.4.3.1 [move.iterator] and 24.4.3.3.12 [move.iter.op.index], change the dec
       The proposed change makes it clear that make_signed<T>::type
       must be one of the signed integer types as defined in 3.9.1. Ditto for
       make_unsigned<T>type and unsigned integer types.
-      20.5.6.3 [meta.trans.sign] table 48...
+      20.6.6.3 [meta.trans.sign] table 48...
     
    
     
    
       Table 48: Sign modifications
@@ -18789,12 +14714,12 @@ In 24.4.3.1 [move.iterator] and 24.4.3.3.12 [move.iter.op.index], change the dec
 
     
    
       Note: I believe that the basefield values should probably be
-      prefixed with ios_base:: as they are in 22.2.2.2.2 [facet.num.put.virtuals]
+      prefixed with ios_base:: as they are in 22.4.2.2.2 [facet.num.put.virtuals]
 
       The listed virtuals are all overloaded on signed and unsigned integer
       types, the new wording just maintains consistency.
 
-      22.2.2.1.2 [facet.num.get.virtuals] table 78...
+      22.4.2.1.2 [facet.num.get.virtuals] table 78...
     
    
     
    
       Table 78: Integer Conversions
@@ -18836,7 +14761,7 @@ In 24.4.3.1 [move.iterator] and 24.4.3.3.12 [move.iter.op.index], change the dec
     
     
    
       Rationale is same as above.
-      22.2.2.2.2 [facet.num.put.virtuals] table 80...
+      22.4.2.2.2 [facet.num.put.virtuals] table 80...
     
    
     
    
       Table 80: Integer Conversions
@@ -18881,7 +14806,7 @@ In 24.4.3.1 [move.iterator] and 24.4.3.3.12 [move.iter.op.index], change the dec
 
     
     
    
-      23.1 [container.requirements] table 80...
+      23.2 [container.requirements] table 80...
     
    
     
    
       Table 89: Container requirements
@@ -18917,7 +14842,7 @@ In 24.4.3.1 [move.iterator] and 24.4.3.3.12 [move.iter.op.index], change the dec
     
    
 
     
    
-      24.1 [iterator.requirements] paragraph 1...
+      24.2 [iterator.concepts] paragraph 1...
     
    
     
    
       Iterators are a generalization of pointers that allow a C++ program to
@@ -18945,7 +14870,7 @@ In 24.4.3.1 [move.iterator] and 24.4.3.3.12 [move.iter.op.index], change the dec
       allow instantiations of linear_congruential_engine on
       char, wchar_t, bool, and other types. The
       new wording prohibits this.
-      26.4.3.1 [rand.eng.lcong] paragraph 2...
+      26.5.3.1 [rand.eng.lcong] paragraph 2...
     
    
     
    
       The template parameter UIntType shall denote an
@@ -18962,7 +14887,7 @@ In 24.4.3.1 [move.iterator] and 24.4.3.3.12 [move.iter.op.index], change the dec
     
     
    
       Same rationale as the previous change.
-      26.4.4.4 [rand.adapt.xor] paragraph 6...
+      X [rand.adapt.xor] paragraph 6...
     
    
     
    
       Both Engine1::result_type and
@@ -18974,7 +14899,7 @@ In 24.4.3.1 [move.iterator] and 24.4.3.3.12 [move.iter.op.index], change the dec
     
    
     
     
    
-      26.4.7.1 [rand.util.seedseq] paragraph 7...
+      26.5.7.1 [rand.util.seedseq] paragraph 7...
     
    
     
    
       Requires:RandomAccessIterator shall meet the
@@ -18989,7 +14914,7 @@ In 24.4.3.1 [move.iterator] and 24.4.3.3.12 [move.iter.op.index], change the dec
       representation, but are not signed integer types, would no longer be
       required to use a two's complement representation. This may go against
       the original intent, and should be reviewed.
-      29.4 [atomics.types.operations] paragraph 24...
+      29.6 [atomics.types.operations] paragraph 24...
     
    
     
    
       Remark: For signed integral typessigned integer
@@ -19004,203 +14929,13 @@ In 24.4.3.1 [move.iterator] and 24.4.3.3.12 [move.iter.op.index], change the dec
 
 
 
-
    
-
    874. Missing initializer_list constructor for discrete_distribution
    
-
    Section: 26.4.8.5.1 [rand.dist.samp.discrete] Status: New
- Submitter: Daniel Krügler Date: 2008-08-22
    
-
    View other active issues in [rand.dist.samp.discrete].
    
-
    View all other issues in [rand.dist.samp.discrete].
    
-
    View all issues with New status.
    
-
    Discussion:
    
-
    
-During the Sophia Antipolis meeting it was decided to separate from 793 a
-subrequest that adds initializer list support to
-discrete_distribution, specifically,
-the issue proposed to add a c'tor taking a initializer_list<double>.
-
    
-
-
-
-
    Proposed resolution:
    
-
      
-
    1. 
-
      
-In 26.4.8.5.1 [rand.dist.samp.discrete]/1, class discrete_distribution,
-just before the member declaration
-
      
-
-
      explicit discrete_distribution(const param_type& parm);
-
      
-
-
      
-insert
-
      
-
-
      discrete_distribution(initializer_list<double> wl);
-
      
-
      2. 
-
-
    2. 
-
      
-Between p.4 and p.5 of the same section insert a new
-paragraph as part of the new member description:
-
      
-
-
      discrete_distribution(initializer_list<double> wl);
-
      
-
-
      
-Effects: Same as discrete_distribution(wl.begin(), wl.end()).
-
      
-
      
-
      3. 
-
    
-
-
-
-
-
-
    
-
    875. Missing initializer_list constructor for piecewise_constant_distribution
    
-
    Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: New
- Submitter: Daniel Krügler Date: 2008-08-22
    
-
    View other active issues in [rand.dist.samp.pconst].
    
-
    View all other issues in [rand.dist.samp.pconst].
    
-
    View all issues with New status.
    
-
    Discussion:
    
-
    
-During the Sophia Antipolis meeting it was decided to separate from
-794 a subrequest that adds initializer list support to
-piecewise_constant_distribution, specifically, the issue proposed
-to add a c'tor taking a initializer_list<double> and a Callable to evaluate
-weight values. For consistency with the remainder of this class and
-the remainder of the initializer_list-aware library the author decided to
-change the list argument type to the template parameter RealType
-instead. For the reasoning to use Func instead of Func&& as c'tor
-function argument see issue 793.
-
    
-
-
-
    Proposed resolution:
    
-
      
-
    1. 
-
      
-In 26.4.8.5.2 [rand.dist.samp.pconst]/1, class piecewise_constant_distribution,
-just before the member declaration
-
      
-
-
      explicit piecewise_constant_distribution(const param_type& parm);
-
      
-
-
      
-insert
-
      
-
-
      template<typename Func>
-piecewise_constant_distribution(initializer_list<RealType> bl, Func fw);
-
      
-
      2. 
-
-
    2. 
-
      
-Between p.4 and p.5 of the same section insert a series of
-new paragraphs nominated below as [p5_1], [p5_2], and [p5_3]
-as part of the new member description:
-
      
-
-
      template<typename Func>
-piecewise_constant_distribution(initializer_list<RealType> bl, Func fw);
-
      
-
-
      
-
-
      
-[p5_1] Complexity: Exactly nf = max(bl.size(), 1) - 1 invocations of fw.
-
      
-
-
      
-[p5_2] Requires:
-
      
-
-
        
-
      1. 
-fw shall be callable with one argument of type RealType, and shall
-   return values of a type convertible to double;
-
        2. 
-
      2. 
-The relation 0 < S = w0+. . .+wn-1 shall hold. 
-For all sampled values xk defined below, fw(xk) shall return a weight
-   value wk that is non-negative, non-NaN, and non-infinity;
-
        3. 
-
      3. 
-If nf > 0 let bk = *(bl.begin() + k), k = 0, . . . , bl.size()-1 and the
-following relations shall hold for k = 0, . . . , nf-1: bk < bk+1.
-
        4. 
-
      
-
-
      
-[p5_3] Effects:
-
      
-
-
        
-
      1. 
-
        If nf == 0,
        
-
          
-
        1. 
-lets the sequence w have length n = 1 and consist of the single
-     value w0 = 1, and
-
          2. 
-
        2. 
-lets the sequence b have length n+1 with b0 = 0 and b1 = 1.
-
          3. 
-
        
-
        2. 
-
-
      2. 
-
        Otherwise,
        
-
          
-
        1. 
-sets n = nf, and [bl.begin(), bl.end()) shall form the sequence b of
-length n+1, and
-
          2. 
-
        2. 
-
          lets the sequences w have length n and for each k = 0, . . . ,n-1,
-     calculates:
          
-
          xk = 0.5*(bk+1 + bk)
-wk = fw(xk)
-
          
-
          3. 
-
        
-
        3. 
-
-
      3. 
-
        
-Constructs a piecewise_constant_distribution object with
-the above computed sequence b as the interval boundaries
-and with the probability densities:
-
        
-
        ρk = wk/(S * (bk+1 - bk)) for k = 0, . . . , n-1.
-
        
-
-
        4. 
-
      
-
-
      
-
      
-
      3. 
-
    
-
-
-
-
-
 
    
 
    876. basic_string access operations should give stronger guarantees
    
-
    Section: 21.3 [basic.string] Status: New
- Submitter: Daniel Krügler Date: 2008-08-22
    
+
    Section: 21.4 [basic.string] Status: Open
+ Submitter: Daniel Krügler Opened: 2008-08-22  Last modified: 2008-09-18
    
 
    View other active issues in [basic.string].
    
 
    View all other issues in [basic.string].
    
-
    View all issues with New status.
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
 During the Sophia Antipolis meeting it was decided to split-off some
@@ -19262,13 +14997,40 @@ separated, because this part is theoretically observable in
 specifically designed test programs.
 
    
 
+
    [
+San Francisco:
+]
    
+
+
+
    
+
    
+We oppose part 1 of the issue but hope to address size() in
+issue 877.
+
    
+
    
+We do not support part B. 4 of the issue because of the breaking API change.
+
    
+
    
+We support part A. 2 of the issue.
+
    
+
    
+On support part A. 3 of the issue:
+
    
+
    
+Pete's broader comment: now that we know that basic_string will be a
+block of contiguous memory, we should just rewrite its specification
+with that in mind. The expression of the specification will be simpler
+and probably more correct as a result.
+
    
+
    
+
 
 
    Proposed resolution:
    
 
      
 
    1. 
 
        
 
      1. 
-
        In 21.3.4 [string.capacity], just after p. 1 add a new paragraph:
+
        In 21.4.4 [string.capacity], just after p. 1 add a new paragraph:
 
        
 
        
 Throws: Nothing.
@@ -19277,7 +15039,7 @@ specifically designed test programs.
 
        2. 
 
      2. 
 
        
-In 21.3.5 [string.access] replace p. 1 by the following 4 paragraghs:
+In 21.4.5 [string.access] replace p. 1 by the following 4 paragraghs:
 
        
 
 
        
@@ -19299,7 +15061,7 @@ a reference to a charT() that shall not be modified.
 
        3. 
 
      3. 
 
        
-In 21.3.7.1 [string.accessors] replace the now common returns
+In 21.4.7.1 [string.accessors] replace the now common returns
 clause of c_str() and data() by the following three paragraphs:
 
        
 
        
@@ -19321,7 +15083,7 @@ in [0, size()].
 
          
 
        1. 
 
          
-In 21.3.5 [string.access] replace p.2 and p.3 by:
+In 21.4.5 [string.access] replace p.2 and p.3 by:
 
          
 
          
 
          
@@ -19343,10 +15105,11 @@ In 21.3.5 [string.access] replace p.2 and p.3 by:
 
 
          
 
          877. to throw() or to Throw: Nothing.
          
-
          Section: 17 [library] Status: New
- Submitter: Martin Sebor Date: 2008-08-23
          
+
          Section: 17 [library] Status: Open
+ Submitter: Martin Sebor Opened: 2008-08-23  Last modified: 2008-09-18
          
+
          View other active issues in [library].
          
 
          View all other issues in [library].
          
-
          View all issues with New status.
          
+
          View all issues with Open status.
          
 
          Discussion:
          
        
          
 
@@ -19663,9 +15426,9 @@ specification with a "Throws: Nothing." clause.
 
 
          
 
          878. forward_list preconditions
          
-
          Section: 23.2.3 [forwardlist] Status: New
- Submitter: Martin Sebor Date: 2008-08-23
          
-
          View all issues with New status.
          
+
          Section: 23.3.3 [forwardlist] Status: Tentatively Ready
+ Submitter: Martin Sebor Opened: 2008-08-23  Last modified: 2009-05-10
          
+
          View all issues with Tentatively Ready status.
          
 
          Discussion:
          
        
          
 
@@ -19697,22 +15460,22423 @@ That is, when it's dereferenceable, position must point
 into *this, not just any forward_list object.
 
        
          
-   
-   
          Proposed resolution:
          
+
+
          [
+San Francisco:
+]
          
+
+
+
          
+Robert suggested alternate proposed wording which had large support.
+
          
+
+
          [
+Post Summit:
+]
          
+
+
+
          
+
          
+Walter: "position is before_begin() or a dereferenceable": add "is" after the "or"
+
          
+
          
+With that minor update, Recommend Tentatively Ready.
+
          
+
          
+
+
+
+
          Proposed resolution:
          
        
          
 
-Change the Requires clause as follows:
+Change the Requires clauses
+ [forwardlist] , p21, p24, p26, p29, and,
+23.3.3.5 [forwardlist.ops], p39, p43, p47
+as follows:
 
        
          
        
          
 
-Requires: position is in the range
-[before_begin(), end()) dereferenceable
-or equal to before_begin().
+Requires: position is before_begin() or is a
+dereferenceable
+iterator in the range [begin(), end())
+or equal to before_begin(). ...
 
        
          
    
 
 
 
+
          
+
          879. Atomic load const qualification
          
+
          Section: 29 [atomics] Status: Review
+ Submitter: Alexander Chemeris Opened: 2008-08-24  Last modified: 2009-03-22
          
+
          View other active issues in [atomics].
          
+
          View all other issues in [atomics].
          
+
          View all issues with Review status.
          
+
          Discussion:
          
+
          
+The atomic_address type and atomic<T*> specialization provide atomic
+updates to pointers.  However, the current specification requires
+that the types pointer be to non-const objects.  This restriction
+is unnecessary and unintended.
+
          
+
+
          [
+Summit:
+]
          
+
+
          
+Move to review.  Lawrence will first check with Peter whether the
+current examples are sufficient, or whether they need to be expanded to
+include all cases.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Add const qualification to the pointer values of the atomic_address
+and atomic<T*> specializations.  E.g.
+
          
+
+
          typedef struct atomic_address {
+   void store(const void*, memory_order = memory_order_seq_cst) volatile;
+   void* exchange( const void*, memory_order = memory_order_seq_cst) volatile;
+   bool compare_exchange( const void*&, const void*,
+                          memory_order, memory_order) volatile;
+   bool compare_exchange( const void*&, const void*,
+                          memory_order = memory_order_seq_cst ) volatile;
+   void* operator=(const void*) volatile;
+} atomic_address;
+
+void atomic_store(volatile atomic_address*, const void*);
+void atomic_store_explicit(volatile atomic_address*, const void*,
+                          memory_order);
+void* atomic_exchange(volatile atomic_address*, const void*);
+void* atomic_exchange_explicit(volatile atomic_address*, const void*,
+                              memory_order);
+bool atomic_compare_exchange(volatile atomic_address*,
+                            const void**, const void*);
+bool atomic_compare_exchange_explicit(volatile atomic_address*,
+                                     const void**, const void*,
+                                     memory_order, memory_order);
+
          
+
+
+
+
+
+
          
+
          880. Missing atomic exchange parameter
          
+
          Section: 29 [atomics] Status: Open
+ Submitter: Lawrence Crowl Opened: 2008-08-24  Last modified: 2009-03-22
          
+
          View other active issues in [atomics].
          
+
          View all other issues in [atomics].
          
+
          View all issues with Open status.
          
+
          Duplicate of: 942
          
+
          Discussion:
          
+
          
+The atomic_exchange and atomic_exchange_explicit functions seem to
+be inconsistently missing parameters.
+
          
+
+
          [
+Post Summit:
+]
          
+
+
+
          
+
          
+Lawrence: Need to write up a list for Pete with details.
+
          
+
          
+Detlef: Should not be New, we already talked about in Concurrency group.
+
          
+
          
+Recommend Open.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+Add the appropriate parameters.  For example,
+
          
+
+
          bool atomic_exchange(volatile atomic_bool*, bool);
+bool atomic_exchange_explicit(volatile atomic_bool*, bool, memory_order);
+
          
+
+
+
+
+
+
          
+
          881. shared_ptr conversion issue
          
+
          Section: 20.8.13.2.1 [util.smartptr.shared.const] Status: Open
+ Submitter: Peter Dimov Opened: 2008-08-30  Last modified: 2008-09-18
          
+
          View other active issues in [util.smartptr.shared.const].
          
+
          View all other issues in [util.smartptr.shared.const].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+We've changed shared_ptr<Y> to not convert to shared_ptr<T> when Y*
+doesn't convert to T* by resolving issue 687. This only fixed the
+converting copy constructor though.
+N2351
+later added move support, and
+the converting move constructor is not constrained.
+
          
+
+
          [
+San Francisco:
+]
          
+
+
+
          
+We might be able to move this to NAD, Editorial once shared_ptr is
+conceptualized, but we want to revisit this issue to make sure.
+
          
+
+
+
          Proposed resolution:
          
+
          
+We need to change the Requires clause of the move constructor:
+
          
+
+
          shared_ptr(shared_ptr&& r); 
+template<class Y> shared_ptr(shared_ptr<Y>&& r); 
+
          
+
          
+Requires: For the second constructor Y* shall be
+convertible to T*.
+
+The second constructor shall not participate in overload resolution
+unless Y* is convertible to T*.
+
+
          
+
          
+
+
          
+in order to actually make the example in 687 compile
+(it now resolves to the move constructor).
+
          
+
+
+
+
+
+
+
          
+
          883. swap circular definition
          
+
          Section: 23 [containers] Status: Open
+ Submitter: Alisdair Meredith Opened: 2008-09-10  Last modified: 2009-03-11
          
+
          View other active issues in [containers].
          
+
          View all other issues in [containers].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          
+Note in particular that Table 90 "Container Requirements" gives
+semantics of a.swap(b) as swap(a,b), yet for all
+containers we define swap(a,b) to call a.swap(b) - a
+circular definition.
+
          
+
+
          [
+San Francisco:
+]
          
+
+
+
          
+Robert to propose a resolution along the lines of "Postcondition: "a =
+b, b = a" This will be a little tricky for the hash containers, since
+they don't have operator==.
+
          
+
+
          [
+Post Summit Anthony Williams provided proposed wording.
+]
          
+
+
+
+
+
          Proposed resolution:
          
+
          
+In table 80 in section 23.2.1 [container.requirements.general],
+replace the postcondition of a.swap(b) with the following:
+
          
+
+
          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
          Table 80 -- Container requirements
          ExpressionReturn typeOperational semanticsAssertion/note pre-/post-conidtionComplexity
          ...............
          a.swap(b);void swap(a,b)
+Exchange the contents of a and b as-if
          
+X u=std::move(a);
          
+a=std::move(b);
          
+b=std::move(u);          		(Note A)
          
+
          
+
+
          
+Remove the reference to swap from the paragraph following the table.
+
          
+
+
          
+Notes: the algorithms swap(), equal() and
+lexicographical_compare() are defined in Clause 25. ...
+
          
+
+
+
+
+
+
          
+
          884. shared_ptr swap
          
+
          Section: 20.8.13.2.4 [util.smartptr.shared.mod] Status: Tentatively NAD Editorial
+ Submitter: Jonathan Wakely Opened: 2008-09-15  Last modified: 2009-05-23
          
+
          View all issues with Tentatively NAD Editorial status.
          
+
          Discussion:
          
+
          #include <memory>
+#include <cassert>
+
+struct A { };
+struct B : A { };
+
+int main()
+{
+    std::shared_ptr<A> pa(new A);
+    std::shared_ptr<B> pb(new B);
+    std::swap<A>(pa, pb);  // N.B. no argument deduction
+    assert( pa.get() == pb.get() );
+    return 0;
+}
+
          
+
+
          
+Is this behaviour correct (I believe it is) and if so, is it
+unavoidable, or not worth worrying about?
+
          
+
+
          
+This calls the lvalue/rvalue swap overload for shared_ptr:
+
          
+
+
          template<class T> void swap( shared_ptr<T> & a, shared_ptr<T> && b );
+
          
+
+
          
+silently converting the second argument from shared_ptr<B> to
+shared_ptr<A> and binding the rvalue ref to the produced temporary.
+
          
+
+
          
+This is not, in my opinion, a shared_ptr problem; it is a general issue
+with the rvalue swap overloads. Do we want to prevent this code from
+compiling? If so, how?
+
          
+
+
          
+Perhaps we should limit rvalue args to swap to those types that would
+benefit from the "swap trick".  Or, since we now have shrink_to_fit(), just
+eliminate the rvalue swap overloads altogether.  The original motivation
+was:
+
          
+
+
          vector<A> v = ...;
+...
+swap(v, vector<A>(v));
+
          
+
+N1690.
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to NAD Editorial.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Recommend NAD Editorial, fixed by
+N2844.
+
          
+
+
+
+
+
+
          
+
          885. pair assignment
          
+
          Section: 20.3.3 [pairs] Status: Open
+ Submitter: Alisdair Meredith Opened: 2008-09-15  Last modified: 2009-05-25
          
+
          View other active issues in [pairs].
          
+
          View all other issues in [pairs].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          20.2.3 pairs
+Missing assignemnt operator:
+template<class U , class V>
+  requires CopyAssignable<T1, U> && CopyAssignable<T2, V>
+    pair& operator=(pair<U , V> const & p );
+
          
+
+
          
+Well, that's interesting. This assignment operator isn't in the
+current working paper, either. Perhaps we deemed it acceptable to
+build a temporary of type pair from pair<U, V>, then move-assign
+from that temporary?
+
          
+
          
+It sounds more like an issue waiting to be opened, unless you want to plug
+it now.  As written we risk moving from lvalues.
+
          
+
+
          [
+San Francisco:
+]
          
+
+
+
          
+
          
+Would be NAD if better ctors fixed it.
+
          
+
          
+Related to 811.
+
          
+
          
+
+
          [
+post San Francisco:
+]
          
+
+
+
          
+Possibly NAD Editorial, solved by
+N2770.
+
          
+
+
          [
+2009-05-25 Alisdair adds:
+]
          
+
+
+
          
+Issue 885 was something I reported while reviewing the library concepts
+documents ahead of San Francisco.  The missing operator was added as part of
+the paper adopted at that meeting
+(N2770)
+and I can confirm this operator is
+present in the current working paper.  I recommend NAD.
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
+
+
+
          
+
          886. tuple construction
          
+
          Section: 20.5.2.1 [tuple.cnstr] Status: Open
+ Submitter: Alisdair Meredith Opened: 2008-09-15  Last modified: 2009-05-05
          
+
          View other active issues in [tuple.cnstr].
          
+
          View all other issues in [tuple.cnstr].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+20.5.2.1 [tuple.cnstr]:
+
          
+
          
+Effects: Default initializes each element.
+
          
+
+
          
+Could be clarified to state each "non-trivial" element.  Otherwise
+we have a conflict with Core deinfition of default initialization -
+trivial types do not get initialized (rather than initialization
+having no effect)
+
          
+
+
          
+I'm going to punt on this one, because it's not an issue that's
+related to concepts. I suggest bringing it to Howard's attention on
+the reflector.
+
          
+
+
          [
+San Francisco:
+]
          
+
+
+
          
+
          
+Text in draft doesn't mean anything, changing to "non-trivial" makes it
+meaningful.
+
          
+
          
+We prefer "value initializes". Present implementations use
+value-initialization. Users who don't want value initialization have
+alternatives.
+
          
+
          
+Request resolution text from Alisdair.
+
          
+
+
          
+This issue relates to Issue 868 default construction and value-initialization.
+
          
+
          
+
+
          [
+2009-05-04 Alisdair provided wording and adds:
+]
          
+
+
+
          
+
          
+Note: This IS a change of semantic from TR1, although one the room agreed
+with during the discussion.  To preserve TR1 semantics, this would have been
+worded:
+
          
+
          requires DefaultConstructible<Types>... tuple();
+
          
+
          
+-2-   Effects: Default-initializes each non-trivial element.
+
          
+
          
+
+
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change p2 in Construction 20.5.2.1 [tuple.cnstr]:
+
          
+
+
          requires DefaultConstructible<Types>... tuple();
+
          
+
          
+
          
+-2- Effects: Default Value-initializes each element.
+
          
+
          
+
          
+
+
+
+
+
+
+
          
+
          887. issue with condition::wait_...
          
+
          Section: 30.5.1 [thread.condition.condvar] Status: Open
+ Submitter: Lawrence Crowl Opened: 2008-09-15  Last modified: 2009-03-09
          
+
          View other active issues in [thread.condition.condvar].
          
+
          View all other issues in [thread.condition.condvar].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+The Posix/C++ working group has identified an inconsistency between
+Posix and the C++ working draft in that Posix requires the clock to be
+identified at creation, whereas C++ permits identifying the clock at the
+call to wait.  The latter cannot be implemented with the former.
+
          
+
+
          [
+San Francisco:
+]
          
+
+
+
          
+
          
+Howard recommends NAD with the following explanation:
+
          
+
+
          
+The intent of the current wording is for the condtion_variable::wait_until
+be able to handle user-defined clocks as well as clocks the system knows about.
+This can be done by providing overloads for the known clocks, and another
+overload for unknown clocks which synchs to a known clock before waiting.
+For example:
+
          
+
+
          template <class Duration>
+bool
+condition_variable::wait_until(unique_lock<mutex>& lock,
+                               const chrono::time_point<chrono::system_clock, Duration>& abs_time)
+{
+    using namespace chrono;
+    nanoseconds d = __round_up<nanoseconds>(abs_time.time_since_epoch());
+    __do_timed_wait(lock.mutex()->native_handle(), time_point<system_clock, nanoseconds>(d));
+    return system_clock::now() < abs_time;
+}
+
+template <class Clock, class Duration>
+bool
+condition_variable::wait_until(unique_lock<mutex>& lock,
+                               const chrono::time_point<Clock, Duration>& abs_time)
+{
+    using namespace chrono;
+    typename Clock::time_point  c_entry = Clock::now();
+    system_clock::time_point    s_entry = system_clock::now();
+    nanoseconds dn = __round_up<nanoseconds>(abs_time.time_since_epoch() -
+                                              c_entry.time_since_epoch());
+    __do_timed_wait(lock.mutex()->native_handle(), s_entry + dn);
+    return Clock::now() < abs_time;
+}
+
          
+
+
          
+In the above example, system_clock is the only clock which the underlying
+condition variable knows how to deal with.  One overload just passes that clock
+through.  The second overload (approximately) converts the unknown clock into
+a system_clock  time_point prior to passing it down to the native
+condition variable.
+
          
+
+
          
+On Posix systems vendors are free to add implementation defined constructors which
+take a clock.  That clock can be stored in the condition_variable, and converted
+to (or not as necessary) as shown above.
+
          
+
+
          
+If an implementation defined constructor takes a clock (for example), then part
+of the semantics for that implementation defined ctor might include that a
+wait_until using a clock other than the one constructed with results
+in an error (exceptional condition) instead of a conversion to the stored clock.
+Such a design is up to the vendor as once an implementation defined ctor is used,
+the vendor is free to specifiy the behavior of waits and/or notifies however
+he pleases (when the cv is constructed in an implementation defined manner).
+
          
+
          
+
+
          [
+Post Summit:
+]
          
+
+
+
          
+
          
+"POSIX people will review the proposed NAD resolution at their upcoming NY
+meeting.
+
          
+
+
          
+See the minutes at: http://wiki.dinkumware.com/twiki/bin/view/Posix/POSIX-CppBindingWorkingGroupNewYork2009.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
+
+
+
          
+
          888. this_thread::yield too strong
          
+
          Section: 30.3.2 [thread.thread.this] Status: Tentatively Ready
+ Submitter: Lawrence Crowl Opened: 2008-09-15  Last modified: 2009-03-09
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+I never thought I'd say this, but this_thread::yield seems to be too
+strong in specification.  The issue is that some systems distinguish
+between yielding to another thread in the same process and yielding
+to another process.  Given that the C++ standard only talks about
+a single program, one can infer that the specification allows yielding
+only to another thread within the same program.  Posix has no
+facility for that behavior.  Can you please file an issue to weaken
+the wording.  Perhaps "Offers the operating system the opportunity
+to reschedule."
+
          
+
+
          [
+Post Summit:
+]
          
+
+
+
          
+Recommend move to Tentatively Ready.
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+Change 30.3.2 [thread.thread.this]/3:
+
          
+
+
          
+
          void this_thread::yield();
+
          
+
          
+Effects: Offers the operating system implementation
+the opportunity to reschedule.
+another thread.
+
          
+
          
+
+
+
+
+
+
          
+
          889. thread::id comparisons
          
+
          Section: 30.3.1.1 [thread.thread.id] Status: Open
+ Submitter: Lawrence Crowl Opened: 2008-09-15  Last modified: 2009-05-24
          
+
          View all other issues in [thread.thread.id].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses UK 324
          
+
+
          
+The thread::id type supports the full set of comparison operators.  This
+is substantially more than is required for the associative containers that
+justified them.  Please place an issue against the threads library.
+
          
+
+
          [
+San Francisco:
+]
          
+
+
+
          
+
          
+Would depend on proposed extension to POSIX, or non-standard extension.
+What about hash? POSIX discussing op. POSIX not known to be considering
+support needed for hash, op.
+
          
+
          
+Group expresses support for putting ids in both unordered and ordered containers.
+
          
+
          
+
+
          [
+post San Francisco:
+]
          
+
+
+
          
+
          
+Howard:  It turns out the current working paper
+N2723
+already has hash<thread::id>
+(20.7 [function.objects], 20.7.17 [unord.hash]).  We simply
+overlooked it in the meeting.  It is a good thing we voted in favor of it
+(again). :-)
+
          
+
          
+Recommend NAD.
+
          
+
+
          
+
+
          [
+Post Summit:
+]
          
+
+
+
          
+Recommend to close as NAD. For POSIX, see if we need to add a function to
+convert pthread_t to integer.
+
          
+
+
          [
+Post Summit, Alisdair adds:
+]
          
+
+
+
          
+
          
+The recommendation for LWG-889/UK-324 is NAD, already specified.
+
          
+
          
+It is not clear to me that the specification is complete.
+
          
+
          
+In particular, the synopsis of <functional> in 20.7 [function.objects] does not mention hash< thread::id
+> nor hash< error_code >, although their
+existence is implied by 20.7.17 [unord.hash], p1.
+
          
+
          
+I am fairly uncomfortable putting the declaration for the
+thread_id specialization into <functional> as
+id is a nested class inside std::thread, so it implies
+that <functional> would require the definition of the
+thread class template in order to forward declared
+thread::id and form this specialization.
+
          
+
          
+It seems better to me that the dependency goes the other way around
+(<thread> will more typically make use of
+<functional> than vice-versa) and the
+hash<thread::id> specialization be declared in the
+<thread> header.
+
          
+
          
+I think hash<error_code> could go into either
+<system_error> or <functional> and have no
+immediate preference either way.  However, it should clearly appear in
+the synopsis of one of these two.
+
          
+
          
+Recommend moving 889 back to open, and tying in a reference to UK-324.
+
          
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+Howard observes that thread::id need not be a nested class;
+it could be a typedef for a more visible type.
+
          
+
+
          [
+2009-05-24 Alisdair adds:
+]
          
+
+
          
+I do not believe this is correct.  thread::id is explicitly documents as a
+nested class, rather than as an unspecified typedef analogous to an
+iterator.  If the intent is that this is not implemented as a nested class
+(under the as-if freedoms) then this is a novel form of standardese.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Move to NAD.
+
          
+
+
+
+
+
+
          
+
          890. Improving <system_error> initialization
          
+
          Section: 19.5.1 [syserr.errcat] Status: Tentatively Ready
+ Submitter: Beman Dawes Opened: 2008-09-14  Last modified: 2009-03-09
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+The static const error_category objects generic_category and
+system_category in header <system_error> are currently declared:
+
          
+
+
          const error_category& get_generic_category();
+const error_category& get_system_category();
+
+static const error_category& generic_category = get_generic_category();
+static const error_category& system_category = get_system_category();
+
          
+
+
          
+This formulation has several problems:
+
          
+
+
            
+
          • 
+Implementation details are exposed, since initialization is specified in
+the interface. This over-constrains implementations without offsetting
+user benefits. The form of initialization specified may be less than
+maximally efficient on some platforms.
+
            • 
+
          • 
+Use of the objects is more expensive in terms of number of machine level
+instructions. See Implementation experience below.
+
            • 
+
          • 
+Depending on the compiler, some cost may be incurred by each translation unit
+that includes the header, even if the objects are not used. This is a
+common scenario in user code, since the header is included by other
+standard library headers. It should be mentioned that at least one
+compilers is able to optimize this cost away, however.
+
            • 
+
          
+
+
          
+IO streams uses a somewhat different formulation for iostream_category, but 
+still suffer much the same problems.
+
          
+
+
          
+The original plan was to eliminate these problems by applying the C++0x
+constexpr feature. See LWG issue 832. However, that approach turned out
+to be unimplementable, since it would require a constexpr object of a
+class with virtual functions, and that is not allowed by the core
+language.
+
          
+
+
          
+The proposed resolution was developed as an alternative. It mitigates the above 
+problems by removing initialization from the visible interface, allowing 
+implementations flexibility.
+
          
+
+
          
+Implementation experience:
+
          
+
+
          
+Prototype implementations of the current WP interface and proposed
+resolution interface were tested with recent Codegear, GCC, Intel, and Microsoft 
+compilers on Windows. The code generated by the Microsoft compiler was studied 
+at length; the WP and proposal versions generated very similar code. For both versions 
+the compiler did make use of static
+initialization; apparently the compiler applied an implicit constexpr
+where useful, even in cases where constexpr would not be permitted by
+the language!
+
          
+
+
          
+Acknowledgements:
+
          
+
+
          
+Martin Sebor, Chris Kohlhoff, and John Lakos provided useful ideas and comments on initialization issues.
+
          
+
+
          [
+San Francisco:
+]
          
+
+
+
          
+
          
+Martin: prefers not to create more file-scope static objects, and would
+like to see get_* functions instead.
+
          
+
          
+
+
+
          [Pre-Summit:]
          
+
+
          
+
+
+
          
+Beman: The proposed resolution has been reworked to remove the file-scope 
+static objects, per Martin's suggestions. The get_ prefix has been 
+eliminated from the function names as no longer necessary and to conform with 
+standard library naming practice.
+
          
+
+
          
+
+
          [
+Post Summit:
+]
          
+
+
+
          
+Agreement that this is wise and essential, text provided works and has
+been implemented. Seems to be widespread consensus. Move to Tentative Ready.
+
          
+
+
+
+
          Proposed resolution:
          
+
+
          Change 17.6.4.12 [value.error.codes] Value of error codes as indicated:
          
+
          
+ 
          Certain functions in the C++ standard library report errors via a 
+ std::error_code (19.4.2.2) object. That object's category() member shall 
+ return a reference to std::system_category() for errors originating from the 
+ operating system, or a reference to an implementation-defined error_category 
+ object for errors originating elsewhere. The implementation shall define the 
+ possible values of value() for each of these error categories. [Example: For 
+ operating systems that are based on POSIX, implementations are encouraged to 
+ define the std::system_category() values as identical to the POSIX errno values, 
+ with additional values as defined by the operating system's documentation. 
+ Implementations for operating systems that are not based on POSIX are 
+ encouraged to define values identical to the operating system's values. For 
+ errors that do not originate from the operating system, the implementation may 
+ provide enums for the associated values --end example]
          
+
          
+
+
          
+Change 19.5.1.1 [syserr.errcat.overview] Class error_category overview
+error_category synopsis as indicated:
+
          
+
+
          
+
          const error_category& get_generic_category();
+const error_category& get_system_category();
+
+static storage-class-specifier const error_category& generic_category = get_generic_category();
+static storage-class-specifier const error_category& system_category = get_system_category();
+
          
+
          
+
+
          
+Change 19.5.1.5 [syserr.errcat.objects] Error category objects as indicated:
+
          
+
+
          
+
          const error_category& get_generic_category();
+
          
+
+
          
+
+
          
+Returns: A reference to an object of a type derived from class error_category.
+
          
+
+
          
+Remarks: The object's default_error_condition and equivalent virtual
+functions shall behave as specified for the class error_category. The
+object's name virtual function shall return a pointer to the string
+"GENERIC".
+
          
+
          
+
+
          const error_category& get_system_category();
+
          
+
+
          
+
          
+Returns: A reference to an object of a type derived from class error_category.
+
          
+
+
          
+Remarks: The object's equivalent virtual functions shall behave as
+specified for class error_category. The object's name virtual function
+shall return a pointer to the string "system". The object's
+default_error_condition virtual function shall behave as follows:
+
          
+
          
+If the argument ev corresponds to a POSIX errno value posv, the function
+shall return error_condition(posv, generic_category()). Otherwise, the
+function shall return error_condition(ev, system_category()). What
+constitutes correspondence for any given operating system is
+unspecified. [Note: The number of potential system error codes is large
+and unbounded, and some may not correspond to any POSIX errno value.
+Thus implementations are given latitude in determining correspondence.
+-- end note]
+
          
+
          
+
+
          
+
+
          Change 19.5.2.3 [syserr.errcode.constructors] Class error_code constructors 
+as indicated:
          
+
          
+ 
          error_code();
          
+ 
          
+ 
          Effects: Constructs an object of type error_code.
          
+ 
          Postconditions: val_ == 0 and cat_ == &system_category().
          
+ 
          
+
          
+
          Change 19.5.2.4 [syserr.errcode.modifiers] Class error_code modifiers as 
+indicated:
          
+
          
+ 
          void clear();
          
+ 
          
+ 
          Postconditions: value() == 0 and category() == 
+ system_category().
          
+ 
          
+
          
+
          Change 19.5.2.6 [syserr.errcode.nonmembers] Class error_code non-member 
+functions as indicated:
          
+
          
+ 
          error_code make_error_code(errc e);
          
+ 
          
+ 
          Returns: error_code(static_cast<int>(e), generic_category()).
          
+ 
          
+
          
+
          Change 19.5.3.3 [syserr.errcondition.constructors] Class error_condition 
+constructors as indicated:
          
+
          
+ 
          error_condition();
          
+ 
          
+ 
          Effects: Constructs an object of type error_condition.
          
+ 
          Postconditions: val_ == 0 and cat_ == &generic_category().
          
+ 
          
+
          
+
          Change 19.5.3.4 [syserr.errcondition.modifiers] Class error_condition 
+modifiers as indicated:
          
+
          
+ 
          void clear();
          
+ 
          
+ 
          Postconditions: value() == 0 and category() == 
+ generic_category().
          
+ 
          
+
          
+
          Change 19.5.3.6 [syserr.errcondition.nonmembers] Class error_condition 
+non-member functions as indicated:
          
+
          
+ 
          error_condition make_error_condition(errc e);
          
+ 
          
+ 
          Returns: error_condition(static_cast<int>(e), generic_category()).
          
+ 
          
+
          
+ 
          Change 27.5 [iostreams.base] Iostreams base classes, Header <ios> 
+ synopsis as indicated:
          
+
          
+ 
          concept_map ErrorCodeEnum<io_errc> { };
+error_code make_error_code(io_errc e);
+error_condition make_error_condition(io_errc e);
+storage-class-specifier const error_category& iostream_category();
          
+
          
+
          Change 27.5.2.1.1 [ios::failure] Class ios_base::failure, paragraph 2 as 
+indicated:
          
+
          
+
          When throwing ios_base::failure exceptions, implementations should provide 
+values of ec that identify the specific reason for the failure. [ Note: Errors 
+arising from the operating system would typically be reported as 
+system_category() errors with an error value of the 
+error number reported by the operating system. Errors arising from within the 
+stream library would typically be reported as error_code(io_errc::stream, 
+iostream_category()). --end note ]
          
+
          
+
          Change 27.5.5.5 [error.reporting] Error reporting as indicated:
          
+
          
+ 
          error_code make_error_code(io_errc e);
          
+ 
          
+ 
          Returns: error_code(static_cast<int>(e), iostream_category()).
          
+ 
          
+ 
          error_condition make_error_condition(io_errc e);
          
+ 
          
+ 
          Returns: error_condition(static_cast<int>(e), 
+ iostream_category()).
          
+ 
          
+ 
          storage-class-specifier const error_category& iostream_category();
          
+ 
          
+ 
          The implementation shall initialize iostream_category. Its storage-class-specifier 
+ may be static or extern. It is unspecified whether initialization is static 
+ or dynamic (3.6.2). If initialization is dynamic, it shall occur before 
+ completion of the dynamic initialization of the first translation unit 
+ dynamically initialized that includes header <system_error>.
          
+
          
+Returns: A reference to an object of a type derived from class error_category.
+
          
+
          Remarks: The object's default_error_condition and equivalent virtual functions shall 
+behave as specified for the class error_category. The object's name virtual 
+function shall return a pointer to the string "iostream".
          
+ 
          
+
          
+
+
+
+
+
+
+
+
          
+
          891. std::thread, std::call_once issue
          
+
          Section: 30.3.1.2 [thread.thread.constr], 30.4.5.2 [thread.once.callonce] Status: Open
+ Submitter: Peter Dimov Opened: 2008-09-15  Last modified: 2009-03-22
          
+
          View other active issues in [thread.thread.constr].
          
+
          View all other issues in [thread.thread.constr].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+I notice that the vararg overloads of std::thread and std::call_once
+(N2723 30.3.1.2 [thread.thread.constr] and 30.4.5.2 [thread.once.callonce]) are no longer specified in terms of
+std::bind; instead, some of the std::bind wording has been inlined into
+the specification.
+
          
+
          
+There are two problems with this.
+
          
+
          
+First, the specification (and implementation) in terms of std::bind allows, for example:
+
          
+
+
          std::thread th( f, 1, std::bind( g ) );
+
          
+
+
          
+which executes f( 1, g() ) in a thread. This can be useful. The
+"inlined" formulation changes it to execute f( 1, bind(g) ) in a thread.
+
          
+
          
+Second, assuming that we don't want the above, the specification has copied the wording
+
          
+
+
          
+INVOKE(func, w1, w2, ..., wN) (20.6.2) shall be a valid
+expression for some values w1, w2, ..., wN
+
          
+
+
          
+but this is not needed since we know that our argument list is args; it should simply be
+
          
+
+
          
+INVOKE(func, args...) (20.6.2) shall be a valid expression
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Move to open.
+
          
+
+
          [
+Post Summit Anthony provided proposed wording.
+]
          
+
+
+
+
          Proposed resolution:
          
+
          
+Change paragraph 4 of 30.3.1.2 [thread.thread.constr] to:
+
          
+
+
          
+
          template <class F> explicit thread(F f);
+template <class F, class ...Args> thread(F&& f, Args&&... args);
+
          
+
          
+-4- Requires: F and each Ti in Args
+shall be CopyConstructible if an lvalue and otherwise
+MoveConstructible. INVOKE(f, w1, w2, ..., wN args...)
+(20.6.2) shall be a valid expression for some values w1, w2, ...,
+wN, where N == sizeof...(Args).
+
          
+
          
+
+
          
+Change paragraph 1 of 30.4.5.2 [thread.once.callonce] to:
+
          
+
+
          template<class Callable, class ...Args> 
+  void call_once(once_flag& flag, Callable func, Args&&... args);
+
          
+
          
+-1- Requires: The template parameters Callable> and each
+Ti in Args shall be CopyConstructible if an
+lvalue and otherwise MoveConstructible. INVOKE(func,
+w1, w2, ..., wN args...) (20.6.2) shall be a
+valid expression for some values w1, w2, ..., wN, where
+N == sizeof...(Args).
+
          
+
          
+
+
+
+
+
+
          
+
          893. std::mutex issue
          
+
          Section: 30.4.1.1 [thread.mutex.class] Status: Open
+ Submitter: Peter Dimov Opened: 2008-09-15  Last modified: 2009-03-22
          
+
          View other active issues in [thread.mutex.class].
          
+
          View all other issues in [thread.mutex.class].
          
+
          View all issues with Open status.
          
+
          Duplicate of: 905
          
+
          Discussion:
          
+
          
+30.4.1.1 [thread.mutex.class]/27 (in
+N2723)
+says that the behavior is undefined if:
+
          
+
            
+
          • a thread that owns a mutex object calls lock() or
+try_lock() on that object
            • 
+
          
+
          
+I don't believe that this is right. Calling lock() or try_lock() on a
+locked mutex is well defined in the general case. try_lock() is required
+to fail and return false. lock() is required to either throw an
+exception (and is allowed to do so if it detects deadlock) or to block
+until the mutex is free. These general requirements apply regardless of
+the current owner of the mutex; they should apply even if it's owned by
+the current thread.
+
          
+
          
+Making double lock() undefined behavior probably can be justified (even
+though I'd still disagree with the justification), but try_lock() on a
+locked mutex must fail.
+
          
+
+
          [
+Summit:
+]
          
+
+
          
+
          
+Move to open. Proposed resolution:
+
          
+
            
+
          • 
+In 30.4.1 [thread.mutex.requirements] paragraph 12, change the error
+condition for resource_deadlock_would_occur to: "if the implementation
+detects that a deadlock would occur"
+
            • 
+
          • 
+Strike 30.4.1.1 [thread.mutex.class] paragraph 3 bullet 2 "a thread that owns a mutex object
+calls lock() or try_lock() on that object, or"
+
            • 
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+In 30.4.1 [thread.mutex.requirements] paragraph 12 change:
+
          
+
+
          
+
            
+
          • ...
            • 
+
          • 
+resource_deadlock_would_occur -- if the current thread already owns the mutex and is able 
+to detect it implementation detects that a deadlock would occur.
+
            • 
+
          • ...
            • 
+
          
+
          
+
+
          
+Strike 30.4.1.1 [thread.mutex.class] paragraph 3 bullet 2:
+
          
+
          
+
          
+-3- The behavior of a program is undefined if:
+
          
+
            
+
          • ...
            • 
+
          • 
+a thread that owns a mutex object calls lock() or try_lock() on that object, or
+
            • 
+
          • ...
            • 
+
          
+
          
+
+
+
+
+
+
+
+
          
+
          895. "Requires:" on std::string::at et al
          
+
          Section: 17.5.1.4 [structure.specifications] Status: Open
+ Submitter: James Dennett Opened: 2008-09-16  Last modified: 2009-03-11
          
+
          View other active issues in [structure.specifications].
          
+
          View all other issues in [structure.specifications].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+Per discussion, we need an issue open to cover looking at "Requires"
+clauses which are not constraints on user code, such as that on
+std::basic_string::at.
+
          
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
+
+
+
          
+
          896. Library thread safety issue
          
+
          Section: 20.8.13.2 [util.smartptr.shared] Status: Open
+ Submitter: Hans Boehm Opened: 2008-09-16  Last modified: 2008-09-25
          
+
          View other active issues in [util.smartptr.shared].
          
+
          View all other issues in [util.smartptr.shared].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+It is unclear whether shared_ptr is thread-safe in the sense that
+multiple threads may simultaneously copy a shared_ptr.  However this
+is a critical piece of information for the client, and it has significant
+impact on usability for many applications.  (Detlef Vollman thinks it
+is currently clear that it is not thread-safe.  Hans Boehm thinks
+it currently requires thread safety, since the use_count is not an
+explicit field, and constructors and assignment take a const reference
+to an existing shared_ptr.)
+
          
+
+
          
+Pro thread-safety:
+
          
+
          
+Many multi-threaded usages are impossible.  A thread-safe version can
+be used to destroy an object when the last thread drops it, something
+that is often required, and for which we have no other easy mechanism.
+
          
+
          
+Against thread-safety:
+
          
+
          
+The thread-safe version is well-known to be far more expensive, even
+if used by a single thread.  Many applications, including all single-threaded
+ones, do not care.
+
          
+
+
          [
+San Francisco:
+]
          
+
+
+
          
+
          
+Beman: this is a complicated issue, and would like to move this to Open
+and await comment from Peter Dimov; we need very careful and complete
+rationale for any decision we make; let's go slow
+
          
+
          
+Detlef: I think that shared_ptr should not be thread-safe.
+
          
+
          
+Hans: When you create a thread with a lambda, it in some cases makes it
+very difficult for the lambda to reference anything in the heap. It's
+currently ambiguous as to whether you can use a shared_ptr to get at an
+object.
+
          
+
          
+Leave in Open. Detlef will submit an alternative proposed resolution
+that makes shared_ptr explicitly unsafe.
+
          
+
          
+A third option is to support both threadsafe and non-safe share_ptrs,
+and to let the programmer decide which behavior they want.
+
          
+
+
          
+Beman:  Peter, do you support the PR?
+
          
+
+
          
+Peter:
+
          
+
          
+
          
+Yes, I support the proposed resolution, and I certainly oppose any
+attempts to make shared_ptr thread-unsafe.
+
          
+
          
+I'd mildly prefer if
+
          
+
          
+[Note: This is true in spite of that fact that such functions often
+modify use_count() --end note]
+
          
+
          
+is changed to
+
          
+
          
+[Note: This is true in spite of that fact that such functions often
+cause a change in use_count() --end note]
+
          
+
          
+(or something along these lines) to emphasise that use_count() is not,
+conceptually, a variable, but a return value.
+
          
+
          
+
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+Make it explicitly thread-safe, in this weak sense, as I believe was intended:
+
          
+
          
+Insert in 20.8.13.2 [util.smartptr.shared], before p5:
+
          
+
          
+
          
+For purposes of determining the presence of a data race,
+member functions do not modify const shared_ptr and
+const weak_ptr arguments, nor any objects they
+refer to.  [Note: This is true in spite of that fact that such functions often
+cause a change in use_count() --end note]
+
          
+
          
+
          
+On looking at the text, I'm not sure we need a similar disclaimer
+anywhere else, since nothing else has the problem with the modified
+use_count().  I think Howard arrived at a similar conclusion.
+
          
+
+
+
+
+
+
          
+
          897. Forward_list issues... Part 2
          
+
          Section: 23.3.3.4 [forwardlist.modifiers] Status: Review
+ Submitter: Howard Hinnant Opened: 2008-09-22  Last modified: 2009-05-23
          
+
          View all issues with Review status.
          
+
          Discussion:
          
+
          
+This issue was split off from 892 at the request of the LWG.
+
          
+
+
          [
+San Francisco:
+]
          
+
+
+
          
+
          
+This issue is more complicated than it looks.
+
          
+
          
+paragraph 47: replace each (first, last) with (first, last]
+
          
+
          
+add a statement after paragraph 48 that complexity is O(1)
+
          
+
          
+remove the complexity statement from the first overload of splice_after
+
          
+
          
+We may have the same problems with other modifiers, like erase_after.
+Should it require that all iterators in the range (position, last] be
+dereferenceable?
+
          
+
          
+
+
          
+There are actually 3 issues here:
+
          
+
+
            
+
          1. 
+
            
+What value should erase_after return?  With list, code often
+looks like:
+
            
+
            for (auto i = l.begin(); i != l.end();)
+{
+    // inspect *i and decide if you want to erase it
+    // ...
+    if (I want to erase *i)
+        i = l.erase(i);
+    else
+        ++i;
+}
+
            
+
            
+I.e. the iterator returned from erase is useful for setting up the
+logic for operating on the next element.  For forward_list this might
+look something like:
+
            
+
            auto i = fl.before_begin();
+auto ip1 = i;
+for (++ip1; ip1 != fl.end(); ++ip1)
+{
+    // inspect *(i+1) and decide if you want to erase it
+    // ...
+    if (I want to erase *(i+1))
+        i = fl.erase_after(i);
+    else
+        ++i;
+    ip1 = i;
+}
+
            
+
            
+In the above example code, it is convenient if erase_after returns
+the element prior to the erased element (range) instead of the element
+after the erase element (range).
+
            
+
            
+Existing practice:
+
            
+
              
+
            • SGI slist returns an iterator referencing the element after the erased range.
              • 
+
            • CodeWarrior slist returns an iterator referencing the element before the erased range.
              • 
+
            
+
            
+There is not a strong technical argument for either solution over the other.
+
            
+
            2. 
+
+
          2. 
+
            
+With all other containers, operations always work on the range
+[first, last) and/or prior to the given position.
+
            
+
            
+With forward_list, operations sometimes work on the range
+(first, last] and/or after the given position.
+
            
+
            
+This is simply due to the fact that in order to operate on
+*first (with forward_list) one needs access to
+*(first-1).  And that's not practical with
+forward_list.  So the operating range needs to start with (first,
+not [first (as the current working paper says). 
+
            
+
            
+Additionally, if one is interested in  splicing the range (first, last),
+then (with forward_list), one needs practical (constant time) access to
+*(last-1) so that one can set the next field in this node to
+the proper value.  As this is not possible with forward_list, one must
+specify the last element of interest instead of one past the last element of
+interest.  The syntax for doing this is to pass (first, last] instead
+of (first, last).
+
            
+
            
+With erase_after we have a choice of either erasing the range
+(first, last] or (first, last).  Choosing the latter
+enables:
+
            
+
            x.erase_after(pos, x.end());
+
            
+
+
            
+With the former, the above statement is inconvenient or expensive due to the lack
+of constant time access to x.end()-1.  However we could introduce:
+
            
+
+
            iterator erase_to_end(const_iterator position);
+
            
+
+
            
+to compensate.
+
            
+
+
            
+The advantage of the former ((first, last]) for erase_after
+is a consistency with splice_after which uses (first, last]
+as the specified range.  But this either requires the addition of erase_to_end
+or giving up such functionality.
+
            
+
+
            3. 
+
+
          3. 
+As stated in the discussion of 892, and reienforced by point 2 above,
+a splice_after should work on the source range (first, last]
+if the operation is to be Ο(1).  When splicing an entire list x the
+algorithm needs (x.before_begin(), x.end()-1].  Unfortunately x.end()-1
+is not available in constant time unless we specify that it must be.  In order to
+make x.end()-1 available in constant time, the implementation would have
+to dedicate a pointer to it.  I believe the design of
+N2543
+intended a nominal overhead of foward_list of 1 pointer.  Thus splicing
+one entire forward_list into another can not be Ο(1).
+
            4. 
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We agree with the proposed resolution.
+
          
+
          
+Move to Review.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+Wording below assumes issue 878 is accepted, but this issue is
+independent of that issue.
+
          
+
+
          
+Change 23.3.3.4 [forwardlist.modifiers]:
+
          
+
+
          
+
          iterator erase_after(const_iterator position);
+
          
+
          
+
          
+Requires: The iterator following position is dereferenceable.
+
          
+
          
+Effects: Erases the element pointed to by the iterator following position.
+
          
+
          
+Returns: An iterator pointing to the element following the one that was erased, or end() if no such 
+element exists
+An iterator equal to position.
+
          
+
          
+
+
+
          iterator erase_after(const_iterator position, const_iterator last);
+
          
+
          
+
          
+Requires: All iterators in the range
+[(position,last)
+are dereferenceable.
+
          
+
          
+Effects: Erases the elements in the range
+[(position,last).
+
          
+
          
+Returns:  An iterator equal to position last
+
          
+
          
+
          
+
+
          
+Change 23.3.3.5 [forwardlist.ops]:
+
          
+
+
          
+
          void splice_after(const_iterator position, forward_list<T,Allocator>&& x);
+
          
+
          
+
          
+Requires: position is before_begin() or a
+dereferenceable iterator in the range [begin(), end)). &x != this.
+
          
+
          
+Effects: Inserts the contents of x after position, and
+x becomes empty. Pointers and references to 
+the moved elements of x now refer to those same elements but as members of *this.
+Iterators referring to the moved elements will continue to refer to their elements,
+but they now behave as iterators into *this, not into x. 
+
          
+
          
+Throws: Nothing. 
+
          
+
          
+Complexity: Ο(1) Ο(distance(x.begin(), x.end()))
+
          
+
          
+
+
          ...
          
+
+
          void splice_after(const_iterator position, forward_list<T,Allocator>&& x, 
+                  const_iterator first, const_iterator last);
+
          
+
          
+
          
+Requires: position is before_begin() or a
+dereferenceable iterator in the range [begin(), end)).
+(first,last]) is a valid range in
+x, and all iterators in the range
+(first,last]) are dereferenceable.
+position is not an iterator in the range (first,last]).
+
          
+
          
+Effects: Inserts elements in the range (first,last])
+after position and removes the elements from x.
+Pointers and references to the moved elements of x now refer to
+those same elements but as members of *this. Iterators
+referring to the moved elements will continue to refer to their
+elements, but they now behave as iterators into *this, not into
+x.
+
          
+
          
+Complexity: Ο(1).
+
          
+
          
+
+
          
+
+
+
+
+
+
+
          
+
          898. Small contradiction in n2723 to forward to committee
          
+
          Section: 23.3.3.5 [forwardlist.ops] Status: Tentatively Ready
+ Submitter: Arch Robison Opened: 2008-09-08  Last modified: 2009-05-23
          
+
          View other active issues in [forwardlist.ops].
          
+
          View all other issues in [forwardlist.ops].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+I ran across a small contradiction in working draft n2723. 
+
          
+
          
+
          
+23.3.3 [forwardlist]p2: A forward_list satisfies all of the
+requirements of a container (table 90), except that the size() member
+function is not provided.
+
          
+
          
+23.3.3.5 [forwardlist.ops]p57: Complexity: At most size() + x.size() - 1
+comparisons.
+
          
+
          
+
          
+Presumably 23.3.3.5 [forwardlist.ops]p57 needs to be rephrased to not use
+size(), or note that it is used there only for sake of notational convenience. 
+
          
+
+
          [
+2009-03-29 Beman provided proposed wording.
+]
          
+
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We agree with the proposed resolution.
+
          
+
          
+Move to Tentatively Ready.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          Change 23.3.3.5 [forwardlist.ops],
+forward_list operations, paragraph 19, merge complexity as indicated:
+
          
+
          Complexity: At most size() + x.size()
+distance(begin(), end()) + distance(x.begin(), x.end()) - 1
+comparisons.
+
          
+
+
+
+
+
+
          
+
          899. Adjusting shared_ptr for nullptr_t
          
+
          Section: 20.8.13.2.2 [util.smartptr.shared.dest] Status: Tentatively Ready
+ Submitter: Peter Dimov Opened: 2008-09-18  Last modified: 2009-05-23
          
+
          View all other issues in [util.smartptr.shared.dest].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+James Dennett, message c++std-lib-22442:
+
          
+
          
+The wording below addresses one case of this, but opening an
+issue to address the need to sanity check uses of the term "pointer"
+in 20.8.13.2 [util.smartptr.shared] would be a good thing.
+
          
+
          
+There's one more reference, in ~shared_ptr; we can apply your suggested change to it, too. That is:
+
          
+
          
+Change 20.8.13.2.2 [util.smartptr.shared.dest]/1 second bullet from:
+
          
+
          
+Otherwise, if *this owns a pointer p and a deleter d, d(p) is called.
+
          
+
          
+to:
+
          
+
          
+Otherwise, if *this owns an object p and a deleter d, d(p) is called.
+
          
+
+
          [
+Post Summit:
+]
          
+
+
+
          
+Recommend Review.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Peter Dimov notes the analogous change has already been made
+to "the new nullptr_t taking constructors
+in 20.8.13.2.1 [util.smartptr.shared.const] p9-13."
+
          
+
          
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 20.8.13.2.2 [util.smartptr.shared.dest]/1 second bullet:
+
          
+
          
+
            
+
          • ...
            • 
+
          • 
+Otherwise, if *this owns a pointer
+an object p and a
+deleter d, d(p) is called.
+
            • 
+
          
+
          
+
+
+
+
+
+
          
+
          900. stream move-assignment
          
+
          Section: 27.9.1.8 [ifstream.assign] Status: Open
+ Submitter: Niels Dekker Opened: 2008-09-20  Last modified: 2009-05-23
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+It
+appears that we have an issue similar to issue 675 regarding the move-assignment of
+stream types. For example, when assigning to an std::ifstream,
+ifstream1, it seems preferable to close the file originally held by
+ifstream1:
+
          
+
+
          ifstream1 = std::move(ifstream2); 
+
          
+
+
          
+The current Draft
+(N2723)
+specifies that the move-assignment of
+stream types like ifstream has the same effect as a swap:
+
          
+
+
          
+
          
+Assign and swap 27.9.1.8 [ifstream.assign]
+
          
+
          basic_ifstream& operator=(basic_ifstream&& rhs); 
+
          
+
          
+Effects: swap(rhs).
+
          
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Howard agrees with the analysis and the direction proposed.
+
          
+
          
+Move to Open pending specific wording to be supplied by Howard.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
+
+
+
          
+
          901. insert iterators can move from lvalues
          
+
          Section: 24.7.5 [insert.iterator] Status: Tentatively NAD
+ Submitter: Alisdair Meredith Opened: 2008-09-24  Last modified: 2009-05-23
          
+
          View all issues with Tentatively NAD status.
          
+
          Discussion:
          
+
          Addresses UK 282
          
+
+
          
+The requires clause on the const T & overloads in
+back_insert_iterator/front_insert_iterator/insert_iterator mean that the
+assignment operator will implicitly move from lvalues of a move-only type.
+
          
+
          
+Suggested resolutions are:
+
          
+
            
+
          1. 
+Add another overload with a negative constraint on copy-constructible
+and flag it "= delete".
+
            2. 
+
          2. 
+Drop the copy-constructible overload entirely and rely on perfect
+forwarding to catch move issues one level deeper.
+
            3. 
+
          3. 
+This is a fundamental problem in move-syntax that relies on the
+presence of two overloads, and we need to look more deeply into this
+area as a whole - do not solve this issue in isolation.
+
            4. 
+
          
+
+
          [
+Post Summit, Alisdair adds:
+]
          
+
+
+
          
+
          
+Both comment and issue have been resolved by the adoption of
+N2844
+(rvalue references safety fix) at the last meeting.
+
          
+
+
          
+Suggest resolve as NAD Editorial with a reference to the paper.
+
          
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree that this has been resolved in the latest Working Draft.
+Move to NAD.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Recommend NAD, addressed by N2844.
+
          
+
+
+
+
+
+
          
+
          902. Regular is the wrong concept to constrain numeric_limits
          
+
          Section: 18.3.1 [limits] Status: Open
+ Submitter: Alisdair Meredith Opened: 2008-09-24  Last modified: 2009-03-11
          
+
          View all other issues in [limits].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses FR 32 and DE 16
          
+
+
          
+numeric_limits has functions specifically designed to return NaNs, which
+break the model of Regular (via its axioms.)  While floating point types
+will be acceptible in many algorithms taking Regular values, it is not
+appopriate for this specific API and we need a less refined constraint.
+
          
+
+
          FR 32:
          
+
+
          
+The definition of numeric_limits<> as requiring a regular
+type is both conceptually wrong and operationally illogical. As we
+pointed before, this mistake needs to be corrected. For example, the
+template can be left unconstrained. In fact this reflects a much more
+general problem with concept_maps/axioms and their interpretations. It
+appears that the current text heavily leans toward experimental academic
+type theory.
+
          
+
+
          DE 16:
          
+
+
          
+The class template numeric_limits should not specify the Regular concept
+requirement for its template parameter, because it contains functions
+returning NaN values for floating-point types; these values violate the
+semantics of EqualityComparable.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Move to Open.  Alisdair and Gaby will work on a solution, along with the new
+treatment of axioms in clause 14.
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
+
+
+
          
+
          903. back_insert_iterator issue
          
+
          Section: 24.7.1 [back.insert.iterator] Status: Tentatively NAD
+ Submitter: Dave Abrahams Opened: 2008-09-19  Last modified: 2009-05-30
          
+
          View all issues with Tentatively NAD status.
          
+
          Discussion:
          
+
          
+I just noticed this; don't know how far the problem(?) extends or
+whether it's new or existing: back_insert_iterator's operator* is not
+const, so you can't dereference a const one.
+
          
+
+
          [
+Post Summit Daniel adds:
+]
          
+
+
+
          
+
          
+If done, this change should be applied for front_insert_iterator,
+insert_iterator, ostream_iterator, and ostreambuf_iterator as well.
+
          
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Alisdair notes that these all are output iterators.
+Howard points out that ++*i
+would no longer work if we made this change.
+
          
+
          
+Move to NAD.
+
          
+
          
+
+
          [
+2009-05-25 Daniel adds:
+]
          
+
+
+
            
+
          1. 
+If 1009 is accepted, OutputIterator does no longer support post increment.
+
            2. 
+
          2. 
+To support backward compatibility a second overload of operator*
+can be added.
+Note that the HasDereference concept (and the HasDereference part of concept
+Iterator) was specifically refactored to cope with optional const
+qualification and
+to properly reflect the dual nature of built-in operator* as of
+13.5.8 [over.literal]/6.
+
            3. 
+
          
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          904. result_of argument types
          
+
          Section: 20.7.4 [func.ret] Status: Tentatively Ready
+ Submitter: Jonathan Wakely Opened: 2008-09-10  Last modified: 2009-03-09
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+The WP and TR1 have the same text regarding the argument types of a
+result_of expression:
+
          
+
          
+The values ti are lvalues when the corresponding type Ti is a
+reference type, and rvalues otherwise.
+
          
+
          
+I read this to mean that this compiles:
+
          
+
          typedef int (*func)(int&);
+result_of<func(int&&)>::type i = 0;
+
          
+
          
+even though this doesn't:
+
          
+
          int f(int&);
+f( std::move(0) );
+
          
+
          
+Should the text be updated to say "when Ti is an lvalue-reference
+type" or am I missing something?
+
          
+
          
+I later came up with this self-contained example which won't compile,
+but I think it should:
+
          
+
          struct X {
+  void operator()(int&);
+  int operator()(int&&);
+} x;
+
+std::result_of< X(int&&) >::type i = x(std::move(0));
+
          
+
+
          [
+Post Summit:
+]
          
+
+
+
          
+Recommend Tentatively Ready.
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+Change 20.7.4 [func.ret], p1:
+
          
+
+
          
+... The values ti are lvalues 
+when the corresponding type Ti is an lvalue-reference type,
+and rvalues otherwise. 
+
          
+
+
+
+
+
+
          
+
          906. ObjectType is the wrong concept to constrain initializer_list
          
+
          Section: 18.9 [support.initlist] Status: Tentatively Ready
+ Submitter: Daniel Krügler Opened: 2008-09-26  Last modified: 2009-05-23
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+The currently proposed constraint on initializer_list's element type
+E is that is has to meet ObjectType. This is an underspecification,
+because both core language and library part of initializer_list
+make clear, that it references an implicitly allocated array:
+
          
+
          
+8.5.4 [dcl.init.list]/4:
+
          
+
          
+When an initializer list is implicitly converted to a
+std::initializer_list<E>, the object passed is constructed as if the
+implementation allocated an array of N elements of type E, where
+N is the number of elements in the initializer list.[..]
+
          
+
+
          
+18.9 [support.initlist]/2.
+
          
+
+
          
+An object of type initializer_list<E> provides access to an array of
+objects of type const E.[..]
+
          
+
+
          
+Therefore, E needs to fulfill concept ValueType (thus excluding
+abstract class types). This stricter requirement should be added
+to prevent deep instantiation errors known from the bad old times,
+as shown in the following example:
+
          
+
+
          // Header A: (Should concept-check even in stand-alone modus)
+
+template <DefaultConstructible T>
+requires MoveConstructible<T>
+void generate_and_do_3(T a) {
+  std::initializer_list<T> list{T(), std::move(a), T()};
+  ...
+}
+
+void do_more();
+void do_more_or_less();
+
+template <DefaultConstructible T>
+requires MoveConstructible<T>
+void more_generate_3() {
+  do_more();
+  generate_and_do_3(T());
+}
+
+template <DefaultConstructible T>
+requires MoveConstructible<T>
+void something_and_generate_3() {
+  do_more_or_less();
+  more_generate_3();
+}
+
+// Test.cpp
+
+#include "A.h"
+
+class Abstract {
+public:
+  virtual ~Abstract();
+  virtual void foo() = 0; // abstract type
+  Abstract(Abstract&&){} // MoveConstructible
+  Abstract(){} // DefaultConstructible
+};
+
+int main() {
+  // The restricted template *accepts* the argument, but
+  // causes a deep instantiation error in the internal function
+  // generate_and_do_3:
+  something_and_generate_3<Abstract>();
+}
+
          
+
+
          
+The proposed stricter constraint does not minimize the aim to
+support more general containers for which ObjectType would be
+sufficient. If such an extended container (lets assume it's still a
+class template) provides a constructor that accepts an initializer_list
+only this constructor would need to be restricted on ValueType:
+
          
+
+
          template<ObjectType T>
+class ExtContainer {
+public:
+  requires ValueType<T>
+  ExtContainer(std::initializer_list<T>);
+  ...
+};
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+Move to Tentatively Ready.
+
          
+
+
+
+
          Proposed resolution:
          
+
            
+
          1. 
+In 18.9 [support.initlist]/p.1 replace in "header <initializer_list> synopsis"
+the constraint "ObjectType" in the template parameter list by the
+constraint "ValueType".
+
            2. 
+
          
+
+
+
+
+
+
+
          
+
          907. Bitset's immutable element retrieval is inconsistently defined
          
+
          Section: 20.3.6.2 [bitset.members] Status: Tentatively Ready
+ Submitter: Daniel Krügler Opened: 2008-09-26  Last modified: 2009-05-23
          
+
          View all other issues in [bitset.members].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+The current standard 14882::2003(E) as well as the current draft
+N2723
+have in common a contradiction of the operational semantics
+of member function test 20.3.6.2 [bitset.members]/56-58 and the immutable
+member operator[] overload 20.3.6.2 [bitset.members]/64-66 (all references
+are defined in terms of
+N2723):
+
          
+
+
            
+
          1. bool test(size_t pos) const;
+
            
+
            
+
            
+Requires: pos is valid
+
            
+
            
+Throws: out_of_range if pos does not correspond
+to a valid bit position.
+
            
+
            
+Returns: true if the bit at position pos in *this
+has the value one.
+
            
+
            
+
            2. 
+
          2. constexpr bool operator[](size_t pos) const;
+
            
+
            
+
            
+Requires: pos shall be valid.
+
            
+
            
+Throws: nothing.
+
            
+
            
+Returns: test(pos).
+
            
+
            
+
            3. 
+
          
+
+
          
+Three interpretations:
+
          
+
+
            
+
          1. 
+The operator[] overload is indeed allowed to throw an exception
+(via test(), if pos corresponds to an invalid bit position) which does
+not leave the call frame. In this case this function cannot be a
+constexpr function, because test() is not, due to
+5.19 [expr.const]/2, last bullet.
+
            2. 
+
          2. 
+The intend was not to throw an exception in test in case of an
+invalid bit position. There is only little evidence for this interpretation.
+
            3. 
+
          3. 
+The intend was that operator[] should not throw any exception,
+but that test has the contract to do so, if the provided bit position
+is invalid.
+
            4. 
+
          
+
+
          
+The problem became worse, because issue 720
+recently voted into WP argued that member test logically must be
+a constexpr function, because it was used to define the semantics
+of another constexpr function (the operator[] overload).
+
          
+
+
          
+Three alternatives are proposed, corresponding to the three bullets
+(A), (B), and (C), the author suggests to follow proposal (C).
+
          
+
+
+Proposed alternatives:
+
+
+
            
+
          1. 
+
            
+Remove the constexpr specifier in front of operator[] overload and
+undo that of member test (assuming 720 is accepted) in both the
+class declaration 20.3.6 [template.bitset]/1 and in the member description
+before 20.3.6.2 [bitset.members]/56 and before /64 to read:
+
            
+
            constexpr bool test(size_t pos) const;
+..
+constexpr bool operator[](size_t pos) const;
+
            
+
+
            
+Change the throws clause of p. 65 to read:
+
            
+
+
            
+Throws: nothing
+out_of_range if pos does not correspond to a valid bit
+position.
+
            
+
            2. 
+
          2. 
+
            
+Replace the throws clause p. 57 to read:
+
            
+
+
            
+Throws: out_of_range if pos does not correspond to a valid bit
+position nothing.
+
            
+
            3. 
+
          3. 
+
            
+Undo the addition of the constexpr specifier to the test member
+function in both class declaration 20.3.6 [template.bitset]/1 and in the
+member description before 20.3.6.2 [bitset.members]/56, assuming that 720
+was applied.
+
            
+
+
            constexpr bool test(size_t pos) const;
+
            
+
+
            
+Change the returns clause p. 66 to read:
+
            
+
+
            
+Returns: test(pos) true if the bit at position pos in *this
+has the value one, otherwise false.
+
            
+
            4. 
+
          
+
+
          [
+Post Summit:
+]
          
+
+
+
          
+
          
+Lawrence: proposed resolutions A, B, C are mutually exclusive.
+
          
+
          
+Recommend Review with option C.
+
          
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
+
            
+
          1. 
+
            
+Undo the addition of the constexpr specifier to the test member
+function in both class declaration 20.3.6 [template.bitset]/1 and in the
+member description before 20.3.6.2 [bitset.members]/56, assuming that 720
+was applied.
+
            
+
+
            constexpr bool test(size_t pos) const;
+
            
+
+
            
+Change the returns clause p. 66 to read:
+
            
+
+
            
+Returns: test(pos) true if the bit at position pos in *this
+has the value one, otherwise false.
+
            
+
            2. 
+
          
+
+
+
+
+
+
+
          
+
          908. Deleted assignment operators for atomic types must be volatile
          
+
          Section: 29.5 [atomics.types] Status: Open
+ Submitter: Anthony Williams Opened: 2008-09-26  Last modified: 2009-03-22
          
+
          View all other issues in [atomics.types].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses US 90
          
+
+
          
+The deleted copy-assignment operators for the atomic types are not
+marked as volatile in N2723, whereas the assignment operators from the
+associated non-atomic types are. e.g.
+
          
+
          atomic_bool& operator=(atomic_bool const&) = delete;
+atomic_bool& operator=(bool) volatile;
+
          
+
+
          
+This leads to ambiguity when assigning a non-atomic value to a
+non-volatile instance of an atomic type:
+
          
+
          atomic_bool b;
+b=false;
+
          
+
+
          
+Both assignment operators require a standard conversions: the
+copy-assignment operator can use the implicit atomic_bool(bool)
+conversion constructor to convert false to an instance of
+atomic_bool, or b can undergo a qualification conversion in order to
+use the assignment from a plain bool.
+
          
+
+
          
+This is only a problem once issue 845 is applied.
+
          
+
+
          [
+Summit:
+]
          
+
+
          
+Move to open. Assign to Lawrence. Related to US 90 comment.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Add volatile qualification to the deleted copy-assignment operator of
+all the atomic types:
+
          
+
+
          atomic_bool& operator=(atomic_bool const&) volatile = delete;
+atomic_itype& operator=(atomic_itype const&) volatile = delete;
+
          
+
+
          
+etc.
+
          
+
          
+This will mean that the deleted copy-assignment operator will require
+two conversions in the above example, and thus be a worse match than
+the assignment from plain bool.
+
          
+
+
+
+
+
+
          
+
          909. regex_token_iterator should use initializer_list
          
+
          Section: 28.13.2 [re.tokiter] Status: Tentatively Ready
+ Submitter: Daniel Krügler Opened: 2008-09-26  Last modified: 2009-05-23
          
+
          View all other issues in [re.tokiter].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
+
          Addresses UK 319
          
+
          
+Construction of a regex_token_iterator (28.13.2 [re.tokiter]/6+) usually
+requires the provision of a sequence of integer values, which
+can currently be done via a std::vector<int> or
+a C array of int. Since the introduction of initializer_list in the
+standard it seems much more reasonable to provide a
+corresponding constructor that accepts an initializer_list<int>
+instead. This could be done as a pure addition or one could
+even consider replacement. The author suggests the
+replacement strategy (A), but provides an alternative additive
+proposal (B) as a fall-back, because of the handiness of this
+range type:
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We strongly recommend alternative B of the proposed resolution
+in order that existing code not be broken.
+With that understanding, move to Tentatively Ready.
+
          
+
+
          Original proposed wording:
          
+
+
            
+

          1. 
+
              
+
            1. 
+
              
+In 28.13.2 [re.tokiter]/6 and the list 28.13.2.1 [re.tokiter.cnstr]/10-11 change the
+constructor declaration:
+
              
+
+
              template <std::size_t N>
+regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
+                     const regex_type& re,
+                     const int (&submatches)[N] initializer_list<int> submatches,
+                     regex_constants::match_flag_type m =
+                       regex_constants::match_default);
+
              
+
              2. 
+
+
            2. 
+
              
+In 28.13.2.1 [re.tokiter.cnstr]/12 change the last sentence
+
              
+
+
              
+The third constructor initializes the member subs to hold
+a copy of the sequence of integer values pointed to by the
+iterator range [&submatches.begin(),
+&submatches.end() + N).
+
              
+
              3. 
+
            
+
            2. 
+
+

          2. 
+
              
+
            1. 
+
              
+In 28.13.2 [re.tokiter]/6 and the list 28.13.2.1 [re.tokiter.cnstr]/10-11 insert the
+following constructor declaration between the already existing ones
+accepting a std::vector and a C array of int, resp.:
+
              
+
+
              regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
+                     const regex_type& re,
+                     initializer_list<int> submatches,
+                     regex_constants::match_flag_type m =
+                       regex_constants::match_default);
+
              
+
              2. 
+
            2. 
+
              
+In 28.13.2.1 [re.tokiter.cnstr]/12 change the last sentence
+
              
+
+
              
+The third and fourth constructor initializes the member subs
+to hold a copy of the sequence of integer values pointed to
+by the iterator range [&submatches,&submatches + N)
+and [submatches.begin(),submatches.end()), respectively.
+
              
+
              3. 
+
            
+
            3. 
+
+
          
+
+
+
+
          Proposed resolution:
          
+
+
            
+
+

          1. 
+
              
+
            1. 
+
              
+In 28.13.2 [re.tokiter]/6 and the list 28.13.2.1 [re.tokiter.cnstr]/10-11 insert the
+following constructor declaration between the already existing ones
+accepting a std::vector and a C array of int, resp.:
+
              
+
+
              regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
+                     const regex_type& re,
+                     initializer_list<int> submatches,
+                     regex_constants::match_flag_type m =
+                       regex_constants::match_default);
+
              
+
              2. 
+
            2. 
+
              
+In 28.13.2.1 [re.tokiter.cnstr]/12 change the last sentence
+
              
+
+
              
+The third and fourth constructor initializes the member subs
+to hold a copy of the sequence of integer values pointed to
+by the iterator range [&submatches,&submatches + N)
+and [submatches.begin(),submatches.end()), respectively.
+
              
+
              3. 
+
            
+
            2. 
+
+
          
+
+
+
+
+
+
+
          
+
          910. Effects of MoveAssignable
          
+
          Section: 20.2.9 [concept.copymove] Status: Tentatively Ready
+ Submitter: Alberto Ganesh Barbati Opened: 2008-09-29  Last modified: 2009-05-23
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          Addresses UK 150
          
+
+
          
+The description of the effect of operator= in the MoveAssignable
+concept, given in paragraph 7 is:
+
          
+
+
          result_type  T::operator=(T&&  rv);  // inherited from HasAssign<T, T&&>
+
          
+
+
          
+Postconditions: the constructed T object is equivalent to the value of
+rv before the assignment. [Note: there is no
+requirement on the value of rv after the assignment.  --end note]
+
          
+
          
+
+
          
+The sentence contains a typo (what is the "constructed T object"?)
+probably due to a cut&paste from MoveConstructible. Moreover, the
+discussion of LWG issue 675 shows that the postcondition is too generic
+and might not reflect the user expectations. An implementation of the
+move assignment that just calls swap() would always fulfill the
+postcondition as stated, but might have surprising side-effects in case
+the source rvalue refers to an object that is not going to be
+immediately destroyed. See LWG issue 900 for another example. Due to
+the sometimes intangible nature of the "user expectation", it seems
+difficult to have precise normative wording that could cover all cases
+without introducing unnecessary restrictions. However a non-normative
+clarification could be a very helpful warning sign that swapping is not
+always the correct thing to do.
+
          
+
+
          [
+2009-05-09 Alisdair adds:
+]
          
+
+
+
          
+
          
+Issue 910 is exactly the reason BSI advanced the Editorial comment UK-150.
+
          
+
          
+The post-conditions after assignment are at a minimum that the object
+referenced by rv must be safely destructible, and the transaction should not
+leak resources.  Ideally it should be possible to simply assign rv a new
+valid state after the call without invoking undefined behaviour, but any
+other use of the referenced object would depend upon additional guarantees
+made by that type.
+
          
+
          
+
+
          [
+2009-05-09 Howard adds:
+]
          
+
+
+
          
+
          
+The intent of the rvalue reference work is that the moved from rv is
+a valid object.  Not one in a singular state.  If, for example, the moved from
+object is a vector, one should be able to do anything on that moved-from
+vector that you can do with any other vector.  However you would
+first have to query it to find out what its current state is.  E.g. it might have capacity,
+it might not.  It might have a non-zero size, it might not.  But regardless,
+you can push_back on to it if you want.
+
          
+
+
          
+That being said, most standard code is now conceptized.  That is, the concepts
+list the only operations that can be done with templated types - whether or not
+the values have been moved from.
+
          
+
+
          
+Here is user-written code which must be allowed to be legal:
+
          
+
          #include <vector>
+#include <cstdio>
+
+template <class Allocator>
+void
+inspect(std::vector<double, Allocator>&& v)
+{
+    std::vector<double, Allocator> result(move(v));
+    std::printf("moved from vector has %u size and %u capacity\n", v.size(), v.capacity());
+    std::printf("The contents of the vector are:\n");
+    typedef typename std::vector<double, Allocator>::iterator I;
+    for (I i = v.begin(), e = v.end(); i != e; ++i)
+        printf("%f\n", *i);
+}
+
+int main()
+{
+    std::vector<double> v1(100, 5.5);
+    inspect(move(v1));
+}
+
          
+
+
          
+The above program does not treat the moved-from vector as singular.  It
+only treats it as a vector with an unknown value.
+
          
+
          
+I believe the current proposed wording is consistent with my view on this.
+
          
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree that the proposed resolution
+is an improvement over the current wording.
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+In 20.2.9 [concept.copymove], replace the postcondition in paragraph 7 with:
+
          
+
+
          
+Postconditions: *this is equivalent to the value of rv before the
+assignment. [Note: there is no requirement on the value of rv after the
+assignment, but the
+effect should be unsurprising to the user even in case rv is not
+immediately destroyed. This may require that resources previously owned
+by *this are released instead of transferred to rv. -- end note]
+
          
+
+
+
+
+
+
          
+
          911. I/O streams and move/swap semantic
          
+
          Section: 27.7.1 [input.streams], 27.7.2 [output.streams] Status: Open
+ Submitter: Alberto Ganesh Barbati Opened: 2008-09-29  Last modified: 2009-05-23
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+Class template basic_istream, basic_ostream and basic_iostream
+implements public move constructors, move assignment operators and swap
+method and free functions. This might induce both the user and the
+compiler to think that those types are MoveConstructible, MoveAssignable
+and Swappable. However, those class templates fail to fulfill the user
+expectations. For example:
+
          
+
+
          std::ostream os(std::ofstream("file.txt"));
+assert(os.rdbuf() == 0); // buffer object is not moved to os, file.txt has been closed
+
+std::vector<std::ostream> v;
+v.push_back(std::ofstream("file.txt"));
+v.reserve(100); // causes reallocation
+assert(v[0].rdbuf() == 0); // file.txt has been closed!
+
+std::ostream&& os1 = std::ofstream("file1.txt");
+os1 = std::ofstream("file2.txt");
+os1 << "hello, world"; // still writes to file1.txt, not to file2.txt!
+
+std::ostream&& os1 = std::ofstream("file1.txt");
+std::ostream&& os2 = std::ofstream("file2.txt");
+std::swap(os1, os2);
+os1 << "hello, world"; // writes to file1.txt, not to file2.txt!
+
          
+
+
          
+This is because the move constructor, the move assignment operator and
+swap are all implemented through calls to std::basic_ios member
+functions move() and swap() that do not move nor swap the controlled
+stream buffers. That can't happen because the stream buffers may have
+different types.
+
          
+
+
          
+Notice that for basic_streambuf, the member function swap() is
+protected. I believe that is correct and all of basic_istream,
+basic_ostream, basic_iostream should do the same as the move ctor, move
+assignment operator and swap member function are needed by the derived
+fstreams and stringstreams template. The free swap functions for
+basic_(i|o|io)stream templates should be removed for the same reason.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We note that the rvalue swap functions have already been removed.
+
          
+
          
+Bill is unsure about making the affected functions protected;
+he believes they may need to be public.
+
          
+
          
+We are also unsure about removing the lvalue swap functions as proposed.
+
          
+
          
+Move to Open.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+27.7.1.1 [istream]: make the following member functions protected:
+
          
+
+
          basic_istream(basic_istream&&  rhs);
+basic_istream&  operator=(basic_istream&&  rhs);
+void  swap(basic_istream&&  rhs);
+
          
+
+
          
+Ditto: remove the three swap free functions signatures
+
          
+
+
          // swap: 
+template <class charT, class traits> 
+  void swap(basic_istream<charT, traits>& x, basic_istream<charT, traits>& y); 
+template <class charT, class traits> 
+  void swap(basic_istream<charT, traits>&& x, basic_istream<charT, traits>& y); 
+template <class charT, class traits> 
+  void swap(basic_istream<charT, traits>& x, basic_istream<charT, traits>&& y);
+
          
+
+
          
+27.7.1.1.2 [istream.assign]: remove paragraph 4
+
          
+
+
          template <class charT, class traits> 
+  void swap(basic_istream<charT, traits>& x, basic_istream<charT, traits>& y); 
+template <class charT, class traits> 
+  void swap(basic_istream<charT, traits>&& x, basic_istream<charT, traits>& y); 
+template <class charT, class traits> 
+  void swap(basic_istream<charT, traits>& x, basic_istream<charT, traits>&& y);
+
          
+
          
+Effects: x.swap(y).
+
          
+
          
+
+
          
+27.7.1.5 [iostreamclass]: make the following member function protected:
+
          
+
+
          basic_iostream(basic_iostream&&  rhs);
+basic_iostream&  operator=(basic_iostream&&  rhs);
+void  swap(basic_iostream&&  rhs);
+
          
+
+
          
+Ditto: remove the three swap free functions signatures
+
          
+
+
          template <class charT, class traits> 
+  void swap(basic_iostream<charT, traits>& x, basic_iostream<charT, traits>& y); 
+template <class charT, class traits> 
+  void swap(basic_iostream<charT, traits>&& x, basic_iostream<charT, traits>& y); 
+template <class charT, class traits> 
+  void swap(basic_iostream<charT, traits>& x, basic_iostream<charT, traits>&& y);
+
          
+
+
          
+27.7.1.5.3 [iostream.assign]: remove paragraph 3
+
          
+
+
          template <class charT, class traits> 
+  void swap(basic_iostream<charT, traits>& x, basic_iostream<charT, traits>& y); 
+template <class charT, class traits> 
+  void swap(basic_iostream<charT, traits>&& x, basic_iostream<charT, traits>& y); 
+template <class charT, class traits> 
+  void swap(basic_iostream<charT, traits>& x, basic_iostream<charT, traits>&& y);
+
          
+
          
+Effects: x.swap(y).
+
          
+
          
+
+
          
+27.7.2.1 [ostream]: make the following member function protected:
+
          
+
+
          basic_ostream(basic_ostream&&  rhs);
+basic_ostream&  operator=(basic_ostream&&  rhs);
+void  swap(basic_ostream&&  rhs);
+
          
+
+
          
+Ditto: remove the three swap free functions signatures
+
          
+
+
          // swap: 
+template <class charT, class traits> 
+  void swap(basic_ostream<charT, traits>& x, basic_ostream<charT, traits>& y);
+template <class charT, class traits> 
+  void swap(basic_ostream<charT, traits>&& x, basic_ostream<charT, traits>& y); 
+template <class charT, class traits> 
+  void swap(basic_ostream<charT, traits>& x, basic_ostream<charT, traits>&& y);
+
          
+
+
          
+27.7.2.3 [ostream.assign]: remove paragraph 13 (The paragraphs seems to
+be misnumbered in the whole section 27.7.2 [output.streams] in
+N2723.
+The paragraph to
+remove is the one that describes the three swap free functions).
+
          
+
+
          template <class charT, class traits> 
+  void swap(basic_ostream<charT, traits>& x, basic_ostream<charT, traits>& y); 
+template <class charT, class traits> 
+  void swap(basic_ostream<charT, traits>&& x, basic_ostream<charT, traits>& y); 
+template <class charT, class traits> 
+  void swap(basic_ostream<charT, traits>& x, basic_ostream<charT, traits>&& y);
+
          
+
          
+Effects: x.swap(y).
+
          
+
          
+
+
+
+
+
+
+
          
+
          912. Array swap needs to be conceptualized
          
+
          Section: 25.4.3 [alg.swap] Status: Tentatively NAD
+ Submitter: Daniel Krügler Opened: 2008-10-01  Last modified: 2009-05-23
          
+
          View all other issues in [alg.swap].
          
+
          View all issues with Tentatively NAD status.
          
+
          Discussion:
          
+
          
+With the adaption of 809
+we have a new algorithm swap for C-arrays, which needs to be conceptualized.
+
          
+
+
          [
+Post Summit Daniel adds:
+]
          
+
+
+
          
+Recommend as NAD Editorial: The changes have already been applied to the WP
+N2800.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+Move to NAD; the changes have already been made.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Replace in 25.4.3 [alg.swap] before p. 3 until p. 4 by
+
          
+
+
          template <class ValueType T, size_t N>
+requires Swappable<T>
+void swap(T (&a)[N], T (&b)[N]);
+
          
+
          
+
          
+Requires: T shall be Swappable.
+
          
+
          
+Effects: swap_ranges(a, a + N, b);
+
          
+
          
+
          
+
+
+
+
+
+
+
          
+
          913. Superfluous requirements for replace algorithms
          
+
          Section: 25.4.5 [alg.replace] Status: Tentatively Ready
+ Submitter: Daniel Krügler Opened: 2008-10-03  Last modified: 2009-05-23
          
+
          View other active issues in [alg.replace].
          
+
          View all other issues in [alg.replace].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+(A) 25.4.5 [alg.replace]/1:
+
          
+
+
          
+Requires: The expression *first = new_value shall be valid.
+
          
+
+
          
+(B) 25.4.5 [alg.replace]/4:
+
          
+
+
          
+Requires: The results of the expressions *first and new_value shall
+be writable to the result output iterator.[..]
+
          
+
+
          
+Since conceptualization, the quoted content of these clauses is covered
+by the existing requirements
+
          
+
+
          
+(A) OutputIterator<Iter, const T&>
+
          
+
+
          
+and
+
          
+
+
          
+(B) OutputIterator<OutIter, InIter::reference> && OutputIterator<OutIter, const T&>
+
          
+
+
          
+resp, and thus should be removed.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We agree with the proposed resolution.
+
          
+
          
+Move to Tentatively Ready.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
            
+
          1. 
+
            
+Remove 25.4.5 [alg.replace]/1.
+
            
+
            template<ForwardIterator Iter, class T> 
+  requires OutputIterator<Iter, Iter::reference> 
+        && OutputIterator<Iter, const T&> 
+        && HasEqualTo<Iter::value_type, T> 
+  void replace(Iter first, Iter last, 
+               const T& old_value, const T& new_value); 
+
+template<ForwardIterator Iter, Predicate<auto, Iter::value_type> Pred, class T> 
+  requires OutputIterator<Iter, Iter::reference> 
+        && OutputIterator<Iter, const T&> 
+        && CopyConstructible<Pred> 
+  void replace_if(Iter first, Iter last, 
+                  Pred pred, const T& new_value);
+
            
+
            
+1 Requires: The expression *first = new_value shall be valid.
+
            
+
            
+
            2. 
+
          2. 
+
            
+25.4.5 [alg.replace]/4: Remove the sentence "The results of the
+expressions *first and
+new_value shall be writable to the result output iterator.".
+
            
+
            template<InputIterator InIter, typename OutIter, class T> 
+  requires OutputIterator<OutIter, InIter::reference> 
+        && OutputIterator<OutIter, const T&> 
+        && HasEqualTo<InIter::value_type, T> 
+  OutIter replace_copy(InIter first, InIter last, 
+                       OutIter result, 
+                       const T& old_value, const T& new_value);
+
+template<InputIterator InIter, typename OutIter,
+         Predicate<auto, InIter::value_type> Pred, class T> 
+  requires OutputIterator<OutIter, InIter::reference> 
+        && OutputIterator<OutIter, const T&> 
+        && CopyConstructible<Pred> 
+  OutIter replace_copy_if(InIter first, InIter last, 
+                          OutIter result, 
+                          Pred pred, const T& new_value);
+
            
+
            
+4 Requires: The results of the expressions *first and
+new_value shall be writable to the result output
+iterator. The ranges [first,last) and [result,result +
+(last - first)) shall not overlap.
+
            
+
            
+
            3. 
+
          
+
+
+
+
+
+
          
+
          914. Superfluous requirement for unique
          
+
          Section: 25.4.9 [alg.unique] Status: Tentatively Ready
+ Submitter: Daniel Krügler Opened: 2008-10-03  Last modified: 2009-05-23
          
+
          View other active issues in [alg.unique].
          
+
          View all other issues in [alg.unique].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+25.4.9 [alg.unique]/2: "Requires: The comparison function shall be an
+equivalence relation."
+
          
+
+
          
+The essence of this is already covered by the given requirement
+
          
+
+
          EquivalenceRelation<auto, Iter::value_type> Pred
+
          
+
+
          
+and should thus be removed.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Remove 25.4.9 [alg.unique]/2
+
          
+
+
          template<ForwardIterator Iter>
+  requires OutputIterator<Iter, Iter::reference>
+        && EqualityComparable<Iter::value_type>
+  Iter unique(Iter first, Iter last);
+
+template<ForwardIterator Iter, EquivalenceRelation<auto, Iter::value_type> Pred>
+  requires OutputIterator<Iter, RvalueOf<Iter::reference>::type>
+        && CopyConstructible<Pred>
+  Iter unique(Iter first, Iter last,
+               Pred pred);
+
          
+
          
+
          
+1 Effects: ...
+
          
+
          
+2 Requires: The comparison function shall be an equivalence relation.
+
          
+
          
+
          
+
+
+
+
+
+
          
+
          915. minmax with initializer_list should return
+pair of T, not pair of const T&
          
+
          Section: 25.5.7 [alg.min.max] Status: Tentatively Ready
+ Submitter: Daniel Krügler Opened: 2008-10-04  Last modified: 2009-05-23
          
+
          View other active issues in [alg.min.max].
          
+
          View all other issues in [alg.min.max].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+It seems that the proposed changes for
+N2772
+were not clear enough in
+this point:
+
          
+
+
          
+25.5.7 [alg.min.max], before p.23 + p.24 + before p. 27 + p. 28 say that the return
+type of the minmax overloads with an initializer_list is
+pair<const T&, const T&>,
+which is inconsistent with the decision for the other min/max overloads which take
+a initializer_list as argument and return a T, not a const T&.
+Doing otherwise for minmax would easily lead to unexpected life-time
+problems by using minmax instead of min and max separately.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
            
+
          1. 
+
            
+In 25 [algorithms]/2, header <algorithm> synopsis change as indicated:
+
            
+
+
            template<classLessThanComparable T>
+requires CopyConstructible<T>
+pair<const T&, const T&>
+minmax(initializer_list<T> t);
+
+template<class T, classStrictWeakOrder<auto, T> Compare>
+requires CopyConstructible<T>
+pair<const T&, const T&>
+minmax(initializer_list<T> t, Compare comp);
+
            
+
            2. 
+
          2. 
+
            
+In 25.5.7 [alg.min.max] change as indicated (Begin: Just before p.20):
+
            
+
            template<classLessThanComparable T>
+  requires CopyConstructible<T>
+  pair<const T&, const T&>
+  minmax(initializer_list<T> t);
+
            
+
            
+
            
+-20- Requires: T is LessThanComparable and
+CopyConstructible.
+
            
+
            
+-21- Returns: pair<const T&, const
+T&>(x, y) where x is the
+smallest value and y the largest value in the initializer_list.
+
            
+
            
+
+
            [..]
            
+
            template<class T, classStrictWeakOrder<auto, T> Compare>
+  requires CopyConstructible<T>
+  pair<const T&, const T&>
+  minmax(initializer_list<T> t, Compare comp);
+
            
+
+
            
+
            
+-24- Requires: type T is LessThanComparable and CopyConstructible.
+
            
+
            
+-25- Returns: pair<const T&, const
+T&>(x, y) where x is the
+smallest value and y largest value in the initializer_list.
+
            
+
            
+
            
+
            3. 
+
          
+
+
+
+
+
+
+
          
+
          916. Redundant move-assignment operator of pair should be removed
          
+
          Section: 20.3.3 [pairs] Status: Open
+ Submitter: Daniel Krügler Opened: 2008-10-04  Last modified: 2009-05-23
          
+
          View other active issues in [pairs].
          
+
          View all other issues in [pairs].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          see also 917.
          
+
+
          
+The current WP provides the following assignment operators for pair
+in 20.3.3 [pairs]/1:
+
          
+
+
            
+
          1. 
+
            template<class U , class V>
+requires HasAssign<T1, const U&> && HasAssign<T2, const V&>
+pair& operator=(const pair<U , V>& p);
+
            
+
            2. 
+
          2. 
+
            requires MoveAssignable<T1> && MoveAssignable<T2> pair& operator=(pair&& p );
+
            
+
            3. 
+
          3. 
+
            template<class U , class V>
+requires HasAssign<T1, RvalueOf<U>::type> && HasAssign<T2, RvalueOf<V>::type>
+pair& operator=(pair<U , V>&& p);
+
            
+
            4. 
+
          
+
+
          
+It seems that the functionality of (2) is completely covered by (3), therefore
+(2) should be removed.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Bill believes the extra assignment operators are necessary for resolving
+ambiguities, but that does not mean it needs to be part of the specification.
+
          
+
          
+Move to Open.
+We recommend this be looked at in the context of the ongoing work
+related to the pair templates.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
            
+
          1. 
+
            
+In 20.3.3 [pairs] p. 1, class pair and just before p. 13 remove the declaration:
+
            
+
+
            requires MoveAssignable<T1> && MoveAssignable<T2> pair& operator=(pair&& p );
+
            
+
            2. 
+
+
          2. 
+Remove p.13+p.14
+
            3. 
+
+
          
+
+
+
+
+
+
          
+
          917. Redundant move-assignment operator of tuple should be removed
          
+
          Section: 20.5.2.1 [tuple.cnstr] Status: Open
+ Submitter: Daniel Krügler Opened: 2008-10-04  Last modified: 2009-05-23
          
+
          View other active issues in [tuple.cnstr].
          
+
          View all other issues in [tuple.cnstr].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          see also 916.
          
+
          
+N2770 (and thus now the WP) removed the
+non-template move-assignment operator from tuple's class definition,
+but the latter individual member description does still provide this
+operator. Is this (a) an oversight and can it (b) be solved as part of an
+editorial process?
+
          
+
+
          [
+Post Summit Daniel provided wording.
+]
          
+
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We believe that the proposed resolution's part 1 is editorial.
+
          
+
          
+Regarding part 2, we either remove the specification as proposed,
+or else add back the declaration to which the specification refers.
+Alisdair and Bill prefer the latter.
+It is not immediately obvious whether the function is intended to be present.
+
          
+
          
+We recommend that the Project Editor restore the missing declaration
+and that we keep part 2 of the issue alive.
+
          
+
          
+Move to Open.
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
            
+
          1. 
+
            
+In 20.5.2 [tuple.tuple], class tuple just before member swap please
+change as indicated:
+
            
+
            [
+This fixes an editorial loss between N2798 to N2800
+]
            
+
+
            template <class... UTypes>
+requires HasAssign<Types, const UTypes&>...
+tuple& operator=(const pair<UTypes...>&);
+
+template <class... UTypes>
+requires HasAssign<Types, RvalueOf<UTypes>::type>...
+tuple& operator=(pair<UTypes...>&&);
+
            
+
            2. 
+
          2. 
+
            
+In 20.5.2.1 [tuple.cnstr], starting just before p. 11 please remove
+as indicated:
+
            
+
+
            requires MoveAssignable<Types>... tuple& operator=(tuple&& u);
+
            
+
            
+
            
+-11- Effects: Move-assigns each element of u to the corresponding
+element of *this.
+
            
+
            
+-12- Returns: *this.
+
            
+
            
+
            
+
            3. 
+
          
+
+
+
+
+
+
          
+
          918. Swap for tuple needs to be conceptualized
          
+
          Section: 20.5.2.6 [tuple.swap] Status: Tentatively NAD
+ Submitter: Daniel Krügler Opened: 2008-10-04  Last modified: 2009-05-23
          
+
          View all issues with Tentatively NAD status.
          
+
          Discussion:
          
+
          
+Issue 522 was accepted after tuple had been conceptualized,
+therefore this step needs to be completed.
+
          
+
+
          [
+Post Summit Daniel adds
+]
          
+
+
+
          
+This is now NAD Editorial (addressed by
+N2844)
+except for item 3 in the proposed wording.
+
          
+
+
          [
+2009-05-01 Daniel adds:
+]
          
+
+
+
          
+As of the recent WP
+(N2857),
+this issue is now completely covered by editorial
+changes (including the third bullet), therefore I unconditionally recommend
+NAD.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We observed that all the proposed changes have already been applied to the
+Working Draft, rendering this issue moot.
+
          
+
          
+Move to NAD.
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
            
+
          1. 
+
            
+In both 20.5.1 [tuple.general]/2 and 20.5.2.7 [tuple.special] change
+
            
+
+
            template <class Swappable... Types>
+void swap(tuple<Types...>& x, tuple<Types...>& y);
+
            
+
+
            2. 
+
+
          2. 
+
            
+In 20.5.2 [tuple.tuple], class tuple definition and in
+20.5.2.6 [tuple.swap], change
+
            
+
+
            requires Swappable<Types>...void swap(tuple&);
+
            
+
+
            3. 
+
+
          3. 
+
            
+In 20.5.2.6 [tuple.swap] remove the current requires-clause, which says:
+
            
+
+
            
+Requires: Each type in Types shall be Swappable
+
            
+
            4. 
+
+
          
+
+
+
+
+
+
+
          
+
          919. (forward_)list specialized remove algorithms are over constrained
          
+
          Section: 23.3.3.5 [forwardlist.ops], 23.3.4.4 [list.ops] Status: Review
+ Submitter: Daniel Krügler Opened: 2008-10-06  Last modified: 2009-05-23
          
+
          View other active issues in [forwardlist.ops].
          
+
          View all other issues in [forwardlist.ops].
          
+
          View all issues with Review status.
          
+
          Discussion:
          
+
          
+The signatures of forwardlist::remove and list::remove
+defined in 23.3.3.5 [forwardlist.ops] before 11 + 23.3.4.4 [list.ops] before 15:
+
          
+
+
          requires EqualityComparable<T> void remove(const T& value);
+
          
+
+
          
+are asymmetric to their predicate variants (which only require
+Predicate, not EquivalenceRelation) and with the free algorithm
+remove (which only require HasEqualTo). Also, nothing in the
+pre-concept WP
+N2723
+implies that EqualityComparable should
+be the intended requirement.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We agree with the proposed resolution,
+but would like additional input from concepts experts.
+
          
+
          
+Move to Review.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
            
+
          1. 
+
            
+Replace in 23.3.3.5 [forwardlist.ops] before 11 and in 23.3.4.4 [list.ops] before 15
+
            
+
+
            requires EqualityComparable<T> HasEqualTo<T, T> void remove(const T& value);
+
            
+
            2. 
+
          
+
+
+
+
+
+
+
          
+
          920. Ref-qualification support in the library
          
+
          Section: 20.7.15 [func.memfn] Status: Open
+ Submitter: Bronek Kozicki Opened: 2008-10-06  Last modified: 2009-05-23
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+Daniel Krügler wrote:
+
          
+
+
          
+
          
+Shouldn't above list be completed for &- and &&-qualified
+member functions This would cause to add:
+
          
+
          template<Returnable R, class T, CopyConstructible... Args>
+unspecified mem_fn(R (T::* pm)(Args...) &);
+template<Returnable R, class T, CopyConstructible... Args>
+unspecified mem_fn(R (T::* pm)(Args...) const &);
+template<Returnable R, class T, CopyConstructible... Args>
+unspecified mem_fn(R (T::* pm)(Args...) volatile &);
+template<Returnable R, class T, CopyConstructible... Args>
+unspecified mem_fn(R (T::* pm)(Args...) const volatile &);
+template<Returnable R, class T, CopyConstructible... Args>
+unspecified mem_fn(R (T::* pm)(Args...) &&);
+template<Returnable R, class T, CopyConstructible... Args>
+unspecified mem_fn(R (T::* pm)(Args...) const &&);
+template<Returnable R, class T, CopyConstructible... Args>
+unspecified mem_fn(R (T::* pm)(Args...) volatile &&);
+template<Returnable R, class T, CopyConstructible... Args>
+unspecified mem_fn(R (T::* pm)(Args...) const volatile &&);
+
          
+
+
          
+
+
          
+yes, absolutely. Thanks for spotting this. Without this change mem_fn
+cannot be initialized from pointer to ref-qualified member function. I
+believe semantics of such function pointer is well defined.
+
          
+
+
          [
+Post Summit Daniel provided wording.
+]
          
+
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We need to think about whether we really want to go down the proposed path
+of combinatorial explosion.
+Perhaps a Note would suffice.
+
          
+
          
+We would really like to have an implementation before proceeding.
+
          
+
          
+Move to Open, and recommend this be deferred until after the next
+Committee Draft has been issued.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
            
+
          1. 
+
            
+In 20.7 [function.objects]/2, header <functional> synopsis, just after
+the section "// 20.6.15, member function adaptors::" add the following
+declarations to the existing list:
+
            
+
            template<Returnable R, class T, CopyConstructible... Args>
+  unspecified mem_fn(R (T::* pm)(Args...) &);
+template<Returnable R, class T, CopyConstructible... Args>
+  unspecified mem_fn(R (T::* pm)(Args...) const &);
+template<Returnable R, class T, CopyConstructible... Args>
+  unspecified mem_fn(R (T::* pm)(Args...) volatile &);
+template<Returnable R, class T, CopyConstructible... Args>
+  unspecified mem_fn(R (T::* pm)(Args...) const volatile &);
+template<Returnable R, class T, CopyConstructible... Args>
+  unspecified mem_fn(R (T::* pm)(Args...) &&);
+template<Returnable R, class T, CopyConstructible... Args>
+  unspecified mem_fn(R (T::* pm)(Args...) const &&);
+template<Returnable R, class T, CopyConstructible... Args>
+  unspecified mem_fn(R (T::* pm)(Args...) volatile &&);
+template<Returnable R, class T, CopyConstructible... Args>
+  unspecified mem_fn(R (T::* pm)(Args...) const volatile &&);
+
            
+
            2. 
+
          2. 
+
            
+In 20.7.15 [func.memfn] add the following declarations to the existing
+list:
+
            
+
            template<Returnable R, class T, CopyConstructible... Args>
+  unspecified mem_fn(R (T::* pm)(Args...) &);
+template<Returnable R, class T, CopyConstructible... Args>
+  unspecified mem_fn(R (T::* pm)(Args...) const &);
+template<Returnable R, class T, CopyConstructible... Args>
+  unspecified mem_fn(R (T::* pm)(Args...) volatile &);
+template<Returnable R, class T, CopyConstructible... Args>
+  unspecified mem_fn(R (T::* pm)(Args...) const volatile &);
+template<Returnable R, class T, CopyConstructible... Args>
+  unspecified mem_fn(R (T::* pm)(Args...) &&);
+template<Returnable R, class T, CopyConstructible... Args>
+  unspecified mem_fn(R (T::* pm)(Args...) const &&);
+template<Returnable R, class T, CopyConstructible... Args>
+  unspecified mem_fn(R (T::* pm)(Args...) volatile &&);
+template<Returnable R, class T, CopyConstructible... Args>
+  unspecified mem_fn(R (T::* pm)(Args...) const volatile &&);
+
            
+
            3. 
+
          
+
          
+The following text, most notably p.2 and p.3 which discuss influence
+of the cv-qualification on the definition of the base class's first template
+parameter remains unchanged.
+
          
+
+
+
+
+
+
          
+
          921. Rational Arithmetic should use template aliases
          
+
          Section: 20.4.1 [ratio.ratio] Status: Review
+ Submitter: Pablo Halpern Opened: 2008-10-07  Last modified: 2009-05-23
          
+
          View other active issues in [ratio.ratio].
          
+
          View all other issues in [ratio.ratio].
          
+
          View all issues with Review status.
          
+
          Discussion:
          
+
          
+The compile-time functions that operate on ratio<N,D> require the
+cumbersome and error-prone "evaluation" of a type member using a
+meta-programming style that predates the invention of template aliases.
+Thus, multiplying three ratios a, b, and c requires the expression:
+
          
+
+
          ratio_multiply<a, ratio_multiply<b, c>::type>::type
+
          
+
+
          
+The simpler expression:
+
          
+
+
          ratio_multiply<a, ratio_multiply<b, c>>
+
          
+
+
          
+Could be used by if template aliases were employed in the definitions.
+
          
+
+
          [
+Post Summit:
+]
          
+
+
+
          
+
          
+Jens: not a complete proposed resolution: "would need to make similar change"
+
          
+
          
+Consensus: We agree with the direction of the issue.
+
          
+
          
+Recommend Open.
+
          
+
          
+
+
          [
+2009-05-11 Daniel adds:
+]
          
+
+
+
          
+
          
+Personally I'm not in favor for the addition of:
+
          
+
          typedef ratio type;
+
          
+
          
+For a reader of the
+standard it's usage or purpose is unclear. I haven't seen similar examples
+of attempts to satisfy non-feature complete compilers.
+
          
+
          
+
+
          [
+2009-05-11 Pablo adds:
+]
          
+
+
+
          
+
          
+The addition of type to the ratio template allows the previous style
+(i.e., in the prototype implementations) to remain valid and permits the
+use of transitional library implementations for C++03 compilers.  I do
+not feel strongly about its inclusion, however, and leave it up to the
+reviewers to decide.
+
          
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+Bill asks for additional discussion in the issue
+that spells out more details of the implementation.
+Howard points us to issue 948
+which has at least most of the requested details.
+Tom is strongly in favor of overflow-checking at compile time.
+Pete points out that there is no change of functionality implied.
+We agree with the proposed resolution,
+but recommend moving the issue to Review
+to allow time to improve the discussion if needed.
+
          
+
+
+
          Proposed resolution:
          
+
+ 
+ 
            
+
          1. 
+
            
+In 20.4 [ratio]/3 change as indicated:
+
            
+
+
            // ratio arithmetic
+template <class R1, class R2> structusing ratio_add = see below;
+template <class R1, class R2> structusing ratio_subtract = see below;
+template <class R1, class R2> structusing ratio_multiply = see below;
+template <class R1, class R2> structusing ratio_divide = see below;
+
            
+
            2. 
+
          2. 
+
            
+In 20.4.1 [ratio.ratio], change as indicated:
+
            
+
            namespace std {
+  template <intmax_t N, intmax_t D = 1>
+  class ratio {
+  public:
+    typedef ratio type;
+    static const intmax_t num;
+    static const intmax_t den;
+  };
+}
+
            
+
            3. 
+
          3. 
+
            
+In 20.4.2 [ratio.arithmetic] change as indicated:
+
            
+
+
            template <class R1, class R2> structusing ratio_add = see below{
+  typedef see below type;
+};
+
            
+
+
            
+
            
+1 The nested typedef type ratio_add<R1, R2>
+shall be a synonym for ratio<T1, T2>
+where T1 has the value R1::num * R2::den + R2::num * R1::den and T2
+has the value R1::den * R2::den.
+
            
+
            
+
            
+
            template <class R1, class R2> structusing ratio_subtract = see below{
+  typedef see below type;
+};
+
            
+
            
+
            
+2 The nested typedef type ratio_subtract<R1, R2>
+shall be a synonym for ratio<T1, T2>
+where T1 has the value R1::num * R2::den - R2::num * R1::den and T2
+has the value R1::den * R2::den.
+
            
+
            
+
            
+
            template <class R1, class R2> structusing ratio_multiply = see below{
+  typedef see below type;
+};
+
            
+
            
+
            
+3 The nested typedef type ratio_multiply<R1, R2>
+shall be a synonym for ratio<T1, T2>
+where T1 has the value R1::num * R2::num and T2 has the value R1::den * R2::den.
+
            
+
            
+
            
+
            template <class R1, class R2> structusing ratio_divide = see below{
+  typedef see below type;
+};
+
            
+
            
+
            
+4 The nested typedef type ratio_divide<R1, R2>
+shall be a synonym for ratio<T1, T2>
+where T1 has the value R1::num * R2::den and T2 has the value R1::den * R2::num.
+
            
+
            
+
            
+
            4. 
+
          4. 
+
            
+In 20.9.3.1 [time.duration.cons]/4 change as indicated:
+
            
+
            
+
            
+Requires: treat_as_floating_point<rep>::value shall be true or
+ratio_divide<Period2, period>::type::den shall be 1.[..]
+
            
+
            
+
            5. 
+
          5. 
+
            
+In 20.9.3.7 [time.duration.cast]/2 change as indicated:
+
            
+
            
+
            
+Returns: Let CF be ratio_divide<Period, typename
+ToDuration::period>::type, and [..]
+
            
+
            
+
            6. 
+
          
+
+
+
+
+
+
          
+
          922. [func.bind.place] Number of placeholders
          
+
          Section: B [implimits] Status: Tentatively Ready
+ Submitter: Sohail Somani Opened: 2008-10-11  Last modified: 2009-03-13
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          Addresses DE 24
          
+
+
          
+With respect to the section 20.7.12.1.4 [func.bind.place]:
+
          
+
          
+TR1 dropped some suggested implementation quantities for the number of
+placeholders. The purpose of this defect is to put these back for C++0x.
+
          
+
+
          [
+Post Summit:
+]
          
+
+
+
          
+
          
+see DE 24
+
          
+
          
+Recommend applying the proposed resolution from DE 24, with that
+Tentatively Ready.
+
          
+
          
+
+Original proposed resolution:
+
+
          
+Add 20.7.12.1.4 [func.bind.place]/2:
+
          
+
+
          
+While the exact number of placeholders (_M) is implementation defined,
+this number shall be at least 10.
+
          
+
+
+
+
          Proposed resolution:
          
+
+
          
+Add to B [implimits]:
+
          
+
+
            
+
          • 
+Number of placeholders (20.7.12.1.4 [func.bind.place]) [10].
+
            • 
+
          
+
+
+
+
+
+
+
          
+
          923. atomics with floating-point 
          
+
          Section: 29 [atomics] Status: Open
+ Submitter: Herb Sutter Opened: 2008-10-17  Last modified: 2009-05-01
          
+
          View other active issues in [atomics].
          
+
          View all other issues in [atomics].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+Right now, C++0x doesn't have atomic<float>. We're thinking of adding
+the words to support it for TR2 (note: that would be slightly
+post-C++0x). If we need it, we could probably add the words.
+
          
+
          
+Proposed resolutions: Using atomic<FP>::compare_exchange (weak or
+strong) should be either:
+
          
+
+
            
+
          1. 
+ill-formed, or
+
            2. 
+
          2. 
+well-defined.
+
            3. 
+
          
+
+
          
+I propose Option 1 for C++0x for expediency. If someone wants to argue
+for Option 2, they need to say what exactly they want compare_exchange
+to mean in this case (IIRC, C++0x doesn't even assume IEEE 754).
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Move to open. Blocked until concepts for atomics are addressed.
+
          
+
+
          [
+Post Summit Anthony adds:
+]
          
+
+
+
          
+
          
+Recommend NAD. C++0x does have std::atomic<float>, and both
+compare_exchange_weak and compare_exchange_strong are well-defined in
+this case. Maybe change the note in 29.6 [atomics.types.operations] paragraph 20 to:
+
          
+
+
          
+
          
+[Note: The effect of the compare-and-exchange operations is
+
          
+
          if (!memcmp(object,expected,sizeof(*object)))
+    *object = desired;
+else
+    *expected = *object;
+
          
+
+
          
+This may result in failed comparisons for values that compare equal if
+the underlying type has padding bits or alternate representations of
+the same value. -- end note]
+
          
+
          
+
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+Change the note in 29.6 [atomics.types.operations] paragraph 20 to:
+
          
+
+
          
+
          
+[Note: The effect of the compare-and-exchange operations is
+
          
+
          if (*object == *expected !memcmp(object,expected,sizeof(*object)))
+    *object = desired;
+else
+    *expected = *object;
+
          
+
+
          
+This may result in failed comparisons for values that compare equal if
+the underlying type has padding bits or alternate representations of
+the same value. -- end note]
+
          
+
          
+
+
+
+
+
+
+
          
+
          924. structs with internal padding
          
+
          Section: 29 [atomics] Status: Open
+ Submitter: Herb Sutter Opened: 2008-10-17  Last modified: 2009-03-22
          
+
          View other active issues in [atomics].
          
+
          View all other issues in [atomics].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+Right now, the compare_exchange_weak loop should rapidly converge on the
+padding contents. But compare_exchange_strong will require a bit more
+compiler work to ignore padding for comparison purposes.
+
          
+
          
+Note that this isn't a problem for structs with no padding, and we do
+already have one portable way to ensure that there is no padding that
+covers the key use cases: Have elements be the same type. I suspect that
+the greatest need is for a structure of two pointers, which has no
+padding problem. I suspect the second need is a structure of a pointer
+and some form of an integer. If that integer is intptr_t, there will be
+no padding.
+
          
+
          
+Related but separable issue: For unused bitfields, or other unused
+fields for that matter, we should probably say it's the programmer's
+responsibility to set them to zero or otherwise ensure they'll be
+ignored by memcmp.
+
          
+
+
          
+Proposed resolutions: Using
+atomic<struct-with-padding>::compare_exchange_strong should be either:
+
          
+
+
            
+
          1. 
+ill-formed, or
+
            2. 
+
          2. 
+well-defined.
+
            3. 
+
          
+
+
          
+I propose Option 1 for C++0x for expediency, though I'm not sure how to
+say it. I would be happy with Option 2, which I believe would mean that
+compare_exchange_strong would be implemented to avoid comparing padding
+bytes, or something equivalent such as always zeroing out padding when
+loading/storing/comparing. (Either implementation might require compiler
+support.)
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Move to open. Blocked until concepts for atomics are addressed.
+
          
+
+
          [
+Post Summit Anthony adds:
+]
          
+
+
+
          
+The resoultion of LWG 923 should resolve this issue as well.
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
+
+
+
          
+
          925. shared_ptr's explicit conversion from unique_ptr
          
+
          Section: 20.8.13.2.1 [util.smartptr.shared.const] Status: Tentatively Ready
+ Submitter: Rodolfo Lima Opened: 2008-10-12  Last modified: 2009-05-23
          
+
          View other active issues in [util.smartptr.shared.const].
          
+
          View all other issues in [util.smartptr.shared.const].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+The current working draft
+(N2798),
+section 20.8.13.2.1 [util.smartptr.shared.const] declares
+shared_ptr's constructor that takes a rvalue reference to unique_ptr and
+auto_ptr as being explicit, affecting several valid smart pointer use
+cases that would take advantage of this conversion being implicit, for
+example:
+
          
+
+
          class A;
+std::unique_ptr<A> create();
+void process(std::shared_ptr<A> obj);
+
+int main()
+{
+   process(create());                  // use case #1
+   std::unique_ptr<A> uobj = create();
+   process(std::move(uobj));           // use case #2
+   return 0;
+}
+
          
+
+
          
+If unique_ptr to shared_ptr conversions are explicit, the above lines
+should be written:
+
          
+
+
          process(std::shared_ptr<A>(create()));        // use case #1
+process(std::shared_ptr<A>(std::move(uobj))); // use case #2
+
          
+
+
          
+The extra cast required doesn't seems to give any benefits to the user,
+nor protects him of any unintended conversions, this being the raison
+d'etre of explicit constructors.
+
          
+
+
          
+It seems that this constructor was made explicit to mimic the conversion
+from auto_ptr in pre-rvalue reference days, which accepts both lvalue and
+rvalue references. Although this decision was valid back then, C++0x
+allows the user to express in a clear and non verbose manner when he wants
+move semantics to be employed, be it implicitly (use case 1) or explicitly
+(use case 2).
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Howard and Alisdair like the motivating use cases
+and the proposed resolution.
+
          
+
          
+Move to Tentatively Ready.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+In both 20.8.13.2 [util.smartptr.shared] paragraph 1 and 
+20.8.13.2.1 [util.smartptr.shared.const] change:
+
          
+
+
          template <class Y> explicit shared_ptr(auto_ptr<Y> &&r);
+template <class Y, class D> explicit shared_ptr(unique_ptr<Y, D> &&r);
+
          
+
+
+
+
+
+
+
          
+
          926. Sequentially consistent fences, relaxed operations and modification order
          
+
          Section: 29.3 [atomics.order] Status: Open
+ Submitter: Anthony Williams Opened: 2008-10-19  Last modified: 2009-03-22
          
+
          View all other issues in [atomics.order].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          Addresses UK 313
          
+
+
          
+There was an interesting issue raised over on comp.programming.threads
+today regarding the following example
+
          
+
+
          // Thread 1:
+x.store(1, memory_order_relaxed);           // SX
+atomic_thread_fence(memory_order_seq_cst);  // F1
+y.store(1, memory_order_relaxed);           // SY1
+atomic_thread_fence(memory_order_seq_cst);  // F2
+r1 = y.load(memory_order_relaxed);          // RY
+
+// Thread 2:
+y.store(0, memory_order_relaxed);          // SY2
+atomic_thread_fence(memory_order_seq_cst); // F3
+r2 = x.load(memory_order_relaxed);         // RX
+
          
+
+
          
+is the outcome r1 == 0 and r2 == 0 possible?
+
          
+
          
+I think the intent is that this is not possible, but I am not sure the
+wording guarantees that. Here is my analysis:
+
          
+
          
+Since all the fences are SC, there must be a total order between them.
+F1 must be before F2 in that order since they are in
+the same thread. Therefore F3 is either before F1,
+between F1 and F2 or after F2.
+
          
+
          
+If F3 is after F2, then we can apply 29.3 [atomics.order]p5 from
+N2798:
+
          
+
+
          
+For atomic operations A and B on an atomic object
+M, where A modifies M and B takes
+its value, if there are memory_order_seq_cst fences X
+and Y such that A is sequenced before X,
+Y is sequenced before B, and X precedes
+Y in S, then B observes either the effects of
+A or a later modification of M in its modification
+order.
+
          
+
+
          
+In this case, A is SX, B is RX, the
+fence X is F2 and the fence Y is F3,
+so RX must see 1.
+
          
+
          
+If F3 is before F2, this doesn't apply, but
+F3 can therefore be before or after F1.
+
          
+
          
+If F3 is after F1, the same logic applies, but this
+time the fence X is F1. Therefore again, RX
+must see 1.
+
          
+
          
+Finally we have the case that F3 is before F1
+in the SC ordering. There are now no guarantees about RX, and
+RX can see r2==0.
+
          
+
          
+We can apply 29.3 [atomics.order]p5 again. This time,
+A is SY2, B is RY, X is
+F3 and Y is F1. Thus RY must observe
+the effects of SY2 or a later modification of y in its
+modification order.
+
          
+
          
+Since SY1 is sequenced before RY, RY must
+observe the effects of SY1 or a later modification of
+y in its modification order.
+
          
+
          
+In order to ensure that RY sees (r1==1), we must see
+that SY1 is later in the modification order of y than
+SY2.
+
          
+
          
+We're now skating on thin ice. Conceptually, SY2 happens-before
+F3, F3 is SC-ordered before F1, F1
+happens-before SY1, so SY1 is later in the
+modification order M of y, and RY must see
+the result of SY1 (r1==1). However, I don't think the
+words are clear on that.
+
          
+
+
          [
+Post Summit Hans adds:
+]
          
+
+
+
          
+
          
+In my (Hans') view, our definition of fences will always be weaker than
+what particular hardware will guarantee.  Memory_order_seq_cst fences
+inherently don't guarantee sequential consistency anyway, for good
+reasons (e.g. because they can't enforce a total order on stores).
+ Hence I don't think the issue demonstrates a gross failure to achieve
+what we intended to achieve.  The example in question is a bit esoteric.
+ Hence, in my view, living with the status quo certainly wouldn't be a
+disaster either.
+
          
+
          
+In any case, we should probably add text along the lines of the
+following between p5 and p6 in 29.3 [atomics.order]:
+
          
+
          
+[Note: Memory_order_seq_cst only ensures sequential consistency for a
+data-race-free program that uses exclusively memory_order_seq_cst
+operations.  Any use of weaker ordering will invalidate this guarantee
+unless extreme care is used.  In particular, memory_order_seq_cst fences
+only ensure a total order for the fences themselves.  They cannot, in
+general, be used to restore sequential consistency for atomic operations
+with weaker ordering specifications.]
+
          
+
+
          
+Also see thread beginning at c++std-lib-23271.
+
          
+
+
          
+
+
          [
+Herve's correction:
+]
          
+
+
          
+
          
+Minor point, and sorry for the knee jerk reaction: I admit to having
+no knowledge of Memory_order_seq_cst, but my former boss (John Lakos)
+has ingrained an automatic introspection on the use of "only".   I
+think you meant:
+
          
+
+
          
+[Note: Memory_order_seq_cst ensures sequential consistency only
+for . . . .  In particular, memory_order_seq_cst fences ensure a
+total order only for . . .
+
          
+
          
+Unless, of course, Memory_order_seq_cst really do nothing but ensure
+sequential consistency for a data-race-free program that uses
+exclusively memory_order_seq_cst operations.
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+Add a new paragraph after 29.3 [atomics.order]p5 that says
+
          
+
+
          
+For atomic operations A and B on an atomic object
+M, where A and B modify M, if there
+are memory_order_seq_cst fences X and Y such
+that A is sequenced before X, Y is sequenced
+before B, and X precedes Y in S,
+then B occurs later than A in the modifiction order of
+M.
+
          
+
+
+
+
+
+
          
+
          927. Dereferenceable  should be HasDereference
          
+
          Section: 20.8.2.2 [allocator.concepts] Status: Tentatively NAD Editorial
+ Submitter: Pablo Halpern Opened: 2008-10-23  Last modified: 2009-05-23
          
+
          View all issues with Tentatively NAD Editorial status.
          
+
          Discussion:
          
+
          
+20.8.2.2 [allocator.concepts] contains a reference to a concept named
+Dereferenceable. No such concept exists.
+
          
+
+
          [
+Daniel adds 2009-02-14:
+]
          
+
+
+
          
+The proposal given in the paper
+N2829
+would automatically resolve this issue.
+
          
+
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+This particular set of changes has already been made.
+There are two related changes later on (and possibly also an earlier Example);
+these can be handled editorially.
+
          
+
          
+Move to NAD Editorial.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change all uses of the concept Dereferenceable to
+HasDereference in 20.8.2.2 [allocator.concepts].
+
          
+
+
+
+
+
+
          
+
          928. Wrong concepts used for tuple's comparison operators
          
+
          Section: 20.5.2.5 [tuple.rel] Status: Tentatively Ready
+ Submitter: Joe Gottman Opened: 2008-10-28  Last modified: 2009-03-09
          
+
          View all other issues in [tuple.rel].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+In the latest working draft for C++0x, tuple's operator== and operator<
+are declared as 
+
          
+
+
          template<class... TTypes, class... UTypes> 
+  requires EqualityComparable<TTypes, UTypes>... 
+  bool operator==(const tuple<TTypes...>& t, const tuple<UTypes...>& u);
+
          
+
+
          
+and
+
          
+
+
          template<class... TTypes, class... UTypes> 
+  requires LessThanComparable<TTypes, UTypes>... 
+  bool operator<(const tuple<TTypes...>& t, const tuple<UTypes...>& u);
+
          
+
+
          
+But the concepts EqualityComparable and LessThanComparable only take one 
+parameter, not two.  Also, even if LessThanComparable could take two 
+parameters, the definition of tuple::operator<() should also require 
+
          
+
+
          LessThanComparable<UTypes, TTypes>... // (note the order) 
+
          
+
+
          
+since the algorithm for tuple::operator< is the following (pseudo-code)
+
          
+
+
          for (size_t N = 0; N < sizeof...(TTypes); ++N) { 
+    if (get<N>(t) < get<N>(u) return true; 
+    else if ((get<N>(u) < get<N>(t)) return false; 
+} 
+
+return false; 
+
          
+
+
          
+Similar problems hold for tuples's other comparison operators.
+
          
+
+
          [
+Post Summit:
+]
          
+
+
+
          
+Recommend Tentatively Ready.
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+In 20.5.1 [tuple.general] and 20.5.2.5 [tuple.rel] change:
+
          
+
+
          template<class... TTypes, class... UTypes>
+  requires EqualityComparableHasEqualTo<TTypes, UTypes>...
+  bool operator==(const tuple<TTypes...>&, const tuple<UTypes...>&);
+
+template<class... TTypes, class... UTypes>
+  requires LessThanComparableHasLess<TTypes, UTypes>... && HasLess<UTypes, TTypes>...
+  bool operator<(const tuple<TTypes...>&, const tuple<UTypes...>&);
+
+template<class... TTypes, class... UTypes>
+  requires EqualityComparableHasEqualTo<TTypes, UTypes>...
+  bool operator!=(const tuple<TTypes...>&, const tuple<UTypes...>&);
+
+template<class... TTypes, class... UTypes>
+  requires LessThanComparableHasLess<UTTypes, TUTypes>... && HasLess<UTypes, TTypes>...
+  bool operator>(const tuple<TTypes...>&, const tuple<UTypes...>&);
+
+template<class... TTypes, class... UTypes>
+  requires LessThanComparableHasLess<UTTypes, TUTypes>... && HasLess<UTypes, TTypes>...
+  bool operator<=(const tuple<TTypes...>&, const tuple<UTypes...>&);
+
+template<class... TTypes, class... UTypes>
+  requires LessThanComparableHasLess<TTypes, UTypes>... && HasLess<UTypes, TTypes>...
+  bool operator>=(const tuple<TTypes...>&, const tuple<UTypes...>&);
+
          
+
+
+
+
+
+
          
+
          929. Thread constructor
          
+
          Section: 30.3.1.2 [thread.thread.constr] Status: Review
+ Submitter: Anthony Williams Opened: 2008-10-23  Last modified: 2009-05-23
          
+
          View other active issues in [thread.thread.constr].
          
+
          View all other issues in [thread.thread.constr].
          
+
          View all issues with Review status.
          
+
          Discussion:
          
+
+
          Addresses UK 323
          
+
+
          
+The thread constructor for starting a new thread with a function and
+arguments is overly constrained by the signature requiring rvalue
+references for func and args and the CopyConstructible requirements
+for the elements of args. The use of an rvalue reference for the
+function restricts the potential use of a plain function name, since
+the type of the bound parameter will be deduced to be a function
+reference and decay to pointer-to-function will not happen. This
+therefore complicates the implementation in order to handle a simple
+case. Furthermore, the use of rvalue references for args prevents the
+array to pointer decay. Since arrays are not CopyConstructible or even
+MoveConstructible, this essentially prevents the passing of arrays as
+parameters. In particular it prevents the passing of string literals.
+Consequently a simple case such as
+
          
+
+
          void f(const char*);
+std::thread t(f,"hello");
+
          
+
+
          
+is ill-formed since the type of the string literal is const char[6].
+
          
+
+
          
+By changing the signature to take all parameters by value we can
+eliminate the CopyConstructible requirement and permit the use of
+arrays, as the parameter passing semantics will cause the necessary
+array-to-pointer decay. They will also cause the function name to
+decay to a pointer to function and allow the implementation to handle
+functions and function objects identically.
+
          
+
+
          
+The new signature of the thread constructor for a function and
+arguments is thus:
+
          
+
+
          template<typename F,typename... Args>
+thread(F,Args... args);
+
          
+
+
          
+Since the parameter pack Args can be empty, the single-parameter
+constructor that takes just a function by value is now redundant.
+
          
+
+
          [
+Howard adds:
+]
          
+
+
+
          
+
          
+I agree with everything Anthony says in this issue.  However I believe we
+can optimize in such a way as to get the pass-by-value behavior with the
+pass-by-rvalue-ref performance.  The performance difference is that the latter
+removes a move when passing in an lvalue.
+
          
+
+
          
+This circumstance is very analogous to make_pair (20.3.3 [pairs])
+where we started with passing by const reference, changed to pass by value to
+get pointer decay, and then changed to pass by rvalue reference, but modified with
+decay<T> to retain the pass-by-value behavior.  If we were to
+apply the same solution here it would look like:
+
          
+
+
          template <class F> explicit thread(F f);
+template <class F, class ...Args> thread(F&& f, Args&&... args);
+
          
+
          
+
          
+-4- Requires: F and each Ti in Args shall be CopyConstructible
+if an lvalue and otherwise MoveConstructible.
+INVOKE(f, w1, w2, ..., wN) (20.7.2 [func.require]) shall be a valid expression for
+some values w1, w2, ... , wN, where N == sizeof...(Args).
+
          
+
          
+-5- Effects: Constructs an object of type thread
+and executes INVOKE(f, t1, t2, ..., tN) in a new
+thread of execution, where t1, t2, ..., tN are the values in args....
+Constructs
+the following objects in memory which is accessible to a new thread of execution
+as if:
+
          
+
          typename decay<F>::type g(std::forward<F>(f));
+tuple<typename decay<Args>::type...> w(std::forward<Args>(args)...);
+
          
+
          
+The new thread of
+execution executes INVOKE(g, wi...) where the wi... refers
+to the elements stored in the tuple w.
+Any return value from g is ignored.
+If f terminates with an uncaught exception, std::terminate() shall be called.
+If the evaluation of INVOKE(g,  wi...) terminates
+with an uncaught exception, std::terminate() shall be called [Note:
+std::terminate() could be called before entering g. -- end note]. Any
+exception thrown before the evaluation of INVOKE has started shall be
+catchable in the calling thread.
+
          
+
          
+
          
+
+
          
+Text referring to when terminate() is called was contributed by Ganesh.
+
          
+
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution,
+but would like the final sentence to be reworded
+since "catchable" is not a term of art (and is used nowhere else).
+
          
+
+
+
          Proposed resolution:
          
+
          
+Modify the class definition of std::thread in 30.3.1 [thread.thread.class] to remove the
+following signature:
+
          
+
+
          template<class F> explicit thread(F f);
+template<class F, class ... Args> explicit thread(F&& f, Args&& ... args);
+
          
+
+
          
+Modify 30.3.1.2 [thread.thread.constr] to replace the constructors prior to paragraph 4 with
+the single constructor as above. Replace paragraph 4 - 6 with the
+following:
+
          
+
+
          
+
          
+-4- Requires: F and each Ti in Args shall be CopyConstructible
+if an lvalue and otherwise MoveConstructible.
+INVOKE(f, w1, w2, ..., wN) (20.7.2 [func.require]) shall be a valid expression for
+some values w1, w2, ... , wN, where N == sizeof...(Args).
+
          
+
          
+-5- Effects: Constructs an object of type thread
+and executes INVOKE(f, t1, t2, ..., tN) in a new
+thread of execution, where t1, t2, ..., tN are the values in args....
+Constructs
+the following objects:
+
          
+
          typename decay<F>::type g(std::forward<F>(f));
+tuple<typename decay<Args>::type...> w(std::forward<Args>(args)...);
+
          
+
          
+and executes INVOKE(g, wi...) in a new thread of execution.
+These objects shall be destroyed when the new thread of execution completes.
+Any return value from g is ignored.
+If f terminates with an uncaught exception, std::terminate() shall be called.
+If the evaluation of INVOKE(g,  wi...) terminates
+with an uncaught exception, std::terminate() shall be called [Note:
+std::terminate() could be called before entering g. -- end note]. Any
+exception thrown before the evaluation of INVOKE has started shall be
+catchable in the calling thread.
+
          
+
          
+-6- Synchronization: The invocation of the constructor happens before the
+invocation of f g.
+
          
+
          
+
+
+
+
+
+
+
          
+
          930. Access to std::array data as built-in array type
          
+
          Section: 23.3.1 [array] Status: Open
+ Submitter: Niels Dekker Opened: 2008-11-17  Last modified: 2009-06-01
          
+
          View other active issues in [array].
          
+
          View all other issues in [array].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          
+The Working Draft (N2798) allows access to the elements of
+std::array by its data() member function:
+
          
+
+
          
+
+
          23.2.1.4 array::data [array.data]
          
+
           T *data();
+ const T *data() const;
+
          
+
          1. 
+ Returns: elems.
+
          
+
          
+
+
          
+Unfortunately, the result of std::array::data() cannot be bound
+to a reference to a built-in array of the type of array::elems.
+And std::array provides no other way to get a reference to
+array::elems. 
+This hampers the use of std::array, for example when trying to
+pass its data to a C style API function:
+
          
+
+
           // Some C style API function. 
+ void set_path( char (*)[MAX_PATH] );
+
+ std::array<char,MAX_PATH> path;
+ set_path( path.data() );  // error
+ set_path( &(path.data()) );  // error
+
          
+
+ 
          
+Another example, trying to pass the array data to an instance of another
+C++ class:
+
          
+
+
           // Represents a 3-D point in space.
+ class three_d_point {
+ public:
+   explicit three_d_point(const double (&)[3]); 
+ };
+
+ const std::array<double,3> coordinates = { 0, 1, 2 };
+ three_d_point point1( coordinates.data() );  // error.
+ three_d_point point2( *(coordinates.data()) );  // error.
+
          
+
+
          
+A user might be tempted to use std::array::elems instead, but
+doing so isn't recommended, because std::array::elems is "for
+exposition only".  Note that Boost.Array users might already use
+boost::array::elems, as its documentation doesn't explicitly
+state that boost::array::elems is for exposition only:
+http://www.boost.org/doc/libs/1_36_0/doc/html/boost/array.html
+
          
+
          
+I can think of three options to solve this issue:
+
          
+
          1. 
+Remove the words "exposition only" from the definition of
+std::array::elems, as well as the note saying that "elems is
+shown for exposition only."
+
          2. 
+Change the signature of std::array::data(), so that it would
+return a reference to the built-in array, instead of a pointer to its
+first element.
+
          3. 
+Add extra member functions, returning a reference to the built-in array.
+
          
+
          
+Lawrence Crowl wrote me that it might be better to leave
+std::array::elems "for exposition only", to allow alternate
+representations to allocate the array data dynamically.  This might be
+of interest to the embedded community, having to deal with very limited
+stack sizes.
+
          
+
          
+The second option, changing the return type of
+std::array::data(), would break backward compatible to current
+Boost and TR1 implementations, as well as to the other contiguous
+container (vector and string) in a very subtle way.
+For example, the following call to std::swap currently swap two
+locally declared pointers (data1, data2), for any container
+type T that has a data() member function. When
+std::array::data() is changed to return a reference, the
+std::swap call may swap the container elements instead.
+
          
+
+
           template <typename T>
+ void func(T& container1, T& container2)
+ {
+   // Are data1 and data2 pointers or references?
+   auto data1 = container1.data();
+   auto data2 = container2.data();
+
+   // Will this swap two local pointers, or all container elements?
+   std::swap(data1, data2);
+ }
+
          
+
+
          
+The following concept is currently satisfied by all contiguous
+containers, but it no longer is for std::array, when
+array::data()
+is changed to return a reference (tested on ConceptGCC Alpha 7):
+
          
+
+
           auto concept ContiguousContainerConcept<typename T>
+ {
+   typename value_type = typename T::value_type;
+   const value_type * T::data() const;
+ }
+
          
+
+
          
+Still it's worth considering having std::array::data() return a
+reference, because it might be the most intuitive option, from a user's
+point of view.  Nicolai Josuttis (who wrote boost::array)
+mailed me that he very much prefers this option.
+
          
+
          
+Note that for this option, the definition of data() would also
+need to be revised for zero-sized arrays, as its return type cannot be a
+reference to a zero-sized built-in array.  Regarding zero-sized array,
+data() could throw an exception.  Or there could be a partial
+specialization of std::array where data() returns
+T* or gets removed.
+
          
+
          
+Personally I prefer the third option, adding a new member function to
+std::array, overloaded for const and non-const access,
+returning a reference to the built-in array, to avoid those compatible
+issues. I'd propose naming the function std::array::c_array(),
+which sounds intuitive to me. Note that boost::array already
+has a c_array() member, returning a pointer, but Nicolai told
+me that this one is only there for historical reasons. (Otherwise a name
+like std::array::native_array() or
+std::array::builtin_array() would also be fine with me.) 
+According to my proposed resolution, a zero-sized std::array does not need
+to have c_array(), while it is still required to have
+data() functions.
+
          
+
+
          [
+Post Summit:
+]
          
+
+
+
          
+
+
          
+Alisdair: Don't like p4 suggesting implementation-defined behaviour.
+
          
+
          
+Walter: What about an explicit conversion operator, instead of adding
+the new member function?
+
          
+
          
+Alisdair: Noodling about:
+
          
+
          template<size_t N, ValueType T>
+struct array
+{
+  T elems[N];
+
+// fantasy code starts here
+
+// crazy decltype version for grins only
+//requires True<(N>0)>
+//explict operator decltype(elems) & () { return elems; }
+
+// conversion to lvalue ref
+requires True<(N>0)>
+explict operator T(&)[N] () & { return elems; }
+
+// conversion to const lvalue ref
+requires True<(N>0)>
+explict operator const T(&)[N] () const & { return elems; }
+
+// conversion to rvalue ref using ref qualifiers
+requires True<(N>0)>
+explict operator T(&&)[N] () && { return elems; }
+
+// fantasy code ends here
+
+explicit operator bool() { return true; }
+};
+
          
+
+
          
+This seems legal but odd. Jason Merrill says currently a CWG issue 613
+on the non-static data member that fixes the error that current G++
+gives for the non-explicit, non-conceptualized version of this. Verdict
+from human compiler: seems legal.
+
          
+
          
+Some grumbling about zero-sized arrays being allowed and supported.
+
          
+
          
+Walter: Would this address the issue? Are we inclined to go this route?
+
          
+
          
+Alan: What would usage look like?
+
          
+
          // 3-d point in space
+struct three_d_point
+{
+  explicit three_d_point(const double (&)[3]);
+};
+
+void sink(double*);
+
+const std::array<double, 3> coordinates = { 0, 1, 2 };
+three_d_point point1( coordinates.data() ); //error
+three_d_point point2( *(coordinates.data()) ); // error
+three_d_point point3( coordinates ); // yay!
+
+sink(cooridinates); // error, no conversion
+
          
+
+
          
+Recommended Open with new wording. Take the required clause and add the
+explicit conversion operators, not have a typedef. At issue still is use
+decltype or use T[N]. In favour of using T[N], even though use of
+decltype is specially clever.
+
          
+
+
          
+
+
          [
+Post Summit, further discussion in the thread starting with c++std-lib-23215.
+]
          
+
+
+
+
+
          Proposed resolution:
          
+
          
+Add to the template definition of array, 23.3.1 [array]/3:
+
          
+
+
          
+
          
+typedef T c_array_type[N];
+c_array_type & c_array() &;
+c_array_type && c_array() &&;
+const c_array_type & c_array() const &;
+
+
          
+
          
+
+
          
+Add the following subsection to 23.3.1 [array], after 23.3.1.4 [array.data]:
+
          
+
+
          
+
          23.2.1.5 array::c_array [array.c_array]
          
+    
          
+c_array_type & c_array() &;
+c_array_type && c_array() &&;
+const c_array_type & c_array() const &;
+
          
+
          
+
          
+Returns: elems.
+
          
+
          
+
+
          
+
+
          
+Add to Zero sized arrays 23.3.1.6 [array.zero]:
+
          
+
+
          
+4. The presence of c_array_type and c_array() and
+their semantics are implementation defined, for a zero-sized array.
+
          
+
+
+
+
+
+
          
+
          931. type trait extent<T, I>
          
+
          Section: 20.6.4.3 [meta.unary.prop] Status: Tentatively Ready
+ Submitter: Yechezkel Mett Opened: 2008-11-04  Last modified: 2009-03-09
          
+
          View other active issues in [meta.unary.prop].
          
+
          View all other issues in [meta.unary.prop].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+The draft (N2798) says in 20.6.4.3 [meta.unary.prop] Table 44: 
+
          
+
          
+
+
+
+
+
+
+
+
          Table 44 -- Type property queries
          TemplateValue
          
+template <class T, unsigned I = 0> struct extent;
+
+If T is not an array type (8.3.4), or if it has rank less than
+I, or if I is 0
+and T has type "array of unknown bound of U", then 0; otherwise, the
+size of the I'th dimension of T
+
          
+
          
+
+
          
+Firstly it isn't clear from the wording if I is 0-based or 1-based 
+("the I'th dimension" sort of implies 1-based). From the following 
+example it is clear that the intent is 0-based, in which case it 
+should say "or if it has rank less than or equal to I".
+
          
+
          
+Sanity check:
+
          
+
          
+The example says assert((extent<int[2], 1>::value) == 0);
+
          
+
          
+Here the rank is 1 and I is 1, but the desired result is 0.
+
          
+
+
          [
+Post Summit:
+]
          
+
+
+
          
+
          
+Do not use "size" or "value", use "bound". Also, move the
+cross-reference to 8.3.4 to just after "bound".
+
          
+
          
+Recommend Tentatively Ready.
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+In Table 44 of 20.6.4.3 [meta.unary.prop], third row, column "Value",
+change the cell content:
+
          
+
+
          
+
+
+
+
+
+
+
+
          Table 44 -- Type property queries
          TemplateValue
          
+template <class T, unsigned I = 0> struct extent;
+
+If T is not an array type (8.3.4), or if it has rank less than
+ or equal to I, or if I is 0
+and T has type "array of unknown bound of U", then 0; otherwise, the
+size bound (8.3.4) of the I'th dimension of T,
+where indexing of I is zero-based.
+
          
+
          
+
+
          [
+Wording supplied by Daniel.
+]
          
+
+
+
+
+
+
+
+
          
+
          932. unique_ptr(pointer p) for pointer deleter types
          
+
          Section: 20.8.12.2.1 [unique.ptr.single.ctor] Status: Tentatively Ready
+ Submitter: Howard Hinnant Opened: 2008-11-26  Last modified: 2009-03-12
          
+
          View other active issues in [unique.ptr.single.ctor].
          
+
          View all other issues in [unique.ptr.single.ctor].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
+
          Addresses US 79
          
+
+
          
+20.8.12.2.1 [unique.ptr.single.ctor]/5 no longer requires for D
+not to be a pointer type.  I believe this restriction was accidently removed
+when we relaxed the completeness reuqirements on T. The restriction
+needs to be put back in.  Otherwise we have a run time failure that could
+have been caught at compile time:
+
          
+
+
          {
+unique_ptr<int, void(*)(void*)> p1(malloc(sizeof(int)));  // should not compile
+}  // p1.~unique_ptr() dereferences a null function pointer
+unique_ptr<int, void(*)(void*)> p2(malloc(sizeof(int)), free);  // ok
+
          
+
+
          [
+Post Summit:
+]
          
+
+
+
          
+Recommend Tentatively Ready.
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+Change 20.8.12.2.1 [unique.ptr.single.ctor]/5:
+
          
+
+
          unique_ptr(pointer p);
+
          
+
          
+Requires: D shall not be a pointer type (diagnostic required).
+D shall be default constructible, and that construction shall not throw an exception.
+
          
+
          
+
+
+
+
+
+
          
+
          933. Unique_ptr defect
          
+
          Section: 20.8.12.2.5 [unique.ptr.single.modifiers] Status: Open
+ Submitter: Alisdair Meredith Opened: 2008-11-27  Last modified: 2009-05-23
          
+
          View other active issues in [unique.ptr.single.modifiers].
          
+
          View all other issues in [unique.ptr.single.modifiers].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+If we are supporting stateful deleters, we need an overload for
+reset that
+takes a deleter as well.
+
          
+
+
          void reset( pointer p, deleter_type d);
+
          
+
+
          
+We probably need two overloads to support move-only deleters, and
+this
+sounds uncomfortably like the two constructors I have been ignoring
+for
+now...
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Howard comments that we have the functionality via move-assigment.
+
          
+
          
+Move to Open.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
+
+
+
          
+
          934. duration is missing operator%
          
+
          Section: 20.9.3 [time.duration] Status: Tentatively Ready
+ Submitter: Terry Golubiewski Opened: 2008-11-30  Last modified: 2009-05-23
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
+
          Addresses US 81
          
+
+
          
+duration is missing operator%.  This operator is convenient
+for computing where in a time frame a given duration lies.  A
+motivating example is converting a duration into a "broken-down"
+time duration such as hours::minutes::seconds:
+
          
+
+
          class ClockTime
+{
+    typedef std::chrono::hours hours;
+    typedef std::chrono::minutes minutes;
+    typedef std::chrono::seconds seconds;
+public:
+    hours hours_;
+    minutes minutes_;
+    seconds seconds_;
+
+    template <class Rep, class Period>
+      explicit ClockTime(const std::chrono::duration<Rep, Period>& d)
+        : hours_  (std::chrono::duration_cast<hours>  (d)),
+          minutes_(std::chrono::duration_cast<minutes>(d % hours(1))),
+          seconds_(std::chrono::duration_cast<seconds>(d % minutes(1)))
+          {}
+};
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Agree except that there is a typo in the proposed resolution. The member
+operators should be operator%=.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Add to the synopsis in 20.9 [time]:
+
          
+
+
          template <class Rep1, class Period, class Rep2>
+  duration<typename common_type<Rep1, Rep2>::type, Period>
+  operator%(const duration<Rep1, Period>& d, const Rep2& s);
+template <class Rep1, class Period1, class Rep2, class Period2>
+  typename common_type<duration<Rep1, Period1>, duration<Rep2, Period2>>::type
+  operator%(const duration<Rep1, Period1>& lhs, const duration<Rep2, Period2>& rhs);
+
          
+
+
          
+Add to the synopsis of duration in 20.9.3 [time.duration]:
+
          
+
+
          template <class Rep, class Period = ratio<1>>
+class duration {
+public:
+  ...
+  duration& operator%=(const rep& rhs);
+  duration& operator%=(const duration& d);
+  ...
+};
+
          
+
+
          
+Add to 20.9.3.3 [time.duration.arithmetic]:
+
          
+
+
          
+
          duration& operator%=(const rep& rhs);
+
          
+
          
+
          
+Effects: rep_ %= rhs.
+
          
+
          
+Returns: *this.
+
          
+
          
+
+
          duration& operator%=(const duration& d);
+
          
+
          
+
          
+Effects: rep_ %= d.count().
+
          
+
          
+Returns: *this.
+
          
+
          
+
          
+
+
          
+Add to 20.9.3.5 [time.duration.nonmember]:
+
          
+
+
          
+
+
          template <class Rep1, class Period, class Rep2>
+  duration<typename common_type<Rep1, Rep2>::type, Period>
+  operator%(const duration<Rep1, Period>& d, const Rep2& s);
+
          
+
          
+
          
+Requires: Rep2 shall be implicitly convertible to CR(Rep1, Rep2) and
+Rep2 shall not be an instantiation of duration. Diagnostic required.
+
          
+
          
+Returns: duration<CR, Period>(d) %= s.
+
          
+
          
+
+
          template <class Rep1, class Period1, class Rep2, class Period2>
+  typename common_type<duration<Rep1, Period1>, duration<Rep2, Period2>>::type
+  operator%(const duration<Rep1, Period1>& lhs, const duration<Rep2, Period2>& rhs);
+
          
+
          
+
          
+Returns: common_type<duration<Rep1, Period1>, duration<Rep2, Period2>>::type(lhs) %= rhs.
+
          
+
          
+
+
          
+
+
+
+
+
+
+
          
+
          935. clock error handling needs to be specified
          
+
          Section: 20.9.5 [time.clock] Status: Open
+ Submitter: Beman Dawes Opened: 2008-11-24  Last modified: 2009-05-23
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+Each of the three clocks specified in Clocks 20.9.5 [time.clock]
+provides the member function:
+
          
+
+
          static time_point now();
+
          
+
+
          
+The semantics specified by Clock requirements 20.9.1 [time.clock.req]
+make no mention of error handling. Thus the function may throw bad_alloc
+or an implementation-defined exception (17.6.4.10 [res.on.exception.handling]
+paragraph 4).
+
          
+
+
          
+Some implementations of these functions on POSIX, Windows, and
+presumably on other operating systems, may fail in ways only detectable
+at runtime. Some failures on Windows are due to supporting chipset
+errata and can even occur after successful calls to a clock's now()
+function.
+
          
+
+
          
+These functions are used in cases where exceptions are not appropriate
+or where the specifics of the exception or cause of error need to be
+available to the user. See
+N2828,
+Library Support for hybrid error
+handling (Rev 1), for more specific discussion of use cases. Thus some change in
+the interface of now is required.
+
          
+
+
          
+The proposed resolution has been implemented in the Boost version of the
+chrono library. No problems were encountered.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We recommend this issue be deferred until the next Committee Draft
+has been issued and the prerequisite paper has been accepted.
+
          
+
          
+Move to Open.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+Accept the proposed wording of
+N2828,
+Library Support for hybrid error handling (Rev 1).
+
          
+
+
          
+Change Clock requirements 20.9.1 [time.clock.req] as indicated:
+
          
+
+
          
+
          
+-2- In Table 55 C1 and C2 denote clock types. t1 and
+t2 are values returned by C1::now() where the call 
+returning t1 happens before (1.10) the call returning t2 and
+both of these calls happen before C1::time_point::max().
+ec denotes an object of type error_code 
+(19.5.2.2 [syserr.errcode.overview]).
+
          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
          Table 55 -- Clock requirements
          ExpressionReturn typeOperational semantics
          .........
          C1::now()C1::time_pointReturns a time_point object representing the current point in time.
+
          C1::now(ec)C1::time_pointReturns a time_point object representing the current point in time.
+
          
+
          
+
+
          
+Change Class system_clock 20.9.5.1 [time.clock.system] as indicated:
+
          
+
+
          static time_point now(error_code& ec=throws());
+
          
+
+
          
+Change Class monotonic_clock 20.9.5.2 [time.clock.monotonic] as indicated:
+
          
+
+
          static time_point now(error_code& ec=throws());
+
          
+
+
          
+Change Class high_resolution_clock 20.9.5.3 [time.clock.hires] as indicated:
+
          
+
+
          static time_point now(error_code& ec=throws());
+
          
+
+
+
+
+
+
+
          
+
          936. Mutex type overspecified
          
+
          Section: 30.4.1 [thread.mutex.requirements] Status: Open
+ Submitter: Pete Becker Opened: 2008-12-05  Last modified: 2009-03-22
          
+
          View other active issues in [thread.mutex.requirements].
          
+
          View all other issues in [thread.mutex.requirements].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+30.4.1 [thread.mutex.requirements] describes the requirements for a type to be
+a "Mutex type". A Mutex type can be used as the template argument for
+the Lock type that's passed to condition_variable_any::wait (although
+Lock seems like the wrong name here, since Lock is given a different
+formal meaning in 30.4.3 [thread.lock]) and, although the WD doesn't quite say
+so, as the template argument for lock_guard and unique_lock.
+
          
+
+
          
+The requirements for a Mutex type include:
+
          
+
+
            
+
          • 
+m.lock() shall be well-formed and have [described] semantics, including a return type of void.
+
            • 
+
          • 
+m.try_lock() shall be well-formed and have [described] semantics, including a return type of bool.
+
            • 
+
          • 
+m.unlock() shall be well-formed and have [described] semantics, including a return type of void.
+
            • 
+
          
+
+
          
+Also, a Mutex type "shall not be copyable nor movable".
+
          
+
+
          
+The latter requirement seems completely irrelevant, and the three
+requirements on return types are tighter than they need to be. For
+example, there's no reason that lock_guard can't be instantiated with a
+type that's copyable. The rule is, in fact, that lock_guard, etc. won't
+try to copy objects of that type. That's a constraint on locks, not on
+mutexes. Similarly, the requirements for void return types are
+unnecessary; the rule is, in fact, that lock_guard, etc. won't use any
+returned value. And with the return type of bool, the requirement should
+be that the return type is convertible to bool.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+
          
+Move to open. Related to conceptualization and should probably be tackled as part of that.
+
          
+
            
+
          • 
+The intention is not only to place a constraint on what types such as
+lock_guard may do with mutex types, but on what any code, including user
+code, may do with mutex types. Thus the constraints as they are apply to
+the mutex types themselves, not the current users of mutex types in the
+standard.
+
            • 
+
          • 
+This is a low priority issue; the wording as it is may be overly
+restrictive but this may not be a real issue.
+
            • 
+
          
+
          
+
+
          [
+Post Summit Anthony adds:
+]
          
+
+
+
          
+
          
+Section 30.4.1 [thread.mutex.requirements] conflates the
+requirements on a generic Mutex type (including user-supplied mutexes)
+with the requirements placed on the standard-supplied mutex types in an
+attempt to group everything together and save space.
+
          
+
          
+When applying concepts to chapter 30, I suggest that the concepts
+Lockable and TimedLockable embody the requirements for
+*use* of a mutex type as required by
+unique_lock/lock_guard/condition_variable_any. These should be
+relaxed as Pete describes in the issue. The existing words in 30.4.1 [thread.mutex.requirements] are requirements on all of
+std::mutex, std::timed_mutex,
+std::recursive_mutex and std::recursive_timed_mutex,
+and should be rephrased as such.
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
+
+
+
          
+
          938. default_delete<T[]>::operator() should only accept T*
          
+
          Section: 20.8.12.1.2 [unique.ptr.dltr.dflt1] Status: Tentatively Ready
+ Submitter: Howard Hinnant Opened: 2008-12-07  Last modified: 2009-05-23
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+Consider:
+
          
+
+
          derived* p = new derived[3];
+std::default_delete<base[]> d;
+d(p);  // should fail
+
          
+
+
          
+Currently the marked line is a run time failure.  We can make it a compile
+time failure by "poisoning" op(U*).
+
          
+
+
          [
+Post Summit:
+]
          
+
+
+
          
+Recommend Review.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Add to 20.8.12.1.2 [unique.ptr.dltr.dflt1]:
+
          
+
+
          namespace std {
+  template <class T> struct default_delete<T[]> {
+    void operator()(T*) const;
+  template <class U> void operator()(U*) const = delete;
+};
+}
+
          
+
+
+
+
+
+
          
+
          939. Problem with std::identity and reference-to-temporaries
          
+
          Section: 20.7.6 [identity.operation] Status: Review
+ Submitter: Alisdair Meredith Opened: 2008-12-11  Last modified: 2009-06-02
          
+
          View all issues with Review status.
          
+
          Discussion:
          
+
          
+std::identity takes an argument of type T const &
+and returns a result of T const &.
+
          
+
          
+Unfortunately, this signature will accept a value of type other than T that
+is convertible-to-T, and then return a reference to the dead temporary.  The
+constraint in the concepts version simply protects against returning
+reference-to-void.
+
          
+
          
+Solutions:
+
          
+
          
+
          
+i/  Return-by-value, potentially slicing bases and rejecting non-copyable
+types
+
          
+
          
+ii/ Provide an additional overload:
+
          
+
          template< typename T >
+template operator( U & ) = delete;
+
          
+
          
+This seems closer on intent, but moves beyond the original motivation for
+the operator, which is compatibility with existing (non-standard)
+implementations.
+
          
+
          
+iii/ Remove the operator() overload.  This restores the original definition
+of the identity, although now effectively a type_trait rather than part of
+the perfect forwarding protocol.
+
          
+
          
+iv/ Remove std::identity completely; its original reason to exist is
+replaced with the IdentityOf concept.
+
          
+
          
+
          
+My own preference is somewhere between (ii) and (iii) - although I stumbled
+over the issue with a specific application hoping for resolution (i)!
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We dislike options i and iii, and option ii seems like overkill.
+If we remove it (option iv), implementers can still provide it under a
+different name.
+
          
+
          
+Move to Open pending wording (from Alisdair) for option iv.
+
          
+
          
+
+
          [
+2009-05-23 Alisdair provided wording for option iv.
+]
          
+
+
+
+
+
          Proposed resolution:
          
+
          
+Strike 20.2.1 [concept.transform] p3:
+
          
+
+
          
+-4- Note: concept form of the identity type metafunction (20.7.6).
+
          
+
+
          
+Strike from 20.7 [function.objects] p2:
+
          
+
+
          // 20.7.6, identity operation:
+template <IdentityOf T> struct identity;
+
          
+
+
          
+Remove 20.7.6 [identity.operation] (whole subclause):
+
          
+
+
          
+
          template <IdentityOf T> struct identity {
+  typedef T type;
+
+  requires ReferentType<T>
+     const T& operator()(const T& x) const;
+};
+
+requires ReferentType<T>
+  const T& operator()(const T& x) const;
+
          
+
          
+-1-  Returns: x
+
          
+
          
+
+
+
+
+
+
+
          
+
          940. std::distance
          
+
          Section: 24.4 [iterator.operations] Status: Tentatively Ready
+ Submitter: Thomas Opened: 2008-12-14  Last modified: 2009-05-23
          
+
          View other active issues in [iterator.operations].
          
+
          View all other issues in [iterator.operations].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
+
          Addresses UK 270
          
+
+
          
+Regarding the std::distance - function, 24.4 [iterator.operations]
+/ 4 says:
+
          
+
          
+Returns the
+number of increments or decrements needed to get from first to last.
+
          
+
          
+This sentence is completely silent about the sign of the return value.
+24.4 [iterator.operations] / 1 gives more information about the
+underlying operations, but
+again no inferences about the sign can be made.
+Strictly speaking, that is taking that sentence literally, I think this
+sentence even implies a positive return value in all cases, as the
+number of increments or decrements is clearly a ratio scale variable,
+with a natural zero bound.
+
          
+
          
+Practically speaking, my implementations did what common sense and
+knowledge based on pointer arithmetic forecasts, namely a positive sign
+for increments (that is, going from first to last by operator++), and a
+negative sign for decrements (going from first to last by operator--).
+
          
+
          
+Here are my two questions:
+
          
+
          
+First, is that paragraph supposed to be interpreted in the way what I
+called 'common sense', that is negative sign for decrements ? I am
+fairly sure that's the supposed behavior, but a double-check here in
+this group can't hurt.
+
          
+
          
+Second, is the present wording (2003 standard version - no idea about
+the draft for the upcoming standard) worth an edit to make it a bit more
+sensible, to mention the sign of the return value explicitly ?
+
          
+
+
          [
+Daniel adds:
+]
          
+
+
+
          
+
          
+My first thought was that resolution 204 would already cover the
+issue report, but it seems that current normative wording is in
+contradiction to that resolution:
+
          
+
+
          
+Referring to
+N2798,
+24.4 [iterator.operations]/ p.4 says:
+
          
+
+
          
+Effects: Returns the number of increments or decrements needed to get
+from first to last.
+
          
+
+
          
+IMO the part " or decrements" is in contradiction to p. 5 which says
+
          
+
+
          
+Requires: last shall be reachable from first.
+
          
+
+
          
+because "reachable" is defined in 24.2 [iterator.concepts]/7 as
+
          
+
+
          
+An iterator j is called reachable from an iterator i if and only if
+there is a finite
+sequence of applications of the expression ++i that makes i == j.[..]
+
          
+
+
          
+Here is wording that would be consistent with this definition of "reachable":
+
          
+
+
          
+Change 24.4 [iterator.operations] p4 as follows:
+
          
+
+
          
+Effects: Returns the number of increments or decrements
+needed to get from first to last.
+
          
+
+
          
+
+
          
+Thomas adds more discussion and an alternative view point
+here.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+The proposed wording below was verbally agreed to.  Howard provided.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Pete reports that a recent similar change has been made
+for the advance() function.
+
          
+
          
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 24.4 [iterator.operations]:
+
          
+
+
          
+
          template <InputIterator Iter>
+  Iter::difference_type
+  distance(Iter first, Iter last);
+template <RandomAccessIterator Iter>
+  Iter::difference_type distance(Iter first, Iter last);
+
          
+
+
          
+
          
+-4- Effects: Returns the number of increments or decrements
+needed to get from first to last.
+
          
+
          
+-5- Requires: last shall be reachable from first.
+
          
+
          
+
+
          template <RandomAccessIterator Iter>
+  Iter::difference_type distance(Iter first, Iter last);
+
          
+
+
          
+
          
+-6- Effects: Returns the number of increments or decrements
+needed to get from first to last.
+
          
+
          
+-7- Requires: last shall be reachable from first
+or first shall be reachable from last.
+
          
+
          
+
+
+
          
+
+
+
+
+
+
+
          
+
          941. Ref-qualifiers for assignment operators
          
+
          Section: 17 [library] Status: Open
+ Submitter: Niels Dekker Opened: 2008-12-18  Last modified: 2009-05-23
          
+
          View other active issues in [library].
          
+
          View all other issues in [library].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+The assignment and equality operators = and == are easily confused, just
+because of their visual similarity, and in this case a simple typo can cause
+a serious bug. When the left side of an operator= is an rvalue, it's
+highly unlikely that the assignment was intended by the programmer:
+
          
+
          if ( func() = value )  // Typical typo: == intended!
+
          
+
          
+Built-in types don't support assignment to an rvalue, but unfortunately,
+a lot of types provided by the Standard Library do.
+
          
+
          
+Fortunately the language now offers a syntax to prevent a certain member
+function from having an rvalue as *this: by adding a ref-qualifier (&)
+to the member function declaration.  Assignment operators are explicitly
+mentioned as a use case of ref-qualifiers, in "Extending Move Semantics
+To *this (Revision 1)",
+N1821 by Daveed
+Vandevoorde and Bronek Kozicki
+
          
+
          
+Hereby I would like to propose adding ref-qualifiers to all appropriate
+assignment operators in the library.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+Move to Open.
+We recommend this be deferred until after the next Committee Draft.
+
          
+
+
+
          Proposed resolution:
          
+
          
+A proposed resolution is provided by the paper on this subject,
+N2819,
+Ref-qualifiers for assignment operators of the Standard Library
+
          
+
+
+
+
+
+
          
+
          943. ssize_t undefined
          
+
          Section: 29.5.2 [atomics.types.address] Status: Tentatively Ready
+ Submitter: Holger Grund Opened: 2008-12-19  Last modified: 2009-05-23
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+There is a row in "Table 122 - Atomics for standard typedef types"
+in 29.5.1 [atomics.types.integral] with atomic_ssize_t
+and ssize_t. Unless, I'm missing something ssize_t
+is not defined by the standard.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Move to review. Proposed resolution: Remove the typedef. Note: ssize_t
+is a POSIX type.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Remove the row containing ssize_t from Table 119
+"Atomics for standard typedef types" in 29.5.2 [atomics.types.address].
+
          
+
+
+
+
+
+
          
+
          944. atomic<bool> derive from atomic_bool?
          
+
          Section: 29.5.3 [atomics.types.generic] Status: Open
+ Submitter: Holger Grund Opened: 2008-12-19  Last modified: 2009-03-22
          
+
          View all other issues in [atomics.types.generic].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+I think it's fairly obvious that atomic<bool> is supposed to be derived
+from atomic_bool (and otherwise follow the atomic<integral> interface),
+though I think the current wording doesn't support this. I raised this
+point along with atomic<floating-point> privately with Herb and I seem
+to recall it came up in the resulting discussion on this list. However,
+I don't see anything on the current libs issue list mentioning this
+problem.
+
          
+
+
          
+29.5.3 [atomics.types.generic]/3 reads
+
          
+
+
          
+There are full specializations over the integral types on the atomic
+class template. For each integral type integral in the second column of
+table 121 or table 122, the specialization atomic<integral> shall be
+publicly derived from the corresponding atomic integral type in the
+first column of the table. These specializations shall have trivial
+default constructors and trivial destructors.
+
          
+
+
          
+Table 121 does not include (atomic_bool, bool),
+so that this should probably be mentioned explicitly in the quoted paragraph.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Move to open. Lawrence will draft a proposed resolution. Also, ask
+Howard to fix the title.
+
          
+
+
          [
+Post Summit Anthony provided proposed wording.
+]
          
+
+
+
+
          Proposed resolution:
          
+
          
+Replace paragraph 3 in 29.5.3 [atomics.types.generic] with
+
          
+
+
          
+-3- There are full specializations over the integral types on the atomic
+class template. For each integral type integral in the second column of
+table 121 or table 122, the specialization atomic<integral> shall be
+publicly derived from the corresponding atomic integral type in the first
+column of the table.
+In addition, the specialization atomic<bool>
+shall be publicly derived from atomic_bool.
+These specializations shall have trivial default
+constructors and trivial destructors.
+
          
+
+
+
+
+
+
          
+
          945. system_clock::rep not specified
          
+
          Section: 20.9.5.1 [time.clock.system] Status: Tentatively NAD Editorial
+ Submitter: Pete Becker Opened: 2008-12-19  Last modified: 2009-05-23
          
+
          View other active issues in [time.clock.system].
          
+
          View all other issues in [time.clock.system].
          
+
          View all issues with Tentatively NAD Editorial status.
          
+
          Discussion:
          
+
          
+In 20.9.5.1 [time.clock.system], the declaration of system_clock::rep says "see
+below", but there is nothing below that describes it.
+
          
+
+
          [
+Howard adds:
+]
          
+
+
+
          
+
          
+This note refers to:
+
          
+
+
          
+-2- system_clock::duration::min() < system_clock::duration::zero() shall be true.
+
          
+
+
          
+I.e. this is standardeze for "system_clock::rep is signed".
+Perhaps an editorial note along the lines of:
+
          
+
+
          
+-2- system_clock::duration::min() < system_clock::duration::zero()
+shall be true. [Note: system_clock::rep shall be signed. -- end note].
+
          
+
+
          
+?
+
          
+
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the direction of the proposed resolution.
+Move to NAD Editorial.
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+Add a note to 20.9.5.1 [time.clock.system], p2:
+
          
+
          
+-2- system_clock::duration::min() < system_clock::duration::zero()
+shall be true. [Note: system_clock::rep shall be signed. -- end note].
+
          
+
+
+
+
+
+
          
+
          946. duration_cast improperly specified
          
+
          Section: 20.9.3.7 [time.duration.cast] Status: Tentatively NAD
+ Submitter: Pete Becker Opened: 2008-12-20  Last modified: 2009-05-23
          
+
          View other active issues in [time.duration.cast].
          
+
          View all other issues in [time.duration.cast].
          
+
          View all issues with Tentatively NAD status.
          
+
          Discussion:
          
+20.9.3.7 [time.duration.cast]/3:
+
+
          
+.... All intermediate computations shall be
+carried out in the widest possible representation... .
+
          
+
+
          
+So ignoring
+floating-point types for the moment, all this arithmetic has to be done
+using the implementation's largest integral type, even if both arguments
+use int for their representation. This seems excessive. And it's not at
+all clear what this means if we don't ignore floating-point types.
+
          
+
+
          
+This issue is related to 952.
+
          
+
+
          [
+Howard adds:
+]
          
+
+
+
          
+
          
+The intent of this remark is that intermediate computations are carried out
+using:
+
          
+
+
          common_type<typename ToDuration::rep, Rep, intmax_t>::type
+
          
+
+
          
+The Remark was intended to be clarifying prose supporting the rather algorithmic description
+of the previous paragraph.  I'm open to suggestions.  Perhaps the entire paragraph
+3 (Remarks) would be better dropped?
+
          
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We view this as a specific case of issue 952,
+and should be resolved when that issue is resolved.
+
          
+
          
+Move to NAD.
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
+
+
+
          
+
          947. duration arithmetic: contradictory requirements
          
+
          Section: 20.9.3.5 [time.duration.nonmember] Status: Open
+ Submitter: Pete Becker Opened: 2008-12-20  Last modified: 2009-05-23
          
+
          View all other issues in [time.duration.nonmember].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+In 20.9.3.5 [time.duration.nonmember], paragraph 8 says that calling
+dur / rep
+when rep is an instantiation of duration requires a diagnostic.
+That's followed by an operator/ that takes two durations.
+So dur1 / dur2 is legal under the second version,
+but requires a diagnostic under the first.
+
          
+
+
          [
+Howard adds:
+]
          
+
+
+
          
+Please see the thread starting with c++std-lib-22980 for more information.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+Move to Open, pending proposed wording (and preferably an implementation).
+
          
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
+
+
+
          
+
          948. ratio arithmetic tweak
          
+
          Section: 20.4.2 [ratio.arithmetic] Status: Tentatively Ready
+ Submitter: Howard Hinnant Opened: 2008-12-26  Last modified: 2009-03-09
          
+
          View other active issues in [ratio.arithmetic].
          
+
          View all other issues in [ratio.arithmetic].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+N2800,
+20.4.2 [ratio.arithmetic] lacks a paragraph from the proposal
+N2661:
+
          
+
+
          
+
          ratio arithmetic [ratio.arithmetic]
          
+
+
          
+... If the implementation is unable to form the indicated ratio due to
+overflow, a diagnostic shall be issued.
+
          
+
          
+
+
          
+The lack of a diagnostic on compile-time overflow is a significant lack of
+functionality.  This paragraph could be put back into the WP simply editorially.
+However in forming this issue I realized that we can do better than that.  This
+paragraph should also allow alternative formulations which go to extra lengths
+to avoid overflow when possible.  I.e. we should not mandate overflow when the
+implementation can avoid it.
+
          
+
+
          
+For example:
+
          
+
+
          
+
          template <class R1, class R2> struct ratio_multiply {
+  typedef see below} type; 
+
          
+
+
          
+The nested typedef type shall be a synonym for ratio<T1, T2> where
+T1 has the value R1::num * R2::num and T2 has the
+value R1::den * R2::den.
+
          
+
+
          
+
+
          
+Consider the case where intmax_t is a 64 bit 2's complement signed integer,
+and we have:
+
          
+
+
          typedef std::ratio<0x7FFFFFFFFFFFFFFF, 0x7FFFFFFFFFFFFFF0> R1;
+typedef std::ratio<8, 7> R2;
+typedef std::ratio_multiply<R1, R2>::type RT;
+
          
+
+
          
+According to the present formulation the implementaiton will multiply
+0x7FFFFFFFFFFFFFFF * 8 which will result in an overflow and subsequently
+require a diagnostic.
+
          
+
+
          
+However if the implementation is first allowed to divde 0x7FFFFFFFFFFFFFFF
+by 7 obtaining 0x1249249249249249 / 1 and divide
+8 by 0x7FFFFFFFFFFFFFF0 obtaining 1 / 0x0FFFFFFFFFFFFFFE,
+then the exact result can then be computed without overflow:
+
          
+
+
          [0x7FFFFFFFFFFFFFFF/0x7FFFFFFFFFFFFFF0] * [8/7] = [0x1249249249249249/0x0FFFFFFFFFFFFFFE]
+
          
+
+
          
+Example implmentation which accomplishes this:
+
          
+
+
          template <class R1, class R2>
+struct ratio_multiply
+{
+private:
+    typedef ratio<R1::num, R2::den> _R3;
+    typedef ratio<R2::num, R1::den> _R4;
+public:
+    typedef ratio<__ll_mul<_R3::num, _R4::num>::value,
+                  __ll_mul<_R3::den, _R4::den>::value> type;
+};
+
          
+
+
          [
+Post Summit:
+]
          
+
+
+
          
+Recommend Tentatively Ready.
+
          
+
+
+
+
+
          Proposed resolution:
          
+
          
+Add a paragraph prior to p1 in 20.4.2 [ratio.arithmetic]:
+
          
+
+
          
+Implementations may use other algorithms to compute the indicated ratios to avoid overflow. 
+If overflow occurs, a diagnostic shall be issued.
+
          
+
+
+
+
+
+
          
+
          949. owner_less
          
+
          Section: 20.8.13.4 [util.smartptr.ownerless] Status: Tentatively Ready
+ Submitter: Thomas Plum Opened: 2008-12-30  Last modified: 2009-03-10
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+20.8.13.4 [util.smartptr.ownerless] (class template owner_less) says that 
+operator()(x,y) shall return x.before(y).
+
          
+
          
+However, shared_ptr and weak_ptr have an owner_before() but not a
+before(), and there's no base class to provide a missing before().
+
          
+
          
+Being that the class is named  owner_less , I'm guessing that
+"before()" should be "owner_before()", right?
+
          
+
+
          [
+Herve adds:
+]
          
+
+
+
          
+Agreed with the typo, it should be "shall return x.owner_before(y)".
+
          
+
+
          [
+Post Summit:
+]
          
+
+
+
          
+Recommend Tentatively Ready.
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+Change 20.8.13.4 [util.smartptr.ownerless] p2:
+
          
+
+
          
+-2- operator()(x,y) shall return
+x.owner_before(y). [Note: ...
+
          
+
+
+
+
+
+
          
+
          950. unique_ptr converting ctor shouldn't accept array form
          
+
          Section: 20.8.12.2.1 [unique.ptr.single.ctor] Status: Tentatively Ready
+ Submitter: Howard Hinnant Opened: 2009-01-07  Last modified: 2009-05-23
          
+
          View other active issues in [unique.ptr.single.ctor].
          
+
          View all other issues in [unique.ptr.single.ctor].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+unique_ptr's of array type should not convert to
+unique_ptr's which do not have an array type.
+
          
+
+
          struct Deleter
+{
+   void operator()(void*) {}
+};
+
+int main()
+{
+   unique_ptr<int[], Deleter> s;
+   unique_ptr<int, Deleter> s2(std::move(s));  // should not compile
+}
+
          
+
+
          [
+Post Summit:
+]
          
+
+
+
          
+
          
+Walter: Does the "diagnostic required" apply to both arms of the "and"?
+
          
+
          
+Tom Plum: suggest to break into several sentences
+
          
+
          
+Walter: suggest "comma" before the "and" in both places
+
          
+
          
+Recommend Review.
+
          
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+The post-Summit comments have been applied to the proposed resolution.
+We now agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 20.8.12.2.1 [unique.ptr.single.ctor]:
+
          
+
+
          
+
          template <class U, class E> unique_ptr(unique_ptr<U, E>&& u);
+
          
+
          
+
          
+-20- Requires: If D is not a reference type,
+construction of the deleter D from an rvalue of type E
+shall be well formed and shall not throw an exception. If D is
+a reference type, then E shall be the same type as D
+(diagnostic required). unique_ptr<U, E>::pointer shall be
+implicitly convertible to pointer (diagnostic required). U shall not be
+an array type (diagnostic required). [Note: These requirements
+imply that T and U are complete types. -- end note]
+
          
+
          
+
          
+
+
          
+Change 20.8.12.2.3 [unique.ptr.single.asgn]:
+
          
+
+
          
+
          template <class U, class E> unique_ptr& operator=(unique_ptr<U, E>&& u);
+
          
+
          
+
          
+-6- Requires: Assignment of the deleter D from an rvalue
+D shall not throw an exception. unique_ptr<U,
+E>::pointer shall be implicitly convertible to pointer
+(diagnostic required).  U shall not be an array type (diagnostic required).
+[Note: These requirements imply that T and U
+are complete types. -- end note]
+
          
+
          
+
          
+
+
+
+
+
+
+
          
+
          951. Various threading bugs #1
          
+
          Section: 20.9.2.1 [time.traits.is_fp] Status: Open
+ Submitter: Pete Becker Opened: 2009-01-07  Last modified: 2009-05-23
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          
+Related to 953.
+
          
+
+
          
+20.9.2.1 [time.traits.is_fp] says that the type Rep "is
+assumed to be ... a class emulating an integral type." What are the
+requirements for such a type?
+
          
+
          [
+2009-05-10 Howard adds:
+]
          
+
+
+
          
+IntegralLike.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+As with issue 953,
+we recommend this issue be addressed in the context of providing concepts for the entire thread header.
+
          
+
          
+We look forward to proposed wording.
+
          
+
          
+Move to Open.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
+
+
+
          
+
          952. Various threading bugs #2
          
+
          Section: 20.9.3.7 [time.duration.cast] Status: Tentatively NAD Editorial
+ Submitter: Pete Becker Opened: 2009-01-07  Last modified: 2009-05-23
          
+
          View other active issues in [time.duration.cast].
          
+
          View all other issues in [time.duration.cast].
          
+
          View all issues with Tentatively NAD Editorial status.
          
+
          Discussion:
          
+
          
+20.9.3.7 [time.duration.cast] specifies an implementation and imposes
+requirements in text (and the implementation doesn't satisfy all of the
+text requirements). Pick one.
+
          
+
+
          
+This issue is related to 946.
+
          
+
+
          [
+2009-05-10 Howard adds:
+]
          
+
+
+
          
+
          
+The Remarks paragraph is an English re-statement of the preceeding
+Returns clause.  It was meant to be clarifying and motivating, not
+confusing.  I'm not aware with how the Remarks contradicts the Returns clause
+but I'm ok with simply removing the Remarks.
+
          
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Pete suggests that this could be resolved
+by rephrasing the Remarks to Notes.
+
          
+
          
+Move to NAD Editorial.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
+
+
+
          
+
          953. Various threading bugs #3
          
+
          Section: 20.9.1 [time.clock.req] Status: Open
+ Submitter: Pete Becker Opened: 2009-01-07  Last modified: 2009-05-23
          
+
          View other active issues in [time.clock.req].
          
+
          View all other issues in [time.clock.req].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          
+Related to 951.
+
          
+
+
          
+20.9.1 [time.clock.req] says that a clock's rep member is "an
+arithmetic type or a class emulating an arithmetic type." What are the
+requirements for such a type?
+
          
+
+
          [
+2009-05-10 Howard adds:
+]
          
+
+
+
          
+This wording was aimed directly at the ArithmeticLike concept.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We recommend this issue be addressed in the context of providing concepts
+for the entire thread header.
+
          
+
          
+May resolve for now by specifying arithmetic types,
+and in future change to ArithmeticLike.
+However, Alisdair believes this is not feasible.
+
          
+
          
+Bill disagrees.
+
          
+
          
+We look forward to proposed wording.  Move to Open.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
+
+
+
          
+
          954. Various threading bugs #4
          
+
          Section: 20.9.1 [time.clock.req] Status: Open
+ Submitter: Pete Becker Opened: 2009-01-07  Last modified: 2009-05-30
          
+
          View other active issues in [time.clock.req].
          
+
          View all other issues in [time.clock.req].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+Table 55 -- Clock Requirements (in 20.9.1 [time.clock.req])
+
          
+
+
            
+
          1. 
+the requirements for C1::time_point require C1 and C2
+to "refer to the same epoch", but "epoch" is not defined.
+
            2. 
+
          2. 
+"Different clocks may share a time_point definition if it is
+valid to compare their time_points by comparing their
+respective durations." What does "valid" mean here? And, since
+C1::rep is "**THE** representation type of the native
+duration and time_point" (emphasis added), there
+doesn't seem to be much room for some other representation.
+
            3. 
+
          3. 
+C1::is_monotonic has type "const bool". The
+"const" should be removed.
+
            4. 
+
          4. 
+C1::period has type ratio. ratio isn't a type, 
+it's a template. What is the required type?
+
            5. 
+
          
+
+
          [
+2009-05-10 Howard adds:
+]
          
+
+
+
            
+
          1. 
+
            
+"epoch" is purposefully not defined beyond the common English
+definition.  The C standard
+also chose not to define epoch, though POSIX did.  I believe it is a strength
+of the C standard that epoch is not defined.  When it is known that two time_points
+refer to the same epoch, then a definition of the epoch is not needed to compare
+the two time_points, or subtract them.
+
            
+
            
+A time_point and a Clock implicitly refer to an (unspecified) epoch.
+The time_point represents an offset (duration) from an epoch.
+
            
+
            2. 
+
          2. 
+
            
+The sentence:
+
            
+
            
+Different clocks 
+may share a time_point
+definition if it is valid to 
+compare their time_points by 
+comparing their respective 
+durations.
+
            
+
+
            
+is redundant and could be removed.  I believe the sentence which follows the above:
+
            
+
+
            
+C1 and C2 shall refer to the same epoch.
+
            
+
+
            
+is sufficient.  If two clocks share the same epoch, then by definition, comparing
+their time_points is valid.
+
            
+
            3. 
+
          3. 
+is_monotonic is meant to never change (be const).  It is also
+desired that this value be usable in compile-time computation and branching.
+
            4. 
+
          4. 
+
            
+This should probably instead be worded:
+
            
+
            
+An instantiation of ratio.
+
            
+
            5. 
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Re (a): It is not clear to us whether "epoch" is a term of art.
+
          
+
          
+Re (b), (c), and (d):  We agree with Howard's comments,
+and would consider adding to (c) a static constexpr requirement.
+
          
+
          
+Move to Open pending proposed wording.
+
          
+
          
+
+
          [
+2009-05-25 Daniel adds:
+]
          
+
+
+
          
+In regards to (d) I suggest to say "a specialization of ratio" instead of
+"An instantiation of ratio". This seems to be the better matching standard
+core language term for this kind of entity.
+
          
+
+
          [
+2009-05-25 Ganesh adds:
+]
          
+
+
+
          
+
          
+Regarding (a), I found this paper on the ISO website using the term "epoch" consistently with the current wording:
+
          
+
+
          
+http://standards.iso.org/ittf/PubliclyAvailableStandards/C030811e_FILES/MAIN_C030811e/text/ISOIEC_18026E_TEMPORAL_CS.HTM
+
          
+
          
+which is part of ISO/IEC 18026 "Information technology -- Spatial Reference Model (SRM)".
+
          
+
          
+
+
+
+
+
          Proposed resolution:
          
+
            
+
          1. 
+
            
+Change 20.9.1 [time.clock.req] p1:
+
            
+
            
+-1- A clock is a bundle consisting of a native duration, a native time_point, and a function now() to get the 
+current time_point.  The origin of the clock's time_point is referred to as the clock's epoch as defined in 
+section 6.3 of ISO/IEC 18026.
+A clock shall meet the requirements in Table 45.
+
            
+
            2. 
+
          2. 
+
            
+Remove the sentence from the time_point row of the table "Clock Requirements":
+
            
+
+
+
+
+
+
+
+
            Clock requirements
            
+C1::time_point
+
+chrono::time_point<C1> or chrono::time_point<C2, C1::duration>
+
+The native time_point type of the clock.
+Different clocks may share a time_point definition if it is valid to compare their time_points by comparing their respective durations.
+C1 and C2 shall refer to the same epoch.
+
            
+
            3. 
+
          
+
            
+
          1. 
+
            
+Change the row starting with C1::period of the table "Clock Requirements":
+
            
+
+
+
+
+
+
+
+
            Clock requirements
            
+C1::period
+
+a specialization of ratio
+
+The tick period of the clock in seconds.
+
            
+
+
            2. 
+
          
+
+
+
+
+
+
          
+
          955. Various threading bugs #5
          
+
          Section: 20.9.1 [time.clock.req] Status: Open
+ Submitter: Pete Becker Opened: 2009-01-07  Last modified: 2009-06-07
          
+
          View other active issues in [time.clock.req].
          
+
          View all other issues in [time.clock.req].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+20.9.1 [time.clock.req] requires that a clock type have a member
+typedef named time_point that names an instantiation of the
+template time_point, and a member named duration that
+names an instantiation of the template duration. This mixing of
+levels is confusing. The typedef names should be different from the
+template names.
+
          
+
+
          [
+Post Summit, Anthony provided proposed wording.
+]
          
+
+
+
          [
+2009-05-04 Howard adds:
+]
          
+
+
+
          
+
          
+The reason that the typedef names were given the same name as the class templates
+was so that clients would not have to stop and think about whether they were
+using the clock's native time_point / duration or the class
+template directly.  In this case, one person's confusion is another person's
+encapsulation.  The detail that sometimes one is referring to the clock's
+native types, and sometimes one is referring to an independent type is
+purposefully "hidden" because it is supposed to be an unimportant
+detail.  It can be confusing to have to remember when to type duration
+and when to type duration_type, and there is no need to require the
+client to remember something like that.
+
          
+
+
          
+For example, here is code that I once wrote in testing out the usability of
+this facility:
+
          
+
+
          template <class Clock, class Duration>
+void do_until(const std::chrono::time_point<Clock, Duration>& t)
+{
+    typename Clock::time_point now = Clock::now();
+    if (t > now)
+    {
+        typedef typename std::common_type
+        <
+            Duration,
+            typename std::chrono::system_clock::duration
+        >::type CD;
+        typedef std::chrono::duration<double, std::nano> ID;
+
+        CD d = t - now;
+        ID us = duration_cast<ID>(d);
+        if (us < d)
+            ++us;
+        ...
+    }
+}
+
          
+
+
          
+I see no rationale to require the client to append _type to some
+of those declarations.  It seems overly burdensome on the author of do_until:
+
          
+
+
          template <class Clock, class Duration>
+void do_until(const std::chrono::time_point<Clock, Duration>& t)
+{
+    typename Clock::time_point_type now = Clock::now();
+    if (t > now)
+    {
+        typedef typename std::common_type
+        <
+            Duration,
+            typename std::chrono::system_clock::duration_type
+        >::type CD;
+        typedef std::chrono::duration<double, std::nano> ID;
+
+        CD d = t - now;
+        ID us = duration_cast<ID>(d);
+        if (us < d)
+            ++us;
+        ...
+    }
+}
+
          
+
+
          
+Additionally I'm fairly certain that this suggestion hasn't been implemented.
+If it had, it would have been discovered that it is incomplete.  time_point
+also has a nested type (purposefully) named duration.
+
          
+
          
+That is, the current proposed wording would put the WP into an inconsistent state.
+
          
+
          
+In contrast,
+the current WP has been implemented and I've received very favorable feedback
+from people using this interface in real-world code.
+
          
+
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Bill agrees that distinct names should be used for distinct kinds of entities.
+
          
+
          
+Walter would prefer not to suffix type names,
+especially for such well-understood terms as "duration".
+
          
+
          
+Howard reminds us that the proposed resolution is incomplete, per his comment
+in the issue.
+
          
+
          
+Move to Open.
+
          
+
          
+
+
          [
+2009-06-07 Howard adds:
+]
          
+
+
+
          
+
          
+Not meaning to be argumentative, but we have a decade of positive experience
+with the precedent of using the same name for the nested type as an external
+class representing an identical concept.
+
          
+
+
          template<class Category, class T, class Distance = ptrdiff_t,
+         class Pointer = T*, class Reference = T&>
+struct iterator
+{
+    ...
+};
+
+template <BidirectionalIterator Iter>
+class reverse_iterator
+{
+    ...
+};
+
+template <ValueType T, Allocator Alloc = allocator<T> >
+    requires NothrowDestructible<T>
+class list
+{
+public:
+    typedef implementation-defined     iterator;
+    ...
+    typedef reverse_iterator<iterator> reverse_iterator;
+    ...
+};
+
          
+
+
          
+I am aware of zero complaints regarding the use of iterator
+and reverse_iterator as nested types of the containers despite these
+names also having related meaning at namespace std scope.
+
          
+
+
          
+Would we really be doing programmers a favor by renaming these nested types?
+
          
+
+
          template <ValueType T, Allocator Alloc = allocator<T> >
+    requires NothrowDestructible<T>
+class list
+{
+public:
+    typedef implementation-defined     iterator_type;
+    ...
+    typedef reverse_iterator<iterator> reverse_iterator_type;
+    ...
+};
+
          
+
+
          
+I submit that such design contributes to needless verbosity which ends up
+reducing readability.
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+Change 20.9 [time]:
+
          
+
+
          ...
+template <class Clock, class Duration = typename Clock::duration_type> class time_point;
+...
+
          
+
+
          
+Change 20.9.1 [time.clock.req]:
+
          
+
+
          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
          Table 45 -- Clock requirements
          ExpressionReturn typeOperational semantics
          .........
          C1::duration_typechrono::duration<C1::rep, C1::period>The native duration type of the clock.
          C1::time_point_typechrono::time_point<C1> or chrono::time_point<C2, C1::duration_type<The native time_point type of the clock.   Different clocks may  share a time_point_type
+definition if it is valid to 
+compare their time_point_types by 
+comparing their respective 
+duration_types. C1 and C2 shall 
+refer to the same epoch.
          .........
          C1::now()C1::time_point_typeReturns a time_point_type object 
+representing the current point 
+in time.
+
          
+
          
+
+
          
+Change 20.9.5.1 [time.clock.system]:
+
          
+
+
          
+
          
+-1- Objects of class system_clock represent wall clock time from the system-wide realtime clock.
+
          
+
+
          class system_clock { 
+public: 
+  typedef see below rep; 
+  typedef ratio<unspecified, unspecified> period; 
+  typedef chrono::duration<rep, period> duration_type; 
+  typedef chrono::time_point<system_clock> time_point_type; 
+  static const bool is_monotonic = unspecified ; 
+
+  static time_point_type now(); 
+
+  // Map to C API 
+  static time_t to_time_t (const time_point_type& t); 
+  static time_point_type from_time_t(time_t t); 
+};
+
          
+
+
          
+-2- system_clock::duration_type::min() < system_clock::duration_type::zero() shall be true.
+
          
+
+
          time_t to_time_t(const time_point_type& t);
+
          
+
+
          
+-3- Returns: A time_t object that represents the same
+point in time as t when both values are truncated to the
+coarser of the precisions of time_t and time_point_type.
+
          
+
+
          time_point_type from_time_t(time_t t);
+
          
+
+
          
+-4- Returns: A time_point_type object that represents the same point
+in time as t when both values are truncated to the coarser of the
+precisions of time_t and time_point_type.
+
          
+
          
+
+
          
+Change 20.9.5.2 [time.clock.monotonic]:
+
          
+
+
          class monotonic_clock { 
+public: 
+  typedef unspecified                                rep; 
+  typedef ratio<unspecified , unspecified>           period; 
+  typedef chrono::duration<rep, period>              duration_type; 
+  typedef chrono::time_point<unspecified , duration_type> time_point_type; 
+  static const bool is_monotonic =                   true; 
+
+  static time_point_type now();
+};
+
          
+
+
          
+Change 20.9.5.3 [time.clock.hires]:
+
          
+
+
          class high_resolution_clock { 
+public: 
+  typedef unspecified                                rep; 
+  typedef ratio<unspecified , unspecified>           period; 
+  typedef chrono::duration<rep, period>              duration_type; 
+  typedef chrono::time_point<unspecified , duration_type> time_point_type; 
+  static const bool is_monotonic =                   true; 
+
+  static time_point_type now();
+};
+
          
+
+
+
+
+
+
+
          
+
          956. Various threading bugs #6
          
+
          Section: 20.9.1 [time.clock.req] Status: Open
+ Submitter: Pete Becker Opened: 2009-01-07  Last modified: 2009-05-23
          
+
          View other active issues in [time.clock.req].
          
+
          View all other issues in [time.clock.req].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+20.9.1 [time.clock.req] uses the word "native" in several places,
+but doesn't define it. What is a "native duration"?
+
          
+
+
          [
+2009-05-10 Howard adds:
+]
          
+
+
+
          
+The standard uses "native" in several places without defining it (e.g.
+2.14.3 [lex.ccon]).  It is meant to mean "that which is defined
+by the facility", or something along those lines.  In this case it refers
+to the nested time_point and duration types of the clock.
+Better wording is welcome.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+Move to Open pending proposed wording from Pete.
+
          
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
+
+
+
          
+
          957. Various threading bugs #7
          
+
          Section: 20.9.5.1 [time.clock.system] Status: Review
+ Submitter: Pete Becker Opened: 2009-01-07  Last modified: 2009-05-23
          
+
          View other active issues in [time.clock.system].
          
+
          View all other issues in [time.clock.system].
          
+
          View all issues with Review status.
          
+
          Discussion:
          
+
          
+20.9.5.1 [time.clock.system]: to_time_t is overspecified. It
+requires truncation, but should allow rounding. For example, suppose a
+system has a clock that gives times in milliseconds, but time() rounds
+those times to the nearest second. Then system_clock can't use any
+resolution finer than one second, because if it did, truncating times
+between half a second and a full second would produce the wrong time_t
+value.
+
          
+
+
          [
+Post Summit Anthony Williams provided proposed wording.
+]
          
+
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+Move to Review pending input from Howard. and other stakeholders.
+
          
+
+
          [
+2009-05-23 Howard adds:
+]
          
+
+
+
          
+I am in favor of the wording provided by Anthony.
+
          
+
+
+
          Proposed resolution:
          
+
          
+In 20.9.5.1 [time.clock.system] replace paragraphs 3 and 4 with:
+
          
+
+
          
+
          time_t to_time_t(const time_point& t);
+
          
+
          
+-3- Returns: A time_t object that represents the same
+point in time as t when both values are truncated
+restricted to the coarser of the precisions of
+time_t and time_point.  It is implementation
+defined whether values are rounded or truncated to the required
+precision.
+
          
+
+
          time_point from_time_t(time_t t);
+
          
+
          
+-4- Returns: A time_point object that represents the
+same point in time as t when both values are truncated
+restricted to the
+coarser of the precisions of time_t and time_point.
+It is implementation defined whether values are
+rounded or truncated to the required precision.
+
          
+
          
+
+
+
+
+
+
          
+
          958. Various threading bugs #8
          
+
          Section: 30.5.1 [thread.condition.condvar] Status: Open
+ Submitter: Pete Becker Opened: 2009-01-07  Last modified: 2009-03-22
          
+
          View other active issues in [thread.condition.condvar].
          
+
          View all other issues in [thread.condition.condvar].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+30.5.1 [thread.condition.condvar]: the specification for wait_for
+with no predicate has an effects clause that says it calls wait_until,
+and a returns clause that sets out in words how to determine the return
+value. Is this description of the return value subtly different from the
+description of the value returned by wait_until? Or should the effects
+clause and the returns clause be merged?
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Move to open. Associate with LWG 859 and any other monotonic-clock
+related issues.
+
          
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
+
+
+
          
+
          959. Various threading bugs #9
          
+
          Section: 30.5.1 [thread.condition.condvar] Status: Open
+ Submitter: Pete Becker Opened: 2009-01-07  Last modified: 2009-03-22
          
+
          View other active issues in [thread.condition.condvar].
          
+
          View all other issues in [thread.condition.condvar].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+30.5.1 [thread.condition.condvar]: condition_variable::wait_for
+is required to compute the absolute time by adding the duration value to
+chrono::monotonic_clock::now(), but monotonic_clock is not required to
+exist.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Move to open. Associate with LWG 859 and any other monotonic-clock
+related issues.
+
          
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
+
+
+
          
+
          960. Various threading bugs #10
          
+
          Section: 30.4.1 [thread.mutex.requirements] Status: Open
+ Submitter: Pete Becker Opened: 2009-01-07  Last modified: 2009-03-27
          
+
          View other active issues in [thread.mutex.requirements].
          
+
          View all other issues in [thread.mutex.requirements].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+30.4.1 [thread.mutex.requirements]: paragraph 4 is entitled
+"Error conditions", but according to 17.5.1.4 [structure.specifications], "Error
+conditions:" specifies "the error conditions for error codes reported by
+the function." It's not clear what this should mean when there is no
+function in sight.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Move to open.
+
          
+
+
          [
+Beman provided proposed wording.
+]
          
+
+
+
+
          Proposed resolution:
          
+
          
+Change 30.4.1 [thread.mutex.requirements] Mutex requirements,
+paragraph 4 as indicated:
+
          
+
+
          
+
          
+-4- Error conditions:
+The error conditions for error codes, if any, reported by member
+functions of type Mutex shall be:
+
          
+
            
+
          • 
+not_enough_memory -- if there is not enough memory to construct
+the mutex object.
+
            • 
+
          • 
+resource_unavailable_try_again -- if any native handle type
+manipulated is not available.
+
            • 
+
          • 
+operation_not_permitted -- if the thread does not have the
+necessary permission to change the state of the mutex object.
+
            • 
+
          • 
+device_or_resource_busy -- if any native handle type
+manipulated is already locked.
+
            • 
+
          • 
+invalid_argument -- if any native handle type manipulated as
+part of mutex construction is incorrect.
+
            • 
+
          
+
          
+
+
+
+
+
+
          
+
          961. Various threading bugs #11
          
+
          Section: 30.4.1 [thread.mutex.requirements] Status: Open
+ Submitter: Pete Becker Opened: 2009-01-07  Last modified: 2009-03-22
          
+
          View other active issues in [thread.mutex.requirements].
          
+
          View all other issues in [thread.mutex.requirements].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+30.4.1 [thread.mutex.requirements] describes required member
+functions of mutex types, and requires that they throw exceptions under
+certain circumstances. This is overspecified. User-defined types can
+abort on such errors without affecting the operation of templates
+supplied by standard-library.
+
          
+
+
          [
+Summit:
+]
          
+
+
          
+Move to open. Related to conceptualization and should probably be
+tackled as part of that.
+
          
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
+
+
+
          
+
          962. Various threading bugs #12
          
+
          Section: 30.4.3.2.2 [thread.lock.unique.locking] Status: Open
+ Submitter: Pete Becker Opened: 2009-01-07  Last modified: 2009-03-22
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+30.4.3.2.2 [thread.lock.unique.locking]:  unique_lock::lock is
+required to throw an object of type std::system_error "when the
+postcondition cannot be achieved." The postcondition is owns == true,
+and this is trivial to achieve. Presumably, the requirement is intended
+to mean something more than that.
+
          
+
+
          [
+Summit:
+]
          
+
+
          
+Move to open.
+
          
+
+
          [
+Beman has volunteered to provide proposed wording.
+]
          
+
+
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
+
+
+
          
+
          963. Various threading bugs #13
          
+
          Section: 30.3.1.5 [thread.thread.member] Status: Open
+ Submitter: Pete Becker Opened: 2009-01-07  Last modified: 2009-03-22
          
+
          View other active issues in [thread.thread.member].
          
+
          View all other issues in [thread.thread.member].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+30.3.1.5 [thread.thread.member]:  thread::detach is required to
+throw an exception if the thread is "not a detachable thread".
+"Detachable" is never defined.
+
          
+
+
          [
+Howard adds:
+]
          
+
+
+
          
+Due to a mistake on my part, 3 proposed resolutions appeared at approximately
+the same time.  They are all three noted below in the discussion.
+
          
+
+
          [
+Summit, proposed resolution:
+]
          
+
+
+
          
+
          
+In 30.3.1.5 [thread.thread.member] change:
+
          
+
+
          void detach();
+
          
+
          
+
          ...
          
+
          -14- Error conditions:
          
+
            
+
          • no_such_process --  if the thread is not a valid thread.
            • 
+
          • invalid_argument -- if the thread is not a detachable joinable thread.
            • 
+
          
+
          
+
+
          
+
+
          
+
+
          [
+Post Summit, Jonathan Wakely adds:
+]
          
+
+
+
          
+
          
+A thread is detachable if it is joinable. As we've defined joinable,
+we can just use that.
+
          
+
          
+This corresponds to the pthreads specification, where pthread_detach
+fails if the thread is not joinable:
+
          
+
          
+EINVAL: The  implementation  has  detected  that  the value specified by
+thread does not refer to a joinable thread.
+
          
+
          
+Jonathan recommends this proposed wording:
+
          
+
          
+
          
+In 30.3.1.5 [thread.thread.member] change:
+
          
+
+
          void detach();
+
          
+
          
+
          ...
          
+
          -14- Error conditions:
          
+
            
+
          • ...
            • 
+
          • invalid_argument -- not a detachable joinable thread.
            • 
+
          
+
          
+
+
          
+
          
+
          
+
+
          [
+Post Summit, Anthony Williams adds:
+]
          
+
+
+
          
+
          
+This is covered by the precondition that joinable() be true.
+
          
+
          
+Anthony recommends this proposed wording:
+
          
+
+
          
+
          
+In 30.3.1.5 [thread.thread.member] change:
+
          
+
+
          void detach();
+
          
+
          
+
          ...
          
+
          -14- Error conditions:
          
+
            
+
          • ...
            • 
+
          • invalid_argument -- not a detachable thread.
            • 
+
          
+
          
+
+
          
+
+
          
+
+
          
+
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          964. Various threading bugs #14
          
+
          Section: 30.5.2 [thread.condition.condvarany] Status: Open
+ Submitter: Pete Becker Opened: 2009-01-07  Last modified: 2009-03-22
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+The requirements for the constructor for condition_variable has several
+error conditions, but the requirements for the constructor for
+condition_variable_any has none. Is this difference intentional?
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Move to open, pass to Howard. If this is intentional, a note may be
+helpful. If the error conditions are to be copied from
+condition_variable, this depends on LWG 965.
+
          
+
+
          [
+Post Summit Howard adds:
+]
          
+
+
+
          
+The original intention 
+(N2447)
+was to let the OS return whatever errors it was going to return, and for
+those to be translated into exceptions, for both
+condition_variable and condition_variable_any.  I have not
+received any complaints about specific error conditions from vendors on
+non-POSIX platforms, but such complaints would not surprise me if they surfaced.
+
          
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          965. Various threading bugs #15
          
+
          Section: 30.5.1 [thread.condition.condvar] Status: Tentatively Ready
+ Submitter: Pete Becker Opened: 2009-01-07  Last modified: 2009-05-23
          
+
          View other active issues in [thread.condition.condvar].
          
+
          View all other issues in [thread.condition.condvar].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+30.5.1 [thread.condition.condvar]: the constructor for
+condition_variable throws an exception with error code
+device_or_resource_busy "if attempting to initialize a
+previously-initialized but as of yet undestroyed condition_variable."
+How can this occur?
+
          
+
+
          [
+Summit:
+]
          
+
+
          
+
          
+Move to review. Proposed resolution: strike the device_or_resource_busy
+error condition from the constructor of condition_variable.
+
          
+
            
+
          • 
+This is a POSIX error that cannot occur in this interface because the
+C++ interface does not separate declaration from initialization.
+
            • 
+
          
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 30.5.1 [thread.condition.condvar] p3:
+
          
+
+
          
+
            
+
          • ...
            • 
+
          • 
+device_or_resource_busy -- if attempting to initialize a
+previously-initialized but as of yet undestroyed
+condition_variable.
+
            • 
+
          
+
          
+
+
+
+
+
+
          
+
          966. Various threading bugs #16
          
+
          Section: 30.5.1 [thread.condition.condvar] Status: Open
+ Submitter: Pete Becker Opened: 2009-01-07  Last modified: 2009-03-22
          
+
          View other active issues in [thread.condition.condvar].
          
+
          View all other issues in [thread.condition.condvar].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+30.5.1 [thread.condition.condvar]: condition_variable::wait and
+condition_variable::wait_until both have a postcondition that lock is
+locked by the calling thread, and a throws clause that requires throwing
+an exception if this postcondition cannot be achieved. How can the
+implementation detect that this lock can never be obtained?
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Move to open. Requires wording. Agreed this is an issue, and the
+specification should not require detecting deadlocks.
+
          
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          967. Various threading bugs #17
          
+
          Section: 30.3.1.2 [thread.thread.constr] Status: Open
+ Submitter: Pete Becker Opened: 2009-01-07  Last modified: 2009-03-22
          
+
          View other active issues in [thread.thread.constr].
          
+
          View all other issues in [thread.thread.constr].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+the error handling for the constructor for condition_variable
+distinguishes lack of memory from lack of other resources, but the error
+handling for the thread constructor does not. Is this difference
+intentional?
+
          
+
+
          [
+Beman has volunteered to provide proposed wording.
+]
          
+
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
+
+
+
          
+
          968. Various threading bugs #18
          
+
          Section: 30.4.1 [thread.mutex.requirements] Status: Open
+ Submitter: Pete Becker Opened: 2009-01-07  Last modified: 2009-03-22
          
+
          View other active issues in [thread.mutex.requirements].
          
+
          View all other issues in [thread.mutex.requirements].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+30.4.1 [thread.mutex.requirements]: several functions are
+required to throw exceptions "if the thread does not have the necessary
+permission ...". "The necessary permission" is not defined.
+
          
+
+
          [
+Summit:
+]
          
+
+
          
+Move to open.
+
          
+
+
+
          [
+Beman has volunteered to provide proposed wording.
+]
          
+
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
+
+
+
          
+
          969. What happened to Library Issue 475?
          
+
          Section: 25.3.4 [alg.foreach] Status: Tentatively NAD Editorial
+ Submitter: Stephan T. Lavavej Opened: 2009-01-12  Last modified: 2009-05-23
          
+
          View other active issues in [alg.foreach].
          
+
          View all other issues in [alg.foreach].
          
+
          View all issues with Tentatively NAD Editorial status.
          
+
          Discussion:
          
+
          
+Library Issue 475 has CD1 status, but the non-normative note in
+N2723
+was removed in
+N2798
+(25.3.4 [alg.foreach] in both drafts).
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+Move to NAD Editorial.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Restore the non-normative note. It might need to be expressed in terms of concepts.
+
          
+
+
+
+
+
+
          
+
          970. addressof overload unneeded
          
+
          Section: 20.8.11.1 [object.addressof] Status: Tentatively Ready
+ Submitter: Howard Hinnant Opened: 2009-01-16  Last modified: 2009-05-23
          
+
          View other active issues in [object.addressof].
          
+
          View all other issues in [object.addressof].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+20.8.11.1 [object.addressof] specifies:
+
          
+
+
          template <ObjectType T> T* addressof(T& r);
+template <ObjectType T> T* addressof(T&& r);
+
          
+
+
          
+The two signatures are ambiguous when the argument is an lvalue.  The
+second signature seems not useful:  what does it mean to take the
+address of an rvalue?
+
          
+
+
          [
+Post Summit:
+]
          
+
+
+
          
+Recommend Review.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 20.8.11.1 [object.addressof]:
+
          
+
+
          template <ObjectType T> T* addressof(T& r);
+template <ObjectType T> T* addressof(T&& r);
+
          
+
+
+
+
+
+
+
          
+
          971. Spurious diagnostic conversion function
          
+
          Section: 19.5.2.6 [syserr.errcode.nonmembers] Status: Open
+ Submitter: Beman Dawes Opened: 2009-01-19  Last modified: 2009-05-23
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+Anthony Williams raised the question in c++std-lib-22987 "why is there
+std::make_error_code(std::errc)? What purpose does this serve?"
+
          
+
          
+The function make_error_code(errc e) is not required, since
+make_error_condition(errc e) is the function that is needed for errc
+conversions. make_error_code(errc e) appears to be a holdover from my
+initial confusion over the distinction between POSIX and operating
+systems that conform to the POSIX spec.
+
          
+
+
          [
+Post Summit:
+]
          
+
+
+
          
+Recommend Review.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+The designer of the facility (Christopher Kohlhoff)
+strongly disagrees that there is an issue here,
+and especially disagrees with the proposed resolution.
+Bill would prefer to be conservative and not apply this proposed resolution.
+Move to Open, and recommend strong consideration for NAD status.
+
          
+
+
          [
+2009-05-21 Beman adds:
+]
          
+
+
+
          
+My mistake. Christopher and Bill are correct and the issue should be
+NAD. The function is needed by users.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change System error support 19.5 [syserr], Header <system_error>
+synopsis, as indicated:
+
          
+
+
          error_code make_error_code(errc e);
+error_condition make_error_condition(errc e);
+
          
+
+
          
+Delete from Class error_code non-member functions
+19.5.2.6 [syserr.errcode.nonmembers]:
+
          
+
+
          error_code make_error_code(errc e);
+
          
+
          
+Returns: error_code(static_cast<int>(e),
+generic_category).
+
          
+
          
+
+
+
+
+
+
+
          
+
          972. The term "Assignable" undefined but still in use
          
+
          Section: 17 [library] Status: Tentatively NAD Editorial
+ Submitter: Niels Dekker Opened: 2009-01-07  Last modified: 2009-05-23
          
+
          View other active issues in [library].
          
+
          View all other issues in [library].
          
+
          View all issues with Tentatively NAD Editorial status.
          
+
          Discussion:
          
+
          
+Previous versions of the Draft had a table, defining the Assignable 
+requirement.  For example 
+N2134
+Table 79, "Assignable requirements". But I guess the term "Assignable" 
+is outdated by now, because the current Committee Draft provides 
+MoveAssignable, CopyAssignable, and TriviallyCopyAssignable concepts 
+instead. And as far as I can see, it no longer has a definition of 
+Assignable. (Please correct me if I'm wrong.) Still the word 
+"Assignable" is used in eight places in the Draft, 
+N2800.
+
          
+
+
          
+Are all of those instances of "Assignable" to be replaced by "CopyAssignable"? 
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+Move to NAD Editorial.
+
          
+
+
+
          Proposed resolution:
          
+
+
          
+Change Exception Propagation 18.8.5 [propagation]:
+
          
+
          
+exception_ptr shall be DefaultConstructible, CopyConstructible,
+CopyAssignable and EqualityComparable.
+
          
+
+
          
+Change Class template reference_wrapper 20.7.5 [refwrap]:
+
          
+
          
+reference_wrapper<T> is a CopyConstructible and CopyAssignable wrapper around a reference to an object of type T.
+
          
+
          
+Change Placeholders 20.7.12.1.4 [func.bind.place]:
+
          
+
          
+It is implementation defined whether placeholder types are CopyAssignable. CopyAssignable placeholders' copy assignment operators shall not throw exceptions.
+
          
+
          
+Change Class template shared_ptr 20.8.13.2 [util.smartptr.shared]:
+
          
+
          
+Specializations of shared_ptr shall be CopyConstructible, CopyAssignable, and LessThanComparable...
+
          
+
          
+Change Class template weak_ptr 20.8.13.3 [util.smartptr.weak]:
+
          
+
          
+Specializations of weak_ptr shall be CopyConstructible, CopyAssignable, and LessThanComparable...
+
          
+
          
+Change traits typedefs 21.2.2 [char.traits.typedefs] (note: including deletion of reference to 23.1!):
+
          
+
          
+Requires: state_type shall meet the requirements of CopyAssignable (23.1), CopyConstructible (20.1.8), and DefaultConstructible types.
+
          
+
          
+Change Class seed_seq 26.5.7.1 [rand.util.seedseq] (note again: including deletion of reference to 23.1!):
+
          
+
          
+In addition to the requirements set forth below, instances of
+seed_seq shall meet the requirements of CopyConstructible (20.1.8) and of CopyAssignable (23.1).
+
          
+
+
          
+Note: The proposed resolution of this issue does not deal with the
+instance of the term "Assignable" in D.9.1 [auto.ptr], as this is dealt
+with more specifically by LWG 973, "auto_ptr characteristics", submitted
+by Maarten Hilferink.
+
          
+
+
+
+
+
+
+
          
+
          973. auto_ptr characteristics
          
+
          Section: D.9.1 [auto.ptr] Status: Tentatively NAD Editorial
+ Submitter: Maarten Hilferink Opened: 2009-01-21  Last modified: 2009-05-23
          
+
          View other active issues in [auto.ptr].
          
+
          View all other issues in [auto.ptr].
          
+
          View all issues with Tentatively NAD Editorial status.
          
+
          Discussion:
          
+
          
+I think that the Note of D.9.1 [auto.ptr], paragraph 3 needs a rewrite 
+since "Assignable" is no longer defined as a concept. 
+The relationship of auto_ptr with the new CopyAssignable, MoveAssignable,
+ and MoveConstructible concepts should be clarified.
+Furthermore, since the use of auto_ptr is depreciated anyway,
+ we can also omit a description of its intended use.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the intent of the proposed resolution.
+Move to NAD Editorial.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change D.9.1 [auto.ptr], paragraph 3:
+
          
+
+
          
+The auto_ptr provides a semantics of strict ownership. An
+auto_ptr owns the ob ject it holds a pointer to. Copying an
+auto_ptr copies the pointer and transfers ownership to the
+destination. If more than one auto_ptr owns the same ob ject at
+the same time the behavior of the program is undefined. [Note:
+The uses of auto_ptr include providing temporary
+exception-safety for dynamically allocated memory, passing ownership of
+dynamically allocated memory to a function, and returning dynamically
+allocated memory from a function.
+auto_ptr does not meet the
+CopyConstructible and Assignable requirements for
+standard library container elements and thus instantiating a standard
+library container with an auto_ptr results in undefined
+behavior.
+
+Instances of auto_ptr shall
+meet the MoveConstructible and MoveAssignable
+requirements, but do not meet the CopyConstructible and
+CopyAssignable requirements.
+-- end note]
+
          
+
+
+
+
+
+
          
+
          974. duration<double> should not implicitly convert to duration<int>
          
+
          Section: 20.9.3.1 [time.duration.cons] Status: Tentatively Ready
+ Submitter: Howard Hinnant Opened: 2009-01-21  Last modified: 2009-05-23
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+The following code should not compile because it involves implicit truncation
+errors (against the design philosophy of the duration library).
+
          
+
+
          duration<double> d(3.5);
+duration<int> i = d;  // implicit truncation, should not compile
+
          
+
+
          
+This intent was codified in the example implementation which drove this proposal
+but I failed to accurately translate the code into the specification in this
+regard.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We agree with the proposed resolution.
+
          
+
          
+Move to Tentatively Ready.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 20.9.3.1 [time.duration.cons], p4:
+
          
+
+
          
+
          template <class Rep2, class Period2> 
+  duration(const duration<Rep2, Period2>& d);
+
          
+
          
+-4- Requires: treat_as_floating_point<rep>::value
+shall be true or both ratio_divide<Period2,
+period>::type::den shall be 1
+and treat_as_floating_point<Rep2>::value
+shall be false.
+Diagnostic required.
+[Note: This requirement prevents implicit truncation error when
+converting between integral-based duration types. Such a
+construction could easily lead to confusion about the value of the
+duration. -- end note]
+
          
+
          
+
+
+
+
+
+
          
+
          975. is_convertible cannot be instantiated for  non-convertible types
          
+
          Section: 20.6.5 [meta.rel] Status: Tentatively Ready
+ Submitter: Daniel Krügler Opened: 2009-01-25  Last modified: 2009-05-23
          
+
          View other active issues in [meta.rel].
          
+
          View all other issues in [meta.rel].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
+Addresses UK 206
+
+
          
+Related to 1114.
+
          
+
+
          
+The current specification of std::is_convertible (reference is draft
+N2798)
+is basically defined by 20.6.5 [meta.rel]/4:
+
          
+
+
          
+
          
+In order to instantiate the template is_convertible<From,
+To>, the following code shall be well formed:
+
          
+
+
          template <class T>
+  typename add_rvalue_reference<T>::type create();
+
+To test() {
+  return create<From>();
+}
+
          
+
+
          
+[Note: This requirement gives well defined results for reference
+types, void types, array types, and function types. --end note]
+
          
+
          
+
+
          
+The first sentence can be interpreted, that e.g. the expression
+
          
+
+
          std::is_convertible<double, int*>::value
+
          
+
+
          
+is ill-formed because std::is_convertible<double, int*> could not be
+instantiated, or in more general terms: The wording requires that
+std::is_convertible<X, Y> cannot be instantiated for otherwise valid
+argument types X and Y if X is not convertible to Y.
+
          
+
+
          
+This semantic is both unpractical and in contradiction to what the last type
+traits paper
+N2255
+proposed:
+
          
+
+
          
+
          
+If the following test function is well formed code b
+is true, else it is false.
+
          
+
+
          template <class T>
+  typename add_rvalue_reference<T>::type create();
+
+To test() {
+  return create<From>();
+}
+
          
+
+
          
+[Note: This definition gives well defined results for reference
+types, void types, array types, and function types. --end note]
+
          
+
          
+
+
          [
+Post Summit:
+]
          
+
+
+
          
+
          
+Jens: Checking that code is well-formed and then returning true/false
+sounds like speculative compilation. John Spicer would really dislike
+this. Please find another wording suggesting speculative compilation.
+
          
+
          
+Recommend Open.
+
          
+
          
+
+
          [
+Post Summit, Howard adds:
+]
          
+
+
+
          
+
          
+John finds the following wording clearer:
+
          
+
          
+
+
+
+
+
+
+
+
+
+
+
          TemplateConditionComments
          template <class From, class To>
          struct is_convertible;          		see belowFrom and To shall be complete types, arrays of unknown bound,
+or (possibly cv-qualified) void types.
          
+
+
          
+Given the following function prototype:
+
          
+
+
          template <class T>
+  typename add_rvalue_reference<T>::type create();
+
          
+
+
          
+is_convertible<From, To>::value shall be true if the
+return expression in the following code would be well-formed, including
+any implicit conversions to the return type of the function, else
+is_convertible<From, To>::value shall be false.
+
          
+
+
          To test() {
+  return create<From>();
+}
+
          
+
+
          
+
+
          
+
+Original proposed wording:
+
+
          
+In 20.6.5 [meta.rel]/4 change:
+
          
+
+
          
+In order to instantiate the template is_convertible<From, To>, the
+following code shall be well formed If the following code
+is well formed is_convertible<From, To>::value is true, otherwise
+false:[..]
+
          
+
+
          Revision 2
          
+
+
          
+
+
          
+In 20.6.5 [meta.rel] change:
+
          
+
+
          
+
+
+
+
+
+
+
+
+
+
+
+
          TemplateConditionComments
          .........
          template <class From, class To>
          struct is_convertible;          		
+The code set out below shall be well formed.
+see belowFrom and To shall be complete types, arrays of unknown bound,
+or (possibly cv-qualified) void types.
          
+
+
          
+-4- In order to instantiate the template is_convertible<From, To>, the
+following code shall be well formed:
+Given the following function prototype:
+
          
+
+
          template <class T> 
+  typename add_rvalue_reference<T>::type create();
+
          
+
+
          
+is_convertible<From, To>::value inherits either directly or
+indirectly from true_type if the
+return expression in the following code would be well-formed, including
+any implicit conversions to the return type of the function, else
+is_convertible<From, To>::value inherits either directly or
+indirectly from false_type.
+
          
+
+
          To test() { 
+  return create<From>(); 
+}
+
          
+
+
          
+[Note: This requirement gives well defined results for reference types,
+void types, array types, and function types. -- end note]
+
          
+
+
          
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
+
          
+In 20.6.5 [meta.rel] change:
+
          
+
+
          
+
+
+
+
+
+
+
+
+
+
+
+
          TemplateConditionComments
          .........
          template <class From, class To>
          struct is_convertible;          		
+The code set out below shall be well formed.
+see belowFrom and To shall be complete types, arrays of unknown bound,
+or (possibly cv-qualified) void types.
          
+
+
          
+-4- In order to instantiate the template is_convertible<From, To>, the
+following code shall be well formed:
+Given the following function prototype:
+
          
+
+
          template <class T> 
+  typename add_rvalue_reference<T>::type create();
+
          
+
+
          
+the predicate condition for a template specialization
+is_convertible<From, To> shall be satisfied, if and only
+if the return expression in the following code would be well-formed,
+including any implicit conversions to the return type of the
+function.
+
          
+
+
          To test() { 
+  return create<From>(); 
+}
+
          
+
+
          
+[Note: This requirement gives well defined results for reference types,
+void types, array types, and function types. — end note]
+
          
+
+
          
+
+
+
+
+
+
          
+
          976. Class template std::stack should be movable
          
+
          Section: 23.3.5.3.1 [stack.defn] Status: Tentatively Ready
+ Submitter: Daniel Krügler Opened: 2009-02-01  Last modified: 2009-05-23
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+The synopsis given in 23.3.5.3.1 [stack.defn] does not show up
+
          
+
+
          requires MoveConstructible<Cont> stack(stack&&);
+requires MoveAssignable<Cont> stack& operator=(stack&&);
+
          
+
+
          
+although the other container adaptors do provide corresponding
+members.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We agree with the proposed resolution.
+
          
+
          
+Move to Tentatively Ready.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+In the class stack synopsis of 23.3.5.3.1 [stack.defn] insert:
+
          
+
+
          template <ObjectType T, StackLikeContainer Cont = deque<T> > 
+  requires SameType<Cont::value_type, T> 
+        && NothrowDestructible<Cont> 
+class stack { 
+public: 
+   ...
+   requires CopyConstructible<Cont> explicit stack(const Cont&); 
+   requires MoveConstructible<Cont> explicit stack(Cont&& = Cont()); 
+   requires MoveConstructible<Cont> stack(stack&&);
+   requires MoveAssignable<Cont> stack& operator=(stack&&);
+   template <class Alloc> 
+     requires Constructible<Cont, const Alloc&> 
+     explicit stack(const Alloc&);
+   ...
+};
+
          
+
+
          
+[Remark: This change should be done in sync with the resolution of
+paper
+N2819]
+
          
+
+
+
+
+
+
+
          
+
          977. insert iterators inefficient for expensive to move types
          
+
          Section: 24.7 [insert.iterators] Status: Open
+ Submitter: Howard Hinnant Opened: 2009-02-02  Last modified: 2009-05-23
          
+
          View other active issues in [insert.iterators].
          
+
          View all other issues in [insert.iterators].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+The new concepts for the insert iterators mandate an extra copy when
+inserting an lvalue:
+
          
+
+
          requires CopyConstructible<Cont::value_type>
+  back_insert_iterator<Cont>& 
+  operator=(const Cont::value_type& value);
+
          
+
          
+-1- Effects: push_back(*container, Cont::value_type(value));
+
          
+
          
+
+
          
+The reason is to convert value into an rvalue because the current
+BackInsertionContainer concept only handles push_back-ing
+rvalues:
+
          
+
+
          concept BackInsertionContainer<typename C> : Container<C> { 
+  void push_back(C&, value_type&&); 
+}
+
          
+
+
          
+Without the conversion of value to an rvalue, the assignment operator
+fails to concept check.
+
          
+
+
          
+A solution is to modify the BackInsertionContainer concept so that
+the client can pass in the parameter type for push_back similar to
+what is already done for the OutputIterator concept:
+
          
+
+
          concept BackInsertionContainer<typename C, typename Value = C::value_type&&>
+  : Container<C> { 
+     void push_back(C&, Value); 
+}
+
          
+
+
          
+This allows the assignment operator to be adjusted appropriately:
+
          
+
+
          requires BackInsertionContainer<Cont, Cont::value_type const&> &&
+         CopyConstructible<Cont::value_type>
+  back_insert_iterator<Cont>& 
+  operator=(const Cont::value_type& value);
+
          
+
          
+-1- Effects: push_back(*container, value);
+
          
+
          
+
+
          [
+We may want to propagate this fix to other concepts such as StackLikeContainer.
+]
          
+
+
+
          [
+Solution and wording collaborated on by Doug and Howard.
+]
          
+
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Howard notes that "these operations behaved efficiently until concepts were added."
+
          
+
          
+Alisdair is uncertain that the proposed resolution is syntactically correct.
+
          
+
          
+Move to Open, and recommend the issue be deferred until after the next
+Committee Draft is issued.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 23.2.6.1 [container.concepts.free]:
+
          
+
+
          
+
          concept FrontInsertionContainer<typename C, typename Value = C::value_type&&>
+    : Container<C> { 
+  void push_front(C&, value_type&& Value); 
+
+  axiom FrontInsertion(C c, value_type Value x) { 
+    x == (push_front(c, x), front(c)); 
+  } 
+}
+
          
+
+
          ...
          
+
+
          concept BackInsertionContainer<typename C, typename Value = C::value_type&&>
+    : Container<C> { 
+  void push_back(C&, value_type&& Value); 
+}
+
          
+
+
          ...
          
+
+
          concept InsertionContainer<typename C, typename Value = C::value_type&&>
+    : Container<C> { 
+  iterator insert(C&, const_iterator, value_type&& Value); 
+
+  axiom Insertion(C c, const_iterator position, value_type Value v) { 
+    v == *insert(c, position, v); 
+  } 
+}
+
          
+
+
          
+
+
          
+Change 23.2.6.2 [container.concepts.member]:
+
          
+
+
          
+
          auto concept MemberFrontInsertionContainer<typename C, typename Value = C::value_type&&>
+    : MemberContainer<C> { 
+  void C::push_front(value_type&& Value); 
+
+  axiom MemberFrontInsertion(C c, value_type Value x) { 
+    x == (c.push_front(x), c.front()); 
+  } 
+}
+
          
+
+
          ...
          
+
+
          auto concept MemberBackInsertionContainer<typename C, typename Value = C::value_type&&>
+    : MemberContainer<C> { 
+  void C::push_back(value_type&& Value); 
+}
+
          
+
+
          ...
          
+
+
          auto concept MemberInsertionContainer<typename C, typename Value = C::value_type&&>
+    : MemberContainer<C> { 
+  iterator C::insert(const_iterator, value_type&& Value); 
+
+  axiom MemberInsertion(C c, const_iterator position, value_type Value v) { 
+    v == *c.insert(position, v); 
+  } 
+}
+
          
+
          
+
+
          
+Change 23.2.6.3 [container.concepts.maps]:
+
          
+
+
          
+
          template <MemberFrontInsertionContainer C, typename Value = C::value_type&&> 
+concept_map FrontInsertionContainer<C, Value> { 
+  typedef Container<C>::value_type value_type;
+
+  void push_front(C& c, value_type&& Value v) { c.push_front(static_cast<value_type&& Value>(v)); } 
+}
+
          
+
+
          ...
          
+
+
          template <MemberBackInsertionContainer C, typename Value = C::value_type&&> 
+concept_map BackInsertionContainer<C, Value> { 
+  typedef Container<C>::value_type value_type;
+
+  void push_back(C& c, value_type&& Value v) { c.push_back(static_cast<value_type&& Value>(v)); } 
+}
+
          
+
+
          ...
          
+
+
          template <MemberInsertionContainer C, typename Value = C::value_type&&> 
+concept_map InsertionContainer<C, Value> { 
+  typedef Container<C>::value_type value_type;
+  Container<C>::iterator insert(C& c, Container<C>::const_iterator i, value_type&& Value v) 
+  { return c.insert(i, static_cast<value_type&& Value>(v)); } 
+}
+
          
+
+
          
+
+
          
+Change 24.7.1 [back.insert.iterator]:
+
          
+
+
          template <BackInsertionContainer Cont> 
+class back_insert_iterator {
+  ...
+  requires BackInsertionContainer<Cont, const Cont::value_type&>
+           CopyConstructible<Cont::value_type>
+    back_insert_iterator<Cont>& 
+      operator=(const Cont::value_type& value);
+  ...
+
          
+
+
          
+Change 24.7.2.2 [back.insert.iter.op=]:
+
          
+
+
          
+
          requires BackInsertionContainer<Cont, const Cont::value_type&>
+         CopyConstructible<Cont::value_type>
+  back_insert_iterator<Cont>& 
+    operator=(const Cont::value_type& value);
+
          
+
          
+-1- Effects: push_back(*container, Cont::value_type(value));
+
          
+
          
+
+
          
+Change 24.7.3 [front.insert.iterator]:
+
          
+
+
          template <FrontInsertionContainer Cont> 
+class front_insert_iterator {
+  ...
+  requires FrontInsertionContainer<Cont, const Cont::value_type&>
+           CopyConstructible<Cont::value_type>
+    front_insert_iterator<Cont>& 
+      operator=(const Cont::value_type& value);
+  ...
+
          
+
+
          
+Change 24.7.4.2 [front.insert.iter.op=]:
+
          
+
+
          
+
          requires FrontInsertionContainer<Cont, const Cont::value_type&>
+         CopyConstructible<Cont::value_type>
+  front_insert_iterator<Cont>& 
+    operator=(const Cont::value_type& value);
+
          
+
          
+-1- Effects: push_front(*container, Cont::value_type(value));
+
          
+
          
+
+
          
+Change 24.7.5 [insert.iterator]:
+
          
+
+
          template <InsertionContainer Cont> 
+class insert_iterator {
+  ...
+  requires InsertionContainer<Cont, const Cont::value_type&>
+           CopyConstructible<Cont::value_type>
+    insert_iterator<Cont>& 
+      operator=(const Cont::value_type& value);
+  ...
+
          
+
+
          
+Change 24.7.6.2 [insert.iter.op=]:
+
          
+
+
          
+
          requires InsertionContainer<Cont, const Cont::value_type&>
+         CopyConstructible<Cont::value_type>
+  insert_iterator<Cont>& 
+    operator=(const Cont::value_type& value);
+
          
+
          
+
          
+-1- Effects:
+
          
+
          iter = insert(*container, iter, Cont::value_type(value)); 
+++iter;
+
          
+
          
+
          
+
+
+
+
+
+
+
          
+
          978. Hashing smart pointers
          
+
          Section: 20.7.17 [unord.hash] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-02-02  Last modified: 2009-05-31
          
+
          View other active issues in [unord.hash].
          
+
          View all other issues in [unord.hash].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+I don't see an open issue on supporting std::hash for smart pointers
+(unique_ptr and shared_ptr at least).
+
          
+
          
+It seems reasonable to at least expect support for the smart
+pointers, especially as they support comparison for use in ordered
+associative containers.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Howard points out that the client can always supply a custom hash function.
+
          
+
          
+Alisdair replies that the smart pointer classes are highly likely
+to be frequently used as hash keys.
+
          
+
          
+Bill would prefer to be conservative.
+
          
+
          
+Alisdair mentions that this issue may also be viewed as a subissue or
+duplicate of issue 1025.
+
          
+
          
+Move to Open, and recommend the issue be deferred until after the next
+Committee Draft is issued.
+
          
+
          
+
+
          [
+2009-05-31 Peter adds:
+]
          
+
+
+
          
+
          
+Howard points out that the client can always supply a custom hash function.
+
          
+
          
+Not entirely true. The client cannot supply the function that hashes the
+address of the control block (the equivalent of the old operator<, now
+proudly carrying the awkward name of 'owner_before'). Only the
+implementation can do that, not necessarily via specializing hash<>, of
+course.
+
          
+
          
+This hash function makes sense in certain situations for shared_ptr
+(when one needs to switch from set/map using ownership ordering to
+unordered_set/map) and is the only hash function that makes sense for
+weak_ptr.
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
+
+
+
          
+
          979. Bad example
          
+
          Section: 24.5.3 [move.iterators] Status: Tentatively NAD Editorial
+ Submitter: Howard Hinnant Opened: 2009-02-03  Last modified: 2009-05-23
          
+
          View all issues with Tentatively NAD Editorial status.
          
+
          Discussion:
          
+
          
+24.5.3 [move.iterators] has an incorrect example:
+
          
+
+
          
+
          
+-2- [Example:
+
          
+
+
          set<string> s; 
+// populate the set s 
+vector<string> v1(s.begin(), s.end());          // copies strings into v1 
+vector<string> v2(make_move_iterator(s.begin()), 
+                  make_move_iterator(s.end())); // moves strings into v2
+
          
+
+
          
+-- end example]
+
          
+
          
+
+
          
+One can not move from a set because the iterators return const
+references.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution. Move to NAD Editorial.
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+Change 24.5.3 [move.iterators]/2:
+
          
+
+
          
+
          
+-2- [Example:
+
          
+
+
          setlist<string> s; 
+// populate the setlist s 
+vector<string> v1(s.begin(), s.end());          // copies strings into v1 
+vector<string> v2(make_move_iterator(s.begin()), 
+                  make_move_iterator(s.end())); // moves strings into v2
+
          
+
+
          
+-- end example]
+
          
+
          
+
+
+
+
+
+
          
+
          981. Unordered container requirements should add  initializer_list support
          
+
          Section: 23.2.5 [unord.req] Status: Tentatively Ready
+ Submitter: Daniel Krügler Opened: 2009-02-08  Last modified: 2009-05-23
          
+
          View other active issues in [unord.req].
          
+
          View all other issues in [unord.req].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+Refering to
+N2800
+all container requirements tables (including those for
+associative containers) provide useful member function overloads
+accepting std::initializer_list as argument, the only exception is
+Table 87. There seems to be no reason for not providing them, because 23.5 [unord]
+is already initializer_list-aware. For the sake of 
+library interface consistency and user-expectations corresponding 
+overloads should be added to the table requirements of unordered 
+containers as well.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We agree with the proposed resolution.
+
          
+
          
+Move to Tentatively Ready.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
+
          
+In 23.2.5 [unord.req]/9 insert:
+
          
+
+
          
+... [q1, q2) is a valid range in a, il
+designates an object of type initializer_list<value_type>, t is a value of type
+X::value_type, ...
+
          
+
+
          
+In 23.2.5 [unord.req], Table 87 insert:
+
          
+
+
          
+
+
+
+
+
+
+
+
+
+ 
+ 
+
+
+
+
+
+
+
+
+
+ 
+ 
+
+
+
+
+
+
+
+
+
+ 
+ 
+
+
+
          Table 87 - Unordered associative container requirements (in addition to container)
          Expression Return type Assertion/note
          pre-/post-condition          		 Complexity
          X(i, j)
          X a(i, j)          		 X ... ...
          X(il) XSame as X(il.begin(), il.end()).Same as X(il.begin(), il.end()).
          ... ... ... ...
          a = b X ... ...
          a = il X&a = X(il); return *this;Same as a = X(il).
          ... ... ... ...
          a.insert(i, j) void ... ...
          a.insert(il) voidSame as a.insert(il.begin(), il.end()).Same as a.insert(il.begin(), il.end()).
          
+
          
+
+
+
+
+
+
+
          
+
          982. Wrong complexity for initializer_list assignment in  Table 85
          
+
          Section: 23.2.4 [associative.reqmts] Status: Tentatively Ready
+ Submitter: Daniel Krügler Opened: 2009-02-08  Last modified: 2009-05-23
          
+
          View other active issues in [associative.reqmts].
          
+
          View all other issues in [associative.reqmts].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+According to
+N2800,
+the associative container requirements table 85 says
+    that assigning an initializer_list to such a container is of
+    constant complexity, which is obviously wrong.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We agree with the proposed resolution.
+
          
+
          
+Move to Tentatively Ready.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
+
          
+In 23.2.4 [associative.reqmts], Table 85 change:
+
          
+
+
          
+
+
+
+
+
+
+ 
+
+
+
          Table 85 - Associative container requirements (in addition to container)
          Expression Return type Assertion/note
          pre-/post-condition          		 Complexity
          a = il X& a = X(il);
          return *this;          		constantSame as a = X(il).
          
+
          
+
+
+
+
+
+
+
          
+
          983. unique_ptr reference deleters should not be moved from
          
+
          Section: 20.8.12.2 [unique.ptr.single] Status: Review
+ Submitter: Howard Hinnant Opened: 2009-02-10  Last modified: 2009-05-23
          
+
          View other active issues in [unique.ptr.single].
          
+
          View all other issues in [unique.ptr.single].
          
+
          View all issues with Review status.
          
+
          Discussion:
          
+
          
+Dave brought to my attention that when a unique_ptr has a non-const reference
+type deleter, move constructing from it, even when the unique_ptr containing
+the reference is an rvalue, could have surprising results:
+
          
+
+
          D d(some-state);
+unique_ptr<A, D&> p(new A, d);
+unique_ptr<A, D> p2 = std::move(p);
+// has d's state changed here?
+
          
+
+
          
+I agree with him.  It is the unique_ptr that is the rvalue, not the
+deleter.  When the deleter is a reference type, the unique_ptr should
+respect the "lvalueness" of the deleter.
+
          
+
+
          
+Thanks Dave.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+Seems correct, but complicated enough that we recommend moving to Review.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 20.8.12.2.1 [unique.ptr.single.ctor], p20-21
+
          
+
+
          
+
          template <class U, class E> unique_ptr(unique_ptr<U, E>&& u);
+
          
+
+
          
+
+
          
+-20- Requires: If D E is not a reference type,
+construction of the deleter D from an rvalue of type E
+shall be well formed and shall not throw an exception.
+
+Otherwise E is a reference type and construction of the deleter
+D from an lvalue of type E shall be well formed and
+shall not throw an exception.
+
+If D is
+a reference type, then E shall be the same type as D
+(diagnostic required). unique_ptr<U, E>::pointer shall be
+implicitly convertible to pointer. [Note: These
+requirements imply that T and U are complete types.
+-- end note]
+
          
+
+
          
+-21- Effects: Constructs a unique_ptr which owns the
+pointer which u owns (if any). If the deleter
+E is not a reference type, it this
+deleter is move constructed from u's deleter, otherwise
+the reference this deleter is copy constructed
+from u.'s deleter. After the construction, u no longer
+owns a pointer. [Note: The deleter constructor can be implemented
+with std::forward<DE>. -- end
+note]
+
          
+
+
          
+
          
+
+
          
+Change 20.8.12.2.3 [unique.ptr.single.asgn], p1-3
+
          
+
+
          
+
          unique_ptr& operator=(unique_ptr&& u);
+
          
+
          
+
+
          
+-1- Requires: If the deleter D is not a reference type,
+Aassignment of the deleter D from an rvalue D shall not throw an exception.
+
+Otherwise the deleter D is a reference type,
+and assignment of the deleter D from an lvalue D shall not throw an exception.
+
          
+
+
          
+-2- Effects: reset(u.release()) followed by
+an move assignment from u's deleter to this deleter
+std::forward<D>(u.get_deleter()).
+
          
+
+
          
+-3- Postconditions: This unique_ptr now owns the pointer
+which u owned, and u no longer owns it. [Note: If
+D is a reference type, then the referenced lvalue deleters are
+move assigned. -- end note]
+
          
+
          
+
          
+
+
          
+Change 20.8.12.2.3 [unique.ptr.single.asgn], p6-7
+
          
+
+
          
+
          template <class U, class E> unique_ptr& operator=(unique_ptr<U, E>&& u);
+
          
+
          
+
+
          
+Requires: If the deleter E is not a reference type,
+Aassignment of the deleter D from an rvalue
+DE shall not throw an exception.
+
+Otherwise the deleter E is a reference type,
+and assignment of the deleter D from an lvalue E shall not throw an exception.
+unique_ptr<U, E>::pointer shall be implicitly convertible to pointer.
+[Note: These requirements imply that T and U>
+are complete types. -- end note]
+
          
+
+
          
+Effects: reset(u.release()) followed by
+an move assignment from u's deleter to this deleter
+std::forward<E>(u.get_deleter()).
+If either
+D or E is a reference type, then the referenced lvalue
+deleter participates in the move assignment.
+
          
+
+
          
+
          
+
+
+
+
+
+
+
          
+
          984. Does <cinttypes> have macro guards?
          
+
          Section: 27.9.2 [c.files] Status: Tentatively Ready
+ Submitter: Howard Hinnant Opened: 2009-02-12  Last modified: 2009-05-23
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+The C standard says about <inttypes.h>:
+
          
+
+
          
+C++ implementations should define these macros only when __STDC_FORMAT_MACROSis defined 
+before <inttypes.h> is included.
+
          
+
+
          
+The C standard has a similar note about <stdint.h>.  For <cstdint>
+we adopted a "thanks but no thanks" policy and documented that fact in
+18.4.1 [cstdint.syn]:
+
          
+
+
          
+... [Note: The macros defined by <stdint> are
+provided unconditionally. In particular, the symbols
+__STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS
+(mentioned in C99 footnotes 219, 220, and 222) play no role in C++.
+-- end note]
+
          
+
+
          
+I recommend we put a similar note in 27.9.2 [c.files] regarding <cinttypes>.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Add to 27.9.2 [c.files]:
+
          
+
+
          
+Table 112 describes header <cinttypes>.
+
+[Note: The macros defined by <cintypes> are
+provided unconditionally. In particular, the symbol
+__STDC_FORMAT_MACROS
+(mentioned in C99 footnote 182) plays no role in C++.
+-- end note]
+
+
          
+
+
+
+
+
+
          
+
          985. Allowing throwing move
          
+
          Section: 23.2.1 [container.requirements.general] Status: Open
+ Submitter: Rani Sharoni Opened: 2009-02-12  Last modified: 2009-05-23
          
+
          View other active issues in [container.requirements.general].
          
+
          View all other issues in [container.requirements.general].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+Introduction
+
          
+
+
          This proposal is meant to resolve potential regression of the
+N2800
+draft, see
+next section, and to relax the requirements for containers of types with
+throwing move constructors.
          
+
+
          The basic problem is that some containers operations, like push_back,
+have a strong exception safety
+guarantee (i.e. no side effects upon exception) that are not achievable when
+throwing move constructors are used since there is no way to guarantee revert
+after partial move. For such operations the implementation can at most provide
+the basic guarantee (i.e. valid but unpredictable) as it does with multi
+copying operations (e.g. range insert).
          
+
+
          For example, vector<T>::push_back() (where T has a move
+constructor) might resize the vector and move the objects to the new underlying
+buffer. If move constructor throws it might
+not be possible to recover the throwing object or to move the old objects back to
+the original buffer.
          
+
+
          The current draft is explicit by disallowing throwing move
+for some operations (e.g. vector<>::reserve) and not clear about other
+operations mentioned in 23.2.1 [container.requirements.general]/10
+(e.g. single element insert): it guarantees strong exception
+safety without explicitly disallowing a throwing move constructor.
+
          
+
+
          
+Regression
+
          
+
+
          This section only refers to cases in which the contained object
+is by itself a standard container.
          
+
+
          Move constructors of standard containers are allowed to throw and therefore
+existing operations are broken, compared with C++03, due to move optimization.
+(In fact existing implementations like Dinkumware are actually throwing).
          
+
+
          For example, vector< list<int> >::reserve yields
+undefined behavior since list<int>'s move constructor is allowed to throw.
+On the other hand, the same operation has strong exception safety guarantee in
+C++03.
          
+
+
          There are few options to solve this regression:
          
+
+
            
+
          1. 
+Disallow throwing move and throwing default constructor
+
            2. 
+
+
          2. 
+Disallow throwing move but disallowing usage after move
+
            3. 
+
+
          3. 
+Special casing
+
            4. 
+
+
          4. 
+Disallow throwing move and making it optional
+
            5. 
+
+
          
+
+
          Option 1 is suggested by proposal
+N2815
+but it might not be applicable for existing implementations for which
+containers default constructors are throwing.
          
+
+
          Option 2 limits the usage significantly and it's error prone
+by allowing zombie objects that are nothing but destructible (e.g. no clear()
+is allowed after move). It also potentially complicates the implementation by
+introducing special state.
          
+
+
          Option 3 is possible, for example, using default
+construction and swap instead of move for standard containers case. The
+implementation is also free to provide special hidden operation for non
+throwing move without forcing the user the cope with the limitation of option-2
+when using the public move.
          
+
+
          Option 4 impact the efficiency in all use cases due to rare throwing move.
          
+
+
          The proposed wording will imply option 1 or 3 though option 2 is also
+achievable using more wording. I personally oppose to option 2 that has impact
+on usability.
          
+
+
          
+Relaxation for user types
+
          
+
+
          Disallowing throwing move constructors in general seems very restrictive
+since, for example, common implementation of move will be default construction
++ swap so move will throw if the
+default constructor will throw. This is currently the case with the Dinkumware
+implementation of node based containers (e.g. std::list)
+though this section doesn't refer to standard types.
          
+
+
          For throwing move constructors it seem that the implementation should have
+no problems to provide the basic guarantee instead of the strong one. It's
+better to allow throwing move constructors with basic guarantee than to
+disallow it silently (compile and run), via undefined behavior.
          
+
+
          There might still be cases in which the relaxation will break existing generic
+code that assumes the strong guarantee but it's broken either way given a
+throwing move constructor since this is not a preserving optimization. 
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Bjarne comments (referring to his draft paper):
+"I believe that my suggestion simply solves that.
+Thus, we don't need a throwing move."
+
          
+
          
+Move to Open and recommend it be deferred until after the next
+Committee Draft is issued.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
+
          
+23.2.1 [container.requirements.general]  paragraph 10 add footnote:
+
          
+
+
          
+
          
+-10- Unless otherwise specified (see 23.1.4.1, 23.1.5.1, 23.2.2.3, and
+23.2.6.4) all container types defined in this Clause meet the following
+additional requirements:
+
          
+
            
+
          • ...
            • 
+
          
+
+
          
+[Note: for compatibility with C++
+2003, when "no effect" is required, standard containers should not use the
+value_type's throwing move constructor when the contained object is by itself a
+standard container. -- end note]
+
          
+
+
          
+
+
          23.2.5.1 [unord.req.except] change paragraph 2 to say: 
          
+
+
          
+
          
+-2- For unordered associative containers, if an exception is
+thrown by any operation other than the container's hash function from within an
+insert() function inserting a single element, the insert()
+function has no effect unless the exception is thrown by the contained
+object move constructor.
+
          
+
+
          
+-4- For unordered associative containers, if an exception is
+thrown from within a rehash() function other than by the container's hash
+function or comparison function, the rehash() function has no effect
+unless the exception is thrown by the contained
+object move constructor.
          
+
+
          
+
+
          
+23.3.2.3 [deque.modifiers] change paragraph 2 to say:
+
          
+
+
          
+-2- Remarks: If an exception is thrown other than by
+the copy constructor, move constructor
+or assignment operator of T
+there are no effects.
+If an exception is thrown by push_back() or emplace_back()
+function, that function has no effects unless the exception is thrown by
+the move constructor of T.
+
          
+
+
          
+23.3.2.3 [deque.modifiers] change paragraph 6 to say:
+
          
+
+
          
+-6- Throws: Nothing unless an exception is thrown by the copy
+constructor, move constructor or assignment operator of T.
+
          
+
+
          
+23.3.6.2 [vector.capacity] remove paragraph 2
+
          
+
+
          
+-2- Requires: If value_type has a move constructor,
+that constructor shall not throw any exceptions.
+
          
+
+
          
+23.3.6.2 [vector.capacity] paragraph 3 change to say:
+
          
+
+
          
+-3- Effects: A directive that informs a vector
+of a planned change in size, so
+that it can manage the storage allocation accordingly. After reserve(),
+capacity() is greater or equal to the argument of reserve
+if reallocation happens; and equal
+to the previous value of capacity()
+otherwise. Reallocation happens at this point if and only if the current
+capacity is less than the argument of reserve().
+If an exception is thrown, there are no effects
+unless the exception is thrown by the contained object move constructor.
+
          
+
+
          
+23.3.6.2 [vector.capacity] paragraph 12 change to say:
+
          
+
+
          
+-12- Requires: If value_type has a move constructor,
+that constructor shall not throw any exceptions.
+If an exception is thrown, there are no effects unless the exception is thrown by
+the contained object move constructor.
+
          
+
+
          
+23.3.6.4 [vector.modifiers] change paragraph 1 to say:
+
          
+
+
          
+-1- Requires: If value_type has a move constructor,
+that constructor shall not throw any exceptions.
+Remarks: If an exception is thrown by push_back()
+or emplace_back() function, that function has no effect unless the
+exception is thrown by the move constructor of T.
+
          
+
+
          
+23.3.6.4 [vector.modifiers] change paragraph 2 to say:
+
          
+
+
          
+-2- Remarks: Causes reallocation if the new size is greater than
+the old capacity. If no reallocation happens, all the iterators and
+references before the insertion point remain valid. If an exception is
+thrown other than by the copy constructor, move constructor
+or assignment operator of T or by any InputIterator
+operation there are no effects.
+
          
+
+
          
+23.3.6.4 [vector.modifiers] change paragraph 6 to say:
+
          
+
+
          
+-6- Throws: Nothing unless an exception is thrown by the copy
+constructor, move constructor or assignment operator of T.
+
          
+
+
+
+
+
+
+
          
+
          986. Generic try_lock contradiction
          
+
          Section: 30.4.4 [thread.lock.algorithm] Status: Tentatively Ready
+ Submitter: Chris Fairles Opened: 2009-02-14  Last modified: 2009-05-23
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+In 30.4.4 [thread.lock.algorithm], the generic try_lock effects (p2) say that a failed
+try_lock is when it either returns false or throws an exception. In
+the event a call to try_lock does fail, by either returning false or
+throwing an exception, it states that unlock shall be called for all
+prior arguments. Then the returns clause (p3) goes on to state
+in a note that after returning, either all locks are locked or none
+will be. So what happens if multiple locks fail on try_lock?
+
          
+
+
          
+Example:
+
          
+
+
          #include <mutex>
+
+int main() {
+ std::mutex m0, m1, m2;
+ std::unique_lock<std::mutex> l0(m0, std::defer_lock);
+ std::unique_lock<std::mutex> l1(m1); //throws on try_lock
+ std::unique_lock<std::mutex> l2(m2); //throws on try_lock
+
+ int result = std::try_lock(l0, l1, l2);
+
+ assert( !l0.owns_lock() );
+ assert( l1.owns_lock() ); //??
+ assert( l2.owns_lock() ); //??
+}
+
          
+
+
          
+The first lock's try_lock succeeded but, being a prior argument to a
+lock whose try_lock failed, it gets unlocked as per the effects clause
+of 30.4.4 [thread.lock.algorithm]. However, 2 locks remain locked in this case but the return
+clause states that either all arguments shall be locked or none will
+be. This seems to be a contradiction unless the intent is for
+implementations to make an effort to unlock not only prior arguments,
+but the one that failed and those that come after as well. Shouldn't
+the note only apply to the arguments that were successfully locked?
+
          
+
+
          
+Further discussion and possible resolutions in c++std-lib-23049.
+
          
+
+
          [
+Summit:
+]
          
+
+
          
+Move to review. Agree with proposed resolution.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
+
          
+Change 30.4.4 [thread.lock.algorithm], p2:
+
          
+
+
          
+-2- Effects: Calls try_lock() for each argument in order
+beginning with the first until all arguments have been processed or a
+call to try_lock() fails, either by returning false or by throwing an
+exception. If a call to try_lock() fails, unlock() shall be called for
+all prior arguments and there shall be no further calls to try_lock().
+
          
+
+
          
+Delete the note from 30.4.4 [thread.lock.algorithm], p3
+
          
+
+
          
+-3- Returns: -1 if all calls to try_lock() returned true,
+otherwise a 0-based index value that indicates 
+the argument for which try_lock() returned false. [Note:
+On return, either all arguments will be 
+locked or none will be locked. -- end note]
+
          
+
+
+
+
+
+
          
+
          987. reference_wrapper and function types
          
+
          Section: 20.7.5 [refwrap] Status: Review
+ Submitter: Howard Hinnant Opened: 2009-02-18  Last modified: 2009-05-23
          
+
          View all other issues in [refwrap].
          
+
          View all issues with Review status.
          
+
          Discussion:
          
+
          
+The synopsis in 20.7.5 [refwrap] says:
+
          
+
+
          template <ObjectType T> class reference_wrapper
+...
+
          
+
+
          
+And then paragraph 3 says:
+
          
+
+
          
+
          
+The template instantiation reference_wrapper<T> shall be
+derived from std::unary_function<T1, R> only if the type
+T is any of the following:
+
          
+
+
            
+
          • 
+a function type or a pointer to function type taking one argument of
+type T1 and returning R
+
            • 
+
          
+
          
+
+
          
+But function types are not ObjectTypes.
+
          
+
+
          
+Paragraph 4 contains the same contradiction.
+
          
+
+
          [
+Post Summit:
+]
          
+
+
+
          
+
          
+Jens: restricted reference to ObjectType
+
          
+
          
+Recommend Review.
+
          
+
          
+
+
          [
+Post Summit, Peter adds:
+]
          
+
+
+
          
+
          
+In https://svn.boost.org/trac/boost/ticket/1846
+however Eric Niebler makes the very reasonable point that reference_wrapper<F>,
+where F is a function type, represents a reference to a function,
+a legitimate entity. So boost::ref was changed to allow it.
+
          
+
          
+https://svn.boost.org/trac/boost/browser/trunk/libs/bind/test/ref_fn_test.cpp
+
          
+
          
+Therefore, I believe an alternative proposed resolution for issue 987 could simply
+allow reference_wrapper to be used with function types.
+
          
+
          
+
+
          [
+Post Summit, Howard adds:
+]
          
+
+
+
          
+
          
+I agree with Peter (and Eric).  I got this one wrong on my first try.  Here
+is code that demonstrates how easy (and useful) it is to instantiate
+reference_wrapper with a function type:
+
          
+
+
          #include <functional>
+
+template <class F>
+void test(F f);
+
+void f() {}
+
+int main()
+{
+    test(std::ref(f));
+}
+
          
+
+
          
+Output (link time error shows type of reference_wrapper instantiated
+with function type):
+
          
+
+
          Undefined symbols:
+  "void test<std::reference_wrapper<void ()()> >(std::reference_wrapper<void ()()>)",...
+
          
+
+
          
+I've taken the liberty of changing the proposed wording to allow function types
+and set to Open.  I'll also freely admit that I'm not positive ReferentType
+is the correct concept.
+
          
+
+
          
+
+
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Howard observed that FunctionType,
+a concept not (yet?) in the Working Paper,
+is likely the correct constraint to be applied.
+However, the proposed resolution provides an adequate approximation.
+
          
+
          
+Move to Review.
+
          
+
          
+
+
          [
+2009-05-23 Alisdair adds:
+]
          
+
+
+
          
+
          
+By constraining to PointeeType we rule out the ability for T to be a
+reference, and call in reference-collapsing.  I'm not sure if this is
+correct and intended, but would like to be sure the case was considered.
+
          
+
          
+Is dis-allowing reference types and the
+implied reference collapsing the intended result?
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+Change the synopsis in 20.7 [function.objects]:
+
          
+
+
          // 20.6.5, reference_wrapper:
+template <ObjectType ReferentType T>
+  requires PointeeType<T>
+  class reference_wrapper;
+
+template <ObjectType PointeeType T>
+  reference_wrapper<T> ref(T&);
+
+template <ObjectType PointeeType T>
+  reference_wrapper<const T> cref(const T&);
+
+template <ObjectType PointeeType T>
+  reference_wrapper<T> ref(reference_wrapper<T>);
+template <ObjectType PointeeType T>
+  reference_wrapper<const T> cref(reference_wrapper<T>);
+
          
+
+
          
+Change the synopsis in 20.7.5 [refwrap]:
+
          
+
+
          template <ObjectType ReferentType T>
+  requires PointeeType<T>
+  class reference_wrapper
+   ...
+
          
+
+
          
+Change the prototypes in 20.7.5.5 [refwrap.helpers]:
+
          
+
+
          template <ObjectType PointeeType T>
+  reference_wrapper<T> ref(T&);
+...
+template <ObjectType PointeeType T>
+  reference_wrapper<const T> cref(const T&);
+...
+template <ObjectType PointeeType T>
+  reference_wrapper<T> ref(reference_wrapper<T>);
+...
+template <ObjectType PointeeType T>
+  reference_wrapper<const T> cref(reference_wrapper<T>);
+
          
+
+
+
+
          Rationale:
          
+
          
+a) The occurrence of T& in the function signature auto-implies
+std::ReferentType,
+this is due to 14.11.1.2 [temp.req.impl]/4 bullet 4
+
          
+
          
+b) The occurrence of the constrained template reference_wrapper<T> in
+the remaining
+signatures lets kick in 14.11.1.2 [temp.req.impl]/4 bullet 1 and adds *all* requirements of
+this template. But we need to add at least *one* requirement (and it
+was an arbitrary,
+but natural decision to require std::PointeeType here) to *activate*
+this. If we hadn't done
+this, we were in unconstrained mode!
+
          
+
+
+
+
+
+
          
+
          988. Reflexivity meaningless?
          
+
          Section: 20.2.6 [concept.comparison] Status: Tentatively NAD
+ Submitter: Alisdair Meredith Opened: 2009-02-24  Last modified: 2009-05-23
          
+
          View other active issues in [concept.comparison].
          
+
          View all other issues in [concept.comparison].
          
+
          View all issues with Tentatively NAD status.
          
+
          Discussion:
          
+
          
+20.2.6 [concept.comparison] p2:
+
          
+
          
+Due to the subtle meaning of == inside axioms, the Reflexivity axiom does
+not do anything as written. It merely states that a value is substitutable
+with itself, rather than asserting a property of the == operator.
+
          
+
+
+Original proposed resolution:
+
+
+
          
+Change the definition of Reflexivity in 20.2.6 [concept.comparison]:
+
          
+
+
          axiom Reflexivity(T a) { (a == a) == true; }
+
          
+
+
          [
+Post Summit:
+]
          
+
+
+
          
+
          
+Alisdair: I was wrong.
+
          
+
          
+Recommend NAD.
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+NAD.
+
          
+
+
+
+
+
+
          
+
          989. late_check and library
          
+
          Section: 17 [library] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-02-24  Last modified: 2009-05-23
          
+
          View other active issues in [library].
          
+
          View all other issues in [library].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+The example in 6.9p2 shows how late_check blocks inhibit concept_map lookup
+inside a constrained context, and so inhibit concept map adaption by users
+to meet template requirements.
+
          
+
          
+Do we need some text in clause 17 prohibitting use of late_check in library
+template definitions unless otherwise documented?
+
          
+
+
          [
+Doug adds:
+]
          
+
+
+
          
+We need something like this, but it should be a more general statement
+about implementations respecting the concept maps provided by the
+user. Use of late_check is one way in which implementations can
+subvert the concept maps provided by the user, but there are other
+ways as well ("pattern-based" overloading, tricks with "auto" concept
+maps and defaulted associated type arguments).
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+Move to Open, pending proposed wording from Alisdair and/or Doug for further review.
+
          
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          990. monotonic_clock::is_monotonic must be true
          
+
          Section: 20.9.5.2 [time.clock.monotonic] Status: Tentatively Ready
+ Submitter: Howard Hinnant Opened: 2009-03-09  Last modified: 2009-05-23
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+There is some confusion over what the value of monotonic_clock::is_monotonic
+when monotonic_clock is a  synonym for system_clock.  The
+intent is that if monotonic_clock exists, then monotonic_clock::is_monotonic
+is true.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We agree with the proposed resolution.
+
          
+
          
+Move to Tentatively Ready.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 20.9.5.2 [time.clock.monotonic], p1:
+
          
+
+
          
+-1- Objects of class monotonic_clock represent clocks for which
+values of time_point never decrease as physical time advances.
+monotonic_clock may be a synonym for system_clock
+if and only if system_clock::is_monotonic is
+true.
+
          
+
+
+
+
+
+
          
+
          991. Response to JP 50
          
+
          Section: 22.3.3.2.2 [conversions.string] Status: Tentatively Ready
+ Submitter: P.J. Plauger Opened: 2009-03-03  Last modified: 2009-05-23
          
+
          View other active issues in [conversions.string].
          
+
          View all other issues in [conversions.string].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+Add custom allocator parameter to wstring_convert, since we cannot
+allocate memory for strings from a custom allocator.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 22.3.3.2.2 [conversions.string]:
+
          
+
+
          template<class Codecvt, class Elem = wchar_t,
+         class Wide_alloc = std::allocator<Elem>,
+         class Byte_alloc = std::allocator<char> > class wstring_convert {
+  public:
+    typedef std::basic_string<char, char_traits<char>, Byte_alloc> byte_string;
+    typedef std::basic_string<Elem, char_traits<Elem>, Wide_alloc> wide_string;
+     ...
+
          
+
+
          
+Change 22.3.3.2.2 [conversions.string], p3:
+
          
+
+
          
+-3- The class template describes an ob ject that controls conversions
+between wide string ob jects of class
+std::basic_string<Elem, char_traits<Elem>, Wide_alloc>
+and byte string objects of class
+std::basic_string<char, char_traits<char>, Byte_alloc>
+(also known as std::string).
+
          
+
+
+
+
+
+
+
          
+
          992. Response to UK 169
          
+
          Section: 17.6.1.1 [contents] Status: Open
+ Submitter: P.J. Plauger Opened: 2009-03-03  Last modified: 2009-05-23
          
+
          View other active issues in [contents].
          
+
          View all other issues in [contents].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+This phrasing contradicts later freedom to implement the C standard
+library portions in the global namespace as well as std. (17.6.2.3p4)
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+The proposed wording seems to go too far.
+Move back to Open.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 17.6.1.1 [contents], p2:
+
          
+
+
          
+-2- All library entities except those from the Standard C
+library, macros, operator new and operator
+delete are defined within the namespace std or namespaces
+nested within namespace std.
+
          
+
+
+
+
+
+
+
          
+
          993. Response to UK 188
          
+
          Section: 18.5 [support.start.term] Status: Tentatively Ready
+ Submitter: P.J. Plauger Opened: 2009-03-03  Last modified: 2009-05-23
          
+
          View all other issues in [support.start.term].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+The function _Exit does not appear to be defined in this standard.
+Should it be added to the table of functions included-by-reference to
+the C standard?
+
          
+
+
          [
+2009-05-09 Alisdair fixed some minor issues in the wording.
+]
          
+
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Add to 18.5 [support.start.term] Table 20 (Header
+<cstdlib> synopsis) Functions:
+
          
+
+
          _Exit
+
          
+
+
          
+Add before the description of abort(void):
+
          
+
+
          void _Exit [[noreturn]] (int status)
+
          
+
+
          
+
          
+The function _Exit(int status) has additional behavior in this
+International Standard:
+
          
+
            
+
          • 
+The program is terminated without executing destructors for objects of
+automatic, thread, or static storage duration and without calling the
+functions passed to atexit() (3.6.3 [basic.start.term]).
+
            • 
+
          
+
          
+
          
+
+
+
+
+
+
+
          
+
          994. Response to UK 193
          
+
          Section: 18.6.2.2 [new.handler] Status: Tentatively Ready
+ Submitter: P.J. Plauger Opened: 2009-03-03  Last modified: 2009-05-23
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+quick_exit has been added as a new valid way to terminate a program in a
+well defined way
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 18.6.2.2 [new.handler], p2:
+
          
+
+
          
+
          
+-2- Required behavior: ...
+
          
+
            
+
          • ...
            • 
+
          • 
+call either abort() or exit();
+terminate execution of the program without returning to the caller
+
            • 
+
          
+
          
+
+
+
+
+
+
+
+
          
+
          995. Operational Semantics Unclear
          
+
          Section: 17.5.1.3 [structure.requirements] Status: Tentatively NAD
+ Submitter: David Abrahams Opened: 2009-03-06  Last modified: 2009-05-23
          
+
          View all issues with Tentatively NAD status.
          
+
          Discussion:
          
+
          
+As a practical matter there's disagreement on the meaning of operational
+semantics.  If the text in 17.5.1.3 [structure.requirements]p4 isn't
+clear, it should be clarified.  However, it's not clear whether the
+disagreement is merely due to people not being aware of the text.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+Agree with the recommended NAD resolution.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Recommend NAD.  The text in 17.5.1.3 [structure.requirements] is
+perfectly clear.
+
          
+
+
+
+
+
+
          
+
          996. Move operation not well specified
          
+
          Section: 17 [library] Status: Open
+ Submitter: David Abrahams Opened: 2009-03-06  Last modified: 2009-05-23
          
+
          View other active issues in [library].
          
+
          View all other issues in [library].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+There are lots of places in the standard where we talk about "the move
+constructor" but where we mean "the move operation," i.e.  T( move( x ) ).
+
          
+
          
+We also don't account for whether that operation modifies x or not, and
+we need to.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+Move to Open, pending proposed wording from Dave for further
+review.
+
          
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
+
+
+
          
+
          997. Response to UK 163
          
+
          Section: 17.5.1.4 [structure.specifications] Status: Tentatively Ready
+ Submitter: Thomas Plum Opened: 2009-03-03  Last modified: 2009-05-23
          
+
          View other active issues in [structure.specifications].
          
+
          View all other issues in [structure.specifications].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+Many functions are defined as "Effects: Equivalent to a...", which seems
+to also define the preconditions, effects, etc. But this is not made
+clear.
+
          
+
+
          
+After studying the occurrences of "Effects: Equivalent to", I agree with
+the diagnosis but disagree with the solution.  In 21.4.2 [string.cons]
+we find
+
          
+
+
          
+
          
+14 Effects: If InputIterator is an integral type, equivalent to
+basic_string(static_cast<size_type>(begin), static_cast<value_type>(end), a)
+
          
+
          
+15 Otherwise constructs a string from the values in the range [begin,
+end), as indicated in the Sequence Requirements table (see 23.1.3).
+
          
+
          
+
+
          
+This would be devishly difficult to re-write with an explicit
+"Equivalent to:" clause.  Instead, I propose the following, which will
+result in much less editorial re-work.
+
          
+
+
          [
+2009-05-09 Alisdair adds:
+]
          
+
+
+
          
+This issue is related to 492.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Add a new paragraph after 17.5.1.4 [structure.specifications], p3:
+
          
+
+
          
+
          
+-3- Descriptions of function semantics contain the following elements (as appropriate):154
+
          
+
+
            
+
          • 
+Requires: the preconditions for calling the function
+
            • 
+
          • 
+Effects: the actions performed by the function
+
            • 
+
          • 
+Postconditions: the observable results established by the function
+
            • 
+
          • 
+Returns: a description of the value(s) returned by the function
+
            • 
+
          • 
+Throws: any exceptions thrown by the function, and the conditions that would cause the exception
+
            • 
+
          • 
+Complexity: the time and/or space complexity of the function
+
            • 
+
          • 
+Remarks: additional semantic constraints on the function
+
            • 
+
          • 
+Error conditions: the error conditions for error codes reported by the function.
+
            • 
+
          • 
+Notes: non-normative comments about the function
+
            • 
+
          
+
+
          
+Whenever the Effects element specifies that the semantics of some
+function F are Equivalent to some code-sequence, then
+the various elements are interpreted as follows.  If F's
+semantics specifies a Requires element, then that requirement is
+logically imposed prior to the equivalent-to semantics.  Then,
+the semantics of the code-sequence are determined by the
+Requires, Effects, Postconditions, Returns,
+Throws, Complexity, Remarks, Error
+Conditions and Notes specified for the (one or more) function
+invocations contained in the code-sequence. The value returned from
+F is specified by F's Returns element, or
+if F has no Returns element, a non-void return from F is specified 
+by the Returns elements in code-sequence.  If
+F's semantics contains a Throws (or
+Postconditions, or Complexity) element, then that
+supersedes any occurrences of that element in the code-sequence.
+
          
+
          
+
+
+
+
+
+
+
          
+
          998. Smart pointer referencing its owner
          
+
          Section: 20.8.12.2.5 [unique.ptr.single.modifiers] Status: Tentatively Ready
+ Submitter: Pavel Minaev Opened: 2009-02-26  Last modified: 2009-05-23
          
+
          View other active issues in [unique.ptr.single.modifiers].
          
+
          View all other issues in [unique.ptr.single.modifiers].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+Consider the following (simplified) implementation of 
+std::auto_ptr<T>::reset(): 
+
          
+
+
          void reset(T* newptr = 0) { 
+   if (this->ptr && this->ptr != newptr) { 
+     delete this->ptr; 
+   } 
+   this->ptr = newptr; 
+} 
+
          
+
+
          
+Now consider the following code which uses the above implementation: 
+
          
+
+
          struct foo { 
+   std::auto_ptr<foo> ap; 
+   foo() : ap(this) {} 
+   void reset() { ap.reset(); } 
+}; 
+int main() { 
+   (new foo)->reset(); 
+} 
+
          
+
+
          
+With the above implementation of auto_ptr, this results in U.B. at the 
+point of auto_ptr::reset(). If this isn't obvious yet, let me explain 
+how this goes step by step: 
+
          
+
+
            
+
          1. 
+foo::reset() entered 
+
            2. 
+
          2. 
+auto_ptr::reset() entered 
+
            3. 
+
          3. 
+auto_ptr::reset() tries to delete foo
+
            4. 
+
          4. 
+foo::~foo() entered, tries to destruct its members 
+
            5. 
+
          5. 
+auto_ptr::~auto_ptr() executed - auto_ptr is no longer a valid object! 
+
            6. 
+
          6. 
+foo::~foo() left 
+
            7. 
+
          7. 
+auto_ptr::reset() sets its "ptr" field to 0 <- U.B.! auto_ptr
+is not a valid object here already! 
+
            8. 
+
          
+
+
          [
+Thanks to Peter Dimov who recognized the connection to unique_ptr and
+brought this to the attention of the LWG, and helped with the solution.
+]
          
+
+
+
          [
+Howard adds:
+]
          
+
+
+
          
+To fix this behavior reset must be specified such that deleting the
+pointer is the last action to be taken within reset.
+
          
+
+
          [
+Alisdair adds:
+]
          
+
+
+
          
+
          
+The example providing the rationale for LWG 998 is poor, as it relies on
+broken semantics of having two object believing they are unique owners of a
+single resource.  It should not be surprising that UB results from such
+code, and I feel no need to go out of our way to support such behaviour.
+
          
+
          
+If an example is presented that does not imply multiple ownership of a
+unique resource, I would be much more ready to accept the proposed
+resolution.
+
          
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Howard summarizes:
+
          
+
          
+This issue has to do with circular ownership,
+and affects auto_ptr, too (but we don't really care about that).
+It is intended to spell out the order in which operations must be performed
+so as to avoid the possibility
+of undefined behavior in the self-referential case.
+
          
+
          
+Howard points to message c++std-lib-23175 for another example,
+requested by Alisdair.
+
          
+
          
+We agree with the issue and with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+Change 20.8.12.2.5 [unique.ptr.single.modifiers], p5 (Effects clause for reset), and p6:
+
          
+
+
          
+
          
+-5- Effects: If get() == nullptr there are no effects. Otherwise get_deleter()(get()).
+Assigns p to the stored pointer, and then if the old value of the pointer is not
+equal to nullptr, calls get_deleter()(the old value of the pointer).
+[Note: The order of these operations is significant because the call to get_deleter()
+may destroy *this. -- end note]
+
          
+
+
          
+-6- Postconditions: get() == p.
+[Note: The postcondition does not hold if the call to
+get_deleter() destroys *this since this->get() is no longer a valid
+expression. -- end note]
+
          
+
          
+
+
+
+
+
+
          
+
          999. Taking the address of a function
          
+
          Section: 20.8.11.1 [object.addressof] Status: Tentatively Ready
+ Submitter: Peter Dimov Opened: 2009-03-09  Last modified: 2009-05-23
          
+
          View other active issues in [object.addressof].
          
+
          View all other issues in [object.addressof].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+The same fix (reference 987) may be applied to addressof, which is also constrained to
+ObjectType. (That was why boost::ref didn't work with functions - it
+tried to apply boost::addressof and the reinterpret_cast<char&>
+implementation of addressof failed.)
+
          
+
+
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We agree.
+
          
+
          
+Move to Tentatively Ready.
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+Change the synopsis in 20.8 [memory]:
+
          
+
+
          template <ObjectType PointeeType T>
+  T* addressof(T& r);
+
          
+
+
          
+Change 20.8.11.1 [object.addressof]:
+
          
+
+
          template <ObjectType PointeeType T>
+  T* addressof(T& r);
+
          
+
+
+
          Rationale:
          
+
          
+a) The occurrence of T& in the function signature auto-implies
+std::ReferentType,
+this is due to 14.11.1.2 [temp.req.impl]/4 bullet 4
+
          
+
+
+
+
+
+
          
+
          1000. adjacent_find is over-constrained
          
+
          Section: 25.3.8 [alg.adjacent.find] Status: Open
+ Submitter: Chris Jefferson Opened: 2009-03-09  Last modified: 2009-03-13
          
+
          View all other issues in [alg.adjacent.find].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+Addresses UK 296
+
          
+
+
          
+adjacent_find in C++03 allows an arbitrary predicate, but in C++0x
+EqualityComparable/EquivalenceRelation is required. This forbids a
+number of use cases, including:
+
          
+
          
+
+
+
+
+
+
+
+
+
+
          
+adjacent_find(begin, end, less<double>)
+
+Find the first
+place where a range is not ordered in decreasing order - in use to check
+for sorted ranges.
+
          
+adjacent_find(begin, end, DistanceBiggerThan(6) ) )
+
+Find the first
+place in a range where values differ by more than a given value - in use
+to check an algorithm which produces points in space does not generate
+points too far apart.
+
          
+
          
+
+
          
+A number of books use predicate which are not equivalence relations in
+examples, including "Thinking in C++" and "C++ Primer".
+
          
+
+
          
+Adding the requirement that the predicate is an EquivalenceRelation
+does not appear to open up any possibility for a more optimised algorithm.
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+Change the definition of adjacent_find in the synopsis of 25 [algorithms]
+and 25.3.8 [alg.adjacent.find] to:
+
          
+
+
          template<ForwardIterator Iter> 
+  requires EqualityComparableHasEqualTo<Iter::value_type, Iter::value_type>
+  Iter adjacent_find(Iter first, Iter last);
+
+template<ForwardIterator Iter, EquivalenceRelationPredicate<auto, Iter::value_type, Iter::value_type> Pred> 
+  requires CopyConstructible<Pred> 
+  Iter adjacent_find(Iter first, Iter last, Pred pred);
+
          
+
+
+
+
+
+
          
+
          1001. Pointers, concepts and headers
          
+
          Section: 17 [library] Status: Review
+ Submitter: Alisdair Meredith Opened: 2009-03-10  Last modified: 2009-06-16
          
+
          View other active issues in [library].
          
+
          View all other issues in [library].
          
+
          View all issues with Review status.
          
+
          Discussion:
          
+
+
          Addresses UK 78
          
+
+
          
+Related to 1063.
+
          
+
+
          
+This is effectively an extension of LWG issue 343.
+
          
+
          
+We know there is an increasing trend (encouraged by conformance testers and
+some users) that each library header should supply no more than required to
+satisfy the synopsis in the standard.  This is typically achieved by
+breaking larger headers into smaller subsets, and judicious use of forward
+declarations.
+
          
+
          
+If we apply this policy to C++0x (per
+N2800)
+it will be very surprising for
+people using library algorithms over ranges defined by pointers that they
+must #include <iterator_concepts> for their code to compile again.  That is
+because pointers do not satisfy any of the iterator concepts without the
+concept_map supplied in this header.
+
          
+
          
+Therefore, I suggest we should require all library headers that make use of
+iterator concepts are specifically required to #include <iterator_concepts>.
+
          
+
          
+At a minimum, the list of headers would be: (assuming all are constrained by
+concepts)
+
          
+
          algorithm
+array
+deque
+forward_list
+initializer_list
+iterator
+locale
+list
+map
+memory          // if 1029 is adopted
+memory_concepts
+numeric
+random
+regex
+set
+string
+tuple
+unordered_map
+unordered_set
+utility
+vector
+
          
+
+
          [
+Ganesh adds:
+]
          
+
+
+
          
+
          
+The same problems exists for <memory_concepts> and
+<container_concepts>.
+
          
+
          
+In order to compile <vector> you just need the
+definitions of the concepts in <memory_concepts>, the
+concept maps defined there are not necessary. Yet, from the user point
+of view, if the concept map template for AllocatableElement are
+not in scope, <vector> is pretty useless. Same for
+<tuple> and ConstructibleWithAllocator.
+
          
+
          
+Similarly, <queue> is not very useful if the concept map
+template for QueueLikeContainer is not in scope, although the
+definition of concept alone is theoretically sufficient.
+
          
+
          
+There's a pattern here: if a concept has concept maps "attached", they
+should never be separated.
+
          
+
          
+
+
          [
+Beman provided the proposed resolution for the May 2009 mailing. He 
+comments:
+]
          
+
+
+
          
+
+
          Initially I tried to specify exactly what header should include what other 
+headers. This was verbose, error prone, hard to maintain, and appeared to add 
+little value compared to just stating the general rule.
          
+
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Pete believes the proposed wording overconstrains implementers.
+Instead of specifying the mechanism,
+he prefers a solution that spells out what needs to be declared,
+rather than how those declarations are to be provided,
+e.g.,
+
          
+
          
+A C++ header shall provide the names
+that are required to be defined in that header.
+
          
+
          
+Bill suggests approaching the wording from a programmer's perspective.
+We may want to consider promising that certain widely-used headers
+(e.g., the concept headers) are included when needed by other headers.
+He feels, however, there is nothing broken now,
+although we may want to consider "something nicer."
+
          
+
          
+Move to Open status.
+
          
+
+
          
+
+
          [
+2009-06-16 Beman updated the proposed resolution:
+]
          
+
+
+
          
+  
            
+    
          • The mechanism is no longer specified, as requested in Batavia.
            • 
+    
          • The footnote has been removed since it specified mechanism and also did 
+    not reflect existing practice.
            • 
+    
          • A sentence was added that makes it clear that the existing practice is 
+    permitted.
            • 
+  
          
+
          
+
+
+
+
          Proposed resolution:
          
+
          Change 17.6.4.2 [res.on.headers], Headers, paragraph 1, as indicated:
          
+
          
+  
           A C++ 
+  header shall provide definitions for any names that appear in its synopsis (3.2 [basic.def.odr]). 
+  A C++ header may include other C++ headers.[footnote] A C++ 
+  header shown in its synopsis as including other C++ headers shall provide 
+  definitions for the same names as if those other headers were included. A C++ header that uses a 
+  concept (14.10 [concept]) shall provide the definition for that concept as if it included the C++ header 
+  that defines that concept in its synopsis. The mechanism and ordering of such 
+  definitions is unspecified.
          
+
+  
          [Example: If C++ header <a> contains a concept 
+  defined in C++ header <b>, and header <b> contains a 
+  concept defined in C++ header <c>, then inclusion of <a> 
+  is equivalent to inclusion of <a>, <b>, and 
+  <c>. — end example]
          
+
+  
          [footnote] C++ headers must include a C++ header that contains 
+  any needed definition (3.2).
          
+
          
+
+
+
+
+
+
+
          
+
          1002. Response to UK 170
          
+
          Section: 17.6.1.2 [headers] Status: Tentatively Ready
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-05-23
          
+
          View all other issues in [headers].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
+
          Addresses UK 170
          
+
+
          
+One of goals of C++0x is to make language easier to teach and for
+'incidental' programmers. The fine-grained headers of the C++ library
+are valuable in large scale systems for managing dependencies and
+optimising build times, but overcomplicated for simple development and
+tutorials. Add additional headers to support the whole library through a
+single include statement.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We do not all agree that this is an issue,
+but we agree that if it needs solving this is the right way to do it.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Insert a new paragraph in 17.6.1.2 [headers] between p4 and p5
+
          
+
          
+An additional header <std> shall have the effect of
+supplying the entire standard library.  [Note: for example, it
+might be implemented as a file with an #include statement for each of the
+headers listed in tables 13 and 14. -- end note]
+
          
+
+
+
+
+
+
          
+
          1003. Response to JP 23
          
+
          Section: 17.6.1.3 [compliance] Status: Review
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-05-23
          
+
          View other active issues in [compliance].
          
+
          View all other issues in [compliance].
          
+
          View all issues with Review status.
          
+
          Discussion:
          
+
+
          Addresses JP 23
          
+
+
          
+There is a freestanding implementation including
+<type_traits>, <array>,
+<ratio>, lately added to Table 13, C++ library headers.
+Programmers think them useful and hope that these headers are also added
+to Table 15, C++ headers for freestanding implementations, that shows
+the set of headers which a freestanding implementation shall include at
+least.
+
          
+
+
          Original proposed resolution
          
+
+
          
+Add <type_traits>, <array>,
+<ratio> to Table 15.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+
          
+ The <array> header has far too many dependencies to require for a
+free-standing implementation.
+
          
+
          
+The <ratio> header would be useful, has no dependencies, but is not
+strictly necessary.
+
          
+
          
+The <type_traits> header is fundamentally a core language facility with a
+library interface, so should be supported.
+
          
+
+
          
+(it is anticipated the resolution will come via an update to paper
+N2814)
+(see also LWG 833)
+
          
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+Leave in Review status pending a paper on freestanding implementations
+by Martin Tasker.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Add <type_traits> to Table 15.
+
          
+
+
+
+
+
+
+
          
+
          1004. Response to UK 179
          
+
          Section: 17.6.3.8 [res.on.functions] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-05-23
          
+
          View all other issues in [res.on.functions].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses UK 179
          
+
+
          
+According to the 4th bullet there is a problem if "if any replacement
+function or handler function or destructor operation throws an
+exception". There should be no problem throwing exceptions so long as
+they are caught within the function.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+The phrasing "throws an exception" is commonly used elsewhere
+to mean "throws or propagates an exception."
+Move to Open pending a possible more general resolution.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change the 4th bullet of 17.6.3.8 [res.on.functions], p2:
+
          
+
+
          
+
            
+
          • 
+if any replacement function or handler function or destructor operation
+throws propagates an exception, unless specifically
+allowed in the applicable Required behavior: paragraph.
+
            • 
+
          
+
          
+
+
+
+
+
+
+
          
+
          1005. Response to JP 26
          
+
          Section: 18.3.1.1 [numeric.limits] Status: Review
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-05-25
          
+
          View all issues with Review status.
          
+
          Discussion:
          
+
+
          Addresses JP 26
          
+
+
          
+numeric_limits [partial specializations] does not use concept.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Alisdair will provide a soltion as part of treatment of axioms and LWG 902.
+
          
+
+
          [
+Post Summit:
+]
          
+
+
+
          
+Alisdair recommends NAD as the partial specializations are already
+constrained by requirements on the primary template.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+The Working Draft does not in general repeat a primary template's constraints
+in any specializations.
+Move to NAD.
+
          
+
+
          [
+2009-05-25 Howard adds:
+]
          
+
+
+
          
+A c++std-lib thread starting at c++std-lib-23880 has cast doubt that NAD is the
+correct resolution of this issue.  Indeed the discussion also casts doubt that
+the current proposed wording is the correct resolution as well.  Personally I'm
+inclined to reset the status to Open.  However I'm reverting the status to 
+that which it had prior to the Batavia recommendation.  I'm setting back to Review.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 18.3.1.1 [numeric.limits]:
+
          
+
+
          template<class Regular T> class numeric_limits<const T>;
+template<class Regular T> class numeric_limits<volatile T>;
+template<class Regular T> class numeric_limits<const volatile T>;
+
          
+
+
+
+
+
+
+
          
+
          1006. Response to UK 190
          
+
          Section: 18.6.1 [new.delete] Status: Tentatively Ready
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-05-23
          
+
          View all other issues in [new.delete].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
+
          Addresses UK 190
          
+
+
          
+It is not entirely clear how the current specification acts in the
+presence of a garbage collected implementation.
+
          
+
+
          [
+Summit:
+]
          
+
+ 
+
          
+Agreed.
+
          
+
+
          [
+2009-05-09 Alisdair adds:
+]
          
+
+
+
          
+Proposed wording is too strict for implementations that do not support
+garbage collection.  Updated wording supplied.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We recommend advancing this to Tentatively Ready
+with the understanding that it will not be moved for adoption
+unless and until the proposed resolution to Core issue #853 is adopted.
+
          
+
+
+
          Proposed resolution:
          
+
+
          
+(Editorial note: This wording ties into the proposed
+resolution for Core #853)
+
          
+
+
          
+Add paragraphs to 18.6.1.1 [new.delete.single]:
+
          
+
+
          void operator delete(void* ptr) throw();
+void operator delete(void* ptr, const std::nothrow_t&) throw();
+
          
+
+
          [
+The second signature deletion above is editorial.
+]
          
+
+
+
          
+
          
+Requires: If an implementation has strict pointer safety
+(3.7.4.3 [basic.stc.dynamic.safety]) then ptr shall
+be a safely-derived pointer.
+
          
+
+
          -10- ...
          
+
          
+
+
          void operator delete(void* ptr, const std::nothrow_t&) throw();
+
          
+
+
          
+
          
+Requires: If an implementation has strict pointer safety
+(3.7.4.3 [basic.stc.dynamic.safety]) then ptr shall
+be a safely-derived pointer.
+
          
+
+
          -15- ...
          
+
          
+
+
          
+
+
          
+Add paragraphs to 18.6.1.2 [new.delete.array]:
+
          
+
+
          void operator delete[](void* ptr) throw();
+void operator delete[](void* ptr, const std::nothrow_t&) throw();
+
          
+
+
          [
+The second signature deletion above is editorial.
+]
          
+
+
+
          
+
          
+Requires: If an implementation has strict pointer safety
+(3.7.4.3 [basic.stc.dynamic.safety]) then ptr shall
+be a safely-derived pointer.
+
          
+
+
          -9- ...
          
+
          
+
+
          void operator delete[](void* ptr, const std::nothrow_t&) throw();
+
          
+
+
          
+
          
+Requires: If an implementation has strict pointer safety
+(3.7.4.3 [basic.stc.dynamic.safety]) then ptr shall
+be a safely-derived pointer.
+
          
+
+
          -13- ...
          
+
          
+
+
          
+
+
+
          
+Add paragraphs to 18.6.1.3 [new.delete.placement]:
+
          
+
+
          void operator delete(void* ptr, void*) throw();
+
          
+
+
          
+
          
+Requires: If an implementation has strict pointer safety
+(3.7.4.3 [basic.stc.dynamic.safety]) then ptr shall
+be a safely-derived pointer.
+
          
+
+
          -7- ...
          
+
          
+
+
          void operator delete[](void* ptr, void*) throw();
+
          
+
+
          
+
          
+Requires: If an implementation has strict pointer safety
+(3.7.4.3 [basic.stc.dynamic.safety]) then ptr shall
+be a safely-derived pointer.
+
          
+
+
          -9- ...
          
+
          
+
+
          
+
+
+
+
+
+
+
          
+
          1007. Response to JP 29
          
+
          Section: 18.8.6 [except.nested] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-03-13
          
+
          View other active issues in [except.nested].
          
+
          View all other issues in [except.nested].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses JP 29
          
+
+
          
+throw_with_nested does not use concept.
+
          
+
+
          [
+Summit:
+]
          
+
+ 
+
          
+Agreed.
+
          
+
+
+
+
          Proposed resolution:
          
+
+
          
+Alisdair initially proposed wording in
+N2619.
+
          
+
          
+We are awaiting an updated paper based on feedback from the San Francisco
+review.
+
          
+
+
+
+
+
+
          
+
          1008. Response to JP 31
          
+
          Section: 18.8.6 [except.nested] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-03-13
          
+
          View other active issues in [except.nested].
          
+
          View all other issues in [except.nested].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses JP 31
          
+
+
          
+It is difficult to understand in which case nested_exception is applied.
+
          
+
+
          [
+Summit:
+]
          
+
+ 
+
          
+Alisdair will add an example in an update to
+N2619.
+
          
+
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1009. Response to UK 251
          
+
          Section: 24.2.1 [iterator.iterators] Status: Review
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-03-22
          
+
          View all issues with Review status.
          
+
          Discussion:
          
+
+
          Addresses UK 251
          
+
+
          
+The post-increment operator is dangerous for a general InputIterator.
+The multi-pass guarantees that make it meaningful are defined as part of
+the ForwardIterator refinement. Any change will affect only constrained
+templates that have not yet been written, so should not break existing
+user iterators which remain free to add these operations. This change
+will also affect the generalised OutputIterator, although there is no
+percieved need for the post-increment operator in this case either.
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+Change 24.2.1 [iterator.iterators]:
+
          
+
+
          concept Iterator<typename X> : Semiregular<X> { 
+  MoveConstructible reference = typename X::reference; 
+  MoveConstructible postincrement_result;
+
+  requires HasDereference<postincrement_result>;
+
+  reference operator*(X&&); 
+  X& operator++(X&); 
+  postincrement_result operator++(X&, int);
+}
+
          
+
+
          ...
          
+
          postincrement_result operator++(X& r, int);
+
          
+
+
          
+-3- Effects: equivalent to { X tmp = r; ++r; return tmp; }.
+
          
+
+
          
+
+
          
+Change 24.2.2 [input.iterators]:
+
          
+
+
          
+
          concept InputIterator<typename X> : Iterator<X>, EqualityComparable<X> { 
+  ObjectType value_type = typename X::value_type; 
+  MoveConstructible pointer = typename X::pointer; 
+
+  SignedIntegralLike difference_type = typename X::difference_type; 
+
+  requires IntegralType<difference_type> 
+        && Convertible<reference, const value_type &>; 
+        && Convertible<pointer, const value_type*>; 
+
+  requires Convertible<HasDereference<postincrement_result>::result_type, const value_type&>;
+
+  pointer operator->(const X&); 
+}
+
          
+
          
+
+
          
+Change 24.2.3 [output.iterators]:
+
          
+
+
          
+
          auto concept OutputIterator<typename X, typename Value> { 
+  requires Iterator<X>; 
+
+  typename reference = Iterator<X>::reference; 
+  typename postincrement_result = Iterator<X>::postincrement_result;
+  requires SameType<reference, Iterator<X>::reference> 
+        && SameType<postincrement_result, Iterator<X>::postincrement_result>
+        && Convertible<postincrement_result, const X&>
+        && HasAssign<reference, Value> 
+        && HasAssign<HasDereference<postincrement_result>::result_type, Value>;
+}
+
          
+
          
+
+
          
+Change 24.2.4 [forward.iterators]:
+
          
+
+
          [
+See 1084 which is attempting to change this same area in a compatible
+way.
+]
          
+
+
+
          
+
          concept ForwardIterator<typename X> : InputIterator<X>, Regular<X> { 
+  requires Convertible<postincrement_result, const X&>;
+
+  MoveConstructible postincrement_result;
+  requires HasDereference<postincrement_result>
+        && Convertible<HasDereference<postincrement_result>::result_type, const value_type&>;
+
+  postincrement_result operator++(X&, int);
+
+  axiom MultiPass(X a, X b) { 
+    if (a == b) *a == *b; 
+    if (a == b) ++a == ++b; 
+  } 
+}
+
          
+
+
          
+
          -4- ...
          
+
          
+
+
          postincrement_result operator++(X& r, int);
+
          
+
+
          
+
          
+-5- Effects: equivalent to { X tmp = r; ++r; return tmp; }.
+
          
+
          
+
+
          
+
+
+
+
+
+
+
          
+
          1010. Response to UK 263
          
+
          Section: 24.2.6 [random.access.iterators] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-05-23
          
+
          View other active issues in [random.access.iterators].
          
+
          View all other issues in [random.access.iterators].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses UK 263
          
+
+
          
+This requirement on operator-= would be better expressed as a default
+implementation in the concept, with a matching axiom.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+The proposed resolution should also remove
+paragraph 5 and the declaration that precedes it.
+Further, we should provide an axiom
+that captures the desired semantics.
+This may be a broader policy to be applied.
+Move to Open.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 24.2.6 [random.access.iterators]:
+
          
+
+
          concept RandomAccessIterator<typename X> : BidirectionalIterator<X>, LessThanComparable<X> {
+  ...
+  X& operator-=(X& x, difference_type n) { return x += -n; }
+  ...
+}
+
          
+
+
+
+
+
+
+
          
+
          1011. Response to UK 271
          
+
          Section: 24.4 [iterator.operations] Status: Tentatively Ready
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-05-23
          
+
          View other active issues in [iterator.operations].
          
+
          View all other issues in [iterator.operations].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
+
          Addresses UK 271
          
+
+
          
+next/prev return an incremented iterator without changing the value of
+the original iterator. However, even this may invalidate an
+InputIterator. A ForwardIterator is required to guarantee the
+'multipass' property.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change  [iterator.synopsis]:
+
          
+
+
          template <InputIterator ForwardIterator Iter> 
+  Iter next(Iter x, 
+    Iter::difference_type n = 1);
+
          
+
+
          
+Change 24.4 [iterator.operations], p6:
+
          
+
+
          template <InputIterator ForwardIterator Iter> 
+  Iter next(Iter x, 
+    Iter::difference_type n = 1);
+
          
+
+
+
+
+
+
+
          
+
          1012. Response to UK 277
          
+
          Section: 24.5.1.2.1 [reverse.iter.cons] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-05-23
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses UK 277
          
+
+
          
+The default constructor default-initializes current, rather than
+value-initializes. This means that when Iterator corresponds to a
+trivial type, the current member is left un-initialized, even when the
+user explictly requests value intialization! At this point, it is not
+safe to perform any operations on the reverse_iterator other than assign
+it a new value or destroy it. Note that this does correspond to the
+basic definition of a singular iterator.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Agree with option i.
+
          
+
+
          
+Related issue: 408
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We believe this should be revisited
+in conjunction with issue 408,
+which nearly duplicates this issue.
+Move to Open.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change  [reverse.iter.con]:
+
          
+
+
          reverse_iterator();
+
          
+
          
+-1- Effects: Default Value initializes current. Iterator
+operations applied to the resulting iterator have defined behavior if and
+only if the corresponding operations are defined on a default constructed
+iterator of type Iterator.
+
          
+
          
+
+
          
+Change 24.5.3.2.1 [move.iter.op.const]:
+
          
+
+
          move_iterator();
+
          
+
          
+-1- Effects: Constructs a move_iterator, default value
+initializing current.
+
          
+
          
+
+
+
+
+
+
+
          
+
          1013. Response to UK 305
          
+
          Section: 25.5.7 [alg.min.max] Status: Tentatively Ready
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-05-23
          
+
          View other active issues in [alg.min.max].
          
+
          View all other issues in [alg.min.max].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
+
          Addresses UK 305
          
+
+
          
+The negative requirement on IsSameType is a hold-over from an earlier
+draught with a variadic template form of min/max algorith. It is no
+longer necessary.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 25 [algorithms]:
+
          
+
+
          template<class T, StrictWeakOrder<auto, T> Compare>
+  requires !SameType<T, Compare> && CopyConstructible<Compare>
+  const T& min(const T& a, const T& b, Compare comp);
+...
+template<class T, StrictWeakOrder<auto, T> Compare>
+  requires !SameType<T, Compare> && CopyConstructible<Compare>
+  const T& max(const T& a, const T& b, Compare comp);
+...
+template<class T, StrictWeakOrder<auto, T> Compare>
+  requires !SameType<T, Compare> && CopyConstructible<Compare>
+  pair<const T&, const T&> minmax(const T& a, const T& b, Compare comp);
+
          
+
+
          
+Change 25.5.7 [alg.min.max], p1, p9 and p17:
+
          
+
+
          template<class T, StrictWeakOrder<auto, T> Compare>
+  requires !SameType<T, Compare> && CopyConstructible<Compare>
+  const T& min(const T& a, const T& b, Compare comp);
+...
+template<class T, StrictWeakOrder<auto, T> Compare>
+  requires !SameType<T, Compare> && CopyConstructible<Compare>
+  const T& max(const T& a, const T& b, Compare comp);
+...
+template<class T, StrictWeakOrder<auto, T> Compare>
+  requires !SameType<T, Compare> && CopyConstructible<Compare>
+  pair<const T&, const T&> minmax(const T& a, const T& b, Compare comp);
+
          
+
+
+
+
+
+
+
          
+
          1014. Response to UK 317 and JP 74
          
+
          Section: 28.9.2 [re.regex.construct] Status: Tentatively Ready
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-05-23
          
+
          View all other issues in [re.regex.construct].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
+
          Addresses UK 317 and JP 74
          
+
+
          
+UK 317:
+
          
+
+
          
+basic_string has both a constructor and an assignment operator that
+accepts an initializer list, basic_regex should have the same.
+
          
+
+
          
+JP 74:
+
          
+
+
          
+basic_regx & operator= (initializer_list<T>); is not defined.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+UK 317 asks for both assignment and constructor,
+but the requested constructor is already present in the current Working Paper.
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 28.9 [re.regex]:
+
          
+
+
          template <class charT,
+          class traits = regex_traits<charT> >
+class basic_regex {
+  ...
+  basic_regex& operator=(const charT* ptr);
+  basic_regex& operator=(initializer_list<charT> il);
+  template <class ST, class SA>
+    basic_regex& operator=(const basic_string<charT, ST, SA>& p);
+  ...
+};
+
          
+
+
          
+Add in  28.9.2 [re.regex.construct]:
+
          
+
+
          
+
          
+-20- ...
+
          
+
          basic_regex& operator=(initializer_list<charT> il);
+
          
+
          
+-21- Effects: returns assign(il.begin(), il.end());
+
          
+
          
+
+
+
+
+
+
+
          
+
          1015. Response to UK 199
          
+
          Section: 20.2.1 [concept.transform] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-05-23
          
+
          View other active issues in [concept.transform].
          
+
          View all other issues in [concept.transform].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses UK 199
          
+
+
          
+The requirement that programs do not supply concept_maps should
+probably be users do not supply their own concept_map
+specializations. The program will almost certainly supply
+concept_maps - the standard itself supplies a specialization
+for RvalueOf references. Note that the term program is
+defined in 3.5 [basic.link]p1 and makes no account of the
+standard library being treated differently to user written code.
+
          
+
+
          [
+2009-05-09 Alisdair adds:
+]
          
+
+
+
          
+
          
+The same problem is present in the words added for the
+LvalueReference/RvalueReference concepts last meeting.
+
          
+
          
+With three subsections requiring the same constraint, I'm wondering if there
+is a better way to organise this section.
+Possible 20.2.1 -> 20.2.3 belong in the fundamental concepts clause in
+14.10.4 [concept.support]?  While they can be implemented purely as a
+library feature without additional compiler support, they are pretty
+fundamental and we want the same restriction on user-concept maps as is
+mandated there.
+
          
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the issue,
+but believe the wording needs further improvement.
+We want to investigate current definitions for nomenclature such as
+"user" and "program."
+Move to Open pending the recommended investigation.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 20.2.1 [concept.transform] p2:
+
          
+
+
          
+-2- A program user shall not provide concept maps for
+any concept in 20.1.1.
+
          
+
+
          
+Change 20.2.2 [concept.true] p2:
+
          
+
+
          
+-2- Requires: a program user shall not
+provide a concept map for the True concept.
+
          
+
+
          
+Change 20.2.3 [concept.classify] p2:
+
          
+
+
          
+-2- Requires: a programuser shall not provide concept
+maps for any concept in this section.
+
          
+
+
+
+
+
+
+
          
+
          1016. Response to JP 33
          
+
          Section: 20.2.6 [concept.comparison] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-03-12
          
+
          View other active issues in [concept.comparison].
          
+
          View all other issues in [concept.comparison].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses JP 33
          
+
+
          
+LessThanComparable and EqualityComparable don't correspond to NaN. 
+
          
+
+
          Original proposed resolution:
          
+
+
          
+Apply concept_map to these concepts at FloatingPointType.
+
          
+
+
          [
+Post Summit, Alisdair adds:
+]
          
+
+
+
          
+
          
+I don't understand the proposed resolution - there is no such thing as a
+'negative' concept_map, and these concepts are auto concepts that match
+float/double etc. Also not clear how we are supposed to match values to
+concepts.
+
          
+
          
+Recommend NAD and treat as a subset of issue 902.
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+Recommend NAD.
+
          
+
+
+
+
+
+
          
+
          1017. Response to US 66
          
+
          Section: 20.2.11 [concept.regular] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-03-12
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses US 66
          
+
+
          
+Application of the Regular concept to floating-point types appears to be
+controversial (see long discussion on std-lib reflector). 
+
          
+
+
          Original proposed resolution:
          
+
+
          
+State that the Regular concept does not apply to floating-point types. 
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+
          
+Recommend that we handle the same as JP 33 / 1016.
+
          
+
          
+
+
          [
+Post Summit, Alisdair adds:
+]
          
+
+
+
          
+
          
+Recommend Open, and review after resolution of 902 and revised axiom
+feature.
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1018. Response to US 70
          
+
          Section: 20.6 [meta] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-03-12
          
+
          View other active issues in [meta].
          
+
          View all other issues in [meta].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses US 70
          
+
+
          
+Specifications now expressed via narrative text are more accurately and
+clearly expressed via executable code.
+
          
+
          
+Wherever concepts are available that directly match this section's type
+traits, express the traits in terms of the concepts instead of via
+narrative text. Where the type traits do not quite match the
+corresponding concepts, bring the two into alignment so as to avoid two
+nearly-identical notions.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+
          
+We think that this is a good idea, but it requires a lot of work. If someone
+submits a paper proposing specific changes, we would be happy to review it
+at the next meeting.
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1019. Response to UK 205
          
+
          Section: 20.6.3 [meta.help] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-05-23
          
+
          View other active issues in [meta.help].
          
+
          View all other issues in [meta.help].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses UK 205
          
+
+
          
+integral_constant objects should be usable in integral-constant-expressions.
+The addition to the language of literal types and the enhanced rules for
+constant expressions make this possible.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree that the static data member
+ought be declared constexpr,
+but do not see a need for the proposed operator value_type().
+(A use case would be helpful.)
+Move to Open.
+
          
+
+
          [
+2009-05-23 Alisdair adds:
+]
          
+
+
+
          
+
          
+The motivating case in my mind is that we can then use
+true_type and false_type as integral Boolean expressions, for example inside
+a static_assert declaration.  In that sense it is purely a matter of style.
+
          
+
          
+Note that Boost has applied the non-explicit conversion operator for many
+years as it has valuable properties for extension into other metaprogramming
+libraries, such as MPL.  If additional rationale is desired I will poll the
+Boost lists for why this extension was originally applied.  I would argue
+that explicit conversion is more appropriate for 0x though.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+Add to the integral_constant struct definition in 20.6.3 [meta.help]:
+
          
+
+
          template <class T, T v>
+struct integral_constant {
+  static constexpr T value = v;
+  typedef T value_type;
+  typedef integral_constant<T,v> type;
+  constexpr operator value_type() { return value; }
+};
+
          
+
+
+
+
+
+
          
+
          1020. Response to UK 204
          
+
          Section: 20.6.7 [meta.trans.other] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-03-12
          
+
          View other active issues in [meta.trans.other].
          
+
          View all other issues in [meta.trans.other].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses UK 204
          
+
+
          
+It is not possible to create a variant union based on a parameter pack
+expansion, e.g. to implement a classic discriminated union template. 
+
          
+
+
          Original proposed resolutuion:
          
+
+
          
+Restore aligned_union template that was removed by LWG issue 856. 
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Agree. The need for aligned_union is compelling enough to reinstate.
+
          
+
+
          [
+Post Summit, Alisdair adds:
+]
          
+
+
+
          
+paper
+N2843
+proposes an extension to the [[align]] attribute
+that further diminishes the need for this template.  Recommend NAD.
+
          
+
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1021. Response to UK 211
          
+
          Section: 20.8.12.2.3 [unique.ptr.single.asgn] Status: Tentatively Ready
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-05-23
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
+
          Addresses UK 211
          
+
+
          
+The nullptr_t type was introduced to resolve the null pointer literal
+problem. It should be used for the assignemnt operator, as with the
+constructor and elsewhere through the library.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change the synopsis in 20.8.12.2 [unique.ptr.single]:
+
          
+
+
          unique_ptr& operator=(unspecified-pointer-type nullptr_t);
+
          
+
+
          
+Change 20.8.12.2.3 [unique.ptr.single.asgn]:
+
          
+
+
          unique_ptr& operator=(unspecified-pointer-type nullptr_t);
+
          
+
          
+Assigns from the literal 0 or NULL. [Note: The
+unspecified-pointer-type is often implemented as a pointer to a
+private data member, avoiding many of the implicit conversion pitfalls.
+-- end note]
+
          
+
          
+
+
+
+
+
+
          
+
          1023. Response to DE 22
          
+
          Section: 20.7.16.2 [func.wrap.func] Status: Tentatively NAD Editorial
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-05-23
          
+
          View other active issues in [func.wrap.func].
          
+
          View all other issues in [func.wrap.func].
          
+
          View all issues with Tentatively NAD Editorial status.
          
+
          Discussion:
          
+
+
          Addresses DE 22
          
+
+
          Related to issue 1114.
          
+
+
          
+The conditions for deriving from std::unary_function and
+std::binary_function are unclear: The condition would also be satisfied if
+ArgTypes were std::vector<T1>, because it (arguably)
+"contains" T1.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Agree. std::reference_wrapper has the same structure, and we
+suggest that std::function be presented in the same way as
+std::reference_wrapper.
+
          
+
+
          [
+2009-05-09 Alisdair adds:
+]
          
+
+
+
          
+Phrasing should be "publicly and
+unambiguously derived from" and probably back in reference_wrapper too.  Updated
+wording supplied.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed wording.
+Move to NAD Editorial.
+
          
+
+
+
          Proposed resolution:
          
+
          
+(no changes to <functional> synopsis required)
+
          
+
+
          
+Change synopsis in Class template function 20.7.16.2 [func.wrap.func]:
+
          
+
+
          template<Returnable R, CopyConstructible... ArgTypes> 
+class function<R(ArgTypes...)> 
+  : public unary_function<T1, R>      // iff sizeof...(ArgTypes) == 1 and see below
+                                      // ArgTypes contains T1
+  : public binary_function<T1, T2, R> // iff sizeof...(ArgTypes) == 2 and see below
+                                      // ArgTypes contains T1 and T2
+{
+   ...
+
          
+
+
          
+Add new p1/p2 before 20.7.16.2.1 [func.wrap.func.con]:
+
          
+
+
          
+
          
+The template instantiation function<R(T1)> shall be publicly and
+unambiguously derived from 
+std::unary_function<T1,R> if and only if the template type parameter
+is a function type taking one argument of type T1 and returning R.
+
          
+
+
          
+The template instantiation function<R(T1,T2)> shall be publicly and
+unambiguously derived from 
+std::binary_function<T1,T2,R> if and only if the template type
+parameter is a function type taking two arguments of type T1 and T2 and
+returning R.
+
          
+
+
          explicit function();
+
          
+
          
+
+
+
+
+
+
+
          
+
          1024. Response to JP 39
          
+
          Section: 20.7.16.2 [func.wrap.func] Status: Tentatively Ready
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-05-23
          
+
          View other active issues in [func.wrap.func].
          
+
          View all other issues in [func.wrap.func].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
+
          Addresses JP 39
          
+
+
          
+There are no requires corresponding to F of std::function.
+
          
+
+
          [
+2009-05-01 Daniel adds:
+]
          
+
+
+
          
+1070 removes the second constructor.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+If issue 1070 is accepted,
+the changes to the second constructor
+in this issue are moot.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Correct as follows in 20.7.16.2 [func.wrap.func] (class definition)
+
          
+
+
           template<class F, Allocator Alloc>
+   requires ConstructibleWithAllocator<F, Alloc>
+     && call=Callable<F, ArgTypes...>
+     && Convertible<call::result_type, R>
+   function(allocator_arg_t, const Alloc&, F);
+ template<class F, Allocator Alloc>
+   requires ConstructibleWithAllocator<F,Alloc>
+     && call=Callable<F, ArgTypes...>
+     && Convertible<call::result_type, R>
+   function(allocator_arg_t, const Alloc&, F&&);
+
          
+
+
+
+
+
+
+
          
+
          1026. Response to UK 209
          
+
          Section: 20.8 [memory] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-03-12
          
+
          View other active issues in [memory].
          
+
          View all other issues in [memory].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses UK 209
          
+
+
          
+Smart pointers cannot be used in constrained templates.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+We look forward to a paper on this topic. We recommend no action until a
+paper is available. We understand that a paper is forthcoming.
+
          
+
+
          [
+Peter Dimov adds:
+]
          
+
+
+
          
+shared_ptr<T> and weak_ptr<T> support all
+types T for which T* is valid. In other words, a
+possible (partial) resolution is to change class T to
+PointeeType T for shared_ptr, weak_ptr and
+possibly enable_shared_from_this.
+
          
+
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1027. Response to UK 213
          
+
          Section: 20.8.6 [default.allocator] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-03-13
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses UK 213
          
+
+
          
+std::allocator should be constrained to simplify its use on constrained
+contexts. This library component models allocation from free store via the
+new operator so choose constraints to 
+match. The Allocator concept allows for a wider variety of allocators that
+users may choose to supply if their allocation model does not require
+operator new, without impacting the 
+requirements of this template. 
+
          
+
+
          
+Suggested direction:
+
          
+
          
+The primary allocator template should be constrained to require
+ObjectType<T> and FreeStoreAllocatable<T>.
+Further operations to be constrained as required.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Agree as stated. A future paper will address additional related issues.
+
          
+
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1028. Response to UK 214
          
+
          Section: 20.8.8 [storage.iterator] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-03-15
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses UK 214
          
+
+
          
+raw_storage_iterator needs constraining as an iterator adaptor to be safely
+used in constrained templates 
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+We look forward to a paper on this topic. We recommend no action until a
+paper is available.
+
          
+
+
          [
+Post Summit Alisdair provided wording and rationale.
+]
          
+
+
+
+
+
          Proposed resolution:
          
+
          
+20.8 [memory] p2
+
          
+
          
+Update the synopsis for <memory>
+
          
+
          // 20.7.8, raw storage iterator:
+template <class ForwardIterator OutputIterator, class ObjectType T> 
+  requires OutputIterator< OutIter, T >
+    class raw_storage_iterator;
+
+template <ForwardIterator OutIter, ObjectType T> 
+  requires OutputIterator< OutIter, T >
+  concept_map Iterator<raw_storage_iterator< OutIter, T > > { }
+
          
+
+
+
          
+20.8.8 [storage.iterator] p1
+
          
+
          
+Replace class template definition with:
+
          
+
          namespace std { 
+  template <class ForwardIterator OutputIterator, class ObjectType T> 
+    requires OutputIterator< OutIter, T >
+  class raw_storage_iterator 
+    : public iterator<output_iterator_tag,void,void,void,void> { 
+  public: 
+    explicit raw_storage_iterator(OutputIterator x); 
+
+    raw_storage_iterator<OutputIterator,T>& operator*(); 
+    raw_storage_iterator<OutputIterator,T>& operator=(const T& element); 
+    raw_storage_iterator<OutputIterator,T>& operator++(); 
+    raw_storage_iterator<OutputIterator,T> operator++(int); 
+  }; 
+
+  template <ForwardIterator OutIter, ObjectType T> 
+    requires OutputIterator< OutIter, T >
+    concept_map Iterator<raw_storage_iterator< OutIter, T > > { }
+}
+
          
+
+
+
          Rationale:
          
+
          
+raw_storage_iterator has to adapt a ForwardIterator,
+rather than just an InputIterator for two reasons:
+
          
+
+
            
+
          1. 
+The initial iterator passed by value is expected to remain valid,
+pointing to the initialized region of memory.
+
            2. 
+
          2. 
+to avoid breaking the declaration of post-increment operator which would
+require some kind of proxy formulation to support generalised InputIterators.
+
            3. 
+
          
+
+
+
+
+
+
+
          
+
          1029. Response to UK 210
          
+
          Section: 20.8.11 [specialized.algorithms] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-03-15
          
+
          View all other issues in [specialized.algorithms].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses UK 210
          
+
+
          Related to 582
          
+
+
          
+Specialized algorithms for memory managenment need requirements to be
+easily usable in constrained templates.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+We look forward to a paper on this topic. We recommend no action until a
+paper is available.
+
          
+
+
          [
+Post Summit Alisdair provided wording.
+]
          
+
+
+
          [
+Post Summit:
+]
          
+
+
+
          
+
          
+Daniel adds:
+
          
+
+
          
+
            
+
          1. 
+I suggest Size should require IntegralLike and not UnsignedIntegralLike,
+because otherwise simple int-literals could not be provided as arguments
+and it would conflict with other algorithms that only require IntegralLike.
+
            2. 
+
          2. 
+
            
+The current for-loop-test relies on evaluation in boolean context which is
+not provided by ArithmeticLike and it's refinements. I propose to change the
+corresponding for-loop-headers to:
+
            
+
              
+
            1. 
+for uninitialized_copy_n: for ( ; n > Size(0); ++result, ++first, --n) {
+
              2. 
+
            2. 
+for uninitialized_fill_n: for (; n > Size(0); ++first, --n) {
+
              3. 
+
            
+
            3. 
+
          
+
          
+
+
          
+Alisdair adds:
+
          
+
          
+For the record I agree with Daniel's suggestion.
+
          
+
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+20.8 [memory] p2
+
          
+
          
+Update the synopsis for <memory>
+
          
+
          template <class InputIterator InIter,
+         class ForwardIterator OutputIterator<auto, InIter::reference> OutIter> 
+   requires ForwardIterator<OutIter>
+   ForwardIterator OutIter
+   uninitialized_copy(InputIterator InIter first, InputIterator InIter last, 
+                      ForwardIterator OutIter result);
+
+template <class InputIterator InIter,
+          class IntegralLike Size,
+          class ForwardIterator OutputIterator<auto, InIter::reference> OutIter> 
+  requires ForwardIterator<OutIter>
+  ForwardIterator OutIter
+  uninitialized_copy_n(InputIterator InIter first, Size n, 
+                       ForwardIterator OutIter result);
+
+template <class ForwardIterator Iter, class ObjectType T>
+  requires Constructible< Iter::value_type, const T& >
+  void uninitialized_fill(ForwardIterator Iter first, ForwardIterator Iter last, 
+                          const T& x);
+
+template <class ForwardIterator Iter, class IntegralLike Size, class ObjectType T> 
+  requires Constructible< Iter::value_type, const T& >
+  void
+  uninitialized_fill_n(ForwardIterator Iter first, Size n, const T& x);
+
          
+
+
          
+Update as follows:
+
          
+
+
          
+uninitialized_copy 20.8.11.2 [uninitialized.copy]
+
          
+
+
          template <class InputIterator InIter,
+         class ForwardIterator OutputIterator<auto, InIter::reference> OutIter> 
+   requires ForwardIterator<OutIter>
+   ForwardIterator OutIter
+   uninitialized_copy(InputIterator InIter first, InputIterator InIter last, 
+                      ForwardIterator OutIter result);
+
          
+
+
          
+
          
+-1- Effects:
+
          
+
          for (; first != last; ++result, ++first)  {
+   new (static_cast<void*>(&*result))
+       typename iterator_traits<ForwardIterator> OutIter::value_type(*first);
+}
+
          
+
+
          
+-2- Returns: result
+
          
+
+
          
+
+
          template <class InputIterator InIter,
+          class IntegralLike Size,
+          class ForwardIterator OutputIterator<auto, InIter::reference> OutIter> 
+  requires ForwardIterator<OutIter>
+  ForwardIterator OutIter
+  uninitialized_copy_n(InputIterator InIter first, Size n, 
+                       ForwardIterator OutIter result);
+
          
+
+
          
+
          
+-3- Effects:
+
          
+
          for ( ; n > Size(0); ++result, ++first, --n) {
+   new (static_cast<void*>(&*result))
+       typename iterator_traits<ForwardIterator> OutIter::value_type(*first);
+}
+
          
+
          
+-4- Returns: result
+
          
+
          
+
+
          
+
+
+
          
+uninitialized_fill 20.8.11.3 [uninitialized.fill]
+
          
+
+
          template <class ForwardIterator Iter, class ObjectType T>
+  requires Constructible< Iter::value_type, const T& >
+  void uninitialized_fill(ForwardIterator Iter first, ForwardIterator Iter last, 
+                          const T& x);
+
          
+
+
          
+
          
+-1- Effects:
+
          
+
          for (; first != last; ++first) {
+   new ( static_cast<void*>( &*first) ) 
+       typename iterator_traits<ForwardIterator> Iter::value_type(x);
+}
+
          
+
          
+
          
+
+
+
          
+uninitialized_fill_n 20.8.11.4 [uninitialized.fill.n]
+
          
+
+
          template <class ForwardIterator Iter, class IntegralLike Size, class ObjectType T> 
+  requires Constructible< Iter::value_type, const T& >
+  void
+  uninitialized_fill_n(ForwardIterator Iter first, Size n, const T& x);
+
          
+
+
          
+
          
+-1- Effects:
+
          
+
          for (; n-- > Size(0); ++first, --n) {
+   new ( static_cast<void*>( &*first) ) 
+       typename iterator_traits<ForwardIterator> Iter::value_type(x);
+}
+
          
+
          
+
          
+
+
+
+
+
+
+
          
+
          1030. Response to JP 44
          
+
          Section: 20.8.13.6 [util.smartptr.shared.atomic] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-03-12
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses JP 44
          
+
+
          
+The 1st parameter p and 2nd parameter v is now
+shared_ptr<T>*.
+
          
+
          
+It should be shared_ptr<T>&, or if these are
+shared_ptr<T>* then add the "p shall not be a
+null pointer" at the requires.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Agree. All of the functions need a requirement that p (or
+v) is a pointer to a valid object.
+
          
+
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1031. Response to US 78
          
+
          Section: 20.8.13.2 [util.smartptr.shared] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-03-12
          
+
          View other active issues in [util.smartptr.shared].
          
+
          View all other issues in [util.smartptr.shared].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses US 78
          
+
+
          
+There is presently no way to convert directly from a shared_ptr to a
+unique_ptr. Add an interface that performs the conversion. 
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+We look forward to a paper on this topic. We recommend no action until a
+paper is available. We believe that the shared pointer must use the default
+deleter for the conversion to succeed.
+
          
+
+
          [
+Peter Dimov adds:
+]
          
+
+
+
          
+This is basically a request for shared_ptr<>::release in
+disguise, with all the associated problems. Not a good idea.
+
          
+
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1032. Response to JP 45
          
+
          Section: 20.9 [time] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-03-12
          
+
          View all other issues in [time].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses JP 45
          
+
+
          
+Rep, Period, Clock and Duration
+don't correspond to concept.
+
          
+
          template <class Rep, class Period = ratio<1>> class duration; 
+template <class Clock, class Duration = typename Clock::duration> class time_point; 
+
          
+
          
+Make concept for Rep, Period, Clock and Duration.
+Fix 20.9 [time] and wait_until
+and wait_for's template parameter at 30 [thread]. 
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+We agree that this section needs concepts. We look forward to a paper on
+this topic. We recommend no action until a paper is available.
+
          
+
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1033. thread::join() effects?
          
+
          Section: 30.3.1.5 [thread.thread.member] Status: Open
+ Submitter: Alberto Ganesh Barbati Opened: 2009-03-12  Last modified: 2009-05-23
          
+
          View other active issues in [thread.thread.member].
          
+
          View all other issues in [thread.thread.member].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          
+While looking at thread::join() I think I spotted a couple of
+possible defects in the specifications. I could not find a previous
+issue or NB comment about that, but I might have missed it.
+
          
+
+
          
+The postconditions clause for thread::join() is:
+
          
+
+
          
+Postconditions: If join() throws an exception, the value
+returned by get_id() is unchanged. Otherwise, get_id() == id().
+
          
+
+
          
+and the throws clause is:
+
          
+
+
          
+Throws: std::system_error when the postconditions cannot be achieved.
+
          
+
+
          
+Now... how could the postconditions not be achieved?
+It's just a matter of resetting the value of get_id() or leave it
+unchanged! I bet we can always do that. Moreover, it's a chicken-and-egg
+problem: in order to decide whether to throw or not I depend on the
+postconditions, but the postconditions are different in the two cases.
+
          
+
+
          
+I believe the throws clause should be:
+
          
+
+
          
+Throws: std::system_error when the effects or postconditions
+cannot be achieved.
+
          
+
+
          
+as it is in detach(), or, even better, as the postcondition is
+trivially satisfiable and to remove the circular dependency:
+
          
+
+
+
          
+Throws: std::system_error if the effects cannot be achieved.
+
          
+
+
          
+Problem is that... ehm... join() has no "Effects" clause. Is that intentional?
+
          
+
+
          [
+See the thread starting at c++std-lib-23204 for more discussion.
+]
          
+
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Pete believes there may be some more general language (in frontmatter)
+that can address this and related issues such as 962.
+
          
+
          
+Move to Open.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1034. Response to UK 222
          
+
          Section: 23.2.1 [container.requirements.general] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-12  Last modified: 2009-03-12
          
+
          View other active issues in [container.requirements.general].
          
+
          View all other issues in [container.requirements.general].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses UK 222
          
+
+
          
+It is not clear what purpose the Requirement tables serve in the
+Containers clause. Are they the definition of a library Container? Or
+simply a conventient shorthand to factor common semantics into a single
+place, simplifying the description of each subsequent container? This
+becomes an issue for 'containers' like array, which does not meet the
+default-construct-to-empty requirement, or forward_list which does not
+support the size operation. Are these components no longer containers?
+Does that mean the remaining requirements don't apply? Or are these
+contradictions that need fixing, despite being a clear design decision?
+
          
+
+
          
+Recommend:
+
          
+
+
          
+Clarify all the tables in 23.2 [container.requirements] are
+there as a convenience for documentation, rather than a strict set of
+requirements. Containers should be allowed to relax specific
+requirements if they call attention to them in their documentation. The
+introductory text for array should be expanded to mention a
+default constructed array is not empty, and
+forward_list introduction should mention it does not provide
+the required size operation as it cannot be implemented
+efficiently.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Agree in principle.
+
          
+
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1035. Response to UK 226
          
+
          Section: 23.2.1 [container.requirements.general] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-12  Last modified: 2009-05-02
          
+
          View other active issues in [container.requirements.general].
          
+
          View all other issues in [container.requirements.general].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses UK 226
          
+
+
          
+<array> must be added to this list. In particular it
+doesn't satisfy: - no swap() function invalidates any
+references, pointers, or iterators referring to the elements of the
+containers being swapped. and probably doesn't satisfy: - no
+swap() function throws an exception.
+
          
+
          
+If <array> remains a container, this will have to also
+reference array, which will then have to say which of these
+points it satisfies.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Agree. The proposed resolution is incomplete. Further work required.
+
          
+
+
          [
+2009-05-01 Daniel adds:
+]
          
+
+
+
          
+Issue 1099 also suggests
+adding move constructor to this.
+
          
+
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1036. Response to UK 231
          
+
          Section: 23.2.3 [sequence.reqmts] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-12  Last modified: 2009-03-12
          
+
          View other active issues in [sequence.reqmts].
          
+
          View all other issues in [sequence.reqmts].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses UK 231
          
+
+
          
+p9-p11 are redundant now that Concepts define what it means to be an
+Iterator and guide overload resolution accordingly. 
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Agree with issue and change to 23.2.3 [sequence.reqmts]. The
+changes required to 21 [strings] will be part of the general
+concept support for that clause.
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+Strike 23.2.3 [sequence.reqmts]p9-11. Make sure std::basic_string
+has constraints similar to
+std::vector to meet this old guarantee. 
+
          
+
+
+
+
+
+
          
+
          1037. Response to UK 232
          
+
          Section: 23.2.3 [sequence.reqmts] Status: Tentatively Ready
+ Submitter: Alisdair Meredith Opened: 2009-03-12  Last modified: 2009-05-23
          
+
          View other active issues in [sequence.reqmts].
          
+
          View all other issues in [sequence.reqmts].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
+
          Addresses UK 232
          
+
+
          
+match_results may follow the requirements but is not listed a general
+purpose library container.
+
          
+
+
          
+Remove reference to match_results against a[n] operation.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Agree. operator[] is defined elsewhere.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
          
+In 23.2.3 [sequence.reqmts] Table 84, remove reference to
+match_results in the row describing the a[n] operation.
+
          
+
+
+
+
+
+
          
+
          1038. Response to UK 233
          
+
          Section: 23.2.3 [sequence.reqmts] Status: Tentatively Ready
+ Submitter: Alisdair Meredith Opened: 2009-03-12  Last modified: 2009-05-23
          
+
          View other active issues in [sequence.reqmts].
          
+
          View all other issues in [sequence.reqmts].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
+
          Addresses UK 233
          
+
+
          
+Table 84 is missing references to several new container types.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Agree.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
          
+In 23.2.3 [sequence.reqmts] Table 84, Add reference to listed
+containers to the following rows:
+
          
+
+
          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
          Table 84 -- Optional sequence container operations
          ExpressionReturn typeOperational semanticsContainer
          a.front()......vector, list, deque, basic_string, array, forward_list
          a.back()......vector, list, deque, basic_string, array
          a.emplace_front(args)......list, deque, forward_list
          a.push_front(t)......list, deque, forward_list
          a.push_front(rv)......list, deque, forward_list
          a.pop_front()......list, deque, forward_list
          a[n]......vector, deque, basic_string, array
          a.at(n)......vector, deque, basic_string, array
          
+
          
+
+
+
+
+
+
          
+
          1039. Response to UK 234
          
+
          Section: 23.2.3 [sequence.reqmts] Status: Tentatively Ready
+ Submitter: Alisdair Meredith Opened: 2009-03-12  Last modified: 2009-05-23
          
+
          View other active issues in [sequence.reqmts].
          
+
          View all other issues in [sequence.reqmts].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
+
          Addresses UK 234
          
+
+
          
+The reference to iterator in semantics for back should
+also allow for const_iterator when called on a const-qualified
+container. This would be ugly to specify in the 03 standard, but is
+quite easy with the addition of auto in this new standard.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Agree.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
          
+In 23.2.3 [sequence.reqmts] Table 84, replace iterator with auto in semantics for back:
+
          
+
+
          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
          Table 84 -- Optional sequence container operations
          ExpressionReturn typeOperational semanticsContainer
          a.back()reference; const_reference for constant a{ iterator auto tmp = a.end();
          --tmp;
          return *tmp; }          		vector, list, deque, basic_string
          
+
          
+
+
+
+
+
+
          
+
          1040. Response to UK 238
          
+
          Section: 23.2.4 [associative.reqmts] Status: Tentatively Ready
+ Submitter: Alisdair Meredith Opened: 2009-03-12  Last modified: 2009-05-23
          
+
          View other active issues in [associative.reqmts].
          
+
          View all other issues in [associative.reqmts].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
+
          Addresses UK 238
          
+
+
          
+Leaving it unspecified whether or not iterator and const_iterator are the
+same type is dangerous, as user code may or may not violate the One
+Definition Rule by providing overloads for 
+both types. It is probably too late to specify a single behaviour, but
+implementors should document what to expect. Observing that problems can be
+avoided by users restricting themselves to using const_iterator, add a note to that effect. 
+
          
+
          
+Suggest Change 'unspecified' to 'implementation defined'.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Agree with issue. Agree with adding the note but not with changing the
+normative text. We believe the note provides sufficient guidance.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
          
+In 23.2.4 [associative.reqmts] p6, add:
+
          
+
+
          
+-6- iterator of an associative container meets the requirements
+of the BidirectionalIterator concept. For associative
+containers where the value type is the same as the key type, both
+iterator and const_iterator are constant iterators. It
+is unspecified whether or not iterator and
+const_iterator are the same type.
+[Note: iterator and const_iterator have identical semantics in
+this case, and iterator is convertible to const_iterator. Users can avoid
+violating the One Definition Rule by always using const_iterator
+in their function parameter lists -- end note]
+
          
+
+
+
+
+
+
          
+
          1041. Response to UK 239
          
+
          Section: 23.2.4 [associative.reqmts] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-12  Last modified: 2009-03-15
          
+
          View other active issues in [associative.reqmts].
          
+
          View all other issues in [associative.reqmts].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses UK 239
          
+
+
          
+It is not possible to take a move-only key out of an unordered
+container, such as (multi)set or
+(multi)map, or the new unordered containers.
+
          
+
+
          
+Add below a.erase(q), a.extract(q), with the following notation:
+
          
+
          
+a.extract(q)>, Return type pair<key, iterator>
+Extracts the element pointed to by q and erases it from the
+set. Returns a pair containing the value pointed to by
+q and an iterator pointing to the element immediately
+following q prior to the element being erased. If no such
+element exists,returns a.end().
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+We look forward to a paper on this topic. We recommend no action until a
+paper is available. The paper would need to address exception safety.
+
          
+
+
          [
+Post Summit Alisdair adds:
+]
          
+
+
+
          
+Would value_type be a better return type than key_type?
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+In 23.2.4 [associative.reqmts] Table 85, add:
+
          
+
+
          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
          Table 85 --  Associative container requirements (in addition to container)
          ExpressionReturn typeAssertion/note
          pre-/post-condition          		Complexity
          a.erase(q).........
          a.extract(q)pair<key_type, iterator>Extracts the element pointed to by q and erases it from the set. 
+Returns a pair containing the value pointed to by q and an iterator
+pointing to the element immediately following q prior to the element being
+erased. If no such element 
+exists, returns a.end().amortized constant
          
+
          
+
+
          
+In 23.2.5 [unord.req] Table 87, add:
+
          
+
+
          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
          Table 87 -- Unordered associative container requirements (in addition to container)
          ExpressionReturn typeAssertion/note
          pre-/post-condition          		Complexity
          a.erase(q).........
          a.extract(q)pair<key_type, iterator>Extracts the element pointed to by q and erases it from the set. 
+Returns a pair containing the value pointed to by q and an iterator
+pointing to the element immediately following q prior to the element being
+erased. If no such element 
+exists, returns a.end().amortized constant
          
+
          
+
+
+
+
+
+
          
+
          1042. Response to UK 244
          
+
          Section: 23.3 [sequences] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-12  Last modified: 2009-03-14
          
+
          View all other issues in [sequences].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses UK 244
          
+
+
          
+The validity of the expression &a[n] == &a[0] + n is contingent on
+operator& doing the "right thing" (as captured by the CopyConstructible
+requirements in table 30 in C++2003). However this constraint has been
+lost in the Concepts of C++0x. This applies to vector and array (it
+actually applies to string also, but that's a different chapter, so I'll
+file a separate comment there and cross-reference).
+
          
+
+
          
+Suggested solution:
+
          
+
+
          
+Define a ContiguousStrorage and apply it to
+vector, array and string.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Agree with the issue but not the details of the proposed solution. Walter to
+provide wording for the new concept.
+
          
+
+
          [
+Post Summit Alisdair adds:
+]
          
+
+
+
          
+Another LWG subgroup wondered if this concept
+should extend to complex<T>, and so not be built on the container concept at
+all?
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+Add to <container_concepts> synopsis in 23.2.6 [container.concepts]
+
          
+
+
          concept< typename C > ContiguousStorageContainer see below;
+
          
+
+
          
+Add a new section to the end of 23.2.6 [container.concepts]
+
          
+
+
          
+
          
+23.1.6.x ContiguousStorageContainer concept [container.concepts.contiguous]
+
          
+
+
          concept ContiguousStorageContainer< typename C >
+  : Container<C>
+{
+  value_type* data(C&);
+
+  axiom Contiguity(C& c, size_type i) {
+    if( i < size(c) ) {
+         addressof( * (data(c) + i) )
+      == addressof( * advance(data(c), i) );
+    }
+  }
+}
+
          
+
+
          
+The ContiguousStorageContainer concept describes a container whose elements
+are allocated in a single region of memory, and are stored sequentially
+without intervening padding other than to meet alignment requirements.
+For example, the elements may be stored in a
+single array of suitable length.
+
          
+
+
          value_type * data( C& );
+
          
+
+
          
+Returns: a pointer to the first element in the region of storage.
+Result is unspecified for an empty container.
+
          
+
+
          
+
+
          
+Change 23.3.1 [array] p1:
+
          
+
+
          
+-1- The header <array> defines a class template for
+storing fixed-size sequences of objects. An array supports
+random access iterators. An instance of array<T, N>
+stores N elements of type T, so that size() ==
+N is an invariant. The elements of an array are stored
+contiguously, meaning that if a is an
+array<T, N> then it obeys the identity &a[n]
+== &a[0] + n for all 0 <= n < N
+satisfies the concept ContiguousStorageContainer< array<T,
+N>>.
+
          
+
+
          
+Add to the synopsis in 23.3.1 [array]:
+
          
+
+
              ...
+    T * data(); 
+    const T * data() const; 
+  };
+
+  template< typename T, size_t N >
+    concept_map ContiguousStorageContainer< array<T, N>> {};
+} 
+
          
+
+
          
+Change 23.3.6 [vector] p1:
+
          
+
+
          
+A vector is a sequence container that supports random access
+iterators. In addition, it supports (amortized) constant time insert and
+erase operations at the end; insert and erase in the middle take linear
+time. Storage management is handled automatically, though hints can be
+given to improve efficiency. The elements of a vector are stored
+contiguously, meaning that if v is a
+vector<T, Alloc> (where T is some
+type other than bool), then it obeys the
+identity &v[n] == &v[0] + n for all 0 <= n <
+v.size() satisfies the concept ContiguousStorageContainer<
+vector< T, Alloc>>.
+
          
+
+
          
+Add at the end of the synopsis in 23.3.6 [vector] p2:
+
          
+
+
          template< typename T, typename A >
+  requires !SameType< T, bool >
+  concept_map ContiguousStorageContainer< vector<T, A>> {};
+
          
+
+
+
+
+
+
+
          
+
          1043. Response to US 91
          
+
          Section: 29.6 [atomics.types.operations] Status: Review
+ Submitter: Alisdair Meredith Opened: 2009-03-12  Last modified: 2009-05-23
          
+
          View all other issues in [atomics.types.operations].
          
+
          View all issues with Review status.
          
+
          Discussion:
          
+
+
          Addresses US 91
          
+
+
          
+It is unclear whether or not a failed compare_exchange is a RMW operation
+(as used in 1.10 [intro.multithread]).
+
          
+
+
          
+Suggested solution:
+
          
+
+
          
+Make failing compare_exchange operations not be RMW.
+
          
+
+
          [
+Anthony Williams adds:
+]
          
+
+
+
          
+In 29.6 [atomics.types.operations] p18 it says that "These
+operations are atomic read-modify-write operations" (final sentence).
+This is overly restrictive on the implementations of
+compare_exchange_weak and compare_exchange_strong on platforms without a
+native CAS instruction.
+
          
+
+
+
          [
+Summit:
+]
          
+
+
+
          
+Group agrees with the resolution as proposed by Anthony Williams in the attached note.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We recommend the proposed resolution be reviewed
+by members of the Concurrency Subgroup.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 29.6 [atomics.types.operations] p18:
+
          
+
+
          
+-18- Effects: Atomically, compares the value pointed to by
+object or by this for equality with that in
+expected, and if true, replaces the value pointed to by
+object or by this with desired, and if false, updates
+the value in expected with the value pointed to by
+object or by this. Further, if the comparison is true,
+memory is affected according to the value of success, and if the
+comparison is false, memory is affected according to the value of
+failure. When only one memory_order argument is
+supplied, the value of success is order, and the value
+of failure is order except that a value of
+memory_order_acq_rel shall be replaced by the value
+memory_order_acquire and a value of
+memory_order_release shall be replaced by the value
+memory_order_relaxed. If the comparison is true, 
+Tthese operations are atomic
+read-modify-write operations (1.10). 
+If the comparison is false, these
+operations are atomic load operations.
+
          
+
+
+
+
+
+
+
          
+
          1044. Response to UK 325
          
+
          Section: 30.4 [thread.mutex] Status: Tentatively Ready
+ Submitter: Alisdair Meredith Opened: 2009-03-12  Last modified: 2009-05-23
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
+
          Addresses UK 325
          
+
+
          
+We believe constexpr literal values should be a more natural expression
+of empty tag types than extern objects as it should improve the
+compiler's ability to optimize the empty object away completely.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Move to review. The current specification is a "hack", and the proposed
+specification is a better "hack".
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change the synopsis in 30.4 [thread.mutex]:
+
          
+
+
          struct defer_lock_t {};
+struct try_to_lock_t {};
+struct adopt_lock_t {};
+
+extern constexpr defer_lock_t defer_lock {};
+extern constexpr try_to_lock_t try_to_lock {};
+extern constexpr adopt_lock_t adopt_lock {};
+
          
+
+
+
+
+
+
+
          
+
          1045. Response to UK 326
          
+
          Section: 30.4.3.2.1 [thread.lock.unique.cons] Status: Tentatively Ready
+ Submitter: Alisdair Meredith Opened: 2009-03-12  Last modified: 2009-05-23
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
+
          Addresses UK 326
          
+
+
          
+The precondition that the mutex is not owned by this thread offers
+introduces the risk of un-necessary undefined behaviour into the
+program. The only time it matters whether the current thread owns the
+mutex is in the lock operation, and that will happen subsequent to
+construction in this case. The lock operation has the identical
+pre-condition, so there is nothing gained by asserting that precondition
+earlier and denying the program the right to get into a valid state
+before calling lock.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Agree, move to review.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Strike 30.4.3.2.1 [thread.lock.unique.cons] p7:
+
          
+
+
          unique_lock(mutex_type& m, defer_lock_t);
+
          
+
          
+-7- Precondition: If mutex_type is not a recursive mutex
+the calling thread does not own the mutex.
+
          
+
          
+
+
+
+
+
+
+
          
+
          1046. Response to UK 329
          
+
          Section: 30.6 [futures] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-12  Last modified: 2009-03-13
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses UK 329
          
+
+
          
+future, promise and packaged_task provide a
+framework for creating future values, but a simple function to tie all
+three components together is missing. Note that we only need a *simple*
+facility for C++0x. Advanced thread pools are to be left for TR2.
+
          
+
+
          
+Simple Proposal:
+
          
+
+
          
+Provide a simple function along the lines of: 
+
          
+
          template< typename F, typename ... Args >
+  requires Callable< F, Args... >
+    future< Callable::result_type > async( F&& f, Args && ... ); 
+
          
+
+
          
+Semantics are similar to creating a thread object with a packaged_task
+invoking f with forward<Args>(args...)
+but details are left unspecified to allow different scheduling and thread
+spawning implementations. 
+
          
+
          
+It is unspecified whether a task submitted to async is run on its own thread
+or a thread previously used for another async task. If a call to async
+succeeds, it shall be safe to wait for it from any thread. 
+
          
+
          
+The state of thread_local variables shall be preserved during async calls. 
+
          
+
          
+No two incomplete async tasks shall see the same value of
+this_thread::get_id(). 
+
          
+
          
+[Note: this effectively forces new tasks to be run on a new thread, or a
+fixed-size pool with no queue. If the 
+library is unable to spawn a new thread or there are no free worker threads
+then the async call should fail. --end note] 
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+
          
+The concurrency subgroup has revisited this issue and decided that it
+could be considered a defect according to the Kona compromise. A task
+group was formed lead by Lawrence Crowl and Bjarne Stroustrup to write a
+paper for Frankfort proposing a simple asynchronous launch facility
+returning a future. It was agreed that the callable must be run on a
+separate thread from the caller, but not necessarily a brand-new thread.
+The proposal might or might not allow for an implementation that uses
+fixed-size or unlimited thread pools.
+
          
+
          
+Bjarne in c++std-lib-23121: I think that what we agreed was that to
+avoid deadlock async() would almost certainly be specified to  launch in
+a different thread from the thread that executed async(), but I don't
+think it was a specific design constraint.
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1047. Response to UK 334
          
+
          Section: 30.6.4 [futures.unique_future] Status: Review
+ Submitter: Alisdair Meredith Opened: 2009-03-12  Last modified: 2009-05-23
          
+
          View other active issues in [futures.unique_future].
          
+
          View all other issues in [futures.unique_future].
          
+
          View all issues with Review status.
          
+
          Discussion:
          
+
+
          Addresses UK 334
          
+
+
          
+Behaviour of get() is undefined if calling get() while
+not is_ready(). The intent is that get() is a blocking
+call, and will wait for the future to become ready.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+
          
+Agree, move to Review.
+
          
+
          
+
+
          [
+2009-04-03 Thomas J. Gritzan adds:
+]
          
+
+
+
          
+
          
+This issue also applies to shared_future::get().
+
          
+
+
          
+Suggested wording:
+
          
+
+
          
+Add a paragraph to  [futures.shared_future]:
+
          
+
+
          void shared_future<void>::get() const;
+
          
+
          
+Effects: If is_ready() would return false, block on the asynchronous 
+result associated with *this.
+
          
+
          
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+It is not clear to us that this is an issue,
+because the proposed resolution's Effects clause seems to duplicate
+information already present in the Synchronization clause.
+Keep in Review status.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Add a paragraph to 30.6.4 [futures.unique_future]:
+
          
+
+
          R&& unique_future::get(); 
+R& unique_future<R&>::get(); 
+void unique_future<void>::get();
+
          
+
          
+
          Note:...
          
+
          
+Effects: If is_ready() would return false,
+block on the asynchronous result associated with *this.
+
          
+
          
+Synchronization: if *this is associated with a
+promise object, the completion of set_value() or
+set_exception() to that promise happens before (1.10)
+get() returns.
+
          
+
          
+
          
+
+
+
+
+
+
          
+
          1048. Response to UK 335
          
+
          Section: 30.6.4 [futures.unique_future] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-12  Last modified: 2009-03-13
          
+
          View other active issues in [futures.unique_future].
          
+
          View all other issues in [futures.unique_future].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses UK 335
          
+
+
          
+std::unique_future is MoveConstructible, so you can transfer the
+association with an asynchronous result from one instance to another.
+However, there is no way to determine whether or not an instance has
+been moved from, and therefore whether or not it is safe to wait for it.
+
          
+
+
          std::promise<int> p;
+std::unique_future<int> uf(p.get_future());
+std::unique_future<int> uf2(std::move(uf));
+uf.wait(); // oops, uf has no result to wait for. 
+
          
+
+
          
+Suggest we add a waitable() function to unique_future
+(and shared_future) akin to std::thread::joinable(),
+which returns true if there is an associated result to wait for
+(whether or not it is ready).
+
          
+
+
          
+Then we can say:
+
          
+
+
          if(uf.waitable()) uf.wait();
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+
          
+Create an issue. Requires input from Howard. Probably NAD.
+
          
+
          
+
+
          [
+Post Summit, Howard thows in his two cents:
+]
          
+
+
+
          
+
          
+Here is a copy/paste of my last prototype of unique_future which was
+several years ago.  At that time I was calling unique_future future:
+
          
+
+
          template <class R>
+class future
+{
+public:
+    typedef R result_type;
+private:
+    future(const future&);// = delete;
+    future& operator=(const future&);// = delete;
+
+    template <class R1, class F1> friend class prommise;
+public:
+    future();
+    ~future();
+
+    future(future&& f);
+    future& operator=(future&& f);
+
+    void swap(future&& f);
+
+    bool joinable() const;
+    bool is_normal() const;
+    bool is_exceptional() const;
+    bool is_ready() const;
+
+    R get();
+
+    void join();
+    template <class ElapsedTime>
+        bool timed_join(const ElapsedTime&);
+};
+
          
+
+
          
+shared_future had a similar interface.  I intentionally reused
+the thread interface where possible to lessen the learning
+curve std::lib clients will be faced with.
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1049. Response to UK 339
          
+
          Section: 30.6.6 [futures.promise] Status: Review
+ Submitter: Alisdair Meredith Opened: 2009-03-12  Last modified: 2009-05-23
          
+
          View other active issues in [futures.promise].
          
+
          View all other issues in [futures.promise].
          
+
          View all issues with Review status.
          
+
          Discussion:
          
+
+
          Addresses UK 339
          
+
+
          
+Move assignment is goiing in the wrong direction, assigning from
+*this to the passed rvalue, and then returning a reference to
+an unusable *this.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+
          
+Agree, move to Review.
+
          
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We recommend deferring this issue until after Detlef's paper (on futures)
+has been issued.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Strike 30.6.6 [futures.promise] p6 and change p7:
+
          
+
+
          promise& operator=(promise&& rhs);
+
          
+
          
+
          
+-6- Effects: move assigns its associated state to rhs.
+
          
+
          
+-7- Postcondition: *this has no associated
+state. associated state of *this is the same as the
+associated state of rhs before the call. rhs has no
+associated state.
+
          
+
          
+
          
+
+
+
+
+
+
+
          
+
          1050. Response to UK 340
          
+
          Section: 30.6.6 [futures.promise] Status: Review
+ Submitter: Alisdair Meredith Opened: 2009-03-12  Last modified: 2009-05-23
          
+
          View other active issues in [futures.promise].
          
+
          View all other issues in [futures.promise].
          
+
          View all issues with Review status.
          
+
          Discussion:
          
+
+
          Addresses UK 340
          
+
+
          
+There is an implied postcondition for get_future() that the state of the
+promise is transferred into the future leaving the promise with no
+associated state. It should be spelled out.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+
          
+Agree, move to Review.
+
          
+
          
+
+
          [
+2009-04-03 Thomas J. Gritzan adds:
+]
          
+
+
+
          
+
          
+promise::get_future() must not invalidate the state of the promise object. 
+
          
+
          
+A promise is used like this: 
+
          
+
          promise<int> p; 
+unique_future<int> f = p.get_future(); 
+// post 'p' to a thread that calculates a value 
+// use 'f' to retrieve the value. 
+
          
+
          
+So get_future() must return an object that shares the same associated 
+state with *this. 
+
          
+
          
+But still, this function should throw an future_already_retrieved error 
+when it is called twice. 
+
          
+
          
+packaged_task::get_future() throws std::bad_function_call if its future
+was already retrieved. It should throw 
+future_error(future_already_retrieved), too. 
+
          
+
          
+Suggested resolution: 
+
          
+
          
+Replace p12/p13 30.6.6 [futures.promise]: 
+
          
+
          
+
          
+-12- Throws: future_error if *this has no associated state
+the future has already been retrieved.
+
          
+
          
+-13- Error conditions: future_already_retrieved if *this
+has no associated state
+the future associated with 
+the associated state has already been retrieved.
+
          
+
          
+Postcondition: The returned object and *this share the associated state.
+
          
+
          
+
          
+Replace p14 30.6.8 [futures.task]: 
+
          
+
          
+
          
+-14- Throws: std::bad_function_call future_error if the future associated with
+the task has already been retrieved.
+
          
+
+
          
+Error conditions: future_already_retrieved if the future associated with 
+the task has already been retrieved. 
+
          
+
          
+Postcondition: The returned object and *this share the associated task.
+
          
+
          
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+Keep in Review status
+pending Detlef's forthcoming paper on futures.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Add after p13 30.6.6 [futures.promise]:
+
          
+
+
          unique_future<R> get_future();
+
          
+
          
+
          
+-13- ...
+
          
+
          
+Postcondition: *this has no associated state.
+
          
+
          
+
          
+
+
+
+
+
+
+
          
+
          1051. Response to UK 279
          
+
          Section: 24.5.1.2.12 [reverse.iter.opindex], 24.5.3.2.12 [move.iter.op.index] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-12  Last modified: 2009-03-21
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses UK 279
          
+
+
          
+The reason the return type became unspecified is LWG issue 386. This
+reasoning no longer applies as there are at least two ways to get the right
+return type with the new language facilities added since the previous
+standard. 
+
          
+
+
          
+Proposal: Specify the return type using either decltype or the Iter concept_map.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+
          
+Under discussion. This is a general question about all iterator
+adapters.
+
          
+
          
+
+
          [
+Howard adds post Summit:
+]
          
+
+
+
          
+I am requesting test cases to demonstrate a position.
+
          
+
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1052. Response to UK 281
          
+
          Section: 24.5.1.2.5 [reverse.iter.opref] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-12  Last modified: 2009-03-13
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses UK 281
          
+
+
          
+The current specification for return value for reverse_iterator::operator->
+will always be a true pointer type, but reverse_iterator supports proxy
+iterators where the pointer type may be some kind of 'smart pointer'.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+
          
+move_iterator avoids this problem by returning a value of the wrapped
+Iterator type.
+study group formed to come up with a suggested resolution.
+
          
+
          
+move_iterator solution shown in proposed wording.
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+Change synopsis in 24.5.1.1 [reverse.iterator]:
+
          
+
+
          template <BidirectionalIterator Iter> 
+class reverse_iterator { 
+  ...
+  typedef Iter::pointer pointer; 
+
          
+
+
          
+Change 24.5.1.2.5 [reverse.iter.opref]:
+
          
+
+
          pointer operator->() const;
+
          
+
          
+Returns:
+
          &(operator*());
+this->tmp = current;
+--this->tmp;
+return this->tmp;
+
          
+
          
+
          
+
+
+
+
+
+
+
          
+
          1053. Response to UK 295
          
+
          Section: 25 [algorithms] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-12  Last modified: 2009-03-13
          
+
          View all other issues in [algorithms].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses UK 295
          
+
+
          
+There is a level of redundancy in the library specification for many
+algorithms that can be eliminated with the combination of concepts and
+default parameters for function templates. Eliminating redundancy simplified
+specification and reduces the risk of introducing accidental
+inconsistencies.
+
          
+
          
+Proposed resolution: Adopt
+N2743.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+
          
+NAD, this change would break code that takes the address of an
+algorithm.
+
          
+
          
+
+
          [
+Post Summit Alisdair adds:
+]
          
+
+
+
          
+
          
+Request 'Open'.  The issues in the paper go beyond just reducing
+the number of signatures, but cover unifying the idea of the ordering
+operation used by algorithms, containers and other library components.  At
+least, it takes a first pass at the problem.
+
          
+
+
          
+For me (personally) that was the more important part of the paper, and not
+clearly addressed by the Summit resolution.
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1054. forward broken
          
+
          Section: 20.3.2 [forward] Status: Open
+ Submitter: Howard Hinnant Opened: 2009-03-13  Last modified: 2009-05-23
          
+
          View all other issues in [forward].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          
+This is a placeholder issue to track the fact that we (well I) put the standard
+into an inconsistent state by requesting that we accept
+N2844
+except for the proposed changes to [forward].
+
          
+
+
          
+There will exist in the post meeting mailing
+N2835
+which in its current state reflects the state of affairs prior to the Summit
+meeting.  I hope to update it in time for the post Summit mailing, but as I write
+this issue I have not done so yet.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+Move to Open, awaiting the promised paper.
+
          
+
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1055. Response to UK 98
          
+
          Section: 20.6.7 [meta.trans.other] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-12  Last modified: 2009-05-23
          
+
          View other active issues in [meta.trans.other].
          
+
          View all other issues in [meta.trans.other].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses UK 98
          
+
+
          
+It would be useful to be able to determine the underlying
+type of an arbitrary enumeration type. This would allow
+safe casting to an integral type (especially needed for
+scoped enums, which do not promote), and would allow
+use of numeric_limits. In general it makes generic
+programming with enumerations easier.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+Pete observes (and Tom concurs)
+that the proposed resolution seems to require compiler support
+for its implementation,
+as it seems necessary to look at the range of values
+of the enumerated type.
+To a first approximation,
+a library solution could give an answer based on the size of the type.
+If the user has specialized numeric_limits for the enumerated type,
+then the library might be able to do better,
+but there is no such requirement.
+Keep status as Open
+and solicit input from CWG.
+
          
+
+
          [
+2009-05-23 Alisdair adds:
+]
          
+
+
+
          
+Just to confirm that the BSI originator of this comment assumed it did
+indeed imply a compiler intrinsic.  Rather than request a Core extension, it
+seemed in keeping with that the type traits interface provides a library API
+to unspecified compiler features - where we require several other traits
+(e.g. has_trivial_*) to get the 'right' answer now, unlike in TR1.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Add a new row to the table in 20.6.7 [meta.trans.other]:
+
          
+
+
          
+
+
+
+
+
+
+
+
+
+
+
+
+
          Table 41 -- Other transformations
          TemplateConditionComments
          
+template< class T > struct enum_base;
+
+T shall be an enumeration type (7.2 [dcl.enum])
+
+The member typedef type shall name the underlying type
+of the enum T.
+
          
+
          
+
+
+
+
+
+
          
+
          1056. Must all Engines and Distributions be Streamable?
          
+
          Section: 26.5 [rand] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-12  Last modified: 2009-05-31
          
+
          View other active issues in [rand].
          
+
          View all other issues in [rand].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          
+Both the concepts RandomNumberEngine and RandomNumberDistribution have
+requirements to be InputStreamable and OutputStreamable.
+
          
+
          
+I have no problems leaving the WP in an inconsistent state on the best-faith
+assumption these concepts will be provided later, however disagree with the
+proposers that these constraints are not separable, orthogonal to the basic
+concepts of generating random number distributions.
+
          
+
          
+These constraints should be dropped, and applied to specific algorithms as
+needed.
+
          
+
          
+If a more refined concept (certainly deemed useful by the proposers) is
+proposed there is no objection, but the basic concept should not require
+persistence via streaming.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+Move to Open.
+
          
+
+
          [
+2009-05-31 Alisdair adds:
+]
          
+
+
+
          
+
          
+Working on constraining the stream iterators, I have a few more observations
+to make on the concepts proposed while constraining the random number
+facility.
+
          
+
          
+While I still believe the concerns are orthogonal, I don't believe the
+existing constraints go far enough either!  The goal we want to achieve is
+not that a RandomNumberEngine / RandomNumberDistribution supports the stream
+operators, but that it is Serializable.  I.e. there is a relationship
+between the insert and extract operations that guarantees to restore the
+state of the original object.  This implies a coupling of the concepts
+together in a broader concept (Serializable) with at least one axiom to
+assert the semantics.
+
          
+
          
+One problem is that istream and ostream may be fundamentally different
+types, although we can hook a relation if we are prepared to drop down to
+the char type and char_traits template parameters.  Doing so ties us to a
+form of serialization that demands implementation via the std iostreams
+framework, which seems overly prescriptive.  I believe the goal is generally
+to support serialization without regard to how it is expressed - although
+this is getting even more inventive in terms of concepts we do not have
+today.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1057. RandomNumberEngineAdaptor
          
+
          Section: 26.5 [rand] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-12  Last modified: 2009-05-23
          
+
          View other active issues in [rand].
          
+
          View all other issues in [rand].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          
+The RandomNumberEngineAdaptor concept breaks precedent in the
+way the library has been specified by grouping requirements into a
+concept that is never actually used in the library.
+
          
+
          
+This is undoubtedly a very helpful device for documentation, but we are not
+comfortable with the precedent - especially as we have rejected national
+body comments on the same grounds.
+
          
+
          
+Suggest either removing the concept, or providing an algorithm/type that
+requires this concept in their definition (such as a factory function to
+create new engines).
+
          
+
          
+The preference is to create a single new algorithm and retain the value of
+the existing documentation.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Walter points out that it is unlikely that any algorithm would ever
+require this concept, but that the concept nonetheless is useful as
+documentation, and (via concept maps) as a means of checking specific adapters.
+
          
+
          
+Alisdair disagrees as to the concept's value as documentation.
+
          
+
          
+Marc points out that the RandomNumberDistribution
+is also a concept not used elsewhere in the Standard.
+
          
+
          
+Pete agrees that a policy of not inventing concepts
+that aren't used in the Standard is a good starting point,
+but should not be used as a criterion for rejecting a concept.
+
          
+
          
+Move to Open.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1058. New container issue
          
+
          Section: 23.2.3 [sequence.reqmts] Status: Tentatively NAD Editorial
+ Submitter: Alisdair Meredith Opened: 2009-03-12  Last modified: 2009-05-23
          
+
          View other active issues in [sequence.reqmts].
          
+
          View all other issues in [sequence.reqmts].
          
+
          View all issues with Tentatively NAD Editorial status.
          
+
          Discussion:
          
+
+
          
+Sequence containers 23.2.3 [sequence.reqmts]:
+
          
+
+
          
+The return value of new calls added to table 83 are not specified.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We agree with the proposed resolution.
+
          
+
          
+Move to NAD Editorial.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+Add after p6 23.2.3 [sequence.reqmts]:
+
          
+
+
          
+
          
+-6- ...
+
          
+
          
+The iterator returned from a.insert(p,rv) points to the copy of rv
+inserted into a.
+
          
+
          
+The iterator returned from a.emplace(p, args) points to the new
+element constructed from args inserted into a.
+
          
+
          
+
+
+
+
+
+
          
+
          1059. Usage of no longer existing FunctionType concept
          
+
          Section: 20.7.16.2 [func.wrap.func] Status: Open
+ Submitter: Daniel Krügler Opened: 2009-03-13  Last modified: 2009-05-23
          
+
          View other active issues in [func.wrap.func].
          
+
          View all other issues in [func.wrap.func].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+Due to a deliberate core language decision, the earlier called
+"foundation" concept std::FunctionType had been removed in
+N2773
+shortly
+before the first "conceptualized" version of the WP
+(N2798)
+had been
+prepared. This caused a break of the library, which already used this
+concept in the adapted definition of std::function
+(20.7 [function.objects]/2, header <functional> synopsis and
+20.7.16.2 [func.wrap.func]).
+
          
+
          
+A simple fix would be to either (a) make std::function's primary template
+unconstrained or to (b) add constraints based on existing (support) concepts.
+A more advanced fix would (c) introduce a new library concept.
+
          
+
          
+The big disadvantage of (a) is, that users can define templates which
+cause compiler errors during instantiation time because of under-constrainedness
+and would thus violate the basic advantage of constrained
+code.
+
          
+
          
+For (b), the ideal constraints for std::function's template parameter would
+be one which excludes everything else but the single provided partial
+specialization that matches every "free function" type (i.e. any function
+type w/o cv-qualifier-seq and w/o ref-qualifier).
+Expressing such a type as as single requirement would be written as
+
          
+
          template<typename T>
+requires ReferentType<T> // Eliminate cv void and function types with cv-qual-seq
+                         //   or ref-qual (depending on core issue #749)
+      && PointeeType<T>  // Eliminate reference types
+      && !ObjectType<T>  // Eliminate object types
+
          
+
          
+Just for completeness approach (c), which would make sense, if the
+library has more reasons to constrain for free function types:
+
          
+
          auto concept FreeFunctionType<typename T>
+  : ReferentType<T>, PointeeType<T>, MemberPointeeType<T>
+{
+  requires !ObjectType<T>;
+}
+
          
+
          
+I mention that approach because I expect that free function types belong
+to the most natural type categories for every days coders. Potential
+candidates in the library are addressof and class template packaged_task.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Alisdair would prefer to have a core-supported FunctionType concept
+in order that any future changes be automatically correct
+without need for a library solution to catch up;
+he points to type traits as a precedent.
+Further, he believes that a published concept can't in the future
+be changed.
+
          
+
          
+Bill feels this category of entity would change sufficiently slowly
+that he would be willing to take the risk.
+
          
+
          
+Of the discussed solutions, we tend toward option (c).
+We like the idea of having a complete taxonomy of native types,
+and perhaps erred in trimming the set.
+
          
+
          
+We would like to have this issue reviewed by Core and would like
+their feedback.  Move to Open.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
            
+
          1. 
+
            
+Change in 20.7 [function.objects]/2, Header <functional> synopsis:
+
            
+
            // 20.6.16 polymorphic function wrappers:
+class bad_function_call;
+template<FunctionTypeReferentType F>
+requires PointeeType<F> && !ObjectType<F>
+class function; // undefined
+
            
+
            2. 
+
          2. 
+
            
+Change in 20.7.16.2 [func.wrap.func]:
+
            
+
            namespace std {
+template<FunctionTypeReferentType F>
+requires PointeeType<F> && !ObjectType<F>
+class function; // undefined
+
            
+
            3. 
+
          
+
+
+
+
+
+
          
+
          1060. Embedded nulls in NTBS
          
+
          Section: 17.5.2.1.4.1 [byte.strings] Status: Tentatively NAD Editorial
+ Submitter: Alisdair Meredith Opened: 2009-03-13  Last modified: 2009-05-23
          
+
          View all issues with Tentatively NAD Editorial status.
          
+
          Discussion:
          
+
+
          
+Definition of null-terminated sequences allow for embedded nulls. This is
+surprising, and probably not supportable with the intended use cases.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the issue, but believe this can be handled editorially.
+Move to NAD Editorial.
+
          
+
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1061. Bad indexing for tuple access to pair (Editorial?)
          
+
          Section: 20.3.4 [pair.astuple] Status: Tentatively NAD Editorial
+ Submitter: Alisdair Meredith Opened: 2009-03-13  Last modified: 2009-05-23
          
+
          View all issues with Tentatively NAD Editorial status.
          
+
          Discussion:
          
+
+
          
+The definition of get implies that get must return the second element if
+given a negative integer.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+Move to NAD Editorial.
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+20.3.4 [pair.astuple] p5:
+
          
+
+
          template<int size_t I, class T1, class T2> 
+  requires True<(I < 2)> 
+  const P& get(const pair<T1, T2>&);
+
          
+
          
+
+
+
+
+
+
+
          
+
          1062. Missing insert_iterator for stacks/queues
          
+
          Section: 24.7 [insert.iterators] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-13  Last modified: 2009-05-23
          
+
          View other active issues in [insert.iterators].
          
+
          View all other issues in [insert.iterators].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          
+It is odd that we have an iterator to insert into a vector, but not an
+iterator to insert into a vector that is adapted as a stack. The standard
+container adapters all have a common interface to push and pop so it should
+be simple to create an iterator adapter to complete the library support.
+
          
+
+
          
+We should provide an AdaptedContainer concept supporting push and pop
+operations. Create a new insert iterator and factory function that inserts
+values into the container by calling push.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Walter recommends NAD Future.
+
          
+
          
+Move to Open, and recommend deferring the issue until after the next
+Committee Draft is issued.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1063. 03 iterator compatibilty
          
+
          Section: D.10.4 [iterator.backward] Status: Tentatively Ready
+ Submitter: Alisdair Meredith Opened: 2009-03-15  Last modified: 2009-05-23
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
+
          
+Which header must a user #include to obtain the library-supplied
+concept_maps declared in this paragraph?
+
          
+
+
          
+This is important information, as existing user code will break if this
+header is not included, and we should make a point of mandating this header
+is #include-d by library headers likely to make use of it, notably
+<algorithm>.  See issue 1001 for more details.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the direction of the proposed resolution.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
          Change D.10 [depr.lib.iterator.primitives], Iterator primitives, as
+indicated:
          
+
+
          
+  
          To simplify the use of iterators and provide backward compatibility with
+  previous C++ Standard Libraries,
+  the library provides several classes and functions. Unless otherwise
+  specified, these classes and functions shall be defined in header <iterator>.
          
+
          
+
          Change D.10.4 [iterator.backward], Iterator backward compatibility, as
+indicated:
          
+
          
+  
          The library provides concept maps that allow iterators specified with
+  iterator_traits to interoperate with
+  algorithms that require iterator concepts. These concept maps shall be
+  defined in the same header that defines the iterator. [Example:
          
+
          
+
+
+
+
+
+
          
+
          1064. Response to UK 152
          
+
          Section: 17.3.15 [defns.obj.state] Status: Open
+ Submitter: Howard Hinnant Opened: 2009-03-15  Last modified: 2009-03-15
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses UK 152
          
+
+
          
+Object state is using a definition of object (instance of a class) from
+outside the standard, rather than the 'region of storage' definiton in
+1.8 [intro.object]p1
+
          
+
+
          [
+Summit:
+]
          
+
+
          
+We think we're removing this; See 20.7.18.1 [func.referenceclosure.cons].
+
          
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
+
+
+
          
+
          1065. Response to UK 168
          
+
          Section: 17.6.1.1 [contents] Status: Tentatively Ready
+ Submitter: Howard Hinnant Opened: 2009-03-15  Last modified: 2009-05-23
          
+
          View other active issues in [contents].
          
+
          View all other issues in [contents].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          Addresses UK 168
          
+
          
+We should make it clear (either by note or normatively) that namespace
+std may contain inline namespaces, and that entities specified to be
+defined in std may in fact be defined in one of these inline namespaces.
+(If we're going to use them for versioning, eg when TR2 comes along,
+we're going to need that.)
+
          
+
+
          
+Replace "namespace std or namespaces nested within namespace std" with
+"namespace std or namespaces nested within namespace std or inline
+namespaces nested directly or indirectly within namespace std"
+
          
+
+
          [
+Summit:
+]
          
+
+
          
+adopt UK words (some have reservations whether it is correct)
+
          
+
+
          [
+2009-05-09 Alisdair improves the wording.
+]
          
+
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Bill believes there is strictly speaking no need to say that
+because no portable test can detect the difference.
+However he agrees that it doesn't hurt to say this.
+
          
+
          
+Move to Tentatively Ready.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 17.6.1.1 [contents] p2:
+
          
+
+
          
+All library entities except macros, operator new and
+operator delete are defined within the namespace std or
+namespaces nested within namespace std.
+It is unspecified whether names declared in a specific namespace
+are declared directly in that namespace, or in an inline namespace inside
+that namespace. [Footnote: This gives implementers freedom to support
+multiple configurations of the library.]
+
          
+
+
+
+
+
+
          
+
          1066. Response to UK 189 and JP 27
          
+
          Section: 18 [language.support] Status: Tentatively Ready
+ Submitter: Howard Hinnant Opened: 2009-03-15  Last modified: 2009-05-23
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          Addresses UK 189 and JP 27
          
+
          
+The addition of the [[noreturn]] attribute to the language will be an
+important aid for static analysis tools.
+
          
+
+
          
+The following functions should be declared in C++ with the
+[[noreturn]] attribute: abort exit
+quick_exit terminate unexpected
+rethrow_exception throw_with_nested.
+
          
+
+
          [
+Summit:
+]
          
+
+
          
+Agreed.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 18.5 [support.start.term] p3:
+
          
+
+
          
+
          -2- ...
          
+
          void abort [[noreturn]] (void)
+
          
+
          -3- ...
          
+
          -6- ...
          
+
          void exit [[noreturn]] (int status)
+
          
+
          -7- ...
          
+
          -11- ...
          
+
          void quick_exit [[noreturn]] (int status)
+
          
+
          -12- ...
          
+
          
+
+
          
+Change the <exception> synopsis in 18.8 [support.exception]:
+
          
+
+
          void unexpected [[noreturn]] ();
+...
+void terminate [[noreturn]] ();
+...
+void rethrow_exception [[noreturn]] (exception_ptr p);
+...
+template <class T> void throw_with_nested [[noreturn]] (T&& t); // [[noreturn]]
+
          
+
+
          
+Change 18.8.2.4 [unexpected]:
+
          
+
+
          void unexpected [[noreturn]] ();
+
          
+
+
          
+Change 18.8.3.3 [terminate]:
+
          
+
+
          void terminate [[noreturn]] ();
+
          
+
+
          
+Change 18.8.5 [propagation]:
+
          
+
+
          void rethrow_exception [[noreturn]] (exception_ptr p);
+
          
+
+
          
+In the synopsis of 18.8.6 [except.nested] and the definition area change:
+
          
+
+
          template <class T> void throw_with_nested [[noreturn]] (T&& t); // [[noreturn]]
+
          
+
+
+
+
+
+
          
+
          1067. simplified wording for inner_product
          
+
          Section: 26.7 [numeric.ops] Status: Tentatively Ready
+ Submitter: Alisdair Meredith Opened: 2009-03-17  Last modified: 2009-05-23
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
+
          
+One of the motivating examples for introducing requirements-aliases was to
+simplify the wording of the inner_product requirements.  As the paper
+adopting the feature and constrained wording for the library went through in
+the same meeting, it was not possible to make the change at the time.  The
+simpler form should be adopted now though.  Similarly, most the other
+numerical algorithms can benefit from a minor cleanup.
+
          
+
          
+Note that in each case, the second more generalised form of the algorithm
+does not benefit, as there are already named constraints supplied by the
+template type parameters.
+
          
+
+
          [
+2009-05-02 Daniel adds:
+]
          
+
+
+
          
+
          
+one part of the suggested resolution suggests the removal of the
+MoveConstructible<T> requirement from
+inner_product. According to 26.7.2 [inner.product]
+
          
+
+
          
+Computes its result by initializing the accumulator acc with the
+initial value init
+
          
+
+
          
+this step requires at least MoveConstructible.
+
          
+
+
          
+Therefore I strongly suggest to take this removal back (Note also
+that the corresponding overload with a functor argument still has
+the same MoveConstructible<T> requirement).
+
          
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We agree with the proposed resolution as amended by Daniel's suggestion
+to restore MoveConstructible,
+reflected in the updated proposed resolution below.
+
          
+
          
+Move to Tentatively Ready.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change in 26.7 [numeric.ops] and  [accumulate]:
+
          
+
+
          template <InputIterator Iter, MoveConstructible T>
+ requires add = HasPlus<T, Iter::reference>
+       && HasAssign<T, HasPlus<T, Iter::reference> add::result_type>
+ T accumulate(Iter first, Iter last, T init);
+
          
+
+
          
+Change in 26.7 [numeric.ops] and 26.7.2 [inner.product]:
+
          
+
+
          template <InputIterator Iter1, InputIterator Iter2, MoveConstructible T>
+  requires mult = HasMultiply<Iter1::reference, Iter2::reference>
+        && add = HasPlus<T, HasMultiply<Iter1::reference, Iter2::reference> mult::result_type>
+        && HasAssign< 
+             T,
+             HasPlus<T,
+                     HasMultiply<Iter1::reference, Iter2::reference>::result_type> add::result_type>
+  T inner_product(Iter1 first1, Iter1 last1, Iter2 first2, T init);
+
          
+
+
          
+Change in 26.7 [numeric.ops] and 26.7.3 [partial.sum]:
+
          
+
+
          template <InputIterator InIter, OutputIterator<auto, const InIter::value_type&> OutIter>
+  requires add = HasPlus<InIter::value_type, InIter::reference>
+        && HasAssign<InIter::value_type,
+                     HasPlus<InIter::value_type, InIter::reference> add::result_type>
+        && Constructible<InIter::value_type, InIter::reference>
+  OutIter partial_sum(InIter first, InIter last, OutIter result);
+
          
+
+
          
+Change in 26.7 [numeric.ops] and 26.7.4 [adjacent.difference]:
+
          
+
+
          template <InputIterator InIter, OutputIterator<auto, const InIter::value_type&> OutIter>
+  requires sub = HasMinus<InIter::value_type, InIter::value_type>
+        && Constructible<InIter::value_type, InIter::reference>
+        && OutputIterator<OutIter, HasMinus<InIter::value_type, InIter::value_type> sub::result_type>
+        && MoveAssignable<InIter::value_type>
+  OutIter adjacent_difference(InIter first, InIter last, OutIter result);
+
          
+
+
+
+
+
+
+
          
+
          1068. class random_device should be movable
          
+
          Section: 26.5.6 [rand.device] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-18  Last modified: 2009-05-23
          
+
          View all other issues in [rand.device].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          
+class random_device should be movable.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+Move to Open, and recommend this issue be deferred until after the next
+Committee Draft is issued.
+
          
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1069. class seed_seq should support efficient move operations
          
+
          Section: 26.5.7.1 [rand.util.seedseq] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-18  Last modified: 2009-05-23
          
+
          View all other issues in [rand.util.seedseq].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          
+class seed_seq should support efficient move operations.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+Move to Open, and recommend this issue be deferred until after the next
+Committee Draft is issued.
+
          
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1070. Ambiguous move overloads in function
          
+
          Section: 20.7.16.2 [func.wrap.func] Status: Tentatively Ready
+ Submitter: Howard Hinnant Opened: 2009-03-19  Last modified: 2009-05-23
          
+
          View other active issues in [func.wrap.func].
          
+
          View all other issues in [func.wrap.func].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+The synopsis in 20.7.16.2 [func.wrap.func] says:
+
          
+
+
          template<Returnable R, CopyConstructible... ArgTypes> 
+class function<R(ArgTypes...)>
+{
+    ...
+    template<class F> 
+      requires CopyConstructible<F> && Callable<F, ArgTypes...> 
+            && Convertible<Callable<F, ArgTypes...>::result_type, R> 
+      function(F); 
+    template<class F> 
+      requires CopyConstructible<F> && Callable<F, ArgTypes...> 
+            && Convertible<Callable<F, ArgTypes...>::result_type, R> 
+      function(F&&);
+    ...
+    template<class F, Allocator Alloc> function(allocator_arg_t, const Alloc&, F); 
+    template<class F, Allocator Alloc> function(allocator_arg_t, const Alloc&, F&&);
+    ...
+    template<class F> 
+      requires CopyConstructible<F> && Callable<F, ArgTypes..> 
+            && Convertible<Callable<F, ArgTypes...>::result_type 
+      function& operator=(F); 
+    template<class F> 
+      requires CopyConstructible<F> && Callable<F, ArgTypes...> 
+            && Convertible<Callable<F, ArgTypes...>::result_type, R> 
+      function& operator=(F&&);
+    ...
+};
+
          
+
+
          
+Each of the 3 pairs above are ambiguous.  We need only one of each pair, and we
+could do it with either one.  If we choose the F&& version we
+need to bring decay into the definition to get the pass-by-value behavior.
+In the proposed wording I've gotten lazy and just used the pass-by-value signature.
+
          
+
+
          [
+2009-05-01 Daniel adds:
+]
          
+
+
+
          
+1024 modifies the second removed constructor.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We briefly discussed whether we ought support moveable function objects,
+but decided that should be a separate issue if someone cares to propose it.
+
          
+
          
+Move to Tentatively Ready.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change the synopsis of 20.7.16.2 [func.wrap.func], and remove the associated definitions in
+20.7.16.2.1 [func.wrap.func.con]:
+
          
+
+
          template<Returnable R, CopyConstructible... ArgTypes> 
+class function<R(ArgTypes...)>
+{
+    ...
+    template<class F> 
+      requires CopyConstructible<F> && Callable<F, ArgTypes...> 
+            && Convertible<Callable<F, ArgTypes...>::result_type, R> 
+      function(F); 
+    template<class F> 
+      requires CopyConstructible<F> && Callable<F, ArgTypes...> 
+            && Convertible<Callable<F, ArgTypes...>::result_type, R> 
+      function(F&&);
+    ...
+    template<class F, Allocator Alloc> function(allocator_arg_t, const Alloc&, F); 
+    template<class F, Allocator Alloc> function(allocator_arg_t, const Alloc&, F&&);
+    ...
+    template<class F> 
+      requires CopyConstructible<F> && Callable<F, ArgTypes..> 
+            && Convertible<Callable<F, ArgTypes...>::result_type 
+      function& operator=(F); 
+    template<class F> 
+      requires CopyConstructible<F> && Callable<F, ArgTypes...> 
+            && Convertible<Callable<F, ArgTypes...>::result_type, R> 
+      function& operator=(F&&);
+    ...
+};
+
          
+
+
+
+
+
+
+
          
+
          1071. is_bind_expression should derive from integral_constant<bool>
          
+
          Section: 20.7.12.1.1 [func.bind.isbind] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-19  Last modified: 2009-05-31
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          
+Class template is_bind_expression 20.7.12.1.1 [func.bind.isbind]:
+
          
+
+
          namespace std {
+  template<class T> struct is_bind_expression {
+    static const bool value = see below;
+  };
+}
+
          
+
          
+is_bind_expression should derive from std::integral_constant<bool> like
+other similar trait types.
+
          
+
+
          [
+Daniel adds:
+]
          
+
+
          
+We need the same thing for the trait is_placeholder as well.
+
          
+
          [
+2009-03-22 Daniel provided wording.
+]
          
+
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We recommend this be deferred until after the next Committee Draft is issued.
+
          
+
          
+Move to Open.
+
          
+
          
+
+
          [
+2009-05-31 Peter adds:
+]
          
+
+
+
          
+
          
+I am opposed to the proposed resolution and to the premise of the issue
+in general. The traits's default definitions should NOT derive from
+integral_constant, because this is harmful, as it misleads people into
+thinking that is_bind_expression<E> always derives from
+integral_constant, whereas it may not.
+
          
+
          
+is_bind_expression and is_placeholder allow user
+specializations, and in fact, this is their primary purpose. Such user
+specializations may not derive from integral_constant, and the
+places where is_bind_expression and is_placeholder are
+used intentionally do not require such derivation.
+
          
+
          
+The long-term approach here is to switch to
+BindExpression<E> and Placeholder<P>
+explicit concepts, of course, but until that happens, I say leave them
+alone.
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
            
+
          1. 
+
            
+In 20.7.12.1.1 [func.bind.isbind] change as indicated:
+
            
+
            namespace std {
+ template<class T> struct is_bind_expression : integral_constant<bool, see below> { };{
+   static const bool value = see below;
+ };
+}
+
            
+
            2. 
+
          2. 
+
            
+In 20.7.12.1.1 [func.bind.isbind]/2 change as indicated:
+
            
+
            static const bool value;
+
            
+
            
+-2- true if T is a type returned from bind, false otherwise.
+  If T is a type returned from bind, is_bind_expression<T> shall
+be publicly derived from
+        integral_constant<bool, true>, otherwise it shall be
+publicly derived from
+          integral_constant<bool, false>.
+
            
+
            
+
            3. 
+
          3. 
+
            
+In 20.7.12.1.2 [func.bind.isplace] change as indicated:
+
            
+
            namespace std {
+ template<class T> struct is_placeholder : integral_constant<int, see below> { };{
+   static const int value = see below;
+ };
+}
+
            
+
            4. 
+
          4. 
+
            
+In 20.7.12.1.2 [func.bind.isplace]/2 change as indicated:
+
            
+
            static const int value;
+
            
+
            
+-2- value is J if T is the type of std::placeholders::_J, 0 otherwise.
+  If T is the type of std::placeholders::_J, is_placeholder<T>
+shall be publicly
+          derived from integral_constant<int, J> otherwise it shall
+be publicly derived
+          from integral_constant<int, 0>.
+
            
+
            
+
            5. 
+
          
+
+
+
+
+
+
          
+
          1072. Is std::hash a constrained template or not?
          
+
          Section: 20.7.17 [unord.hash] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-19  Last modified: 2009-05-23
          
+
          View other active issues in [unord.hash].
          
+
          View all other issues in [unord.hash].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          
+Is std::hash a constrained template or not?
+
          
+
          
+According to Class template hash 20.7.17 [unord.hash], the definition is:
+
          
+
+
          template <class T>
+struct hash : public std::unary_function<T, std::size_t> {
+  std::size_t operator()(T val) const;
+};
+
          
+
+
          
+And so unconstrained.
+
          
+
          
+According to the <functional> synopsis in p2 Function objects
+20.7 [function.objects] the template is declared as:
+
          
+
+
          template <ReferentType T> struct hash;
+
          
+
+
          
+which would make hash a constrained template.
+
          
+
+
          [
+2009-03-22 Daniel provided wording.
+]
          
+
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Alisdair is not certain that Daniel's proposed resolution is sufficient,
+and recommends we leave the hash template unconstrained for now.
+
          
+
          
+Recommend that the Project Editor make the constrained declaration consistent
+with the definition in order to make the Working Paper internally consistent,
+and that the issue then be revisited.
+
          
+
          
+Move to Open.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
+
          
+[To the editor: This resolution is merge-compatible to the
+resolution of 1078]
+
          
+
+
            
+
          1. 
+
            
+In 20.7 [function.objects]/2, header <functional> synopsis, change as indicated:
+
            
+
+
            // 20.6.17, hash function base template:
+template <ReferentType T> struct hash; // undefined
+
            
+
            2. 
+
          2. 
+
            
+In 20.7.17 [unord.hash]/1 change as indicated:
+
            
+
            namespace std {
+ template <class T>
+ struct hash : public std::unary_function<T, std::size_t> {
+ std::size_t operator()(T val) const;
+ };
+ template <ReferentType T> struct hash; // undefined
+}
+
            
+
            3. 
+
          3. 
+
            
+In 20.7.17 [unord.hash]/2 change as indicated:
+
            
+
+
            
+-2-  For all library-provided specializations, the template
+instantiation hash<T>
+  shall provide a public operator() with return type std::size_t to
+satisfy the concept
+  requirement Callable<const hash<T>, const T&>. If T is an object
+type or reference to
+  object, hash<T> shall be publicly derived from
+std::unary_function<T, std::size_t>.
+   The return value of operator() is unspecified, except that
+equal arguments
+  shall yield the same result. operator() shall not throw exceptions.
+
            
+
            4. 
+
          4. 
+
            
+In 18.7 [support.rtti]/1, header <typeinfo> synopsis change as indicated:
+
            
+
            namespace std {
+  class type_info;
+  class type_index;
+  template <classReferentType T> struct hash;
+
            
+
            5. 
+
          
+
+
+
+
+
+
          
+
          1073. Declaration of allocator_arg should be constexpr
          
+
          Section: 20.8 [memory] Status: Tentatively Ready
+ Submitter: Alisdair Meredith Opened: 2009-03-19  Last modified: 2009-05-23
          
+
          View other active issues in [memory].
          
+
          View all other issues in [memory].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
+
          
+Declaration of allocator_arg should be constexpr to ensure constant
+initialization.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.  Move to Tentatively Ready.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 20.8 [memory] p2:
+
          
+
+
          // 20.8.1, allocator argument tag
+struct allocator_arg_t { };
+constexpr allocator_arg_t allocator_arg = allocator_arg_t();
+
          
+
+
+
+
+
+
+
          
+
          1074. concept map broken by N2840
          
+
          Section: 20.8.3 [allocator.element.concepts] Status: Tentatively NAD
+ Submitter: Alisdair Meredith Opened: 2009-03-19  Last modified: 2009-05-23
          
+
          View all issues with Tentatively NAD status.
          
+
          Discussion:
          
+
+
          
+p7 Allocator-related element concepts 20.8.3 [allocator.element.concepts]
+
          
+
+
          
+The changes to the AllocatableElement concept mean this concept_map
+specialization no longer matches the original concept:
+
          
+
+
          template <Allocator Alloc, class T, class ... Args>
+  requires HasConstructor<T, Args...>
+    concept_map AllocatableElement<Alloc, T, Args&&...> {
+      void construct_element(Alloc& a, T* t, Args&&... args) {
+        Alloc::rebind<T>(a).construct(t, forward(args)...);
+      }
+    }
+
          
+
+
          [
+2009-03-23 Pablo adds:
+]
          
+
+
+
          
+Actually, this is incorrect,
+N2840
+says. "In section 
+20.8.3 [allocator.element.concepts] paragraph 8, modify the definition of the
+AllocatableElement concept and eliminate the related concept map:" but
+then neglects to include the red-lined text of the concept map that was
+to be eliminated. Pete also missed this, but I caught it he asked me to
+review his edits.  Pete's updated WP removes the concept map entirely,
+which was the original intent.  The issue is, therefore, moot.  Note, as
+per my presentation of
+N2840
+in summit, construct() no longer has a
+default implementation.  This regrettable fact was deemed (by David
+Abrahams, Doug, and myself) to be preferable to the complexity of
+providing a default implementation that would not under-constrain a more
+restrictive allocator (like the scoped allocators).
+
          
+
+
          [
+2009-05-01 Daniel adds:
+]
          
+
+
          
+
          
+it seems to me that #1074 should be resolved as a NAD, because the
+current WP has already removed the previous AllocatableElement concept map.
+It introduced auto concept AllocatableElement instead, but as of
+20.8.3 [allocator.element.concepts]/7 this guy contains now
+
          
+
          requires FreeStoreAllocatable<T>;
+void Alloc::construct(T*, Args&&...);
+
          
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+The affected code is no longer part of the Working Draft.
+
          
+
          
+Move to NAD.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 20.8.3 [allocator.element.concepts]:
+
          
+
+
          template <Allocator Alloc, class T, class ... Args>
+  requires HasConstructor<T, Args...>
+    concept_map AllocatableElement<Alloc, T, Args&&...> {
+      void construct_element(Alloc& a, T* t, Args&&... args) {
+        Alloc::rebind<T>(a).construct(t, forward(args)...);
+      }
+    }
+
          
+
+
+
+
+
+
+
          
+
          1075. Response to US 65, US 74.1
          
+
          Section: 20 [utilities], 23 [containers] Status: Open
+ Submitter: Alan Talbot Opened: 2009-03-20  Last modified: 2009-06-10
          
+
          View all other issues in [utilities].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          Addresses US 65 and US 74.1
          
+
+
          US 65:
          
+
+
          
+Scoped allocators and allocator propagation traits add a small amount of
+utility at the cost of a great deal of machinery. The machinery is user
+visible, and it extends to library components that don't have any
+obvious connection to allocators, including basic concepts and simple
+components like pair and tuple.
+
+
          Suggested resolution:
          
+
+
          
+Sketch of proposed resolution: Eliminate scoped allocators, replace
+allocator propagation traits with a simple uniform rule (e.g. always
+propagate on copy and move), remove all mention of allocators from
+components that don't explicitly allocate memory (e.g. pair), and adjust
+container interfaces to reflect this simplification.
+
          
+
          
+Components that I propose eliminating include HasAllocatorType,
+is_scoped_allocator, allocator_propagation_map, scoped_allocator_adaptor,
+and ConstructibleAsElement.
+
          
+
          
+
+
          US 74.1:
          
+
+
          
+
          
+Scoped allocators represent a poor trade-off for standardization, since
+(1) scoped-allocator--aware containers can be implemented outside the
+C++ standard library but used with its algorithms, (2) scoped
+allocators only benefit a tiny proportion of the C++ community
+(since few C++ programmers even use today's allocators), and (3) all C++
+users, especially the vast majority of the C++ community that won't ever
+use scoped allocators are forced to cope with the interface complexity
+introduced by scoped allocators.
+
          
+
          
+In essence, the larger community will suffer to support a very small
+subset of the community who can already implement their own
+data structures outside of the standard library. Therefore, scoped
+allocators should be removed from the working paper.
+
          
+
          
+Some evidence of the complexity introduced by scoped allocators:
+
          
+
          
+
          
+20.3.3 [pairs], 20.5 [tuple]: Large increase in the
+number of pair and tuple constructors.
+
          
+
          
+23 [containers]: Confusing "AllocatableElement" requirements throughout.
+
          
+
          
+
          Suggested resolution:
          
+
+
          
+Remove support for scoped allocators from the working paper. This
+includes at least the following changes:
+
          
+
+
          
+
          
+Remove 20.8.3 [allocator.element.concepts]
+
          
+
          
+Remove 20.8.7 [allocator.adaptor]
+
          
+
          
+Remove 20.8.10 [construct.element]
+
          
+
          
+In Clause 23 [containers]: replace requirements naming the
+AllocatableElement concept with requirements naming CopyConstructible,
+MoveConstructible, DefaultConstructible, or Constructible, as
+appropriate.
+
          
+
          
+
+
          
+
+
          [
+Post Summit Alan moved from NAD to Open.
+]
          
+
+
+
          [
+2009-05-15 Ganesh adds:
+]
          
+
+
+
          
+
          
+The requirement AllocatableElement should not be replaced with
+Constructible on the emplace_xxx() functions as suggested. In the
+one-parameter case the Constructible requirement is not satisfied when
+the constructor is explicit (as per 14.10.2.1 [concept.map.fct], twelfth
+bullet) but we do want to allow explicit constructors in emplace, as the
+following example shows:
+
          
+
+
          vector<shared_ptr<int>> v;
+v.emplace_back(new int); // should be allowed
+
          
+
+
          
+If the issue is accepted and scoped allocators are removed, I suggest to
+add a new pair of concepts to 20.2.7 [concept.construct], namely:
+
          
+
+
          auto concept HasExplicitConstructor<typename T, typename... Args> {
+ explicit T::T(Args...);
+}
+
+auto concept ExplicitConstructible<typename T, typename... Args>
+ : HasExplicitConstructor<T, Args...>, NothrowDestructible<T>
+{ }
+
          
+
+
          
+We should then use ExplicitConstructible as the requirement for all
+emplace_xxx() member functions.
+
          
+
          
+For coherence and consistency with the similar concepts
+Convertible/ExplicitlyConvertible, we might also consider changing
+Constructible to:
+
          
+
+
          auto concept Constructible<typename T, typename... Args>
+ : HasConstructor<T, Args...>, ExplicitConstructible<T, Args...>
+{ }
+
          
+
+
          
+Moreover, all emplace-related concepts in 23.2.6 [container.concepts]
+should also use ExplicitConstructible instead of Constructible in the
+definitions of their axioms. In fact the concepts in 23.2.6 [container.concepts] should be
+corrected even if the issue is not accepted.
+
          
+
          
+On the other hand, if the issue is not accepted, the scoped allocator
+adaptors should be fixed because the following code:
+
          
+
+
          template <typename T> using scoped_allocator = scoped_allocator_adaptor<allocator<T>>;
+
+vector<shared_ptr<int>, scoped_allocator<shared_ptr<int>>> v;
+v.emplace_back(new int); // ops! doesn't compile
+
          
+
+
          
+doesn't compile, as the member function construct() of the scoped
+allocator requires non-explicit constructors through concept
+ConstructibleWithAllocator. Fixing that is not difficult but probably
+more work than it's worth and is therefore, IMHO, one more reason in
+support of the complete removal of scoped allocators.
+
          
+
          
+
+
          [
+2009-06-09 Alan adds:
+]
          
+
+
+
          
+
          
+I reopened this issue because I did not think that these National Body
+comments were adequately addressed by marking them NAD. My understanding
+is that something can be marked NAD if it is clearly a misunderstanding
+or trivial, but a substantive issue that has any technical merit
+requires a disposition that addresses the concerns.
+
          
+
          
+The notes in the NB comment list (US 65 & US 74.1) say that:
+
          
+
            
+
          1. 
+this issue has not introduced any new arguments not previously discussed,
+
            2. 
+
          2. 
+the vote (4-9-3) was not a consensus for removing scoped allocators,
+
            3. 
+
          3. 
+the issue is resolved by
+N2840.
+
            4. 
+
          
+
          
+My opinion is:
+
          
+
            
+
          1. 
+there are new arguments in both comments regarding concepts (which were
+not present in the library when the scoped allocator proposal was voted
+in),
+
            2. 
+
          2. 
+the vote was clearly not a consensus for removal, but just saying there
+was a vote does not provide a rationale,
+
            3. 
+
          3. 
+I do not believe that N2840 addresses these comments (although it does
+many other things and was voted in with strong approval).
+
            4. 
+
          
+
+
          
+My motivation to open the issue was to ensure that the NB comments were
+adequately addressed in a way that would not risk a "no" vote on our
+FCD. If there are responses to the technical concerns raised, then
+perhaps they should be recorded. If the members of the NB who authored
+the comments are satisfied with N2840 and the other disposition remarks
+in the comment list, then I am sure they will say so. In either case,
+this issue can be closed very quickly in Frankfurt, and hopefully will
+have helped make us more confident of approval with little effort. If in
+fact there is controversy, my thought is that it is better to know now
+rather than later so there is more time to deal with it.
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1076. unary/binary_negate need constraining and move support
          
+
          Section: 20.7.11 [negators] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-03-20  Last modified: 2009-05-23
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+The class templates unary/binary_negate need constraining and move support.
+
          
+
          
+Ideally these classes would be deprecated, allowing unary/binary_function to
+also be deprecated.  However, until a generic negate adaptor is introduced
+that can negate any Callable type, they must be supported so should be
+constrained.  Likewise, they should be movable, and support adopting a
+move-only predicate type.
+
          
+
          
+In order to preserve ABI compatibility, new rvalue overloads are supplied in
+preference to changing the existing pass-by-const-ref to pass-by-value.
+
          
+
          
+Do not consider the issue of forwarding mutable lvalues at this point,
+although remain open to another issue on the topic.
+
          
+
+
          [
+2009-05-01 Daniel adds:
+]
          
+
+
          
+
          
+IMO the currently proposed resolution needs some updates
+because it is ill-formed at several places:
+
          
+
+
            
+
          1. 
+
            
+In concept AdaptableUnaryFunction change
+
            
+
            typename X::result_type;
+typename X::argument_type;
+
            
+
            
+to
+
            
+
            Returnable result_type = typename X::result_type;
+typename argument_type = typename X::argument_type;
+
            
+
            
+[The replacement "Returnable result_type" instead of "typename
+result_type" is non-editorial, but maybe you prefer that as well]
+
            
+
            2. 
+
          2. 
+
            
+In concept AdaptableBinaryFunction change
+
            
+
            typename X::result_type;
+typename X::first_argument_type;
+typename X::second_argument_type;
+
            
+
            
+to
+
            
+
            Returnable result_type = typename X::result_type;
+typename first_argument_type = typename X::first_argument_type;
+typename second_argument_type = typename X::second_argument_type;
+
            
+
            
+[The replacement "Returnable result_type" instead of "typename
+result_type" is non-editorial, but maybe you prefer that as well.]
+
            
+
            3. 
+
+
          3. 
+
            
+In class unary/binary_function
+
            
+
              
+
            1. 
+I suggest to change "ReturnType" to "Returnable" in both cases.
+
              2. 
+
            2. 
+I think you want to replace the remaining occurrences of "Predicate" by "P"
+(in both classes in copy/move from a predicate)
+
              3. 
+
            
+
            4. 
+
          4. 
+
            
+I think you need to change the proposed signatures of not1 and not2, because
+they would still remain unconstrained: To make them constrained at least a
+single requirement needs to be added to enable requirement implication. This
+could be done via a dummy ("requires True<true>") or just explicit as follows:
+
            
+
              
+
            1. 
+
              template <AdaptableUnaryFunction P>
+requires Predicate< P, P::argument_type>
+unary_negate<P> not1(const P&& pred);
+template <AdaptableUnaryFunction P>
+requires Predicate< P, P::argument_type >
+unary_negate<P> not1(P&& pred);
+
              
+
              
+-3- Returns: unary_negate<P>(pred).
+
              
+
              
+
              
+[Don't we want a move call for the second overload as in
+
              
+
              unary_negate<P>(std::move(pred))
+
              
+
              
+in the Returns clause ?]
+
              
+
              2. 
+
            2. 
+
              template <AdaptableBinaryFunction P>
+requires Predicate< P, P::first_argument_type, P::second_argument_type >
+binary_negate<P> not2(const P& pred);
+template <AdaptableBinaryFunction P>
+requires Predicate< P, P::first_argument_type, P::second_argument_type >
+binary_negate<P> not2(P&& pred);
+
              
+
              
+-5- Returns: binary_negate<P>(pred).
+
              
+
              
+[Don't we want a move call for the second overload as in
+
              
+
              binary_negate<P>(std::move(pred))
+
              
+
              
+in the Returns clause ?]
+
              
+
              3. 
+
            
+
            5. 
+
          
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+There is concern that complicating the solution
+to preserve the ABI seems unnecessary,
+since we're not in general preserving the ABI.
+
          
+
          
+We would prefer a separate paper consolidating all Clause 20
+issues that are for the purpose of providing constrained versions
+of the existing facilities.
+
          
+
          
+Move to Open.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+Add new concepts where appropriate::
+
          
+
+
          auto concept AdaptableUnaryFunction< typename X > {
+  typename X::result_type;
+  typename X::argument_type;
+}
+
+auto concept AdaptableBinaryFunction< typename X > {
+  typename X::result_type;
+  typename X::first_argument_type;
+  typename X::second_argument_type;
+}
+
          
+
+
          
+Revise as follows:
+
          
+
+
          
+Base 20.7.3 [base] (Only change is constrained Result)
+
          
+
+
          
+
          
+-1-  The following classes are provided to simplify the typedefs of the
+argument and result types:
+
          
+
          namespace std {
+  template <class Arg, class ReturnType Result>
+  struct unary_function {
+     typedef Arg    argument_type;
+     typedef Result result_type;
+  };
+
+  template <class Arg1, class Arg2, class ReturnType Result>
+  struct binary_function {
+     typedef Arg1   first_argument_type;
+     typedef Arg2   second_argument_type;
+     typedef Result result_type;
+  };
+}
+
          
+
+
          
+Negators 20.7.11 [negators]:
+
          
+
+
          
+
          
+-1- Negators not1 and not2 take a unary and a binary predicate,
+respectively, and return their complements (5.3.1).
+
          
+
+
          template <class AdaptableUnaryFunction Predicate>
+  requires Predicate< P, P::argument_type >
+  class unary_negate
+    : public unary_function<typename Predicate::argument_type,bool> {
+  public:
+    unary_negate(const unary_negate & ) = default;
+    unary_negate(unary_negate && );
+
+    requires CopyConstructible< P >
+       explicit unary_negate(const Predicate& pred); 
+    requires MoveConstructible< P >
+       explicit unary_negate(Predicate && pred);
+
+    bool operator()(const typename Predicate::argument_type& x) const;
+  };
+
          
+
          
+-2 operator() returns !pred(x).
+
          
+
+
          template <class Predicate>
+  unary_negate<Predicate> not1(const Predicate&amp; pred);
+template <class Predicate>
+  unary_negate<Predicate> not1(Predicate&& pred);
+
          
+
          
+-3-  Returns: unary_negate<Predicate>(pred).
+
          
+
+
          template <class AdaptableBinaryFunction Predicate >
+  requires Predicate< P, P::first_argument_type, P::second_argument_type >
+  class binary_negate
+    : public binary_function<typename Predicate::first_argument_type,
+                              typename Predicate::second_argument_type, bool> {
+  public:
+    biary_negate(const binary_negate & ) = default;
+    binary_negate(binary_negate && );
+
+    requires CopyConstructible< P >
+       explicit binary_negate(const Predicate& pred);
+    requires MoveConstructible< P >
+       explicit binary_negate(const Predicate& pred);
+
+    bool operator()(const typename Predicate::first_argument_type& x,
+                    const typename Predicate::second_argument_type& y) const;
+  };
+
          
+
          
+-4- operator() returns !pred(x,y).
+
          
+
+
          template <class Predicate>
+  binary_negate<Predicate> not2(const Predicate& pred);
+template <class Predicate>
+  binary_negate<Predicate> not2(Predicate&& pred);
+
          
+
+
          
+-5- Returns: binary_negate<Predicate>(pred).
+
          
+
          
+
+
+
+
+
+
+
          
+
          1077. Nonesense tuple declarations
          
+
          Section: 20.5.2 [tuple.tuple] Status: Tentatively NAD Editorial
+ Submitter: Pete Becker Opened: 2009-03-20  Last modified: 2009-05-23
          
+
          View other active issues in [tuple.tuple].
          
+
          View all other issues in [tuple.tuple].
          
+
          View all issues with Tentatively NAD Editorial status.
          
+
          Discussion:
          
+
          
+Class template tuple 20.5.2 [tuple.tuple]:
+
          
+
+
          template <class... UTypes>
+  requires Constructible<Types, const UTypes&>...
+template <class... UTypes>
+  requires Constructible<Types, RvalueOf<UTypes>::type>...
+
          
+
+
          
+Somebody needs to look at this and say what it should be.
+
          
+
+
          [
+2009-03-21 Daniel provided wording.
+]
          
+
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+The resolution looks correct; move to NAD Editorial.
+
          
+
+
+
          Proposed resolution:
          
+
          
+In 20.5.2 [tuple.tuple], class tuple, change as indicated:
+
          
+
+
          template <class... UTypes>
+  requires Constructible<Types, const UTypes&>...
+  tuple(const pair<UTypes...>&);
+template <class... UTypes>
+  requires Constructible<Types, RvalueOf<UTypes>::type>...
+  tuple(pair<UTypes...>&&);
+
          
+
+
          
+[NB.: The corresponding prototypes do already exist in 20.5.2.1 [tuple.cnstr]/7+8]
+
          
+
+
+
+
+
+
          
+
          1078. DE-17: Remove class type_index
          
+
          Section: 18.7.2 [type.index] Status: Open
+ Submitter: Doug Gregor Opened: 2009-03-20  Last modified: 2009-03-31
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          Addresses DE 17
          
+
+
          
+DE-17: 
+
          
+
          
+The class type_index should be removed; it provides no additional
+functionality beyond providing appropriate concept maps.
+
          
+
+
          [
+2009-03-31 Peter adds:
+]
          
+
+
+
          
+
          
+It is not true, in principle, that std::type_index provides no  utility
+compared to bare std::type_info*.
+
          
+
          
+std::type_index can avoid the lifetime issues with type_info when  the
+DLL that has produced the type_info object is unloaded. A raw
+type_info* does not, and cannot, provide any protection in this  case.
+A type_index can (if the implementor so chooses) because it  can wrap a
+smart (counted or even cloning) pointer to the type_info  data that is
+needed for name() and before() to work.
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
          Modify the header <typeinfo> synopsis in 
+  18.7 [support.rtti]p1 as follows:
          
+
+
          namespace std { 
+  class type_info; 
+  class type_index;
+  template <class T> struct hash;
+  template<> struct hash<type_indexconst type_info *> : public std::unary_function<type_indexconst type_info *, size_t> {
+    size_t operator()(type_indexconst type_info * indext) const;
+  };
+  concept_map LessThanComparable<const type_info *> see below
+  class bad_cast; 
+  class bad_typeid;
+}
+
          
+
+
          Add the following new subsection
          
+
          
+
          
+18.7.1.1 Template specialization hash<const type_info *>
+[type.info.hash]
          
+
+
          size_t operator()(const type_info *x) const;
+
          
+
            
+
          1. Returns: x->hash_code()
            2. 
+
          
+
          
+
+ 
          Add the following new subsection
          
+ 
          
+
          18.7.1.2 type_info concept map [type.info.concepts]
          
+
+
+
          concept_map LessThanComparable<const type_info *> {
+  bool operator<(const type_info *x, const type_info *y) { return x->before(*y); }
+  bool operator<=(const type_info *x, const type_info *y) { return !y->before(*x); }
+  bool operator>(const type_info *x, const type_info *y) { return y->before(*x); }
+  bool operator>=(const type_info *x, const type_info *y) { return !x->before(*y); }
+}
+
          
+
            
+  
          1. Note: provides a well-defined ordering among
+  type_info const pointers, which makes such pointers
+  usable in associative containers (23.4).
            2. 
+
          
+
          
+
+
          Remove section 18.7.2 [type.index]
          
+
+
+
+
+
+
          
+
          1079. UK-265: RandomAccessIterator's operator- has nonsensical effects clause
          
+
          Section: 24.2.6 [random.access.iterators] Status: Open
+ Submitter: Doug Gregor Opened: 2009-03-20  Last modified: 2009-03-22
          
+
          View other active issues in [random.access.iterators].
          
+
          View all other issues in [random.access.iterators].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          Addresses UK 265
          
+
+
          UK-265:
          
+
          
+This effects clause is nonesense. It looks more like an axiom stating
+equivalence, and certainly an effects clause cannot change the state of
+two arguments passed by const reference
+
          
+
+
+
+
          Proposed resolution:
          
+
+
          Modify 24.2.6 [random.access.iterators]p7-9 as follows:
          
+
+
          difference_type operator-(const X& a, const X& b);
+
          
+
            
+  
          1. Precondition: there exists a value n of
+  difference_type such that a == b + n.
            2. 
+  
          2. Effects: b == a + (b - a)
            3. 
+  
          3. Returns: (a < b) ? distance(a,b) :
+  -distance(b,a)n
            4. 
+
          
+
          
+
+
+
+
+
+
          
+
          1080. Concept ArithmeticLike should provide explicit boolean  conversion
          
+
          Section: 20.2.13 [concept.arithmetic] Status: Review
+ Submitter: Daniel Krügler Opened: 2009-03-21  Last modified: 2009-05-23
          
+
          View all issues with Review status.
          
+
          Discussion:
          
+
          
+Astonishingly, the current concept ArithmeticLike as specified in
+20.2.13 [concept.arithmetic] does not provide explicit conversion
+to bool although this is a common property of arithmetic types
+(4.12 [conv.bool]). Recent proposals that introduced such types
+(integers of arbitrary precision,
+n2143,
+decimals
+n2732
+indirectly
+via conversion to long long) also took care of such a feature.
+
          
+
          
+Adding such an explicit conversion associated function would also
+partly solve a currently invalid effects clause in library, which bases
+on this property, 24.2.6 [random.access.iterators]/2:
+
          
+
          { difference_type m = n;
+ if (m >= 0) while (m--) ++r;
+ else while (m++) --r;
+ return r; }
+
          
+
+
          
+Both while-loops take advantage of a contextual conversion to bool
+(Another problem is that the >= comparison uses the no
+longer supported existing implicit conversion from int to IntegralLike).
+
          
+
+Original proposed resolution:
+
            
+
          1. 
+
            
+In 20.2.13 [concept.arithmetic], add to the list of less refined
+concepts one further concept:
+
            
+
+
            concept ArithmeticLike<typename T>
+  : Regular<T>, LessThanComparable<T>, HasUnaryPlus<T>, HasNegate<T>,
+    HasPlus<T, T>, HasMinus<T, T>, HasMultiply<T, T>, HasDivide<T, T>,
+    HasPreincrement<T>, HasPostincrement<T>, HasPredecrement<T>,
+    HasPostdecrement<T>,
+    HasPlusAssign<T, const T&>, HasMinusAssign<T, const T&>,
+    HasMultiplyAssign<T, const T&>,
+    HasDivideAssign<T, const T&>, ExplicitlyConvertible<T, bool> {
+
            
+
            2. 
+
          2. 
+
            
+In 24.2.6 [random.access.iterators]/2 change the current effects clause
+as indicated [The proposed insertion fixes the problem that the previous
+implicit construction from integrals has been changed to an explicit
+constructor]:
+
            
+
            { difference_type m = n;
+ if (m >= difference_type(0)) while (m--) ++r;
+ else while (m++) --r;
+ return r; }
+
            
+
            3. 
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We agree that arithmetic types ought be convertible to bool,
+and we therefore agree with the proposed resolution's paragraph 1.
+
          
+
          
+We do not agree that the cited effects clause is invalid,
+as it expresses intent rather than specific code.
+
          
+
          
+Move to Review, pending input from concepts experts.
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+In 20.2.13 [concept.arithmetic], add to the list of less refined
+concepts one further concept:
+
          
+
+
          concept ArithmeticLike<typename T>
+  : Regular<T>, LessThanComparable<T>, HasUnaryPlus<T>, HasNegate<T>,
+    HasPlus<T, T>, HasMinus<T, T>, HasMultiply<T, T>, HasDivide<T, T>,
+    HasPreincrement<T>, HasPostincrement<T>, HasPredecrement<T>,
+    HasPostdecrement<T>,
+    HasPlusAssign<T, const T&>, HasMinusAssign<T, const T&>,
+    HasMultiplyAssign<T, const T&>,
+    HasDivideAssign<T, const T&>, ExplicitlyConvertible<T, bool> {
+
          
+
+
+
+
+
+
          
+
          1081. Response to UK 216
          
+
          Section: 21 [strings] Status: Open
+ Submitter: Howard Hinnant Opened: 2009-03-22  Last modified: 2009-03-22
          
+
          View all other issues in [strings].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          Addresses UK 216, JP 46, JP 48
          
+
+
          
+All the containers use concepts for their iterator usage, exect for
+basic_string. This needs fixing.
+
          
+
+
          
+Use concepts for iterator template parameters throughout the chapter.
+
          
+
+
          [
+Summit:
+]
          
+
+
          
+NB comments to be handled by Dave Abrahams and Howard Hinnant with
+advice from PJP: UK216 (which duplicates) JP46, JP48. JP46 supplies
+extensive proposed wording; start there.
+
          
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1082. Response to JP 49
          
+
          Section: 22 [localization] Status: Open
+ Submitter: Howard Hinnant Opened: 2009-03-22  Last modified: 2009-03-22
          
+
          View other active issues in [localization].
          
+
          View all other issues in [localization].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          Addresses JP 49
          
+
+
          
+codecvt does not use concept. For example, create CodeConvert
+concept and change as follows.
+
          
+
+
          template<CodeConvert Codecvt, class Elem = wchar_t>
+  class wstring_convert {
+
          
+
+
          [
+Summit:
+]
          
+
+
          
+To be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plauger.
+
          
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1083. Response to JP 52, 53
          
+
          Section: 22 [localization] Status: Open
+ Submitter: Howard Hinnant Opened: 2009-03-22  Last modified: 2009-03-22
          
+
          View other active issues in [localization].
          
+
          View all other issues in [localization].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          Addresses JP 52, JP 53
          
+
+
          
+InputIterator does not use concept.
+
          
+
+
          
+OutputIterator does not use concept.
+
          
+
+
          
+Comments include proposed wording.
+
          
+
+
          [
+Summit:
+]
          
+
+
          
+To be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plauger.
+
          
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1084. Response to UK 250
          
+
          Section: 24.2.4 [forward.iterators] Status: Open
+ Submitter: Howard Hinnant Opened: 2009-03-22  Last modified: 2009-06-09
          
+
          View all other issues in [forward.iterators].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          Addresses UK 250
          
+
+
          
+A default implementation should be supplied for the post-increment
+operator to simplify implementation of iterators by users.
+
          
+
+
          
+Copy the Effects clause into the concept description as the default
+implementation. Assumes a default value for postincrement_result
+
          
+
+
          [
+Summit:
+]
          
+
+
          
+Howard will open an issue.
+
          
+
+
          [
+2009-06-07 Daniel adds:
+]
          
+
+
+
          
+This issue cannot currently be resolved as suggested, because
+that would render auto-detection of the return type
+postincrement_result invalid, see 14.10.2.2 [concept.map.assoc]/4+5. The
+best fix would be to add a default type to that associated type, but
+unfortunately any default type will prevent auto-deduction of types of
+associated functions as quoted above. A corresponding core issue
+is in preparation.
+
          
+
+
+
          Proposed resolution:
          
+
          [
+This wording assumes the acceptance of UK 251 / 1009.  Both
+wordings change the same paragraphs.
+]
          
+
+
+
          
+Change 24.2.4 [forward.iterators]:
+
          
+
+
          
+
          concept ForwardIterator<typename X> : InputIterator<X>, Regular<X> { 
+
+  MoveConstructible postincrement_result;
+  requires HasDereference<postincrement_result>
+        && Convertible<HasDereference<postincrement_result>::result_type, const value_type&>;
+
+  postincrement_result operator++(X& r, int); {
+     X tmp = r;
+     ++r;
+     return tmp;
+  }
+
+  axiom MultiPass(X a, X b) { 
+    if (a == b) *a == *b; 
+    if (a == b) ++a == ++b; 
+  } 
+}
+
          
+
+
+
+
+
+
+
          
+
          1085. Response to UK 258
          
+
          Section: 24.2.5 [bidirectional.iterators] Status: Open
+ Submitter: Howard Hinnant Opened: 2009-03-22  Last modified: 2009-06-09
          
+
          View all other issues in [bidirectional.iterators].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          Addresses UK 258
          
+
+
          
+A default implementation should be supplied for the post-decrement
+operator to simplify implementation of iterators by users.
+
          
+
+
          
+Copy the Effects clause into the concept description as the default
+implementation. Assumes a default value for postincrement_result
+
          
+
+
          [
+Summit:
+]
          
+
+
          
+Howard will open an issue.
+
          
+
+
          [
+2009-06-07 Daniel adds:
+]
          
+
+
+
          
+This issue cannot currently be resolved as suggested, because
+that would render auto-detection of the return type
+postdecrement_result invalid, see 1084.
+
          
+
+
+
          Proposed resolution:
          
+
+
          
+Change 24.2.5 [bidirectional.iterators]:
+
          
+
+
          
+
          concept BidirectionalIterator<typename X> : ForwardIterator<X> { 
+  MoveConstructible postdecrement_result; 
+  requires HasDereference<postdecrement_result> 
+        && Convertible<HasDereference<postdecrement_result>::result_type, const value_type&> 
+        && Convertible<postdecrement_result, const X&>; 
+  X& operator--(X&); 
+  postdecrement_result operator--(X& r, int); {
+     X tmp = r;
+     --r;
+     return tmp;
+  }
+}
+
          
+
+
+
+
+
+
+
          
+
          1086. Response to UK 284
          
+
          Section: 24.6 [stream.iterators] Status: Open
+ Submitter: Howard Hinnant Opened: 2009-03-22  Last modified: 2009-03-22
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          Addresses UK 284
          
+
+
          
+The stream iterators need constraining with concepts/requrires clauses.
+
          
+
+
          [
+Summit:
+]
          
+
+
          
+We agree. To be handled by Howard, Martin and PJ.
+
          
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1087. Response to UK 301
          
+
          Section: 25.4.5 [alg.replace] Status: Review
+ Submitter: Howard Hinnant Opened: 2009-03-22  Last modified: 2009-06-11
          
+
          View other active issues in [alg.replace].
          
+
          View all other issues in [alg.replace].
          
+
          View all issues with Review status.
          
+
          Discussion:
          
+
          Addresses UK 301
          
+
+
          
+replace and replace_if have the requirement: OutputIterator<Iter,
+Iter::reference> Which implies they need to copy some values in the
+range the algorithm is iterating over. This is not however the case, the
+only thing that happens is const T&s might be copied over existing
+elements (hence the OutputIterator<Iter, const T&>.
+
          
+
+
          
+Remove OutputIterator<Iter, Iter::reference> from replace
+and replace_if.
+
          
+
+
          [
+Summit:
+]
          
+
+
          
+We agree. To be handled by Howard.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change in 25.2 [algorithms.syn] and 25.4.5 [alg.replace]:
+
          
+
+
          template<ForwardIterator Iter, class T> 
+  requires OutputIterator<Iter, Iter::reference> 
+        && OutputIterator<Iter, const T&> 
+        && HasEqualTo<Iter::value_type, T> 
+  void replace(Iter first, Iter last, 
+               const T& old_value, const T& new_value); 
+
+template<ForwardIterator Iter, Predicate<auto, Iter::value_type> Pred, class T> 
+  requires OutputIterator<Iter, Iter::reference> 
+        && OutputIterator<Iter, const T&> 
+        && CopyConstructible<Pred> 
+  void replace_if(Iter first, Iter last,
+                  Pred pred, const T& new_value);
+
          
+
+
+
+
+
+
          
+
          1088. Response to UK 342
          
+
          Section: 30.6.6 [futures.promise] Status: Open
+ Submitter: Howard Hinnant Opened: 2009-03-22  Last modified: 2009-03-22
          
+
          View other active issues in [futures.promise].
          
+
          View all other issues in [futures.promise].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          Addresses UK 342
          
+
+
          
+std::promise is missing a non-member overload of swap. This is
+inconsistent with other types that provide a swap member function.
+
          
+
+
          
+Add a non-member overload void swap(promise&& x,promise&& y){ x.swap(y); }
+
          
+
+
          [
+Summit:
+]
          
+
+
          
+Create an issue. Move to review, attention: Howard. Detlef will also
+look into it.
+
          
+
+
          [
+Post Summit Daniel provided wording.
+]
          
+
+
+
+
          Proposed resolution:
          
+
            
+
          1. 
+
            
+In 30.6.6 [futures.promise], before p.1, immediately after class template
+promise add:
+
            
+
            
+template <class R>
+void swap(promise<R>& x, promise<R>& y);
+
+
            
+
            2. 
+
          2. 
+
            
+Change 30.6.6 [futures.promise]/10 as indicated (to fix a circular definition):
+
            
+
            
+
            
+-10- Effects: swap(*this, other)Swaps the associated state
+of *this and other
+
            
+
            
+Throws: Nothing.
+
            
+
            
+
            3. 
+
          3. 
+
            
+After the last paragraph in 30.6.6 [futures.promise] add the following
+prototype description:
+
            
+
            
+template <class R>
+void swap(promise<R>& x, promise<R>& y);
+
            
+
            
+
            
+Effects: x.swap(y)
+
            
+
            
+Throws: Nothing.
+
            
+
            
+
            
+
            4. 
+
+
          
+
+
+
+
+
+
+
          
+
          1089. Response to JP 76
          
+
          Section: 30 [thread] Status: Open
+ Submitter: Howard Hinnant Opened: 2009-03-22  Last modified: 2009-03-22
          
+
          View other active issues in [thread].
          
+
          View all other issues in [thread].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          Addresses JP 76
          
+
+
          
+A description for "Throws: Nothing." are not unified.
+
          
+
+
          
+At the part without throw, "Throws: Nothing." should be described.
+
          
+
+
          
+Add "Throws: Nothing." to the following.
+
          
+
+
            
+
          • 
+30.3.1.6 [thread.thread.static] p1
+
            • 
+
          • 
+30.4.3.1 [thread.lock.guard] p4
+
            • 
+
          • 
+30.4.3.2.1 [thread.lock.unique.cons] p6
+
            • 
+
          • 
+30.5.1 [thread.condition.condvar] p7 and p8
+
            • 
+
          • 
+30.5.2 [thread.condition.condvarany] p6, p7, p19, p21 and p25
+
            • 
+
          
+
+
          [
+Summit:
+]
          
+
+
          
+Pass on to editor.
+
          
+
+
          [
+Post Summit:  Editor declares this non-editorial.
+]
          
+
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1090. Missing description of packaged_task member swap,  missing non-member swap
          
+
          Section: 30.6.8 [futures.task] Status: Open
+ Submitter: Daniel Krügler Opened: 2009-03-22  Last modified: 2009-05-24
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+Class template packaged_task in 30.6.8 [futures.task] shows a member swap
+declaration, but misses to
+document it's effects (No prototype provided). Further on this class
+misses to provide a non-member
+swap.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Alisdair notes that paragraph 2 of the proposed resolution has already been
+applied in the current Working Draft.
+
          
+
          
+We note a pending future-related paper by Detlef;
+we would like to wait for this paper before proceeding.
+
          
+
          
+Move to Open.
+
          
+
          
+
+
          [
+2009-05-24 Daniel removed part 2 of the proposed resolution.
+]
          
+
+
+
+
          Proposed resolution:
          
+
            
+
          1. 
+
            
+In 30.6.8 [futures.task], immediately after the definition of class
+template packaged_task add:
+
            
+
            
+template<class R, class... Argtypes>
+void swap(packaged_task<R(ArgTypes...)>&, packaged_task<R(ArgTypes...)>&);
+
+
            
+
            2. 
+
          
+
+
            
+
          1. 
+
            
+In 30.6.8 [futures.task], immediately after operator= prototype
+description (After p. 8) add:
+
            
+
            void swap(packaged_task& other);
+
            
+
            
+
            
+Effects: Swaps the associated state of *this and other.
+
            
+
            
+Throws: Nothing.
+
            
+
            
+
            
+
            2. 
+
          2. 
+
            
+At the end of 30.6.8 [futures.task] (after p. 20), add add the following
+prototype description:
+
            
+
+
            
+template<class R, class... Argtypes>
+void swap(packaged_task<R(ArgTypes...)>& x, packaged_task<R(ArgTypes...)>& y);
+
            
+
            
+
            
+Effects: x.swap(y)
+
            
+
            
+Throws: Nothing.
+
            
+
            
+
            
+
            3. 
+
          
+
+
+
+
+
+
          
+
          1091. Response to UK 246
          
+
          Section: 23.4.2.2 [multimap.modifiers] Status: Review
+ Submitter: Beman Dawes Opened: 2009-03-22  Last modified: 2009-05-23
          
+
          View all issues with Review status.
          
+
          Discussion:
          
+
+
          Addresses UK 246
          
+
          
+The content of this sub-clause is purely trying to describe in words the
+effect of the requires clauses on these operations, now that we have
+Concepts. As such, the description is more confusing than the signature
+itself. The semantic for these functions is adequately covered in the
+requirements tables in 23.2.4 [associative.reqmts].
+
          
+
+
          [
+Beman adds:
+]
          
+
+
+
          
+Pete is clearly right that
+this one is technical rather than editorial.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We agree with the proposed resolution.
+
          
+
          
+Move to Review.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+Strike 23.4.2.2 [multimap.modifiers] entirely
+(but do NOT strike these signatures from the class template definition!).
+
          
+
+
+
+
+
+
          
+
          1092. Class template integral_constant should be a  constrained template
          
+
          Section: 20.6.3 [meta.help] Status: Open
+ Submitter: Daniel Krügler Opened: 2009-03-22  Last modified: 2009-05-23
          
+
          View other active issues in [meta.help].
          
+
          View all other issues in [meta.help].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+A first step to change the type traits predicates to constrained templates is to
+constrain their common base template integral_constant. This can be done,
+without enforcing depending classes to be constrained as well, but not
+vice versa
+without brute force late_check usages. The following proposed resolution depends
+on the resolution of LWG issue 1019.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+Move to Open, pending a paper that looks at constraints
+for the entirety of the type traits
+and their relationship to the foundation concepts.
+We recommend this be deferred
+until after the next Committee Draft is issued.
+
          
+
+
+
          Proposed resolution:
          
+
            
+
          1. 
+
            
+In 20.6.2 [meta.type.synop], Header <type_traits>
+synopsis change as indicated:
+
            
+
            namespace std {
+// 20.5.3, helper class:
+template <classIntegralConstantExpressionType T, T v> struct integral_constant;
+
            
+
            2. 
+
          2. 
+
            
+In 20.6.3 [meta.help] change as indicated:
+
            
+
            template <classIntegralConstantExpressionType T, T v>
+struct integral_constant {
+  static constexpr T value = v;
+  typedef T value_type;
+  typedef integral_constant<T,v> type;
+  constexpr operator value_type() { return value; }
+};
+
            
+
            3. 
+
          
+
+
+
+
+
+
          
+
          1093. Multiple definitions for random_shuffle algorithm
          
+
          Section: 25.4.12 [alg.random.shuffle] Status: Review
+ Submitter: Alisdair Meredith Opened: 2009-03-22  Last modified: 2009-06-09
          
+
          View all other issues in [alg.random.shuffle].
          
+
          View all issues with Review status.
          
+
          Discussion:
          
+
+
          
+There are a couple of issues with the declaration of the random_shuffle
+algorithm accepting a random number engine.
+
          
+
+
            
+
          1. 
+The Iterators must be shuffle iterators, yet this requirement is missing.
+
            2. 
+
          2. 
+The RandomNumberEngine concept is now provided by the random number
+library
+(n2836)
+and the placeholder should be removed.
+
            3. 
+
          
+
+
          [
+2009-05-02 Daniel adds:
+]
          
+
+
+
          
+
          
+this issue completes adding necessary requirement to the
+third new random_shuffle overload. The current suggestion is:
+
          
+
+
          template<RandomAccessIterator Iter, UniformRandomNumberGenerator Rand>
+requires ShuffleIterator<Iter>
+void random_shuffle(Iter first, Iter last, Rand&& g);
+
          
+
+
          
+IMO this is still insufficient and I suggest to add the requirement
+
          
+
          Convertible<Rand::result_type, Iter::difference_type>
+
          
+
          
+to the list (as the two other overloads already have).
+
          
+
+
          
+Rationale:
+
          
+
+
          
+
          
+Its true that this third overload is somewhat different from the remaining
+two. Nevertheless we know from UniformRandomNumberGenerator, that
+it's result_type is an integral type and that it satisfies
+UnsignedIntegralLike<result_type>.
+
          
+
          
+To realize it's designated task, the algorithm has to invoke the
+Callable aspect of g and needs to perform some algebra involving
+it's min()/max() limits to compute another index value that
+at this point is converted into Iter::difference_type. This is so,
+because 24.2.6 [random.access.iterators] uses this type as argument
+of it's algebraic operators. Alternatively consider the equivalent
+iterator algorithms in 24.4 [iterator.operations] with the same result.
+
          
+
          
+This argument leads us to the conclusion that we also need
+Convertible<Rand::result_type, Iter::difference_type> here.
+
          
+
          
+
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Alisdair notes that point (ii) has already been addressed.
+
          
+
          
+We agree with the proposed resolution to point (i)
+with Daniel's added requirement.
+
          
+
          
+Move to Review.
+
          
+
          
+
+
          [
+2009-06-05 Daniel updated proposed wording as recommended in Batavia.
+]
          
+
+
+
+
          Proposed resolution:
          
+
          
+Change in 25.2 [algorithms.syn] and 25.4.12 [alg.random.shuffle]:
+
          
+
+
          concept UniformRandomNumberGenerator<typename Rand> { }
+template<RandomAccessIterator Iter, UniformRandomNumberGenerator Rand>
+  requires ShuffleIterator<Iter> &&
+  Convertible<Rand::result_type, Iter::difference_type>
+  void random_shuffle(Iter first, Iter last, Rand&& g);
+
          
+
+
+
+
+
+
+
          
+
          1094. Response to JP 65 and JP 66
          
+
          Section: 27.5.4.3 [iostate.flags] Status: Review
+ Submitter: P.J. Plauger Opened: 2009-03-24  Last modified: 2009-05-23
          
+
          View all other issues in [iostate.flags].
          
+
          View all issues with Review status.
          
+
          Discussion:
          
+
          Addresses JP 65 and JP 66
          
+
+
          
+Switch from "unspecified-bool-type" to "explicit operator bool() const". 
+
          
+
+
          
+Replace operator unspecified-bool-type() const;" with explicit operator bool() const;
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to Review.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change the synopis in 27.5.4 [ios]:
+
          
+
+
          explicit operator unspecified-bool-type bool() const;
+
          
+
+
          
+Change 27.5.4.3 [iostate.flags]:
+
          
+
+
          explicit operator unspecified-bool-type bool() const;
+
          
+
+
          
+
          
+-1- Returns: !fail() If fail() then a value that will evaluate
+false in a boolean context; otherwise a value that will evaluate true in
+a boolean context. The value type returned shall not be convertible to
+int.
+
          
+
          
+[Note: This conversion can be used in contexts where a bool is expected
+(e.g., an if condition); however, implicit conversions (e.g.,
+to int) that can occur with bool are not allowed,
+eliminating some sources of user error. One possible implementation
+choice for this type is pointer-to-member. -- end note]
+
          
+
          
+
          
+
+
+
+
+
+
+
+
          
+
          1095. Shared objects and the library wording unclear
          
+
          Section: 17.6.3.10 [res.on.objects] Status: Review
+ Submitter: Beman Dawes Opened: 2009-03-27  Last modified: 2009-05-23
          
+
          View all issues with Review status.
          
+
          Discussion:
          
+
          
+N2775,
+Small library thread-safety revisions, among other changes, removed a note from
+17.6.3.10 [res.on.objects] that read:
+
          
+
+
          
+[Note: This prohibition against concurrent non-const access means that
+modifying an object of a standard library type shared between threads
+without using a locking mechanism may result in a data race. --end note.]
+
          
+
+
          
+That resulted in wording which is technically correct but can only be
+understood by reading the lengthy and complex 17.6.4.7 [res.on.data.races]
+Data race avoidance. This has the effect of making
+17.6.3.10 [res.on.objects] unclear, and has already resulted in a query
+to the LWG reflector. See c++std-lib-23194.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+The proposed wording seems to need a bit of tweaking
+("really bad idea" isn't quite up to standardese).
+We would like feedback
+as to whether the original Note's removal was intentional.
+
          
+
          
+Change the phrase "is a really bad idea"
+to "risks undefined behavior" and
+move to Review status.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 17.6.3.10 [res.on.objects] as indicated:
+
          
+
+
          
+
          
+The behavior of a program is undefined if calls to standard library
+functions from different threads may introduce a data race. The
+conditions under which this may occur are specified in 17.6.4.7.
+
          
+
          
+[Note: Thus modifying an object of a standard library type shared between
+threads risks undefined behavior unless objects of the type are explicitly
+specified as being sharable without data races or the user supplies a
+locking mechanism. --end note]
+
          
+
          
+
+
+
+
+
+
          
+
          1096. unconstrained rvalue ref parameters
          
+
          Section: 17 [library] Status: Open
+ Submitter: David Abrahams Opened: 2009-03-21  Last modified: 2009-05-23
          
+
          View other active issues in [library].
          
+
          View all other issues in [library].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+TODO: Look at all cases of unconstrained rvalue ref parameters and check
+that concept req'ts work when T deduced as reference.
+
          
+
+
          
+ We found some instances where that was not done correctly and we figure
+   the possibility of deducing T to be an lvalue reference was probably
+   overlooked elsewhere.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+Move to Open, pending proposed wording from Dave for further review.
+
          
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
+
+
+
          
+
          1097. #define __STDCPP_THREADS
          
+
          Section: 18.2 [support.types] Status: Review
+ Submitter: Jens Maurer Opened: 2009-04-03  Last modified: 2009-05-23
          
+
          View all other issues in [support.types].
          
+
          View all issues with Review status.
          
+
          Discussion:
          
+
          Addresses DE 18
          
+
+
          
+Freestanding implementations do not (necessarily) have
+  support for multiple threads (see 1.10 [intro.multithread]).
+  Applications and libraries may want to optimize for the
+  absence of threads.  I therefore propose a preprocessor
+  macro to indicate whether multiple threads can occur.
+
          
+
+
          
+There is ample prior implementation experience for this
+  feature with various spellings of the macro name.  For
+  example, gcc implicitly defines _REENTRANT
+  if multi-threading support is selected on the compiler
+  command-line.
+
          
+
+
          
+While this is submitted as a library issue, it may be more
+  appropriate to add the macro in 16.8 cpp.predefined in the
+  core language.
+
          
+
+
          
+See also
+N2693.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We agree with the issue, and believe it is properly a library issue.
+
          
+
          
+We prefer that the macro be conditionally defined
+as part of the <thread> header.
+
          
+
          
+Move to Review.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+Insert a new subsection before 18.2 [support.types], entitled
+"Feature Macros" (support.macros):
+
          
+
          
+
          
+The standard library defines the following macros; no explicit
+prior inclusion of any header file is necessary.
+
          
+
          
+
          
+
          __STDCPP_THREADS
          
+
          
+The macro __STDCPP_THREADS shall be defined if and only if a
+    program can have more than one thread of execution (1.10 [intro.multithread]).
+If the macro is defined, it shall have the same
+    value as the predefined macro __cplusplus (16.8 [cpp.predefined]).
+
          
+
          
+
          
+
          
+
+
+
+
+
+
+
          
+
          1098. definition of get_pointer_safety()
          
+
          Section: 20.8.13.7 [util.dynamic.safety] Status: Open
+ Submitter: Jens Maurer Opened: 2009-04-03  Last modified: 2009-05-23
          
+
          View all other issues in [util.dynamic.safety].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          Addresses DE 18
          
+
+
          
+ In 20.8.13.7 [util.dynamic.safety], get_pointer_safety() purports
+to define behavior for
+ non-safely derived pointers (3.7.4.3 [basic.stc.dynamic.safety]).  However,
+ the cited core-language section in paragraph 4 specifies undefined behavior
+ for the use of such pointer values.  This seems an unfortunate near-contradiction.
+ I suggest to specify the term relaxed pointer safety in
+ the core language section and refer to it from the library description.
+ This issue deals with the library part, the corresponding core issue (c++std-core-13940)
+ deals with the core modifications.
+
          
+
+
          
+See also
+N2693.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We recommend if this issue is to be moved,
+the issue be moved concurrently with the cited Core issue.
+
          
+
          
+We agree with the intent of the proposed resolution.
+We would like input from garbage collection specialists.
+
          
+
          
+Move to Open.
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+In 20.8.13.7 [util.dynamic.safety] p16, replace the description of
+get_pointer_safety() with:
+
          
+
+
          
+
          
+pointer_safety get_pointer_safety();
+
          
+
          
+
          
+Returns: an enumeration value indicating the implementation's treatment
+of pointers that are not safely derived (3.7.4.3). Returns
+pointer_safety::relaxed if pointers that are not safely derived will be
+treated the same as pointers that are safely derived for the duration of
+the program. Returns pointer_safety::preferred if pointers that are not
+safely derived will be treated the same as pointers that are safely
+derived for the duration of the program but allows the implementation to
+hint that it could be desirable to avoid dereferencing pointers that are
+not safely derived as described. [Example: pointer_safety::preferred
+might be returned to detect if a leak detector is running to avoid
+spurious leak reports. -- end note] Returns pointer_safety::strict if
+pointers that are not safely derived might be treated differently than
+pointers that are safely derived.
+
          
+
          
+Returns: Returns pointer_safety::strict if the implementation has
+   strict pointer safety (3.7.4.3 [basic.stc.dynamic.safety]). It is
+   implementation-defined whether get_pointer_safety returns
+   pointer_safety::relaxed or pointer_safety::preferred if the
+   implementation has relaxed pointer safety
+   (3.7.4.3 [basic.stc.dynamic.safety]).Footnote
+
          
+
+
          
+Throws: nothing
+
          
+
+
          
+Footnote) pointer_safety::preferred might be returned to indicate to the
+   program that a leak detector is running so that the program can avoid
+   spurious leak reports.
+
+
          
+
+
          
+
          
+
+
+
+
+
+
          
+
          1099. Various issues
          
+
          Section: 17 [library] Status: Open
+ Submitter: David Abrahams Opened: 2009-03-21  Last modified: 2009-05-23
          
+
          View other active issues in [library].
          
+
          View all other issues in [library].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+Notes
+
          
+
          
+
          
+[2009-03-21 Sat] p. 535 at the top we need MoveConstructible V1,
+MoveConstructible V2 (where V1,V2 are defined on 539).  Also make_tuple
+on 550
+
          
+
          
+[2009-03-21 Sat] p1183 thread ctor, and in general, we need a way to
+talk about "copiable from generalized rvalue ref argument" for cases
+where we're going to forward and copy.  
+
          
+
          
+
          
+   This issue may well be quite large.  Language in para 4 about "if
+   an lvalue" is wrong because types aren't expressions.
+
          
+
          
+   p1199, call_once has all the same issues.
+
          
+
          
+
          
+[2009-03-21 Sat] p869 InputIterator pointer type should not be required
+to be convertible to const value_type*, rather it needs to have a
+operator-> of its own that can be used for the value type.
+
          
+
          
+[2009-03-21 Sat] p818 stack has the same problem with default ctor.
+
          
+
          
+[2009-03-21 Sat] p816 priority_queue has the same sorts of problems as queue, only more so
+
          
+
             requires MoveConstructible<Cont> 
+     explicit priority_queue(const Compare& x = Compare(), Cont&& = Cont()); 
+
          
+
          
+   Don't require MoveConstructible when default constructing Cont.
+   Also missing semantics for move ctor.
+
          
+
          
+
          
+ [2009-03-21 Sat] Why are Allocators required to be CopyConstructible as
+ opposed to MoveConstructible?
+
          
+
          
+ [2009-03-21 Sat] p813 queue needs a separate default ctor (Cont needn't
+ be MoveConstructible).  No documented semantics for move c'tor.  Or
+ *any* of its 7 ctors!
+
          
+
          
+ [2009-03-21 Sat] std::array should have constructors for C++0x,
+ consequently must consider move construction.
+
          
+
+
          [
+2009-05-01 Daniel adds:
+]
          
+
+
+
          
+This could be done as part of 1035, which already handles
+deviation of std::array from container tables.
+
          
+
+
          
+ [2009-03-21 Sat] p622 all messed up.
+
          
+
          
+
          
+   para 8 "implementation-defined" is the wrong term; should be "see
+   below" or something.  
+
          
+
          
+   para 12 "will be selected" doesn't make any sense because we're not
+   talking about actual arg types.
+
          
+
          
+   paras 9-13 need to be totally rewritten for concepts.
+
          
+
          
+
+
          
+ [2009-03-21 Sat] Null pointer comparisons (p587) have all become
+ unconstrained.  Need to fix that
+
          
+
          
+ [2009-03-21 Sat] mem_fun_t etc. definition doesn't match declaration.
+  We think CopyConstructible is the right reqt.
+
          
+
          
+ make_pair needs Constructible<V1, T1&&> requirements!
+
          
+
          
+ make_tuple needs something similar
+
          
+
          
+ tuple bug in synopsis:
+
          
+
             template <class... UTypes>
+   requires Constructible<Types, const UTypes&>...
+   template <class... UTypes>
+   requires Constructible<Types, RvalueOf<UTypes>::type>...
+
          
+
          
+   Note: removal of MoveConstructible requirements in std::function makes
+   these routines unconstrained!
+
          
+
          
+
+
          [
+2009-05-02 Daniel adds:
+]
          
+
+
+
          
+This part of the issue is already covered by 1077.
+
          
+
+
          
+ these unique_ptr constructors are broken [ I think this is covered in "p622 all messed up" ]
+
          
+
           unique_ptr(pointer p, implementation-defined d);
+ unique_ptr(pointer p, implementation-defined d);
+
          
+
          
+ multimap range constructor should not have MoveConstructible<value_type> requirement.
+
          
+
          
+   same with insert(..., P&&); multiset has the same issue, as do
+   unordered_multiset and unordered_multimap. Review these!
+
          
+
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+Move to Open, pending proposed wording from Dave for further review.
+
          
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
+
+
+
          
+
          1100. auto_ptr to unique_ptr conversion
          
+
          Section: D.9 [depr.auto.ptr] Status: Tentatively Ready
+ Submitter: Howard Hinnant Opened: 2009-04-25  Last modified: 2009-05-23
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+Message c++std-lib-23182 led to a discussion in which several people
+expressed interest in being able to convert an auto_ptr to a
+unique_ptr without the need to call release.  Below is
+wording to accomplish this.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Pete believes it not a good idea to separate parts of a class's definition.
+Therefore, if we do this,
+it should be part of unique-ptr's specification.
+
          
+
          
+Alisdair believes the lvalue overload may be not necessary.
+
          
+
          
+Marc believes it is more than just sugar,
+as it does ease the transition to unique-ptr.
+
          
+
          
+We agree with the resolution as presented.
+Move to Tentatively Ready.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+Add to D.9 [depr.auto.ptr]:
+
          
+
+
          
+
          
+The following unique_ptr constructors are in addition to those specified
+in 20.8.12.2.1 [unique.ptr.single.ctor].
+
          
+
          template <class T, class D>
+class unique_ptr
+{
+public:
+    template <class U>
+      requires SameType<D, default_delete<T>>
+            && Convertible<U*, T*>
+      unique_ptr(auto_ptr<U>& u);
+    template <class U>
+      requires SameType<D, default_delete<T>>
+            && Convertible<U*, T*>
+      unique_ptr(auto_ptr<U>&& u);
+};
+
          
+
          
+Effects: Constructs a unique_ptr with u.release().
+
          
+
+
          
+Postconditions: get() ==  the value u.get() had before
+the construciton, modulo any required offset adjustments resulting from the cast from
+U* to T*.  u.get() == nullptr.
+
          
+
+
          
+Throws: nothing.
+
          
+
          
+
+
+
+
+
+
+
          
+
          1101. unique requirements
          
+
          Section: 25.4.9 [alg.unique] Status: Tentatively NAD Editorial
+ Submitter: Howard Hinnant Opened: 2009-04-25  Last modified: 2009-05-23
          
+
          View other active issues in [alg.unique].
          
+
          View all other issues in [alg.unique].
          
+
          View all issues with Tentatively NAD Editorial status.
          
+
          Discussion:
          
+
          
+From Message c++std-core-14160 Howard wrote:
+
          
+
+
          
+It was the intent of the rvalue reference proposal for unique to only require MoveAssignable:
+N1860.
+
          
+
+
          
+And Pete replied:
+
          
+
+
          
+That was overridden by the subsequent changes made for concepts in
+N2573,
+which reimposed the C++03 requirements.
+
          
+
+
          
+My impression is that this overwrite was a simple (unintentional) mistake.
+Wording below to correct it.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Howard notes this issue resolves a discrepancy between the synopsis
+and the description.
+
          
+
          
+Move to NAD Editorial.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 25.4.9 [alg.unique]:
+
          
+
+
          template<ForwardIterator Iter> 
+  requires OutputIterator<Iter, RvalueOf<Iter::reference>::type> 
+        && EqualityComparable<Iter::value_type> 
+  Iter unique(Iter first, Iter last); 
+
+template<ForwardIterator Iter, EquivalenceRelation<auto, Iter::value_type> Pred> 
+  requires OutputIterator<Iter, RvalueOf<Iter::reference>::type> 
+        && CopyConstructible<Pred> 
+  Iter unique(Iter first, Iter last, Pred pred);
+
          
+
+
          
+Note that the synopsis in 25.2 [algorithms.syn] is already correct.
+
          
+
+
+
+
+
+
+
          
+
          1102. std::vector's reallocation policy still unclear
          
+
          Section: 23.3.6.2 [vector.capacity] Status: Review
+ Submitter: Daniel Krügler Opened: 2009-04-20  Last modified: 2009-05-23
          
+
          View all other issues in [vector.capacity].
          
+
          View all issues with Review status.
          
+
          Discussion:
          
+
          
+I have the impression that even the wording of current draft
+N2857
+does insufficiently express the intent of vector's
+reallocation strategy. This has produced not too old library
+implementations which release memory in the clear() function
+and even modern articles about C++ programming cultivate
+the belief that clear is allowed to do exactly this. A typical
+example is something like this:
+
          
+
+
          const int buf_size = ...;
+std::vector<T> buf(buf_size);
+for (int i = 0; i < some_condition; ++i) {
+  buf.resize(buf_size);
+  write_or_read_data(buf.data());
+  buf.clear(); // Ensure that the next round get's 'zeroed' elements
+}
+
          
+
          
+where still the myth is ubiquitous that buf might be
+allowed to reallocate it's memory *inside* the for loop.
+
          
+
          
+IMO the problem is due to the fact, that
+
          
+
+
            
+
          1. 
+the actual memory-reallocation stability of std::vector
+is explained in 23.3.6.2 [vector.capacity]/3 and /6 which
+are describing just the effects of the reserve
+function, but in many examples (like above) there
+is no explicit call to reserve involved. Further-more
+23.3.6.2 [vector.capacity]/6 does only mention insertions
+and never mentions the consequences of erasing
+elements.
+
            2. 
+
          2. 
+
            
+the effects clause of std::vector's erase overloads in
+23.3.6.4 [vector.modifiers]/4 is silent about capacity changes. This
+easily causes a misunderstanding, because the counter
+parting insert functions described in 23.3.6.4 [vector.modifiers]/2
+explicitly say, that
+
            
+
            
+Causes reallocation if the new size is greater than the
+old capacity. If no reallocation happens, all the iterators
+and references before the insertion point remain valid.
+
            
+
            
+It requires a complex argumentation chain about four
+different places in the standard to provide the - possibly
+weak - proof that calling clear() also does never change
+the capacity of the std::vector container. Since std::vector
+is the de-facto replacement of C99's dynamic arrays this
+type is near to a built-in type and it's specification should
+be clear enough that usual programmers can trust their
+own reading.
+
            
+
            3. 
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Bill believes paragraph 1 of the proposed resolution is unnecessary
+because it is already implied (even if tortuously) by the current wording.
+
          
+
          
+Move to Review.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          [
+This is a minimum version. I also
+suggest that the wording explaining the allocation strategy
+of std::vector in 23.3.6.2 [vector.capacity]/3 and /6 is moved into
+a separate sub paragraph of 23.3.6.2 [vector.capacity] before
+any of the prototype's are discussed, but I cannot provide
+reasonable wording changes now
+]
          
+
+
+
            
+
          1. 
+
            
+Change 23.3.6.2 [vector.capacity]/6 as follows:
+
            
+
            
+It is guaranteed that no reallocation takes place during
+insertions or erasures that happen after a call
+to reserve() until the time when an insertion would make
+the size of the vector greater than the value of capacity().
+
            
+
            2. 
+
          2. 
+
            
+Change 23.3.6.4 [vector.modifiers]/4 as follows:
+
            
+
            
+Effects: The capacity shall remain unchanged and no reallocation shall
+happen.
+Invalidates iterators and references at or after the point
+of the erase.
+
            
+
            3. 
+
          
+
+
+
+
+
+
          
+
          1103. system_error constructor postcondition overly strict
          
+
          Section: 19.5.5.2 [syserr.syserr.members] Status: Tentatively Ready
+ Submitter: Howard Hinnant Opened: 2009-04-25  Last modified: 2009-05-23
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+19.5.5.2 [syserr.syserr.members] says:
+
          
+
+
          system_error(error_code ec, const string& what_arg);
+
          
+
          
+
          
+Effects: Constructs an object of class system_error.
+
          
+
          
+Postconditions: code() == ec and strcmp(runtime_error::what(), what_arg.c_str()) == 0.
+
          
+
          
+
          
+
+
          
+However the intent is for:
+
          
+
+
          std::system_error se(std::errc::not_a_directory, "In FooBar");
+...
+se.what();  // returns something along the lines of:
+            //   "In FooBar: Not a directory"
+
          
+
+
          
+The way the constructor postconditions are set up now, to achieve both
+conformance, and the desired intent in the what() string, the
+system_error constructor must store "In FooBar" in the base class,
+and then form the desired output each time what() is called.  Or
+alternatively, store "In FooBar" in the base class, and store the desired
+what() string in the derived system_error, and override
+what() to return the string in the derived part.
+
          
+
+
          
+Both of the above implementations seem suboptimal to me.  In one I'm computing
+a new string every time what() is called.  And since what()
+can't propagate exceptions, the client may get a different string on different
+calls.
+
          
+
+
          
+The second solution requires storing two strings instead of one.
+
          
+
+
          
+What I would like to be able to do is form the desired what() string
+once in the system_error constructor, and store that in the
+base class.  Now I'm:
+
          
+
+
            
+
          1. Computing the desired what() only once.
            2. 
+
          2. The base class what() definition is sufficient and nothrow.
            3. 
+
          3. I'm not storing multiple strings.
            4. 
+
          
+
+
          
+This is smaller code, smaller data, and faster.
+
          
+
+
          
+ios_base::failure has the same issue.
+
          
+
+
          [
+Comments about this change received favorable comments from the system_error
+designers.
+]
          
+
+
+
          [
+Batavia (2009-05):
+]
          
+
+
+
          
+
          
+We agree with the proposed resolution.
+
          
+
          
+Move to Tentatively Ready.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+In 19.5.5.2 [syserr.syserr.members], change the following constructor postconditions:
+
          
+
+
          
+
          system_error(error_code ec, const string& what_arg);
+
          
+
          
+-2- Postconditions: code() == ec
+and strcmp(runtime_error::what(), what_arg.c_str()) == 0
+string(what()).find(what_arg) != string::npos.
+
          
+
+
          system_error(error_code ec, const char* what_arg);
+
          
+
          
+-4- Postconditions: code() == ec
+and strcmp(runtime_error::what(), what_arg) == 0
+string(what()).find(what_arg) != string::npos.
+
          
+
+
          system_error(error_code ec);
+
          
+
          
+-6- Postconditions: code() == ec
+and strcmp(runtime_error::what(), "".
+
          
+
+
          system_error(int ev, const error_category& ecat, const string& what_arg);
+
          
+
          
+-8- Postconditions: code() == error_code(ev, ecat)
+and strcmp(runtime_error::what(), what_arg.c_str()) == 0
+string(what()).find(what_arg) != string::npos.
+
          
+
+
          system_error(int ev, const error_category& ecat, const char* what_arg);
+
          
+
          
+-10- Postconditions: code() == error_code(ev, ecat)
+and strcmp(runtime_error::what(), what_arg) == 0
+string(what()).find(what_arg) != string::npos.
+
          
+
+
          system_error(int ev, const error_category& ecat);
+
          
+
          
+-12- Postconditions: code() == error_code(ev, ecat)
+and strcmp(runtime_error::what(), "") == 0.
+
          
+
+
          
+
+
          
+In 19.5.5.2 [syserr.syserr.members], change the description of what():
+
          
+
+
          
+
          const char *what() const throw();
+
          
+
          
+
          
+-14- Returns: An NTBS incorporating runtime_error::what() and
+code().message() the arguments supplied in the constructor.
+
          
+
          
+[Note: One possible implementation would be:
+The return NTBS might take the form: what_arg + ": " + code().message()
+
          
+
          
+if (msg.empty()) { 
+  try { 
+    string tmp = runtime_error::what(); 
+    if (code()) { 
+      if (!tmp.empty()) 
+        tmp += ": "; 
+      tmp += code().message(); 
+    } 
+    swap(msg, tmp); 
+  } catch(...) { 
+    return runtime_error::what(); 
+  } 
+return msg.c_str();
+
          
+
          
+— end note]
+
          
+
          
+
          
+
+
          
+In 27.5.2.1.1 [ios::failure], change the synopsis:
+
          
+
+
          namespace std { 
+  class ios_base::failure : public system_error { 
+  public: 
+    explicit failure(const string& msg, const error_code& ec = io_errc::stream); 
+    explicit failure(const char* msg, const error_code& ec = io_errc::stream); 
+    virtual const char* what() const throw();
+  }; 
+}
+
          
+
+
          
+In 27.5.2.1.1 [ios::failure], change the description of the constructors:
+
          
+
+
          
+
+
          explicit failure(const string& msg, , const error_code& ec = io_errc::stream);
+
          
+
          
+
          
+-3- Effects: Constructs an object of class failure
+by constructing the base class with msg and ec.
+
          
+
          
+-4- Postcondition: code() == ec and strcmp(what(), msg.c_str()) == 0
+
          
+
          
+
+
          explicit failure(const char* msg, const error_code& ec = io_errc::stream);
+
          
+
          
+
          
+-5- Effects: Constructs an object of class failure
+by constructing the base class with msg and ec.
+
          
+
          
+-6- Postcondition: code() == ec and strcmp(what(), msg) == 0
+
          
+
          
+
+
          
+
+
          
+In 27.5.2.1.1 [ios::failure], remove what (the base class definition
+need not be repeated here).
+
          
+
+
          
+
          const char* what() const;
+
          
+
          
+-7- Returns: The message msg with which the exception was created.
+
          
+
+
          
+
+
+
+
+
+
+
          
+
          1104. basic_ios::move should accept lvalues
          
+
          Section: 27.5.4.2 [basic.ios.members] Status: Review
+ Submitter: Howard Hinnant Opened: 2009-04-25  Last modified: 2009-05-23
          
+
          View other active issues in [basic.ios.members].
          
+
          View all other issues in [basic.ios.members].
          
+
          View all issues with Review status.
          
+
          Discussion:
          
+
          
+With the rvalue reference changes in
+N2844
+basic_ios::move no longer has the most convenient signature:
+
          
+
+
          void move(basic_ios&& rhs);
+
          
+
+
          
+This signature should be changed to accept lvalues.  It does not need to be
+overloaded to accept rvalues.  This is a special case that only derived clients
+will see.  The generic move still needs to accept rvalues.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Tom prefers, on general principles, to provide both overloads.
+Alisdair agrees.
+
          
+
          
+Howard points out that there is no backward compatibility issue
+as this is new to C++0X.
+
          
+
          
+We agree that both overloads should be provided,
+and Howard will provide the additional wording.
+Move to Open.
+
          
+
          
+
+
          [
+2009-05-23 Howard adds:
+]
          
+
+
+
          
+Added overload, moved to Review.
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+Add a signature to the existing prototype in the synopsis of 27.5.4 [ios]
+and in 27.5.4.2 [basic.ios.members]:
+
          
+
+
          void move(basic_ios& rhs);
+void move(basic_ios&& rhs);
+
          
+
+
+
+
+
+
          
+
          1105. Shouldn't Range be an auto concept
          
+
          Section: 24.2.8 [iterator.concepts.range] Status: Open
+ Submitter: David Abrahams Opened: 2009-04-23  Last modified: 2009-05-23
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          [
+2009-04-26 Herb adds:
+]
          
+
+
+
          
+
          
+Here's a common example: We have many ISV customers who have built lots of
+in-house STL-like containers. Imagine that, for the past ten years, the user
+has been happily using his XYZCorpContainer<T> that has begin() and end()
+and an iterator typedef, and indeed satisfies nearly all of Container,
+though maybe not quite all just like valarray. The user upgrades to a
+range-enabled version of a library, and now lib_algo( xyz.begin(), xyz.end());
+no longer works -- compiler error.
+
          
+
          
+Even though XYZCorpContainer matches the pre-conceptized version of the
+algorithm, and has been working for years, it appears the user has to write
+at least this:
+
          
+
          template<class T> concept_map Range<XYZCorpContainer<T>> {};
+
+template<class T> concept_map Range<const XYZCorpContainer<T>> {};
+
          
+
          
+Is that correct?
+
          
+
          
+But he may actually have to write this as we do for initializer list:
+
          
+
          template<class T>
+concept_map Range<XYZCorpContainer<T>> {
+   typedef T* iterator;
+   iterator begin(XYZCorpContainer<T> c) { return c.begin(); }
+   iterator end(XYZCorpContainer<T> c) { return c.end(); }
+};
+
+template<class T>
+concept_map Range<const XYZCorpContainer<T>> {
+   typedef T* iterator;
+   iterator begin(XYZCorpContainer<T> c) { return c.begin(); }
+   iterator end(XYZCorpContainer<T> c) { return c.end(); }
+};
+
          
+
+
          
+
+
          [
+2009-04-28 Alisdair adds:
+]
          
+
+
+
          
+
          
+I recommend NAD, although remain concerned about header organisation.
+
          
+
          
+A user container will satisfy the MemberContainer concept, which IS auto.
+There is a concept_map for all MemberContainers to Container, and then a
+further concept_map for all Container to Range, so the stated problem is not
+actually true.  User defined containers will automatically match the Range
+concept without explicitly declaring a concept_map.
+
          
+
          
+The problem is that they should now provide an additional two headers,
+<iterator_concepts> and <container_concepts>.
+ The only difference from
+making Range an auto concept would be this reduces to a single header,
+<iterator_concepts>.
+
          
+
          
+I am strongly in favour of any resolution that tackles the issue of
+explicitly requiring concept headers to make these concept maps available.
+
          
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We observe there is a recent paper by Bjarne that overlaps this issue.
+
          
+
          
+Alisdair continues to recommend NAD.
+
          
+
          
+Move to Open, and recommend the issue be deferred until after the next
+Committee Draft is issued.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1106. Multiple exceptions from connected shared_future::get()?
          
+
          Section: 30.6.5 [future.shared_future] Status: Open
+ Submitter: Thomas J. Gritzan Opened: 2009-04-03  Last modified: 2009-05-23
          
+
          View other active issues in [future.shared_future].
          
+
          View all other issues in [future.shared_future].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+It is not clear, if multiple threads are waiting in a 
+shared_future::get() call, if each will rethrow the stored exception.
+
          
+
          
+Paragraph 9 reads: 
+
          
+
          
+Throws: the stored exception, if an exception was stored and not 
+retrieved before.
+
          
+
          
+The "not retrieved before" suggests that only one exception is thrown, 
+but one exception for each call to get() is needed, and multiple calls 
+to get() even on the same shared_future object seem to be allowed. 
+
          
+
          
+I suggest removing "and not retrieved before" from the Throws paragraph. 
+I recommend adding a note that explains that multiple calls on get() are 
+allowed, and each call would result in an exception if an exception was 
+stored. 
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We note there is a pending paper by Detlef
+on such future-related issues;
+we would like to wait for his paper before proceeding.
+
          
+
          
+Alisdair suggests we may want language to clarify that this
+get() function can be called from several threads
+with no need for explicit locking.
+
          
+
          
+Move to Open.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 30.6.5 [future.shared_future]:
+
          
+
+
          const R& shared_future::get() const; 
+R& shared_future<R&>::get() const; 
+void shared_future<void>::get() const;
+
          
+
          
+
          ...
          
+
          
+-9- Throws: the stored exception, if an exception was stored and not retrieved before.
+
+[Note: Multiple calls on get() are 
+allowed, and each call would result in an exception if an exception was 
+stored. — end note]
+
+
          
+
          
+
          
+
+
+
+
+
+
+
          
+
          1107. constructor shared_future(unique_future) by value?
          
+
          Section: 30.6.5 [future.shared_future] Status: Tentatively Ready
+ Submitter: Thomas J. Gritzan Opened: 2009-04-03  Last modified: 2009-05-23
          
+
          View other active issues in [future.shared_future].
          
+
          View all other issues in [future.shared_future].
          
+
          View all issues with Tentatively Ready status.
          
+
          Discussion:
          
+
          
+In the shared_future class definition in 30.6.5 [future.shared_future]
+the move constructor 
+that constructs a shared_future from an unique_future receives the 
+parameter by value. In paragraph 3, the same constructor receives it as 
+const value. 
+
          
+
+
          
+I think that is a mistake and the constructor should take a r-value 
+reference: 
+
          
+
+
          shared_future(unique_future<R>&& rhs);
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We agree with the proposed resolution.
+
          
+
          
+Move to Tentatively Ready.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change the synopsis in 30.6.5 [future.shared_future]:
+
          
+
+
          shared_future(unique_future<R>&& rhs);
+
          
+
+
          
+Change the definition of the constructor in 30.6.5 [future.shared_future]:
+
          
+
+
          shared_future(const unique_future<R>&& rhs);
+
          
+
+
+
+
+
+
+
          
+
          1108. thread.req.exception overly constrains implementations
          
+
          Section: 30.2.2 [thread.req.exception] Status: Open
+ Submitter: Christopher Kohlhoff Opened: 2009-04-25  Last modified: 2009-05-23
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+The current formulation of 30.2.2 [thread.req.exception]/2 reads:
+
          
+
          
+The error_category of the error_code reported by such an
+exception's code() member function is as specified in the error
+condition Clause.
+
          
+
          
+This constraint on the code's associated error_categor means an
+implementation must perform a mapping from the system-generated
+error to a generic_category() error code. The problems with this
+include:
+
          
+
+
            
+
          • 
+The mapping is always performed, even if the resultant value is
+ never used.
+
            • 
+
          • 
+
            
+The original error produced by the operating system is lost.
+
            
+
            • 
+
          
+
          
+The latter was one of Peter Dimov's main objections (in a private
+email discussion) to the original error_code-only design, and led to
+the creation of error_condition in the first place. Specifically,
+error_code and error_condition are intended to perform the following
+roles:
+
          
+
            
+
          • 
+error_code holds the original error produced by the operating
+ system.
+
            • 
+
          • 
+error_condition and the generic category provide a set of well
+ known error constants that error codes may be tested against.
+
            • 
+
          
+
          
+Any mapping determining correspondence of the returned error code to
+the conditions listed in the error condition clause falls under the
+"latitude" granted to implementors in 19.5.1.5 [syserr.errcat.objects].
+(Although obviously their latitude is restricted a little by the
+need to match the right error condition when returning an error code
+from a library function.)
+
          
+
          
+It is important that this error_code/error_condition usage is done
+correctly for the thread library since it is likely to set the
+pattern for future TR libraries that interact with the operating
+system.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+Move to Open, and recommend the issue be deferred until after the next
+Committee Draft is issued.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 30.2.2 [thread.req.exception]/2:
+
          
+
+
          
+
          
+-2- The error_category (19.5.1.1) of the error_code reported by
+such an exception's code() member function 
+is as specified in the error condition Clause.
+
+The error_code reported by such an exception's code() member
+function shall compare equal to one of the conditions specified in
+the function's error condition Clause. [Example: When the thread
+constructor fails:
+
+
          
+
          
+ec.category() == implementation-defined // probably system_category
+ec == errc::resource_unavailable_try_again // holds true
+
          
+
+
          
+— end example]
+
          
+
+
          
+
+
+
+
+
+
+
          
+
          1109. std::includes should require CopyConstructible predicate
          
+
          Section: 25.5.5.1 [includes] Status: Tentatively NAD Editorial
+ Submitter: Alisdair Meredith Opened: 2009-04-28  Last modified: 2009-05-23
          
+
          View other active issues in [includes].
          
+
          View all other issues in [includes].
          
+
          View all issues with Tentatively NAD Editorial status.
          
+
          Discussion:
          
+
          
+All the set operation algorithms require a CopyConstructible predicate, with
+the exception of std::includes.  This looks like a typo as much as anything,
+given the general library requirement that predicates are copy
+constructible, and wording style of other set-like operations.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+We agree with the proposed resolution.
+Move to NAD Editorial.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 25.2 [algorithms.syn] and 25.5.5.1 [includes]:
+
          
+
+
          template<InputIterator Iter1, InputIterator Iter2,
+         typename CopyConstructible Compare>
+  requires Predicate<Compare, Iter1::value_type, Iter2::value_type>
+        && Predicate<Compare, Iter2::value_type, Iter1::value_type>
+  bool includes(Iter1 first1, Iter1 last1,
+                Iter2 first2, Iter2 last2,
+                Compare comp);
+
          
+
+
+
+
+
+
          
+
          1110. Is for_each overconstrained?
          
+
          Section: 25.3.4 [alg.foreach] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-04-29  Last modified: 2009-05-23
          
+
          View other active issues in [alg.foreach].
          
+
          View all other issues in [alg.foreach].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+Quoting working paper for reference (25.3.4 [alg.foreach]):
+
          
+
+
          
+
          template<InputIterator Iter, Callable<auto, Iter::reference> Function>
+  requires CopyConstructible<Function>
+  Function for_each(Iter first, Iter last, Function f);
+
          
+
          
+
          
+1 Effects: Applies f to the result of dereferencing every iterator in the
+ range [first,last), starting from first and proceeding to last - 1.
+
          
+
          
+2 Returns: f.
+
          
+
          
+3 Complexity: Applies f exactly last - first times.
+
          
+
          
+
          
+
+
          
+P2 implies the passed object f should be invoked at each stage, rather than
+some copy of f.  This is important if the return value is to usefully
+accumulate changes.  So the requirements are an object of type Function can
+be passed-by-value, invoked multiple times, and then return by value.  In
+this case, MoveConstructible is sufficient. This would open support for
+move-only functors, which might become important in concurrent code as you
+can assume there are no other references (copies) of a move-only type and so
+freely use them concurrently without additional locks.
+
          
+
+
          [
+See further discussion starting with c++std-lib-23686.
+]
          
+
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Pete suggests we may want to look at this in a broader context
+involving other algorithms.
+We should also consider the implications of parallelism.
+
          
+
          
+Move to Open, and recommend the issue be deferred until after the next
+Committee Draft is issued.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 25.2 [algorithms.syn] and 25.3.4 [alg.foreach]:
+
          
+
+
          template<InputIterator Iter, Callable<auto, Iter::reference> Function>
+  requires CopyConstructible MoveConstructible<Function>
+  Function for_each(Iter first, Iter last, Function f);
+
          
+
+
+
+
+
+
          
+
          1111. associative containers underconstrained
          
+
          Section: 23.4 [associative] Status: Review
+ Submitter: Alisdair Meredith Opened: 2009-04-29  Last modified: 2009-05-23
          
+
          View other active issues in [associative].
          
+
          View all other issues in [associative].
          
+
          View all issues with Review status.
          
+
          Discussion:
          
+
          
+According to table 87 (n2857) the expression X::key_equal for an unordered
+container shall return a value of type Pred, where Pred is an equivalence
+relation.
+
          
+
+
          
+However, all 4 containers constrain Pred to be merely a Predicate,
+and not EquivalenceRelation.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+We agree with the proposed resolution.
+
          
+
          
+Move to Review.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+For ordered containers, replace 
+
          
+
          Predicate<auto, Key, Key> Compare = less<Key>
+
          
+
          
+with 
+
          
+
          StrictWeakOrder<auto, Key, Key> Compare = less<Key>
+
          
+
+
          
+For unordered containers, replace 
+
          
+
          Predicate<auto, Key, Key> Compare = less<Key>
+
          
+
          
+with 
+
          
+
          EquivalenceRelation<auto, Key, Key> Compare = less<Key>
+
          
+
          
+As in the following declarations:
+
          
+
+
          
+
          
+Associative containers 23.4 [associative]
+
          
+
          
+ 1 Headers <map> and <set>:
+
          
+
          
+   Header <map> synopsis
+
          
+
             namespace std {
+     template <ValueType Key, ValueType T,
+               PredicateStrictWeakOrder<auto, Key, Key> Compare = less<Key>,
+               Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
+       requires NothrowDestructible<Key> && NothrowDestructible<T>
+             && CopyConstructible<Compare>
+             && AllocatableElement<Alloc, Compare, const Compare&>
+             && AllocatableElement<Alloc, Compare, Compare&&>
+     class map;
+
+     ...
+
+     template <ValueType Key, ValueType T,
+               PredicateStrictWeakOrder<auto, Key, Key> Compare = less<Key>,
+               Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
+       requires NothrowDestructible<Key> && NothrowDestructible<T>
+             && CopyConstructible<Compare>
+             && AllocatableElement<Alloc, Compare, const Compare&>
+             && AllocatableElement<Alloc, Compare, Compare&&>
+     class multimap;
+
+     ...
+
+   }
+
          
+
+
          
+   Header <set> synopsis
+
          
+
             namespace std {
+     template <ValueType Key, PredicateStrictWeakOrder<auto, Key, Key> Compare = less<Key>,
+               Allocator Alloc = allocator<Key> >
+       requires NothrowDestructible<Key> && CopyConstructible<Compare>
+             && AllocatableElement<Alloc, Compare, const Compare&>
+             && AllocatableElement<Alloc, Compare, Compare&&>
+     class set;
+
+     ...
+
+     template <ValueType Key, PredicateStrictWeakOrder<auto, Key, Key> Compare = less<Key>,
+               Allocator Alloc = allocator<Key> >
+       requires NothrowDestructible<Key> && CopyConstructible<Compare>
+             && AllocatableElement<Alloc, Compare, const Compare&>
+             && AllocatableElement<Alloc, Compare, Compare&&>
+     class multiset;
+
+     ...
+
+   }
+
          
+
+
          
+ 23.4.1p2 Class template map [map]
+
          
+
           namespace std {
+   template <ValueType Key, ValueType T,
+             PredicateStrictWeakOrder<auto, Key, Key> Compare = less<Key>,
+             Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
+     requires NothrowDestructible<Key> && NothrowDestructible<T>
+           && CopyConstructible<Compare>
+           && AllocatableElement<Alloc, Compare, const Compare&>
+           && AllocatableElement<Alloc, Compare, Compare&&>
+   class map {
+     ...
+   };
+ }
+
          
+
+
+
          
+ 23.4.2p2 Class template multimap [multimap]
+
          
+
           namespace std {
+   template <ValueType Key, ValueType T,
+             PredicateStrictWeakOrder<auto, Key, Key> Compare = less<Key>,
+             Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
+     requires NothrowDestructible<Key> && NothrowDestructible<T>
+           && CopyConstructible<Compare>
+           && AllocatableElement<Alloc, Compare, const Compare&>
+           && AllocatableElement<Alloc, Compare, Compare&&>
+   class multimap {
+     ...
+   };
+ }
+
          
+
+
+
          
+ 23.4.3p2 Class template set [set]
+
          
+
           namespace std {
+   template <ValueType Key, PredicateStrictWeakOrder<auto, Key, Key> Compare = less<Key>,
+             Allocator Alloc = allocator<Key> >
+     requires NothrowDestructible<Key> && CopyConstructible<Compare>
+           && AllocatableElement<Alloc, Compare, const Compare&>
+           && AllocatableElement<Alloc, Compare, Compare&&>
+   class set {
+     ...
+   };
+ }
+
          
+
+
+
          
+ 23.4.4p2 Class template multiset [multiset]
+
          
+
           namespace std {
+   template <ValueType Key, PredicateStrictWeakOrder<auto, Key, Key> Compare = less<Key>,
+             Allocator Alloc = allocator<Key> >
+     requires NothrowDestructible<Key> && CopyConstructible<Compare>
+           && AllocatableElement<Alloc, Compare, const Compare&>
+           && AllocatableElement<Alloc, Compare, Compare&&>
+   class multiset {
+     ...
+   };
+ }
+
          
+
+
          
+ 23.5 Unordered associative containers [unord]
+
          
+
          
+ 1 Headers <unordered_map> and <unordered_set>:
+
          
+
          
+ Header <unordered_map> synopsis
+
          
+
           namespace std {
+   // 23.5.1, class template unordered_map:
+   template <ValueType Key,
+             ValueType T,
+             Callable<auto, const Key&> Hash = hash<Key>,
+             PredicateEquivalenceRelation<auto, Key, Key> Pred = equal_to<Key>,
+             Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
+     requires NothrowDestructible<Key> && NothrowDestructible<T>
+           && SameType<Hash::result_type, size_t>
+           && CopyConstructible<Hash> && CopyConstructible<Pred>
+           && AllocatableElement<Alloc, Pred, const Pred&>
+           && AllocatableElement<Alloc, Pred, Pred&&>
+           && AllocatableElement<Alloc, Hash, const Hash&>
+           && AllocatableElement<Alloc, Hash, Hash&&>
+     class unordered_map;
+
+   // 23.5.2, class template unordered_multimap:
+   template <ValueType Key,
+             ValueType T,
+             Callable<auto, const Key&> Hash = hash<Key>,
+             PredicateEquivalenceRelation<auto, Key, Key> Pred = equal_to<Key>,
+             Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
+     requires NothrowDestructible<Key> && NothrowDestructible<T>
+           && SameType<Hash::result_type, size_t>
+           && CopyConstructible<Hash> && CopyConstructible<Pred>
+           && AllocatableElement<Alloc, Pred, const Pred&>
+           && AllocatableElement<Alloc, Pred, Pred&&>
+           && AllocatableElement<Alloc, Hash, const Hash&>
+           && AllocatableElement<Alloc, Hash, Hash&&>
+     class unordered_multimap;
+
+   ...
+ }
+
          
+
+
          
+ Header <unordered_set> synopsis
+
          
+
           namespace std {
+   // 23.5.3, class template unordered_set:
+   template <ValueType Value,
+             Callable<auto, const Value&> Hash = hash<Value>,
+             PredicateEquivalenceRelation<auto, Value, Value> class Pred = equal_to<Value>,
+             Allocator Alloc = allocator<Value> >
+     requires NothrowDestructible<Value>
+           && SameType<Hash::result_type, size_t>
+           && CopyConstructible<Hash> && CopyConstructible<Pred>
+           && AllocatableElement<Alloc, Pred, const Pred&>
+           && AllocatableElement<Alloc, Pred, Pred&&>
+           && AllocatableElement<Alloc, Hash, const Hash&>
+           && AllocatableElement<Alloc, Hash, Hash&&>
+     class unordered_set;
+
+   // 23.5.4, class template unordered_multiset:
+   template <ValueType Value,
+             Callable<auto, const Value&> Hash = hash<Value>,
+             PredicateEquivalenceRelation<auto, Value, Value> class Pred = equal_to<Value>,
+             Allocator Alloc = allocator<Value> >
+     requires NothrowDestructible<Value>
+           && SameType<Hash::result_type, size_t>
+           && CopyConstructible<Hash> && CopyConstructible<Pred>
+           && AllocatableElement<Alloc, Pred, const Pred&>
+           && AllocatableElement<Alloc, Pred, Pred&&>
+           && AllocatableElement<Alloc, Hash, const Hash&>
+           && AllocatableElement<Alloc, Hash, Hash&&>
+     class unordered_multiset;
+
+   ...
+ }
+
          
+
+
          
+ 23.5.1p3 Class template unordered_map [unord.map]
+
          
+
           namespace std {
+   template <ValueType Key,
+             ValueType T,
+             Callable<auto, const Key&> Hash = hash<Key>,
+             PredicateEquivalenceRelation<auto, Key, Key> Pred = equal_to<Key>,
+             Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
+     requires NothrowDestructible<Key> && NothrowDestructible<T>
+           && SameType<Hash::result_type, size_t>
+           && CopyConstructible<Hash> && CopyConstructible<Pred>
+           && AllocatableElement<Alloc, Pred, const Pred&>
+           && AllocatableElement<Alloc, Pred, Pred&&>
+           && AllocatableElement<Alloc, Hash, const Hash&>
+           && AllocatableElement<Alloc, Hash, Hash&&>
+   class unordered_map
+   {
+     ...
+   };
+ }
+
          
+
+
          
+ 23.5.2p3 Class template unordered_multimap [unord.multimap]
+
          
+
           namespace std {
+   template <ValueType Key,
+             ValueType T,
+             Callable<auto, const Key&> Hash = hash<Key>,
+             PredicateEquivalenceRelation<auto, Key, Key> Pred = equal_to<Key>,
+             Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
+     requires NothrowDestructible<Key> && NothrowDestructible<T>
+           && SameType<Hash::result_type, size_t>
+           && CopyConstructible<Hash> && CopyConstructible<Pred>
+           && AllocatableElement<Alloc, Pred, const Pred&>
+           && AllocatableElement<Alloc, Pred, Pred&&>
+           && AllocatableElement<Alloc, Hash, const Hash&>
+           && AllocatableElement<Alloc, Hash, Hash&&>
+   class unordered_multimap
+   {
+     ...
+   };
+ }
+
          
+
+
          
+ 23.5.3p3 Class template unordered_set [unord.set]
+
          
+
           namespace std {
+   template <ValueType Value,
+             Callable<auto, const Value&> Hash = hash<Value>,
+             PredicateEquivalenceRelation<auto, Value, Value> class Pred = equal_to<Value>,
+             Allocator Alloc = allocator<Value> >
+     requires NothrowDestructible<Value>
+           && SameType<Hash::result_type, size_t>
+           && CopyConstructible<Hash> && CopyConstructible<Pred>
+           && AllocatableElement<Alloc, Pred, const Pred&>
+           && AllocatableElement<Alloc, Pred, Pred&&>
+           && AllocatableElement<Alloc, Hash, const Hash&>
+           && AllocatableElement<Alloc, Hash, Hash&&>
+   class unordered_set
+   {
+     ...
+   };
+ }
+
          
+
          
+ 23.5.4p3 Class template unordered_multiset [unord.multiset]
+
          
+
           namespace std {
+   template <ValueType Value,
+             Callable<auto, const Value&> Hash = hash<Value>,
+             PredicateEquivalenceRelation<auto, Value, Value> class Pred = equal_to<Value>,
+             Allocator Alloc = allocator<Value> >
+     requires NothrowDestructible<Value>
+           && SameType<Hash::result_type, size_t>
+           && CopyConstructible<Hash> && CopyConstructible<Pred>
+           && AllocatableElement<Alloc, Pred, const Pred&>
+           && AllocatableElement<Alloc, Pred, Pred&&>
+           && AllocatableElement<Alloc, Hash, const Hash&>
+           && AllocatableElement<Alloc, Hash, Hash&&>
+   class unordered_multiset
+   {
+     ...
+   };
+ }
+
          
+
+
          
+
+
+
+
+
+
+
          
+
          1112. bitsets and new style for loop
          
+
          Section: 20.3.6 [template.bitset] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-05-06  Last modified: 2009-05-25
          
+
          View other active issues in [template.bitset].
          
+
          View all other issues in [template.bitset].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+Std::bitset is a homogeneous container-like sequence of bits, yet it does
+not model the Range concept so cannot be used with the new for-loop syntax.
+It is the only such type in the library that does NOT support the new for
+loop.
+
          
+
          
+The obvious reason is that bitset does not support iterators.
+
          
+
          
+At least two reasonable solutions are available:
+
          
+
            
+
          1. 
+Add an iterator interface to bitset, bringing its interface close to that
+of std::array
+
            2. 
+
          2. 
+Provide an unspecified concept_map for Range<bitset>.
+
            3. 
+
          
+
          
+The latter will still need some kind of iterator-like adapter for bitset,
+but gives implementers greater freedom on the details. E.g. begin/end return
+some type that simply invokes operator[] on the object it wraps, and
+increments its index on operator++.  A vendor can settle for InputIterator
+support, rather than wrapping up a full RandomAccessIterator.
+
          
+
          
+I have a mild preference for option (ii) as I think it is less work to
+specify at this stage of the process, although (i) is probably more useful
+in the long run.
+
          
+
          
+Hmm, my wording looks a little woolly, as it does not say what the element
+type of the range is.  Do I get a range of bool, bitset<N>::reference, or
+something else entirely?
+
          
+
          
+I guess most users will assume the behaviour of reference, but expect to
+work with bool.  Bool is OK for read-only traversal, but you really need to
+take a reference to a bitset::reference if you want to write back.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+Move to Open.
+We further recommend this be deferred until after the next Committee Draft.
+
          
+
+
          [
+2009-05-25 Alisdair adds:
+]
          
+
+
+
          
+
          
+I just stumbled over the Range concept_map for valarray and this should
+probably set the precedent on how to write the wording.
+
          
+
+
          [
+Howard: I've replaced the proposed wording with Alisdair's suggestion.
+]
          
+
+
+
          
+
+
+
+
          Proposed resolution:
          
+
+
          
+20.3.6.X bitset concept maps [bitset.concepts] (made up clause name/number)
+
          
+
          template<size_t N>
+concept_map Range<bitset<N>> {
+  typedef unspecified iterator;
+  iterator begin(bitset<N>& a);
+  iterator end(bitset<N>& a);
+}
+
+template<typename T>
+concept_map Range<const bitset<N>> {
+  typedef unspecified iterator;
+  iterator begin(const bitset<N>& a);
+  iterator end(const bitset<N>& a);
+}
+
          
+
          
+-1- Note: these concept_maps adapt bitset to the Range concept.
+
          
+
+
          typedef unspecified iterator;
+
          
+
+
          
+-2- Requires: iterator shall meet the requirements of the
+RandomAccessIterator concept and iterator::reference
+shall equal bitset<N>::reference or const bitset<N>::reference.
+
          
+
+
          iterator begin(bitset<N>& a);
+iterator begin(const bitset<N>& a);
+
          
+
+
          
+-3- Returns: an iterator referencing the first bit in the bitset.
+
          
+
+
          iterator end(bitset<N>& a);
+iterator end(const bitset<N>& a);
+
          
+
+
          
+-4- Returns: an iterator referencing one past the last bit in the bitset.
+
          
+
+
+
+
+
+
+
+
+
+
+
          
+
          1113. bitset::to_string could be simplified
          
+
          Section: 20.3.6 [template.bitset] Status: Open
+ Submitter: Alisdair Meredith Opened: 2009-05-09  Last modified: 2009-05-23
          
+
          View other active issues in [template.bitset].
          
+
          View all other issues in [template.bitset].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
          
+In 853 our resolution is changing the signature by adding two
+defaulting arguments to 3 calls.  In principle, this means that ABI breakage
+is not an issue, while API is preserved.
+
          
+
          
+With that observation, it would be very nice to use the new ability to
+supply default template parameters to function templates to collapse all 3
+signatures into 1.  In that spirit, this issue offers an alternative resolution
+than that of 853.
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+Move to Open,
+and look at the issue again after 853 has been accepted.
+We further recommend this be deferred until after the next Committee Draft.
+
          
+
+
+
          Proposed resolution:
          
+
+
            
+
          1. 
+
            
+In 20.3.6 [template.bitset]/1 (class bitset) ammend:
+
            
+
            template <class charT = char,
+            class traits = char_traits<charT>,
+            class Allocator = allocator<charT>> 
+  basic_string<charT, traits, Allocator>
+  to_string(charT zero = charT('0'), charT one = charT('1')) const;
+template <class charT, class traits> 
+  basic_string<charT, traits, allocator<charT> > to_string() const; 
+template <class charT> 
+  basic_string<charT, char_traits<charT>, allocator<charT> > to_string() const; 
+basic_string<char, char_traits<char>, allocator<char> > to_string() const;
+
            
+
            2. 
+
          2. 
+
            
+In 20.3.6.2 [bitset.members] prior to p35 ammend:
+
            
+
            template <class charT = char,
+            class traits = char_traits<charT>,
+            class Allocator = allocator<charT>> 
+  basic_string<charT, traits, Allocator>
+  to_string(charT zero = charT('0'), charT one = charT('1')) const;
+
            
+
            3. 
+
          3. 
+Strike 20.3.6.2 [bitset.members] paragraphs 37 -> 39 (including signature
+above 37)
+
            4. 
+
          
+
+
+
+
+
+
+
          
+
          1114. Type traits underspecified
          
+
          Section: 20.6 [meta] Status: Open
+ Submitter: Daniel Krügler Opened: 2009-05-12  Last modified: 2009-05-23
          
+
          View other active issues in [meta].
          
+
          View all other issues in [meta].
          
+
          View all issues with Open status.
          
+
          Discussion:
          
+
+
          
+Related to 975 and 1023.
+
          
+
+
          
+The current wording in 20.6.1 [meta.rqmts] is still unclear concerning
+it's requirements on the type traits classes regarding ambiguities.
+Specifically it's unclear
+
          
+
+
            
+
          • 
+if a predicate trait (20.6.4 [meta.unary], 20.6.5 [meta.rel]) could derive from both
+true_type/false_type.
+
            • 
+
          • 
+if any of the type traits (20.6.1 [meta.rqmts], 20.6.4 [meta.unary], 20.6.5 [meta.rel]) could ambiguously derive
+from the same specified result type.
+
            • 
+
          • 
+if any of the type traits (20.6.1 [meta.rqmts], 20.6.4 [meta.unary], 20.6.5 [meta.rel]) could derive from other
+integral_constant types making the contained names ambiguous
+
            • 
+
          • 
+if any of the type traits (20.6.1 [meta.rqmts], 20.6.4 [meta.unary], 20.6.5 [meta.rel]) could have other base
+classes that contain members hiding the name of the result type members
+or make the contained member names ambiguous.
+
            • 
+
          
+
+
          [
+Batavia (2009-05):
+]
          
+
+
          
+
          
+Alisdair would prefer to factor some of the repeated text,
+but modulo a corner case or two,
+he believes the proposed wording is otherwise substantially correct.
+
          
+
          
+Move to Open.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          [
+The usage of the notion of a BaseCharacteristic below
+might be
+useful in other places - e.g. to define the base class relation in
+20.7.5 [refwrap], 20.7.15 [func.memfn], or 20.7.16.2 [func.wrap.func].
+In this case it's definition should probably
+be moved to Clause 17
+]
          
+
+
+
            
+
          1. 
+
            
+Change 20.6.1 [meta.rqmts]/1 as indicated:
+
            
+
            
+[..] It shall be DefaultConstructible, CopyConstructible, and publicly
+and unambiguously derived, directly or indirectly, from
+its BaseCharacteristic, which is a specialization of the
+template integral_constant (20.6.3), with the arguments to the template
+integral_constant determined by the requirements for the particular
+property being described. The member names of the
+BaseCharacteristic shall be unhidden and unambiguously
+available in the UnaryTypeTrait.
+
            
+
            2. 
+
          2. 
+
            
+Change 20.6.1 [meta.rqmts]/2 as indicated:
+
            
+
            
+[..] It shall be DefaultConstructible, CopyConstructible, and publicly
+and unambiguously derived, directly or indirectly, from
+an instance its BaseCharacteristic, which is a
+specialization of the template integral_constant (20.6.3), with
+the arguments to the template integral_constant determined by the
+requirements for the particular relationship being described. The
+member names of the BaseCharacteristic shall be unhidden
+and unambiguously available in the BinaryTypeTrait.
+
            
+
            3. 
+
          3. 
+
            
+Change 20.6.4 [meta.unary]/2 as indicated:
+
            
+
            
+Each of these templates shall be a UnaryTypeTrait (20.6.1),
+publicly derived directly or indirectly from true_type if the
+corresponding condition is true, otherwise from false_type
+where its BaseCharacteristic shall be true_type if the
+corresponding condition is true, otherwise false_type.
+
            
+
            4. 
+
          4. 
+
            
+Change 20.6.5 [meta.rel]/2 as indicated:
+
            
+
+
            
+Each of these templates shall be a BinaryTypeTrait (20.6.1),
+publicly derived directly or indirectly from true_type if the
+corresponding condition is true, otherwise from false_type
+where its BaseCharacteristic shall be true_type if the
+corresponding condition is true, otherwise false_type.
+
            
+
            5. 
+
          
+
+
+
+
+
+
+
          
+
          1115. va_copy missing from Standard macros table
          
+
          Section: C.2 [diff.library] Status: New
+ Submitter: Miles Zhao Opened: 2009-05-23  Last modified: 2009-05-23
          
+
          View all other issues in [diff.library].
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
          
+In "Table 122 -- Standard macros" of C.2 [diff.library], which lists the 56 macros
+inherited from C library, va_copy seems to be missing. But in
+"Table 21 -- Header <cstdarg> synopsis" (18.10 [support.runtime]), there is.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Add va_copy to Table 122 -- Standard macros in C.2 [diff.library].
+
          
+
+
+
+
+
+
          
+
          1116. Literal constructors for tuple
          
+
          Section: 20.5.2 [tuple.tuple] Status: New
+ Submitter: Alisdair Meredith Opened: 2009-05-23  Last modified: 2009-05-24
          
+
          View other active issues in [tuple.tuple].
          
+
          View all other issues in [tuple.tuple].
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
          
+It is not currently possible to construct tuple literal values,
+even if the elements are all literal types.  This is because parameters
+are passed to constructor by reference.
+
          
+
          
+An alternative would be to pass all constructor arguments by value, where it
+is known that *all* elements are literal types.  This can be determined with
+concepts, although note that the negative constraint really requires
+factoring out a separate concept, as there is no way to provide an 'any of
+these fails' constraint inline.
+
          
+
          
+Note that we will have similar issues with pair (and
+tuple constructors from pair) although I am steering
+clear of that class while other constructor-related issues settle.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Ammend the tuple class template declaration in 20.5.2 [tuple.tuple] as
+follows
+
          
+
+
          
+
          
+Add the following concept:
+
          
+
+
          auto concept AllLiteral< typename ... Types > {
+  requires LiteralType<Types>...;
+}
+
          
+
+
          
+ammend the constructor 
+
          
+
+
          template <class... UTypes>
+  requires AllLiteral<Types...>
+        && Constructible<Types, UTypes>...
+  explicit tuple(UTypes...);
+
+template <class... UTypes>
+  requires !AllLiteral<Types...>
+        && Constructible<Types, UTypes&&>...
+  explicit tuple(UTypes&&...);
+
          
+
+
          
+ammend the constructor
+
          
+
+
          template <class... UTypes>
+  requires AllLiteral<Types...>
+        && Constructible<Types, UTypes>...
+  tuple(tuple<UTypes...>);
+
+template <class... UTypes>
+  requires !AllLiteral<Types...>
+        && Constructible<Types, const UTypes&>...
+  tuple(const tuple<UTypes...>&);
+
          
+
+
          
+
+
          
+Update the same signatures in 20.5.2.1 [tuple.cnstr], paras 3 and 5.
+
          
+
+
+
+
+
+
          
+
          1117. tuple copy constructor
          
+
          Section: 20.5.2.1 [tuple.cnstr] Status: New
+ Submitter: Alisdair Meredith Opened: 2009-05-23  Last modified: 2009-05-30
          
+
          View other active issues in [tuple.cnstr].
          
+
          View all other issues in [tuple.cnstr].
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
          
+The copy constructor for the tuple template is constrained.  This seems an
+unusual strategy, as the copy constructor will be implicitly deleted if the
+constraints are not met.  This is exactly the same effect as requesting an
+=default; constructor.  The advantage of the latter is that it retains
+triviality, and provides support for tuples as literal types if issue
+1116 is also accepted.
+
          
+
          
+Actually, it might be worth checking with core if a constrained copy
+constructor is treated as a constructor template, and as such does not
+suppress the implicit generation of the copy constructor which would hide
+the template in this case.
+
          
+
+
          [
+2009-05-27 Daniel adds:
+]
          
+
+
+
          
+This would solve one half of the suggested changes in 801.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 20.5.2 [tuple.tuple] and 20.5.2.1 [tuple.cnstr] p4:
+
          
+
+
          requires CopyConstructible<Types>... tuple(const tuple&) = default;
+
          
+
+
+
+
+
+
          
+
          1118. tuple query APIs do not support cv-qualification
          
+
          Section: 20.5.2.3 [tuple.helper] Status: New
+ Submitter: Alisdair Meredith Opened: 2009-05-23  Last modified: 2009-05-25
          
+
          View other active issues in [tuple.helper].
          
+
          View all other issues in [tuple.helper].
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
          
+The APIs tuple_size and tuple_element do not support
+cv-qualified tuples, pairs or arrays.
+
          
+
          
+The most generic solution would be to supply partial specializations once
+for each cv-type in the tuple header.  However, requiring this header for
+cv-qualified pairs/arrays seems unhelpful.  The BSI editorial
+suggestion (UK-198/US-69,
+N2533)
+to merge tuple into <utility> would help with pair,
+but not array.  That might be resolved by making a dependency between the
+<array> header and <utility>, or simply recognising
+the dependency be fulfilled in a Remark.
+
          
+
+
          [
+2009-05-24 Daniel adds:
+]
          
+
+
+
          
+
          
+All tuple_size templates with a base class need to derive publicly, e.g.
+
          
+
+
          template <IdentityOf T> class tuple_size< const T > :
+   public tuple_size<T> {};
+
          
+
+
          
+The same applies to the tuple_element class hierarchies.
+
          
+
          
+What is actually meant with the comment
+
          
+
          
+this solution relies on 'metafunction forwarding' to inherit the
+nested typename type
+
          
+
          
+?
+
          
+
          
+I ask, because all base classes are currently unconstrained and their
+instantiation is invalid in the constrained context of the tuple_element partial
+template specializations.
+
          
+
          
+
+
          [
+2009-05-24 Alisdair adds:
+]
          
+
+
+
          
+
          
+I think a better solution might be to ask Pete editorially to change all
+declarations of tupling APIs to use the struct specifier instead of class.
+
          
+
          
+"metafunction forwarding" refers to the MPL metafunction protocol, where a
+metafunction result is declared as a nested typedef with the name "type",
+allowing metafunctions to be chained by means of inheritance.  It is a
+neater syntax than repeatedly declaring a typedef, and inheritance syntax is
+slightly nicer when it comes to additional typename keywords.
+
          
+
          
+The constrained template with an unconstrained base is a good observation
+though.
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+Add to 20.5.1 [tuple.general] p2 (Header <tuple> synopsis)
+
          
+
+
          // 20.5.2.3, tuple helper classes:
+template <IdentityOf T> class tuple_size; // undefined
+template <IdentityOf T> class tuple_size< const T > : tuple_size<T> {};
+template <IdentityOf T> class tuple_size< volatile T > : tuple_size<T> {};
+template <IdentityOf T> class tuple_size< const volatile T > : tuple_size<T> {};
+
+template <VariableType... Types> class tuple_size<tuple<Types...> >;
+
+template <size_t I, IdentityOf T> class tuple_element; // undefined
+template <size_t I, IdentityOf T> class tuple_element<I, const T>;
+template <size_t I, IdentityOf T> class tuple_element<I, volatile T>;
+template <size_t I, IdentityOf T> class tuple_element<I, const volatile T>;
+
+template <size_t I, VariableType... Types>
+  requires True<(I < sizeof...(Types))> class tuple_element<I, tuple<Types...> >;
+
          
+
+
          
+Add to 20.5.2.3 [tuple.helper]
+
          
+
          [
+(note that this solution relies on 'metafunction forwarding' to inherit the
+nested typename type)
+]
          
+
+
+
          template <class... Types>
+class tuple_size<tuple<Types...> >
+  : public integral_constant<size_t, sizeof...(Types)> { };
+
+template <size_t I, class... Types>
+requires True<(I < sizeof...(Types))>
+class tuple_element<I, tuple<Types...> > {
+public:
+  typedef TI type;
+};
+
+template <size_t I, IdentityOf T>
+  class tuple_element<I, const T> : add_const<tuple_element<I,T>> {};
+
+template <size_t I, IdentityOf T>
+  class tuple_element<I, volatile T> : add_volatile<tuple_element<I,T>> {};
+
+template <size_t I, IdentityOf T>
+  class tuple_element<I, const volatile T> : add_cv<tuple_element<I,T>> {};
+
          
+
+
+
+
+
+
          
+
          1119. tuple query APIs do not support references
          
+
          Section: 20.5.2.3 [tuple.helper] Status: New
+ Submitter: Alisdair Meredith Opened: 2009-05-23  Last modified: 2009-05-24
          
+
          View other active issues in [tuple.helper].
          
+
          View all other issues in [tuple.helper].
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
          
+The tuple query APIs tuple_size and
+tuple_element do not support references-to-tuples.  This can be
+annoying when a template deduced a parameter type to be a reference,
+which must be explicitly stripped with remove_reference before calling
+these APIs.
+
          
+
          
+I am not proposing a resolution at this point, as there is a
+combinatorial explosion with lvalue/rvalue references and
+cv-qualification (see previous issue) that suggests some higher
+refactoring is in order.  This might be something to kick back over to
+Core/Evolution.
+
          
+
          
+Note that we have the same problem in numeric_limits.
+
          
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1120. New type trait - remove_all
          
+
          Section: 20.6 [meta] Status: New
+ Submitter: Alisdair Meredith Opened: 2009-05-23  Last modified: 2009-05-24
          
+
          View other active issues in [meta].
          
+
          View all other issues in [meta].
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
          
+Sometimes it is necessary to remove all qualifiers from a type before
+passing on to a further API.  A good example would be calling the
+tuple query APIs tuple_size or tuple_element
+with a deduced type inside a function template.  If the deduced type is
+cv-qualified or a reference then the call will fail.  The solution is to
+chain calls to
+remove_cv<remove_reference<T>::type>::type, and
+note that the order matters.
+
          
+
          
+Suggest it would be helpful to add a new type trait,
+remove_all, that removes all top-level qualifiers from a type
+i.e. cv-qualification and any references.  Define the term in such a way
+that if additional qualifiers are added to the language, then
+remove_all is defined as stripping those as well.
+
          
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1121. Support for multiple arguments
          
+
          Section: 20.4.2 [ratio.arithmetic] Status: New
+ Submitter: Alisdair Meredith Opened: 2009-05-25  Last modified: 2009-05-25
          
+
          View other active issues in [ratio.arithmetic].
          
+
          View all other issues in [ratio.arithmetic].
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
          
+Both add and multiply could sensibly be called with more than two arguments.
+The variadic template facility makes such declarations simple, and is likely
+to be frequently wrapped by end users if we do not supply the variant
+ourselves.
+
          
+
          
+We deliberately ignore divide at this point as it is not transitive.
+Likewise, subtract places special meaning on the first argument so I do not
+suggest extending that immediately.  Both could be supported with analogous
+wording to that for add/multiply below.
+
          
+
          
+Note that the proposed resolution is potentially incompatible with that
+proposed for 921, although the addition of the typedef to ratio would be
+equally useful.
+
          
+
+
+
          Proposed resolution:
          
+
          [
+note that this wording relies on 'metafunction forwarding' as described by
+Boost MPL
+]
          
+
+
+
          
+20.4 [ratio] p3 synopsis: change
+
          
+
+
          // ratio arithmetic
+template <class R1, class R2, class ... RList> struct ratio_add;
+template <class R1, class R2> struct ratio_subtract;
+template <class R1, class R2, class ... RList> struct ratio_multiply;
+template <class R1, class R2> struct ratio_divide;
+
          
+
+
          
+20.4.2 [ratio.arithmetic] p1: change
+
          
+
+
          template <class R1, class R2, class ... RList> struct ratio_add
+  : ratio_add< R1, ratio_add<R2, RList...>> {
+};
+
+template <class R1, class R2> struct ratio_add<R1, R2> {
+  typedef see below type;
+};
+
          
+
+
+
          
+20.4.2 [ratio.arithmetic] p3: change
+
          
+
+
          template <class R1, class R2, class ... RList> struct ratio_multiply
+  : ratio_multiply< R1, ratio_ multiply <R2, RList...>> {
+};
+
+template <class R1, class R2> struct ratio_ multiply<R1, R2> {
+  typedef see below type;
+};
+
          
+
+
+
+
+
+
+
          
+
          1122. Ratio values should be constexpr
          
+
          Section: 20.4.1 [ratio.ratio] Status: New
+ Submitter: Alisdair Meredith Opened: 2009-05-25  Last modified: 2009-05-25
          
+
          View other active issues in [ratio.ratio].
          
+
          View all other issues in [ratio.ratio].
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
          
+The values num and den in the ratio template
+should be declared constexpr.
+
          
+
+
+
          Proposed resolution:
          
+
          
+20.4.1 [ratio.ratio]
+
          
+
+
          namespace std {
+  template <intmax_t N, intmax_t D = 1>
+  class ratio {
+  public:
+    static constexpr intmax_t num;
+    static constexpr intmax_t den;
+  };
+}
+
          
+
+
+
+
+
+
+
          
+
          1123. no requirement that standard streams be flushed
          
+
          Section: 27.5.2.1.6 [ios::Init] Status: New
+ Submitter: James Kanze Opened: 2009-05-14  Last modified: 2009-05-30
          
+
          View other active issues in [ios::Init].
          
+
          View all other issues in [ios::Init].
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
          
+As currently formulated, the standard doesn't require that there 
+is ever a flush of cout, etc.  (This implies, for example, that 
+the classical hello, world program may have no output.)  In the 
+current draft
+(N2798),
+there is a requirement that the objects 
+be constructed before main, and before the dynamic 
+initialization of any non-local objects defined after the 
+inclusion of <iostream> in the same translation unit.  The only 
+requirement that I can find concerning flushing, however, is in 
+27.5.2.1.6 [ios::Init], where the destructor of the last 
+std::ios_base::Init object flushes.  But there is, as far as I 
+can see, no guarantee that such an object ever exists. 
+
          
+
          
+Also, the wording in  [iostreams.objects] says that:
+
          
+
          
+The objects 
+are constructed and the associations are established at some 
+time prior to or during the first time an object of class 
+ios_base::Init is constructed, and in any case before the body 
+of main begins execution.
+
          
+
          
+In 27.5.2.1.6 [ios::Init], however, as an 
+effect of the constructor, it says that
+
          
+
          
+If init_cnt is zero, 
+the function stores the value one in init_cnt, then constructs 
+and initializes the objects cin, cout, cerr, clog 
+wcin, wcout, wcerr, and wclog"
+
          
+
+
          
+which seems to forbid earlier 
+construction. 
+
          
+
+
          
+(Note that with these changes, the exposition only "static 
+int init_cnt" in ios_base::Init can be dropped.) 
+
          
+
          
+Of course, a determined programmer can still inhibit the 
+flush with things like: 
+
          
+
          new std::ios_base::Init ;       //  never deleted 
+
          
+
          
+or (in a function): 
+
          
+
          std::ios_base::Init ensureConstruction ; 
+//  ... 
+exit( EXIT_SUCCESS ) ; 
+
          
+
          
+Perhaps some words somewhere to the effect that all 
+std::ios_base::Init objects should have static lifetime 
+would be in order. 
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 27.4 [iostream.objects]/2:
+
          
+
+
          
+-2- The objects are constructed and the associations are established at
+some time prior to or during the first time an object of class
+ios_base::Init is constructed, and in any case before the body
+of main begins execution.292 The objects are not destroyed
+during program execution.293
+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.
+The results of including <iostream> in a translation
+unit shall be as if <iostream> defined an instance of
+ios_base::Init with static lifetime. Similarly, the entire
+program shall behave as if there were at least one instance of
+ios_base::Init with static lifetime.
+
          
+
+
          
+Change 27.5.2.1.6 [ios::Init]/3:
+
          
+
+
          
+
          Init();
+
          
+
          
+-3- Effects: Constructs an object of class Init. 
+If init_cnt is zero, the function stores the value one in
+init_cnt, then constructs and initializes the objects
+cin, cout, cerr, clog (27.4.1),
+wcin, wcout, wcerr, and wclog
+(27.4.2). In any case, the function then adds one to the value stored in
+init_cnt.
+Constructs and initializes the objects cin, cout,
+cerr, clog, wcin, wcout,
+wcerr and wclog if they have not already been
+constructed and initialized.
+
          
+
          
+
+
          
+Change 27.5.2.1.6 [ios::Init]/4:
+
          
+
+
          
+
          ~Init();
+
          
+
          
+-4- Effects: Destroys an object of class Init.
+The function subtracts one from the value stored in init_cnt and,
+if the resulting stored value is one,
+If there are no other instances of the class still in
+existance,
+calls cout.flush(),
+cerr.flush(), clog.flush(), wcout.flush(),
+wcerr.flush(), wclog.flush().
+
          
+
          
+
+
+
+
+
+
+
          
+
          1124.  Invalid definition of concept RvalueOf
          
+
          Section: 20.2.1 [concept.transform] Status: New
+ Submitter: Daniel Krügler Opened: 2009-05-28  Last modified: 2009-05-30
          
+
          View other active issues in [concept.transform].
          
+
          View all other issues in [concept.transform].
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
          
+A recent news group
+article
+points to several defects in the
+specification of reference-related concepts.
+
          
+
          
+One problem of the concept RvalueOf as currently defined in
+20.2.1 [concept.transform]:
+
          
+
+
          concept RvalueOf<typename T> {
+ typename type = T&&;
+ requires ExplicitlyConvertible<T&,type> && Convertible<T&&,type>;
+}
+
+template<typename T> concept_map RvalueOf<T&> {
+ typedef T&& type;
+}
+
          
+
+
          
+is that if T is an lvalue-reference, the requirement
+Convertible<T&&,type> isn't satisfied for
+lvalue-references, because after reference-collapsing in the concept
+definition we have Convertible<T&,type> in this case,
+which isn't satisfied in the concept map template and also is not the
+right constraint either. I think that the reporter is right that
+SameType requirements should do the job and that we also should
+use the new RvalueReference concept to specify a best matching
+type requirement.
+
          
+
+
+
          Proposed resolution:
          
+
          
+In 20.2.1 [concept.transform] before p. 4 change as indicated:
+
          
+
+
          auto concept RvalueOf<typename T> {
+  typenameRvalueReference type = T&&;
+  requires ExplicitlyConvertible<T&, type> && Convertible<T&&, type>SameType<T&, type&>;
+}
+
          
+
+
+
+
+
+
          
+
          1125. ostream_iterator does not work with movable types
          
+
          Section: 24.6.2.2 [ostream.iterator.ops] Status: New
+ Submitter: Alisdair Meredith Opened: 2009-05-28  Last modified: 2009-05-30
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
          
+ostream_iterator has not been updated to support moveable types, in a
+similar manner to the insert iterators.
+Note that this is not a problem for ostreambuf_iterator, as the types it is
+restricted to dealing with do not support extra-efficient moving.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Add second operator= overload to class template ostream_iterator
+in 24.6.2 [ostream.iterator], para 2:
+
          
+
+
          ostream_iterator<T,charT,traits>& operator=(const T& value);
+ostream_iterator<T,charT,traits>& operator=(T&& value);
+
          
+
+
          
+Add a new paragraph: in 24.6.2.2 [ostream.iterator.ops]:
+
          
+
+
          
+
          ostream_iterator& operator=(T&& value);
+
          
+
          
+
          
+-2- Effects:
+
          
+
          *out_stream << std::move(value);
+if(delim != 0)
+  *out_stream << delim;
+return (*this);
+
          
+
          
+
          
+
+
+
+
+
+
+
          
+
          1126. istreambuff_iterator::equal needs a const & parameter
          
+
          Section: 24.6.3.5 [istreambuf.iterator::equal] Status: New
+ Submitter: Alisdair Meredith Opened: 2009-05-28  Last modified: 2009-05-30
          
+
          View other active issues in [istreambuf.iterator::equal].
          
+
          View all other issues in [istreambuf.iterator::equal].
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
          
+The equal member function of istreambuf_iterator is
+declared const, but takes its argument by non-const reference.
+
          
+
          
+This is not compatible with the operator== free function overload, which is
+defined in terms of calling equal yet takes both arguments by reference to
+const.
+
          
+
+
          [
+The proposed wording is consistent with 110 with status TC1.
+]
          
+
+
+
+
+
          Proposed resolution:
          
+
          
+Ammend in both:
          
+24.6.3 [istreambuf.iterator]
          
+24.6.3.5 [istreambuf.iterator::equal]
          
+
          
+
+
          bool equal(const istreambuf_iterator& b) const;
+
          
+
+
+
+
+
+
+
          
+
          1127. rvalue references and iterator traits
          
+
          Section: D.10.1 [iterator.traits] Status: New
+ Submitter: Alisdair Meredith Opened: 2009-05-28  Last modified: 2009-05-30
          
+
          View all other issues in [iterator.traits].
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
          
+The deprecated support for iterator_traits and legacy (unconstrained)
+iterators features the (exposition only) concept:
+
          
+
+
          concept IsReference<typename T> { } // exposition only
+template<typename T> concept_map IsReference<T&> { }
+
          
+
          
+Now this looks exactly like the LvalueReference concept recently added to
+clause 20, so I wonder if we should use that instead?
+Then I consider the lack of rvalue-reference support, which means that
+move_iterator would always flag as merely supporting the input_iterator_tag
+category.  This suggests we retain the exposition concept, but add a second
+concept_map to support rvalue references.
+
          
+
          
+I would suggest adding the extra concept_map is the right way forward, but
+still wonder if the two exposition-only concepts in this clause might be
+worth promoting to clause 20.  That question might better be answered with a
+fuller investigation of type_trait/concept unification though.
+
          
+
+
+
          Proposed resolution:
          
+
          
+In Iterator traits D.10.1 [iterator.traits] para 4 add:
+
          
+
+
          concept IsReference<typename T> { } // exposition only
+template<typename T> concept_map IsReference<T&> { }
+template<typename T> concept_map IsReference<T&&> { }
+
          
+
+
+
+
+
+
+
          
+
          1128. Missing definition of iterator_traits<T*>
          
+
          Section: 24.3 [iterator.syn] Status: New
+ Submitter: Alisdair Meredith Opened: 2009-05-28  Last modified: 2009-05-30
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
          
+The <iterator> header synopsis declares a partial specialization of
+iterator_traits to support pointers, 24.3 [iterator.syn].  The implication
+is that specialization will be described in D10, yet it did not follow the
+rest of the deprecated material into this clause.
+
          
+
          
+However, this is not as bad as it first seems!
+There are partial specializations of iterator_traits for types that satisfy
+the various Iterator concepts, and there are concept_maps for pointers to
+explicitly support the RandomAccessIterator concept, so the required
+template will be present - just not in the manner advertised.
+
          
+
          
+I can see two obvious solutions:
+
          
+
+
            
+
          1. 
+Restore the iterator_traits<T*> partial specialization in D.10
+
            2. 
+
          2. 
+Remove the declaration of iterator_traits<T*> from 24.3 synopsis
+
            3. 
+
          
+
          
+I recommend option (ii) in the wording below
+
          
+
          
+Option (ii) could be extended to strike all the declarations of deprecated
+material from the synopsis, as it is effectively duplicating D.10 anyway.
+This is the approach taken for deprecated library components in the 98/03
+standards.  This is probably a matter best left to the Editor though.
+
          
+
+
+
          Proposed resolution:
          
+
          
+In 24.3 [iterator.syn] strike:
+
          
+
+
          template<class T> struct iterator_traits<T*>;
+
          
+
+
+
+
+
+
+
          
+
          1129. istream(buf)_iterator should support literal sentinel value
          
+
          Section: 24.6.1.1 [istream.iterator.cons], 24.6.3 [istreambuf.iterator] Status: New
+ Submitter: Alisdair Meredith Opened: 2009-05-30  Last modified: 2009-06-09
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
          
+istream_iterator and istreambuf_iterator should support literal sentinel
+values.  The default constructor is frequently used to terminate ranges, and
+could easily be a literal value for istreambuf_iterator, and
+istream_iterator when iterating value types.  A little more work using a
+suitably sized/aligned char-array for storage (or an updated component like
+boost::optional proposed for TR2) would allow istream_iterator to support
+constexpr default constructor in all cases, although we might leave this
+tweak as a QoI issue.  Note that requiring constexpr be supported also
+allows us to place no-throw guarantees on this constructor too.
+
          
+
+
          [
+2009-06-02 Daniel adds:
+]
          
+
+
+
          
+
          
+I agree with the usefulness of the issue suggestion, but we need
+to ensure that istream_iterator can satisfy be literal if needed.
+Currently this is not clear, because 24.6.1 [istream.iterator]/3 declares
+a copy constructor and a destructor and explains their semantic in
+24.6.1.1 [istream.iterator.cons]/3+4.
+
          
+
          
+The prototype semantic specification is ok (although it seems
+somewhat redundant to me, because the semantic doesn't say
+anything interesting in both cases), but for support of trivial class
+types we also need a trivial copy constructor and destructor as of
+9 [class]/6. The current non-informative specification of these
+two special members suggests to remove their explicit declaration
+in the class and add explicit wording that says that if T is
+trivial a default constructed iterator is also literal, alternatively it
+would be possible to mark both as defaulted and add explicit
+(memberwise) wording that guarantees that they are trivial.
+
          
+
          
+Btw.: I'm quite sure that the istreambuf_iterator additions to
+ensure triviality are not sufficient as suggested, because the
+library does not yet give general guarantees that a defaulted
+special member declaration makes this member also trivial.
+Note that e.g. the atomic types do give a general statement!
+
          
+
          
+Finally there is a wording issue: There does not exist something
+like a "literal constructor". The core language uses the term
+"constexpr constructor" for this.
+
          
+
          
+Suggestion:
+
          
+
            
+
          1. 
+
            
+Change 24.6.1 [istream.iterator]/3 as indicated:
+
            
+
            constexpr istream_iterator();
+istream_iterator(istream_type& s);
+istream_iterator(const istream_iterator<T,charT,traits,Distance>& x) = default;
+~istream_iterator() = default;
+
            
+
            2. 
+
          2. 
+
            
+Change 24.6.1.1 [istream.iterator.cons]/1 as indicated:
+
            
+
            constexpr istream_iterator();
+
            
+
            
+-1- Effects: Constructs the end-of-stream iterator. If T is a literal type,
+then this constructor shall be a constexpr constructor.
+
            
+
            
+
            3. 
+
          3. 
+
            
+Change 24.6.1.1 [istream.iterator.cons]/3 as indicated:
+
            
+
            istream_iterator(const istream_iterator<T,charT,traits,Distance>& x) = default;
+
            
+
            
+-3- Effects: Constructs a copy of x. If T is a literal type, then
+this constructor shall be a trivial copy constructor.
+
            
+
            
+
            4. 
+
          4. 
+
            
+Change 24.6.1.1 [istream.iterator.cons]/4 as indicated:
+
            
+
+
            ~istream_iterator() = default;
+
            
+
            
+-4- Effects: The iterator is destroyed. If T is a literal type, then
+this destructor shall be a trivial
+destructor.
+
            
+
            
+
            5. 
+
          5. 
+
            
+Change 24.6.3 [istreambuf.iterator] before p. 1 as indicated:
+
            
+
+
            constexpr istreambuf_iterator() throw();
+istreambuf_iterator(const istreambuf_iterator&)  throw() = default;
+~istreambuf_iterator()  throw() = default;
+
            
+
            6. 
+
          6. 
+
            
+Change 24.6.3 [istreambuf.iterator]/1 as indicated:
+
            
+
            
+[..] The default constructor istreambuf_iterator() and the constructor
+istreambuf_iterator(0) both
+construct an end of stream iterator object suitable for use as an
+end-of-range. All
+specializations of istreambuf_iterator shall have a trivial copy
+constructor, a constexpr default
+constructor and a trivial destructor.
+
            
+
            7. 
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+24.6.1 [istream.iterator] para 3
+
          
+
+
          constexpr istream_iterator();
+
          
+
+
          
+24.6.1.1 [istream.iterator.cons]
+
          
+
+
          constexpr istream_iterator();
+
          
+
          
+-1- Effects: Constructs the end-of-stream iterator.
+If T is a literal type, then this constructor shall
+be a literal constructor.
+
          
+
          
+
+
          
+24.6.3 [istreambuf.iterator]
+
          
+
+
          constexpr istreambuf_iterator() throw();
+
          
+
+
+
+
+
+
+
          
+
          1130. copy_exception name misleading
          
+
          Section: 18.8.5 [propagation] Status: New
+ Submitter: Peter Dimov Opened: 2009-05-13  Last modified: 2009-06-02
          
+
          View other active issues in [propagation].
          
+
          View all other issues in [propagation].
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
          
+The naming of std::copy_exception misleads almost everyone
+(experts included!) to think that it is the function that copies an
+exception_ptr:
+
          
+
+
          exception_ptr p1 = current_exception();
+exception_ptr p2 = copy_exception( p1 );
+
          
+
+
          
+But this is not at all what it does. The above actually creates an
+exception_ptr p2 that contains a copy of p1, not of
+the exception to which p1 refers!
+
          
+
          
+This is, of course, all my fault; in my defence, I used copy_exception
+because I was unable to think of a better name.
+
          
+
          
+But I believe that, based on what we've seen so far, any other name would be better.
+
          
+
          
+Therefore, I propose copy_exception to be renamed to
+create_exception:
+
          
+
+
          template<class E> exception_ptr create_exception(E e);
+
          
+
+
          
+with the following explanatory paragraph after it:
+
          
+
+
          
+Creates an exception_ptr that refers to a copy of e.
+
          
+
+
          [
+2009-05-13 Daniel adds:
+]
          
+
+
+
          
+
          
+What about
+
          
+
          make_exception_ptr
+
          
+
          
+in similarity to make_pair and make_tuple, make_error_code and
+make_error_condition, or make_shared? Or, if a stronger symmetry to
+current_exception is preferred:
+
          
+
+
          make_exception
+
          
+
          
+We have not a single create_* function in the library, it was always
+make_* used.
+
          
+
          
+
+
          [
+2009-05-13 Peter adds:
+]
          
+
+
+
          
+make_exception_ptr works for me.
+
          
+
+
          [
+2009-06-02 Thomas J. Gritzan adds:
+]
          
+
+
+
          
+
          
+To avoid surprises and unwanted recursion, how about making a call to
+std::make_exception_ptr with an exception_ptr illegal?
+
          
+
          
+It might work like this:
+
          
+
          template<class E>
+exception_ptr make_exception_ptr(E e);
+template<>
+exception_ptr make_exception_ptr<exception_ptr>(exception_ptr e) = delete;
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+Change 18.8.5 [propagation]:
+
          
+
+
          
+
          template<class E> exception_ptr copy_exceptionmake_exception_ptr(E e);
+
          
+
+
          
+
          
+-11- Effects: Creates an exception_ptr that refers
+to a copy of e, as if
+
          
+
+
          try {
+  throw e;
+} catch(...) {
+  return current_exception();
+}
+
          
+
+
          ...
          
+
          
+
+
          
+
+
+
+
+
+
+
          
+
          1131. C++0x does not need alignment_of
          
+
          Section: 20.6.4.3 [meta.unary.prop] Status: New
+ Submitter: Niels Dekker Opened: 2009-06-01  Last modified: 2009-06-02
          
+
          View other active issues in [meta.unary.prop].
          
+
          View all other issues in [meta.unary.prop].
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
          
+The alignment_of template is no longer necessary, now that the
+core language will provide alignof. Scott Meyers raised this
+issue at comp.std.c++,
+C++0x: alignof vs. alignment_of,
+May 21, 2009.  In a reply, Daniel Krügler pointed out that
+alignof was added to the working paper after
+alignment_of. So it appears that alignment_of is only
+part of the current Working Draft 
+(N2857)
+because it is in TR1.
+
          
+
          
+Having both alignof and alignment_of would cause
+unwanted confusion. In general, I think TR1 functionality should not be
+brought into C++0x if it is entirely redundant with other C++0x language
+or library features.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Remove from Header <type_traits> synopsis 20.6.2 [meta.type.synop]:
+
          
+
          template <class T> struct alignment_of;
+
          
+
+
          
+Remove the first row of Table 34 ("Type property queries"), from
+Type properties 20.6.4.3 [meta.unary.prop]:
+
          
+
          
+
+
+
+
+
+
+
          Table 34 -- Type property queries
          template <class T> struct alignment_of;alignof(T).
          
+Precondition: T shall be a complete type, a reference
+type, or an array of unknown bound, but shall not be a function type or
+(possibly cv-qualified) void.
+
          
+
          
+
+
          
+Change text in Table 41 ("Other transformations"), from Other
+transformations 20.6.7 [meta.trans.other], as follows:
+
          
+
          
+
+
+
+
+
+
          Table 41 -- Other transformations
          ...
+ Align shall be equal to 
+ alignment_of<T>::value
+ alignof(T)
+  for some type T or to default-alignment.
+...
          
+
          
+
+
+
+
+
+
          
+
          1132. JP-30: nested exceptions
          
+
          Section: 18.8.6 [except.nested] Status: New
+ Submitter: Seiji Hayashida Opened: 2009-06-01  Last modified: 2009-06-02
          
+
          View other active issues in [except.nested].
          
+
          View all other issues in [except.nested].
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
          Addresses JP 30
          
+
+
          
+C++0x nested_exception cannot handle a structured exception well. The
+following codes show two types of tree structured exception handling.
+
          
+
          
+The first one is based on nested_exception in C++0x,
+while the second one is based on my library trickerr.h (in Japanese).
+http://tricklib.com/cxx/dagger/trickerr.h
+
          
+
          
+Assume that Function A() calls two sub functions A_a() and A_b(), both might
+throw tree structured exceptions, and A_b() must be called even if A_a()
+throws an exception.
+
          
+
          
+List A (code of tree structured exception handling based on nested_exception
+in C++0x)
+
          
+
+
          void A()
+{
+    try
+    {
+        std::vector<exception_ptr> exception_list;
+        try
+        {
+            // A_a() does a similar processing as A().
+            A_a();
+        }
+        catch(...)
+        {
+            exception_list.push_back(current_exception());
+        }
+
+        // ***The processing A() has to do even when A_a() fails. ***
+        try
+        {
+            // A_b() does a similar processing as A().
+            A_b();
+        }
+        catch(...)
+        {
+            exception_list.push_back(current_exception());
+        }
+        if (!exception_list.empty())
+        {
+            throw exception_list;
+        }
+    }
+    catch(...)
+    {
+        throw_with_nested(A_exception("someone error"));
+    }
+}
+void print_tree_exception(exception_ptr e, const std::string & indent ="")
+{
+    const char * indent_unit = " ";
+    const char * mark = "- ";
+    try
+    {
+        rethow_exception(e);
+    }
+    catch(const std::vector<exception_ptr> e)
+    {
+        for(std::vector<exception_ptr>::const_iterator i = e.begin(); i!=e.end(); ++i)
+        {
+            print_tree_exception(i, indent);
+        }
+    }
+    catch(const std::nested_exception  e)
+    {
+        print_tree_exception(evil_i(e), indent +indent_unit);
+    }
+    catch(const std::exception e)
+    {
+        std::cout << indent << mark << e.what() << std::endl;
+    }
+    catch(...)
+    {
+        std::cout << indent << mark << "unknown exception" << std::endl;
+    }
+}
+int main(int, char * [])
+{
+    try
+    {
+        A();
+    }
+    catch()
+    {
+        print_tree_exception(current_exception());
+    }
+    return EXIT_SUCCESS;
+}
+
          
+
+
          
+List B ( code of tree structured exception handling based on trickerr.h. )
+"trickerr.h" (in Japanese), refer to:
+http://tricklib.com/cxx/dagger/trickerr.h.
+
          
+
+
          void A()
+{
+    tricklib::error_listener_type error_listener;
+    // A_a() is like A(). A_a() can throw tree structured exception.
+    A_a();
+
+    // *** It must do process so that A_a() throws exception in A(). ***
+    // A_b() is like A(). A_b() can throw tree structured exception.
+    A_b();
+
+    if (error_listener.has_error()) // You can write this "if block" in destructor
+                                    //  of class derived from error_listener_type.
+    {
+        throw_error(new A_error("someone error",error_listener.listener_off().extract_pending_error()));
+    }
+}
+void print_tree_error(const tricklib::error_type &a_error, const std::string & indent = "")
+{
+    const char * indent_unit = " ";
+    const char * mark = "- ";
+
+    tricklib::error_type error = a_error;
+    while(error)
+    {
+        std::cout << indent << mark << error->message << std::endl;
+        if (error->children)
+        {
+            print_tree_error(error->children, indent +indent_unit);
+        }
+        error = error->next;
+    }
+}
+int main(int, char * [])
+{
+    tricklib::error_thread_power error_thread_power_on; // This object is necessary per thread.
+
+    try
+    {
+        A();
+    }
+    catch(error_type error)
+    {
+        print_tree_error(error);
+    }
+    catch(...)
+    {
+        std::cout << "- unknown exception" << std::endl;
+    }
+    return EXIT_SUCCESS;
+}
+
          
+
+
          
+Prospect
+
          
+
          
+We will focus on the method A() since the other methods, also main(), occur
+only once respectively.
+
          
+
+
            
+
          • 
+ In the List A above (of the nested exception handling), it is hard to
+ find out an active reason to use the nested exception handling at this
+ scene. Rather, we can take a simpler description by throwing the entire
+ exception_list directly to the top level.
+
            • 
+
          • 
+ The code in the same example gives us a kind of redundant impression,
+ which might have come from the fact that the try-throw-catch framework does
+ not assume a tree structured exception handling.
+
            • 
+
          
+
+
          
+According to the above observation, we cannot help concluding that it is not
+so easy to use the nested_exception handling as a tree structured exception
+handling mechanism in a practical sense.
+
          
+
          
+This text is based on the web page below (in Japanese).
+http://d.hatena.ne.jp/wraith13/20081231/1230715424
+
          
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
+
+
+
          
+
          1133. Does N2844 break current specification of list::splice?
          
+
          Section: 23.3.3.5 [forwardlist.ops], 23.3.4.4 [list.ops] Status: New
+ Submitter: Alisdair Meredith Opened: 2009-05-09  Last modified: 2009-06-09
          
+
          View other active issues in [forwardlist.ops].
          
+
          View all other issues in [forwardlist.ops].
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
          
+IIUC,
+N2844
+means that lvalues will no longer bind to rvalue references.
+Therefore, the current specification of list::splice (list
+operations 23.3.4.4 [list.ops]) will be a breaking change of behaviour for existing
+programs.  That is because we changed the signature to swallow via an rvalue
+reference rather than the lvalue reference used in 03.
+
          
+
          
+Retaining this form would be safer, requiring an explicit move when splicing
+from lvalues.  However, this will break existing programs.
+We have the same problem with forward_list, although without the risk of
+breaking programs so here it might be viewed as a positive feature.
+
          
+
          
+The problem signatures:
+
          
+
          void splice_after(const_iterator position, forward_list<T,Alloc>&& x);
+void splice_after(const_iterator position, forward_list<T,Alloc>&& x,
+                  const_iterator i);
+void splice_after(const_iterator position, forward_list<T,Alloc>&& x,
+                  const_iterator first, const_iterator last);
+
+void splice(const_iterator position, list<T,Alloc>&& x);
+void splice(const_iterator position, list<T,Alloc>&& x,
+            const_iterator i);
+void splice(const_iterator position, list<T,Alloc>&& x,
+            const_iterator first, const_iterator last);
+
          
+
+Possible resolutions:
+
+
          
+Option A.	Add an additional (non-const) lvalue-reference
+overload in each case
+
          
+
          
+Option B.	Change rvalue reference back to (non-const)
+lvalue-reference overload in each case
+
          
+
          
+Option C.	Add an additional (non-const) lvalue-reference
+overload in just the std::list cases
+
          
+
          
+I think (B) would be very unfortunate, I really like the forward_list
+behaviour in (C) but feel (A) is needed for consistency.
+
          
+
          
+My actual preference would be NAD, ship with this as a breaking change as it
+is a more explicit interface.  I don't think that will fly though!
+
          
+
+
          
+See the thread starting with c++std-lib-23725 for more discussion.
+
          
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1134. Redundant specification of stdint.h, fenv.h, tgmath.h, and maybe complex.h
          
+
          Section: 18.4.2 [stdinth], 26.3.2 [fenv], 26.8 [c.math], 26.4.11 [cmplxh] Status: New
+ Submitter: Robert Klarer Opened: 2009-05-26  Last modified: 2009-06-14
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
          
+This is probably editorial.
+
          
+
          
+The following items should be removed from the draft, because they're
+redundant with Annex D, and they arguably make some *.h headers
+non-deprecated:
+
          
+
          
+18.4.2 [stdinth] (regarding <stdint.h>) 
+
          
+
          
+26.3.2 [fenv] (regarding <fenv.h>
+
          
+
          
+Line 3 of 26.8 [c.math] (regarding <tgmath.h>) 
+
          
+
          
+26.4.11 [cmplxh] (regarding <complex.h>, though the note in this subclause is not redundant) 
+
          
+
+
          [
+2009-06-10 Ganesh adds:
+]
          
+
+
+
          
+While searching for stdint in the CD, I found that <stdint.h> is also
+mentioned in 3.9.1 [basic.fundamental] /5. It guess it should refer to
+<cstdint> instead.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Remove the section 18.4.2 [stdinth].
+
          
+
          
+Remove the section 26.3.2 [fenv].
+
          
+
          
+Remove 26.8 [c.math], p3:
+
          
+
+
          
+-3- The header <tgmath.h> effectively includes the headers <complex.h>
+and <math.h>.
+
          
+
          
+Remove the section 26.4.11 [cmplxh].
+
          
+
+
+
+
+
+
          
+
          1135. exception_ptr should support contextual conversion to bool
          
+
          Section: 18.8.5 [propagation] Status: New
+ Submitter: Daniel Krügler Opened: 2007-06-06  Last modified: 2009-06-09
          
+
          View other active issues in [propagation].
          
+
          View all other issues in [propagation].
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
          
+As of
+N2857
+18.8.5 [propagation]/5, the implementation-defined type
+exception_ptr does provide the following ways to check whether
+it is a null value:
+
          
+
          void f(std::exception_ptr p) {
+  p == nullptr;
+  p == 0;
+  p == exception_ptr();
+}
+
          
+
          
+This is rather cumbersome way of checking for the null value
+and I suggest to require support for evaluation in a boolean
+context like so:
+
          
+
+
          void g(std::exception_ptr p) {
+  if (p) {}
+  !p;
+}
+
          
+
+
+
          Proposed resolution:
          
+
          
+In section 18.8.5 [propagation] insert a new paragraph between p.5 and p.6:
+
          
+
+
          
+
+An object e of type exception_ptr can be contextually converted to bool.
+The effect shall be as if e != exception_ptr() had been evaluated in place
+of e. There shall be no implicit conversion to arithmetic type, to
+enumeration type or to pointer type.
+
+
          
+
+
+
+
+
+
          
+
          1136. Incomplete specification of nested_exception::rethrow_nested()
          
+
          Section: 18.8.6 [except.nested] Status: New
+ Submitter: Daniel Krügler Opened: 2007-06-06  Last modified: 2009-06-09
          
+
          View other active issues in [except.nested].
          
+
          View all other issues in [except.nested].
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
          
+It was recently mentioned in a newsgroup article
+http://groups.google.de/group/comp.std.c++/msg/f82022aff68edf3d
+that the specification of the member function rethrow_nested() of the
+class nested_exception is incomplete, specifically it remains unclear
+what happens, if member nested_ptr() returns a null value. In
+18.8.6 [except.nested] we find only the following paragraph related to that:
+
          
+
          void rethrow_nested() const; // [[noreturn]]
+
          
+
          
+-4- Throws: the stored exception captured by this nested_exception object.
+
          
+
          
+
          
+This is a problem, because it is possible to create an object of
+nested_exception with exactly such a state, e.g.
+
          
+
          #include <exception>
+#include <iostream>
+
+int main() try {
+  std::nested_exception e; // OK, calls current_exception() and stores it's null value
+  e.rethrow_nested(); // ?
+  std::cout << "A" << std::endl;
+}
+catch(...) {
+  std::cout << "B" << std::endl;
+}
+
          
+
          
+I suggest to follow the proposal of the reporter, namely to invoke
+terminate() if nested_ptr() return a null value of exception_ptr instead
+of relying on the fallback position of undefined behavior. This would
+be consistent to the behavior of a throw; statement when no
+exception is being handled.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change around 18.8.6 [except.nested]/4 as indicated:
+
          
+
          
+
          
+-4- Throws: the stored exception captured by this nested_exception
+object, if nested_ptr() != nullptr
+
          
+
          
+- Remarks: If nested_ptr() == nullptr, terminate()
+shall be called.
+
          
+
          
+
+
+
+
+
+
          
+
          1137. Return type of conj and proj
          
+
          Section: 26.4.9 [cmplx.over] Status: New
+ Submitter: Marc Steinbach Opened: 2009-06-11  Last modified: 2009-06-14
          
+
          View all other issues in [cmplx.over].
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
          
+In clause 1, the Working Draft 
+(N2857)
+specifies overloads of the
+functions
+
          
+
          arg, conj, imag, norm, proj, real
+
          
+
          
+for non-complex arithmetic types (float, double,
+long double, and integers).
+The only requirement (clause 2) specifies type promotion of arguments.
+
          
+
          
+I strongly suggest to add the following requirement on the return types:
+
          
+
          
+All the specified overloads must return real (i.e., non-complex) values,
+specifically, the nested value_type of promoted arguments.
+
          
+
+
          
+(This has no effect on arg, imag, norm, real:
+they are real-valued anyway.)
+
          
+
          Rationale:
          
+
          
+Mathematically, conj() and proj(), like the transcendental functions, are
+complex-valued in general but map the (extended) real line to itself.
+In fact, both functions act as identity on the reals.
+A typical user will expect conj() and proj() to preserve this essential
+mathematical property in the same way as exp(), sin(), etc.
+A typical use of conj(), e.g., is the generic scalar product of n-vectors:
+
          
+
+
          template<typename T>
+inline T
+scalar_product(size_t n, T const* x, T const* y) {
+  T result = 0;
+  for (size_t i = 0; i < n; ++i)
+    result += std::conj(x[i]) * y[i];
+  return result;
+}
+
          
+
          
+This will work equally well for real and complex floating-point types T if
+conj() returns T. It will not work with real types if conj()
+returns complex values.
+
          
+
          
+Instead, the implementation of scalar_product becomes either less efficient
+and less useful (if a complex result is always returned), or unnecessarily
+complicated (if overloaded versions with proper return types are defined).
+In the second case, conj() is not used with real arguments.
+
          
+
          
+Any use of conj() I can think of would benefit from the proposed return type
+requirement, in a similar way.
+It will not harm use cases where a complex value is expected, because of
+implicit conversion to complex.
+Without the proposed return type guarantee, I find an overloaded conj() not
+only useless but actually troublesome.
+
          
+
          
+I believe that the same applies to proj(), althought up to now I had no need
+for it.
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+Insert a new paragraph after 26.4.9 [cmplx.over]/2:
+
          
+
+
          
+
+All of the specified overloads shall have a return type which is the nested value_type of
+the promoted arguments.
+
+
          
+
+
+
+
+
+
          
+
          1138. unusal return value for operator+
          
+
          Section: 21.4.8.1 [string::op+] Status: New
+ Submitter: Alisdair Meredith Opened: 2009-06-12  Last modified: 2009-06-15
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
          
+Many of the basic_string operator+ overloads return an rvalue-reference.  Is
+that really intended?
+
          
+
          
+I'm considering it might be a mild performance tweak to avoid making
+un-necessary copies of a cheaply movable type, but it opens risk to dangling
+references in code like:
+
          
+
+
          auto && s = string{"x"} + string{y};
+
          
+
+
          
+and I'm not sure about:
+
          
+
+
          auto s = string{"x"} + string{y};
+
          
+
+
+
          Proposed resolution:
          
+
          
+Strike the && from the return type in the following function
+signatures:
+
          
+
+
          
+
          
+21.3 [string.classes] p2 Header Synopsis
+
          
+
+
          template<class charT, class traits, class Allocator>
+  basic_string<charT,traits,Allocator>&&
+    operator+(basic_string<charT,traits,Allocator>&& lhs,
+              const basic_string<charT,traits,Allocator>& rhs);
+
+template<class charT, class traits, class Allocator>
+  basic_string<charT,traits,Allocator>&&
+    operator+(const basic_string<charT,traits,Allocator>& lhs,
+              basic_string<charT,traits,Allocator>&& rhs);
+
+template<class charT, class traits, class Allocator>
+  basic_string<charT,traits,Allocator>&&
+    operator+(basic_string<charT,traits,Allocator>&& lhs,
+              basic_string<charT,traits,Allocator>&& rhs);
+
+
+template<class charT, class traits, class Allocator>
+  basic_string<charT,traits,Allocator>&&
+    operator+(const charT* lhs,
+              basic_string<charT,traits,Allocator>&& rhs);
+
+template<class charT, class traits, class Allocator>
+  basic_string<charT,traits,Allocator>&&
+    operator+(charT lhs, basic_string<charT,traits,Allocator>&& rhs);
+
+template<class charT, class traits, class Allocator>
+  basic_string<charT,traits,Allocator>&&
+    operator+(basic_string<charT,traits,Allocator>&& lhs,
+              const charT* rhs);
+
+template<class charT, class traits, class Allocator>
+  basic_string<charT,traits,Allocator>&&
+    operator+(basic_string<charT,traits,Allocator>&& lhs, charT rhs);
+
          
+
+
          
+21.4.8.1 [string::op+]
+
          
+
+
          template<class charT, class traits, class Allocator>
+  basic_string<charT,traits,Allocator>&&
+    operator+(basic_string<charT,traits,Allocator>&& lhs,
+              const basic_string<charT,traits,Allocator>& rhs);
+
+template<class charT, class traits, class Allocator>
+  basic_string<charT,traits,Allocator>&&
+    operator+(const basic_string<charT,traits,Allocator>& lhs,
+              basic_string<charT,traits,Allocator>&& rhs);
+
+template<class charT, class traits, class Allocator>
+  basic_string<charT,traits,Allocator>&&
+    operator+(basic_string<charT,traits,Allocator>&& lhs,
+              basic_string<charT,traits,Allocator>&& rhs);
+
+
+template<class charT, class traits, class Allocator>
+  basic_string<charT,traits,Allocator>&&
+    operator+(const charT* lhs,
+              basic_string<charT,traits,Allocator>&& rhs);
+
+template<class charT, class traits, class Allocator>
+  basic_string<charT,traits,Allocator>&&
+    operator+(charT lhs, basic_string<charT,traits,Allocator>&& rhs);
+
+template<class charT, class traits, class Allocator>
+  basic_string<charT,traits,Allocator>&&
+    operator+(basic_string<charT,traits,Allocator>&& lhs,
+              const charT* rhs);
+
+template<class charT, class traits, class Allocator>
+  basic_string<charT,traits,Allocator>&&
+    operator+(basic_string<charT,traits,Allocator>&& lhs, charT rhs);
+
          
+
+
          
+
+
+
+
+
+
+
          
+
          1139. Response to US 93
          
+
          Section: 30 [thread] Status: New
+ Submitter: Beman Dawes Opened: 2009-06-15  Last modified: 2009-06-15
          
+
          View other active issues in [thread].
          
+
          View all other issues in [thread].
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
+
          Addresses US 93, JP 79, UK 333, JP 81
          
+
+
          
+The thread chapter is not concept enabled.
+
          
+
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1140. Response to US 84
          
+
          Section: 26 [numerics] Status: New
+ Submitter: Beman Dawes Opened: 2009-06-15  Last modified: 2009-06-15
          
+
          View other active issues in [numerics].
          
+
          View all other issues in [numerics].
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
+
          Addresses US 84
          
+
+
          
+The numerics chapter is not concept enabled.
+
          
+
+
          
+The portion of this comment dealing with random numbers was resolved by
+N2836,
+which was accepted in Summit.
+
          
+
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1141. Response to US 85
          
+
          Section: 27 [input.output] Status: New
+ Submitter: Beman Dawes Opened: 2009-06-15  Last modified: 2009-06-15
          
+
          View other active issues in [input.output].
          
+
          View all other issues in [input.output].
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
+
          Addresses US 85, JP 67, JP 68, JP 69, JP 72
          
+
+
          
+The input/output chapter is not concept enabled.
+
          
+
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1142. Response to US 86
          
+
          Section: 28 [re] Status: New
+ Submitter: Beman Dawes Opened: 2009-06-15  Last modified: 2009-06-15
          
+
          View other active issues in [re].
          
+
          View all other issues in [re].
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
+
          Addresses US 86, UK 309, UK 310
          
+
+
          
+The regular expressions chapter is not concept enabled.
+
          
+
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1143. Response to US 87
          
+
          Section: 29 [atomics] Status: New
+ Submitter: Beman Dawes Opened: 2009-06-15  Last modified: 2009-06-15
          
+
          View other active issues in [atomics].
          
+
          View all other issues in [atomics].
          
+
          View all issues with New status.
          
+
          Discussion:
          
+
+
          Addresses US 87, UK 311
          
+
+
          
+The atomics chapter is not concept enabled.
+
          
+
+
          
+Needs to also consider issues 923 and 924.
+
          
+
+
+
+
          Proposed resolution:
          
+
+
+
+
+
 
\ No newline at end of file
diff --git a/libstdc++-v3/doc/html/ext/lwg-closed.html b/libstdc++-v3/doc/html/ext/lwg-closed.html
index a056c3ee249..2f26c183fcb 100644
--- a/libstdc++-v3/doc/html/ext/lwg-closed.html
+++ b/libstdc++-v3/doc/html/ext/lwg-closed.html
@@ -14,11 +14,11 @@ del {background-color:#FFA0A0}
 
-
+
-
+
@@ -29,9 +29,9 @@ del {background-color:#FFA0A0}
 
          
 
          
 Doc. no.N2729=08-0239N2896=09-0086
 
          
 
          
 Date:2008-08-242009-06-21
 
          
 
          
 Project:Howard Hinnant <howard.hinnant@gmail.com>
 
          
 
          
-
          C++ Standard Library Closed Issues List (Revision R59)
          
+
          C++ Standard Library Closed Issues List (Revision R65)
          
 
-  
          Reference ISO/IEC IS 14882:1998(E)
          
+  
          Reference ISO/IEC IS 14882:2003(E)
          
   
          Also see:
          
     
          2. 
 
        2. Details:
            
-
          • Added the following New issues: 862, 863, 864, 865, 866, 867, 868, 869.
            • 
+
          • Added the following New issues: 862, 863, 864, 865, 866, 867, 868, 869.
            • 
 
          • Changed the following issues from Pending NAD Editorial to NAD Editorial: 393, 557, 592, 754, 757.
            • 
 
          • Changed the following issues from Pending WP to Open: 644.
            • 
-
          • Changed the following issues from WP to Ready: 387, 629.
            • 
-
          • Changed the following issues from Pending NAD Editorial to Review: 709.
            • 
+
          • Changed the following issues from WP to Ready: 387, 629.
            • 
+
          • Changed the following issues from Pending NAD Editorial to Review: 709.
            • 
 
          3. 
 
 
@@ -91,24 +233,24 @@ del {background-color:#FFA0A0}
 
 
        3. Details:
          4. 
 
 
@@ -121,7 +263,7 @@ del {background-color:#FFA0A0}
 
        4. 838 issues total, up by 25.
          5. 
 
 
        5. Details:
          6. 
 
@@ -137,8 +279,8 @@ del {background-color:#FFA0A0}
 
        6. Details:
          7. 
 
        7. Details:
          8. 
 
        8. Details:
          9. 
@@ -204,16 +346,16 @@ del {background-color:#FFA0A0}
 
        9. 754 issues total, up by 31.
          10. 
 
 
        10. Details:
          11. 
 
        11. Details:
          12. 
 
 
@@ -242,13 +384,13 @@ del {background-color:#FFA0A0}
 
        12. 708 issues total, up by 12.
          13. 
 
 
        13. Details:
            
-
          • Added the following New issues: 697, 698, 699, 700, 701, 702, 703, 704, 705, 706, 707, 708.
            • 
+
          • Added the following New issues: 697, 698, 699, 700, 701, 702, 703, 704, 705, 706, 707, 708.
            • 
 
          • Changed the following issues from New to NAD: 583, 584, 662.
            • 
 
          • Changed the following issues from Open to NAD: 528.
            • 
 
          • Changed the following issues from New to NAD Editorial: 637, 647, 658, 690.
            • 
 
          • Changed the following issues from Open to NAD Editorial: 525.
            • 
 
          • Changed the following issues from Pending NAD Editorial to NAD Editorial: 553, 571, 591, 633, 636, 641, 642, 648, 649, 656.
            • 
-
          • Changed the following issues from New to Open: 579, 631, 680.
            • 
+
          • Changed the following issues from New to Open: 579, 631, 680.
            • 
 
          • Changed the following issues from Pending WP to Open: 258.
            • 
 
          • Changed the following issues from Ready to Pending WP: 644.
            • 
 
          • Changed the following issues from New to Ready: 577, 660.
            • 
@@ -269,7 +411,7 @@ del {background-color:#FFA0A0}
 
          • 696 issues total, up by 20.
            • 
 
          14. 
 
        14. Details:
          15. 
 
        15. Details:
          16. 
 
        16. Details:
          17. 
 
@@ -331,7 +473,7 @@ del {background-color:#FFA0A0}
 
        17. 619 issues total, up by 10.
          18. 
 
 
        18. Details:
          19. 
 
 
@@ -347,10 +489,10 @@ del {background-color:#FFA0A0}
 
        19. Moved issues 520, 521, 530, 535, 537, 538, 540, 541 to WP.
          20. 
 
        20. Moved issues 504, 512, 516, 544, 549, 554, 555, 558 to NAD.
          21. 
 
        21. Moved issue 569 to Dup.
          22. 
-
        22. Moved issues 518, 523, 524, 542, 556, 557, 559, 597, 606 to Open.
          23. 
+
        23. Moved issues 518, 523, 524, 542, 556, 557, 559, 597, 606 to Open.
          24. 
 
        24. Moved issues 543, 545, 549, 549, 598 - 603, 605 to Ready.
          25. 
 
        25. Moved issues 531, 551, 604 to Review.
          26. 
-
        26. Added new issues 593-609.
          27. 
+
        27. Added new issues 593, 594, 595, 596, 597, 598, 599, 600, 601, 602, 603, 604, 605, 606, 607, 608, 609.
          28. 
 
 
 
@@ -363,7 +505,7 @@ del {background-color:#FFA0A0}
 
        28. 592 issues total, up by 5.
          29. 
 
 
        29. Details:
          30. 
 
 
@@ -376,7 +518,7 @@ del {background-color:#FFA0A0}
 
        30. 587 issues total, up by 13.
          31. 
 
 
        31. Details:
          32. 
@@ -391,9 +533,9 @@ del {background-color:#FFA0A0}
 
        32. 574 issues total, up by 8.
          33. 
 
 
        33. Details:
          34. 
 
        34. Details:
          35. 
@@ -424,7 +566,7 @@ del {background-color:#FFA0A0}
 
        35. 535 issues total.
          36. 
 
 
        36. Details:
          37. 
 
 
@@ -440,7 +582,7 @@ Moved issue 504-522.
+Merged open TR1 issues in 504-522.
 Added new issues 523-523
 
 
        37. R37: 
@@ -449,7 +591,7 @@ Added new issues 454 were moved to "DR" status, and all issues
+for 454 were moved to "DR" status, and all issues
 previously in "DR" status were moved to "WP".
 
          38. 
 
        38. R35: 
@@ -497,7 +639,7 @@ Pre-Oxford mailing.  Added new issues 253, which has been given a new proposed resolution, were
-moved to DR status.  Added new issues 383-389.  (Issues 387-389 were discussed
+moved to DR status.  Added new issues 383-389.  (Issues 387-389 were discussed
 at the meeting.)  Made progress on issues 225, 226, 229: 225 and 229 have been moved to Ready status, and the only remaining
 concerns with 226 involve wording.
 
          39. 
@@ -556,7 +698,7 @@ Changed status of issues
 to Ready.
 
 Closed issues 
-111 277 279 287
+111 277 279 287
 289 293 302 313
 314
 as NAD.
@@ -582,7 +724,7 @@ issues 209, 210, 211,
 212, 217, 220,
 222, 223, 224,
-227 to "DR".  Reopened issue 23. Reopened
+227 to "DR".  Reopened issue 23. Reopened
 issue 187. Changed issues 2 and
 4 to NAD. Fixed a typo in issue 17. Fixed
 issue 70: signature should be changed both places it
@@ -635,7 +777,7 @@ in Dublin. (99-0016/N1193, 21 Apr 99)
 pre-Dublin updated: Added issues 130, 131,
 132, 133, 134,
 135, 136, 137,
-138, 139 (31 Mar 99)
+138, 139 (31 Mar 99)
 
 
        39. R6: 
 pre-Dublin mailing. Added issues 127, 128,
@@ -648,7 +790,7 @@ for making list public. (30 Dec 98)
 
          40. 
 
        40. R4: 
 post-Santa Cruz II updated: Issues 110,
-111, 112, 113 added, several
+111, 112, 113 added, several
 issues corrected. (22 Oct 98)
 
          41. 
 
        41. R3: 
@@ -669,7 +811,7 @@ format, 2. Auto_ptr conversions effects incorrect
 
          Section: D.9.1.3 [auto.ptr.conv] Status: NAD
- Submitter: Nathan Myers Date: 1997-12-04
          
+ Submitter: Nathan Myers Opened: 1997-12-04  Last modified: 2006-12-29
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          Paragraph 1 in "Effects", says "Calls
@@ -680,7 +822,7 @@ exists.)
          
 
 
 
          Proposed resolution:
          
-
          Change 20.5.4.3 [meta.unary.prop] paragraph 1 Effects from 
+
          Change 20.6.4.3 [meta.unary.prop] paragraph 1 Effects from 
 "Calls p->release()" to "Calls p.release()".
          
 
 
@@ -694,15 +836,15 @@ exists.)
          
 
 
          
 
          4. Basic_string size_type and difference_type should be implementation defined
          
-
          Section: 21.3 [basic.string] Status: NAD
- Submitter: Beman Dawes Date: 1997-11-16
          
+
          Section: 21.4 [basic.string] Status: NAD
+ Submitter: Beman Dawes Opened: 1997-11-16  Last modified: 2006-12-27
          
 
          View other active issues in [basic.string].
          
 
          View all other issues in [basic.string].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          In Morristown we changed the size_type and difference_type typedefs
 for all the other containers to implementation defined with a
-reference to 23.1 [container.requirements].  This should probably also have been
+reference to 23.2 [container.requirements].  This should probably also have been
 done for strings. 
          
 
 
@@ -719,8 +861,8 @@ from implementation defined.
          
 
 
          
 
          6. File position not an offset unimplementable
          
-
          Section: 27.4.3 [fpos] Status: NAD
- Submitter: Matt Austern Date: 1997-12-15
          
+
          Section: 27.5.3 [fpos] Status: NAD
+ Submitter: Matt Austern Opened: 1997-12-15  Last modified: 2006-12-27
          
 
          View all other issues in [fpos].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -745,8 +887,8 @@ and that the above summary is what the Standard in effect says.
          
 
 
          
 
          10. Codecvt<>::do unclear
          
-
          Section: 22.2.1.5 [locale.codecvt.byname] Status: Dup
- Submitter: Matt Austern Date: 1998-01-14
          
+
          Section: 22.4.1.5 [locale.codecvt.byname] Status: Dup
+ Submitter: Matt Austern Opened: 1998-01-14  Last modified: 2006-12-30
          
 
          View all other issues in [locale.codecvt.byname].
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 19
          
@@ -769,8 +911,8 @@ intended here. 
          
 
 
          
 
          12. Way objects hold allocators unclear
          
-
          Section: 20.1.2 [allocator.requirements] Status: NAD
- Submitter: Angelika Langer Date: 1998-02-23
          
+
          Section: X [allocator.requirements] Status: NAD
+ Submitter: Angelika Langer Opened: 1998-02-23  Last modified: 2006-12-30
          
 
          View other active issues in [allocator.requirements].
          
 
          View all other issues in [allocator.requirements].
          
 
          View all issues with NAD status.
          
@@ -787,7 +929,7 @@ unspecified? 
          
 
 
          Rationale:
          
 
          Not a defect. The LWG believes that the Standard is already
-clear.  See 23.1 [container.requirements], paragraph 8.
          
+clear.  See 23.2 [container.requirements], paragraph 8.
          
 
 
 
@@ -795,8 +937,8 @@ clear.  See 23.1 [container.requirements], paragraph 8.
          
 
 
          
 
          43. Locale table correction
          
-
          Section: 22.2.1.5 [locale.codecvt.byname] Status: Dup
- Submitter: Brendan Kehoe Date: 1998-06-01
          
+
          Section: 22.4.1.5 [locale.codecvt.byname] Status: Dup
+ Submitter: Brendan Kehoe Opened: 1998-06-01  Last modified: 2006-12-30
          
 
          View all other issues in [locale.codecvt.byname].
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 33
          
@@ -812,14 +954,14 @@ clear.  See 23.1 [container.requirements], paragraph 8.
          
 
 
          
 
          45. Stringstreams read/write pointers initial position unclear
          
-
          Section: 27.7.3 [ostringstream] Status: NAD
- Submitter: Matthias Mueller Date: 1998-05-27
          
+
          Section: 27.8.3 [ostringstream] Status: NAD
+ Submitter: Matthias Mueller Opened: 1998-05-27  Last modified: 2006-12-27
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          In a comp.lang.c++.moderated Matthias Mueller wrote:
          
 
-
          "We are not sure how to interpret the CD2 (see 27.2
-[iostream.forward], 27.7.3.1 [ostringstream.cons], 27.7.1.1
+
          "We are not sure how to interpret the CD2 (see 27.3
+[iostream.forward], 27.8.3.1 [ostringstream.cons], 27.8.1.1
 [stringbuf.cons])
 with respect to the question as to what the correct initial positions
 of the write and  read pointers of a stringstream should
@@ -847,8 +989,8 @@ behavior is known to be different from strstreams.
          
 
 
          
 
          58. Extracting a char from a wide-oriented stream
          
-
          Section: 27.6.1.2.3 [istream::extractors] Status: NAD
- Submitter: Matt Austern Date: 1998-07-01
          
+
          Section: 27.7.1.2.3 [istream::extractors] Status: NAD
+ Submitter: Matt Austern Opened: 1998-07-01  Last modified: 2006-12-27
          
 
          View all other issues in [istream::extractors].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -873,7 +1015,7 @@ this is the intent of the LWG.
          
 
          
 
          65. Underspecification of strstreambuf::seekoff
          
 
          Section: D.7.1.3 [depr.strstreambuf.virtuals] Status: NAD
- Submitter: Matt Austern Date: 1998-08-18
          
+ Submitter: Matt Austern Opened: 1998-08-18  Last modified: 2006-12-27
          
 
          View all other issues in [depr.strstreambuf.virtuals].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -898,8 +1040,8 @@ to invest effort in this deprecated feature.
          
 
 
          
 
          67. Setw useless for strings
          
-
          Section: 21.3.8.9 [string.io] Status: Dup
- Submitter: Steve Clamage Date: 1998-07-09
          
+
          Section: 21.4.8.9 [string.io] Status: Dup
+ Submitter: Steve Clamage Opened: 1998-07-09  Last modified: 2006-12-30
          
 
          View all other issues in [string.io].
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 25
          
@@ -937,13 +1079,14 @@ parameters whatsoever.
          
 
 
          
 
          72. Do_convert phantom member function
          
-
          Section: 22.2.1.4 [locale.codecvt] Status: Dup
- Submitter: Nathan Myers Date: 1998-08-24
          
+
          Section: 22.4.1.4 [locale.codecvt] Status: Dup
+ Submitter: Nathan Myers Opened: 1998-08-24  Last modified: 2006-12-30
          
+
          View other active issues in [locale.codecvt].
          
 
          View all other issues in [locale.codecvt].
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 24
          
 
          Discussion:
          
-
          In 22.2.1.4 [locale.codecvt] par 3, and in 22.2.1.4.2 [locale.codecvt.virtuals] par 8, a nonexistent member function
+
          In 22.4.1.4 [locale.codecvt] par 3, and in 22.4.1.4.2 [locale.codecvt.virtuals] par 8, a nonexistent member function
 "do_convert" is mentioned. This member was replaced with
 "do_in" and "do_out", the proper referents in the
 contexts above.
          
@@ -957,8 +1100,8 @@ contexts above.
          
 
 
          
 
          73. is_open should be const
          
-
          Section: 27.8.1 [fstreams] Status: NAD
- Submitter: Matt Austern Date: 1998-08-27
          
+
          Section: 27.9.1 [fstreams] Status: NAD
+ Submitter: Matt Austern Opened: 1998-08-27  Last modified: 2006-12-27
          
 
          View all other issues in [fstreams].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -977,8 +1120,8 @@ meaningless.
          
 
 
          
 
          77. Valarray operator[] const returning value
          
-
          Section: 26.5.2.3 [valarray.access] Status: Dup
- Submitter: Levente Farkas Date: 1998-09-09
          
+
          Section: 26.6.2.3 [valarray.access] Status: Dup
+ Submitter: Levente Farkas Opened: 1998-09-09  Last modified: 2007-10-11
          
 
          View all other issues in [valarray.access].
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 389
          
@@ -1005,7 +1148,7 @@ One can't copy even from a const valarray eg:
          
 way. That is what valarray was designed to do; that's where the
 "value array" name comes from. LWG members further comment
 that "we don't want valarray to be a full STL container."
-26.5.2.3 [valarray.access] specifies properties that indicate "an
+26.6.2.3 [valarray.access] specifies properties that indicate "an
 absence of aliasing" for non-constant arrays; this allows
 optimizations, including special hardware optimizations, that are not
 otherwise possible. 
          
@@ -1016,8 +1159,8 @@ otherwise possible. 
          
 
 
          
 
          81. Wrong declaration of slice operations
          
-
          Section: 26.5.5 [template.slice.array], 26.5.7 [template.gslice.array], 26.5.8 [template.mask.array], 26.5.9 [template.indirect.array] Status: NAD
- Submitter: Nico Josuttis Date: 1998-09-29
          
+
          Section: 26.6.5 [template.slice.array], 26.6.7 [template.gslice.array], 26.6.8 [template.mask.array], 26.6.9 [template.indirect.array] Status: NAD
+ Submitter: Nico Josuttis Opened: 1998-09-29  Last modified: 2006-12-29
          
 
          View all other issues in [template.slice.array].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -1043,8 +1186,9 @@ otherwise possible. 
          
 
 
          
 
          82. Missing constant for set elements
          
-
          Section: 23.1.4 [associative.reqmts] Status: NAD
- Submitter: Nico Josuttis Date: 1998-09-29
          
+
          Section: 23.2.4 [associative.reqmts] Status: NAD
+ Submitter: Nico Josuttis Opened: 1998-09-29  Last modified: 2007-01-15
          
+
          View other active issues in [associative.reqmts].
          
 
          View all other issues in [associative.reqmts].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -1070,8 +1214,8 @@ issue.
          
 
 
          
 
          84. Ambiguity with string::insert()
          
-
          Section: 21.3.5 [string.access] Status: NAD
- Submitter: Nico Josuttis Date: 1998-09-29
          
+
          Section: 21.4.5 [string.access] Status: NAD
+ Submitter: Nico Josuttis Opened: 1998-09-29  Last modified: 2006-12-27
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          If I try
          
@@ -1103,7 +1247,7 @@ defect in the Standard as such .
          
 
          
 
          85. String char types
          
 
          Section: 21 [strings] Status: NAD
- Submitter: Nico Josuttis Date: 1998-09-29
          
+ Submitter: Nico Josuttis Opened: 1998-09-29  Last modified: 2006-12-27
          
 
          View all other issues in [strings].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -1113,7 +1257,7 @@ traits::char_type?
          
 
 
 
          Rationale:
          
-
          There is already wording in 21.1 [char.traits] paragraph 3 that
+
          There is already wording in 21.2 [char.traits] paragraph 3 that
 requires them to be the same.
          
 
 
@@ -1121,8 +1265,8 @@ requires them to be the same.
          
 
 
          
 
          87. Error in description of string::compare()
          
-
          Section: 21.3.6.8 [string::swap] Status: Dup
- Submitter: Nico Josuttis Date: 1998-09-29
          
+
          Section: 21.4.6.8 [string::swap] Status: Dup
+ Submitter: Nico Josuttis Opened: 1998-09-29  Last modified: 2006-12-30
          
 
          View all other issues in [string::swap].
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 5
          
@@ -1146,8 +1290,8 @@ exception) 
          
 
 
          
 
          88. Inconsistency between string::insert() and string::append()
          
-
          Section: 21.3.6.4 [string::insert], 21.3.6.2 [string::append] Status: NAD
- Submitter: Nico Josuttis Date: 1998-09-29
          
+
          Section: 21.4.6.4 [string::insert], 21.4.6.2 [string::append] Status: NAD
+ Submitter: Nico Josuttis Opened: 1998-09-29  Last modified: 2006-12-27
          
 
          View all other issues in [string::insert].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -1171,8 +1315,8 @@ serious to constitute a defect.
          
 
 
          
 
          89. Missing throw specification for string::insert() and string::replace()
          
-
          Section: 21.3.6.4 [string::insert], 21.3.6.6 [string::replace] Status: Dup
- Submitter: Nico Josuttis Date: 1998-09-29
          
+
          Section: 21.4.6.4 [string::insert], 21.4.6.6 [string::replace] Status: Dup
+ Submitter: Nico Josuttis Opened: 1998-09-29  Last modified: 2006-12-30
          
 
          View all other issues in [string::insert].
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 83
          
@@ -1193,8 +1337,8 @@ of issue 93. Incomplete Valarray Subset Definitions
-
          Section: 26.5 [numarray] Status: NAD
- Submitter: Nico Josuttis Date: 1998-09-29
          
+
          Section: 26.6 [numarray] Status: NAD
+ Submitter: Nico Josuttis Opened: 1998-09-29  Last modified: 2006-12-29
          
 
          View all other issues in [numarray].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -1230,8 +1374,8 @@ creates a temporary objects, which could be avoided without the cast. 
          
 
 
          
 
          94. May library implementors add template parameters to Standard Library classes?
          
-
          Section: 17.4.4 [conforming] Status: NAD
- Submitter: Matt Austern Date: 1998-01-22
          
+
          Section: 17.6.4 [conforming] Status: NAD
+ Submitter: Matt Austern Opened: 1998-01-22  Last modified: 2006-12-27
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          Is it a permitted extension for library implementors to add template parameters to
@@ -1275,7 +1419,7 @@ may be provided by a non-Standard implementation class:
          
 
 
 
          Proposed resolution:
          
-
          Add a new subclause [presumably 17.4.4.9] following 17.4.4.9 [res.on.exception.handling]:
          
+
          Add a new subclause [presumably 17.4.4.9] following 17.6.4.10 [res.on.exception.handling]:
          
 
 
          
   
          17.4.4.9 Template Parameters
           
          A specialization of a
@@ -1286,7 +1430,7 @@ may be provided by a non-Standard implementation class:
          
 
          
 
 
          Add "template parameters" to the list of subclauses at
-the end of 17.4.4 [conforming] paragraph 1.
          
+the end of 17.6.4 [conforming] paragraph 1.
          
 
 
          [Kona: The LWG agreed the standard needs clarification. After
 discussion with John Spicer, it seems added template parameters can be
@@ -1319,8 +1463,8 @@ of standard library class templates.
 
 
          
 
          95. Members added by the implementation
          
-
          Section: 17.4.4.4 [member.functions] Status: NAD
- Submitter: AFNOR Date: 1998-10-07
          
+
          Section: 17.6.4.5 [member.functions] Status: NAD
+ Submitter: AFNOR Opened: 1998-10-07  Last modified: 2006-12-27
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          In 17.3.4.4/2 vs 17.3.4.7/0 there is a hole; an implementation could add virtual
@@ -1351,7 +1495,7 @@ class vector_checking : public vector
 
 
          Rationale:
          
 
          This is not a defect in the Standard.  The example is already
-illegal.  See 17.4.4.4 [member.functions] paragraph 2.
          
+illegal.  See 17.6.4.5 [member.functions] paragraph 2.
          
 
 
 
@@ -1359,7 +1503,7 @@ illegal.  See 17.4.4.4 [member.functions] paragraph 2.
          
 
          
 
          97. Insert inconsistent definition
          
 
          Section: 23 [containers] Status: NAD
- Submitter: AFNOR Date: 1998-10-07
          
+ Submitter: AFNOR Opened: 1998-10-07  Last modified: 2006-12-27
          
 
          View other active issues in [containers].
          
 
          View all other issues in [containers].
          
 
          View all issues with NAD status.
          
@@ -1379,8 +1523,8 @@ the design, for better or for worse.
          
 
 
          
 
          99. Reverse_iterator comparisons completely wrong
          
-
          Section: 24.4.1.3.13 [reverse.iter.op==] Status: NAD
- Submitter: AFNOR Date: 1998-10-07
          
+
          Section: 24.5.1.2.13 [reverse.iter.op==] Status: NAD
+ Submitter: AFNOR Opened: 1998-10-07  Last modified: 2006-12-27
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          The <, >, <=, >= comparison operator are wrong: they
@@ -1401,8 +1545,10 @@ exactly what the Standard says.
          
 
 
          
 
          100. Insert iterators/ostream_iterators overconstrained
          
-
          Section: 24.4.2 [insert.iterators], 24.5.4 [ostreambuf.iterator] Status: NAD
- Submitter: AFNOR Date: 1998-10-07
          
+
          Section: 24.7 [insert.iterators], 24.6.4 [ostreambuf.iterator] Status: NAD
+ Submitter: AFNOR Opened: 1998-10-07  Last modified: 2006-12-27
          
+
          View other active issues in [insert.iterators].
          
+
          View all other issues in [insert.iterators].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          Overspecified For an insert iterator it, the expression *it is
@@ -1422,8 +1568,8 @@ incorrect code to work, rather than the other way around.
          
 
 
          
 
          101. No way to free storage for vector and deque
          
-
          Section: 23.2.6 [vector], 23.2.1 [array] Status: NAD
- Submitter: AFNOR Date: 1998-10-07
          
+
          Section: 23.3.6 [vector], 23.3.1 [array] Status: NAD
+ Submitter: AFNOR Opened: 1998-10-07  Last modified: 2007-02-19
          
 
          View all other issues in [vector].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -1448,8 +1594,9 @@ expressed in a single line of code (where v is
 
 
          
 
          102. Bug in insert range in associative containers
          
-
          Section: 23.1.4 [associative.reqmts] Status: Dup
- Submitter: AFNOR Date: 1998-10-07
          
+
          Section: 23.2.4 [associative.reqmts] Status: Dup
+ Submitter: AFNOR Opened: 1998-10-07  Last modified: 2006-12-30
          
+
          View other active issues in [associative.reqmts].
          
 
          View all other issues in [associative.reqmts].
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 264
          
@@ -1472,8 +1619,8 @@ container is O(1)!
          
 
 
          
 
          104. Description of basic_string::operator[] is unclear
          
-
          Section: 21.3.4 [string.capacity] Status: NAD
- Submitter: AFNOR Date: 1998-10-07
          
+
          Section: 21.4.4 [string.capacity] Status: NAD
+ Submitter: AFNOR Opened: 1998-10-07  Last modified: 2006-12-27
          
 
          View all other issues in [string.capacity].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -1495,10 +1642,10 @@ the Standard.
          
 
 
          
 
          105. fstream ctors argument types desired
          
-
          Section: 27.8 [file.streams] Status: Dup
- Submitter: AFNOR Date: 1998-10-07
          
+
          Section: 27.9 [file.streams] Status: Dup
+ Submitter: AFNOR Opened: 1998-10-07  Last modified: 2008-01-05
          
 
          View all issues with Dup status.
          
-
          Duplicate of: 454
          
+
          Duplicate of: 454
          
 
          Discussion:
          
 
 
@@ -1518,8 +1665,8 @@ interesting extension for the next Standard. 
          
 
 
          
 
          107. Valarray constructor is strange
          
-
          Section: 26.5.2 [template.valarray] Status: NAD
- Submitter: AFNOR Date: 1998-10-07
          
+
          Section: 26.6.2 [template.valarray] Status: NAD
+ Submitter: AFNOR Opened: 1998-10-07  Last modified: 2006-12-29
          
 
          View all other issues in [template.valarray].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -1546,61 +1693,10 @@ perhaps other cases.
          
 
 
 
-
          
-
          111. istreambuf_iterator::equal overspecified, inefficient
          
-
          Section: 24.5.3.5 [istreambuf.iterator::equal] Status: NAD Future
- Submitter: Nathan Myers Date: 1998-10-15
          
-
          View all issues with NAD Future status.
          
-
          Discussion:
          
-
          The member istreambuf_iterator<>::equal is specified to be
-unnecessarily inefficient. While this does not affect the efficiency
-of conforming implementations of iostreams, because they can
-"reach into" the iterators and bypass this function, it does
-affect users who use istreambuf_iterators. 
          
-
-
          The inefficiency results from a too-scrupulous definition, which
-requires a "true" result if neither iterator is at eof. In
-practice these iterators can only usefully be compared with the
-"eof" value, so the extra test implied provides no benefit,
-but slows down users' code. 
          
-
-
          The solution is to weaken the requirement on the function to return
-true only if both iterators are at eof. 
          
-
-
-
          Proposed resolution:
          
-
          Replace 24.5.3.5 [istreambuf.iterator::equal],
-paragraph 1, 
          
-
-
          
-  
          -1- Returns: true if and only if both iterators are at end-of-stream, or neither is at
-  end-of-stream, regardless of what streambuf object they use. 
          
-
          
-
-
          with
          
-
-
          
-  
          -1- Returns: true if and only if both iterators are at
-  end-of-stream, regardless of what streambuf object they use. 
          
-
          
-
-
-
-
          Rationale:
          
-
          It is not clear that this is a genuine defect.  Additionally, the
-LWG was reluctant to make a change that would result in 
-operator== not being a equivalence relation.  One consequence of
-this change is that an algorithm that's passed the range [i, i)
-would no longer treat it as an empty range.
          
-
-
-
-
-
 
          
 
          113. Missing/extra iostream sync semantics
          
-
          Section: 27.6.1.1 [istream], 27.6.1.3 [istream.unformatted] Status: NAD
- Submitter: Steve Clamage Date: 1998-10-13
          
+
          Section: 27.7.1.1 [istream], 27.7.1.3 [istream.unformatted] Status: NAD
+ Submitter: Steve Clamage Opened: 1998-10-13  Last modified: 2006-12-27
          
 
          View all other issues in [istream].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -1638,8 +1734,9 @@ desired functionality.
          
 
 
          
 
          116. bitset cannot be constructed with a const char*
          
-
          Section: 23.3.5 [template.bitset] Status: Dup
- Submitter: Judy Ward Date: 1998-11-06
          
+
          Section: 20.3.6 [template.bitset] Status: Dup
+ Submitter: Judy Ward Opened: 1998-11-06  Last modified: 2008-03-14
          
+
          View other active issues in [template.bitset].
          
 
          View all other issues in [template.bitset].
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 778
          
@@ -1683,13 +1780,13 @@ longer work.
          
 
 
 
          Proposed resolution:
          
-
          Add to 23.3.5 [template.bitset] a bitset constructor declaration
          
+
          Add to 20.3.6 [template.bitset] a bitset constructor declaration
          
 
 
          
   
          explicit bitset(const char*);
          
 
          
 
-
          and in Section 23.3.5.1 [bitset.cons] add:
          
+
          and in Section 20.3.6.1 [bitset.cons] add:
          
 
 
          
   
          explicit bitset(const char* str);
          
@@ -1710,15 +1807,15 @@ extension.
          
 
 
          
 
          121. Detailed definition for ctype<wchar_t> specialization
          
-
          Section: 22.1.1.1.1 [locale.category] Status: NAD
- Submitter: Judy Ward Date: 1998-12-15
          
+
          Section: 22.3.1.1.1 [locale.category] Status: NAD
+ Submitter: Judy Ward Opened: 1998-12-15  Last modified: 2006-12-27
          
 
          View all other issues in [locale.category].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          Section 22.1.1.1.1 has the following listed in Table 51: ctype<char> ,
 ctype<wchar_t>. 
          
 
-
          Also Section 22.2.1.1 [locale.ctype] says: 
          
+
          Also Section 22.4.1.1 [locale.ctype] says: 
          
 
 
          
   
          The instantiations required in Table 51 (22.1.1.1.1) namely ctype<char> and
@@ -1726,14 +1823,14 @@ ctype<wchar_t>. 
          
   native character set. 
          
 
          
 
-
          However, Section 22.2.1.3 [facet.ctype.special]
+
          However, Section 22.4.1.3 [facet.ctype.special]
 only has a detailed description of the ctype<char> specialization, not the
 ctype<wchar_t> specialization. 
          
 
 
 
          Proposed resolution:
          
 
          Add the ctype<wchar_t> detailed class description to Section 
-22.2.1.3 [facet.ctype.special]. 
          
+22.4.1.3 [facet.ctype.special]. 
          
 
 
 
          Rationale:
          
@@ -1745,8 +1842,8 @@ ctype<wchar_t> specialization. 
          
 
 
          
 
          131. list::splice throws nothing
          
-
          Section: 23.2.4.4 [list.ops] Status: NAD
- Submitter: Howard Hinnant Date: 1999-03-06
          
+
          Section: 23.3.4.4 [list.ops] Status: NAD
+ Submitter: Howard Hinnant Opened: 1999-03-06  Last modified: 2007-02-19
          
 
          View all other issues in [list.ops].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -1763,8 +1860,8 @@ beyond max_size()?
          
 
 
          
 
          135. basic_iostream doubly initialized
          
-
          Section: 27.6.1.5.1 [iostream.cons] Status: NAD
- Submitter: Howard Hinnant Date: 1999-03-06
          
+
          Section: 27.7.1.5.1 [iostream.cons] Status: NAD
+ Submitter: Howard Hinnant Opened: 1999-03-06  Last modified: 2006-12-27
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          -1- Effects Constructs an object of class basic_iostream, assigning
@@ -1793,52 +1890,15 @@ standard.
          
 
 
 
-
          
-
          138. Class ctype_byname<char> redundant and misleading
          
-
          Section: 22.2.1.4 [locale.codecvt] Status: NAD Future
- Submitter: Angelika Langer Date: 1999-03-18
          
-
          View all other issues in [locale.codecvt].
          
-
          View all issues with NAD Future status.
          
-
          Discussion:
          
-
          Section 22.2.1.4 [locale.codecvt] specifies that
-ctype_byname<char> must be a specialization of the ctype_byname
-template.
          
-
-
          It is common practice in the standard that specializations of class templates are only
-mentioned where the interface of the specialization deviates from the interface of the
-template that it is a specialization of. Otherwise, the fact whether or not a required
-instantiation is an actual instantiation or a specialization is left open as an
-implementation detail. 
          
-
-
          Clause 22.2.1.4 deviates from that practice and for that reason is misleading. The
-fact, that ctype_byname<char> is specified as a specialization suggests that there
-must be something "special" about it, but it has the exact same interface as the
-ctype_byname template. Clause 22.2.1.4 does not have any explanatory value, is at best
-redundant, at worst misleading - unless I am missing anything. 
          
-
-
          Naturally, an implementation will most likely implement ctype_byname<char> as a
-specialization, because the base class ctype<char> is a specialization with an
-interface different from the ctype template, but that's an implementation detail and need
-not be mentioned in the standard. 
          
-
-
-
          Rationale:
          
-
           The standard as written is mildly misleading, but the correct fix
-is to deal with the underlying problem in the ctype_byname base class,
-not in the specialization. See issue 228.
          
-
-
-
-
 
          
 
          140. map<Key, T>::value_type does not satisfy the assignable requirement
          
-
          Section: 23.3.1 [map] Status: NAD Editorial
- Submitter: Mark Mitchell Date: 1999-04-14
          
+
          Section: 23.4.1 [map] Status: NAD Editorial
+ Submitter: Mark Mitchell Opened: 1999-04-14  Last modified: 2008-03-14
          
 
          View all other issues in [map].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
 
          
-  
          23.1 [container.requirements]
          
+  
          23.2 [container.requirements]
          
   
          
   expression         return type
        pre/post-condition
          
@@ -1848,7 +1908,7 @@ not in the specialization. See issue 143. C .h header wording unclear
 
          Section: D.5 [depr.c.headers] Status: NAD
- Submitter: Christophe de Dinechin Date: 1999-05-04
          
+ Submitter: Christophe de Dinechin Opened: 1999-05-04  Last modified: 2006-12-27
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          [depr.c.headers] paragraph 2 reads:
          
@@ -1987,8 +2047,8 @@ write code that depends on Koenig lookup of C library functions.
          
 
 
          
 
          145. adjustfield lacks default value
          
-
          Section: 27.4.4.1 [basic.ios.cons] Status: NAD
- Submitter: Angelika Langer Date: 1999-05-12
          
+
          Section: 27.5.4.1 [basic.ios.cons] Status: NAD
+ Submitter: Angelika Langer Opened: 1999-05-12  Last modified: 2006-12-27
          
 
          View all other issues in [basic.ios.cons].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -2014,93 +2074,20 @@ everybody expects anyway.
          
 
 
          Rationale:
          
 
          This is not a defect. It is deliberate that the default is no bits
-set. Consider Arabic or Hebrew, for example. See 22.2.2.2.2 [facet.num.put.virtuals] paragraph 19, Table 61 - Fill padding.
          
-
-
-
-
-
          
-
          149. Insert should return iterator to first element inserted
          
-
          Section: 23.1.3 [sequence.reqmts] Status: NAD Future
- Submitter: Andrew Koenig Date: 1999-06-28
          
-
          View all other issues in [sequence.reqmts].
          
-
          View all issues with NAD Future status.
          
-
          Discussion:
          
-
          Suppose that c and c1 are sequential containers and i is an
-iterator that refers to an element of c.  Then I can insert a copy of
-c1's elements into c ahead of element i by executing 
          
-
-
          
-
-
          c.insert(i, c1.begin(), c1.end());
          
-
-
          
-
-
          If c is a vector, it is fairly easy for me to find out where the
-newly inserted elements are, even though i is now invalid: 
          
-
-
          
-
-
          size_t i_loc = i - c.begin();
-c.insert(i, c1.begin(), c1.end());
          
-
-
          
-
-
          and now the first inserted element is at c.begin()+i_loc and one
-past the last is at c.begin()+i_loc+c1.size().
          
-
          
-But what if c is a list? I can still find the location of one past the
-last inserted element, because i is still valid. To find the location
-of the first inserted element, though, I must execute something like 
          
-
-
          
-
-
          for (size_t n = c1.size(); n; --n)
-   --i;
          
-
-
          
-
-
          because i is now no longer a random-access iterator.
          
-
          
-Alternatively, I might write something like 
          
-
-
          
-
-
          bool first = i == c.begin();
-list<T>::iterator j = i;
-if (!first) --j;
-c.insert(i, c1.begin(), c1.end());
-if (first)
-   j = c.begin();
-else
-   ++j;
          
-
-
          
-
-
          which, although wretched, requires less overhead.
          
-
          
-But I think the right solution is to change the definition of insert
-so that instead of returning void, it returns an iterator that refers
-to the first element inserted, if any, and otherwise is a copy of its
-first argument.  
          
-
-
-
          Rationale:
          
-
          The LWG believes this was an intentional design decision and so is
-not a defect. It may be worth revisiting for the next standard.
          
+set. Consider Arabic or Hebrew, for example. See 22.4.2.2.2 [facet.num.put.virtuals] paragraph 19, Table 61 - Fill padding.
          
 
 
 
 
 
          
 
          157. Meaningless error handling for pword() and iword()
          
-
          Section: 27.4.2.5 [ios.base.storage] Status: Dup
- Submitter: Dietmar Kühl Date: 1999-07-20
          
+
          Section: 27.5.2.5 [ios.base.storage] Status: Dup
+ Submitter: Dietmar Kühl Opened: 1999-07-20  Last modified: 2007-01-15
          
 
          View all other issues in [ios.base.storage].
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 41
          
 
          Discussion:
          
-
          According to paragraphs 2 and 4 of 27.4.2.5 [ios.base.storage], the
+
          According to paragraphs 2 and 4 of 27.5.2.5 [ios.base.storage], the
 functions iword() and pword() "set the
 badbit (which might throw an exception)" on
 failure. ... but what does it mean for ios_base to set the
@@ -2118,8 +2105,8 @@ character type used...
          
 
 
          
 
          162. Really "formatted input functions"?
          
-
          Section: 27.6.1.2.3 [istream::extractors] Status: Dup
- Submitter: Dietmar Kühl Date: 1999-07-20
          
+
          Section: 27.7.1.2.3 [istream::extractors] Status: Dup
+ Submitter: Dietmar Kühl Opened: 1999-07-20  Last modified: 2007-01-15
          
 
          View all other issues in [istream::extractors].
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 60
          
@@ -2129,7 +2116,7 @@ defined in the paragraphs 1 to 5 to be "Formatted input
 function" but since these functions are defined in a section
 labeled "Formatted input functions" it is unclear to me
 whether these operators are considered formatted input functions which
-have to conform to the "common requirements" from 27.6.1.2.1
+have to conform to the "common requirements" from 27.7.1.2.1
 [istream.formatted.reqmts]: If this is the case, all manipulators, not
 just
 ws, would skip whitespace unless noskipws is set
@@ -2148,14 +2135,14 @@ output
          
 
 
          
 
          163. Return of gcount() after a call to gcount
          
-
          Section: 27.6.1.3 [istream.unformatted] Status: Dup
- Submitter: Dietmar Kühl Date: 1999-07-20
          
+
          Section: 27.7.1.3 [istream.unformatted] Status: Dup
+ Submitter: Dietmar Kühl Opened: 1999-07-20  Last modified: 2007-01-15
          
 
          View all other issues in [istream.unformatted].
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 60
          
 
          Discussion:
          
 
          It is not clear which functions are to be considered unformatted
-input functions. As written, it seems that all functions in 27.6.1.3
+input functions. As written, it seems that all functions in 27.7.1.3
 [istream.unformatted] are unformatted input functions. However, it does
 not
 really make much sense to construct a sentry object for
@@ -2183,13 +2170,13 @@ clarification should be used.
          
 
 
          
 
          166. Really "formatted output functions"?
          
-
          Section: 27.6.2.6.3 [ostream.inserters] Status: Dup
- Submitter: Dietmar Kühl Date: 1999-07-20
          
+
          Section: 27.7.2.6.3 [ostream.inserters] Status: Dup
+ Submitter: Dietmar Kühl Opened: 1999-07-20  Last modified: 2007-01-15
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 60
          
 
          Discussion:
          
-
          From 27.6.2.6.1 [ostream.formatted.reqmts] it appears that all the functions
-defined in 27.6.2.6.3 [ostream.inserters] have to construct a
+
          From 27.7.2.6.1 [ostream.formatted.reqmts] it appears that all the functions
+defined in 27.7.2.6.3 [ostream.inserters] have to construct a
 sentry object. Is this really intended?
           
 
 
          This is basically the same problem as issue 162 but
@@ -2204,8 +2191,8 @@ for output instead of input.
          
 
 
          
 
          177. Complex operators cannot be explicitly instantiated
          
-
          Section: 26.3.6 [complex.ops] Status: NAD
- Submitter: Judy Ward Date: 1999-07-02
          
+
          Section: 26.4.6 [complex.ops] Status: NAD
+ Submitter: Judy Ward Opened: 1999-07-02  Last modified: 2006-12-27
          
 
          View all other issues in [complex.ops].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -2261,8 +2248,8 @@ syntax.
          
 
 
          
 
          178. Should clog and cerr initially be tied to cout?
          
-
          Section: 27.3.1 [narrow.stream.objects] Status: NAD
- Submitter: Judy Ward Date: 1999-07-02
          
+
          Section: 27.4.1 [narrow.stream.objects] Status: NAD
+ Submitter: Judy Ward Opened: 1999-07-02  Last modified: 2006-12-27
          
 
          View all other issues in [narrow.stream.objects].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -2294,8 +2281,8 @@ ios_base::init to basic_ios::init().)
          
 
 
          
 
          188. valarray helpers missing augmented assignment operators
          
-
          Section: 26.5.2.6 [valarray.cassign] Status: NAD
- Submitter: Gabriel Dos Reis Date: 1999-08-15
          
+
          Section: 26.6.2.6 [valarray.cassign] Status: NAD
+ Submitter: Gabriel Dos Reis Opened: 1999-08-15  Last modified: 2008-03-11
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          26.5.2.6 defines augmented assignment operators
@@ -2331,8 +2318,8 @@ operators.
          
 
 
          
 
          191. Unclear complexity for algorithms such as binary search
          
-
          Section: 25.3.3 [alg.binary.search] Status: NAD
- Submitter: Nico Josuttis Date: 1999-10-10
          
+
          Section: 25.5.3 [alg.binary.search] Status: NAD
+ Submitter: Nico Josuttis Opened: 1999-10-10  Last modified: 2006-12-27
          
 
          View all other issues in [alg.binary.search].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -2360,8 +2347,9 @@ iterators.
          
 
 
          
 
          192. a.insert(p,t) is inefficient and overconstrained
          
-
          Section: 23.1.4 [associative.reqmts] Status: NAD
- Submitter: Ed Brey Date: 1999-06-06
          
+
          Section: 23.2.4 [associative.reqmts] Status: NAD
+ Submitter: Ed Brey Opened: 1999-06-06  Last modified: 2006-12-30
          
+
          View other active issues in [associative.reqmts].
          
 
          View all other issues in [associative.reqmts].
          
 
          View all issues with NAD status.
          
 
          Duplicate of: 233
          
@@ -2406,7 +2394,7 @@ providing no disadvantage to the container implementation.
          
 
 
 
          Proposed resolution:
          
-
          In 23.1.4 [associative.reqmts] paragraph 7, replace the row in table 69
+
          In 23.2.4 [associative.reqmts] paragraph 7, replace the row in table 69
 for a.insert(p,t) with the following two rows:
          
 
@@ -2447,8 +2435,8 @@ both before p and after p, and don't want to change this behavior.
          194. rdbuf() functions poorly specified
          
-
          Section: 27.4.4 [ios] Status: NAD
- Submitter: Steve Clamage Date: 1999-09-07
          
+
          Section: 27.5.4 [ios] Status: NAD
+ Submitter: Steve Clamage Opened: 1999-09-07  Last modified: 2006-12-27
          View all issues with NAD status.
          Discussion:
          In classic iostreams, base class ios had an rdbuf function that returned a
@@ -2493,20 +2481,20 @@ class  rdbuf() always returns the original streambuf, whereas the base
  rdbuf() will return the "current streambuf" if that has been changed by the variant you mention.
          Permission is not required to add such an extension.  See 
-17.4.4.4 [member.functions].
          
+17.6.4.5 [member.functions].
          196. Placement new example has alignment problems
          
-
          Section: 18.5.1.3 [new.delete.placement] Status: Dup
- Submitter: Herb Sutter Date: 1998-12-15
          
+
          Section: 18.6.1.3 [new.delete.placement] Status: Dup
+ Submitter: Herb Sutter Opened: 1998-12-15  Last modified: 2006-12-30
          View all other issues in [new.delete.placement].
          View all issues with Dup status.
          Duplicate of: 114
          Discussion:
          
-
          The example in 18.5.1.3 [new.delete.placement] paragraph 4 reads: 
          
+
          The example in 18.6.1.3 [new.delete.placement] paragraph 4 reads: 
          
 
@@ -2530,8 +2518,8 @@ class  rdbuf() always returns the original streambuf, whereas the base
 
 
          
 
          197. max_size() underspecified
          
-
          Section: 20.1.2 [allocator.requirements], 23.1 [container.requirements] Status: NAD
- Submitter: Andy Sawyer Date: 1999-10-21
          
+
          Section: X [allocator.requirements], 23.2 [container.requirements] Status: NAD
+ Submitter: Andy Sawyer Opened: 1999-10-21  Last modified: 2006-12-30
          
 
          View other active issues in [allocator.requirements].
          
 
          View all other issues in [allocator.requirements].
          
 
          View all issues with NAD status.
          
@@ -2587,8 +2575,8 @@ called. 
          
 
 
          
 
          203. basic_istream::sentry::sentry() is uninstantiable with ctype<user-defined type>
          
-
          Section: 27.6.1.1.3 [istream::sentry] Status: NAD
- Submitter: Matt McClure and Dietmar Kühl Date: 2000-01-01
          
+
          Section: 27.7.1.1.3 [istream::sentry] Status: NAD
+ Submitter: Matt McClure and Dietmar Kühl Opened: 2000-01-01  Last modified: 2007-01-15
          
 
          View all other issues in [istream::sentry].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -2646,8 +2634,10 @@ and is not a defect.
          
 
 
          
 
          204. distance(first, last) when "last" is before "first"
          
-
          Section: 24.3.4 [iterator.operations] Status: NAD
- Submitter: Rintala Matti Date: 2000-01-28
          
+
          Section: 24.4 [iterator.operations] Status: NAD
+ Submitter: Rintala Matti Opened: 2000-01-28  Last modified: 2008-09-30
          
+
          View other active issues in [iterator.operations].
          
+
          View all other issues in [iterator.operations].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          Section 24.3.4 describes the function distance(first, last) (where first and
@@ -2680,7 +2670,7 @@ category?
          
 
 
 
          Rationale:
          
-
          "Reachable" is defined in the standard in 24.1 [iterator.requirements] paragraph 6.
+
          "Reachable" is defined in the standard in 24.2 [iterator.concepts] paragraph 6.
 The definition is only in terms of operator++(). The LWG sees no defect in
 the standard.
          
 
@@ -2689,17 +2679,17 @@ the standard.
          
 
 
          
 
          205.  numeric_limits unclear on how to determine floating point types
          
-
          Section: 18.2.1.2 [numeric.limits.members] Status: NAD
- Submitter: Steve Cleary Date: 2000-01-28
          
+
          Section: 18.3.1.2 [numeric.limits.members] Status: NAD
+ Submitter: Steve Cleary Opened: 2000-01-28  Last modified: 2006-12-27
          
 
          View all other issues in [numeric.limits.members].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
-
          In several places in 18.2.1.2 [numeric.limits.members], a member is
+
          In several places in 18.3.1.2 [numeric.limits.members], a member is
 described as "Meaningful for all floating point types."
 However, no clear method of determining a floating point type is
 provided.
          
 
-
          In 18.2.1.5 [numeric.special], paragraph 1 states ". . . (for
+
          In 18.3.1.5 [numeric.special], paragraph 1 states ". . . (for
 example, epsilon() is only meaningful if is_integer is
 false). . ." which suggests that a type is a floating point type
 if is_specialized is true and is_integer is false; however, this is
@@ -2721,8 +2711,8 @@ floating point type.
          
 
 
          
 
          207. ctype<char> members return clause incomplete
          
-
          Section: 22.2.1.3.2 [facet.ctype.char.members] Status: Dup
- Submitter: Robert Klarer Date: 1999-11-02
          
+
          Section: 22.4.1.3.2 [facet.ctype.char.members] Status: Dup
+ Submitter: Robert Klarer Opened: 1999-11-02  Last modified: 2006-12-30
          
 
          View all other issues in [facet.ctype.char.members].
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 153
          
@@ -2736,7 +2726,7 @@ clause only describes one of the overloads.
 
 
 
          Proposed resolution:
          
-
          Change the returns clause in 22.2.1.3.2 [facet.ctype.char.members]
+
          Change the returns clause in 22.4.1.3.2 [facet.ctype.char.members]
 paragraph 10 from:
          
 
              Returns: do_widen(low, high, to).
          
 
@@ -2744,7 +2734,7 @@ paragraph 10 from:
          
 
              Returns: do_widen(c) or do_widen(low, high, to), 
 respectively.
          
 
-
          Change the returns clause in 22.2.1.3.2 [facet.ctype.char.members] paragraph 11
+
          Change the returns clause in 22.4.1.3.2 [facet.ctype.char.members] paragraph 11
 from:
           
 
              Returns: do_narrow(low, high, to).
          
 
@@ -2764,8 +2754,8 @@ paragraphs.
          
 
 
          
 
          213. Math function overloads ambiguous
          
-
          Section: 26.7 [c.math] Status: NAD
- Submitter: Nico Josuttis Date: 2000-02-26
          
+
          Section: 26.8 [c.math] Status: NAD
+ Submitter: Nico Josuttis Opened: 2000-02-26  Last modified: 2006-12-29
          
 
          View all other issues in [c.math].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -2790,8 +2780,9 @@ or write floating point expressions as arguments.
          
 
 
          
 
          215. Can a map's key_type be const?
          
-
          Section: 23.1.4 [associative.reqmts] Status: NAD
- Submitter: Judy Ward Date: 2000-02-29
          
+
          Section: 23.2.4 [associative.reqmts] Status: NAD
+ Submitter: Judy Ward Opened: 2000-02-29  Last modified: 2006-12-27
          
+
          View other active issues in [associative.reqmts].
          
 
          View all other issues in [associative.reqmts].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -2815,20 +2806,20 @@ too.
          
 
 
          Rationale:
          
 
          The "key is assignable" requirement from table 69 in
-23.1.4 [associative.reqmts] already implies the key cannot be const.
          
+23.2.4 [associative.reqmts] already implies the key cannot be const.
          
 
 
 
 
 
          
 
          216. setbase manipulator description flawed
          
-
          Section: 27.6.3 [std.manip] Status: Dup
- Submitter: Hyman Rosen Date: 2000-02-29
          
+
          Section: 27.7.3 [std.manip] Status: Dup
+ Submitter: Hyman Rosen Opened: 2000-02-29  Last modified: 2006-12-30
          
 
          View all other issues in [std.manip].
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 193
          
 
          Discussion:
          
-
          27.6.3 [std.manip] paragraph 5 says:
          
+
          27.7.3 [std.manip] paragraph 5 says:
          
 
          
 
          smanip setbase(int base);
          
 
           Returns: An object s of unspecified type such that if out is an
@@ -2873,8 +2864,8 @@ occurs additional places in the section, all requiring fixes.]
          
 
 
          
 
          218. Algorithms do not use binary predicate objects for default comparisons
          
-
          Section: 25.3 [alg.sorting] Status: NAD
- Submitter: Pablo Halpern Date: 2000-03-06
          
+
          Section: 25.5 [alg.sorting] Status: NAD
+ Submitter: Pablo Halpern Opened: 2000-03-06  Last modified: 2006-12-27
          
 
          View all other issues in [alg.sorting].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -2907,66 +2898,19 @@ operator<.
          
 
 
 
-
          
-
          219. find algorithm missing version that takes a binary predicate argument
          
-
          Section: 25.1.5 [alg.find] Status: NAD Future
- Submitter: Pablo Halpern Date: 2000-03-06
          
-
          View all other issues in [alg.find].
          
-
          View all issues with NAD Future status.
          
-
          Discussion:
          
-
          The find function always searches for a value using operator== to compare the
-value argument to each element in the input iterator range. This is inconsistent
-with other find-related functions such as find_end and find_first_of, which
-allow the caller to specify a binary predicate object to be used for determining
-equality. The fact that this can be accomplished using a combination of find_if
-and bind_1st or bind_2nd does not negate the desirability of a consistent,
-simple, alternative interface to find.
          
-
-
-
          Proposed resolution:
          
-
          
-
          In section 25.1.5 [alg.find], add a second prototype for find
-(between the existing prototype and the prototype for find_if), as
-follows:
          
-
              template<class InputIterator, class T, class BinaryPredicate>
-      InputIterator find(InputIterator first, InputIterator last,
-                         const T& value, BinaryPredicate bin_pred);
          
-
          Change the description of the return from:
          
-
          
-  
          Returns: The first iterator i in the range [first, last) for which the following corresponding
-  conditions hold: *i == value, pred(*i) != false. Returns last if no such iterator is found.
          
-
          
-
           to:
          
-
          
-  
          Returns: The first iterator i in the range [first, last) for which the following 
-  corresponding condition holds: *i == value, bin_pred(*i,value) != false, pred(*)
-  != false. Return last if no such iterator is found.
          
-
          
-
          
-
-
-
          Rationale:
          
-
          This is request for a pure extension, so it is not a defect in the
-current standard.  As the submitter pointed out, "this can
-be accomplished using a combination of find_if and bind_1st or
-bind_2nd".
          
-
-
-
-
 
          
 
          236. ctype<char>::is() member modifies facet
          
-
          Section: 22.2.1.3.2 [facet.ctype.char.members] Status: Dup
- Submitter: Dietmar Kühl Date: 2000-04-24
          
+
          Section: 22.4.1.3.2 [facet.ctype.char.members] Status: Dup
+ Submitter: Dietmar Kühl Opened: 2000-04-24  Last modified: 2007-01-15
          
 
          View all other issues in [facet.ctype.char.members].
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 28
          
 
          Discussion:
          
-
          The description of the is() member in paragraph 4 of 22.2.1.3.2 [facet.ctype.char.members] is broken: According to this description, the
+
          The description of the is() member in paragraph 4 of 22.4.1.3.2 [facet.ctype.char.members] is broken: According to this description, the
 second form of the is() method modifies the masks in the
 ctype object. The correct semantics if, of course, to obtain
 an array of masks. The corresponding method in the general case,
-ie. the do_is() method as described in 22.2.1.1.2 [locale.ctype.virtuals] paragraph 1 does the right thing.
          
+ie. the do_is() method as described in 22.4.1.1.2 [locale.ctype.virtuals] paragraph 1 does the right thing.
          
 
 
 
          Proposed resolution:
          
@@ -2990,8 +2934,8 @@ ie. the do_is() method as described in 22.2.1.1.2 [locale.ctype.virtual
 
 
          
 
          244. Must find's third argument be CopyConstructible?
          
-
          Section: 25.1.5 [alg.find] Status: NAD
- Submitter: Andrew Koenig Date: 2000-05-02
          
+
          Section: 25.3.5 [alg.find] Status: NAD
+ Submitter: Andrew Koenig Opened: 2000-05-02  Last modified: 2006-12-27
          
 
          View all other issues in [alg.find].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -3031,8 +2975,8 @@ might reasonably pass an argument that is not Copy Constructible.
          
 
 
          
 
          245. Which operations on istream_iterator trigger input operations?
          
-
          Section: 24.5.1 [istream.iterator] Status: NAD
- Submitter: Andrew Koenig Date: 2000-05-02
          
+
          Section: 24.6.1 [istream.iterator] Status: NAD
+ Submitter: Andrew Koenig Opened: 2000-05-02  Last modified: 2006-12-27
          
 
          View other active issues in [istream.iterator].
          
 
          View all other issues in [istream.iterator].
          
 
          View all issues with NAD status.
          
@@ -3065,8 +3009,9 @@ how many times find may invoke operator++.
          
 
 
          
 
          246. a.insert(p,t) is incorrectly specified
          
-
          Section: 23.1.4 [associative.reqmts] Status: Dup
- Submitter: Mark Rodgers Date: 2000-05-19
          
+
          Section: 23.2.4 [associative.reqmts] Status: Dup
+ Submitter: Mark Rodgers Opened: 2000-05-19  Last modified: 2007-01-15
          
+
          View other active issues in [associative.reqmts].
          
 
          View all other issues in [associative.reqmts].
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 233
          
@@ -3154,7 +3099,8 @@ Change the words "right after" to "immediately before".
          
 
          
 
          249. Return Type of auto_ptr::operator=
          
 
          Section: D.9.1 [auto.ptr] Status: NAD
- Submitter: Joseph Gottman Date: 2000-06-30
          
+ Submitter: Joseph Gottman Opened: 2000-06-30  Last modified: 2006-12-29
          
+
          View other active issues in [auto.ptr].
          
 
          View all other issues in [auto.ptr].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -3195,8 +3141,8 @@ code.
          
 
 
          
 
          257. STL functional object and iterator inheritance.
          
-
          Section: 20.6.3 [base], 24.3.2 [iterator.basic] Status: NAD
- Submitter: Robert Dick  Date: 2000-08-17
          
+
          Section: 20.7.3 [base], D.10.2 [iterator.basic] Status: NAD
+ Submitter: Robert Dick  Opened: 2000-08-17  Last modified: 2006-12-29
          
 
          View all other issues in [base].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -3280,7 +3226,7 @@ want to pass temporaries as traits or tag types in generic code.
 
          
 
          267. interaction of strstreambuf::overflow() and seekoff()
          
 
          Section: D.7.1.3 [depr.strstreambuf.virtuals] Status: NAD
- Submitter: Martin Sebor Date: 2000-10-05
          
+ Submitter: Martin Sebor Opened: 2000-10-05  Last modified: 2007-01-15
          
 
          View all other issues in [depr.strstreambuf.virtuals].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -3383,8 +3329,8 @@ corner cases in a deprecated feature.
          
 
 
          
 
          269. cstdarg and unnamed parameters
          
-
          Section: 18.7 [support.exception] Status: NAD
- Submitter: J. Stephen Adamczyk Date: 2000-10-10
          
+
          Section: 18.8 [support.exception] Status: NAD
+ Submitter: J. Stephen Adamczyk Opened: 2000-10-10  Last modified: 2006-12-27
          
 
          View all other issues in [support.exception].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -3444,8 +3390,8 @@ necessary.
 
 
          
 
          277. Normative encouragement in allocator requirements unclear
          
-
          Section: 20.1.2 [allocator.requirements] Status: NAD
- Submitter: Matt Austern Date: 2000-11-07
          
+
          Section: X [allocator.requirements] Status: NAD
+ Submitter: Matt Austern Opened: 2000-11-07  Last modified: 2006-12-30
          
 
          View other active issues in [allocator.requirements].
          
 
          View all other issues in [allocator.requirements].
          
 
          View all issues with NAD status.
          
@@ -3479,8 +3425,8 @@ even if it is misunderstood.
          
 
 
          
 
          279. const and non-const iterators should have equivalent typedefs
          
-
          Section: 23.1 [container.requirements] Status: NAD
- Submitter: Steve Cleary Date: 2000-11-27
          
+
          Section: 23.2 [container.requirements] Status: NAD
+ Submitter: Steve Cleary Opened: 2000-11-27  Last modified: 2006-12-27
          
 
          View other active issues in [container.requirements].
          
 
          View all other issues in [container.requirements].
          
 
          View all issues with NAD status.
          
@@ -3508,7 +3454,7 @@ const_iterator unless the above it true. I suspect the former.
 
 
          Proposed resolution:
          
 
          
-In Section: 23.1 [container.requirements],
+In Section: 23.2 [container.requirements],
 table 65, in the assertion/note pre/post condition for X::const_iterator,
 add the following:
 
          
@@ -3548,8 +3494,8 @@ have the same value type, but that is a new issue. (Issue 287. conflicting ios_base fmtflags
-
          Section: 27.4.2.2 [fmtflags.state] Status: NAD
- Submitter: Judy Ward Date: 2000-12-30
          
+
          Section: 27.5.2.2 [fmtflags.state] Status: NAD
+ Submitter: Judy Ward Opened: 2000-12-30  Last modified: 2006-12-27
          
 
          View all other issues in [fmtflags.state].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -3603,7 +3549,7 @@ each of those fields.  (For example, dec and
 oct). These fields are used by locale facets. The LWG
 reviewed the way in which each of those three fields is used, and
 believes that in each case the behavior is well defined for any
-possible combination of bits. See for example Table 58, in 22.2.2.2.2
+possible combination of bits. See for example Table 58, in 22.4.2.2.2
 [facet.num.put.virtuals], noting the requirement in paragraph 6 of that
 section.
 
          
@@ -3618,8 +3564,8 @@ version of setf, to avoid unexpected behavior.
 
 
          
 
          289. <cmath> requirements missing C float and long double versions
          
-
          Section: 26.7 [c.math] Status: NAD
- Submitter: Judy Ward Date: 2000-12-30
          
+
          Section: 26.8 [c.math] Status: NAD
+ Submitter: Judy Ward Opened: 2000-12-30  Last modified: 2007-01-15
          
 
          View all other issues in [c.math].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -3689,8 +3635,8 @@ never referred to by the C++ standard.
          
 
 
          
 
          293. Order of execution in transform algorithm
          
-
          Section: 25.2.4 [alg.transform] Status: NAD
- Submitter: Angelika Langer Date: 2001-01-04
          
+
          Section: 25.4.4 [alg.transform] Status: NAD
+ Submitter: Angelika Langer Opened: 2001-01-04  Last modified: 2007-01-15
          
 
          View all other issues in [alg.transform].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -3758,12 +3704,13 @@ wrapping it in an Input Iterator adaptor.
          
 
 
          
 
          296. Missing descriptions and requirements of pair operators
          
-
          Section: 20.2.3 [pairs] Status: NAD
- Submitter: Martin Sebor Date: 2001-01-14
          
+
          Section: 20.3.3 [pairs] Status: NAD
+ Submitter: Martin Sebor Opened: 2001-01-14  Last modified: 2006-12-27
          
+
          View other active issues in [pairs].
          
 
          View all other issues in [pairs].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
-
          The synopsis of the header <utility> in 20.2 [utility]
+
          The synopsis of the header <utility> in 20.3 [utility]
 lists the complete set of equality and relational operators for pair
 but the section describing the template and the operators only describes
 operator==() and operator<(), and it fails to mention
@@ -3773,10 +3720,10 @@ not mentioned at all.
 
 
 
          Rationale:
          
-
          20.2.1 [operators] paragraph 10 already specifies the semantics.
+
          20.3.1 [operators] paragraph 10 already specifies the semantics.
 That paragraph says that, if declarations of operator!=, operator>,
 operator<=, and operator>= appear without definitions, they are
-defined as specified in 20.2.1 [operators].  There should be no user
+defined as specified in 20.3.1 [operators].  There should be no user
 confusion, since that paragraph happens to immediately precede the
 specification of pair.
          
 
@@ -3784,10 +3731,140 @@ specification of pair.
          
 
 
 
+
          
+
          299. Incorrect return types for iterator dereference
          
+
          Section: 24.2.5 [bidirectional.iterators], 24.2.6 [random.access.iterators] Status: NAD Editorial
+ Submitter: John Potter Opened: 2001-01-22  Last modified: 2008-09-26
          
+
          View all other issues in [bidirectional.iterators].
          
+
          View all issues with NAD Editorial status.
          
+
          Discussion:
          
+
          
+In section 24.2.5 [bidirectional.iterators],
+Table 75 gives the return type of *r-- as convertible to T.  This is
+not consistent with Table 74 which gives the return type of *r++ as
+T&.  *r++ = t is valid while *r-- = t is invalid.
+
          
+
+
          
+In section 24.2.6 [random.access.iterators],
+Table 76 gives the return type of a[n] as convertible to T.  This is
+not consistent with the semantics of *(a + n) which returns T& by
+Table 74.  *(a + n) = t is valid while a[n] = t is invalid.
+
          
+
+
          
+Discussion from the Copenhagen meeting: the first part is
+uncontroversial.  The second part, operator[] for Random Access
+Iterators, requires more thought.  There are reasonable arguments on
+both sides.  Return by value from operator[] enables some potentially
+useful iterators, e.g. a random access "iota iterator" (a.k.a
+"counting iterator" or "int iterator").  There isn't any obvious way
+to do this with return-by-reference, since the reference would be to a
+temporary.  On the other hand, reverse_iterator takes an
+arbitrary Random Access Iterator as template argument, and its
+operator[] returns by reference.  If we decided that the return type
+in Table 76 was correct, we would have to change
+reverse_iterator.  This change would probably affect user
+code.
+
          
+
+
          
+History: the contradiction between reverse_iterator and the
+Random Access Iterator requirements has been present from an early
+stage.  In both the STL proposal adopted by the committee
+(N0527==94-0140) and the STL technical report (HPL-95-11 (R.1), by
+Stepanov and Lee), the Random Access Iterator requirements say that
+operator[]'s return value is "convertible to T".  In N0527
+reverse_iterator's operator[] returns by value, but in HPL-95-11
+(R.1), and in the STL implementation that HP released to the public,
+reverse_iterator's operator[] returns by reference.  In 1995, the
+standard was amended to reflect the contents of HPL-95-11 (R.1).  The
+original intent for operator[] is unclear.
+
          
+
+
          
+In the long term it may be desirable to add more fine-grained 
+iterator requirements, so that access method and traversal strategy
+can be decoupled.  (See "Improved Iterator Categories and
+Requirements", N1297 = 01-0011, by Jeremy Siek.)  Any decisions
+about issue 299 should keep this possibility in mind.
+
          
+
+
          Further discussion: I propose a compromise between John Potter's
+resolution, which requires T& as the return type of
+a[n], and the current wording, which requires convertible to
+T. The compromise is to keep the convertible to T
+for the return type of the expression a[n], but to also add
+a[n] = t as a valid expression. This compromise "saves" the
+common case uses of random access iterators, while at the same time
+allowing iterators such as counting iterator and caching file
+iterators to remain random access iterators (iterators where the
+lifetime of the object returned by operator*() is tied to the
+lifetime of the iterator).
+
          
+
+
          
+Note that the compromise resolution necessitates a change to
+reverse_iterator. It would need to use a proxy to support
+a[n] = t.
+
          
+
+
          
+Note also there is one kind of mutable random access iterator that
+will no longer meet the new requirements. Currently, iterators that
+return an r-value from operator[] meet the requirements for a
+mutable random access iterartor, even though the expression a[n] =
+t will only modify a temporary that goes away. With this proposed
+resolution, a[n] = t will be required to have the same
+operational semantics as *(a + n) = t.
+
          
+
+
+
+
          Proposed resolution:
          
+
+
          
+In section 24.1.4 [lib.bidirectdional.iterators], change the return
+type in table 75 from "convertible to T" to
+T&.
+
          
+
+
          
+In section 24.1.5 [lib.random.access.iterators], change the
+operational semantics for a[n] to " the r-value of
+a[n] is equivalent to the r-value of *(a +
+n)". Add a new row in the table for the expression a[n] = t
+with a return type of convertible to T and operational semantics of
+*(a + n) = t.
+
          
+
+
          [Lillehammer: Real problem, but should be addressed as part of
+  iterator redesign]
          
+
+
+
+
+
          Rationale:
          
+
          [
+San Francisco:
+]
          
+
+
+
          
+Solved by
+N2758.
+
          
+
+
+
+
+
+
+
 
          
 
          302. Need error indication from codecvt<>::do_length
          
-
          Section: 22.2.1.5 [locale.codecvt.byname] Status: NAD
- Submitter: Gregory Bumgardner Date: 2001-01-25
          
+
          Section: 22.4.1.5 [locale.codecvt.byname] Status: NAD
+ Submitter: Gregory Bumgardner Opened: 2001-01-25  Last modified: 2006-12-27
          
 
          View all other issues in [locale.codecvt.byname].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -3857,10 +3934,10 @@ external characters, it stops.
          
 
 
          
 
          304. Must *a return an lvalue when a is an input iterator?
          
-
          Section: 24.1 [iterator.requirements] Status: NAD
- Submitter: Dave Abrahams Date: 2001-02-05
          
-
          View other active issues in [iterator.requirements].
          
-
          View all other issues in [iterator.requirements].
          
+
          Section: 24.2 [iterator.concepts] Status: NAD
+ Submitter: Dave Abrahams Opened: 2001-02-05  Last modified: 2008-09-30
          
+
          View other active issues in [iterator.concepts].
          
+
          View all other issues in [iterator.concepts].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          
@@ -3903,8 +3980,8 @@ buffered somewhere to make a legal input iterator.
 
 
          
 
          313. set_terminate and set_unexpected question
          
-
          Section: 18.7.3.3 [terminate] Status: NAD
- Submitter: Judy Ward Date: 2001-04-03
          
+
          Section: 18.8.3.3 [terminate] Status: NAD
+ Submitter: Judy Ward Opened: 2001-04-03  Last modified: 2006-12-27
          
 
          View all other issues in [terminate].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -3953,8 +4030,8 @@ to call itself.
          
 
 
          
 
          314. Is the stack unwound when terminate() is called?
          
-
          Section: 18.7.3.3 [terminate] Status: NAD
- Submitter: Detlef Vollmann Date: 2001-04-11
          
+
          Section: 18.8.3.3 [terminate] Status: NAD
+ Submitter: Detlef Vollmann Opened: 2001-04-11  Last modified: 2007-01-15
          
 
          View all other issues in [terminate].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -4000,8 +4077,8 @@ about when terminate() is called; it merely specifies which
 
 
          
 
          323. abs() overloads in different headers
          
-
          Section: 26.7 [c.math] Status: NAD
- Submitter: Dave Abrahams Date: 2001-06-04
          
+
          Section: 26.8 [c.math] Status: NAD
+ Submitter: Dave Abrahams Opened: 2001-06-04  Last modified: 2008-03-12
          
 
          View all other issues in [c.math].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -4079,8 +4156,8 @@ The situation is not sufficiently severe to warrant a change.
 
 
          
 
          326. Missing typedef in moneypunct_byname
          
-
          Section: 22.2.6.4 [locale.moneypunct.byname] Status: NAD
- Submitter: Martin Sebor Date: 2001-07-05
          
+
          Section: 22.4.6.4 [locale.moneypunct.byname] Status: NAD
+ Submitter: Martin Sebor Opened: 2001-07-05  Last modified: 2006-12-27
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          The definition of the moneypunct facet contains the typedefs char_type
@@ -4091,7 +4168,7 @@ the derived facet, moneypunct_byname.
          
 
          Proposed resolution:
          
 
          For consistency with the numpunct facet, add a typedef for
 char_type to the definition of the moneypunct_byname facet in
-22.2.6.4 [locale.moneypunct.byname].
          
+22.4.6.4 [locale.moneypunct.byname].
          
 
 
 
          Rationale:
          
@@ -4104,8 +4181,8 @@ the typedef, because it is inherited from the base class.
          
 
 
          
 
          330. Misleading "exposition only" value in class locale definition
          
-
          Section: 22.1.1 [locale] Status: NAD
- Submitter: Martin Sebor Date: 2001-07-15
          
+
          Section: 22.3.1 [locale] Status: NAD
+ Submitter: Martin Sebor Opened: 2001-07-15  Last modified: 2006-12-27
          
 
          View all other issues in [locale].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -4135,7 +4212,7 @@ belonging to the collate category from the German locale on AIX:
 
          The LWG agrees that it may be difficult to implement locale member
 functions in such a way that they can take either category
 arguments or the LC_ constants defined in <cctype>.  In light of
-this requirement (22.1.1.1.1 [locale.category], paragraph 2), and in light
+this requirement (22.3.1.1.1 [locale.category], paragraph 2), and in light
 of the requirement in the preceding paragraph that it is possible to
 combine category bitmask elements with bitwise operations,
 defining the category elements is delicate,
@@ -4154,14 +4231,14 @@ any other choice would be.
          
 
 
          
 
          332. Consider adding increment and decrement operators to std::fpos< T > 
          
-
          Section: 27.4.3 [fpos] Status: NAD
- Submitter: PremAnand M. Rao Date: 2001-08-27
          
+
          Section: 27.5.3 [fpos] Status: NAD
+ Submitter: PremAnand M. Rao Opened: 2001-08-27  Last modified: 2006-12-27
          
 
          View all other issues in [fpos].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          
 Increment and decrement operators are missing from 
-Table 88 -- Position type requirements in 27.4.3 [fpos].
+Table 88 -- Position type requirements in 27.5.3 [fpos].
 
          
 
 
@@ -4196,8 +4273,8 @@ report.  Additionally, nobody saw a clear need for this extension;
 
 
          
 
          344. grouping + showbase
          
-
          Section: 22.2.2 [category.numeric] Status: NAD
- Submitter: Howard Hinnant Date: 2001-10-13
          
+
          Section: 22.4.2 [category.numeric] Status: NAD
+ Submitter: Howard Hinnant Opened: 2001-10-13  Last modified: 2007-01-15
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          
@@ -4214,7 +4291,7 @@ to format (or parse) in this manner.
 
 
          Proposed resolution:
          
 
          
-Insert into 22.2.3.1.2 [facet.numpunct.virtuals] paragraph 3, just before the last
+Insert into 22.4.3.1.2 [facet.numpunct.virtuals] paragraph 3, just before the last
 sentence:
 
          
 
          
@@ -4240,8 +4317,9 @@ consensus in the LWG for action.
 
 
          
 
          348. Minor issue with std::pair operator<
          
-
          Section: 20.2.3 [pairs] Status: Dup
- Submitter: Andy Sawyer Date: 2001-10-23
          
+
          Section: 20.3.3 [pairs] Status: Dup
+ Submitter: Andy Sawyer Opened: 2001-10-23  Last modified: 2008-01-05
          
+
          View other active issues in [pairs].
          
 
          View all other issues in [pairs].
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 532
          
@@ -4255,7 +4333,7 @@ operator< on any pair type which contains a pointer.
 
 
 
          Proposed resolution:
          
-
          In 20.2.3 [pairs] paragraph 6, replace:
          
+
          In 20.3.3 [pairs] paragraph 6, replace:
          
 
              Returns: x.first < y.first || (!(y.first < x.first) && x.second <
         y.second).
 
          
@@ -4288,8 +4366,8 @@ operator< on any pair type which contains a pointer.
 
 
          
 
          350. allocator<>::address
          
-
          Section: 20.7.5.1 [allocator.members], 20.1.2 [allocator.requirements], 17.4.1.1 [contents] Status: Dup
- Submitter: Nathan Myers Date: 2001-10-25
          
+
          Section: 20.8.6.1 [allocator.members], X [allocator.requirements], 17.6.1.1 [contents] Status: Dup
+ Submitter: Nathan Myers Opened: 2001-10-25  Last modified: 2007-10-11
          
 
          View all other issues in [allocator.members].
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 634
          
@@ -4353,7 +4431,7 @@ a.address(s) lines, respectively:
 
 
          Rationale:
          
 
          The LWG believes both examples are ill-formed.  The contained type
-is required to be CopyConstructible (20.1.1 [utility.arg.requirements]), and that
+is required to be CopyConstructible (X [utility.arg.requirements]), and that
 includes the requirement that &t return the usual types and
 values. Since allocators are intended to be used in conjunction with
 containers, and since the CopyConstructible requirements appear to
@@ -4373,15 +4451,15 @@ exhibiting a problem.
          
 
 
          
 
          351. unary_negate and binary_negate: struct or class?
          
-
          Section: 20.6 [function.objects] Status: NAD Editorial
- Submitter: Dale Riley Date: 2001-11-12
          
+
          Section: 20.7 [function.objects] Status: NAD Editorial
+ Submitter: Dale Riley Opened: 2001-11-12  Last modified: 2007-04-24
          
 
          View all other issues in [function.objects].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
 
          
-In 20.6 [function.objects] the header <functional> synopsis declares
+In 20.7 [function.objects] the header <functional> synopsis declares
 the unary_negate and binary_negate function objects as struct.
-However in 20.6.10 [negators] the unary_negate and binary_negate
+However in 20.7.11 [negators] the unary_negate and binary_negate
 function objects are defined as class.  Given the context, they are
 not "basic function objects" like negate, so this is either a typo or
 an editorial oversight.
@@ -4392,7 +4470,7 @@ an editorial oversight.
 
 
 
          Proposed resolution:
          
-
          Change the synopsis to reflect the useage in 20.6.10 [negators]
          
+
          Change the synopsis to reflect the useage in 20.7.11 [negators]
          
 
 
          [Curaçao: Since the language permits "struct", the LWG
 views this as NAD. They suggest, however, that the Project Editor
@@ -4406,8 +4484,9 @@ might wish to make the change as editorial.]
          
 
 
          
 
          353. std::pair missing template assignment
          
-
          Section: 20.2.3 [pairs] Status: NAD Editorial
- Submitter: Martin Sebor Date: 2001-12-02
          
+
          Section: 20.3.3 [pairs] Status: NAD Editorial
+ Submitter: Martin Sebor Opened: 2001-12-02  Last modified: 2008-01-05
          
+
          View other active issues in [pairs].
          
 
          View all other issues in [pairs].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
@@ -4461,8 +4540,8 @@ and thus moved from NAD Future to NAD Editorial.
 
 
          
 
          356. Meaning of ctype_base::mask enumerators
          
-
          Section: 22.2.1 [category.ctype] Status: NAD
- Submitter: Matt Austern Date: 2002-01-23
          
+
          Section: 22.4.1 [category.ctype] Status: NAD
+ Submitter: Matt Austern Opened: 2002-01-23  Last modified: 2006-12-27
          
 
          View all other issues in [category.ctype].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -4509,7 +4588,7 @@ The above program assumes that ctype_base::mask enumerators like
 space and print are disjoint, and that the way to
 say that a character is both a space and a printing character is to or
 those two enumerators together.  This is suggested by the "exposition
-only" values in 22.2.1 [category.ctype], but it is nowhere specified in
+only" values in 22.4.1 [category.ctype], but it is nowhere specified in
 normative text.  An alternative interpretation is that the more
 specific categories subsume the less specific.  The above program
 gives the results it does on the Microsoft compiler because, on that
@@ -4616,8 +4695,8 @@ to see which interpretation is being used.
          
 
 
          
 
          357. <cmath> float functions cannot return HUGE_VAL
          
-
          Section: 26.7 [c.math] Status: NAD Editorial
- Submitter: Ray Lischner Date: 2002-02-26
          
+
          Section: 26.8 [c.math] Status: NAD Editorial
+ Submitter: Ray Lischner Opened: 2002-02-26  Last modified: 2007-04-24
          
 
          View all other issues in [c.math].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
@@ -4677,8 +4756,8 @@ discussion concur.
          
 
 
          
 
          361. num_get<>::do_get (..., void*&) checks grouping
          
-
          Section: 22.2.2.2.2 [facet.num.put.virtuals] Status: NAD
- Submitter: Martin Sebor Date: 2002-03-12
          
+
          Section: 22.4.2.2.2 [facet.num.put.virtuals] Status: NAD
+ Submitter: Martin Sebor Opened: 2002-03-12  Last modified: 2007-01-15
          
 
          View all other issues in [facet.num.put.virtuals].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -4732,7 +4811,8 @@ Change the first sentence of 22.2.2.2.2, p12 from
 
          
 
          366. Excessive const-qualification
          
 
          Section: 27 [input.output] Status: NAD
- Submitter: Walter Brown, Marc Paterno Date: 2002-05-10
          
+ Submitter: Walter Brown, Marc Paterno Opened: 2002-05-10  Last modified: 2006-12-27
          
+
          View other active issues in [input.output].
          
 
          View all other issues in [input.output].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -4855,13 +4935,13 @@ those terms, does not appear in the standard.]
          
 
 
          
 
          367. remove_copy/remove_copy_if and Input Iterators
          
-
          Section: 25.2.8 [alg.remove] Status: NAD
- Submitter: Anthony Williams Date: 2002-05-13
          
+
          Section: 25.4.8 [alg.remove] Status: NAD
+ Submitter: Anthony Williams Opened: 2002-05-13  Last modified: 2006-12-27
          
 
          View all other issues in [alg.remove].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          
-remove_copy and remove_copy_if (25.2.8 [alg.remove]) permit their
+remove_copy and remove_copy_if (25.4.8 [alg.remove]) permit their
 input range to be marked with Input Iterators. However, since two
 operations are required against the elements to copy (comparison and
 assigment), when the input range uses Input Iterators, a temporary
@@ -4878,7 +4958,7 @@ result maintained, so the temporary is not required.
 Add "If InputIterator does not meet the requirements of forward
 iterator, then the value type of InputIterator must be copy
 constructible. Otherwise copy constructible is not required." to
-25.2.8 [alg.remove] paragraph 6.
+25.4.8 [alg.remove] paragraph 6.
 
          
 
 
@@ -4892,12 +4972,12 @@ constructible. Otherwise copy constructible is not required." to
 
 
          
 
          368. basic_string::replace has two "Throws" paragraphs
          
-
          Section: 21.3.6.6 [string::replace] Status: NAD Editorial
- Submitter: Beman Dawes Date: 2002-06-03
          
+
          Section: 21.4.6.6 [string::replace] Status: NAD Editorial
+ Submitter: Beman Dawes Opened: 2002-06-03  Last modified: 2007-04-24
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
 
          
-21.3.6.6 [string::replace] basic_string::replace, second
+21.4.6.6 [string::replace] basic_string::replace, second
 signature, given in paragraph 1, has two "Throws" paragraphs (3 and
 5).
 
          
@@ -4924,13 +5004,13 @@ part of the "Effects" paragraph.
 
 
          
 
          372. Inconsistent description of stdlib exceptions
          
-
          Section: 17.4.4.9 [res.on.exception.handling], 18.6.1 [type.info] Status: NAD
- Submitter: Randy Maddox Date: 2002-07-22
          
+
          Section: 17.6.4.10 [res.on.exception.handling], 18.7.1 [type.info] Status: NAD
+ Submitter: Randy Maddox Opened: 2002-07-22  Last modified: 2006-12-27
          
 
          View all other issues in [res.on.exception.handling].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
-
          Paragraph 3 under clause 17.4.4.9 [res.on.exception.handling], Restrictions on
+
          Paragraph 3 under clause 17.6.4.10 [res.on.exception.handling], Restrictions on
 Exception Handling, states that "Any other functions defined in the
 C++ Standard Library that do not have an exception-specification may
 throw implementation-defined exceptions unless otherwise specified."
@@ -4941,7 +5021,7 @@ not required) to report errors by throwing exceptions from (or derived
 from) the standard exceptions."
          
 
 
          These statements appear to be in direct contradiction to clause
-18.6.1 [type.info], which states "The class exception defines the
+18.7.1 [type.info], which states "The class exception defines the
 base class for the types of objects thrown as exceptions by the C++
 Standard library components ...".
          
 
@@ -4964,18 +5044,18 @@ Standard library components ...".
          
 
 
          
 
          374. moneypunct::frac_digits returns int not unsigned
          
-
          Section: 22.2.6.3.1 [locale.moneypunct.members], 22.2.6.3.2 [locale.moneypunct.virtuals] Status: NAD
- Submitter: Ray Lischner Date: 2002-08-08
          
+
          Section: 22.4.6.3.1 [locale.moneypunct.members], 22.4.6.3.2 [locale.moneypunct.virtuals] Status: NAD
+ Submitter: Ray Lischner Opened: 2002-08-08  Last modified: 2006-12-27
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          
-In section 22.2.6.3.1 [locale.moneypunct.members], frac_digits() returns type
+In section 22.4.6.3.1 [locale.moneypunct.members], frac_digits() returns type
 "int". This implies that frac_digits() might return a negative value,
 but a negative value is nonsensical. It should return "unsigned".
 
          
 
 
          
-Similarly, in section 22.2.6.3.2 [locale.moneypunct.virtuals], do_frac_digits()
+Similarly, in section 22.4.6.3.2 [locale.moneypunct.virtuals], do_frac_digits()
 should return "unsigned".
 
          
 
@@ -4997,13 +5077,13 @@ checks.
          
 
 
          
 
          377. basic_string::insert and length_error
          
-
          Section: 21.3.6.4 [string::insert] Status: NAD
- Submitter: Ray Lischner Date: 2002-08-16
          
+
          Section: 21.4.6.4 [string::insert] Status: NAD
+ Submitter: Ray Lischner Opened: 2002-08-16  Last modified: 2006-12-27
          
 
          View all other issues in [string::insert].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          
-Section 21.3.6.4 [string::insert], paragraph 4, contains the following,
+Section 21.4.6.4 [string::insert], paragraph 4, contains the following,
 "Then throws length_error if size() >= npos - rlen."
 
          
 
@@ -5023,8 +5103,8 @@ needed.
          
 
 
          
 
          378. locale immutability and locale::operator=()
          
-
          Section: 22.1.1 [locale] Status: Dup
- Submitter: Martin Sebor Date: 2002-09-06
          
+
          Section: 22.3.1 [locale] Status: Dup
+ Submitter: Martin Sebor Opened: 2002-09-06  Last modified: 2006-12-30
          
 
          View all other issues in [locale].
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 31
          
@@ -5073,14 +5153,15 @@ out of scope?
 
          
 
          385. Does call by value imply the CopyConstructible requirement?
          
 
          Section: 17 [library] Status: NAD
- Submitter: Matt Austern Date: 2002-10-23
          
+ Submitter: Matt Austern Opened: 2002-10-23  Last modified: 2007-04-18
          
+
          View other active issues in [library].
          
 
          View all other issues in [library].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          
 Many function templates have parameters that are passed by value;
 a typical example is find_if's pred parameter in
-25.1.5 [alg.find].  Are the corresponding template parameters
+25.3.5 [alg.find].  Are the corresponding template parameters
 (Predicate in this case) implicitly required to be
 CopyConstructible, or does that need to be spelled out explicitly?
 
          
@@ -5150,8 +5231,8 @@ then precisely describe and enforce the precise requirements.
 
 
          
 
          388. Use of complex as a key in associative containers
          
-
          Section: 26.3 [complex.numbers] Status: NAD
- Submitter: Gabriel Dos Reis Date: 2002-11-08
          
+
          Section: 26.4 [complex.numbers] Status: NAD
+ Submitter: Gabriel Dos Reis Opened: 2002-11-08  Last modified: 2008-02-27
          
 
          View all other issues in [complex.numbers].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -5222,9 +5303,8 @@ provide their own comparison function object.
          
 
 
          
 
          390. CopyConstructible requirements too strict
          
-
          Section: 20.1.1 [utility.arg.requirements] Status: NAD Editorial
- Submitter: Doug Gregor Date: 2002-10-24
          
-
          View other active issues in [utility.arg.requirements].
          
+
          Section: X [utility.arg.requirements] Status: NAD Editorial
+ Submitter: Doug Gregor Opened: 2002-10-24  Last modified: 2008-03-14
          
 
          View all other issues in [utility.arg.requirements].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
@@ -5290,20 +5370,20 @@ that &t and &u return the address of t and u, respectively.
 
 
          
 
          392. 'equivalence' for input iterators
          
-
          Section: 24.1.1 [input.iterators] Status: NAD
- Submitter: Corwin Joy Date: 2002-12-11
          
+
          Section: 24.2.2 [input.iterators] Status: NAD
+ Submitter: Corwin Joy Opened: 2002-12-11  Last modified: 2006-12-27
          
 
          View all other issues in [input.iterators].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
 
          
-In section 24.1.1 [input.iterators] table 72 -
+In section 24.2.2 [input.iterators] table 72 -
 'Input Iterator Requirements' we have as a postcondition of *a:
 "If a==b and (a, b) is in the domain of == then *a is equivalent to *b".
 
          
 
 
          
-In section 24.5.3.5 [istreambuf.iterator::equal] it states that
+In section 24.6.3.5 [istreambuf.iterator::equal] it states that
 "istreambuf_iterator::equal returns true if and only if both iterators
 are at end-of-stream, or neither is at end-of-stream, regardless of
 what streambuf object they use."  (My emphasis).
@@ -5311,7 +5391,7 @@ what streambuf object they use."  (My emphasis).
 
 
          
 The defect is that either 'equivalent' needs to be more precisely
-defined or the conditions for equality in 24.5.3.5 [istreambuf.iterator::equal]
+defined or the conditions for equality in 24.6.3.5 [istreambuf.iterator::equal]
 are incorrect. (Or both).
 
          
 
@@ -5332,7 +5412,7 @@ are incorrect. (Or both).
 
 
 
          Now assuming that neither f1 or f2 are at the end-of-stream then
-f1 == f2 by 24.5.3.5 [istreambuf.iterator::equal].
          
+f1 == f2 by 24.6.3.5 [istreambuf.iterator::equal].
          
 
 
          However, it is unlikely that *f1 will give the same value as *f2 except
 by accident.
          
@@ -5355,8 +5435,8 @@ of input iterators.
          
 
 
          
 
          393. do_in/do_out operation on state unclear
          
-
          Section: 22.2.1.4.2 [locale.codecvt.virtuals] Status: NAD Editorial
- Submitter: Alberto Barbati Date: 2002-12-24
          
+
          Section: 22.4.1.4.2 [locale.codecvt.virtuals] Status: NAD Editorial
+ Submitter: Alberto Barbati Opened: 2002-12-24  Last modified: 2008-07-02
          
 
          View all other issues in [locale.codecvt.virtuals].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
@@ -5373,7 +5453,7 @@ characters as a result of operation on state?
 
 
          Proposed resolution:
          
 
          
-Add a note at the end of 22.2.1.4.2 [locale.codecvt.virtuals], 
+Add a note at the end of 22.4.1.4.2 [locale.codecvt.virtuals], 
 paragraph 3:
 
          
 
@@ -5417,8 +5497,8 @@ correct. Proposed Disposition: NAD, Editorial
 
 
          
 
          399. volations of unformatted input function requirements
          
-
          Section: 27.6.1.3 [istream.unformatted] Status: NAD
- Submitter: Martin Sebor Date: 2003-01-05
          
+
          Section: 27.7.1.3 [istream.unformatted] Status: NAD
+ Submitter: Martin Sebor Opened: 2003-01-05  Last modified: 2006-12-27
          
 
          View all other issues in [istream.unformatted].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -5462,99 +5542,10 @@ can use alternative signatures that don't call widen.
 
 
 
-
          
-
          424. normative notes
          
-
          Section: 17.3.1.1 [structure.summary] Status: Pending NAD Editorial
- Submitter: Martin Sebor Date: 2003-09-18
          
-
          View all issues with Pending NAD Editorial status.
          
-
          Discussion:
          
-
-
          
-The text in 17.3.1.1, p1 says:
-
          
-
-"Paragraphs labelled "Note(s):" or "Example(s):" are informative, other
-paragraphs are normative."
-
          
-
-The library section makes heavy use of paragraphs labeled "Notes(s),"
-some of which are clearly intended to be normative (see list 1), while
-some others are not (see list 2). There are also those where the intent
-is not so clear (see list 3).
-

          
-
-List 1 -- Examples of (presumably) normative Notes:
-
          
-
-20.7.5.1 [allocator.members], p3,
          
-20.7.5.1 [allocator.members], p10,
          
-21.3.2 [string.cons], p11,
          
-22.1.1.2 [locale.cons], p11,
          
-23.2.2.3 [deque.modifiers], p2,
          
-25.3.7 [alg.min.max], p3,
          
-26.3.6 [complex.ops], p15,
          
-27.5.2.4.3 [streambuf.virt.get], p7.
          
-
          
-
-List 2 -- Examples of (presumably) informative Notes:
-
          
-
-18.5.1.3 [new.delete.placement], p3,
          
-21.3.6.6 [string::replace], p14,
          
-22.2.1.4.2 [locale.codecvt.virtuals], p3,
          
-25.1.4 [alg.foreach], p4,
          
-26.3.5 [complex.member.ops], p1,
          
-27.4.2.5 [ios.base.storage], p6.
          
-
          
-
-List 3 -- Examples of Notes that are not clearly either normative
-or informative:
-
          
-
-22.1.1.2 [locale.cons], p8,
          
-22.1.1.5 [locale.statics], p6,
          
-27.5.2.4.5 [streambuf.virt.put], p4.
          
-
          
-
-None of these lists is meant to be exhaustive.
-
          
-
-
          [Definitely a real problem.  The big problem is there's material
-  that doesn't quite fit any of the named paragraph categories
-  (e.g. Effects).  Either we need a new kind of named
-  paragraph, or we need to put more material in unnamed paragraphs
-  jsut after the signature.  We need to talk to the Project Editor
-  about how to do this.
-]
          
-
-
-
          [
-Bellevue: Specifics of list 3: First 2 items correct in std (22.1.1.2,
-22.1.1.5) Third item should be non-normative (27.5.2.4.5), which Pete
-will handle editorially.
-]
          
-
-
-
-
          Proposed resolution:
          
-
          [Pete: I changed the paragraphs marked "Note" and "Notes" to use "Remark" and "Remarks".
-Fixed as editorial.  This change has been in the WD since the post-Redmond mailing, in 2004.
-Recommend NAD.]
          
-
-
          [
-Batavia:  We feel that the references in List 2 above should be changed from Remarks
-to Notes.  We also feel that those items in List 3 need to be double checked for
-the same change.  Alan and Pete to review.
-]
          
-
-
-
-
-
 
          
 
          429. typo in basic_ios::clear(iostate)
          
-
          Section: 27.4.4.3 [iostate.flags] Status: Dup
- Submitter: Martin Sebor Date: 2003-09-18
          
+
          Section: 27.5.4.3 [iostate.flags] Status: Dup
+ Submitter: Martin Sebor Opened: 2003-09-18  Last modified: 2006-12-30
          
 
          View all other issues in [iostate.flags].
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 412
          
@@ -5595,8 +5586,8 @@ to
 
 
          
 
          433. Contradiction in specification of unexpected()
          
-
          Section: 18.7.2.4 [unexpected] Status: NAD
- Submitter: Vyatcheslav Sysoltsev Date: 2003-09-29
          
+
          Section: 18.8.2.4 [unexpected] Status: NAD
+ Submitter: Vyatcheslav Sysoltsev Opened: 2003-09-29  Last modified: 2006-12-27
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          
@@ -5628,8 +5619,8 @@ ambiguity in understanding.
 
 
          
 
          437. Formatted output of function pointers is confusing
          
-
          Section: 27.6.2.6.2 [ostream.inserters.arithmetic] Status: NAD
- Submitter: Ivan Godard Date: 2003-10-24
          
+
          Section: 27.7.2.6.2 [ostream.inserters.arithmetic] Status: NAD
+ Submitter: Ivan Godard Opened: 2003-10-24  Last modified: 2006-12-27
          
 
          View all other issues in [ostream.inserters.arithmetic].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -5674,8 +5665,8 @@ conversions from C and the function pointer is converted to bool.
 
 
          
 
          439. Should facets be copyable?
          
-
          Section: 22.2 [locale.categories] Status: NAD
- Submitter: Matt Austern Date: 2003-11-02
          
+
          Section: 22.4 [locale.categories] Status: NAD
+ Submitter: Matt Austern Opened: 2003-11-02  Last modified: 2006-12-27
          
 
          View other active issues in [locale.categories].
          
 
          View all other issues in [locale.categories].
          
 
          View all issues with NAD status.
          
@@ -5731,8 +5722,8 @@ conversions from C and the function pointer is converted to bool.
 
 
          
 
          440. Should std::complex use unqualified transcendentals?
          
-
          Section: 26.3.8 [complex.transcendentals] Status: NAD
- Submitter: Matt Austern Date: 2003-11-05
          
+
          Section: 26.4.8 [complex.transcendentals] Status: NAD
+ Submitter: Matt Austern Opened: 2003-11-05  Last modified: 2009-03-21
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          
@@ -5751,7 +5742,7 @@ transcendentals, as discussed in issue complex for types other than float, double or long double is
-unspecified." (26.3.1 [complex.synopsis]) Second, the standard does not
+unspecified." (26.4.1 [complex.syn]) Second, the standard does not
 dictate implementation, so there is no guarantee that a particular
 real math function is used in the implementation of a particular
 complex function.
          
@@ -5771,8 +5762,8 @@ are off.
          
 
 
          
 
          447. Wrong template argument for time facets
          
-
          Section: 22.1.1.1.1 [locale.category] Status: Dup
- Submitter: Pete Becker Date: 2003-12-26
          
+
          Section: 22.3.1.1.1 [locale.category] Status: Dup
+ Submitter: Pete Becker Opened: 2003-12-26  Last modified: 2007-01-15
          
 
          View all other issues in [locale.category].
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 327
          
@@ -5807,23 +5798,23 @@ Change the second template argument to InputIterator.
 
 
          
 
          450. set::find is inconsistent with associative container requirements
          
-
          Section: 23.3.3 [set] Status: Dup
- Submitter: Bill Plauger Date: 2004-01-30
          
+
          Section: 23.4.3 [set] Status: Dup
+ Submitter: Bill Plauger Opened: 2004-01-30  Last modified: 2009-05-01
          
 
          View all other issues in [set].
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 214
          
 
          Discussion:
          
 
          map/multimap have:
          
 
-
          	iterator find(const key_type& x) const;
-	const_iterator find(const key_type& x) const;
+
              iterator find(const key_type& x) const;
+    const_iterator find(const key_type& x) const;
 
          
 
 
          
 which is consistent with the table of associative container requirements.
 But set/multiset have:
 
          
-
          	iterator find(const key_type&) const;
+
              iterator find(const key_type&) const;
 
          
 
 
          
@@ -5844,21 +5835,22 @@ table, in this regard.
 
 
          
 
          451. Associative erase should return an iterator
          
-
          Section: 23.1.4 [associative.reqmts], 23.3 [associative] Status: Dup
- Submitter: Bill Plauger Date: 2004-01-30
          
+
          Section: 23.2.4 [associative.reqmts], 23.4 [associative] Status: Dup
+ Submitter: Bill Plauger Opened: 2004-01-30  Last modified: 2009-05-01
          
+
          View other active issues in [associative.reqmts].
          
 
          View all other issues in [associative.reqmts].
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 130
          
 
          Discussion:
          
 
          map/multimap/set/multiset have:
          
-
          	void erase(iterator);
-	void erase(iterator, iterator);
+
              void erase(iterator);
+    void erase(iterator, iterator);
 
          
 
 
          But there's no good reason why these can't return an iterator, as for
 vector/deque/list:
          
-
          	iterator erase(iterator);
-	iterator erase(iterator, iterator);
+
              iterator erase(iterator);
+    iterator erase(iterator, iterator);
 
          
 
 
@@ -5880,13 +5872,13 @@ first element beyond the erased subrange.
 
 
          
 
          452.  locale::combine should be permitted to generate a named locale
          
-
          Section: 22.1.1.3 [locale.members] Status: NAD
- Submitter: Bill Plauger Date: 2004-01-30
          
+
          Section: 22.3.1.3 [locale.members] Status: NAD
+ Submitter: Bill Plauger Opened: 2004-01-30  Last modified: 2009-05-01
          
 
          View all other issues in [locale.members].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          template<class Facet>
-	locale::combine(const locale&) const;
+    locale::combine(const locale&) const;
 
          
 
          
 is obliged to create a locale that has no name. This is overspecification
@@ -5919,10 +5911,202 @@ standard facets.
 
 
 
+
          
+
          454. basic_filebuf::open should accept wchar_t names
          
+
          Section: 27.9.1.4 [filebuf.members] Status: NAD
+ Submitter: Bill Plauger Opened: 2004-01-30  Last modified: 2009-05-01
          
+
          View all other issues in [filebuf.members].
          
+
          View all issues with NAD status.
          
+
          Duplicate of: 105
          
+
          Discussion:
          
+
              basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode);
+
          
+
+
          should be supplemented with the overload:
          
+
+
              basic_filebuf *basic_filebuf::open(const wchar_t *, ios_base::open_mode);
+
          
+
+
          
+Depending on the operating system, one of these forms is fundamental and
+the other requires an implementation-defined mapping to determine the
+actual filename.
+
          
+
+
          [Sydney: Yes, we want to allow wchar_t filenames.  Bill will
+  provide wording.]
          
+
+
+
          [
+In Toronto we noted that this is issue 5 from
+N1569.
+]
          
+
+
          
+How does this interact with the newly-defined character types, and how
+do we avoid interface explosion considering std::string overloads that
+were added? Propose another solution that is different than the
+suggestion proposed by PJP.
+
          
+
          
+Suggestion is to make a member template function for basic_string (for
+char, wchar_t, u16char, u32char instantiations), and then just keep a
+const char* member.
+
          
+
          
+Goal is to do implicit conversion between character string literals to
+appropriate basic_string type. Not quite sure if this is possible.
+
          
+
          
+Implementors are free to add specific overloads for non-char character
+types.
+
          
+
+
          [
+Martin adds pre-Sophia Antipolis:
+]
          
+
+
+
          
+Please see issue 454: problems and solutions.
+
          
+
+
          [
+Sophia Antipolis:
+]
          
+
+
+
          
+
          
+Beman is concerned that making these changes to basic_filebuf is not
+usefully changed unless fstream is also changed; this also only handles
+wchar_t and not other character types.
+
          
+
          
+The TR2 filesystem library is a more complete solution, but is not available soon.
+
          
+
          
+
+
          [
+Martin adds:  please reference
+N2683 for
+problems and solutions.
+]
          
+
+
+
+
+
          Proposed resolution:
          
+
+
          Change from:
          
+
          
+
          basic_filebuf<charT,traits>* open(
+    const char* s,
+    ios_base::openmode mode );
+
          
+
+
          
+Effects: If is_open() != false, returns a null pointer.
+Otherwise, initializes the filebuf as required. It then
+opens a file, if possible, whose name is the NTBS s ("as if"
+by calling std::fopen(s,modstr)).
          
+
          
+
+
          to:
          
+
+
          
+
          basic_filebuf<charT,traits>* open(
+    const char* s,
+    ios_base::openmode mode );
+
+basic_filebuf<charT,traits>* open(
+    const wchar_t* ws,
+    ios_base::openmode mode );
+
          
+
+
          
+Effects: If is_open() != false, returns a null pointer.
+Otherwise, initializes the filebuf as required. It then
+opens a file, if possible, whose name is the NTBS s ("as if"
+by calling std::fopen(s,modstr)).
+For the second signature, the NTBS s is determined from the
+WCBS ws in an implementation-defined manner.
+
          
+
+
          
+(NOTE: For a system that "naturally" represents a filename
+as a WCBS, the NTBS s in the first signature may instead
+be mapped to a WCBS; if so, it follows the same mapping
+rules as the first argument to open.)
+
          
+
          
+
+
+
+
          Rationale:
          
+
          
+Slightly controversial, but by a 7-1 straw poll the LWG agreed to move
+this to Ready.  The controversy was because the mapping between wide
+names and files in a filesystem is implementation defined.  The
+counterargument, which most but not all LWG members accepted, is that
+the mapping between narrow files names and files is also
+implemenation defined.
          
+
+
          [Lillehammer: Moved back to "open" status, at Beman's urging.
+(1) Why just basic_filebuf, instead of also basic_fstream (and
+possibly other things too). (2) Why not also constructors that take
+std::basic_string? (3) We might want to wait until we see Beman's
+filesystem library; we might decide that it obviates this.]
          
+
+
+
          [
+post Bellevue:
+]
          
+
+
+
          
+
          
+Move again to Ready.
+
          
+
          
+There is a timing issue here. Since the filesystem library will not be
+in C++0x, this should be brought forward. This solution would remain
+valid in the context of the proposed filesystem.
+
          
+
          
+This issue has been kicking around for a while, and the wchar_t addition
+alone would help many users. Thus, we suggest putting this on the
+reflector list with an invitation for someone to produce proposed
+wording that covers basic_fstream. In the meantime, we suggest that the
+proposed wording be adopted as-is.
+
          
+
          
+If more of the Lillehammer questions come back, they should be
+introduced as separate issues.
+
          
+
          
+
+
          [
+San Francisco:
+]
          
+
+
+
          
+Some existing implementations provide overload already. Expected
+filesystem "path" object overloads neatly, without surprises; implying
+NAD.
+
          
+
+
+
+
+
+
+
 
          
 
          462. Destroying objects with static storage duration
          
-
          Section: 3.6.3 [basic.start.term], 18.3 [cstdint] Status: NAD
- Submitter: Bill Plauger Date: 2004-03-23
          
+
          Section: 3.6.3 [basic.start.term], 18.4 [cstdint] Status: NAD
+ Submitter: Bill Plauger Opened: 2004-03-23  Last modified: 2008-02-25
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          
@@ -6073,58 +6257,10 @@ Bill agrees issue is no longer serious, and accepts NAD.
 
 
 
-
          
-
          466. basic_string ctor should prevent null pointer error
          
-
          Section: 21.3.1 [string.require] Status: NAD
- Submitter: Daniel Frey Date: 2004-06-10
          
-
          View all other issues in [string.require].
          
-
          View all issues with NAD status.
          
-
          Discussion:
          
-
          
-Today, my colleagues and me wasted a lot of time. After some time, I
-found the problem. It could be reduced to the following short example:
-
          
-
-
            #include <string>
-  int main() { std::string( 0 ); }
-
          
-
-
          The problem is that the tested compilers (GCC 2.95.2, GCC 3.3.1 and
-Comeau online) compile the above without errors or warnings! The
-programs (at least for the GCC) resulted in a SEGV.
          
-
-
          I know that the standard explicitly states that the ctor of string
-requires a char* which is not zero. STLs could easily detect the above
-case with a private ctor for basic_string which takes a single 'int'
-argument. This would catch the above code at compile time and would not
-ambiguate any other legal ctors.
          
-
-
          [Redmond: No great enthusiasm for doing this.  If we do,
-  however, we want to do it for all places that take charT*
-  pointers, not just the single-argument constructor.  The other
-  question is whether we want to catch this at compile time (in which
-  case we catch the error of a literal 0, but not an expression whose
-  value is a null pointer), at run time, or both.]
          
-
-
-
-
-
          Proposed resolution:
          
-
-
-
          Rationale:
          
-
          
-Recommend NAD.  Relegate this functionality to debugging implementations.
-
          
-
-
-
-
-
 
          
 
          470. accessing containers from their elements' special functions
          
 
          Section: 23 [containers] Status: NAD
- Submitter: Martin Sebor Date: 2004-06-28
          
+ Submitter: Martin Sebor Opened: 2004-06-28  Last modified: 2007-04-18
          
 
          View other active issues in [containers].
          
 
          View all other issues in [containers].
          
 
          View all issues with NAD status.
          
@@ -6177,8 +6313,8 @@ corner cases.
 
 
          
 
          472. Missing "Returns" clause in std::equal_range
          
-
          Section: 25.3.3.3 [equal.range] Status: Dup
- Submitter: Prateek R Karandikar Date: 2004-06-30
          
+
          Section: 25.5.3.3 [equal.range] Status: Dup
+ Submitter: Prateek R Karandikar Opened: 2004-06-30  Last modified: 2006-12-30
          
 
          View all other issues in [equal.range].
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 270
          
@@ -6201,8 +6337,8 @@ There is no "Returns:" clause for std::equal_range, which returns non-void.
 
 
          
 
          476. Forward Iterator implied mutability
          
-
          Section: 24.1.3 [forward.iterators] Status: NAD
- Submitter: Dave Abrahams Date: 2004-07-09
          
+
          Section: 24.2.4 [forward.iterators] Status: NAD
+ Submitter: Dave Abrahams Opened: 2004-07-09  Last modified: 2007-01-15
          
 
          View all other issues in [forward.iterators].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -6241,8 +6377,8 @@ overhaul.)
          
 
 
          
 
          477. Operator-> for const forward iterators
          
-
          Section: 24.1.3 [forward.iterators] Status: Dup
- Submitter: Dave Abrahams Date: 2004-07-11
          
+
          Section: 24.2.4 [forward.iterators] Status: Dup
+ Submitter: Dave Abrahams Opened: 2004-07-11  Last modified: 2007-01-15
          
 
          View all other issues in [forward.iterators].
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 478
          
@@ -6294,8 +6430,8 @@ as the first line.
          
 
 
          
 
          479. Container requirements and placement new
          
-
          Section: 23.1 [container.requirements] Status: Dup
- Submitter: Herb Sutter Date: 2004-08-01
          
+
          Section: 23.2 [container.requirements] Status: Dup
+ Submitter: Herb Sutter Opened: 2004-08-01  Last modified: 2007-04-18
          
 
          View other active issues in [container.requirements].
          
 
          View all other issues in [container.requirements].
          
 
          View all issues with Dup status.
          
@@ -6343,8 +6479,8 @@ support that the eventual solution should make this code well formed.
 
 
          
 
          480. unary_function and binary_function should have protected nonvirtual destructors
          
-
          Section: 20.6.3 [base] Status: NAD
- Submitter: Joe Gottman Date: 2004-08-19
          
+
          Section: 20.7.3 [base] Status: NAD
+ Submitter: Joe Gottman Opened: 2004-08-19  Last modified: 2006-12-29
          
 
          View all other issues in [base].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -6408,8 +6544,9 @@ nonvirtual destructors.
          
 
 
          
 
          481. unique's effects on the range [result, last)
          
-
          Section: 25.2.9 [alg.unique] Status: NAD
- Submitter: Andrew Koenig Date: 2004-08-30
          
+
          Section: 25.4.9 [alg.unique] Status: NAD
+ Submitter: Andrew Koenig Opened: 2004-08-30  Last modified: 2006-12-27
          
+
          View other active issues in [alg.unique].
          
 
          View all other issues in [alg.unique].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -6445,8 +6582,9 @@ explicit, but it's hard to think that's a major problem.
          
 
 
          
 
          482. Swapping pairs
          
-
          Section: 20.2.3 [pairs], 20.4 [tuple] Status: NAD Editorial
- Submitter: Andrew Koenig Date: 2004-09-14
          
+
          Section: 20.3.3 [pairs], 20.5 [tuple] Status: NAD Editorial
+ Submitter: Andrew Koenig Opened: 2004-09-14  Last modified: 2007-05-06
          
+
          View other active issues in [pairs].
          
 
          View all other issues in [pairs].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
@@ -6463,7 +6601,7 @@ list<double> > should not take O(1).
          
 
 
          [
 Post Oxford:  We got swap for pair but accidently
-missed tuple.  tuple::swap is being tracked by 522.
+missed tuple.  tuple::swap is being tracked by 522.
 ]
          
 
 
@@ -6487,8 +6625,8 @@ Recommend NAD, fixed by
 
 
          
 
          483. Heterogeneous equality and EqualityComparable
          
-
          Section: 25.1 [alg.nonmodifying], 25.2 [alg.modifying.operations] Status: Dup
- Submitter: Peter Dimov Date: 2004-09-20
          
+
          Section: 25.3 [alg.nonmodifying], 25.4 [alg.modifying.operations] Status: Dup
+ Submitter: Peter Dimov Opened: 2004-09-20  Last modified: 2007-01-15
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 283
          
 
          Discussion:
          
@@ -6590,10 +6728,83 @@ operator that takes a T, or a T may be convertible to the type of *i.
 
 
 
+
          
+
          484. Convertible to T
          
+
          Section: 24.2.2 [input.iterators] Status: NAD Editorial
+ Submitter: Chris Jefferson Opened: 2004-09-16  Last modified: 2008-09-26
          
+
          View all other issues in [input.iterators].
          
+
          View all issues with NAD Editorial status.
          
+
          Discussion:
          
+
          From comp.std.c++:
          
+
+
          
+I note that given an input iterator a for type T, 
+then *a only has to be "convertable to T", not actually of type T.
+
          
+
+
          Firstly, I can't seem to find an exact definition of "convertable to T". 
+While I assume it is the obvious definition (an implicit conversion), I 
+can't find an exact definition. Is there one?
          
+
+
          Slightly more worryingly, there doesn't seem to be any restriction on 
+the this type, other than it is "convertable to T". Consider two input 
+iterators a and b. I would personally assume that most people would 
+expect *a==*b would perform T(*a)==T(*b), however it doesn't seem that 
+the standard requires that, and that whatever type *a is (call it U) 
+could have == defined on it with totally different symantics and still 
+be a valid inputer iterator.
          
+
+
          Is this a correct reading? When using input iterators should I write 
+T(*a) all over the place to be sure that the object i'm using is the 
+class I expect?
          
+
+
          This is especially a nuisance for operations that are defined to be
+  "convertible to bool".  (This is probably allowed so that
+  implementations could return say an int and avoid an unnessary
+  conversion. However all implementations I have seen simply return a
+  bool anyway.  Typical implemtations of STL algorithms just write
+  things like while(a!=b && *a!=0).  But strictly
+  speaking, there are lots of types that are convertible to T but
+  that also overload the appropriate operators so this doesn't behave
+  as expected.
          
+
+
          If we want to make code like this legal (which most people seem to
+  expect), then we'll need to tighten up what we mean by "convertible
+  to T".
          
+
+
          [Lillehammer: The first part is NAD, since "convertible" is
+ well-defined in core. The second part is basically about pathological
+ overloads. It's a minor problem but a real one. So leave open for
+ now, hope we solve it as part of iterator redesign.]
          
+
+
+
+
+
          Proposed resolution:
          
+
+
+
          Rationale:
          
+
          [
+San Francisco:
+]
          
+
+
+
          
+Solved by
+N2758.
+
          
+
+
+
+
+
+
+
 
          
 
          486. min/max CopyConstructible requirement is too strict
          
-
          Section: 25.3.7 [alg.min.max] Status: Dup
- Submitter: Dave Abrahams Date: 2004-10-13
          
+
          Section: 25.5.7 [alg.min.max] Status: Dup
+ Submitter: Dave Abrahams Opened: 2004-10-13  Last modified: 2006-12-30
          
+
          View other active issues in [alg.min.max].
          
 
          View all other issues in [alg.min.max].
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 281
          
@@ -6615,8 +6826,8 @@ copy T.
          
 
 
          
 
          487. Allocator::construct is too limiting
          
-
          Section: 20.1.2 [allocator.requirements] Status: NAD
- Submitter: Dhruv Matani Date: 2004-10-17
          
+
          Section: X [allocator.requirements] Status: NAD
+ Submitter: Dhruv Matani Opened: 2004-10-17  Last modified: 2006-12-30
          
 
          View other active issues in [allocator.requirements].
          
 
          View all other issues in [allocator.requirements].
          
 
          View all issues with NAD status.
          
@@ -6660,8 +6871,8 @@ be called! Doesn't that sound great?
 
 
          
 
          489. std::remove / std::remove_if wrongly specified
          
-
          Section: 25.2.8 [alg.remove] Status: NAD
- Submitter: Thomas Mang Date: 2004-12-12
          
+
          Section: 25.4.8 [alg.remove] Status: NAD
+ Submitter: Thomas Mang Opened: 2004-12-12  Last modified: 2006-12-27
          
 
          View all other issues in [alg.remove].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -6859,8 +7070,9 @@ ISO/IEC 14882:2003.
 
 
          
 
          490. std::unique wrongly specified
          
-
          Section: 25.2.9 [alg.unique] Status: NAD
- Submitter: Thomas Mang Date: 2004-12-12
          
+
          Section: 25.4.9 [alg.unique] Status: NAD
+ Submitter: Thomas Mang Opened: 2004-12-12  Last modified: 2006-12-27
          
+
          View other active issues in [alg.unique].
          
 
          View all other issues in [alg.unique].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -7110,12 +7322,12 @@ change, so there is no real-world harm here.
          
 
 
          
 
          491. std::list<>::unique incorrectly specified
          
-
          Section: 23.2.4.4 [list.ops] Status: NAD
- Submitter: Thomas Mang Date: 2004-12-12
          
+
          Section: 23.3.4.4 [list.ops] Status: NAD
+ Submitter: Thomas Mang Opened: 2004-12-12  Last modified: 2007-02-19
          
 
          View all other issues in [list.ops].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
-
          In Section 23.2.4.4 [list.ops], paragraphs 19 to 21 describe the
+
          In Section 23.3.4.4 [list.ops], paragraphs 19 to 21 describe the
 behavior of the std::list<T, Allocator>::unique operation. However, the
 current wording is defective for various reasons.
          
 
@@ -7125,7 +7337,7 @@ current wording is defective for various reasons.
          
 1) Analysis of current wording:
 
          
 
-
          23.2.4.4 [list.ops], paragraph 19:
          
+
          23.3.4.4 [list.ops], paragraph 19:
          
 
 
          
 Current wording says:
@@ -7139,7 +7351,7 @@ predicate argument) holds."
          
 This sentences makes use of the undefined term "Eliminates". Although it
 is, to a certain degree, reasonable to consider the term "eliminate"
 synonymous with "erase", using "Erase" in the first place, as the
-wording of 23.2.4.4 [list.ops], paragraph 15 does, would be clearer.
          
+wording of 23.3.4.4 [list.ops], paragraph 15 does, would be clearer.
          
 
 
          
 The range of the elements referred to by iterator i is "[first + 1,
@@ -7156,7 +7368,7 @@ The same problems as pointed out in DR 202 (equivalence relation / order
 of arguments for pred()) apply to this paragraph.
          
 
 
          
-23.2.4.4 [list.ops], paragraph 20:
+23.3.4.4 [list.ops], paragraph 20:
 
          
 
 
          
@@ -7173,7 +7385,7 @@ expressions ( "*i == *(i - 1)", "pred(*i, *(i -1))" ).
 
          
 
 
          
-23.2.4.4 [list.ops], paragraph 21:
          
+23.3.4.4 [list.ops], paragraph 21:
          
 
 
          
 Current wording says:
@@ -7212,7 +7424,7 @@ of DR 202, no impact on current code is expected.
          
 3) Proposed fixes:
          
 
 
          
-Change 23.2.4.4 [list.ops], paragraph 19 to:
          
+Change 23.3.4.4 [list.ops], paragraph 19 to:
          
 
 
          
 "Effect: Erases all but the first element from every consecutive group
@@ -7231,7 +7443,7 @@ wording need also additional review.
 b) "Erases" refers in the author's opinion unambiguously to the member
 function "erase". In case there is doubt this might not be unamgibuous,
 a direct reference to the member function "erase" is suggested [Note:
-This would also imply a change of 23.2.4.4 [list.ops], paragraph
+This would also imply a change of 23.3.4.4 [list.ops], paragraph
 15.].
 c) The expression "(i - 1)" was left, but is expected that DR submitted
 by Thomas Mang regarding invalid iterator arithmetic expressions will
@@ -7251,7 +7463,7 @@ elements consists of only a single element, this element is also
 considered the first element."
          
 
 
          
-Change 23.2.4.4 [list.ops], paragraph 20 to:
          
+Change 23.3.4.4 [list.ops], paragraph 20 to:
          
 
 
          
 "Throws: Nothing unless an exception is thrown by *(i-1) == *i or
@@ -7262,7 +7474,7 @@ Comments to the new wording:
          
 
 
          
 a) The wording regarding the conditions is identical to proposed
-23.2.4.4 [list.ops], paragraph 19. If 23.2.4.4 [list.ops],
+23.3.4.4 [list.ops], paragraph 19. If 23.3.4.4 [list.ops],
 paragraph 19 is resolved in another way, the proposed wording need also
 additional review.
 b) The expression "(i - 1)" was left, but is expected that DR submitted
@@ -7271,7 +7483,7 @@ take this into account.
 c) Typos fixed.
          
 
 
          
-Change 23.2.4.4 [list.ops], paragraph 21 to:
          
+Change 23.3.4.4 [list.ops], paragraph 21 to:
          
 
 
          
 "Complexity: If empty() == false, exactly size() - 1 applications of the
@@ -7312,8 +7524,8 @@ harm.
          
 
 
          
 
          493. Undefined Expression in Input Iterator Note Title
          
-
          Section: 24.1.1 [input.iterators] Status: NAD
- Submitter: Chris Jefferson Date: 2004-12-13
          
+
          Section: 24.2.2 [input.iterators] Status: NAD
+ Submitter: Chris Jefferson Opened: 2004-12-13  Last modified: 2006-12-27
          
 
          View all other issues in [input.iterators].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -7352,8 +7564,9 @@ not guarantee the substitution property or referential transparency).
          
 
 
          
 
          494. Wrong runtime complexity for associative container's insert and delete
          
-
          Section: 23.1.4 [associative.reqmts] Status: NAD
- Submitter: Hans B os Date: 2004-12-19
          
+
          Section: 23.2.4 [associative.reqmts] Status: NAD
+ Submitter: Hans B os Opened: 2004-12-19  Last modified: 2006-12-27
          
+
          View other active issues in [associative.reqmts].
          
 
          View all other issues in [associative.reqmts].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -7410,8 +7623,8 @@ last) and insert(first, last).
          
 
 
          
 
          499. Std. doesn't seem to require stable_sort() to be stable!
          
-
          Section: 25.3.1.2 [stable.sort] Status: NAD Editorial
- Submitter: Prateek Karandikar Date: 2005-04-12
          
+
          Section: 25.5.1.2 [stable.sort] Status: NAD Editorial
+ Submitter: Prateek Karandikar Opened: 2005-04-12  Last modified: 2008-03-13
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
 
          
@@ -7480,8 +7693,8 @@ This change has already been made.
 
 
          
 
          500. do_length cannot be implemented correctly
          
-
          Section: 22.2.1.5 [locale.codecvt.byname] Status: NAD
- Submitter: Krzysztof Żelechowski Date: 2005-05-24
          
+
          Section: 22.4.1.5 [locale.codecvt.byname] Status: NAD
+ Submitter: Krzysztof Żelechowski Opened: 2005-05-24  Last modified: 2008-03-13
          
 
          View all other issues in [locale.codecvt.byname].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -7505,8 +7718,8 @@ Contradiction.
 
 
          
 
          501. Proposal: strengthen guarantees of lib.comparisons
          
-
          Section: 20.6.3 [base] Status: NAD
- Submitter: Me <anti_spam_email2003@yahoo.com> Date: 2005-06-07
          
+
          Section: 20.7.3 [base] Status: NAD
+ Submitter: Me <anti_spam_email2003@yahoo.com> Opened: 2005-06-07  Last modified: 2008-03-13
          
 
          View all other issues in [base].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -7577,8 +7790,8 @@ to detect overlapping memory situations.
 
 
          
 
          504. Integer types in pseudo-random number engine requirements
          
-
          Section: 26.4.1 [rand.req], TR1 5.1.1 [tr.rand.req] Status: NAD Editorial
- Submitter: Walter Brown Date: 2005-07-03
          
+
          Section: X [rand.req], TR1 5.1.1 [tr.rand.req] Status: NAD Editorial
+ Submitter: Walter Brown Opened: 2005-07-03  Last modified: 2008-03-13
          
 
          View all other issues in [rand.req].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
@@ -7646,8 +7859,9 @@ Portland:  Subsumed by N2111.
 
 
          
 
          506. Requirements of Distribution parameter for variate_generator
          
-
          Section: 26.4 [rand], TR1 5.1.3 [tr.rand.var] Status: NAD
- Submitter: Walter Brown Date: 2005-07-03
          
+
          Section: 26.5 [rand], TR1 5.1.3 [tr.rand.var] Status: NAD
+ Submitter: Walter Brown Opened: 2005-07-03  Last modified: 2008-03-13
          
+
          View other active issues in [rand].
          
 
          View all other issues in [rand].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -7687,8 +7901,8 @@ Marc supports having min and max to satisfy generic programming interface.
 
 
          
 
          509. Uniform_int template parameters
          
-
          Section: 26.4.8.1 [rand.dist.uni], TR1 5.1.7.1 [tr.rand.dist.iunif] Status: NAD
- Submitter: Walter Brown Date: 2005-07-03
          
+
          Section: 26.5.8.1 [rand.dist.uni], TR1 5.1.7.1 [tr.rand.dist.iunif] Status: NAD
+ Submitter: Walter Brown Opened: 2005-07-03  Last modified: 2008-03-13
          
 
          View all other issues in [rand.dist.uni].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -7728,8 +7942,8 @@ eliminated.
 
 
          
 
          510. Input_type for bernoulli_distribution
          
-
          Section: 26.4.8.2 [rand.dist.bern], TR1 5.1.7.2 [tr.rand.dist.bern] Status: NAD
- Submitter: Walter Brown Date: 2005-07-03
          
+
          Section: 26.5.8.2 [rand.dist.bern], TR1 5.1.7.2 [tr.rand.dist.bern] Status: NAD
+ Submitter: Walter Brown Opened: 2005-07-03  Last modified: 2008-03-13
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          
@@ -7759,8 +7973,8 @@ eliminated.
 
 
          
 
          511. Input_type for binomial_distribution
          
-
          Section: 26.4.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] Status: NAD
- Submitter: Walter Brown Date: 2005-07-03
          
+
          Section: 26.5.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] Status: NAD
+ Submitter: Walter Brown Opened: 2005-07-03  Last modified: 2008-03-13
          
 
          View all other issues in [rand.dist].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -7849,8 +8063,8 @@ eliminated.
 
 
          
 
          512. Seeding subtract_with_carry_01 from a single unsigned long
          
-
          Section: 26.4.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] Status: NAD Editorial
- Submitter: Walter Brown Date: 2005-07-03
          
+
          Section: 26.5.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] Status: NAD Editorial
+ Submitter: Walter Brown Opened: 2005-07-03  Last modified: 2008-03-13
          
 
          View all other issues in [rand.eng].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
@@ -7939,8 +8153,8 @@ Portland:  Subsumed by N2111.
 
 
          
 
          513. Size of state for subtract_with_carry_01
          
-
          Section: 26.4.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] Status: NAD Editorial
- Submitter: Walter Brown Date: 2005-07-03
          
+
          Section: 26.5.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] Status: NAD Editorial
+ Submitter: Walter Brown Opened: 2005-07-03  Last modified: 2008-03-13
          
 
          View all other issues in [rand.eng].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
@@ -7992,8 +8206,8 @@ Berlin: N1932 adopts the proposed NAD.
 
 
          
 
          514. Size of state for subtract_with_carry
          
-
          Section: 26.4.3.3 [rand.eng.sub], TR1 5.1.4.3 [tr.rand.eng.sub] Status: NAD Editorial
- Submitter: Walter Brown Date: 2005-07-03
          
+
          Section: 26.5.3.3 [rand.eng.sub], TR1 5.1.4.3 [tr.rand.eng.sub] Status: NAD Editorial
+ Submitter: Walter Brown Opened: 2005-07-03  Last modified: 2008-03-13
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
 
          
@@ -8037,8 +8251,8 @@ Berlin: N1932 adopts the proposed NAD.
 
 
          
 
          515. Random number engine traits
          
-
          Section: 26.4.2 [rand.synopsis], TR1 5.1.2 [tr.rand.synopsis] Status: NAD
- Submitter: Walter Brown Date: 2005-07-03
          
+
          Section: 26.5.1 [rand.synopsis], TR1 5.1.2 [tr.rand.synopsis] Status: NAD
+ Submitter: Walter Brown Opened: 2005-07-03  Last modified: 2008-03-13
          
 
          View all other issues in [rand.synopsis].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -8111,8 +8325,8 @@ covers this.  Already in WP.
 
 
          
 
          516. Seeding subtract_with_carry_01 using a generator
          
-
          Section: 26.4.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] Status: NAD Editorial
- Submitter: Walter Brown Date: 2005-07-03
          
+
          Section: 26.5.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] Status: NAD Editorial
+ Submitter: Walter Brown Opened: 2005-07-03  Last modified: 2008-03-13
          
 
          View all other issues in [rand.eng].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
@@ -8149,8 +8363,8 @@ Portland:  Subsumed by N2111.
 
 
          
 
          517. Should include name in external representation
          
-
          Section: 26.4.1 [rand.req], TR1 5.1.1 [tr.rand.req] Status: NAD
- Submitter: Walter Brown Date: 2005-07-03
          
+
          Section: X [rand.req], TR1 5.1.1 [tr.rand.req] Status: NAD
+ Submitter: Walter Brown Opened: 2005-07-03  Last modified: 2008-03-13
          
 
          View all other issues in [rand.req].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -8187,8 +8401,8 @@ Berlin: N1932 considers this NAD. This is a QOI issue.
 
 
          
 
          525. type traits definitions not clear
          
-
          Section: 20.5.4 [meta.unary], TR1 4.5 [tr.meta.unary] Status: NAD Editorial
- Submitter: Robert Klarer Date: 2005-07-11
          
+
          Section: 20.6.4 [meta.unary], TR1 4.5 [tr.meta.unary] Status: NAD Editorial
+ Submitter: Robert Klarer Opened: 2005-07-11  Last modified: 2008-03-13
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
 
          
@@ -8222,8 +8436,9 @@ in the WP.
 
 
          
 
          526. Is it undefined if a function in the standard changes in parameters?
          
-
          Section: 23.1.3 [sequence.reqmts] Status: NAD
- Submitter: Chris Jefferson Date: 2005-09-14
          
+
          Section: 23.2.3 [sequence.reqmts] Status: NAD
+ Submitter: Chris Jefferson Opened: 2005-09-14  Last modified: 2008-03-13
          
+
          View other active issues in [sequence.reqmts].
          
 
          View all other issues in [sequence.reqmts].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -8357,8 +8572,8 @@ doesn't give permission for it not to work.
 
        42. list::remove(value) is required to work because the standard
 doesn't give permission for it not to work.
          43. 
 
        43. vector::insert(iter, iter, iter) is not required to work because
-23.1.3 [sequence.reqmts], p4 says so.
          44. 
-
        44. copy has to work, except where 25.2.1 [alg.copy] says
+23.2.3 [sequence.reqmts], p4 says so.
          45. 
+
        45. copy has to work, except where 25.4.1 [alg.copy] says
 it doesn't have to work.  While a language lawyer can tear this wording apart,
 it is felt that the wording is not prone to accidental interpretation.
          46. 
 
        46. The current working draft provide exceptions for the unordered associative
@@ -8372,9 +8587,8 @@ template insert functions from self referencing.
          47. 
 
 
          
 
          528. const_iterator iterator issue when they are the same type
          
-
          Section: 23.4 [unord], TR1 6.3.4 [tr.unord.unord] Status: NAD
- Submitter: Paolo Carlini Date: 2005-10-12
          
-
          View other active issues in [unord].
          
+
          Section: 23.5 [unord], TR1 6.3.4 [tr.unord.unord] Status: NAD
+ Submitter: Paolo Carlini Opened: 2005-10-12  Last modified: 2008-03-13
          
 
          View all other issues in [unord].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -8449,8 +8663,8 @@ chapter 17 wording.
 
 
          
 
          529. The standard encourages redundant and confusing preconditions
          
-
          Section: 17.4.3.10 [res.on.required] Status: NAD Editorial
- Submitter: David Abrahams Date: 2005-10-25
          
+
          Section: 17.6.3.11 [res.on.required] Status: NAD Editorial
+ Submitter: David Abrahams Opened: 2005-10-25  Last modified: 2008-03-13
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
 
          
@@ -8543,9 +8757,10 @@ Alan provided the survey
 
 
          
 
          532. Tuple comparison
          
-
          Section: 20.4.1.6 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] Status: Pending NAD Editorial
- Submitter: David Abrahams Date: 2005-11-29
          
-
          View all issues with Pending NAD Editorial status.
          
+
          Section: 20.5.2.5 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] Status: NAD Editorial
+ Submitter: David Abrahams Opened: 2005-11-29  Last modified: 2008-09-23
          
+
          View all other issues in [tuple.rel].
          
+
          View all issues with NAD Editorial status.
          
 
          Duplicate of: 348
          
 
          Discussion:
          
 
          
@@ -8612,14 +8827,24 @@ algorithms). Dietmar will survey and work up proposed wording.
 Recommend NAD.  This will be fixed with the next revision of concepts.
 
          
 
+
          [
+San Francisco:
+]
          
+
+
+
          
+Solved by
+N2770.
+
          
+
 
 
 
 
 
          
 
          536. Container iterator constructor and explicit convertibility
          
-
          Section: 23.1 [container.requirements] Status: Dup
- Submitter: Joaquín M López Muńoz Date: 2005-12-17
          
+
          Section: 23.2 [container.requirements] Status: Dup
+ Submitter: Joaquín M López Muńoz Opened: 2005-12-17  Last modified: 2007-04-18
          
 
          View other active issues in [container.requirements].
          
 
          View all other issues in [container.requirements].
          
 
          View all issues with Dup status.
          
@@ -8691,7 +8916,8 @@ Berlin: Some support, not universal, for respecting the explicit qualifier.
 
          
 
          544. minor NULL problems in C.2
          
 
          Section: C.2 [diff.library] Status: NAD Editorial
- Submitter: Martin Sebor Date: 2005-11-25
          
+ Submitter: Martin Sebor Opened: 2005-11-25  Last modified: 2007-04-24
          
+
          View all other issues in [diff.library].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
 
          
@@ -8734,8 +8960,9 @@ Portland:  Resolution is considered editorial.  It will be incorporated into the
 
 
          
 
          547. division should be floating-point, not integer
          
-
          Section: 26.4 [rand], TR1 5.1 [tr.rand] Status: NAD
- Submitter: Matt Austern Date: 2006-01-10
          
+
          Section: 26.5 [rand], TR1 5.1 [tr.rand] Status: NAD
+ Submitter: Matt Austern Opened: 2006-01-10  Last modified: 2007-04-18
          
+
          View other active issues in [rand].
          
 
          View all other issues in [rand].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -8767,8 +8994,9 @@ Recommend NAD as the affected section is now gone and so the issue is moot.
 
 
          
 
          548. May random_device block?
          
-
          Section: 26.4.6 [rand.device], TR1 5.1.6 [tr.rand.device] Status: NAD
- Submitter: Matt Austern Date: 2006-01-10
          
+
          Section: 26.5.6 [rand.device], TR1 5.1.6 [tr.rand.device] Status: NAD
+ Submitter: Matt Austern Opened: 2006-01-10  Last modified: 2007-10-18
          
+
          View all other issues in [rand.device].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          
@@ -8809,8 +9037,8 @@ Adopt the proposed resolution in
 
 
          
 
          549. Undefined variable in binomial_distribution
          
-
          Section: 26.4.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] Status: NAD Editorial
- Submitter: Matt Austern Date: 2006-01-10
          
+
          Section: 26.5.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] Status: NAD Editorial
+ Submitter: Matt Austern Opened: 2006-01-10  Last modified: 2007-04-24
          
 
          View all other issues in [rand.dist].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
@@ -8838,8 +9066,8 @@ Portland:  Subsumed by N2111.
 
 
          
 
          553. very minor editorial change intptr_t / uintptr_t
          
-
          Section: 18.3.1 [cstdint.syn], TR1 8.22.1 [tr.c99.cstdint.syn] Status: NAD Editorial
- Submitter: Paolo Carlini Date: 2006-01-30
          
+
          Section: 18.4.1 [cstdint.syn], TR1 8.22.1 [tr.c99.cstdint.syn] Status: NAD Editorial
+ Submitter: Paolo Carlini Opened: 2006-01-30  Last modified: 2007-07-02
          
 
          View all other issues in [cstdint.syn].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
@@ -8855,7 +9083,7 @@ probably should, consistently with C99, 7.18.1.4.
 
 
          Proposed resolution:
          
 
          
-Change 18.3.1 [cstdint.syn]:
+Change 18.4.1 [cstdint.syn]:
 
          
 
 
          ...
@@ -8876,8 +9104,8 @@ Recommend NAD and fix as editorial with the proposed resolution.
 
 
          
 
          554. Problem with lwg DR 184 numeric_limits<bool>
          
-
          Section: 18.2.1.5 [numeric.special] Status: NAD
- Submitter: Howard Hinnant Date: 2006-01-29
          
+
          Section: 18.3.1.5 [numeric.special] Status: NAD
+ Submitter: Howard Hinnant Opened: 2006-01-29  Last modified: 2007-01-15
          
 
          View all other issues in [numeric.special].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -8943,7 +9171,7 @@ value that will trap.
 
          
 
          555. TR1, 8.21/1: typo
          
 
          Section: TR1 8.21 [tr.c99.boolh] Status: NAD Editorial
- Submitter: Paolo Carlini Date: 2006-02-02
          
+ Submitter: Paolo Carlini Opened: 2006-02-02  Last modified: 2007-04-24
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
 
          
@@ -8971,10 +9199,85 @@ Redmond:  Editorial.
 
 
 
+
          
+
          556. is Compare a BinaryPredicate?
          
+
          Section: 25.5 [alg.sorting] Status: NAD Editorial
+ Submitter: Martin Sebor Opened: 2006-02-05  Last modified: 2008-09-26
          
+
          View all other issues in [alg.sorting].
          
+
          View all issues with NAD Editorial status.
          
+
          Discussion:
          
+
          
+In 25, p8 we allow BinaryPredicates to return a type that's convertible
+to bool but need not actually be bool. That allows predicates to return
+things like proxies and requires that implementations be careful about
+what kinds of expressions they use the result of the predicate in (e.g.,
+the expression in if (!pred(a, b)) need not be well-formed since the
+negation operator may be inaccessible or return a type that's not
+convertible to bool).
+
          
+
          
+Here's the text for reference:
+
          
+
          
+  ...if an algorithm takes BinaryPredicate binary_pred as its argument
+ and first1 and first2 as its iterator arguments, it should work
+ correctly in the construct if (binary_pred(*first1, first2)){...}.
+
          
+
+
          
+In 25.3, p2 we require that the Compare function object return true
+of false, which would seem to preclude such proxies. The relevant text
+is here:
+
          
+
          
+  Compare is used as a function object which returns true if the first
+  argument is less than the second, and false otherwise...
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+I think we could fix this by rewording 25.3, p2 to read somthing like:
+
          
+
          
+-2- Compare is used as a function object which returns
+true if the first argument a BinaryPredicate. The
+return value of the function call operator applied to an object of type
+Compare, when converted to type bool, yields true
+if the first argument of the call is less than the second, and
+false otherwise. Compare comp is used throughout for
+algorithms assuming an ordering relation. It is assumed that comp
+will not apply any non-constant function through the dereferenced iterator.
+
          
+
+
+
          [
+Portland:  Jack to define "convertible to bool" such that short circuiting isn't
+destroyed.
+]
          
+
+
+
          Rationale:
          
+
          [
+San Francisco:
+]
          
+
+
+
          
+Solved by
+(N2774).
+
          
+
+
+
+
+
+
 
          
 
          557. TR1: div(_Longlong, _Longlong) vs div(intmax_t, intmax_t)
          
-
          Section: 18.3 [cstdint], TR1 8.22 [tr.c99.cstdint] Status: NAD Editorial
- Submitter: Paolo Carlini Date: 2006-02-06
          
+
          Section: 18.4 [cstdint], TR1 8.22 [tr.c99.cstdint] Status: NAD Editorial
+ Submitter: Paolo Carlini Opened: 2006-02-06  Last modified: 2008-07-02
          
 
          View all other issues in [cstdint].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
@@ -9064,8 +9367,8 @@ may not be unique if intmax_t==_longlong.
 
 
          
 
          558. lib.input.iterators Defect
          
-
          Section: 24.1.1 [input.iterators] Status: NAD Editorial
- Submitter: David Abrahams Date: 2006-02-09
          
+
          Section: 24.2.2 [input.iterators] Status: NAD Editorial
+ Submitter: David Abrahams Opened: 2006-02-09  Last modified: 2007-04-24
          
 
          View all other issues in [input.iterators].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
@@ -9112,8 +9415,8 @@ Portland: Editorial.
 
 
          
 
          560. User-defined allocators without default constructor
          
-
          Section: 20.1.2 [allocator.requirements] Status: NAD
- Submitter: Sergey P. Derevyago Date: 2006-02-17
          
+
          Section: X [allocator.requirements] Status: NAD
+ Submitter: Sergey P. Derevyago Opened: 2006-02-17  Last modified: 2007-04-18
          
 
          View other active issues in [allocator.requirements].
          
 
          View all other issues in [allocator.requirements].
          
 
          View all issues with NAD status.
          
@@ -9251,8 +9554,8 @@ semantics of copying the allocator from one of the strings (lhs when ther
 
 
          
 
          569. Postcondition for basic_ios::clear(iostate) incorrectly stated
          
-
          Section: 27.4.4.3 [iostate.flags] Status: Dup
- Submitter: Seungbeom Kim Date: 2006-03-10
          
+
          Section: 27.5.4.3 [iostate.flags] Status: Dup
+ Submitter: Seungbeom Kim Opened: 2006-03-10  Last modified: 2006-12-30
          
 
          View all other issues in [iostate.flags].
          
 
          View all issues with Dup status.
          
 
          Duplicate of: 272
          
@@ -9290,8 +9593,8 @@ committee meant.
 
 
          
 
          570. Request adding additional explicit specializations of char_traits
          
-
          Section: 21.1 [char.traits] Status: NAD
- Submitter: Jack Reeves Date: 2006-04-06
          
+
          Section: 21.2 [char.traits] Status: NAD
+ Submitter: Jack Reeves Opened: 2006-04-06  Last modified: 2008-06-18
          
 
          View all other issues in [char.traits].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -9358,7 +9661,7 @@ Nobody has submitted the requested paper, so we move to NAD, as suggested by the
 
          
 
          571. Update C90 references to C99?
          
 
          Section: 1.2 [intro.refs] Status: NAD Editorial
- Submitter: Beman Dawes Date: 2006-04-08
          
+ Submitter: Beman Dawes Opened: 2006-04-08  Last modified: 2007-07-02
          
 
          View all other issues in [intro.refs].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
@@ -9393,8 +9696,9 @@ Recommend NAD, fixed editorially.
 
 
          
 
          572. Oops, we gave 507 WP status
          
-
          Section: 26.4 [rand], TR1 5.1 [tr.rand] Status: NAD
- Submitter: Howard Hinnant Date: 2006-04-11
          
+
          Section: 26.5 [rand], TR1 5.1 [tr.rand] Status: NAD
+ Submitter: Howard Hinnant Opened: 2006-04-11  Last modified: 2007-04-18
          
+
          View other active issues in [rand].
          
 
          View all other issues in [rand].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -9429,8 +9733,8 @@ is adopted.
 
 
          
 
          579. erase(iterator) for unordered containers should not return an iterator
          
-
          Section: 23.1.5 [unord.req] Status: NAD
- Submitter: Joaquín M López Muńoz Date: 2006-06-13
          
+
          Section: 23.2.5 [unord.req] Status: NAD
+ Submitter: Joaquín M López Muńoz Opened: 2006-06-13  Last modified: 2008-03-12
          
 
          View other active issues in [unord.req].
          
 
          View all other issues in [unord.req].
          
 
          View all issues with NAD status.
          
@@ -9517,8 +9821,8 @@ uses depend on the iterator being returned.
 
 
          
 
          583. div() for unsigned integral types
          
-
          Section: 26.7 [c.math] Status: NAD
- Submitter: Beman Dawes Date: 2006-06-15
          
+
          Section: 26.8 [c.math] Status: NAD
+ Submitter: Beman Dawes Opened: 2006-06-15  Last modified: 2007-07-25
          
 
          View all other issues in [c.math].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -9555,8 +9859,8 @@ behavior and thus does not need this treatment.
 
 
          
 
          584. missing int pow(int,int) functionality
          
-
          Section: 26.7 [c.math] Status: NAD
- Submitter: Beman Dawes Date: 2006-06-15
          
+
          Section: 26.8 [c.math] Status: NAD
+ Submitter: Beman Dawes Opened: 2006-06-15  Last modified: 2007-07-25
          
 
          View all other issues in [c.math].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -9577,7 +9881,7 @@ T power( T x, int n );
 
 
 
          Rationale:
          
-Toronto:  We already have double pow(integral, integral) from 26.7 [c.math] p11.
+Toronto:  We already have double pow(integral, integral) from 26.8 [c.math] p11.
 
 
 
@@ -9586,7 +9890,7 @@ Toronto:  We already have double pow(integral, integral) from 26.7 [c.math] p11.
 
          
 
          587. iststream ctor missing description
          
 
          Section: D.7.2.1 [depr.istrstream.cons] Status: NAD Editorial
- Submitter: Martin Sebor Date: 2006-06-22
          
+ Submitter: Martin Sebor Opened: 2006-06-22  Last modified: 2007-05-11
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
         
          
@@ -9618,8 +9922,9 @@ post Oxford: Noted that it is already fixed in
 
 
          
 
          590. Type traits implementation latitude should be removed for C++0x
          
-
          Section: 20.5 [meta], TR1 4.9 [tr.meta.req] Status: NAD Editorial
- Submitter: Beman Dawes Date: 2006-08-10
          
+
          Section: 20.6 [meta], TR1 4.9 [tr.meta.req] Status: NAD Editorial
+ Submitter: Beman Dawes Opened: 2006-08-10  Last modified: 2007-05-11
          
+
          View other active issues in [meta].
          
 
          View all other issues in [meta].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
@@ -9659,8 +9964,8 @@ current working draft.
 
 
          
 
          591. Misleading "built-in
          
-
          Section: 18.2.1.2 [numeric.limits.members] Status: NAD Editorial
- Submitter: whyglinux Date: 2006-08-08
          
+
          Section: 18.3.1.2 [numeric.limits.members] Status: NAD Editorial
+ Submitter: whyglinux Opened: 2006-08-08  Last modified: 2007-07-02
          
 
          View all other issues in [numeric.limits.members].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
@@ -9728,8 +10033,8 @@ Recommend NAD / Editorial.  The proposed resolution is accepted as editorial.
 
 
          
 
          592. Incorrect treatment of rdbuf()->close() return type
          
-
          Section: 27.8.1.9 [ifstream.members] Status: NAD Editorial
- Submitter: Christopher Kohlhoff Date: 2006-08-17
          
+
          Section: 27.9.1.9 [ifstream.members] Status: NAD Editorial
+ Submitter: Christopher Kohlhoff Opened: 2006-08-17  Last modified: 2008-07-02
          
 
          View all other issues in [ifstream.members].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
@@ -9755,7 +10060,7 @@ correct for basic_ofstream.
 
 
          Proposed resolution:
          
 
          
-Change 27.8.1.9 [ifstream.members], p5:
+Change 27.9.1.9 [ifstream.members], p5:
 
          
 
 
          
@@ -9766,7 +10071,7 @@ calls setstate(failbit) (which may throw ios_base::failure
 
          
 
 
          
-Change 27.8.1.17 [fstream.members], p5:
+Change 27.9.1.17 [fstream.members], p5:
 
          
 
 
          
@@ -9788,11 +10093,10 @@ Kona (2007): Proposed Disposition: NAD, Editorial
 
 
          
 
          594. Disadvantages of defining Swappable in terms of CopyConstructible and Assignable
          
-
          Section: 20.1.1 [utility.arg.requirements] Status: Pending NAD Editorial
- Submitter: Niels Dekker Date: 2006-11-02
          
-
          View other active issues in [utility.arg.requirements].
          
+
          Section: X [utility.arg.requirements] Status: NAD Editorial
+ Submitter: Niels Dekker Opened: 2006-11-02  Last modified: 2008-09-23
          
 
          View all other issues in [utility.arg.requirements].
          
-
          View all issues with Pending NAD Editorial status.
          
+
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
 
          
 It seems undesirable to define the Swappable requirement in terms of
@@ -9925,14 +10229,24 @@ and
 will essentially rewrite this section and provide the desired semantics.
 
          
 
+
          [
+San Francisco:
+]
          
+
+
+
          
+Solved by
+N2774.
+
          
+
 
 
 
 
 
          
 
          615. Inconsistencies in Section 21.4
          
-
          Section: 21.5 [c.strings] Status: NAD Editorial
- Submitter: Bo Persson Date: 2006-12-11
          
+
          Section: 21.6 [c.strings] Status: NAD Editorial
+ Submitter: Bo Persson Opened: 2006-12-11  Last modified: 2007-04-24
          
 
          View all other issues in [c.strings].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
@@ -9968,142 +10282,11 @@ Recommend NAD, editorial.  Send to Pete.
 
 
 
-
          
-
          625. mixed up Effects and Returns clauses
          
-
          Section: 17 [library] Status: Pending NAD Editorial
- Submitter: Martin Sebor Date: 2007-01-20
          
-
          View all other issues in [library].
          
-
          View all issues with Pending NAD Editorial status.
          
-
          Discussion:
          
-        
          
-
-Many  member functions  of  basic_string are  overloaded,
-with  some of  the  overloads taking  a string  argument,
-others  value_type*,  others size_type,  and
-others still iterators. Often, the requirements on one of
-the   overloads  are   expressed  in   the  form   of  Effects,
-Throws,      and     in      the     Working      Paper     
-(N2134)
-also Remark clauses,  while those on the rest  of the overloads
-via a reference to this overload and using a Returns clause.
-
-        
          
-        
          
-
-The  difference between  the two  forms of  specification is  that per
-17.3.1.3 [structure.specifications],  p3,  an  Effects clause  specifies
-"actions  performed  by the  functions,"  i.e., its  observable
-effects,  while a Returns  clause is  "a description  of the
-return  value(s)   of  a  function"  that  does   not  impose  any
-requirements on the function's observable effects.
-
-        
          
-        
          
-
-Since only  Notes are explicitly defined to  be informative and
-all  other paragraphs  are explicitly  defined to  be  normative, like
-Effects and Returns,  the new Remark clauses also
-impose normative requirements.
-
-        
          
-        
          
-
-So  by this  strict  reading of  the  standard there  are some  member
-functions of  basic_string that are required  to throw an
-exception under  some conditions or use specific  traits members while
-many other otherwise equivalent overloads, while obliged to return the
-same  values, aren't required  to follow  the exact  same requirements
-with regards to the observable effects.
-
-        
          
-        
          
-
-Here's an example of this  problem that was precipitated by the change
-from informative Notes to normative Remarks (presumably made to
-address 424):
-
-        
          
-        
          
-
-In the Working  Paper, find(string, size_type) contains a
-Remark  clause (which  is  just a  Note  in the  current
-standard) requiring it to use traits::eq().
-
-        
          
-        
          
-
-find(const  charT  *s,  size_type  pos) is  specified  to
-return  find(string(s), pos)  by a  Returns clause
-and so  it is not required to  use traits::eq(). However,
-the Working  Paper has  replaced the original  informative Note
-about   the  function   using  traits::length()   with  a
-normative  requirement  in  the   form  of  a  Remark.  Calling
-traits::length() may be  suboptimal, for example when the
-argument is a  very long array whose initial  substring doesn't appear
-anywhere in *this.
-
-        
          
-        
          
-
-Here's another  similar example,  one that existed  even prior  to the
-introduction of Remarks:
-
-        
          
-        
          
-
- insert(size_type  pos, string, size_type,  size_type) is
-required   to   throw   out_of_range   if   pos   >
-size().
-
-        
          
-        
          
-
-insert(size_type pos, string  str) is specified to return
-insert(pos, str, 0, npos)  by a Returns clause and
-so its  effects when pos  > size() are  strictly speaking
-unspecified.
-
-        
-        
          
-
-I  believe  a  careful   review  of  the  current  Effects  and
-Returns  clauses  is  needed  in  order to  identify  all  such
-problematic cases. In  addition, a review of the  Working Paper should
-be done to make sure that the newly introduced normative Remark
-clauses do not impose  any undesirable normative requirements in place
-of the original informative Notes.
-
-        
          
-
          [
-Batavia:  Alan and Pete to work.
-]
          
-
-
-
          [
-Bellevue:  Marked as NAD Editorial.
-]
          
-
-
-
          [
-Post-Sophia Antipolis:  Martin indicates there is still work to be done on this issue.
-Reopened.
-]
          
-
-
-
-
-
          Proposed resolution:
          
-
          
-
          
-
-
-
-
-
 
          
 
          626. new Remark clauses not documented
          
-
          Section: 17.3.1.3 [structure.specifications] Status: NAD Editorial
- Submitter: Martin Sebor Date: 2007-01-20
          
+
          Section: 17.5.1.4 [structure.specifications] Status: NAD Editorial
+ Submitter: Martin Sebor Opened: 2007-01-20  Last modified: 2008-02-25
          
+
          View other active issues in [structure.specifications].
          
 
          View all other issues in [structure.specifications].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
@@ -10111,10 +10294,10 @@ Reopened.
 
 The Remark clauses newly  introduced into the Working Paper 
 (N2134)
-are  not mentioned  in  17.3.1.3 [structure.specifications] where  we list  the
+are  not mentioned  in  17.5.1.4 [structure.specifications] where  we list  the
 meaning  of Effects, Requires,  and other  clauses (with
 the exception  of Notes which are documented  as informative in
-17.3.1.1 [structure.summary], p2, and which they replace in many cases).
+17.5.1.2 [structure.summary], p2, and which they replace in many cases).
 
         
          
         
          
@@ -10143,8 +10326,8 @@ Bellevue: Already resolved in current working paper.
 
 
          
 
          627. Low memory and exceptions
          
-
          Section: 18.5.1.1 [new.delete.single] Status: NAD
- Submitter: P.J. Plauger Date: 2007-01-23
          
+
          Section: 18.6.1.1 [new.delete.single] Status: NAD
+ Submitter: P.J. Plauger Opened: 2007-01-23  Last modified: 2008-02-25
          
 
          View all other issues in [new.delete.single].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -10153,7 +10336,7 @@ I recognize the need for nothrow guarantees in the exception reporting
 mechanism, but I strongly believe that implementors also need an escape hatch
 when memory gets really low. (Like, there's not enough heap to construct and
 copy exception objects, or not enough stack to process the throw.) I'd like to
-think we can put this escape hatch in 18.5.1.1 [new.delete.single],
+think we can put this escape hatch in 18.6.1.1 [new.delete.single],
 operator new, but I'm not sure how to do it. We need more than a
 footnote, but the wording has to be a bit vague. The idea is that if
 new can't allocate something sufficiently small, it has the right to
@@ -10176,13 +10359,112 @@ its resource limits", so no further escape hatch is necessary.
 
 
 
          
-
          633. Return clause mentions undefined "type()"
          
-
          Section: 20.6.15.2.5 [func.wrap.func.targ] Status: NAD Editorial
- Submitter: Daniel Krügler Date: 2007-02-03
          
+
          631. conflicting requirements for BinaryPredicate
          
+
          Section: 25 [algorithms] Status: NAD Editorial
+ Submitter: James Kanze Opened: 2007-01-31  Last modified: 2008-09-26
          
+
          View all other issues in [algorithms].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
 
          
-20.6.15.2.5 [func.wrap.func.targ], p4 says:
+The general requirements for BinaryPredicate (in 25 [algorithms]/8) contradict the implied specific requirements for
+some functions. In particular, it says that:
+
          
+
+
          
+[...] if an algorithm takes BinaryPredicate binary_pred
+as its argument and first1 and first2 as its
+iterator arguments, it should work correctly in the construct if
+(binary_pred (*first1 , *first2 )){...}.
+BinaryPredicate always takes the first iterator type as its
+first argument, that is, in those cases when T value is
+part of the signature, it should work correctly in the context of if
+(binary_pred (*first1 , value)){...}.
+
          
+
+
          
+In the description of upper_bound (25.5.3.2 [upper.bound]/2), however, the use is described as
+"!comp(value, e)", where e is an
+element of the sequence (a result of dereferencing
+*first).
+
          
+
+
          
+In the description of lexicographical_compare, we have both
+"*first1 < *first2" and "*first2
+< *first1" (which presumably implies "comp(
+*first1, *first2 )" and "comp( *first2,
+*first1 )".
+
          
+
+
          [
+Toronto:  Moved to Open.  ConceptGCC seems to get lower_bound
+and upper_bound to work withoutt these changes.
+]
          
+
+
+
+
+
          Proposed resolution:
          
+
          
+Logically, the BinaryPredicate is used as an ordering
+relationship, with the semantics of "less than".  Depending on the
+function, it may be used to determine equality, or any of the inequality
+relationships; doing this requires being able to use it with either
+parameter first.  I would thus suggest that the requirement be:
+
          
+
+
          
+[...] BinaryPredicate always takes the first iterator
+value_type as one of its arguments, it is unspecified which. If
+an algorithm takes BinaryPredicate binary_pred as its
+argument and first1 and first2 as its
+iterator arguments, it should work correctly both in the construct
+if (binary_pred (*first1 , *first2 )){...} and
+if (binary_pred (*first2, *first1)){...}.  In
+those cases when T value is part of the signature, it
+should work correctly in the context of if (binary_pred
+(*first1 , value)){...} and of if (binary_pred
+(value, *first1)){...}. [Note: if the two
+types are not identical, and neither is convertable to the other, this
+may require that the BinaryPredicate be a functional object
+with two overloaded operator()() functions. --end note]
+
          
+
+
          
+Alternatively, one could specify an order for each function. IMHO, this
+would be more work for the committee, more work for the implementors,
+and of no real advantage for the user: some functions, such as
+lexicographical_compare or equal_range, will still require both
+functions, and it seems like a much easier rule to teach that both
+functions are always required, rather than to have a complicated list of
+when you only need one, and which one.
+
          
+
+
+
          Rationale:
          
+
          [
+post San Francisco:
+]
          
+
+
+
          
+Solved by
+N2759.
+
          
+
+
+
+
+
+
+
          
+
          633. Return clause mentions undefined "type()"
          
+
          Section: 20.7.16.2.5 [func.wrap.func.targ] Status: NAD Editorial
+ Submitter: Daniel Krügler Opened: 2007-02-03  Last modified: 2007-07-02
          
+
          View all issues with NAD Editorial status.
          
+
          Discussion:
          
+
          
+20.7.16.2.5 [func.wrap.func.targ], p4 says:
 
          
 
          
 Returns: If type() == typeid(T), a pointer to the stored
@@ -10198,7 +10480,7 @@ function type() in class template function nor in the global or
 
        47. 
 Assuming that type should have been target_type(),
 this description would lead to false results, if T = cv
-void due to returns clause 20.6.15.2.5 [func.wrap.func.targ], p1.
+void due to returns clause 20.7.16.2.5 [func.wrap.func.targ], p1.
 
          48. 
 
 
@@ -10206,7 +10488,7 @@ void due to returns clause 20.6.15.2.5 [func.wrap.func.targ], p1.
 
 
          Proposed resolution:
          
 
          
-Change 20.6.15.2.5 [func.wrap.func.targ], p4:
+Change 20.7.16.2.5 [func.wrap.func.targ], p4:
 
          
 
 
          
@@ -10227,8 +10509,8 @@ Pete: Agreed. It's editorial, so I'll fix it.
 
 
          
 
          636. 26.5.2.3 valarray::operator[]
          
-
          Section: 26.5.2.3 [valarray.access] Status: NAD Editorial
- Submitter: Bo Persson Date: 2007-02-11
          
+
          Section: 26.6.2.3 [valarray.access] Status: NAD Editorial
+ Submitter: Bo Persson Opened: 2007-02-11  Last modified: 2007-07-02
          
 
          View all other issues in [valarray.access].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
@@ -10256,13 +10538,13 @@ Pete recommends editorial fix.
 
 
          
 
          637. [c.math]/10 inconsistent return values
          
-
          Section: 26.7 [c.math] Status: NAD Editorial
- Submitter: Bo Persson Date: 2007-02-13
          
+
          Section: 26.8 [c.math] Status: NAD Editorial
+ Submitter: Bo Persson Opened: 2007-02-13  Last modified: 2007-07-26
          
 
          View all other issues in [c.math].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
 
          
-26.7 [c.math], paragraph 10 has long lists of added signatures for float and long double 
+26.8 [c.math], paragraph 10 has long lists of added signatures for float and long double 
 functions. All the signatures have float/long double return values, which is 
 inconsistent with some of the double functions they are supposed to 
 overload.
@@ -10271,7 +10553,7 @@ overload.
 
 
          Proposed resolution:
          
 
          
-Change 26.7 [c.math], paragraph 10,
+Change 26.8 [c.math], paragraph 10,
 
          
 
 
          float int ilogb(float);
@@ -10293,13 +10575,13 @@ Change 26.7 [c.math], paragraph 10,
 
 
          
 
          639. Still problems with exceptions during streambuf IO
          
-
          Section: 27.6.1.2.3 [istream::extractors], 27.6.2.6.3 [ostream.inserters] Status: NAD
- Submitter: Daniel Krügler Date: 2007-02-17
          
+
          Section: 27.7.1.2.3 [istream::extractors], 27.7.2.6.3 [ostream.inserters] Status: NAD
+ Submitter: Daniel Krügler Opened: 2007-02-17  Last modified: 2007-10-10
          
 
          View all other issues in [istream::extractors].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          
-There already exist two active DR's for the wording of 27.6.1.2.3 [istream::extractors]/13
+There already exist two active DR's for the wording of 27.7.1.2.3 [istream::extractors]/13
 from 14882:2003(E), namely 64 and 413.
 
          
 
@@ -10349,7 +10631,7 @@ Is this behaviour by design?
 
          
 
 
          
-I would like to add that its output counterpart in 27.6.2.6.3 [ostream.inserters]/7-9
+I would like to add that its output counterpart in 27.7.2.6.3 [ostream.inserters]/7-9
 (also
 N2134) does not demonstrate such an exception-loss-behaviour.
 On the other side, I wonder concerning several subtle differences
@@ -10365,7 +10647,7 @@ compared to input::
 
 
          
 Note that there is nothing mentioned which would imply that such
-an exception will be caught compared to 27.6.1.2.3 [istream::extractors]/14.
+an exception will be caught compared to 27.7.1.2.3 [istream::extractors]/14.
 
          
 
 
          
@@ -10390,7 +10672,7 @@ imply that such an exception *should* be caught before.
 
 
          Proposed resolution:
          
 
          
-(a) In 27.6.1.2.3 [istream::extractors]/15 (N2134) change the sentence
+(a) In 27.7.1.2.3 [istream::extractors]/15 (N2134) change the sentence
 
          
 
 
          
@@ -10405,7 +10687,7 @@ caught exception is rethrown.
 
          
 
 
          
-(b) In 27.6.2.6.3 [ostream.inserters]/8 (N2134) change the sentence:
+(b) In 27.7.2.6.3 [ostream.inserters]/8 (N2134) change the sentence:
 
          
 
 
          
@@ -10437,14 +10719,13 @@ input functions because that applies to the case in which badbit is set.
 
 
          
 
          641. Editorial fix for 27.6.4 (N2134)
          
-
          Section: 27.6.4 [ext.manip] Status: NAD Editorial
- Submitter: Daniel Krügler Date: 2007-02-18
          
-
          View other active issues in [ext.manip].
          
+
          Section: 27.7.4 [ext.manip] Status: NAD Editorial
+ Submitter: Daniel Krügler Opened: 2007-02-18  Last modified: 2007-07-02
          
 
          View all other issues in [ext.manip].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
 
          
-The function f in para 4 (27.6.4 [ext.manip]) references an unknown strm
+The function f in para 4 (27.7.4 [ext.manip]) references an unknown strm
 in the following line:
 
          
 
@@ -10454,7 +10735,7 @@ in the following line:
 
 
          Proposed resolution:
          
 
          
-Change 27.6.4 [ext.manip], p4:
+Change 27.7.4 [ext.manip], p4:
 
          
 
 
          mg.get(Iter(str.rdbuf()), Iter(), intl, strm, err, mon);
@@ -10472,8 +10753,8 @@ Oxford:  Editorial.
 
 
          
 
          642. Invalidated fstream footnotes in N2134
          
-
          Section: 27.8.1.9 [ifstream.members], 27.8.1.13 [ofstream.members] Status: NAD Editorial
- Submitter: Daniel Krügler Date: 2007-02-20
          
+
          Section: 27.9.1.9 [ifstream.members], 27.9.1.13 [ofstream.members] Status: NAD Editorial
+ Submitter: Daniel Krügler Opened: 2007-02-20  Last modified: 2007-07-02
          
 
          View all other issues in [ifstream.members].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
@@ -10520,7 +10801,7 @@ they where needed for that time).
 
 
          Proposed resolution:
          
 
          
-In 27.8.1.9 [ifstream.members], remove footnote:
+In 27.9.1.9 [ifstream.members], remove footnote:
 
          
 
 
          
@@ -10528,7 +10809,7 @@ In 27.8.1.9 [ifstream.members], remove footnote:
 
          
 
 
          
-In 27.8.1.13 [ofstream.members], remove footnote:
+In 27.9.1.13 [ofstream.members], remove footnote:
 
          
 
 
          
@@ -10542,17 +10823,17 @@ In 27.8.1.13 [ofstream.members], remove footnote:
 
 
          
 
          645. Missing members in match_results
          
-
          Section: 28.10 [re.results] Status: NAD Editorial
- Submitter: Daniel Krügler Date: 2007-02-26
          
+
          Section: 28.11 [re.results] Status: NAD Editorial
+ Submitter: Daniel Krügler Opened: 2007-02-26  Last modified: 2008-03-12
          
 
          View all other issues in [re.results].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
 
          
-According to the description given in 28.10 [re.results]/2 the class template
+According to the description given in 28.11 [re.results]/2 the class template
 match_results "shall satisfy the requirements of a Sequence, [..],
 except that only operations defined for const-qualified Sequences
 are supported".
-Comparing the provided operations from 28.10 [re.results]/3 with the
+Comparing the provided operations from 28.11 [re.results]/3 with the
 sequence/container tables 80 and 81 one recognizes the following
 missing operations:
 
          
@@ -10598,7 +10879,7 @@ should be added according to tables 80/81.
 
 
          Proposed resolution:
          
 
          
-Add the following members to the match_results synopsis after end() in 28.10 [re.results]
+Add the following members to the match_results synopsis after end() in 28.11 [re.results]
 para 3:
 
          
 
@@ -10607,7 +10888,7 @@ const_iterator cend() const;
 
          
 
 
          
-In section 28.10.3 [re.results.acc] change:
+In section 28.11.3 [re.results.acc] change:
 
          
 
 
          
@@ -10649,12 +10930,12 @@ Bellevue:  Proposed wording now in the WP.
 
 
          
 
          647. Inconsistent regex_search params
          
-
          Section: 28.11.3 [re.alg.search] Status: NAD Editorial
- Submitter: Daniel Krügler Date: 2007-02-26
          
+
          Section: 28.12.3 [re.alg.search] Status: NAD Editorial
+ Submitter: Daniel Krügler Opened: 2007-02-26  Last modified: 2007-07-26
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
 
          
-28.11.3 [re.alg.search]/5 declares
+28.12.3 [re.alg.search]/5 declares
 
          
 
 
          template <class iterator, class charT, class traits>
@@ -10668,7 +10949,7 @@ bool regex_search(iterator first, iterator last,
 where it's not explained, which iterator category
 the parameter iterator belongs to. This is inconsistent
 to the preceding declaration in the synopsis section
-28.4 [re.syn], which says:
+28.5 [re.syn], which says:
 
          
 
 
          template <class BidirectionalIterator, class charT, class traits>
@@ -10681,7 +10962,7 @@ bool regex_search(BidirectionalIterator first, BidirectionalIterator last,
 
 
          Proposed resolution:
          
 
          
-In 28.11.3 [re.alg.search]/5 replace all three occurences of param "iterator" with
+In 28.12.3 [re.alg.search]/5 replace all three occurences of param "iterator" with
 "BidirectionalIterator"
 
          
 
@@ -10709,12 +10990,12 @@ Applied to working paper while issue was still in New status.
 
 
          
 
          648. regex_iterator c'tor needs clarification/editorial fix
          
-
          Section: 28.12.1.1 [re.regiter.cnstr] Status: NAD Editorial
- Submitter: Daniel Krügler Date: 2007-03-03
          
+
          Section: 28.13.1.1 [re.regiter.cnstr] Status: NAD Editorial
+ Submitter: Daniel Krügler Opened: 2007-03-03  Last modified: 2007-07-02
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
 
          
-In 28.12.1.1 [re.regiter.cnstr]/2 the effects paragraph starts with:
+In 28.13.1.1 [re.regiter.cnstr]/2 the effects paragraph starts with:
 
          
 
 
          
@@ -10744,7 +11025,7 @@ fix.
 
 
          Proposed resolution:
          
 
          
-In 28.12.1.1 [re.regiter.cnstr]/2 change the above quoted part by
+In 28.13.1.1 [re.regiter.cnstr]/2 change the above quoted part by
 
          
 
 
          
@@ -10763,13 +11044,13 @@ constructor sets *this to the end-of-sequence iterator.
 
 
          
 
          649. Several typos in regex_token_iterator constructors
          
-
          Section: 28.12.2.1 [re.tokiter.cnstr] Status: NAD Editorial
- Submitter: Daniel Krügler Date: 2007-03-03
          
+
          Section: 28.13.2.1 [re.tokiter.cnstr] Status: NAD Editorial
+ Submitter: Daniel Krügler Opened: 2007-03-03  Last modified: 2007-07-02
          
 
          View all other issues in [re.tokiter.cnstr].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
 
          
-In 28.12.2.1 [re.tokiter.cnstr]/1+2 both the constructor declaration
+In 28.13.2.1 [re.tokiter.cnstr]/1+2 both the constructor declaration
 and the following text shows some obvious typos:
 
          
 
          
@@ -10819,7 +11100,7 @@ by the parameter "m".
 
 
          Proposed resolution:
          
 
          
-Change 28.12.2.1 [re.tokiter.cnstr]/1:
+Change 28.13.2.1 [re.tokiter.cnstr]/1:
 
          
 
          template <std::size_t N>
   regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b, 
@@ -10830,7 +11111,7 @@ Change 28.12.2.1 [re.tokiter.cnstr]/1:
 
          
 
 
          
-Change 28.12.2.1 [re.tokiter.cnstr]/2:
+Change 28.13.2.1 [re.tokiter.cnstr]/2:
 
          
 
 
          
@@ -10844,7 +11125,7 @@ pointed to by the iterator range [&submatches, &submatches +
 
          
 
 
          
-Change 28.12.2.1 [re.tokiter.cnstr]/3:
+Change 28.13.2.1 [re.tokiter.cnstr]/3:
 
          
 
 
          
@@ -10866,7 +11147,7 @@ constructor sets *this to an end-of-sequence iterator.
 
          
 
          653. Library reserved names
          
 
          Section: 1.2 [intro.refs] Status: NAD
- Submitter: Alisdair Meredith Date: 2007-03-08
          
+ Submitter: Alisdair Meredith Opened: 2007-03-08  Last modified: 2008-02-25
          
 
          View all other issues in [intro.refs].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -10951,13 +11232,13 @@ Suggest a formal paper rather than a defect report is the correct way to proceed
 
 
          
 
          656. Typo in subtract_with_carry_engine declaration
          
-
          Section: 26.4.2 [rand.synopsis] Status: NAD Editorial
- Submitter: Daniel Krügler Date: 2007-03-08
          
+
          Section: 26.5.1 [rand.synopsis] Status: NAD Editorial
+ Submitter: Daniel Krügler Opened: 2007-03-08  Last modified: 2007-07-02
          
 
          View all other issues in [rand.synopsis].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
 
          
-26.4.2 [rand.synopsis] the header <random> synopsis
+26.5.1 [rand.synopsis] the header <random> synopsis
 contains an unreasonable closing curly brace inside the
 subtract_with_carry_engine declaration.
 
          
@@ -10965,7 +11246,7 @@ contains an unreasonable closing curly brace inside the
 
 
          Proposed resolution:
          
 
          
-Change the current declaration in 26.4.2 [rand.synopsis]
+Change the current declaration in 26.5.1 [rand.synopsis]
 
          
 
 
          template <class UIntType, size_t w}, size_t s, size_t r>
@@ -10983,12 +11264,12 @@ Pete: Recommends editorial.
 
 
          
 
          657. unclear requirement about header inclusion
          
-
          Section: 17.4.2.1 [using.headers] Status: NAD
- Submitter: Gennaro Prota Date: 2007-03-14
          
+
          Section: 17.6.2.2 [using.headers] Status: NAD
+ Submitter: Gennaro Prota Opened: 2007-03-14  Last modified: 2007-10-10
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          
-17.4.2.1 [using.headers] states:
+17.6.2.2 [using.headers] states:
 
          
 
 
          
@@ -11079,13 +11360,13 @@ unlikely to be better than what's already in the standard.
 
 
          
 
          658. Two unspecified function comparators in [function.objects]
          
-
          Section: 20.6 [function.objects] Status: NAD Editorial
- Submitter: Daniel Krügler Date: 2007-03-19
          
+
          Section: 20.7 [function.objects] Status: NAD Editorial
+ Submitter: Daniel Krügler Opened: 2007-03-19  Last modified: 2007-08-05
          
 
          View all other issues in [function.objects].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
 
          
-The header <functional> synopsis in 20.6 [function.objects]
+The header <functional> synopsis in 20.7 [function.objects]
 contains the following two free comparison operator templates
 for the function class template
 
          
@@ -11099,7 +11380,7 @@ void operator!=(const function<Function1>&, const function<Function
 
          
 which are nowhere described. I assume that they are relicts before the
 corresponding two private and undefined member templates in the function
-template (see 20.6.15.2 [func.wrap.func] and X [func.wrap.func.undef]) have been introduced. The original free
+template (see 20.7.16.2 [func.wrap.func] and  [func.wrap.func.undef]) have been introduced. The original free
 function templates should be removed, because using an undefined entity
 would lead to an ODR violation of the user.
 
          
@@ -11108,7 +11389,7 @@ would lead to an ODR violation of the user.
 
          Proposed resolution:
          
 
          
 Remove the above mentioned two function templates from
-the header <functional> synopsis (20.6 [function.objects])
+the header <functional> synopsis (20.7 [function.objects])
 
          
 
 
          template<class Function1, class Function2>
@@ -11130,14 +11411,14 @@ Standard Library Applications for Deleted Functions.
 
 
          
 
          662. Inconsistent handling of incorrectly-placed thousands separators
          
-
          Section: 22.2.2.1.2 [facet.num.get.virtuals] Status: NAD
- Submitter: Cosmin Truta Date: 2007-04-05
          
+
          Section: 22.4.2.1.2 [facet.num.get.virtuals] Status: NAD
+ Submitter: Cosmin Truta Opened: 2007-04-05  Last modified: 2007-07-25
          
 
          View other active issues in [facet.num.get.virtuals].
          
 
          View all other issues in [facet.num.get.virtuals].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          
-From Section 22.2.2.1.2 [facet.num.get.virtuals], paragraphs 11 and 12, it is implied
+From Section 22.4.2.1.2 [facet.num.get.virtuals], paragraphs 11 and 12, it is implied
 that the value read from a stream must be stored
 even if the placement of thousands separators does not conform to the
 grouping() specification from the numpunct facet.
@@ -11229,7 +11510,7 @@ to remain intact when a failure occurs.
 
          Proposed resolution:
          
 
 
          
-Change 22.2.2.1.2 [facet.num.get.virtuals]:
+Change 22.4.2.1.2 [facet.num.get.virtuals]:
 
          
 
 
          
@@ -11258,17 +11539,18 @@ makes this resolution obsolete.
 
 
          
 
          663. Complexity Requirements
          
-
          Section: 17.3.1.3 [structure.specifications] Status: NAD
- Submitter: Thomas Plum Date: 2007-04-16
          
+
          Section: 17.5.1.4 [structure.specifications] Status: NAD
+ Submitter: Thomas Plum Opened: 2007-04-16  Last modified: 2009-05-01
          
+
          View other active issues in [structure.specifications].
          
 
          View all other issues in [structure.specifications].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          
-17.3.1.3 [structure.specifications] para 5 says
+17.5.1.4 [structure.specifications] para 5 says
 
          
 
 
          
--5- Complexity requirements specified in the library 
+-5- Complexity requirements specified in the library
 clauses are upper bounds, and implementations that provide better
 complexity guarantees satisfy the requirements.
 
          
@@ -11281,14 +11563,14 @@ objection has been raised:
 
          
 The library clauses suggest general
 guidelines regarding complexity, but we have been unable to discover
-any absolute hard-and-fast formulae for these requirements.  Unless
+any absolute hard-and-fast formulae for these requirements. Unless
 or until the Library group standardizes specific hard-and-fast
-formulae, we regard all the complexity requirements as subject to a 
+formulae, we regard all the complexity requirements as subject to a
 "fudge factor" without any intrinsic upper bound.
 
          
 
 
          
-[Plum ref 
+[Plum ref
 _23213Y31 etc]
 
          
 
@@ -11307,14 +11589,707 @@ identified, and big-O notation always involves constant factors.
 
 
 
          
-
          683. regex_token_iterator summary error
          
-
          Section: 28.12.2 [re.tokiter] Status: Pending NAD Editorial
- Submitter: Eric Niebler Date: 2007-06-02
          
-
          View all other issues in [re.tokiter].
          
-
          View all issues with Pending NAD Editorial status.
          
+
          670. money_base::pattern and space
          
+
          Section: 22.4.6.3 [locale.moneypunct] Status: Dup
+ Submitter: Thomas Plum Opened: 2007-04-16  Last modified: 2008-09-22
          
+
          View all issues with Dup status.
          
+
          Duplicate of: 836
          
 
          Discussion:
          
 
          
-28.12.2 [re.tokiter], p3 says:
+22.4.6.3 [locale.moneypunct], para 2 says:
+
          
+
+
          
+The value space indicates that at least one space is required at 
+that position.
+
          
+
+
          
+The following objection has been raised:
+
          
+
+
          
+Whitespace is optional when matching space. (See 22.4.6.1.2 [locale.money.get.virtuals], para 2.)
+
          
+
+
          
+[Plum ref _22263Y22]
+
          
+
+
          [
+Kona (2007): Bill to provide proposed wording. We agree that C++03 is
+ambiguous, and that we want C++0X to say "space" means 0 or more
+whitespace characters on input.
+]
          
+
+
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          676. Moving the unordered containers
          
+
          Section: 23.5 [unord] Status: NAD Editorial
+ Submitter: Howard Hinnant Opened: 2007-05-05  Last modified: 2008-09-26
          
+
          View all other issues in [unord].
          
+
          View all issues with NAD Editorial status.
          
+
          Discussion:
          
+
          
+Move semantics are missing from the unordered containers.  The proposed
+resolution below adds move-support consistent with
+N1858
+and the current working draft.
+
          
+
+
          
+The current proposed resolution simply lists the requirements for each function.
+These might better be hoisted into the requirements table for unordered associative containers.
+Futhermore a mild reorganization of the container requirements could well be in order.
+This defect report is purposefully ignoring these larger issues and just focusing
+on getting the unordered containers "moved".
+
          
+
+
+
+
          Proposed resolution:
          
+
+
          
+Add to 23.5 [unord]:
+
          
+
+
          template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_map<Key, T, Hash, Pred, Alloc>& y); 
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_map<Key, T, Hash, Pred, Alloc>&& y);
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x, 
+            unordered_map<Key, T, Hash, Pred, Alloc>& y);
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x, 
+            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
+
+...
+
+template <class Value, class Hash, class Pred, class Alloc> 
+  void swap(unordered_set<Value, Hash, Pred, Alloc>& x, 
+            unordered_set<Value, Hash, Pred, Alloc>& y); 
+
+template <class Value, class Hash, class Pred, class Alloc> 
+  void swap(unordered_set<Value, Hash, Pred, Alloc>& x, 
+            unordered_set<Value, Hash, Pred, Alloc>&& y);
+
+template <class Value, class Hash, class Pred, class Alloc> 
+  void swap(unordered_set<Value, Hash, Pred, Alloc>&& x, 
+            unordered_set<Value, Hash, Pred, Alloc>& y);
+
+template <class Value, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multiset<Value, Hash, Pred, Alloc>& x, 
+            unordered_multiset<Value, Hash, Pred, Alloc>& y);
+
+template <class Value, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multiset<Value, Hash, Pred, Alloc>& x, 
+            unordered_multiset<Value, Hash, Pred, Alloc>&& y);
+
+template <class Value, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multiset<Value, Hash, Pred, Alloc>&& x, 
+            unordered_multiset<Value, Hash, Pred, Alloc>& y);
+
          
+
+
          unordered_map
          
+
+
          
+Change 23.5.1 [unord.map]:
+
          
+
+
          class unordered_map
+{
+    ...
+    unordered_map(const unordered_map&);
+    unordered_map(unordered_map&&);
+    ~unordered_map();
+    unordered_map& operator=(const unordered_map&);
+    unordered_map& operator=(unordered_map&&);
+    ...
+    // modifiers 
+    std::pair<iterator, bool> insert(const value_type& obj); 
+    template <class P> pair<iterator, bool> insert(P&& obj);
+    iterator       insert(iterator hint, const value_type& obj);
+    template <class P> iterator       insert(iterator hint, P&& obj);
+    const_iterator insert(const_iterator hint, const value_type& obj);
+    template <class P> const_iterator insert(const_iterator hint, P&& obj);
+    ...
+    void swap(unordered_map&&);
+    ...
+    mapped_type& operator[](const key_type& k);
+    mapped_type& operator[](key_type&& k);
+    ...
+};
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_map<Key, T, Hash, Pred, Alloc>& y);
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_map<Key, T, Hash, Pred, Alloc>&& y);
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x, 
+            unordered_map<Key, T, Hash, Pred, Alloc>& y);
+
          
+
+
          
+Add to 23.5.1.1 [unord.map.cnstr]:
+
          
+
+
          
+
          template <class InputIterator>
+  unordered_map(InputIterator f, InputIterator l, 
+                size_type n = implementation-defined, 
+                const hasher& hf = hasher(), 
+                const key_equal& eql = key_equal(), 
+                const allocator_type& a = allocator_type());
+
          
+
+
          
+
+Requires: If the iterator's dereference operator returns an
+lvalue or a const rvalue pair<key_type, mapped_type>,
+then both key_type and mapped_type shall be
+CopyConstructible.
+
+
          
+
          
+
+
          
+Add to 23.5.1.2 [unord.map.elem]:
+
          
+
+
          
+
+
          mapped_type& operator[](const key_type& k);
          
+
+
          
+
          ...
          
+
          
+Requires: key_type shall be CopyConstructible
+and mapped_type shall be DefaultConstructible.
+
          
+
          
+
+
          mapped_type& operator[](key_type&& k);
          
+
+
          
+
          
+Effects: If the unordered_map does not already contain an
+element whose key is equivalent to k , inserts the value
+std::pair<const key_type, mapped_type>(std::move(k), mapped_type()).
+
          
+
+
          
+Requires: mapped_type shall be DefaultConstructible.
+
          
+
+
          
+Returns: A reference to x.second, where x is the
+(unique) element whose key is equivalent to k.
+
          
+
+
          
+
+
          
+
+
          
+Add new section [unord.map.modifiers]:
+
          
+
+
          
+
          pair<iterator, bool> insert(const value_type& x);
+template <class P> pair<iterator, bool> insert(P&& x);
+iterator       insert(iterator hint, const value_type& x);
+template <class P> iterator       insert(iterator hint, P&& x);
+const_iterator insert(const_iterator hint, const value_type& x);
+template <class P> const_iterator insert(const_iterator hint, P&& x);
+template <class InputIterator>
+  void insert(InputIterator first, InputIterator last);
+
          
+
+
          
+
          
+Requires: Those signatures taking a const value_type& parameter
+requires both the key_type and the mapped_type to be
+CopyConstructible.
+
          
+
+
          
+P shall be convertible to value_type.
+ If P is instantiated as a reference
+type, then the argument x is copied from. Otherwise x
+is considered to be an rvalue as it is converted to value_type
+and inserted into the unordered_map. Specifically, in such
+cases CopyConstructible is not required of key_type or
+mapped_type unless the conversion from P specifically
+requires it (e.g. if P is a tuple<const key_type,
+mapped_type>, then key_type must be
+CopyConstructible).
+
          
+
+
          
+The signature taking InputIterator
+parameters requires CopyConstructible of both
+key_type and mapped_type if the dereferenced
+InputIterator returns an lvalue or const rvalue
+value_type.
+
          
+
+
          
+
+
          
+
+
          
+Add to 23.5.1.3 [unord.map.swap]:
+
          
+
+
          
+
          template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_map<Key, T, Hash, Pred, Alloc>& y);
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_map<Key, T, Hash, Pred, Alloc>&& y);
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x, 
+            unordered_map<Key, T, Hash, Pred, Alloc>& y);
+
          
+
          
+
+
          unordered_multimap
          
+
+
          
+Change 23.5.2 [unord.multimap]:
+
          
+
+
          class unordered_multimap
+{
+    ...
+    unordered_multimap(const unordered_multimap&);
+    unordered_multimap(unordered_multimap&&);
+    ~unordered_multimap();
+    unordered_multimap& operator=(const unordered_multimap&);
+    unordered_multimap& operator=(unordered_multimap&&);
+    ...
+    // modifiers 
+    iterator insert(const value_type& obj); 
+    template <class P> iterator insert(P&& obj);
+    iterator       insert(iterator hint, const value_type& obj);
+    template <class P> iterator       insert(iterator hint, P&& obj);
+    const_iterator insert(const_iterator hint, const value_type& obj);
+    template <class P> const_iterator insert(const_iterator hint, P&& obj);
+    ...
+    void swap(unordered_multimap&&);
+    ...
+};
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x, 
+            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
+
          
+
+
          
+Add to 23.5.2.1 [unord.multimap.cnstr]:
+
          
+
+
          
+
          template <class InputIterator>
+  unordered_multimap(InputIterator f, InputIterator l, 
+                size_type n = implementation-defined, 
+                const hasher& hf = hasher(), 
+                const key_equal& eql = key_equal(), 
+                const allocator_type& a = allocator_type());
+
          
+
+
          
+
+Requires: If the iterator's dereference operator returns an
+lvalue or a const rvalue pair<key_type, mapped_type>,
+then both key_type and mapped_type shall be
+CopyConstructible.
+
+
          
+
          
+
+
          
+Add new section [unord.multimap.modifiers]:
+
          
+
+
          
+
          iterator insert(const value_type& x);
+template <class P> iterator       insert(P&& x);
+iterator       insert(iterator hint, const value_type& x);
+template <class P> iterator       insert(iterator hint, P&& x);
+const_iterator insert(const_iterator hint, const value_type& x);
+template <class P> const_iterator insert(const_iterator hint, P&& x);
+template <class InputIterator>
+  void insert(InputIterator first, InputIterator last);
+
          
+
+
          
+
          
+Requires: Those signatures taking a const value_type& parameter
+requires both the key_type and the mapped_type to be
+CopyConstructible.
+
          
+
+
          
+P shall be convertible to value_type.
+ If P is instantiated as a reference
+type, then the argument x is copied from. Otherwise x
+is considered to be an rvalue as it is converted to value_type
+and inserted into the unordered_multimap. Specifically, in such
+cases CopyConstructible is not required of key_type or
+mapped_type unless the conversion from P specifically
+requires it (e.g. if P is a tuple<const key_type,
+mapped_type>, then key_type must be
+CopyConstructible).
+
          
+
+
          
+The signature taking InputIterator
+parameters requires CopyConstructible of both
+key_type and mapped_type if the dereferenced
+InputIterator returns an lvalue or const rvalue
+value_type.
+
          
+
          
+
+
          
+
+
          
+Add to 23.5.2.2 [unord.multimap.swap]:
+
          
+
+
          
+
          template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x, 
+            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
+
          
+
          
+
+
          unordered_set
          
+
+
          
+Change 23.5.3 [unord.set]:
+
          
+
+
          class unordered_set
+{
+    ...
+    unordered_set(const unordered_set&);
+    unordered_set(unordered_set&&);
+    ~unordered_set();
+    unordered_set& operator=(const unordered_set&);
+    unordered_set& operator=(unordered_set&&);
+    ...
+    // modifiers 
+    std::pair<iterator, bool> insert(const value_type& obj); 
+    pair<iterator, bool> insert(value_type&& obj);
+    iterator       insert(iterator hint, const value_type& obj);
+    iterator       insert(iterator hint, value_type&& obj);
+    const_iterator insert(const_iterator hint, const value_type& obj);
+    const_iterator insert(const_iterator hint, value_type&& obj);
+    ...
+    void swap(unordered_set&&);
+    ...
+};
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_set<Key, T, Hash, Pred, Alloc>& y);
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_set<Key, T, Hash, Pred, Alloc>&& y);
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_set<Key, T, Hash, Pred, Alloc>&& x, 
+            unordered_set<Key, T, Hash, Pred, Alloc>& y);
+
          
+
+
          
+Add to 23.5.3.1 [unord.set.cnstr]:
+
          
+
+
          
+
          template <class InputIterator>
+  unordered_set(InputIterator f, InputIterator l, 
+                size_type n = implementation-defined, 
+                const hasher& hf = hasher(), 
+                const key_equal& eql = key_equal(), 
+                const allocator_type& a = allocator_type());
+
          
+
+
          
+
+Requires: If the iterator's dereference operator returns an
+lvalue or a const rvalue value_type, then the
+value_type shall be CopyConstructible.
+
+
          
+
          
+
+
          
+Add new section [unord.set.modifiers]:
+
          
+
+
          
+
          pair<iterator, bool> insert(const value_type& x);
+pair<iterator, bool> insert(value_type&& x);
+iterator       insert(iterator hint, const value_type& x);
+iterator       insert(iterator hint, value_type&& x);
+const_iterator insert(const_iterator hint, const value_type& x);
+const_iterator insert(const_iterator hint, value_type&& x);
+template <class InputIterator>
+  void insert(InputIterator first, InputIterator last);
+
          
+
+
          
+
+
          
+Requires: Those signatures taking a const
+value_type& parameter requires the value_type to
+be CopyConstructible.
+
          
+
+
          
+The signature taking InputIterator parameters requires
+CopyConstructible of value_type if the dereferenced
+InputIterator returns an lvalue or const rvalue
+value_type.
+
          
+
+
          
+
+
          
+
+
          
+Add to 23.5.3.2 [unord.set.swap]:
+
          
+
+
          
+
          template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_set<Key, T, Hash, Pred, Alloc>& y);
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_set<Key, T, Hash, Pred, Alloc>&& y);
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_set<Key, T, Hash, Pred, Alloc>&& x, 
+            unordered_set<Key, T, Hash, Pred, Alloc>& y);
+
          
+
          
+
+
          unordered_multiset
          
+
+
          
+Change 23.5.4 [unord.multiset]:
+
          
+
+
          class unordered_multiset
+{
+    ...
+    unordered_multiset(const unordered_multiset&);
+    unordered_multiset(unordered_multiset&&);
+    ~unordered_multiset();
+    unordered_multiset& operator=(const unordered_multiset&);
+    unordered_multiset& operator=(unordered_multiset&&);
+    ...
+    // modifiers 
+    iterator insert(const value_type& obj); 
+    iterator insert(value_type&& obj);
+    iterator       insert(iterator hint, const value_type& obj);
+    iterator       insert(iterator hint, value_type&& obj);
+    const_iterator insert(const_iterator hint, const value_type& obj);
+    const_iterator insert(const_iterator hint, value_type&& obj);
+    ...
+    void swap(unordered_multiset&&);
+    ...
+};
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_multiset<Key, T, Hash, Pred, Alloc>&& y);
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>&& x, 
+            unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
+
          
+
+
          
+Add to 23.5.4.1 [unord.multiset.cnstr]:
+
          
+
+
          
+
          template <class InputIterator>
+  unordered_multiset(InputIterator f, InputIterator l, 
+                size_type n = implementation-defined, 
+                const hasher& hf = hasher(), 
+                const key_equal& eql = key_equal(), 
+                const allocator_type& a = allocator_type());
+
          
+
+
          
+
+Requires: If the iterator's dereference operator returns an
+lvalue or a const rvalue value_type, then the
+value_type shall be CopyConstructible.
+
+
          
+
          
+
+
          
+Add new section [unord.multiset.modifiers]:
+
          
+
+
          
+
          iterator insert(const value_type& x);
+iterator insert(value_type&& x);
+iterator       insert(iterator hint, const value_type& x);
+iterator       insert(iterator hint, value_type&& x);
+const_iterator insert(const_iterator hint, const value_type& x);
+const_iterator insert(const_iterator hint, value_type&& x);
+template <class InputIterator>
+  void insert(InputIterator first, InputIterator last);
+
          
+
+
          
+
+
          
+Requires: Those signatures taking a const
+value_type& parameter requires the value_type to
+be CopyConstructible.
+
          
+
+
          
+The signature taking InputIterator parameters requires
+CopyConstructible of value_type if the dereferenced
+InputIterator returns an lvalue or const rvalue
+value_type.
+
          
+
+
          
+
+
          
+
+
          
+Add to 23.5.4.2 [unord.multiset.swap]:
+
          
+
+
          
+
          template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_multiset<Key, T, Hash, Pred, Alloc>&& y);
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>&& x, 
+            unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
+
          
+
          
+
+
+
+
          [
+Voted to WP in Bellevue.
+]
          
+
+
+
          [
+post Bellevue, Pete notes:
+]
          
+
+
+
          
+
          
+Please remind people who are reviewing issues to check that the text
+modifications match the current draft. Issue 676, for example, adds two
+overloads for unordered_map::insert taking a hint. One takes a
+const_iterator and returns a const_iterator, and the other takes an
+iterator and returns an iterator. This was correct at the time the issue
+was written, but was changed in Toronto so there is only one hint
+overload, taking a const_iterator and returning an iterator.
+
          
+
          
+This issue is not ready. In addition to the relatively minor signature
+problem I mentioned earlier, it puts requirements in the wrong places.
+Instead of duplicating requirements throughout the template
+specifications, it should put them in the front matter that talks about
+requirements for unordered containers in general. This presentation
+problem is editorial, but I'm not willing to do the extensive rewrite
+that it requires. Please put it back into Open status.
+
          
+
          
+
+
          Rationale:
          
+
          [
+San Francisco:
+]
          
+
+
+
          
+Solved by
+N2776.
+
          
+
+
+
+
+
+
+
          
+
          683. regex_token_iterator summary error
          
+
          Section: 28.13.2 [re.tokiter] Status: NAD Editorial
+ Submitter: Eric Niebler Opened: 2007-06-02  Last modified: 2009-03-09
          
+
          View all other issues in [re.tokiter].
          
+
          View all issues with NAD Editorial status.
          
+
          Discussion:
          
+
          
+28.13.2 [re.tokiter], p3 says:
 
          
 
          
 
          
@@ -11357,13 +12332,13 @@ Yep, looks like a typo/administrative fix to me.
 
 
          
 
          684. Unclear which members of match_results should be used in comparison
          
-
          Section: 28.10 [re.results] Status: NAD Editorial
- Submitter: Nozomu Katoo Date: 2007-05-27
          
+
          Section: 28.11 [re.results] Status: NAD Editorial
+ Submitter: Nozomu Katoo Opened: 2007-05-27  Last modified: 2008-03-12
          
 
          View all other issues in [re.results].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
 
          
-In 28.4 [re.syn] of N2284, two template functions 
+In 28.5 [re.syn] of N2284, two template functions 
 are declared here: 
 
          
 
          // 28.10, class template match_results: 
@@ -11405,7 +12380,7 @@ Kona (2007): Bill and Pete to add minor wording to that proposed in
 
 
          Proposed resolution:
          
 
          
-Add a new section after 28.10.6 [re.results.swap], which reads:
+Add a new section after 28.11.6 [re.results.swap], which reads:
 
          
 
          
 28.10.7 match_results non-member functions.
@@ -11458,13 +12433,13 @@ Bellevue:  Proposed wording now in WP.
 
 
          
 
          686. Unique_ptr and shared_ptr fail to specify non-convertibility to int for unspecified-bool-type
          
-
          Section: 20.7.11.2.4 [unique.ptr.single.observers], 20.7.12.2.5 [util.smartptr.shared.obs] Status: NAD
- Submitter: Beman Dawes Date: 2007-06-14
          
+
          Section: 20.8.12.2.4 [unique.ptr.single.observers], 20.8.13.2.5 [util.smartptr.shared.obs] Status: NAD
+ Submitter: Beman Dawes Opened: 2007-06-14  Last modified: 2008-02-27
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          
 The standard library uses the operator unspecified-bool-type() const idiom in
-five places. In three of those places (20.6.15.2.3 [func.wrap.func.cap], function capacity 
+five places. In three of those places (20.7.16.2.3 [func.wrap.func.cap], function capacity 
 for example) the returned value is constrained to disallow
 unintended conversions to int. The standardese is
 
          
@@ -11492,8 +12467,8 @@ makes it irrelevant.
 
          
 To the Returns paragraph for operator unspecified-bool-type()
 const
-of 20.7.11.2.4 [unique.ptr.single.observers] paragraph 11 and
-20.7.12.2.5 [util.smartptr.shared.obs] paragraph 16, add the sentence:
+of 20.8.12.2.4 [unique.ptr.single.observers] paragraph 11 and
+20.8.13.2.5 [util.smartptr.shared.obs] paragraph 16, add the sentence:
 
          
 
          
 The return type shall not be convertible to int.
@@ -11510,13 +12485,13 @@ Kona (2007): Uncertain if nullptr will address this issue.
 
 
          
 
          690. abs(long long) should return long long
          
-
          Section: 26.7 [c.math] Status: NAD Editorial
- Submitter: Niels Dekker Date: 2007-06-10
          
+
          Section: 26.8 [c.math] Status: NAD Editorial
+ Submitter: Niels Dekker Opened: 2007-06-10  Last modified: 2007-07-25
          
 
          View all other issues in [c.math].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
 
          
-Quoting the latest draft (n2135), 26.7 [c.math]: 
+Quoting the latest draft (n2135), 26.8 [c.math]: 
 
          
 
 
          
@@ -11534,7 +12509,7 @@ Shouldn't abs(long long) have long long as return type?
 
 
          Proposed resolution:
          
 
          
-Change 26.7 [c.math]: 
+Change 26.8 [c.math]: 
 
          
 
          long long abs(long long); // llabs()
 
          
@@ -11549,9 +12524,8 @@ Had already been fixed in the WP by the time the LWG reviewed this.
 
 
          
 
          697. New <system_error> header leads to name clashes
          
-
          Section: 19.4 [syserr] Status: NAD Editorial
- Submitter: Daniel Krügler Date: 2007-06-24
          
-
          View other active issues in [syserr].
          
+
          Section: 19.5 [syserr] Status: NAD Editorial
+ Submitter: Daniel Krügler Opened: 2007-06-24  Last modified: 2008-01-06
          
 
          View all other issues in [syserr].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
@@ -11560,12 +12534,12 @@ The most recent state of
 N2241
 as well as the current draft
 N2284
-(section 19.4 [syserr], p.2) proposes a
+(section 19.5 [syserr], p.2) proposes a
 new
 enumeration type posix_errno immediatly in the namespace std. One of
 the enumerators has the name invalid_argument, or fully qualified:
 std::invalid_argument. This name clashes with the exception type
-std::invalid_argument, see 19.1 [std.exceptions]/p.3. This clash makes
+std::invalid_argument, see 19.2 [std.exceptions]/p.3. This clash makes
 e.g. the following snippet invalid:
 
          
 
@@ -11610,10 +12584,173 @@ Fixed by 704. MoveAssignable requirement for container value type overly strict
+
          Section: 23.2 [container.requirements] Status: NAD Editorial
+ Submitter: Howard Hinnant Opened: 2007-05-20  Last modified: 2008-09-26
          
+
          View other active issues in [container.requirements].
          
+
          View all other issues in [container.requirements].
          
+
          View all issues with NAD Editorial status.
          
+
          Discussion:
          
+
          
+The move-related changes inadvertently overwrote the intent of 276.
+Issue 276 removed the requirement of CopyAssignable from
+most of the member functions of node-based containers.  But the move-related changes
+unnecessarily introduced the MoveAssignable requirement for those members which used to
+require CopyAssignable.
+
          
+
+
          
+We also discussed (c++std-lib-18722) the possibility of dropping MoveAssignable
+from some of the sequence requirements.  Additionally the in-place construction
+work may further reduce requirements.  For purposes of an easy reference, here are the
+minimum sequence requirements as I currently understand them.  Those items in requirements
+table in the working draft which do not appear below have been purposefully omitted for
+brevity as they do not have any requirements of this nature.  Some items which do not
+have any requirements of this nature are included below just to confirm that they were
+not omitted by mistake.
+
          
+
+
          
   
          
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
          
+
+
+
+
+
+
+
          Container Requirements
          X u(a)value_type must be CopyConstructible
          X u(rv)array and containers with a propagate_never allocator require value_type to be MoveConstructible
          a = uSequences require value_type to be CopyConstructible and CopyAssignable.
+                               Associative containers require value_type to be CopyConstructible.
          a = rvarray requires value_type to be MoveAssignable.
+                                Sequences and Associative containers with propagate_never and propagate_on_copy_construction allocators require value_type to be MoveConstructible.
          swap(a,u)array and containers with propagate_never and
+                  propagate_on_copy_construction allocators require value_type to be Swappable.
          
+
+
          
+
          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
          Sequence Requirements
          X(n)value_type must be DefaultConstructible
          X(n, t)value_type must be CopyConstructible
          X(i, j)If the iterators return an lvalue the value_type must be CopyConstructible.
+                                 If the iterators return an rvalue the value_type must be MoveConstructible.
          a.insert(p, t)The value_type must be CopyConstructible.
+                                        The sequences vector and deque also require the value_type to be CopyAssignable.
          a.insert(p, rv)The value_type must be MoveConstructible.
+                                        The sequences vector and deque also require the value_type to be MoveAssignable.
          a.insert(p, n, t)The value_type must be CopyConstructible.
+                                        The sequences vector and deque also require the value_type to be CopyAssignable.
          a.insert(p, i, j)If the iterators return an lvalue the value_type must be CopyConstructible.
+                                        The sequences vector and deque also require the value_type to be CopyAssignable when the iterators return an lvalue.
+                                        If the iterators return an rvalue the value_type must be MoveConstructible.
+                                        The sequences vector and deque also require the value_type to be MoveAssignable when the iterators return an rvalue.
          a.erase(p)The sequences vector and deque require the value_type to be MoveAssignable.
          a.erase(q1, q2)The sequences vector and deque require the value_type to be MoveAssignable.
          a.clear()
          a.assign(i, j)If the iterators return an lvalue the value_type must be CopyConstructible and CopyAssignable.
+                                        If the iterators return an rvalue the value_type must be MoveConstructible and MoveAssignable.
          a.assign(n, t)The value_type must be CopyConstructible and CopyAssignable.
          a.resize(n)The value_type must be DefaultConstructible.
+                                     The sequence vector also requires the value_type to be MoveConstructible.
          a.resize(n, t)The value_type must be CopyConstructible.
          
+
+
          
+
          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
          Optional Sequence Requirements
          a.front()
          a.back()
          a.push_front(t)The value_type must be CopyConstructible.
          a.push_front(rv)The value_type must be MoveConstructible.
          a.push_back(t)The value_type must be CopyConstructible.
          a.push_back(rv)The value_type must be MoveConstructible.
          a.pop_front()
          a.pop_back()
          a[n]
          a.at[n]
          
+
+
          
+
          
+
+
+
+
+
+
+
+
+
+
+
+
          Associative Container Requirements
          X(i, j)If the iterators return an lvalue the value_type must be CopyConstructible.
+                                 If the iterators return an rvalue the value_type must be MoveConstructible.
          a_uniq.insert(t)The value_type must be CopyConstructible.
          a_uniq.insert(rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
          a_eq.insert(t)The value_type must be CopyConstructible.
          a_eq.insert(rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
          a.insert(p, t)The value_type must be CopyConstructible.
          a.insert(p, rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
          a.insert(i, j)If the iterators return an lvalue the value_type must be CopyConstructible.
+                                        If the iterators return an rvalue the key_type and the mapped_type (if it exists) must be MoveConstructible..
          
+
+
          
+
          
+
+
+
+
+
+
+
+
+
+
+
+
          Unordered Associative Container Requirements
          X(i, j, n, hf, eq)If the iterators return an lvalue the value_type must be CopyConstructible.
+                                 If the iterators return an rvalue the value_type must be MoveConstructible.
          a_uniq.insert(t)The value_type must be CopyConstructible.
          a_uniq.insert(rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
          a_eq.insert(t)The value_type must be CopyConstructible.
          a_eq.insert(rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
          a.insert(p, t)The value_type must be CopyConstructible.
          a.insert(p, rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
          a.insert(i, j)If the iterators return an lvalue the value_type must be CopyConstructible.
+                                        If the iterators return an rvalue the key_type and the mapped_type (if it exists) must be MoveConstructible..
          
+
+
          
+
          
+
+
+
+
+
+
          Miscellaneous Requirements
          map[lvalue-key]The key_type must be CopyConstructible.
+                                         The mapped_type must be DefaultConstructible and MoveConstructible.
          map[rvalue-key]The key_type must be MoveConstructible.
+                                         The mapped_type must be DefaultConstructible and MoveConstructible.
          
+
+
          [
+Kona (2007): Howard and Alan to update requirements table in issue with emplace signatures.
+]
          
+
+
+
          [
+Bellevue: This should be handled as part of the concepts work.
+]
          
+
+
+
+
+
          Proposed resolution:
          
+
+
+
+
          Rationale:
          
+
          [
+post San Francisco:
+]
          
+
+
+
          
+Solved by
+N2776.
+
          
+
+
+
+
+
+
 
          
 
          707. null pointer constant for exception_ptr
          
-
          Section: 18.7.5 [propagation] Status: NAD
- Submitter: Jens Maurer Date: 2007-07-20
          
+
          Section: 18.8.5 [propagation] Status: NAD
+ Submitter: Jens Maurer Opened: 2007-07-20  Last modified: 2008-02-25
          
 
          View other active issues in [propagation].
          
 
          View all other issues in [propagation].
          
 
          View all issues with NAD status.
          
@@ -11672,15 +12809,15 @@ implementation details.
 
 
          
 
          717. Incomplete valarray::operator[] specification in [valarray.access]
          
-
          Section: 26.5.2.3 [valarray.access] Status: Pending NAD Editorial
- Submitter: Daniel Krügler Date: 2007-08-27
          
+
          Section: 26.6.2.3 [valarray.access] Status: NAD Editorial
+ Submitter: Daniel Krügler Opened: 2007-08-27  Last modified: 2008-09-22
          
 
          View all other issues in [valarray.access].
          
-
          View all issues with Pending NAD Editorial status.
          
+
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
 
          
 Since the return type of valarray's operator[] const overload has been
 changed to const T& as described in 389 several paragraphs of
-the section 26.5.2.3 [valarray.access] are now
+the section 26.6.2.3 [valarray.access] are now
 incompletely
 specified, because many requirements and guarantees should now also
 apply to the const overload. Most notably, the address and reference
@@ -11690,7 +12827,7 @@ guarantees should be extended to the const overload case.
 
 
          Proposed resolution:
          
 
          
-Change 26.5.2.3 [valarray.access]:
+Change 26.6.2.3 [valarray.access]:
 
          
 
 
          
@@ -11730,12 +12867,115 @@ of that array ends, whichever happens first.
 
 
 
+
          
+
          724. DefaultConstructible is not defined
          
+
          Section: X [utility.arg.requirements] Status: NAD Editorial
+ Submitter: Pablo Halpern Opened: 2007-09-12  Last modified: 2008-09-23
          
+
          View all other issues in [utility.arg.requirements].
          
+
          View all issues with NAD Editorial status.
          
+
          Discussion:
          
+
          
+The DefaultConstructible requirement is referenced in
+several places in the August 2007 working draft
+N2369,
+but is not defined anywhere.
+
          
+
+
          [
+Bellevue:
+]
          
+
+
+
          
+
          
+Walking into the default/value-initialization mess...
+
          
+
          
+Why two lines? Because we need both expressions to be valid.
+
          
+
          
+AJM not sure what the phrase "default constructed" means. This is
+unfortunate, as the phrase is already used 24 times in the library!
+
          
+
          
+Example: const int would not accept first line, but will accept the second.
+
          
+
          
+This is an issue that must be solved by concepts, but we might need to solve it independantly first.
+
          
+
          
+It seems that the requirements are the syntax in the proposed first
+column is valid, but not clear what semantics we need.
+
          
+
          
+A table where there is no post-condition seems odd, but appears to sum up our position best.
+
          
+
          
+At a minimum an object is declared and is destuctible.
+
          
+
          
+Move to open, as no-one happy to produce wording on the fly.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+In section X [utility.arg.requirements], before table 33, add the
+following table:
+
          
+
+
          Table 33: DefaultConstructible requirements
          
+
+
          
+
+
+ 
+  
+  
+ 
+ 
+  
+  
+ 
+
          
+  
          expression
          
+            		
+  
          post-condition
          
+  
          
+  
          T
+  t;
          
+  T()
          
+            		
+  
          T
+  is default constructed.
          
+  
          
+
+
          
+
+
+
+
          Rationale:
          
+
          [
+San Francisco:
+]
          
+
+
          
+We believe concepts will solve this problem
+(N2774).
+
          
+
+
+
+
+
 
          
 
          725. Optional sequence container requirements column label
          
-
          Section: 23.1.3 [sequence.reqmts] Status: Pending NAD Editorial
- Submitter: David Abrahams Date: 2007-09-16
          
+
          Section: 23.2.3 [sequence.reqmts] Status: NAD Editorial
+ Submitter: David Abrahams Opened: 2007-09-16  Last modified: 2008-09-22
          
+
          View other active issues in [sequence.reqmts].
          
 
          View all other issues in [sequence.reqmts].
          
-
          View all issues with Pending NAD Editorial status.
          
+
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
 
          
 Table 90: (Optional sequence container operations) states the
@@ -11768,13 +13008,13 @@ Surely that's meant to be "operational semantics?"
 
 
          
 
          729. Problem in [rand.req.eng]/3
          
-
          Section: 26.4.1.3 [rand.req.eng] Status: NAD
- Submitter: Stephan Tolksdorf Date: 2007-09-21
          
+
          Section: X [rand.req.eng] Status: NAD
+ Submitter: Stephan Tolksdorf Opened: 2007-09-21  Last modified: 2008-02-27
          
 
          View all other issues in [rand.req.eng].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          
-The 3rd table row in 26.4.1.3 [rand.req.eng]/3 requires random number engines to accept any 
+The 3rd table row in X [rand.req.eng]/3 requires random number engines to accept any 
 arithmetic type as a seed, which is then casted to the engine's result_type and subsequently 
 used for seeding the state of the engine. The requirement stated as "Creates an engine with 
 initial state determined by static_cast<X::result_type>(s)" forces random number engines 
@@ -11793,11 +13033,11 @@ implementation specific unsigned integer type."
 
          
 
 
          
-Additionally, the definition of s in 26.4.1.3 [rand.req.eng]/1 c) could be restricted to unsigned integer types.
+Additionally, the definition of s in X [rand.req.eng]/1 c) could be restricted to unsigned integer types.
 
          
 
 
          
-Similarly, the type of the seed in 26.4.1.4 [rand.req.adapt]/3 e) could be left unspecified.
+Similarly, the type of the seed in X [rand.req.adapt]/3 e) could be left unspecified.
 
          
 
 
          
@@ -11818,9 +13058,9 @@ regarding this issue:
 
          
 
          
 The descriptions of all engines and engine adaptors given in sections
-26.4.3 [rand.eng] and 26.4.4 [rand.adapt] already specify the concrete
+26.5.3 [rand.eng] and 26.5.4 [rand.adapt] already specify the concrete
 types of the integer arguments for seeding. Hence, relaxing the general
-requirement in 26.4.1.3 [rand.req.eng] would not affect portability and
+requirement in X [rand.req.eng] would not affect portability and
 reproducibility of the standard library. Furthermore, it is not clear to
 me what exactly the guarantee "with initial state determined by
 static_cast<X::result_type>(s)" is useful for. On the other hand,
@@ -11855,7 +13095,7 @@ Stephan Tolksdorf adds pre-Bellevue:
 
 
          
 
          
-Change row 3 of table 105 "Random number engine requirements" in 26.4.1.3 [rand.req.eng]/3
+Change row 3 of table 105 "Random number engine requirements" in X [rand.req.eng]/3
 
          
 
 
          
@@ -11864,7 +13104,7 @@ Creates an engine with initial state determined by
 
          
 
 
          
-Similarly, change 26.4.1.4 [rand.req.adapt]/3 e)
+Similarly, change X [rand.req.adapt]/3 e)
 
          
 
 
          
@@ -11881,8 +13121,8 @@ When X::X is invoked with an X::result_type value <
 
 
          
 
          730. Comment on [rand.req.adapt]/3 e)
          
-
          Section: 26.4.1.4 [rand.req.adapt] Status: NAD
- Submitter: Stephan Tolksdorf Date: 2007-09-21
          
+
          Section: X [rand.req.adapt] Status: NAD
+ Submitter: Stephan Tolksdorf Opened: 2007-09-21  Last modified: 2008-02-27
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          
@@ -11928,15 +13168,14 @@ for the proposed resolution.
 
 
          
 
          731. proposal for a customizable seed_seq
          
-
          Section: 26.4.7.1 [rand.util.seedseq] Status: NAD
- Submitter: Stephan Tolksdorf Date: 2007-09-21
          
-
          View other active issues in [rand.util.seedseq].
          
+
          Section: 26.5.7.1 [rand.util.seedseq] Status: NAD
+ Submitter: Stephan Tolksdorf Opened: 2007-09-21  Last modified: 2008-02-27
          
 
          View all other issues in [rand.util.seedseq].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          
 The proper way to seed random number engines seems to be the most frequently 
-discussed issue of the 26.4 [rand] proposal. While the new seed_seq approach is already rather 
+discussed issue of the 26.5 [rand] proposal. While the new seed_seq approach is already rather 
 general and probably sufficient for most situations, it is unlikely to be optimal in every case (one 
 problem was pointed out in point T5 above). In some situations it might, for instance, be better to 
 seed the state with a cryptographic generator. 
@@ -11953,7 +13192,7 @@ changes:
 
 
            
 
          1. 
-Turn the interface specification of 26.4.7.1 [rand.util.seedseq]/2 into a "SeedSeq" requirement, where the 
+Turn the interface specification of 26.5.7.1 [rand.util.seedseq]/2 into a "SeedSeq" requirement, where the 
 exact behaviour of the constructors and the randomize method are left unspecified and where the
 const qualification for randomize is removed. Classes implementing this interface are additionally 
 required to specialize the traits class in c).
@@ -11975,8 +13214,8 @@ struct is_seed_seq<seed_seq> { static const bool value = true; }
 
            which users can supplement with further specializations.
            
 
            2. 
 
          2. 
-Change 26.4.1.3 [rand.req.eng]/1 d) to "q is an lvalue of a type that fulfils the SeedSeq requirements", and 
-modify the constructors and seed methods in 26.4.3 [rand.eng] appropriately (the actual implementation 
+Change X [rand.req.eng]/1 d) to "q is an lvalue of a type that fulfils the SeedSeq requirements", and 
+modify the constructors and seed methods in 26.5.3 [rand.eng] appropriately (the actual implementation 
 could be done using the SFINAE technique).
 
            3. 
 
          
@@ -12002,10 +13241,86 @@ for the proposed resolution.
 
 
 
+
          
+
          732. Defect in [rand.dist.samp.genpdf]
          
+
          Section: X [rand.dist.samp.genpdf] Status: NAD Editorial
+ Submitter: Stephan Tolksdorf Opened: 2007-09-21  Last modified: 2009-03-09
          
+
          View all other issues in [rand.dist.samp.genpdf].
          
+
          View all issues with NAD Editorial status.
          
+
          Duplicate of: 795
          
+
          Discussion:
          
+
          
+X [rand.dist.samp.genpdf] describes the interface for a distribution template that is 
+meant to simulate random numbers from any general distribution given only the density and the 
+support of the distribution. I'm not aware of any general purpose algorithm that would be capable 
+of correctly and efficiently implementing the described functionality. From what I know, this is 
+essentially an unsolved research problem. Existing algorithms either require more knowledge 
+about the distribution and the problem domain or work only under very limited circumstances. 
+Even the state of the art special purpose library UNU.RAN does not solve the problem in full 
+generality, and in any case, testing and customer support for such a library feature would be a 
+nightmare.
+
          
+
+
          
+Possible resolution: For these reasons, I propose to delete section X [rand.dist.samp.genpdf].
+
          
+
+
          [
+Bellevue:
+]
          
+
+
+
          
+
          
+Disagreement persists.
+
          
+
          
+Objection to this issue is that this function takes a general functor.
+The general approach would be to normalize this function, integrate it,
+and take the inverse of the integral, which is not possible in general.
+An example function is sin(1+n*x) -- for any spatial frequency that the
+implementor chooses, there is a value of n that renders that choice
+arbitrarily erroneous.
+
          
+
          
+Correction: The formula above should instead read 1+sin(n*x).
+
          
+
          
+Objector proposes the following possible compromise positions:
+
          
+
            
+
          • 
+rand.dist.samp.genpdf takes an number of points so that implementor need not guess.
+
            • 
+
          • replace rand.disk.samp.genpdf with an extension to either or both
+of the discrete functions to take arguments that take a functor and
+number of points in place of the list of probabilities. Reference
+issues 793 and 794.
+
            • 
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+See N2813
+for the proposed resolution.
+
          
+
+
+
          Rationale:
          
+Addressed by
+N2836 "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
+
+
+
+
+
 
          
 
          733. Comment on [rand.req.dist]/9
          
-
          Section: 26.4.1.5 [rand.req.dist] Status: NAD
- Submitter: Stephan Tolksdorf Date: 2007-09-21
          
+
          Section: X [rand.req.dist] Status: NAD
+ Submitter: Stephan Tolksdorf Opened: 2007-09-21  Last modified: 2008-02-27
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          
@@ -12045,8 +13360,8 @@ for the proposed resolution.
 
 
          
 
          735. Unfortunate naming
          
-
          Section: 26.4.8.2.2 [rand.dist.bern.bin], 26.4.8.2.4 [rand.dist.bern.negbin] Status: NAD
- Submitter: Stephan Tolksdorf Date: 2007-09-21
          
+
          Section: 26.5.8.2.2 [rand.dist.bern.bin], 26.5.8.2.4 [rand.dist.bern.negbin] Status: NAD
+ Submitter: Stephan Tolksdorf Opened: 2007-09-21  Last modified: 2008-02-27
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          
@@ -12095,9 +13410,8 @@ for the proposed resolution.
 
 
          
 
          736. Comment on [rand.dist.samp.discrete]
          
-
          Section: 26.4.8.5.1 [rand.dist.samp.discrete] Status: NAD
- Submitter: Stephan Tolksdorf Date: 2007-09-21
          
-
          View other active issues in [rand.dist.samp.discrete].
          
+
          Section: 26.5.8.5.1 [rand.dist.samp.discrete] Status: NAD
+ Submitter: Stephan Tolksdorf Opened: 2007-09-21  Last modified: 2008-02-27
          
 
          View all other issues in [rand.dist.samp.discrete].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -12193,7 +13507,7 @@ Stephan Tolksdorf adds pre-Bellevue:
 
 
          
 
          
-In 26.4.8.5.1 [rand.dist.samp.discrete]:
+In 26.5.8.5.1 [rand.dist.samp.discrete]:
 
          
 
 
          
@@ -12252,9 +13566,8 @@ as the weights . -- end note]
 
 
          
 
          737. Comment on [rand.dist.samp.pconst]
          
-
          Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: NAD
- Submitter: Stephan Tolksdorf Date: 2007-09-21
          
-
          View other active issues in [rand.dist.samp.pconst].
          
+
          Section: 26.5.8.5.2 [rand.dist.samp.pconst] Status: NAD
+ Submitter: Stephan Tolksdorf Opened: 2007-09-21  Last modified: 2008-02-27
          
 
          View all other issues in [rand.dist.samp.pconst].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -12316,7 +13629,7 @@ Stephan Tolksdorf adds pre-Bellevue:
 
 
          
 
          
-In 26.4.8.5.2 [rand.dist.samp.pconst]:
+In 26.5.8.5.2 [rand.dist.samp.pconst]:
 
          
 
 
          
@@ -12383,9 +13696,9 @@ and change in para. 3
 
 
          
 
          738. Editorial issue in [rand.adapt.disc]/3
          
-
          Section: 26.4.4.1 [rand.adapt.disc] Status: Pending NAD Editorial
- Submitter: Stephan Tolksdorf Date: 2007-09-21
          
-
          View all issues with Pending NAD Editorial status.
          
+
          Section: 26.5.4.1 [rand.adapt.disc] Status: NAD Editorial
+ Submitter: Stephan Tolksdorf Opened: 2007-09-21  Last modified: 2008-09-22
          
+
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
 
          
 Since the template parameter p and r are of type size_t, the member n in the class 
@@ -12405,8 +13718,8 @@ for the proposed resolution.
 
 
          
 
          739. Defect in [rand.util.canonical]/3
          
-
          Section: 26.4.7.2 [rand.util.canonical] Status: NAD
- Submitter: Stephan Tolksdorf Date: 2007-09-21
          
+
          Section: 26.5.7.2 [rand.util.canonical] Status: NAD
+ Submitter: Stephan Tolksdorf Opened: 2007-09-21  Last modified: 2008-02-27
          
 
          View all other issues in [rand.util.canonical].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -12445,8 +13758,8 @@ for the proposed resolution.
 
 
          
 
          741. Const-incorrect get_deleter function for shared_ptr
          
-
          Section: 20.7.12.2.11 [util.smartptr.getdeleter] Status: NAD
- Submitter: Daniel Krügler Date: 2007-09-27
          
+
          Section: 20.8.13.2.11 [util.smartptr.getdeleter] Status: NAD
+ Submitter: Daniel Krügler Opened: 2007-09-27  Last modified: 2008-02-27
          
 
          View all other issues in [util.smartptr.getdeleter].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -12456,7 +13769,7 @@ The following issue was raised by Alf P. Steinbach in c.l.c++.mod:
 
 
          
 According to the recent draft N2369, both the header memory synopsis
-of 20.7 [memory] and 20.7.12.2.11 [util.smartptr.getdeleter] declare:
+of 20.8 [memory] and 20.8.13.2.11 [util.smartptr.getdeleter] declare:
 
          
 
 
          template<class D, class T> D* get_deleter(shared_ptr<T> const& p);
@@ -12471,7 +13784,7 @@ the mutability of the owner (as seen for the both overloads of
 unique_ptr::get_deleter).
 Even the next similar counter-part of get_deleter - the two
 overloads of function::target in the class template function
-synopsis 20.6.15.2 [func.wrap.func] or in 20.6.15.2.5 [func.wrap.func.targ] - do
+synopsis 20.7.16.2 [func.wrap.func] or in 20.7.16.2.5 [func.wrap.func.targ] - do
 properly mirror the const-state of the owner.
 
          
 
@@ -12479,7 +13792,7 @@ properly mirror the const-state of the owner.
 
 
          
 Replace the declarations of get_deleter in the header <memory>
-synopsis of 20.7 [memory] and in 20.7.12.2.11 [util.smartptr.getdeleter] by one of the
+synopsis of 20.8 [memory] and in 20.8.13.2.11 [util.smartptr.getdeleter] by one of the
 following alternatives (A) or (B):
 
          
 
@@ -12547,10 +13860,181 @@ Concern this is similar to confusing "pointer to const" with "a constant pointer
 
 
 
+
          
+
          742. Enabling swap for proxy iterators
          
+
          Section: X [utility.arg.requirements] Status: NAD Editorial
+ Submitter: Howard Hinnant Opened: 2007-10-10  Last modified: 2008-09-26
          
+
          View all other issues in [utility.arg.requirements].
          
+
          View all issues with NAD Editorial status.
          
+
          Discussion:
          
+
          
+This issue was split from 672. 672 now just
+deals with changing the requirements of T in the Swappable
+requirement from CopyConstructible and CopyAssignable to
+MoveConstructible and MoveAssignable.
+
          
+
+
          
+This issue seeks to widen the Swappable requirement to support proxy iterators.  Here
+is example code:
+
          
+
+
          namespace Mine {
+
+template <class T>
+struct proxy {...};
+
+template <class T>
+struct proxied_iterator
+{
+   typedef T value_type;
+   typedef proxy<T> reference;
+   reference operator*() const;
+   ...
+};
+
+struct A
+{
+   // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
+   void swap(A&);
+   ...
+};
+
+void swap(A&, A&);
+void swap(proxy<A>, A&);
+void swap(A&, proxy<A>);
+void swap(proxy<A>, proxy<A>);
+
+}  // Mine
+
+...
+
+Mine::proxied_iterator<Mine::A> i(...)
+Mine::A a;
+swap(*i1, a);
+
          
+
+
          
+The key point to note in the above code is that in the call to swap, *i1
+and a are different types (currently types can only be Swappable with the
+same type).  A secondary point is that to support proxies, one must be able to pass rvalues
+to swap.  But note that I am not stating that the general purpose std::swap
+should accept rvalues!  Only that overloaded swaps, as in the example above, be allowed
+to take rvalues.
+
          
+
+
          
+That is, no standard library code needs to change.  We simply need to have a more flexible
+definition of Swappable.
+
          
+
+
          [
+Bellevue:
+]
          
+
+
+
          
+
          
+While we believe Concepts work will define a swappable concept, we
+should still resolve this issue if possible to give guidance to the
+Concepts work.
+
          
+
          
+Would an ambiguous swap function in two namespaces found by ADL break
+this wording? Suggest that the phrase "valid expression" means such a
+pair of types would still not be swappable.
+
          
+
          
+Motivation is proxy-iterators, but facility is considerably more
+general. Are we happy going so far?
+
          
+
          
+We think this wording is probably correct and probably an improvement on
+what's there in the WP. On the other hand, what's already there in the
+WP is awfully complicated. Why do we need the two bullet points? They're
+too implementation-centric. They don't add anything to the semantics of
+what swap() means, which is there in the post-condition. What's wrong
+with saying that types are swappable if you can call swap() and it
+satisfies the semantics of swapping?
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+Change X [utility.arg.requirements]:
+
          
+
+
          
+
+
          
+-1- The template definitions in the C++ Standard Library refer to various
+named requirements whose details are set out in tables 31-38. In these
+tables, T and V are is a types to be supplied by a C++ program
+instantiating a template; a, b, and c are
+values of type const T; s and t are modifiable
+lvalues of type T; u is a value of type (possibly
+const) T; and rv is a non-const
+rvalue of type T; w is a value of type T; and v is a value of type V.
+
          
+
+
+
+
+
+
+
+
          Table 37: Swappable requirements [swappable]
          expressionreturn typepost-condition
          swap(sw,tv)voidtw has the value originally
+held by uv, and
+uv has the value originally held
+by tw
          
+
          
+The Swappable requirement is met by satisfying one or more of the following conditions:
+
          
+
            
+
          • 
+T is Swappable if T and V are
+the same type and  T satisfies the
+CopyConstructible
+MoveConstructible requirements (Table 34
+33) and the CopyAssignable
+MoveAssignable requirements (Table 36
+35);
+
            • 
+
          • 
+T is Swappable with V if a namespace scope function named
+swap exists in the same namespace as the definition of
+T or V, such that the expression
+swap(tw,u v) is valid and has the
+semantics described in this table.
+
            • 
+
          
+
          
+
          
+
+
+
+
          Rationale:
          
+
          [
+post San Francisco:
+]
          
+
+
+
          
+Solved by
+N2758.
+
          
+
+
+
+
+
+
 
          
 
          745. copy_exception API slices.
          
-
          Section: 18.7.5 [propagation] Status: NAD
- Submitter: Alisdair Meredith Date: 2007-10-10
          
+
          Section: 18.8.5 [propagation] Status: NAD
+ Submitter: Alisdair Meredith Opened: 2007-10-10  Last modified: 2008-02-25
          
 
          View other active issues in [propagation].
          
 
          View all other issues in [propagation].
          
 
          View all issues with NAD status.
          
@@ -12592,8 +14076,9 @@ slicing involved.
 
 
          
 
          748. The is_abstract type trait is defined by reference to 10.4.
          
-
          Section: 20.5.4.3 [meta.unary.prop] Status: NAD
- Submitter: Alisdair Meredith Date: 2007-10-10
          
+
          Section: 20.6.4.3 [meta.unary.prop] Status: NAD
+ Submitter: Alisdair Meredith Opened: 2007-10-10  Last modified: 2009-05-01
          
+
          View other active issues in [meta.unary.prop].
          
 
          View all other issues in [meta.unary.prop].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -12606,9 +14091,9 @@ For instance, is the following (non-polymorphic) type considered abstract?
 
          
 
          struct abstract {
 protected:
- abstract(){}
- abstract( abstract const & ) {}
- ~abstract() {}
+ abstract(){}
+ abstract( abstract const & ) {}
+ ~abstract() {}
 };
 
          
 
          
@@ -12628,8 +14113,8 @@ Core has clarified that the definition abstract is adequate. Issue withdrawn by
 
 
          
 
          754. Ambiguous return clause for std::uninitialized_copy
          
-
          Section: 20.7.10.1 [uninitialized.copy] Status: NAD Editorial
- Submitter: Daniel Krügler Date: 2007-10-15
          
+
          Section: 20.8.11.2 [uninitialized.copy] Status: NAD Editorial
+ Submitter: Daniel Krügler Opened: 2007-10-15  Last modified: 2008-07-02
          
 
          View all other issues in [uninitialized.copy].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
@@ -12658,7 +14143,7 @@ Core has clarified that the definition abstract is adequate. Issue withdrawn by
 
 
          
 similarily for N2369, and its corresponding section
-20.7.10.1 [uninitialized.copy].
+20.8.11.2 [uninitialized.copy].
 
          
 
 
          
@@ -12690,7 +14175,7 @@ specification of std::copy).
 The problem is: I see nothing in the standard which grants that this
 interpretation
 is correct, specifically [lib.structure.specifications] or
-17.3.1.3 [structure.specifications]
+17.5.1.4 [structure.specifications]
 resp. do not clarify which "look-up" rules apply for names found in
 the elements
 of the detailed specifications - Do they relate to the corresponding
@@ -12706,7 +14191,7 @@ for std::copy.
 
 
          Proposed resolution:
          
 
          
-Change the wording of the return clause to say (20.7.10.1 [uninitialized.copy]):
+Change the wording of the return clause to say (20.8.11.2 [uninitialized.copy]):
 
          
 
 
          
@@ -12732,8 +14217,8 @@ occur.
 
 
          
 
          756. Container adaptors push
          
-
          Section: 23.2.5 [container.adaptors] Status: NAD Editorial
- Submitter: Paolo Carlini Date: 2007-10-31
          
+
          Section: 23.3.5 [container.adaptors] Status: NAD Editorial
+ Submitter: Paolo Carlini Opened: 2007-10-31  Last modified: 2008-06-18
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
 
          
@@ -12760,7 +14245,7 @@ Related to 757. Typo in the synopsis of vector
-
          Section: 23.2.6 [vector] Status: NAD Editorial
- Submitter: Paolo Carlini Date: 2007-11-04
          
+
          Section: 23.3.6 [vector] Status: NAD Editorial
+ Submitter: Paolo Carlini Opened: 2007-11-04  Last modified: 2008-07-02
          
 
          View all other issues in [vector].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
 
          
-In the synopsis 23.2.6 [vector], there is the signature:
+In the synopsis 23.3.6 [vector], there is the signature:
 
          
 
 
          void insert(const_iterator position, size_type n, T&& x);
@@ -12848,14 +14333,14 @@ instead of:
 
          
 
 
          
-23.2.6.4 [vector.modifiers] is fine.
+23.3.6.4 [vector.modifiers] is fine.
 
          
 
 
 
 
          Proposed resolution:
          
 
          
-Change the synopsis in 23.2.6 [vector]:
+Change the synopsis in 23.3.6 [vector]:
 
          
 
 
          iterator insert(const_iterator position, const T& x); 
@@ -12870,8 +14355,9 @@ void     insert(const_iterator position, size_type n, const T& x);
 
 
          
 
          763. Renaming emplace() overloads
          
-
          Section: 23.1.4 [associative.reqmts] Status: NAD
- Submitter: Sylvain Pion Date: 2007-12-04
          
+
          Section: 23.2.4 [associative.reqmts] Status: NAD
+ Submitter: Sylvain Pion Opened: 2007-12-04  Last modified: 2008-03-12
          
+
          View other active issues in [associative.reqmts].
          
 
          View all other issues in [associative.reqmts].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -12922,8 +14408,8 @@ For example to emplace_here, hint_emplace...
 
 
          
 
          764. equal_range on unordered containers should return a pair of local_iterators
          
-
          Section: 23.1.5 [unord.req] Status: NAD
- Submitter: Joe Gottman Date: 2007-11-29
          
+
          Section: 23.2.5 [unord.req] Status: NAD
+ Submitter: Joe Gottman Opened: 2007-11-29  Last modified: 2008-03-12
          
 
          View other active issues in [unord.req].
          
 
          View all other issues in [unord.req].
          
 
          View all issues with NAD status.
          
@@ -12981,7 +14467,7 @@ for dubious benefit, and iterators are already constant time.
 
 
          Proposed resolution:
          
 
          
-Change the entry for equal_range in Table 93 (23.1.5 [unord.req]) as follows:
+Change the entry for equal_range in Table 93 (23.2.5 [unord.req]) as follows:
 
          
 
@@ -13003,7 +14489,7 @@ Change the entry for equal_range in Table 93 (23.1.5 [unord.req]) as fo
 
          767. Forwarding and backward compatibility
          Section: 23 [containers] Status: NAD Editorial
- Submitter: Sylvain Pion Date: 2007-12-28
          
+ Submitter: Sylvain Pion Opened: 2007-12-28  Last modified: 2008-06-18
          View other active issues in [containers].
          View all other issues in [containers].
          View all issues with NAD Editorial status.
          
@@ -13108,7 +14594,7 @@ moved to NAD.
 
 
          Proposed resolution:
          
-Add the following rows to Table 90 "Optional sequence container operations", 23.1.3 [sequence.reqmts]:
+Add the following rows to Table 90 "Optional sequence container operations", 23.2.3 [sequence.reqmts]:
 
          
@@ -13185,7 +14671,7 @@ Add the following rows to Table 90 "Optional sequence container operations", 23.
 
          
-Change the synopsis in 23.2.2 [deque]:
+Change the synopsis in 23.3.2 [deque]:
 
          void push_front(const T& x);
@@ -13197,7 +14683,7 @@ template <class... Args> requires Constructible<T, Args&&.
 
          
-Change 23.2.2.3 [deque.modifiers]:
+Change 23.3.2.3 [deque.modifiers]:
 
          void push_front(const T& x);
@@ -13209,7 +14695,7 @@ template <class... Args> requires Constructible<T, Args&&.
 
          
-Change the synopsis in 23.2.4 [list]:
+Change the synopsis in 23.3.4 [list]:
 
          void push_front(const T& x);
@@ -13221,7 +14707,7 @@ template <class... Args> requires Constructible<T, Args&&.
 
          
-Change 23.2.4.3 [list.modifiers]:
+Change 23.3.4.3 [list.modifiers]:
 
          void push_front(const T& x);
@@ -13233,7 +14719,7 @@ template <class... Args> requires Constructible<T, Args&&.
 
          
-Change the synopsis in 23.2.6 [vector]:
+Change the synopsis in 23.3.6 [vector]:
 
          void push_back(const T& x);
@@ -13242,7 +14728,7 @@ template <class... Args> requires Constructible<T, Args&&.
 
          
-Change 23.2.6.4 [vector.modifiers]:
+Change 23.3.6.4 [vector.modifiers]:
 
          void push_back(const T& x);
@@ -13269,27 +14755,27 @@ If there is still an issue with pair, Howard should submit another issue.
 
 
          
 
          773. issues with random
          
-
          Section: 26.4.8.1 [rand.dist.uni] Status: NAD
- Submitter: P.J. Plauger Date: 2008-01-14
          
+
          Section: 26.5.8.1 [rand.dist.uni] Status: NAD
+ Submitter: P.J. Plauger Opened: 2008-01-14  Last modified: 2008-02-27
          
 
          View all other issues in [rand.dist.uni].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
            
 
          1. 
-26.4.8.1.1 [rand.dist.uni.int] uniform_int constructor has changed the default
+26.5.8.1.1 [rand.dist.uni.int] uniform_int constructor has changed the default
 max constructor parameter from 9 (in TR1) to max(). The value
 is arbitrary at best and shouldn't be lightly changed because
 it breaks backward compatibility.
 
            2. 
 
 
          2. 
-26.4.8.1.1 [rand.dist.uni.int] uniform_int has a parameter param that you can
+26.5.8.1.1 [rand.dist.uni.int] uniform_int has a parameter param that you can
 provide on construction or operator(), set, and get. But there
 is not even a hint of what this might be for.
 
            3. 
 
 
          3. 
-26.4.8.1.2 [rand.dist.uni.real] uniform_real. Same issue as #2.
+26.5.8.1.2 [rand.dist.uni.real] uniform_real. Same issue as #2.
 
            4. 
 
          
 
@@ -13313,8 +14799,8 @@ NAD. Withdrawn.
 
 
          
 
          784. unique_lock::release
          
-
          Section: 30.3.3.2.3 [thread.lock.unique.mod] Status: NAD
- Submitter: Constantine Sapuntzakis Date: 2008-02-02
          
+
          Section: 30.4.3.2.3 [thread.lock.unique.mod] Status: NAD
+ Submitter: Constantine Sapuntzakis Opened: 2008-02-02  Last modified: 2008-02-27
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          
@@ -13360,7 +14846,7 @@ changing. NAD
 
 
          Proposed resolution:
          
 
          
-Change the synopsis in 30.3.3.2 [thread.lock.unique]:
+Change the synopsis in 30.4.3.2 [thread.lock.unique]:
 
          
 
 
          template <class Mutex> 
@@ -13374,7 +14860,7 @@ public:
 
          
 
 
          
-Change 30.3.3.2.3 [thread.lock.unique.mod]:
+Change 30.4.3.2.3 [thread.lock.unique.mod]:
 
          
 
 
          mutex_type *release disown();
@@ -13386,8 +14872,9 @@ Change 30.3.3.2.3 [thread.lock.unique.mod]:
 
 
          
 
          786. Thread library timed waits, UTC and monotonic clocks
          
-
          Section: X [datetime.system] Status: NAD Editorial
- Submitter: Christopher Kohlhoff, Jeff Garland Date: 2008-02-03
          
+
          Section: 20.9 [time] Status: NAD Editorial
+ Submitter: Christopher Kohlhoff, Jeff Garland Opened: 2008-02-03  Last modified: 2008-09-30
          
+
          View all other issues in [time].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
 
          
@@ -13512,8 +14999,8 @@ Addressed by
 
 
          
 
          790. xor_combine::seed not specified
          
-
          Section: 26.4.4.4 [rand.adapt.xor] Status: NAD
- Submitter: P.J. Plauger Date: 2008-02-09
          
+
          Section: X [rand.adapt.xor] Status: NAD
+ Submitter: P.J. Plauger Opened: 2008-02-09  Last modified: 2008-02-27
          
 
          View all other issues in [rand.adapt.xor].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -13542,9 +15029,8 @@ Overcome by the previous proposal. NAD mooted by resolution of 791. piecewise_constant_distribution::densities has wrong name
-
          Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: NAD
- Submitter: P.J. Plauger Date: 2008-02-09
          
-
          View other active issues in [rand.dist.samp.pconst].
          
+
          Section: 26.5.8.5.2 [rand.dist.samp.pconst] Status: NAD
+ Submitter: P.J. Plauger Opened: 2008-02-09  Last modified: 2008-03-11
          
 
          View all other issues in [rand.dist.samp.pconst].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -13587,7 +15073,7 @@ variates.
 
          Proposed resolution:
          
 
 
          
-Change synopsis in 26.4.8.5.2 [rand.dist.samp.pconst]:
+Change synopsis in 26.5.8.5.2 [rand.dist.samp.pconst]:
 
          
 
 
          template <class RealType = double> 
@@ -13601,7 +15087,7 @@ public:
 
          
 
 
          
-Change 26.4.8.5.2 [rand.dist.samp.pconst]/6:
+Change 26.5.8.5.2 [rand.dist.samp.pconst]/6:
 
          
 
 
          vector<double> densities probabilities() const;
@@ -13612,13 +15098,534 @@ Change 26.4.8.5.2 [rand.dist.samp.pconst]/6:
 
 
 
+
          
+
          793. discrete_distribution missing constructor
          
+
          Section: 26.5.8.5.1 [rand.dist.samp.discrete] Status: NAD Editorial
+ Submitter: P.J. Plauger Opened: 2008-02-09  Last modified: 2009-03-09
          
+
          View all other issues in [rand.dist.samp.discrete].
          
+
          View all issues with NAD Editorial status.
          
+
          Discussion:
          
+
          
+discrete_distribution should have a constructor like:
+
          
+
+
          template<class _Fn>
+  discrete_distribution(result_type _Count, double _Low, double _High,
+                        _Fn& _Func);
+
          
+
+
          
+(Makes it easier to fill a histogram with function values over a range.)
+
          
+
+
          [
+Bellevue:
+]
          
+
+
+
          
+How do you specify the function so that it does not return negative
+values? If you do it is a bad construction. This requirement is already
+there. Where in each bin does one evaluate the function? In the middle.
+Need to revisit tomorrow.
+
          
+
+
          [
+Sophia Antipolis:
+]
          
+
+
+
          
+
          
+Bill is not requesting this.
+
          
+
          
+Marc Paterno: _Fn cannot return negative values at the points where the
+function is sampled. It is sampled in the middle of each bin. _Fn cannot
+return 0 everywhere it is sampled.
+
          
+
          
+Jens: lambda expressions are rvalues
+
          
+
          
+Add a library issue to provide an
+initializer_list<double> constructor for
+discrete_distribution.
+
          
+
          
+Marc Paterno: dislikes reference for _Fn parameter. Make it pass-by-value (to use lambda),
+use std::ref to wrap giant-state function objects.
+
          
+
          
+Daniel: See random_shuffle, pass-by-rvalue-reference.
+
          
+
          
+Daniel to draft wording.
+
          
+
          
+
+
          [
+Pre San Francisco, Daniel provided wording:
+]
          
+
+
+
          
+The here proposed changes of the WP refer to the current state of
+N2691.
+During the Sophia Antipolis meeting two different proposals came up
+regarding the functor argument type, either by value or by rvalue-reference.
+For consistence with existing conventions (state-free algorithms and the
+general_pdf_distribution c'tor signature) the author decided to propose a
+function argument that is provided by value. If severe concerns exists that
+stateful functions would be of dominant relevance, it should be possible to
+replace the two occurrences of Func by Func&& in this proposal as part
+of an editorial process.
+
          
+
+
+
+
          Proposed resolution:
          
+
+
          Non-concept version of the proposed resolution
          
+
+
            
+
          1. 
+
            
+In 26.5.8.5.1 [rand.dist.samp.discrete]/1, class discrete_distribution, just
+before the member declaration
+
            
+
+
            explicit discrete_distribution(const param_type& parm);
+
            
+
+
            
+insert:
+
            
+
+
+
            template<typename Func>
+discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
+
            
+
            2. 
+
+
          2. 
+
            
+Between p.4 and p.5 insert a series of new paragraphs as part of the
+new member description::
+
            
+
            template<typename Func>
+discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
+
            
+
+
            
+Complexity: Exactly nf invocations of fw.
+
            
+
            
+Requires:
+
            
+
              
+
            1. 
+fw shall be callable with one argument of type double, and shall
+return values of a type convertible to double;
              2. 
+
+
            2. If nf > 0, the relation xmin < xmax shall hold, and for all sample values
+xk, fw(xk) shall return a weight value wk that is non-negative, non-NaN,
+and non-infinity;
              3. 
+
+
            3. The following relations shall hold: nf ≥ 0, and 0 < S = w0+. . .+wn-1.
              4. 
+
+
            
+
+
            
+Effects:
+
            
+
              
+
            1. If nf == 0, sets n = 1 and lets the sequence w have length n = 1 and
+   consist of the single value w0 = 1.
              2. 
+
+
            2. 
+
              Otherwise, sets n = nf, deltax = (xmax - xmin)/n and xcent = xmin +
+0.5 * deltax.
              
+
              For each k = 0, . . . ,n-1, calculates:
+  xk = xcent + k * deltax
+  wk = fw(xk)
+
              
+
              3. 
+
            3. 
+
              Constructs a discrete_distribution object with probabilities:
              
+
              pk = wk/S  for k = 0, . . . , n-1.
+
              
+
              4. 
+
            
+
            
+
            3. 
+
          
+
+
          Concept version of the proposed resolution
          
+
+
+
            
+
          1. 
+
            
+In 26.5.8.5.1 [rand.dist.samp.discrete]/1, class discrete_distribution, just
+before the member declaration
+
            
+
+
            explicit discrete_distribution(const param_type& parm);
+
            
+
+
            
+insert:
+
            
+
+
+
            template<Callable<auto, double> Func>
+ requires Convertible<Func::result_type, double>
+discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
+
            
+
            2. 
+
+
          2. 
+
            
+Between p.4 and p.5 insert a series of new paragraphs as part of the
+new member description::
+
            
+
            template<Callable<auto, double> Func>
+ requires Convertible<Func::result_type, double>
+discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
+
            
+
+
            
+Complexity: Exactly nf invocations of fw.
+
            
+
            
+Requires:
+
            
+
              
+
            1. If nf > 0, the relation xmin < xmax shall hold, and for all sample values
+xk, fw(xk) shall return a weight value wk that is non-negative, non-NaN,
+and non-infinity;
              2. 
+
+
            2. The following relations shall hold: nf ≥ 0, and 0 < S = w0+. . .+wn-1.
              3. 
+
+
            
+
+
            
+Effects:
+
            
+
              
+
            1. If nf == 0, sets n = 1 and lets the sequence w have length n = 1 and
+   consist of the single value w0 = 1.
              2. 
+
+
            2. 
+
              Otherwise, sets n = nf, deltax = (xmax - xmin)/n and xcent = xmin +
+0.5 * deltax.
              
+
              For each k = 0, . . . ,n-1, calculates:
+  xk = xcent + k * deltax
+  wk = fw(xk)
+
              
+
              3. 
+
            3. 
+
              Constructs a discrete_distribution object with probabilities:
              
+
              pk = wk/S  for k = 0, . . . , n-1.
+
              
+
              4. 
+
            
+
            
+
            3. 
+
          
+
+
+
+
          Rationale:
          
+Addressed by
+N2836 "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
+
+
+
+
+
+
          
+
          794. piecewise_constant_distribution missing constructor
          
+
          Section: 26.5.8.5.2 [rand.dist.samp.pconst] Status: NAD Editorial
+ Submitter: P.J. Plauger Opened: 2008-02-09  Last modified: 2009-03-09
          
+
          View all other issues in [rand.dist.samp.pconst].
          
+
          View all issues with NAD Editorial status.
          
+
          Discussion:
          
+
          
+piecewise_constant_distribution should have a constructor like:
+
          
+
+
          template<class _Fn>
+   piecewise_constant_distribution(size_t _Count,
+            _Ty _Low, _Ty _High, _Fn& _Func);
+
          
+
+
          
+(Makes it easier to fill a histogram with function values over a range.
+The two (reference 793) make a sensible replacement for
+general_pdf_distribution.)
+
          
+
+
          [
+Sophia Antipolis:
+]
          
+
+
+
          
+
          
+Marc: uses variable width of bins and weight for each bin. This is not
+giving enough flexibility to control both variables.
+
          
+
          
+Add a library issue to provide an constructor taking an
+initializer_list<double> and _Fn for piecewise_constant_distribution.
+
          
+
          
+Daniel to draft wording.
+
          
+
          
+
+
          [
+Pre San Francisco, Daniel provided wording.
+]
          
+
+
+
          
+The here proposed changes of the WP refer to the current state of
+N2691.
+For reasons explained in 793, the author decided to propose a function
+argument that is provided by value. The issue proposes a c'tor signature,
+that does not take advantage of the full flexibility of
+piecewise_constant_distribution,
+because it restricts on a constant bin width, but the use-case seems to
+be popular enough to justify it's introduction.
+
          
+
+
+
+
          Proposed resolution:
          
+
+
          Non-concept version of the proposed resolution
          
+
+
            
+
          1. 
+
            
+In 26.5.8.5.2 [rand.dist.samp.pconst]/1, class piecewise_constant_distribution,
+just before the member declaration
+
            
+
+
            explicit piecewise_constant_distribution(const param_type& parm);
+
            
+
            
+insert:
+
            
+
            template<typename Func>
+piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
+
            
+
            2. 
+
+
          2. 
+
            
+Between p.4 and p.5 insert a new sequence of paragraphs nominated
+below as [p5_1], [p5_2],
+[p5_3], and [p5_4] as part of the new member description:
+
            
+
+
            template<typename Func>
+piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
+
            
+
            
+
            
+[p5_1] Complexity: Exactly nf invocations of fw.
+
            
+
            
+[p5_2] Requires:
+
            
+
              
+
            1. fw shall be callable with one argument of type RealType, and shall
+return values of a type convertible to double;
+
              2. 
+
            2. 
+For all sample values xk defined below, fw(xk) shall return a weight
+value wk that is non-negative, non-NaN, and non-infinity;
+
              3. 
+
            3. 
+The following relations shall hold: xmin < xmax, and
+0 < S = w0+. . .+wn-1.
+
              4. 
+
            
+
            
+[p5_3] Effects:
+
            
+
              
+
            1. 
+
              If nf == 0,
              
+ 
                
+ 
              1. 
+sets deltax = xmax - xmin, and
                2. 
+
              2.  lets the sequence w have length n = 1 and consist of the single
+    value w0 = 1, and
                3. 
+
              3.  lets the sequence b have length n+1 with b0 = xmin and 
+              b1 = xmax
+
                4. 
+
              
+
              2. 
+
            2. 
+
              Otherwise,
              
+
                
+
              1.  sets n = nf, deltax = (xmax - xmin)/n,
+                 xcent = xmin + 0.5 * deltax, and
+
                2. 
+
              2. lets the sequences w and b have length n and n+1, resp. and
                
+
                for each k = 0, . . . ,n-1, calculates:
+  dxk = k * deltax
+  bk = xmin + dxk
+  xk = xcent + dxk
+  wk = fw(xk),
+
                 
+
                 and
                
+
                3. 
+
              3.  sets bn = xmax
                4. 
+
              
+
              3. 
+
            3. 
+
              
+Constructs a piecewise_constant_distribution object with
+the above computed sequence b as the interval boundaries
+and with the probability densities:
+
              
+
              ρk = wk/(S * deltax)  for k = 0, . . . , n-1.
+
               
+
              4. 
+
            
+
            
+[p5_4] [Note: In this context, the subintervals [bk, bk+1) are commonly
+ known as the bins of a histogram. -- end note]
+ 
            
+
            
+
            
+
            3. 
+
          
+
+
          Concept version of the proposed resolution
          
+
+
            
+
          1. 
+
            
+In 26.5.8.5.2 [rand.dist.samp.pconst]/1, class piecewise_constant_distribution,
+just before the member declaration
+
            
+
+
            explicit piecewise_constant_distribution(const param_type& parm);
+
            
+
            
+insert:
+
            
+
            template<Callable<auto, RealType> Func>
+ requires Convertible<Func::result_type, double>
+piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
+
            
+
            2. 
+
+
          2. 
+
            
+Between p.4 and p.5 insert a new sequence of paragraphs nominated
+below as [p5_1], [p5_2],
+[p5_3], and [p5_4] as part of the new member description:
+
            
+
+
            template<Callable<auto, RealType> Func>
+ requires Convertible<Func::result_type, double>
+piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
+
            
+
            
+
            
+[p5_1] Complexity: Exactly nf invocations of fw.
+
            
+
            
+[p5_2] Requires:
+
            
+
              
+
            1. 
+For all sample values xk defined below, fw(xk) shall return a weight
+value wk that is non-negative, non-NaN, and non-infinity;
+
              2. 
+
            2. 
+The following relations shall hold: xmin < xmax, and
+0 < S = w0+. . .+wn-1.
+
              3. 
+
            
+
            
+[p5_3] Effects:
+
            
+
              
+
            1. 
+
              If nf == 0,
              
+ 
                
+ 
              1. 
+sets deltax = xmax - xmin, and
                2. 
+
              2.  lets the sequence w have length n = 1 and consist of the single
+    value w0 = 1, and
                3. 
+
              3.  lets the sequence b have length n+1 with b0 = xmin and 
+              b1 = xmax
+
                4. 
+
              
+
              2. 
+
            2. 
+
              Otherwise,
              
+
                
+
              1.  sets n = nf, deltax = (xmax - xmin)/n,
+                 xcent = xmin + 0.5 * deltax, and
+
                2. 
+
              2. lets the sequences w and b have length n and n+1, resp. and
                
+
                for each k = 0, . . . ,n-1, calculates:
+  dxk = k * deltax
+  bk = xmin + dxk
+  xk = xcent + dxk
+  wk = fw(xk),
+
                 
+
                 and
                
+
                3. 
+
              3.  sets bn = xmax
                4. 
+
              
+
              3. 
+
            3. 
+
              
+Constructs a piecewise_constant_distribution object with
+the above computed sequence b as the interval boundaries
+and with the probability densities:
+
              
+
              ρk = wk/(S * deltax)  for k = 0, . . . , n-1.
+
               
+
              4. 
+
            
+
            
+[p5_4] [Note: In this context, the subintervals [bk, bk+1) are commonly
+ known as the bins of a histogram. -- end note]
+ 
            
+
            
+
            
+
            3. 
+
          
+
+
+
+
          Rationale:
          
+Addressed by
+N2836 "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
+
+
+
+
+
 
          
 
          795. general_pdf_distribution should be dropped
          
-
          Section: 26.4.8.5.3 [rand.dist.samp.genpdf] Status: Dup
- Submitter: P.J. Plauger Date: 2008-02-09
          
+
          Section: X [rand.dist.samp.genpdf] Status: Dup
+ Submitter: P.J. Plauger Opened: 2008-02-09  Last modified: 2008-03-11
          
 
          View all other issues in [rand.dist.samp.genpdf].
          
 
          View all issues with Dup status.
          
-
          Duplicate of: 732
          
+
          Duplicate of: 732
          
 
          Discussion:
          
 
          
 general_pdf_distribution should be dropped. (It's a research topic in
@@ -13631,7 +15638,7 @@ Stephan Tolksdorf notes:
 
 
 
          
-This appears to be a duplicate of 732.
+This appears to be a duplicate of 732.
 
          
 
 
@@ -13644,8 +15651,8 @@ This appears to be a duplicate of 796. ranlux48_base returns wrong value
-
          Section: 26.4.5 [rand.predef] Status: NAD
- Submitter: P.J. Plauger Date: 2008-02-09
          
+
          Section: 26.5.5 [rand.predef] Status: NAD
+ Submitter: P.J. Plauger Opened: 2008-02-09  Last modified: 2008-02-27
          
 
          View all other issues in [rand.predef].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -13668,7 +15675,7 @@ Submitter withdraws defect.
 
 
          Proposed resolution:
          
 
          
-Change 26.4.5 [rand.predef]/p5:
+Change 26.5.5 [rand.predef]/p5:
 
          
 
 
          
@@ -13688,8 +15695,8 @@ object of type ranlux48_base shall produce the value
 
 
          
 
          797. ranlux48 returns wrong value
          
-
          Section: 26.4.5 [rand.predef] Status: NAD
- Submitter: P.J. Plauger Date: 2008-02-09
          
+
          Section: 26.5.5 [rand.predef] Status: NAD
+ Submitter: P.J. Plauger Opened: 2008-02-09  Last modified: 2008-02-27
          
 
          View all other issues in [rand.predef].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -13711,7 +15718,7 @@ Submitter withdraws defect.
 
 
          Proposed resolution:
          
 
          
-Change 26.4.5 [rand.predef]/p6:
+Change 26.5.5 [rand.predef]/p6:
 
          
 
 
          
@@ -13731,8 +15738,8 @@ object of type ranlux48 shall produce the value
 
 
          
 
          799. [tr.rand.eng.mers] and [rand.eng.mers]
          
-
          Section: 26.4.3.2 [rand.eng.mers], TR1 5.1.4.2 [tr.rand.eng.mers] Status: NAD
- Submitter: Stephan Tolksdorf Date: 2008-02-18
          
+
          Section: 26.5.3.2 [rand.eng.mers], TR1 5.1.4.2 [tr.rand.eng.mers] Status: NAD
+ Submitter: Stephan Tolksdorf Opened: 2008-02-18  Last modified: 2008-03-11
          
 
          View all other issues in [rand.eng.mers].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -13748,7 +15755,7 @@ although they will produce an identical sequence of random numbers.
 
          
 
 
          
-26.4.3.2 [rand.eng.mers] in the latest C++ draft does not specify the behaviour
+26.5.3.2 [rand.eng.mers] in the latest C++ draft does not specify the behaviour
 of operator== but uses a similar definition of the state and, just like
 TR1 5.1.4.2 [tr.rand.eng.mers], requires the textual representation of a
 mersenne_twister_engine to consist of Xi-n to Xi-1, including the
@@ -13761,7 +15768,7 @@ conceptually is a bit ugly.
 
          
 
 
          
-I propose that a paragraph or footnote is added to 26.4.3.2 [rand.eng.mers] which
+I propose that a paragraph or footnote is added to 26.5.3.2 [rand.eng.mers] which
 clarifies that the lower r bits of Xi-n are not to be compared in
 operator== and operator!=. It would only be consequent if furthermore
 the specification for the textual respresentation was changed to
@@ -13801,7 +15808,7 @@ Revisted: Agree that the fact that there is no practical difference means that n
 
 
          Proposed resolution:
          
 
          
-In 26.4.3.2 [rand.eng.mers]:
+In 26.5.3.2 [rand.eng.mers]:
 
          
 
 
          
@@ -13830,10 +15837,95 @@ The textual representation of xi consists of the values of
 
 
 
+
          
+
          800. Issues in 26.4.7.1 [rand.util.seedseq](6)
          
+
          Section: 26.5.7.1 [rand.util.seedseq] Status: NAD Editorial
+ Submitter: Stephan Tolksdorf Opened: 2008-02-18  Last modified: 2009-03-09
          
+
          View all other issues in [rand.util.seedseq].
          
+
          View all issues with NAD Editorial status.
          
+
          Discussion:
          
+
          
+The for-loop in the algorithm specification has n iterations, where n is
+defined to be end - begin, i.e. the number of supplied w-bit quantities.
+Previous versions of this algorithm and the general logic behind it
+suggest that this is an oversight and that in the context of the
+for-loop n should be the number of full 32-bit quantities in b (rounded
+upwards). If w is 64, the current algorithm throws away half of all bits
+in b. If w is 16, the current algorithm sets half of all elements in v
+to 0.
+
          
+
+
          
+There are two more minor issues:
+
          
+
+
            
+
          • 
+Strictly speaking end - begin is not defined since
+InputIterator is not required to be a random access iterator.
+
            • 
+
          • 
+Currently all integral types are allowed as input to the seed_seq
+constructor, including bool. IMHO allowing bools unnecessarily
+complicates the implementation without any real benefit to the user.
+I'd suggest to exclude bools as input.
+
            • 
+
          
+
+
          [
+Bellevue:
+]
          
+
+
+
          
+Move to OPEN Bill will try to propose a resolution by the next meeting.
+
          
+
+
          [
+post Bellevue:  Bill provided wording.
+]
          
+
+
+
          
+This issue is made moot if 803 is accepted.
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+Replace 26.5.7.1 [rand.util.seedseq] paragraph 6 with:
+
          
+
+
          
+
          
+Effects: Constructs a seed_seq object by effectively concatenating the
+low-order u bits of each of the elements of the supplied sequence [begin,
+end)
+in ascending order of significance to make a (possibly very large) unsigned
+binary number b having a total of n bits, and then carrying out the
+following
+algorithm:
+
          
+
+
          for( v.clear(); n > 0; n -= 32 )
+   v.push_back(b mod 232), b /= 232;
+
          
+
          
+
+
+
          Rationale:
          
+Addressed by
+N2836 "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
+
+
+
+
+
 
          
 
          802. knuth_b returns wrong value
          
-
          Section: 26.4.5 [rand.predef] Status: NAD
- Submitter: P.J. Plauger Date: 2008-02-20
          
+
          Section: 26.5.5 [rand.predef] Status: NAD
+ Submitter: P.J. Plauger Opened: 2008-02-20  Last modified: 2008-03-17
          
 
          View all other issues in [rand.predef].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -13845,7 +15937,7 @@ The 10,000th value returned by knuth_b is supposed to be
 
 
          Proposed resolution:
          
 
          
-Change 26.4.5 [rand.predef]/p8:
+Change 26.5.5 [rand.predef]/p8:
 
          
 
 
          
@@ -13868,10 +15960,387 @@ Bellevue: Submitter withdraws defect. "We got the wrong value for entirely the r
 
 
 
+
          
+
          803. Simplification of seed_seq::seq_seq
          
+
          Section: 26.5.7.1 [rand.util.seedseq] Status: NAD Editorial
+ Submitter: Charles Karney Opened: 2008-02-22  Last modified: 2009-03-09
          
+
          View all other issues in [rand.util.seedseq].
          
+
          View all issues with NAD Editorial status.
          
+
          Discussion:
          
+
          
+seed_seq(InputIterator begin, InputIterator end); constructs a seed_seq
+object repacking the bits of supplied sequence [begin, end) into a
+32-bit vector.
+
          
+
          
+This repacking triggers several problems:
+
          
+
            
+
          1. 
+Distinctness of the output of seed_seq::generate required the
+introduction of the initial "if (w < 32) v.push_back(n);"  (Otherwise
+the unsigned short vectors [1, 0] and [1] generate the same sequence.)
+
            2. 
+
          2. 
+Portability demanded the introduction of the template parameter u.
+(Otherwise some sequences could not be obtained on computers where no
+integer types are exactly 32-bits wide.)
+
            3. 
+
          3. 
+The description and algorithm have become unduly complicated.
+
            4. 
+
          
+
          
+I propose simplifying this seed_seq constructor to be "32-bit only".
+Despite it's being simpler, there is NO loss of functionality (see
+below).
+
          
+
          
+Here's how the description would read
+
          
+
          
+
          
+26.5.7.1 [rand.util.seedseq] Class seed_seq
+
          
+
+
          
+
          template<class InputIterator>
+  seed_seq(InputIterator begin, InputIterator end);
+
          
+
          
+
          
+5 Requires: NO CHANGE
+
          
+
          
+6 Effects: Constructs a seed_seq object by
+
          
+
          
+
          for (InputIterator s = begin; s != end; ++s)
+   v.push_back((*s) mod 2^32);
+
          
+
          
+
          
+
          
+
          
+
+
          
+Discussion:
+
          
+
          
+The chief virtues here are simplicity, portability, and generality.
+
          
+
            
+
          • 
+Simplicity -- compare the above specification with the
+n2461 proposal.
+
            • 
+
          • 
+Portability -- with iterator_traits<InputIterator>::value_type =
+uint_least32_t the user is guaranteed to get the same behavior across
+platforms.
+
            • 
+
          • 
+Generality -- any behavior that the
+n2461
+proposal can achieve can be
+obtained with this simpler proposal (albeit with a shuffling of bits
+in the input sequence).
+
            • 
+
          
+
          
+Arguments (and counter-arguments) against making this change (and
+retaining the
+n2461
+behavior) are:
+
          
+
            
+
          • 
+
            
+The user can pass an array of unsigned char and seed_seq will nicely
+ repack it.
+
            
+
            
+ Response: So what?  Consider the seed string "ABC".  The
+ n2461
+ proposal results in
+
            
+
            v = { 0x3, 0x434241 };
+
            
+
            
+while the simplified proposal yields
+
            
+
            v = { 0x41, 0x42, 0x43 };
+
            
+
            
+The results produced by seed_seq::generate with the two inputs are
+different but nevertheless equivalently "mixed up" and this remains
+true even if the seed string is long.
+
            
+
            • 
+
          • 
+
            
+With long strings (e.g., with bit-length comparable to the number of
+ bits in the state), v is longer (by a factor of 4) with the simplified
+ proposal and seed_seq::generate will be slower.
+
            
+
            
+Response: It's unlikely that the efficiency of seed_seq::generate will
+ be a big issue.  If it is, the user is free to repack the seed vector
+ before constructing seed_seq.
+
            
+
            • 
+
          • 
+
            
+A user can pass an array of 64-bit integers and all the bits will be
+ used.
+
            
+
            
+ Response: Indeed.  However, there are many instances in the 
+ n2461
+ where integers are silently coerced to a narrower width and this
+ should just be a case of the user needing to read the documentation.
+ The user can of course get equivalent behavior by repacking his seed
+ into 32-bit pieces.  Furthermore, the unportability of the 
+ n2461
+ proposal with
+
            
+
            unsigned long s[] = {1, 2, 3, 4};
+seed_seq q(s, s+4);
+
            
+
            
+ which typically results in v = {1, 2, 3, 4} on 32-bit machines and in
+v = {1, 0, 2, 0, 3, 0, 4, 0} on 64-bit machines is a major pitfall for
+ unsuspecting users.
+
            
+
            • 
+
          
+
+
          
+Note: this proposal renders moot issues 782 and 800.
+
          
+
+
          [
+Bellevue:
+]
          
+
+
+
          
+Walter needs to ask Fermilab for guidance. Defer till tomorrow. Bill likes the proposed resolution.
+
          
+
+
          [
+Sophia Antipolis:
+]
          
+
+
+
          
+
          
+Marc Paterno wants portable behavior between 32bit and 64bit machines;
+we've gone to significant trouble to support portability of engines and
+their values.
+
          
+
          
+Jens: the new algorithm looks perfectly portable
+
          
+
          
+Marc Paterno to review off-line.
+
          
+
          
+Modify the proposed resolution to read "Constructs a seed_seq object by the following algorithm ..."
+
          
+
          
+Disposition: move to review; unanimous consent.
+
          
+
          
+(moots 782 and 800)
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+Change 26.5.7.1 [rand.util.seedseq]:
+
          
+
+
          
+
          template<class InputIterator, 
+  size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>
+  seed_seq(InputIterator begin, InputIterator end);
+
          
+
          
+
          
+-5- Requires: InputIterator shall satisfy the requirements of an input iterator (24.1.1)
+such that iterator_traits<InputIterator>::value_type shall denote an integral type.
+
          
+
          
+-6- Constructs a seed_seq object by the following algorithm rearranging some or all of the bits of the supplied sequence
+[begin,end) of w-bit quantities into 32-bit units, as if by the following: 
+
          
+
          
+First extract the rightmost u bits from each of the n = end
+- begin elements of the supplied sequence and concatenate all the
+extracted bits to initialize a single (possibly very large) unsigned
+binary number, b = ∑n-1i=0 (begin[i] 
+mod 2u) ˇ 2wˇi (in which the bits of each begin[i]
+are treated as denoting an unsigned quantity). Then carry out 
+the following algorithm:
+
          
+
          
+v.clear(); 
+if ($w$ < 32) 
+  v.push_back($n$); 
+for( ; $n$ > 0; --$n$) 
+  v.push_back(b mod 232), b /= 232;
+
          
+
          
+
          
+for (InputIterator s = begin; s != end; ++s)
+   v.push_back((*s) mod 232);
+
          
+
          
+
          
+
          
+
+
+
          Rationale:
          
+Addressed by
+N2836 "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
+
+
+
+
+
+
          
+
          811. pair of pointers no longer works with literal 0
          
+
          Section: 20.3.3 [pairs] Status: NAD Editorial
+ Submitter: Doug Gregor Opened: 2008-03-14  Last modified: 2008-09-26
          
+
          View other active issues in [pairs].
          
+
          View all other issues in [pairs].
          
+
          View all issues with NAD Editorial status.
          
+
          Discussion:
          
+
          #include <utility>
+
+int main()
+{
+   std::pair<char *, char *> p (0,0);
+}
+
          
+
+
          
+I just got a bug report about that, because it's valid C++03, but not
+C++0x. The important realization, for me, is that the emplace
+proposal---which made push_back variadic, causing the push_back(0)
+issue---didn't cause this break in backward compatibility. The break
+actually happened when we added this pair constructor as part of adding
+rvalue references into the language, long before variadic templates or
+emplace came along:
+
          
+
+
          template<class U, class V> pair(U&& x, V&& y);
+
          
+
+
          
+Now, concepts will address this issue by constraining that pair
+constructor to only U's and V's that can properly construct "first" and
+"second", e.g. (from
+N2322):
+
          
+
+
          template<class U , class V >
+requires Constructible<T1, U&&> && Constructible<T2, V&&>
+pair(U&& x , V&& y );
+
          
+
+
          [
+San Francisco:
+]
          
+
+
+
          
+
          
+Suggested to resolve using pass-by-value for that case.
+
          
+
          
+Side question: Should pair interoperate with tuples? Can construct a
+tuple of a pair, but not a pair from a two-element tuple.
+
          
+
          
+Related to 885.
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
          Rationale:
          
+
          [
+San Francisco:
+]
          
+
+
+
          
+Solved by
+N2770.
+
          
+
+
+
+
+
+
+
+
          
+
          812. unsolicited multithreading considered harmful?
          
+
          Section: 25.5.1 [alg.sort] Status: NAD Editorial
+ Submitter: Paul McKenney Opened: 2008-02-27  Last modified: 2008-09-17
          
+
          View all issues with NAD Editorial status.
          
+
          Discussion:
          
+
          
+Multi-threading is a good thing, but unsolicited multi-threading can
+potentially be harmful.  For example, sort() performance might be
+greatly increased via a multithreaded implementation.  However, such
+a multithreaded implementation could result in concurrent invocations
+of the user-supplied comparator.  This would in turn result in problems
+given a caching comparator that might be written for complex sort keys.
+Please note that this is not a theoretical issue, as multithreaded
+implementations of sort() already exist.
+
          
+
          
+Having a multithreaded sort() available is good, but it should not
+be the default for programs that are not explicitly multithreaded.
+Users should not be forced to deal with concurrency unless they have
+asked for it.
+
          
+
+
          [
+This may be covered by
+N2410
+Thread-Safety in the Standard Library (Rev 1).
+]
          
+
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
          Rationale:
          
+This is already covered by 17.6.5.6/20 in N2723.
+
+
+
+
+
 
          
 
          826. Equivalent of %'d, or rather, lack thereof?
          
-
          Section: 22.2.2.2 [locale.nm.put] Status: NAD
- Submitter: Peter Dimov Date: 2008-04-07
          
+
          Section: 22.4.2.2 [locale.nm.put] Status: NAD
+ Submitter: Peter Dimov Opened: 2008-04-07  Last modified: 2008-06-18
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
 
          
@@ -13930,8 +16399,8 @@ This is not a part of C99. LWG suggests submitting a paper may be appropriate.
 
 
          
 
          831. wrong type for not_eof()
          
-
          Section: 21.1.3 [char.traits.specializations] Status: NAD Editorial
- Submitter: Dietmar Kühl Date: 2008-04-23
          
+
          Section: 21.2.3 [char.traits.specializations] Status: NAD Editorial
+ Submitter: Dietmar Kühl Opened: 2008-04-23  Last modified: 2008-06-19
          
 
          View all other issues in [char.traits.specializations].
          
 
          View all issues with NAD Editorial status.
          
 
          Discussion:
          
@@ -13939,7 +16408,7 @@ This is not a part of C99. LWG suggests submitting a paper may be appropriate.
   In Table 56 (Traits requirements) the not_eof() member function
   is using an argument of type e which denotes an object of
   type X::int_type. However, the specializations in
-  21.1.3 [char.traits.specializations] all use char_type.
+  21.2.3 [char.traits.specializations] all use char_type.
   This would effectively mean that the argument type actually can't
   represent EOF in the first place. I'm pretty sure that the type used
   to be int_type which is quite obviously the only sensible
@@ -13954,9 +16423,9 @@ This is not a part of C99. LWG suggests submitting a paper may be appropriate.
 
 
          Proposed resolution:
          
 
          
-  In 21.1.3.1 [char.traits.specializations.char],
-  21.1.3.2 [char.traits.specializations.char16_t],
-  21.1.3.3 [char.traits.specializations.char32_t], and
+  In 21.2.3.1 [char.traits.specializations.char],
+  21.2.3.2 [char.traits.specializations.char16_t],
+  21.2.3.3 [char.traits.specializations.char32_t], and
    [char.traits.specializations.wchar_t] correct the
   argument type from char_type to int_type.
 
          
@@ -13969,10 +16438,359 @@ Already fixed in WP.
 
 
 
+
          
+
          832. Applying constexpr to System error support
          
+
          Section: 19.5 [syserr] Status: NAD
+ Submitter: Beman Dawes Opened: 2008-05-14  Last modified: 2008-09-17
          
+
          View all other issues in [syserr].
          
+
          View all issues with NAD status.
          
+
          Discussion:
          
+
          
+Initialization of objects of class error_code
+(19.5.2 [syserr.errcode]) and class
+error_condition (19.5.3 [syserr.errcondition]) can be made simpler and more reliable by use of
+the new constexpr feature 
+[N2349]
+of C++0x. Less code will need to be
+generated for both library implementations and user programs when
+manipulating constant objects of these types. 
+
          
+
+
          
+This was not proposed originally because the constant expressions
+proposal was moving into the standard at about the same time as the
+Diagnostics Enhancements proposal 
+[N2241],
+and it wasn't desirable to
+make the later depend on the former. There were also technical concerns
+as to how constexpr would apply to references. Those concerns are now
+resolved; constexpr can't be used for references, and that fact is
+reflected in the proposed resolution.
+
          
+
+
          
+Thanks to Jens Maurer, Gabriel Dos Reis, and Bjarne Stroustrup for clarification of constexpr requirements.
+
          
+
+
          
+LWG issue 804 is related in that it raises the question of whether the
+exposition only member cat_ of class error_code (19.5.2 [syserr.errcode]) and class
+error_condition (19.5.3 [syserr.errcondition]) should be presented as a reference or pointer.
+While in the context of 804 that is arguably an editorial question,
+presenting it as a pointer becomes more or less required with this
+proposal, given constexpr does not play well with references. The
+proposed resolution thus changes the private member to a pointer, which
+also brings it in sync with real implementations.
+
          
+
+
          [
+Sophia Antipolis:
+]
          
+
+
+
          
+On going question of extern pointer vs. inline functions for interface.
+
          
+
+
          [
+Pre-San Francisco:
+]
          
+
+
+
          
+
          
+Beman Dawes reports that this proposal is unimplementable, and thus NAD.
+
          
+
          
+Implementation would require constexpr objects of classes derived
+from class error_category, which has virtual functions, and that is
+not allowed by the core language. This was determined when trying to
+implement the proposal using a constexpr enabled compiler provided
+by Gabriel Dos Reis, and subsequently verified in discussions with
+Gabriel and Jens Maurer.
+
          
+
+
          
+
+
+
          Proposed resolution:
          
+
          
+The proposed wording assumes the LWG 805 proposed wording has been
+applied to the WP, resulting in the former posix_category being renamed
+generic_category. If 805 has not been applied, the names in this
+proposal must be adjusted accordingly.
+
          
+
+
          
+Change 19.5.1.1 [syserr.errcat.overview] Class
+error_category overview error_category synopsis  as
+indicated:
+
          
+
+
          const error_category& get_generic_category();
+const error_category& get_system_category();
+
+static extern const error_category&* const generic_category = get_generic_category();
+static extern const error_category&* const native_category system_category = get_system_category();
+
          
+
+
          
+Change 19.5.1.5 [syserr.errcat.objects] Error category objects as indicated:
+
          
+
+
          
+
          extern const error_category&* const get_generic_category();
+
          
+
          
+Returns: A reference generic_category shall point
+to an a statically initialized object of a type derived from
+class error_category.
+
          
+
+
          
+Remarks: The object's default_error_condition and equivalent virtual
+functions shall behave as specified for the class error_category. The
+object's name virtual function shall return a pointer to the string
+"GENERIC".
+
          
+
+
          extern const error_category&* const get_system_category();
+
          
+
+
          
+Returns: A reference system_category shall point
+to an a statically
+initialized object of a type derived from class error_category.
+
          
+
+
          
+Remarks:  The object's equivalent virtual functions shall behave as
+specified for class error_category. The object's name virtual function
+shall return a pointer to the string "system". The object's
+default_error_condition virtual function shall behave as follows:
+
          
+
+
          
+If the argument ev corresponds to a POSIX errno value posv, the function
+shall return error_condition(posv, generic_category). Otherwise, the
+function shall return error_condition(ev, system_category). What
+constitutes correspondence for any given operating system is
+unspecified. [Note: The number of potential system error codes is large
+and unbounded, and some may not correspond to any POSIX errno value.
+Thus implementations are given latitude in determining correspondence.
+-- end note]
+
          
+
          
+
+
          
+Change 19.5.2.2 [syserr.errcode.overview] Class error_code overview as indicated:
+
          
+
+
          class error_code {
+public:
+  ...;
+  constexpr error_code(int val, const error_category&* cat);
+  ...
+  void assign(int val, const error_category&* cat);
+  ...
+  const error_category&* category() const;
+  ...
+private:
+  int val_;                    // exposition only
+  const error_category&* cat_; // exposition only
+
          
+
+
          
+Change 19.5.2.3 [syserr.errcode.constructors] Class error_code constructors as indicated:
+
          
+
+
          
+
          constexpr error_code(int val, const error_category&* cat);
+
          
+
          
+Effects: Constructs an object of type error_code.
+
          
+
          
+Postconditions: val_ == val and cat_ == cat.
+
          
+
          
+Throws: Nothing.
+
          
+
          
+
+
          
+Change 19.5.2.4 [syserr.errcode.modifiers] Class error_code modifiers  as indicated:
+
          
+
+
          
+
          void assign(int val, const error_category&* cat);
+
          
+
          
+Postconditions: val_ == val and cat_ == cat.
+
          
+
          
+Throws: Nothing.
+
          
+
          
+
+
          
+Change 19.5.2.5 [syserr.errcode.observers] Class error_code observers  as indicated:
+
          
+
+
          
+
          const error_category&* category() const;
+
          
+
+
          
+Returns: cat_.
+
          
+
          
+Throws: Nothing.
+
          
+
          
+
+
          
+Change 19.5.3.2 [syserr.errcondition.overview] Class error_condition overview   as indicated:
+
          
+
+
          
+
          class error_condition {
+public:
+  ...;
+  constexpr error_condition(int val, const error_category&* cat);
+  ...
+  void assign(int val, const error_category&* cat);
+  ...
+  const error_category&* category() const;
+  ...
+private:
+  int val_;                    // exposition only
+  const error_category&* cat_; // exposition only
+
          
+
          
+
+
          
+Change 19.5.3.3 [syserr.errcondition.constructors] Class error_condition constructors as indicated:
+
          
+
+
          
+
          constexpr error_condition(int val, const error_category&* cat);
+
          
+
          
+Effects: Constructs an object of type error_condition.
+
          
+
          
+Postconditions: val_ == val and cat_ == cat.
+
          
+
          
+Throws: Nothing.
+
          
+
          
+
+
          
+Change 19.5.3.4 [syserr.errcondition.modifiers] Class error_condition modifiers as indicated:
+
          
+
+
          
+
          void assign(int val, const error_category&* cat);
+
          
+
          
+Postconditions: val_ == val and cat_ == cat.
+
          
+
          
+Throws: Nothing.
+
          
+
          
+
+
          
+Change 19.5.3.5 [syserr.errcondition.observers] Class error_condition observers as indicated:
+
          
+
+
          
+
          const error_category&* category() const;
+
          
+
          
+Returns: cat_.
+
          
+
          
+Throws: Nothing.
+
          
+
          
+
+
          
+Throughout 19.5 [syserr] System error support, change "category()."  to "category()->".
+Appears approximately six times.
+
          
+
+
          
+[Partially Editorial] In 19.5.4 [syserr.compare] Comparison operators,
+paragraphs 2 and 4, change "category.equivalent("  to
+"category()->equivalent(".
+
          
+
+
          
+Change 19.5.5.1 [syserr.syserr.overview] Class system_error overview as indicated:
+
          
+
+
          public:
+  system_error(error_code ec, const string& what_arg);
+  system_error(error_code ec);
+  system_error(int ev, const error_category&* ecat,
+      const string& what_arg);
+  system_error(int ev, const error_category&* ecat);
+
          
+
+
          
+Change 19.5.5.2 [syserr.syserr.members] Class system_error members as indicated:
+
          
+
+
          
+
          system_error(int ev, const error_category&* ecat, const string& what_arg);
+
          
+
          
+
          
+Effects: Constructs an object of class system_error.
+
          
+
          
+Postconditions: code() == error_code(ev, ecat) and
+strcmp(runtime_error::what(), what_arg.c_str()) == 0.
+
          
+
          
+
+
          system_error(int ev, const error_category&* ecat);
+
          
+
          
+
          
+Effects: Constructs an object of class system_error.
+
          
+
          
+Postconditions: code() == error_code(ev, ecat) and
+strcmp(runtime_error::what(), "") == 0.
+
          
+
          
+
          
+
+
+
+
          Rationale:
          
+
          [
+San Francisco:
+]
          
+
+
+
          
+NAD because Beman said so.
+
          
+
+
+
+
+
 
          
 
          840. pair default template argument
          
-
          Section: 20.2.3 [pairs] Status: NAD
- Submitter: Thorsten Ottosen Date: 2008-05-23
          
+
          Section: 20.3.3 [pairs] Status: NAD
+ Submitter: Thorsten Ottosen Opened: 2008-05-23  Last modified: 2008-06-18
          
+
          View other active issues in [pairs].
          
 
          View all other issues in [pairs].
          
 
          View all issues with NAD status.
          
 
          Discussion:
          
@@ -13987,14 +16805,14 @@ help those cases where we use it as a return or argument type).
 
 
          Proposed resolution:
          
 
          
-Change the synopsis in 20.2 [utility] to read:
+Change the synopsis in 20.3 [utility] to read:
 
          
 
 
          template <class T1, class T2 = T1> struct pair;
 
          
 
 
          
-Change 20.2.3 [pairs] to read:
+Change 20.3.3 [pairs] to read:
 
          
 
 
          namespace std {
@@ -14013,4 +16831,1597 @@ Change 20.2.3 [pairs] to read:
 
 
 
+
          
+
          841. cstdint.syn inconsistent with C99
          
+
          Section: 18.4.1 [cstdint.syn] Status: NAD Editorial
+ Submitter: Martin Sebor Opened: 2008-05-17  Last modified: 2008-09-17
          
+
          View all other issues in [cstdint.syn].
          
+
          View all issues with NAD Editorial status.
          
+
          Discussion:
          
+   
          
+
+In specifying the names of macros and types defined in
+header <stdint.h>, C99 makes use of the
+symbol N to accommodate unusual platforms with
+word sizes that aren't powers of two. C99
+permits N to take on any positive integer value
+(including, for example, 24).
+
+   
          
+   
          
+
+In  cstdint.syn Header <cstdint>
+synopsis, C++ on the other hand, fixes the value
+of N to 8, 16, 32, and 64, and specifies only
+types with these exact widths. 
+
+   
          
+   
          
+   
          
+
+In addition, paragraph 1 of the same section makes use of a rather
+informal shorthand notation to specify sets of macros. When
+interpreted strictly, the notation specifies macros such
+as INT_8_MIN that are not intended to be specified.
+
+   
          
+
+Finally, the section is missing the usual table of symbols defined
+in that header, making it inconsistent with the rest of the
+specification.
+
+   
          
+ 
+ 
          Proposed resolution:
          
+   
          
+
+I propose to use the same approach in the C++ spec as C99 uses, that
+is, to specify the header synopsis in terms of "exposition only" types
+that make use of the symbol N to denote one or
+more of a theoretically unbounded set of widths.
+
+   
          
+   
          
+
+Further, I propose to add a new table to section listing the symbols
+defined in the header using a more formal notation that avoids
+introducing inconsistencies.
+
+   
          
+   
          
+
+To this effect, in  cstdint.syn
+Header <cstdint> synopsis, replace both the
+synopsis and paragraph 1 with the following text:
+
+   
          
+   
          
+     
          
+       
            
+         
          1. 
+
+In the names defined in the <cstdint> header, the
+symbol N represents a positive decimal integer
+with no leading zeros (e.g., 8 or 24, but not 0, 04, or 048). With the
+exception of exact-width types, macros and types for values
+of N in the set of 8, 16, 32, and 64 are
+required. Exact-width types, and any macros and types for values
+of N other than 8, 16, 32, and 64 are
+optional. However, if an implementation provides integer types with
+widths of 8, 16, 32, or 64 bits, the corresponding exact-width types
+and macros are required.
+
+         
            2. 
+       
          
+     
+     
          namespace std {
+
+   // required types
+
+   // Fastest minimum-width integer types
+   typedef signed integer type   int_fast8_t;
+   typedef signed integer type   int_fast16_t;
+   typedef signed integer type   int_fast32_t;
+   typedef signed integer type   int_fast64_t;
+
+   typedef unsigned integer type uint_fast8_t;
+   typedef unsigned integer type uint_fast16_t;
+   typedef unsigned integer type uint_fast32_t;
+   typedef unsigned integer type uint_fast64_t;
+
+   // Minimum-width integer types
+   typedef signed integer type   int_least8_t;
+   typedef signed integer type   int_least16_t;
+   typedef signed integer type   int_least32_t;
+   typedef signed integer type   int_least64_t;
+
+   typedef unsigned integer type uint_least8_t;
+   typedef unsigned integer type uint_least16_t;
+   typedef unsigned integer type uint_least32_t;
+   typedef unsigned integer type uint_least64_t;
+
+   // Greatest-width integer types
+   typedef signed integer type   intmax_t;
+   typedef unsigned integer type uintmax_t;
+
+   // optionally defined types
+
+   // Exact-width integer types
+   typedef signed integer type   intN_t;
+   typedef unsigned integer type uintN_t;
+
+   // Fastest minimum-width integer types for values
+   // of N other than 8, 16, 32, and 64
+   typedef signed integer type   uint_fastN_t;
+   typedef unsigned integer type uint_fastN_t;
+
+   // Minimum-width integer types for values
+   // of N other than 8, 16, 32, and 64
+   typedef signed integer type   uint_leastN_t;
+   typedef unsigned integer type uint_leastN_t;
+
+   // Integer types capable of holding object pointers
+   typedef signed integer type   intptr_t;
+   typedef signed integer type   intptr_t;
+
+}
          
+   
          
+   
          
+
+[Note to editor: Remove all of the existing paragraph 1 from  cstdint.syn.]
+
+   
          
+   
          
+     Table ??: Header <cstdint> synopsis
+     
          
 
          
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
          
+       
+         
+           
+           
+         
+       
+       
+         
+           
+           
+           
+           
+         
+         
+           
+           
+           
+         
+         
+           
+           
+           
+         
+         
+           
+           
+           
+         
+         
+           
+           
+           
+         
+         
+           
+           
+           
+         
+         
+           
+           
+           
+         
+         
+           
+           
+         
+         
+         
+           
+           
+           
+         
+         
+           
+           
+           
+         
+         
+           
+           
+           
+         
+         
+           
+           
+           
+           
+         
+         
+           
+           
+           
+         
+         
+           
+           
+           
+         
+         
+           
+           
+           
+         
+         
+           
+           
+           
+         
+       
+     
          TypeName(s)
          Macros:INTN_MININTN_MAXUINTN_MAX
          INT_FASTN_MININT_FASTN_MAXUINT_FASTN_MAX
          INT_LEASTN_MININT_LEASTN_MAXUINT_LEASTN_MAX
          INTPTR_MININTPTR_MAXUINTPTR_MAX
          INTMAX_MININTMAX_MAXUINTMAX_MAX
          PTRDIFF_MINPTRDIFF_MAXPTRDIFF_MAX
          SIG_ATOMIC_MINSIG_ATOMIC_MAXSIZE_MAX
          WCHAR_MINWCHAR_MAX
          WINT_MINWINT_MAX
          INTN_C()UINTN_C()
          INTMAX_C()UINTMAX_C()
          Types:intN_tuintN_t
          int_fastN_tuint_fastN_t
          int_leastN_tuint_leastN_t
          intptr_tuintptr_t
          intmax_tuintmax_t
          
+   
          
+ 
+
+
+
+
+
          
+
          849. missing type traits to compute root class and derived class of types in a class hierachy
          
+
          Section: 20.6.7 [meta.trans.other] Status: NAD
+ Submitter: Thorsten Ottosen Opened: 2008-06-05  Last modified: 2008-09-16
          
+
          View other active issues in [meta.trans.other].
          
+
          View all other issues in [meta.trans.other].
          
+
          View all issues with NAD status.
          
+
          Discussion:
          
+
          
+The type traits library contains various traits to dealt with
+polymorphic types, e.g. std::has_virtual_destructor, std::is_polymorphic
+and std::is_base_of. However, there is no way to compute the unique
+public base class of a type  if such  one exists.  Such a trait could be
+very useful if one needs to instantiate a specialization made for the
+root class whenever a derived class is passed as parameter. For example,
+imagine that you wanted to specialize std::hash for a class
+hierarchy---instead of specializing each class, you could specialize the
+std::hash<root_class> and provide a partial specialization that worked
+for all derived classes.
+
          
+
+
          
+This ability---to specify operations in terms of their equivalent in the
+root class---can be done with e.g. normal functions, but there is,
+AFAIK, no way to do it for class templates. Being able to access
+compile-time information about the type-hierachy can be very powerful,
+and I therefore also suggest traits that computes the directly derived
+class whenever that is possible.
+
          
+
+
          
+If the computation can not be done, the traits should fall back on an
+identity transformation. I expect this gives the best overall usability.
+
          
+
+
+
          Proposed resolution:
          
+
          
+Add the following to the synopsis in 20.6.2 [meta.type.synop] under "other transformations":
+
          
+
+
          template< class T > struct direct_base_class;
+template< class T > struct direct_derived_class;
+template< class T > struct root_base_class;
+
          
+
+
          
+Add three new entries to table 51 (20.6.7 [meta.trans.other]) with the following content
+
          
+
+
          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
          TemplateConditionComments
          template< class T > struct direct_base_class;T shall be a complete type.The member typedef type shall equal the accessible unambiguous direct base class of T.
+If no such type exists, the member typedef type shall equal T.
          template< class T > struct direct_derived_class;T shall be a complete type.The member typedef type shall equal the unambiguous type which has T
+as an accessible unambiguous direct base class. If no such type exists, the member typedef
+type shall equal T.
          template< class T > struct root_base_class;T shall be a complete type.The member typedef type shall equal the accessible unambiguous most indirect base class of
+T. If no such type exists, the member typedef type shall equal T.
          
+
          
+
+
+
+
          Rationale:
          
+2008-9-16 San Francisco:  Issue pulled by author prior to being reviewed by the LWG.
+
+
+
+
+
+
          
+
          855. capacity() and reserve() for deque?
          
+
          Section: 23.3.2.2 [deque.capacity] Status: NAD
+ Submitter: Hervé Brönnimann Opened: 2008-06-11  Last modified: 2008-09-22
          
+
          View all other issues in [deque.capacity].
          
+
          View all issues with NAD status.
          
+
          Discussion:
          
+
          
+The main point is that capacity can be viewed as a mechanism to  
+guarantee the validity of iterators when only push_back/pop_back
+operations are used.  For vector, this goes with reallocation.  For  
+deque, this is a bit more subtle:  capacity() of a deque may shrink,  
+whereas that of vector doesn't.   In a circular buffer impl. of the  
+map, as Howard did, there is very similar notion of capacity: as long  
+as size() is less than B * (total size of the map - 2), it is  
+guaranteed that no iterator is invalidated after any number of  
+push_front/back and pop_front/back operations.  But this does not  
+hold for other implementations.
+
          
+
          
+Still, I believe, capacity() can be defined by size() +  how many  
+push_front/back minus pop_front/back that can be performed before  
+terators are invalidated.  In a classical impl., capacity() = size()
++  the min distance to either "physical" end of the deque (i.e.,  
+counting the empty space in the last block plus all the blocks until  
+the end of the map of block pointers).  In Howard's circular buffer  
+impl., capacity() = B * (total size of the map - 2) still works with  
+this definition, even though the guarantee could be made stronger.
+
          
+
          
+A simple picture of a deque:
+
          
+
          A-----|----|-----|---F+|++++|++B--|-----|-----Z
+
          
+
          
+(A,Z mark the beginning/end, | the block boundaries, F=front, B=back,  
+and - are uninitialized, + are initialized)
+In that picture:  capacity = size() + min(dist(A,F),dist(B,Z)) = min 
+(dist(A,B),dist(F,Z)).
+
          
+
          
+Reserve(n) can grow the map of pointers and add possibly a number of  
+empty blocks to it, in order to guarantee that the next n-size()
+push_back/push_front operations will not invalidate iterators, and  
+also will not allocate (i.e. cannot throw).  The second guarantee is  
+not essential and can be left as a QoI.  I know well enough existing  
+implementations of deque (sgi/stl, roguewave, stlport, and  
+dinkumware) to know that either can be implemented with no change to  
+the existing class layout and code, and only a few modifications if  
+blocks are pre-allocated (instead of always allocating a new block,  
+check if the next entry in the map of block pointers is not zero).
+
          
+
          
+Due to the difference with vector, wording is crucial.  Here's a  
+proposed wording to make things concrete;  I tried to be reasonably  
+careful but please double-check me:
+
          
+
+
          [
+San Francisco:
+]
          
+
+
+
          
+
          
+Hans: should the Returns clause for capacity read "1 Returns: A lower
+bound..." rather than "1 Returns: An upper bound..."
+
          
+
          
+Howard: maybe what's needed is capacity_front and capacity_back. In
+fact, I think I implemented a deque that had these members as
+implementation details.
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
+
          
+Add new signatures to synopsis in 23.3.2 [deque]:
+
          
+
+
          size_type capacity() const;
+bool reserve(size_type n);
+
          
+
+
          
+Add new signatures to 23.3.2.2 [deque.capacity]:
+
          
+
+
          
+
          size_type capacity() const;
+
          
+
          
+
          
+1 Returns: An upper bound on n + max(n_f - m_f, n_b - m_b)  such  
+that, for any sequence of n_f push_front, m_f pop_front, n_b  
+push_back, and m_b pop_back operations, interleaved in any order,  
+starting with the current deque of size n, the deque does not  
+invalidate any of its iterators except to the erased elements.
+
          
+
          
+2 Remarks:  Unlike a vector's capacity, the capacity of a deque can  
+decrease after a sequence of insertions at both ends, even if none of  
+the operations caused the deque to invalidate any of its iterators  
+except to the erased elements.
+
          
+
          
+
          
+
+
          
+
          bool reserve(size_type n);
+
          
+
          
+
          
+2 Effects: A directive that informs a deque of a planned sequence of  
+push_front, pop_front, push_back, and pop_back operations, so that it  
+can manage iterator invalidation accordingly. After reserve(),  
+capacity() is greater or equal to the argument of reserve if this  
+operation returns true; and equal to the previous value of capacity()
+otherwise.  If an exception is thrown, there are no effects.
+
          
+
          
+3 Returns: true if iterators are invalidated as a result of this  
+operation, and false otherwise.
+
          
+
          
+4 Complexity: It does not change the size of the sequence and takes  
+at most linear time in n.
+
          
+
          
+5 Throws: length_error if n > max_size().
+
          
+
          
+6 Remarks: It is guaranteed that no invalidation takes place during a  
+sequence of insert or erase operations at either end that happens  
+after a call to reserve() except to the erased elements, until the  
+time when an insertion would make max(n_f-m_f, n_b-m_b) larger than  
+capacity(), where n_f is the number of push_front, m_f of pop_front,  
+n_b of push_back, and m_b of pop_back operations since the call to  
+reserve().
+
          
+
          
+7        An implementation is free to pre-allocate buffers so as to  
+offer the additional guarantee that no exception will be thrown  
+during such a sequence other than by the element constructors.
+
          
+
          
+
          
+
+
          
+And 23.3.2.3 [deque.modifiers] para 1, can be enhanced:
+
          
+
+
          
+1 Effects: An insertion in the middle of the deque invalidates all the iterators and references to elements of the
+deque. An insertion at either end of the deque invalidates all the iterators to the deque,
+unless provisions have been made with reserve,
+but has no effect on the validity of references to elements of the deque.
+
          
+
+
+
          Rationale:
          
+Complication outweighs the benefit.
+
+
+
+
+
+
          
+
          864. Defect in atomic wording
          
+
          Section: 29.6 [atomics.types.operations] Status: NAD Editorial
+ Submitter: Anthony Williams Opened: 2008-07-10  Last modified: 2008-09-17
          
+
          View all other issues in [atomics.types.operations].
          
+
          View all issues with NAD Editorial status.
          
+
          Discussion:
          
+
          
+There's an error in 29.6 [atomics.types.operations]/p9:
+
          
+
+
          
+
          C atomic_load(const volatile A * object);
+C atomic_load_explicit(const volatile A * object, memory_order);
+C A ::load(memory_order order = memory_order_seq_cst) const volatile;
+
          
+
          
+
          
+Requires: The order argument shall not be memory_order_acquire nor
+memory_order_acq_rel.
+
          
+
          
+
          
+
+
          
+I believe that this should state
+
          
+
          
+shall not be memory_order_release.
+
          
+
+
          
+There's also an error in 29.6 [atomics.types.operations]/p17:
+
          
+
+
          
+... When only one memory_order argument is supplied, the value of success
+is order, and
+the value of failure is order except that a value of
+memory_order_acq_rel shall be replaced by the value
+memory_order_require ...
+
          
+
          
+I believe this should state
+
          
+
          
+shall be replaced by the value memory_order_acquire ...
+
          
+
+
+
          Proposed resolution:
          
+
          
+Change 29.6 [atomics.types.operations]/p9:
+
          
+
+
          
+
          C atomic_load(const volatile A * object);
+C atomic_load_explicit(const volatile A * object, memory_order);
+C A ::load(memory_order order = memory_order_seq_cst) const volatile;
+
          
+
          
+
          
+Requires: The order argument shall not be memory_order_acquire
+memory_order_release nor memory_order_acq_rel.
+
          
+
          
+
          
+
+
          
+Change 29.6 [atomics.types.operations]/p17:
+
          
+
+
          
+... When only one memory_order argument is supplied, the value of success
+is order, and
+the value of failure is order except that a value of
+memory_order_acq_rel shall be replaced by the value
+memory_order_require memory_order_acquire ...
+
          
+
+
+
+
          Rationale:
          
+Already fixed by the time the LWG processed it.
+
+
+
+
+
+
          
+
          870. Do unordered containers not support function pointers for predicate/hasher?
          
+
          Section: 23.2.5 [unord.req] Status: NAD Editorial
+ Submitter: Daniel Krügler Opened: 2008-08-17  Last modified: 2008-09-22
          
+
          View other active issues in [unord.req].
          
+
          View all other issues in [unord.req].
          
+
          View all issues with NAD Editorial status.
          
+
          Discussion:
          
+
          
+Good ol' associative containers allow both function pointers and
+function objects as feasible
+comparators, as described in 23.2.4 [associative.reqmts]/2:
+
          
+
+
          
+Each associative container is parameterized on Key and an ordering
+relation Compare that
+induces a strict weak ordering (25.3) on elements of Key. [..]. The
+object of type Compare is
+called the comparison object of a container. This comparison object
+may be a pointer to
+function or an object of a type with an appropriate function call operator.[..]
+
          
+
+
          
+The corresponding wording for unordered containers is not so clear,
+but I read it to disallow
+function pointers for the hasher and I miss a clear statement for the
+equality predicate, see
+23.2.5 [unord.req]/3+4+5:
+
          
+
+
          
+
          
+Each unordered associative container is parameterized by Key, by a
+function object Hash that
+acts as a hash function for values of type Key, and by a binary
+predicate Pred that induces an
+equivalence relation on values of type Key.[..]
+
          
+
          
+A hash function is a function object that takes a single argument of
+type Key and returns a
+value of type std::size_t.
+
          
+
          
+Two values k1 and k2 of type Key are considered equal if the
+container's equality function object
+returns true when passed those values.[..]
+
          
+
          
+
+
          
+and table 97 says in the column "assertion...post-condition" for the
+expression X::hasher:
+
          
+
+
          
+Hash shall be a unary function object type such that the expression
+hf(k) has type std::size_t.
+
          
+
+
          
+Note that 20.7 [function.objects]/1 defines as "Function objects are
+objects with an operator() defined.[..]"
+
          
+
          
+Does this restriction exist by design or is it an oversight? If an
+oversight, I suggest that to apply
+the following
+
          
+
+
+
          Proposed resolution:
          
+
          
+In 23.2.5 [unord.req]/3, just after the second sentence which is written as
+
          
+
+
          
+Additionally, unordered_map and unordered_multimap associate an
+arbitrary mapped type T with the Key.
+
          
+
+
          
+add one further sentence:
+
          
+
+
          
+Both Hash and Pred may be pointers to function or objects of a type
+with an appropriate function call operator.
+
          
+
+
          
+[Note1: Since the detailed requirements for Pred and Hash are given in
+p.4 and p.5, it an alternative resolution
+would be to insert a new paragraph just after p.5, which contains the
+above proposed sentence]
+
          
+
          
+[Note2: I do not propose a change of above quoted element in table 97,
+because the mis-usage of the
+notion of "function object" seems already present in the standard at
+several places, even if it includes
+function pointers, see e.g. 25 [algorithms]/7. The important point is
+that in those places a statement is
+given that the actually used symbol, like "Predicate" applies for
+function pointers as well]
+
          
+
+
+
          Rationale:
          
+
          [
+San Francisco:
+]
          
+
+
+
          
+This is fixed by
+N2776.
+
          
+
+
+
+
+
+
+
          
+
          871. Iota's requirements on T are too strong
          
+
          Section: 26.7.5 [numeric.iota] Status: NAD
+ Submitter: Daniel Krügler Opened: 2008-08-20  Last modified: 2008-09-23
          
+
          View all issues with NAD status.
          
+
          Discussion:
          
+
          
+According to the recent WP
+N2691,
+26.7.5 [numeric.iota]/1, the requires clause
+of std::iota says:
+
          
+
+
          
+T shall meet the requirements of CopyConstructible and Assignable types, and
+shall be convertible to ForwardIterator's value type.[..]
+
          
+
+
          
+Neither CopyConstructible nor Assignable is needed, instead MoveConstructible
+seems to be the correct choice. I guess the current wording resulted as an
+artifact from comparing it with similar numerical algorithms like accumulate.
+
          
+
+
          
+Note: If this function will be conceptualized, the here proposed
+MoveConstructible
+requirement can be removed, because this is an implied requirement of
+function arguments, see
+N2710/[temp.req.impl]/3, last bullet.
+
          
+
+
+
+
          Proposed resolution:
          
+
+
          
+Change the first sentence of 26.7.5 [numeric.iota]/1:
+
          
+
+
          
+Requires: T shall meet the requirements of
+CopyConstructible and Assignable types,
+
+be MoveConstructible (Table 34)
+
+and shall be
+convertible to ForwardIterator's value type. [..]
+
          
+
+
+
+
          Rationale:
          
+
          [
+post San Francisco:
+]
          
+
+
+
          
+Issue pulled by author prior to review.
+
          
+
+
+
+
+
+
+
          
+
          872. move_iterator::operator[] has wrong return type
          
+
          Section: 24.5.3.2.12 [move.iter.op.index] Status: NAD Editorial
+ Submitter: Doug Gregor Opened: 2008-08-21  Last modified: 2008-09-22
          
+
          View all issues with NAD Editorial status.
          
+
          Discussion:
          
+
          
+move_iterator's operator[] is declared as:
+
          
+
+
          reference operator[](difference_type n) const;
+
          
+
+
          
+This has the same problem that reverse_iterator's operator[] used to
+have: if the underlying iterator's operator[] returns a proxy, the
+implicit conversion to value_type&& could end up referencing a temporary
+that has already been destroyed. This is essentially the same issue that
+we dealt with for reverse_iterator in DR 386.
+
          
+
+
+
          Proposed resolution:
          
+
          
+In 24.5.3.1 [move.iterator] and 24.5.3.2.12 [move.iter.op.index], change the declaration of
+move_iterator's operator[] to:
+
          
+
+
          reference unspecified operator[](difference_type n) const;
+
          
+
+
+
+
          Rationale:
          
+
          [
+San Francisco:
+]
          
+
+
+
          
+NAD Editorial, see
+N2777.
+
          
+
+
+
+
+
          
+
          874. Missing initializer_list constructor for discrete_distribution
          
+
          Section: 26.5.8.5.1 [rand.dist.samp.discrete] Status: NAD Editorial
+ Submitter: Daniel Krügler Opened: 2008-08-22  Last modified: 2009-03-09
          
+
          View all other issues in [rand.dist.samp.discrete].
          
+
          View all issues with NAD Editorial status.
          
+
          Discussion:
          
+
          
+During the Sophia Antipolis meeting it was decided to separate from 793 a
+subrequest that adds initializer list support to
+discrete_distribution, specifically,
+the issue proposed to add a c'tor taking a initializer_list<double>.
+
          
+
+
+
+
          Proposed resolution:
          
+
            
+
          1. 
+
            
+In 26.5.8.5.1 [rand.dist.samp.discrete]/1, class discrete_distribution,
+just before the member declaration
+
            
+
+
            explicit discrete_distribution(const param_type& parm);
+
            
+
+
            
+insert
+
            
+
+
            discrete_distribution(initializer_list<double> wl);
+
            
+
            2. 
+
+
          2. 
+
            
+Between p.4 and p.5 of the same section insert a new
+paragraph as part of the new member description:
+
            
+
+
            discrete_distribution(initializer_list<double> wl);
+
            
+
+
            
+Effects: Same as discrete_distribution(wl.begin(), wl.end()).
+
            
+
            
+
            3. 
+
          
+
+
+
          Rationale:
          
+Addressed by
+N2836 "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
+
+
+
+
+
+
          
+
          875. Missing initializer_list constructor for piecewise_constant_distribution
          
+
          Section: 26.5.8.5.2 [rand.dist.samp.pconst] Status: NAD Editorial
+ Submitter: Daniel Krügler Opened: 2008-08-22  Last modified: 2009-03-09
          
+
          View all other issues in [rand.dist.samp.pconst].
          
+
          View all issues with NAD Editorial status.
          
+
          Discussion:
          
+
          
+During the Sophia Antipolis meeting it was decided to separate from
+794 a subrequest that adds initializer list support to
+piecewise_constant_distribution, specifically, the issue proposed
+to add a c'tor taking a initializer_list<double> and a Callable to evaluate
+weight values. For consistency with the remainder of this class and
+the remainder of the initializer_list-aware library the author decided to
+change the list argument type to the template parameter RealType
+instead. For the reasoning to use Func instead of Func&& as c'tor
+function argument see issue 793.
+
          
+
+
+
          Proposed resolution:
          
+
          Non-concept version of the proposed resolution
          
+
+
            
+
          1. 
+
            
+In 26.5.8.5.2 [rand.dist.samp.pconst]/1, class piecewise_constant_distribution,
+just before the member declaration
+
            
+
+
            explicit piecewise_constant_distribution(const param_type& parm);
+
            
+
+
            
+insert
+
            
+
+
            template<typename Func>
+piecewise_constant_distribution(initializer_list<RealType> bl, Func fw);
+
            
+
            2. 
+
+
          2. 
+
            
+Between p.4 and p.5 of the same section insert a series of
+new paragraphs nominated below as [p5_1], [p5_2], and [p5_3]
+as part of the new member description:
+
            
+
+
            template<typename Func>
+piecewise_constant_distribution(initializer_list<RealType> bl, Func fw);
+
            
+
+
            
+
+
            
+[p5_1] Complexity: Exactly nf = max(bl.size(), 1) - 1 invocations of fw.
+
            
+
+
            
+[p5_2] Requires:
+
            
+
+
              
+
            1. 
+fw shall be callable with one argument of type RealType, and shall
+   return values of a type convertible to double;
+
              2. 
+
            2. 
+The relation 0 < S = w0+. . .+wn-1 shall hold. 
+For all sampled values xk defined below, fw(xk) shall return a weight
+   value wk that is non-negative, non-NaN, and non-infinity;
+
              3. 
+
            3. 
+If nf > 0 let bk = *(bl.begin() + k), k = 0, . . . , bl.size()-1 and the
+following relations shall hold for k = 0, . . . , nf-1: bk < bk+1.
+
              4. 
+
            
+
+
            
+[p5_3] Effects:
+
            
+
+
              
+
            1. 
+
              If nf == 0,
              
+
                
+
              1. 
+lets the sequence w have length n = 1 and consist of the single
+     value w0 = 1, and
+
                2. 
+
              2. 
+lets the sequence b have length n+1 with b0 = 0 and b1 = 1.
+
                3. 
+
              
+
              2. 
+
+
            2. 
+
              Otherwise,
              
+
                
+
              1. 
+sets n = nf, and [bl.begin(), bl.end()) shall form the sequence b of
+length n+1, and
+
                2. 
+
              2. 
+
                lets the sequences w have length n and for each k = 0, . . . ,n-1,
+     calculates:
                
+
                xk = 0.5*(bk+1 + bk)
+wk = fw(xk)
+
                
+
                3. 
+
              
+
              3. 
+
+
            3. 
+
              
+Constructs a piecewise_constant_distribution object with
+the above computed sequence b as the interval boundaries
+and with the probability densities:
+
              
+
              ρk = wk/(S * (bk+1 - bk)) for k = 0, . . . , n-1.
+
              
+
+
              4. 
+
            
+
+
            
+
            
+
            3. 
+
          
+
+
          Concept version of the proposed resolution
          
+
+
            
+
          1. 
+
            
+In 26.5.8.5.2 [rand.dist.samp.pconst]/1, class piecewise_constant_distribution,
+just before the member declaration
+
            
+
+
            explicit piecewise_constant_distribution(const param_type& parm);
+
            
+
+
            
+insert
+
            
+
+
            template<Callable<auto, RealType> Func>
+ requires Convertible<Func::result_type, double>
+piecewise_constant_distribution(initializer_list<RealType> bl, Func fw);
+
            
+
            2. 
+
+
          2. 
+
            
+Between p.4 and p.5 of the same section insert a series of
+new paragraphs nominated below as [p5_1], [p5_2], and [p5_3]
+as part of the new member description:
+
            
+
+
            template<Callable<auto, RealType> Func>
+ requires Convertible<Func::result_type, double>
+piecewise_constant_distribution(initializer_list<RealType> bl, Func fw);
+
            
+
+
            
+
+
            
+[p5_1] Complexity: Exactly nf = max(bl.size(), 1) - 1 invocations of fw.
+
            
+
+
            
+[p5_2] Requires:
+
            
+
+
              
+
            1. 
+The relation 0 < S = w0+. . .+wn-1 shall hold. 
+For all sampled values xk defined below, fw(xk) shall return a weight
+   value wk that is non-negative, non-NaN, and non-infinity;
+
              2. 
+
            2. 
+If nf > 0 let bk = *(bl.begin() + k), k = 0, . . . , bl.size()-1 and the
+following relations shall hold for k = 0, . . . , nf-1: bk < bk+1.
+
              3. 
+
            
+
+
            
+[p5_3] Effects:
+
            
+
+
              
+
            1. 
+
              If nf == 0,
              
+
                
+
              1. 
+lets the sequence w have length n = 1 and consist of the single
+     value w0 = 1, and
+
                2. 
+
              2. 
+lets the sequence b have length n+1 with b0 = 0 and b1 = 1.
+
                3. 
+
              
+
              2. 
+
+
            2. 
+
              Otherwise,
              
+
                
+
              1. 
+sets n = nf, and [bl.begin(), bl.end()) shall form the sequence b of
+length n+1, and
+
                2. 
+
              2. 
+
                lets the sequences w have length n and for each k = 0, . . . ,n-1,
+     calculates:
                
+
                xk = 0.5*(bk+1 + bk)
+wk = fw(xk)
+
                
+
                3. 
+
              
+
              3. 
+
+
            3. 
+
              
+Constructs a piecewise_constant_distribution object with
+the above computed sequence b as the interval boundaries
+and with the probability densities:
+
              
+
              ρk = wk/(S * (bk+1 - bk)) for k = 0, . . . , n-1.
+
              
+
+
              4. 
+
            
+
+
            
+
            
+
            3. 
+
          
+
+
+
+
          Rationale:
          
+Addressed by
+N2836 "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
+
+
+
+
+
+
          
+
          892. Forward_list issues...
          
+
          Section: 23.3.3.5 [forwardlist.ops] Status: NAD Editorial
+ Submitter: Ed Smith-Rowland Opened: 2008-09-15  Last modified: 2009-03-09
          
+
          View other active issues in [forwardlist.ops].
          
+
          View all other issues in [forwardlist.ops].
          
+
          View all issues with NAD Editorial status.
          
+
          Discussion:
          
+
          
+I was looking at the latest draft on forward_list.  Especially the splice methods.
+
          
+
          
+The first one splices a whole list after a given iterator in this.  The name is splice_after.
+I think in 23.3.3.5 [forwardlist.ops] paragraph 40
+change:
+
          
+
          
+Effect: Insert the contents of x before after position, ...
+
          
+
+
          
+A deeper issue involves the complexity.  forward_list has no size and we
+don't know when we've reached the end except to walk up to it.  To
+splice we would need to hook the end of the source list to the item
+after position in this list.  This would involve walking length of the
+source list until we got to the last dereference-able element in source.
+There's no way we could do this in O(1) unless we stored a bogus end in
+forward_list.
+
          
+
          
+OTOH, the last version of splice_after with iterator ranges we could do
+in O(1) because we know how to hook the end of the source range to ...
+
          
+
          
+Unless I'm misconceiving the whole thing.  Which is possible.  I'll look at it again.
+
          
+
          
+I'm pretty sure about the first part though.
+
          
+
+
          [
+San Francisco:
+]
          
+
+
+
          
+
          
+This issue is more complicated than it looks.
+
          
+
          
+paragraph 47: replace each (first, last) with (first, last]
+
          
+
          
+add a statement after paragraph 48 that complexity is O(1)
+
          
+
          
+remove the complexity statement from the first overload of splice_after
+
          
+
          
+We may have the same problems with other modifiers, like erase_after.
+Should it require that all iterators in the range (position, last] be
+dereferenceable?
+
          
+
          
+We do, however, like the proposed changes and consider them Editorial.
+Move to NAD Editorial, Pending. Howard to open a new issue to handle the
+problems with the complexity requirements.
+
          
+
          
+Opened 897.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+In 23.3.3.5 [forwardlist.ops] paragraph 40
+change:
+
          
+
          
+Effect: Insert the contents of x before after position, ...
+
          
+
+
+
+
+
+
          
+
          905. Mutex specification questions
          
+
          Section: 30.4.1.1 [thread.mutex.class] Status: Dup
+ Submitter: Herb Sutter Opened: 2008-09-18  Last modified: 2009-03-22
          
+
          View other active issues in [thread.mutex.class].
          
+
          View all other issues in [thread.mutex.class].
          
+
          View all issues with Dup status.
          
+
          Duplicate of: 893
          
+
          Discussion:
          
+
          
+A few questions on the current WP,
+N2723:
+
          
+
          
+30.4.1 [thread.mutex.requirements]/24 says an expression
+mut.unlock() "Throws: Nothing." I'm assuming that, per 17.6.3.11 [res.on.required], errors that violate the precondition "The
+calling thread shall own the mutex" opens the door for throwing an
+exception anyway, such as to report unbalanced unlock operations and
+unlocking from a thread that does not have ownership. Right?
+
          
+
          
+30.4.1.1 [thread.mutex.class]/3 (actually numbered paragraph "27"
+in the WP; this is just a typo I think) says
+
          
+
          
+
          
+The behavior of a program is undefined if:
+
          
+
            
+
          • it destroys a mutex object owned by any thread,
            • 
+
          • a thread that owns a mutex object calls lock() or try_lock() on that object, or
            • 
+
          • a thread terminates while owning a mutex object.
            • 
+
          
+
          
+
+
          
+As already discussed, I think the second bullet should be removed, and
+such a lock() or try_lock() should fail with an
+exception or returning false, respectively.
+
          
+
          
+A potential addition to the list would be
+
          
+
            
+
          • a thread unlocks a mutex it does not have ownership of.
            • 
+
          
+
          
+but without that the status quo text endorses the technique of the
+program logically transferring ownership of a mutex to another thread
+with correctness enforced by programming discipline. Was that intended?
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+
          
+Two resolutions: "not a defect" and "duplicate", as follows:
+
          
+
            
+
          • 
+30.4.1 [thread.mutex.requirements]/24: NAD. If the precondition
+fails the program has undefined behaviour and therefore an
+implementation may throw an exception already.
+
            • 
+
          • 
+30.4.1.1 [thread.mutex.class]/3 bullet 2: Already addressed by issue 893.
+
            • 
+
          • 
+30.4.1.1 [thread.mutex.class]/3 proposed addition: NAD. This is
+already covered by the mutex requirements, which have ownership as a
+Precondition.
+
            • 
+
          
+
          
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
+
          
+
          937. Atomics for standard typedef types
          
+
          Section: 29 [atomics] Status: NAD Editorial
+ Submitter: Clark Nelson Opened: 2008-12-05  Last modified: 2009-05-23
          
+
          View other active issues in [atomics].
          
+
          View all other issues in [atomics].
          
+
          View all issues with NAD Editorial status.
          
+
          Discussion:
          
+
+
          Addresses US 89
          
+
+
          
+
          
+The types in the table "Atomics for standard typedef types" should be
+typedefs, not classes. These semantics are necessary for compatibility
+with C.
+
          
+
+
          
+Change the classes to typedefs.
+
          
+
          
+
+
          
+N2427
+specified different requirements for atomic analogs of fundamental
+integer types (such as atomic_int) and for atomic analogs of <cstdint>
+typedefs (such as atomic_size_t). Specifically, atomic_int et al. were
+specified to be distinct classes, whereas atomic_size_t et al. were
+specified to be typedefs. Unfortunately, in applying
+N2427
+to the WD, that distinction was erased, and the atomic analog of every <cstdint>
+typedef is required to be a distinct class.
+
          
+
+
          
+It shouldn't be required that the atomic analog of every <cstdint>
+typedef be a typedef for some fundamental integer type. After all,
+<cstdint> is supposed to provide standard names for extended integer
+types. So there was a problem in
+N2427,
+which certainly could have been
+interpreted to require that. But the status quo in the WD is even worse,
+because it's unambiguously wrong.
+
          
+
+
          
+What is needed are words to require the existence of a bunch of type
+names, without specifying whether they are class names or typedef names.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+
          
+Change status to NAD, editorial. See US 89 comment notes above.
+
          
+
          
+Direct the editor to turn the types into typedefs as proposed in the
+comment. Paper approved by committee used typedefs, this appears to have
+been introduced as an editorial change. Rationale: for compatibility
+with C.
+
          
+
          
+
+
+
          Proposed resolution:
          
+
          
+
          
+
+
+
+
+
+
          
+
          942. Atomics synopsis typo
          
+
          Section: 29 [atomics] Status: Dup
+ Submitter: Holger Grund Opened: 2008-12-19  Last modified: 2009-03-22
          
+
          View other active issues in [atomics].
          
+
          View all other issues in [atomics].
          
+
          View all issues with Dup status.
          
+
          Duplicate of: 880
          
+
          Discussion:
          
+
+
+
+
          
+I'm looking at 29 [atomics] and can't really make sense of a couple of things.
+
          
+
          
+Firstly, there appears to be a typo in the <cstdatomic> synopsis:
+
          
+
+
          
+
          
+The atomic_exchange overload taking an atomic_address
+is missing the second parameter:
+
          
+
+
          void* atomic_exchange(volatile atomic_address*);
+
          
+
+
          
+should be
+
          
+
+
          void* atomic_exchange(volatile atomic_address*, void*);
+
          
+
+
          
+Note, that this is not covered by 880 "Missing atomic exchange parameter",
+which only talks about the atomic_bool.
+
          
+
          
+
+
+
+
          Proposed resolution:
          
+
          
+Change the synopsis in 29 [atomics]/2:
+
          
+
+
          void* atomic_exchange(volatile atomic_address*, void*);
+
          
+
+
+
+
+
+
+
          
+
          980. mutex lock() missing error conditions
          
+
          Section: 30.4.1 [thread.mutex.requirements] Status: NAD
+ Submitter: Ion Gaztańaga Opened: 2009-02-07  Last modified: 2009-03-22
          
+
          View other active issues in [thread.mutex.requirements].
          
+
          View all other issues in [thread.mutex.requirements].
          
+
          View all issues with NAD status.
          
+
          Discussion:
          
+
          
+POSIX 2008 adds two return values for pthread_mutex_xxxlock():
+EOWNERDEAD (owner_dead) and ENOTRECOVERABLE
+(state_not_recoverable). In the first case the mutex is locked,
+in the second case the mutex is not locked.
+
          
+
+
          
+Throwing an exception in the first case can be incompatible with the use
+of Locks, since the Lock::owns_lock() will be false when the lock is
+being destroyed.
+
          
+
+
          
+Consider:
+
          
+
+
          //Suppose mutex.lock() throws "owner_dead"
+unique_lock ul(&mutex);
+//mutex left locked if "owner_dead" is thrown
+
          
+
+
          
+Throwing an exception with owner_dead might be also undesirable if
+robust-mutex support is added to C++ and the user has the equivalent of
+pthread_mutex_consistent() to notify the user has fixed the corrupted
+data and the mutex state should be marked consistent.
+
          
+
+
            
+
          1. 
+For state_not_recoverable add it to the list of Error conditions:
+
            2. 
+
          2. 
+For owner_dead, no proposed resolution.
+
            3. 
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          
+Not a defect. Handling these error conditions is an implementation
+detail and must be handled below the C++ interface.
+
          
+
+
+
+
          Proposed resolution:
          
+
+
          
+Add to 30.4.1 [thread.mutex.requirements], p12:
+
          
+
+
          
+
          
+-12- Error conditions:
+
          
+
+
            
+
          • 
+operation_not_permitted -- if the thread does not have the necessary permission to change 
+the state of the mutex.
+
            • 
+
          • 
+resource_deadlock_would_occur -- if the current thread already owns the mutex and is able 
+to detect it.
+
            • 
+
          • 
+device_or_resource_busy --  if the mutex is already locked and blocking is not possible.
+
            • 
+
          • 
+state_not_recoverable -- if the state protected by the mutex is not recoverable.
+
            • 
+
          
+
          
+
+
+
+
+
+
          
+
          1022. Response to UK 212
          
+
          Section: 20.8.13.7 [util.dynamic.safety] Status: NAD Editorial
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-03-12
          
+
          View all other issues in [util.dynamic.safety].
          
+
          View all issues with NAD Editorial status.
          
+
          Discussion:
          
+
+
          Addresses UK 212
          
+
+
          
+The pointer-safety API is nothing to do with smart pointers, so does not
+belong in 20.8.13 [util.smartptr]. In fact it is a set of language
+support features are really belongs in clause 18 [language.support], with the contents declared in a header that
+deals with language-support of memory management.
+
          
+
+
          [
+Summit:
+]
          
+
+
+
          Agree in principle, but not with the proposed resolution.
+We believe it
+belongs either a subsection of either 20 [utilities] or 20.8 [memory]
+as part of the general reorganization of 20 [utilities]. The
+declaration should stay in
+<memory>.
+
          
+
+
+
+
          Proposed resolution:
          
+
+
+
+
+
+
          
+
          1025. Response to UK 208
          
+
          Section: 20.7.17 [unord.hash] Status: NAD Future
+ Submitter: Alisdair Meredith Opened: 2009-03-11  Last modified: 2009-03-12
          
+
          View other active issues in [unord.hash].
          
+
          View all other issues in [unord.hash].
          
+
          Discussion:
          
+
+
          Addresses UK 208
          
+
+
          
+std::hash should be implemented for much more of the standard
+library. In particular for pair, tuple and all the
+standard containers.
+
          
+
+
+
+
          Proposed resolution:
          
+
+
+
+
+
 
\ No newline at end of file
diff --git a/libstdc++-v3/doc/html/ext/lwg-defects.html b/libstdc++-v3/doc/html/ext/lwg-defects.html
index 5951a9821e2..5dedc1365cb 100644
--- a/libstdc++-v3/doc/html/ext/lwg-defects.html
+++ b/libstdc++-v3/doc/html/ext/lwg-defects.html
@@ -14,11 +14,11 @@ del {background-color:#FFA0A0}
 
-
+
-
+
@@ -29,9 +29,9 @@ del {background-color:#FFA0A0}
 
          
 
          
 Doc. no.N2728=08-0238N2895=09-0085
 
          
 
          
 Date:2008-08-242009-06-21
 
          
 
          
 Project:Howard Hinnant <howard.hinnant@gmail.com>
 
          
 
          
-
          C++ Standard Library Defect Report List (Revision R59)
          
+
          C++ Standard Library Defect Report List (Revision R65)
          
 
-  
          Reference ISO/IEC IS 14882:1998(E)
          
+  
          Reference ISO/IEC IS 14882:2003(E)
          
   
          Also see:
          
     
          48. 
 
        48. Details:
            
-
          • Added the following New issues: 862, 863, 864, 865, 866, 867, 868, 869.
            • 
+
          • Added the following New issues: 862, 863, 864, 865, 866, 867, 868, 869.
            • 
 
          • Changed the following issues from Pending NAD Editorial to NAD Editorial: 393, 557, 592, 754, 757.
            • 
 
          • Changed the following issues from Pending WP to Open: 644.
            • 
-
          • Changed the following issues from WP to Ready: 387, 629.
            • 
-
          • Changed the following issues from Pending NAD Editorial to Review: 709.
            • 
+
          • Changed the following issues from WP to Ready: 387, 629.
            • 
+
          • Changed the following issues from Pending NAD Editorial to Review: 709.
            • 
 
          49. 
 
 
@@ -91,24 +233,24 @@ del {background-color:#FFA0A0}
 
 
        49. Details:
          50. 
 
 
@@ -121,7 +263,7 @@ del {background-color:#FFA0A0}
 
        50. 838 issues total, up by 25.
          51. 
 
 
        51. Details:
          52. 
 
@@ -137,8 +279,8 @@ del {background-color:#FFA0A0}
 
        52. Details:
          53. 
 
        53. Details:
          54. 
 
        54. Details:
          55. 
@@ -204,16 +346,16 @@ del {background-color:#FFA0A0}
 
        55. 754 issues total, up by 31.
          56. 
 
 
        56. Details:
          57. 
 
        57. Details:
          58. 
 
 
@@ -242,13 +384,13 @@ del {background-color:#FFA0A0}
 
        58. 708 issues total, up by 12.
          59. 
 
 
        59. Details:
            
-
          • Added the following New issues: 697, 698, 699, 700, 701, 702, 703, 704, 705, 706, 707, 708.
            • 
+
          • Added the following New issues: 697, 698, 699, 700, 701, 702, 703, 704, 705, 706, 707, 708.
            • 
 
          • Changed the following issues from New to NAD: 583, 584, 662.
            • 
 
          • Changed the following issues from Open to NAD: 528.
            • 
 
          • Changed the following issues from New to NAD Editorial: 637, 647, 658, 690.
            • 
 
          • Changed the following issues from Open to NAD Editorial: 525.
            • 
 
          • Changed the following issues from Pending NAD Editorial to NAD Editorial: 553, 571, 591, 633, 636, 641, 642, 648, 649, 656.
            • 
-
          • Changed the following issues from New to Open: 579, 631, 680.
            • 
+
          • Changed the following issues from New to Open: 579, 631, 680.
            • 
 
          • Changed the following issues from Pending WP to Open: 258.
            • 
 
          • Changed the following issues from Ready to Pending WP: 644.
            • 
 
          • Changed the following issues from New to Ready: 577, 660.
            • 
@@ -269,7 +411,7 @@ del {background-color:#FFA0A0}
 
          • 696 issues total, up by 20.
            • 
 
          60. 
 
        60. Details:
          61. 
 
        61. Details:
          62. 
 
        62. Details:
          63. 
 
@@ -331,7 +473,7 @@ del {background-color:#FFA0A0}
 
        63. 619 issues total, up by 10.
          64. 
 
 
        64. Details:
          65. 
 
 
@@ -347,10 +489,10 @@ del {background-color:#FFA0A0}
 
        65. Moved issues 520, 521, 530, 535, 537, 538, 540, 541 to WP.
          66. 
 
        66. Moved issues 504, 512, 516, 544, 549, 554, 555, 558 to NAD.
          67. 
 
        67. Moved issue 569 to Dup.
          68. 
-
        68. Moved issues 518, 523, 524, 542, 556, 557, 559, 597, 606 to Open.
          69. 
+
        69. Moved issues 518, 523, 524, 542, 556, 557, 559, 597, 606 to Open.
          70. 
 
        70. Moved issues 543, 545, 549, 549, 598 - 603, 605 to Ready.
          71. 
 
        71. Moved issues 531, 551, 604 to Review.
          72. 
-
        72. Added new issues 593-609.
          73. 
+
        73. Added new issues 593, 594, 595, 596, 597, 598, 599, 600, 601, 602, 603, 604, 605, 606, 607, 608, 609.
          74. 
 
 
 
@@ -363,7 +505,7 @@ del {background-color:#FFA0A0}
 
        74. 592 issues total, up by 5.
          75. 
 
 
        75. Details:
          76. 
 
 
@@ -376,7 +518,7 @@ del {background-color:#FFA0A0}
 
        76. 587 issues total, up by 13.
          77. 
 
 
        77. Details:
          78. 
@@ -391,9 +533,9 @@ del {background-color:#FFA0A0}
 
        78. 574 issues total, up by 8.
          79. 
 
 
        79. Details:
          80. 
 
        80. Details:
          81. 
@@ -424,7 +566,7 @@ del {background-color:#FFA0A0}
 
        81. 535 issues total.
          82. 
 
 
        82. Details:
          83. 
 
 
@@ -440,7 +582,7 @@ Moved issue 504-522.
+Merged open TR1 issues in 504-522.
 Added new issues 523-523
 
 
        83. R37: 
@@ -449,7 +591,7 @@ Added new issues 454 were moved to "DR" status, and all issues
+for 454 were moved to "DR" status, and all issues
 previously in "DR" status were moved to "WP".
 
          84. 
 
        84. R35: 
@@ -497,7 +639,7 @@ Pre-Oxford mailing.  Added new issues 253, which has been given a new proposed resolution, were
-moved to DR status.  Added new issues 383-389.  (Issues 387-389 were discussed
+moved to DR status.  Added new issues 383-389.  (Issues 387-389 were discussed
 at the meeting.)  Made progress on issues 225, 226, 229: 225 and 229 have been moved to Ready status, and the only remaining
 concerns with 226 involve wording.
 
          85. 
@@ -556,7 +698,7 @@ Changed status of issues
 to Ready.
 
 Closed issues 
-111 277 279 287
+111 277 279 287
 289 293 302 313
 314
 as NAD.
@@ -582,7 +724,7 @@ issues 209, 210, 211,
 212, 217, 220,
 222, 223, 224,
-227 to "DR".  Reopened issue 23. Reopened
+227 to "DR".  Reopened issue 23. Reopened
 issue 187. Changed issues 2 and
 4 to NAD. Fixed a typo in issue 17. Fixed
 issue 70: signature should be changed both places it
@@ -635,7 +777,7 @@ in Dublin. (99-0016/N1193, 21 Apr 99)
 pre-Dublin updated: Added issues 130, 131,
 132, 133, 134,
 135, 136, 137,
-138, 139 (31 Mar 99)
+138, 139 (31 Mar 99)
 
 
        85. R6: 
 pre-Dublin mailing. Added issues 127, 128,
@@ -648,7 +790,7 @@ for making list public. (30 Dec 98)
 
          86. 
 
        86. R4: 
 post-Santa Cruz II updated: Issues 110,
-111, 112, 113 added, several
+111, 112, 113 added, several
 issues corrected. (22 Oct 98)
 
          87. 
 
        87. R3: 
@@ -668,9 +810,9 @@ format, 1. C library linkage editing oversight
-
          Section: 17.4.2.2 [using.linkage] Status: TC
- Submitter: Beman Dawes Date: 1997-11-16
          
-
          View all issues with TC status.
          
+
          Section: 17.6.2.3 [using.linkage] Status: TC1
+ Submitter: Beman Dawes Opened: 1997-11-16  Last modified: 2008-09-26
          
+
          View all issues with TC1 status.
          
 
          Discussion:
          
 
          The change specified in the proposed resolution below did not make
 it into the Standard. This change was accepted in principle at the
@@ -679,7 +821,7 @@ Morristown meeting.
          
 
 
 
          Proposed resolution:
          
-
          Change 17.4.2.2 [using.linkage] paragraph 2
+
          Change 17.6.2.3 [using.linkage] paragraph 2
 from:
          
 
 
          
@@ -703,9 +845,10 @@ from:
          
 
 
          
 
          3. Atexit registration during atexit() call is not described
          
-
          Section: 18.4 [support.start.term] Status: TC
- Submitter: Steve Clamage Date: 1997-12-12
          
-
          View all issues with TC status.
          
+
          Section: 18.5 [support.start.term] Status: TC1
+ Submitter: Steve Clamage Opened: 1997-12-12  Last modified: 2008-09-26
          
+
          View all other issues in [support.start.term].
          
+
          View all issues with TC1 status.
          
 
          Discussion:
          
 
          We appear not to have covered all the possibilities of
  exit processing with respect to
@@ -836,10 +979,10 @@ supporting to the proposed resolution.
          
 
 
          
 
          5. String::compare specification questionable
          
-
          Section: 21.3.6.8 [string::swap] Status: TC
- Submitter: Jack Reeves Date: 1997-12-11
          
+
          Section: 21.4.6.8 [string::swap] Status: TC1
+ Submitter: Jack Reeves Opened: 1997-12-11  Last modified: 2008-09-26
          
 
          View all other issues in [string::swap].
          
-
          View all issues with TC status.
          
+
          View all issues with TC1 status.
          
 
          Duplicate of: 87
          
 
          Discussion:
          
 
          At the very end of the basic_string class definition is the signature: int
@@ -863,7 +1006,7 @@ charT* s, size_type n2) const; each defined in terms of the corresponding constr
 
 
 
          Proposed resolution:
          
-
          Replace the compare signature in 21.3 [basic.string]
+
          Replace the compare signature in 21.4 [basic.string]
 (at the very end of the basic_string synopsis) which reads:
          
 
 
          
@@ -882,7 +1025,7 @@ charT* s, size_type n2) const; each defined in terms of the corresponding constr
   size_type n2) const;
          
 
          
 
-
          Replace the portion of 21.3.6.8 [string::swap]
+
          Replace the portion of 21.4.6.8 [string::swap]
 paragraphs 5 and 6 which read:
          
 
 
          
@@ -929,12 +1072,12 @@ identified in issues 7 (item 5) and 87.
          
 
 
          
 
          7. String clause minor problems
          
-
          Section: 21 [strings] Status: TC
- Submitter: Matt Austern Date: 1997-12-15
          
+
          Section: 21 [strings] Status: TC1
+ Submitter: Matt Austern Opened: 1997-12-15  Last modified: 2008-09-26
          
 
          View all other issues in [strings].
          
-
          View all issues with TC status.
          
+
          View all issues with TC1 status.
          
 
          Discussion:
          
-
          (1) In 21.3.6.4 [string::insert], the description of template
+
          (1) In 21.4.6.4 [string::insert], the description of template
 <class InputIterator> insert(iterator, InputIterator,
 InputIterator) makes no sense. It refers to a member function that
 doesn't exist. It also talks about the return value of a void
@@ -955,9 +1098,9 @@ possible const charT&. 
          
 charT* in the description. Second, given what it says in RETURNS,
 leaving out the final argument will always result in an exception
 getting thrown. This is paragraphs 5 and 6 of 
-21.3.6.8 [string::swap]
          
+21.4.6.8 [string::swap]
          
 
-
          (6) In table 37, in section 21.1.1 [char.traits.require],
+
          (6) In table 37, in section 21.2.1 [char.traits.require],
 there's a note for X::move(s, p, n). It says "Copies correctly
 even where p is in [s, s+n)". This is correct as far as it goes,
 but it doesn't go far enough; it should also guarantee that the copy
@@ -1010,9 +1153,9 @@ s+n) overlap."
          
 
 
          
 
          8. Locale::global lacks guarantee
          
-
          Section: 22.1.1.5 [locale.statics] Status: TC
- Submitter: Matt Austern Date: 1997-12-24
          
-
          View all issues with TC status.
          
+
          Section: 22.3.1.5 [locale.statics] Status: TC1
+ Submitter: Matt Austern Opened: 1997-12-24  Last modified: 2008-09-26
          
+
          View all issues with TC1 status.
          
 
          Discussion:
          
 
          It appears there's an important guarantee missing from clause
 22. We're told that invoking locale::global(L) sets the C locale if L
@@ -1024,7 +1167,7 @@ such words anywhere. 
          
 
 
 
          Proposed resolution:
          
-
          Add a sentence at the end of 22.1.1.5 [locale.statics],
+
          Add a sentence at the end of 22.3.1.5 [locale.statics],
 paragraph 2:  
          
 
 
          
@@ -1039,9 +1182,10 @@ paragraph 2:  
          
 
 
          
 
          9. Operator new(0) calls should not yield the same pointer
          
-
          Section: 18.5.1 [new.delete] Status: TC
- Submitter: Steve Clamage Date: 1998-01-04
          
-
          View all issues with TC status.
          
+
          Section: 18.6.1 [new.delete] Status: TC1
+ Submitter: Steve Clamage Opened: 1998-01-04  Last modified: 2008-09-26
          
+
          View all other issues in [new.delete].
          
+
          View all issues with TC1 status.
          
 
          Discussion:
          
 
          Scott Meyers, in a comp.std.c++ posting: I just noticed that
 section 3.7.3.1 of CD2 seems to allow for the possibility that all
@@ -1106,10 +1250,11 @@ supporting to the proposed resolution.
          
 
 
          
 
          11. Bitset minor problems
          
-
          Section: 23.3.5 [template.bitset] Status: TC
- Submitter: Matt Austern Date: 1998-01-22
          
+
          Section: 20.3.6 [template.bitset] Status: TC1
+ Submitter: Matt Austern Opened: 1998-01-22  Last modified: 2008-09-26
          
+
          View other active issues in [template.bitset].
          
 
          View all other issues in [template.bitset].
          
-
          View all issues with TC status.
          
+
          View all issues with TC1 status.
          
 
          Discussion:
          
 
          (1) bitset<>::operator[] is mentioned in the class synopsis (23.3.5), but it is
 not documented in 23.3.5.2. 
          
@@ -1126,7 +1271,7 @@ go in the Effects clause.
          
 
          Proposed resolution:
          
 
          ITEMS 1 AND 2:
          
 
          
-In the bitset synopsis (23.3.5 [template.bitset]), 
+In the bitset synopsis (20.3.6 [template.bitset]), 
 replace the member function 
          
 
          
     reference operator[](size_t pos);
          
@@ -1136,7 +1281,7 @@ with the two member functions
          
     bool operator[](size_t pos) const; 
          
     reference operator[](size_t pos); 
          
 
          
-Add the following text at the end of 23.3.5.2 [bitset.members], 
+Add the following text at the end of 20.3.6.2 [bitset.members], 
 immediately after paragraph 45:
          
 
 
          
@@ -1156,7 +1301,7 @@ immediately after paragraph 45:
          
 
 
          Rationale:
          
 
          The LWG believes Item 3 is not a defect. "Formatted
-input" implies the desired semantics. See 27.6.1.2 [istream.formatted].
+input" implies the desired semantics. See 27.7.1.2 [istream.formatted].
 
          
 
 
@@ -1165,10 +1310,10 @@ input" implies the desired semantics. See 27.6.1.2 [istream.formatted].
 
 
          
 
          13. Eos refuses to die
          
-
          Section: 27.6.1.2.3 [istream::extractors] Status: TC
- Submitter: William M. Miller Date: 1998-03-03
          
+
          Section: 27.7.1.2.3 [istream::extractors] Status: TC1
+ Submitter: William M. Miller Opened: 1998-03-03  Last modified: 2008-09-26
          
 
          View all other issues in [istream::extractors].
          
-
          View all issues with TC status.
          
+
          View all issues with TC1 status.
          
 
          Discussion:
          
 
          In 27.6.1.2.3, there is a reference to "eos", which is
 the only one in the whole draft (at least using Acrobat search), so
@@ -1176,7 +1321,7 @@ it's undefined. 
          
 
 
 
          Proposed resolution:
          
-
          In 27.6.1.2.3 [istream::extractors], replace "eos" with
+
          In 27.7.1.2.3 [istream::extractors], replace "eos" with
 "charT()"
          
 
 
@@ -1185,10 +1330,10 @@ it's undefined. 
          
 
 
          
 
          14. Locale::combine should be const
          
-
          Section: 22.1.1.3 [locale.members] Status: TC
- Submitter: Nathan Myers Date: 1998-08-06
          
+
          Section: 22.3.1.3 [locale.members] Status: TC1
+ Submitter: Nathan Myers Opened: 1998-08-06  Last modified: 2008-09-26
          
 
          View all other issues in [locale.members].
          
-
          View all issues with TC status.
          
+
          View all issues with TC1 status.
          
 
          Discussion:
          
 
          locale::combine is the only member function of locale (other than constructors and
 destructor) that is not const. There is no reason for it not to be const, and good reasons
@@ -1203,7 +1348,7 @@ time, but the omission was not noticed. 
          
 
 
 
          Proposed resolution:
          
-
          In 22.1.1 [locale] and also in 22.1.1.3 [locale.members], add 
+
          In 22.3.1 [locale] and also in 22.3.1.3 [locale.members], add 
 "const" to the declaration of member combine: 
          
 
          
   
          template <class Facet> locale combine(const locale& other) const; 
          
@@ -1215,17 +1360,17 @@ time, but the omission was not noticed. 
          
 
 
          
 
          15. Locale::name requirement inconsistent
          
-
          Section: 22.1.1.3 [locale.members] Status: TC
- Submitter: Nathan Myers Date: 1998-08-06
          
+
          Section: 22.3.1.3 [locale.members] Status: TC1
+ Submitter: Nathan Myers Opened: 1998-08-06  Last modified: 2008-09-26
          
 
          View all other issues in [locale.members].
          
-
          View all issues with TC status.
          
+
          View all issues with TC1 status.
          
 
          Discussion:
          
 
          locale::name() is described as returning a string that can be passed to a locale
 constructor, but there is no matching constructor. 
          
 
 
 
          Proposed resolution:
          
-
          In 22.1.1.3 [locale.members], paragraph 5, replace
+
          In 22.3.1.3 [locale.members], paragraph 5, replace
 "locale(name())" with
 "locale(name().c_str())".
 
          
@@ -1236,10 +1381,11 @@ constructor, but there is no matching constructor. 
          
 
 
          
 
          16. Bad ctype_byname<char> decl
          
-
          Section: 22.2.1.4 [locale.codecvt] Status: TC
- Submitter: Nathan Myers Date: 1998-08-06
          
+
          Section: 22.4.1.4 [locale.codecvt] Status: TC1
+ Submitter: Nathan Myers Opened: 1998-08-06  Last modified: 2008-09-26
          
+
          View other active issues in [locale.codecvt].
          
 
          View all other issues in [locale.codecvt].
          
-
          View all issues with TC status.
          
+
          View all issues with TC1 status.
          
 
          Discussion:
          
 
          The new virtual members ctype_byname<char>::do_widen and do_narrow did not get
 edited in properly. Instead, the member do_widen appears four times, with wrong argument
@@ -1249,7 +1395,7 @@ lists. 
          
 
          Proposed resolution:
          
 
          The correct declarations for the overloaded members
 do_narrow and do_widen should be copied 
-from 22.2.1.3 [facet.ctype.special].
          
+from 22.4.1.3 [facet.ctype.special].
          
 
 
 
@@ -1257,11 +1403,11 @@ from 22.2.1.3 [facet.ctype.special].
          
 
 
          
 
          17. Bad bool parsing
          
-
          Section: 22.2.2.1.2 [facet.num.get.virtuals] Status: TC
- Submitter: Nathan Myers Date: 1998-08-06
          
+
          Section: 22.4.2.1.2 [facet.num.get.virtuals] Status: TC1
+ Submitter: Nathan Myers Opened: 1998-08-06  Last modified: 2008-09-26
          
 
          View other active issues in [facet.num.get.virtuals].
          
 
          View all other issues in [facet.num.get.virtuals].
          
-
          View all issues with TC status.
          
+
          View all issues with TC1 status.
          
 
          Discussion:
          
 
          This section describes the process of parsing a text boolean value from the input
 stream. It does not say it recognizes either of the sequences "true" or
@@ -1306,7 +1452,7 @@ code above.
          
 
 
 
          Proposed resolution:
          
-
          In 22.2.2.1.2 [facet.num.get.virtuals], in the first line of paragraph 14,
+
          In 22.4.2.1.2 [facet.num.get.virtuals], in the first line of paragraph 14,
 change "&&" to "&".
          
 
 
          Then, replace paragraphs 15 and 16 as follows:
          
@@ -1349,10 +1495,10 @@ change "&&" to "&".
          
 
 
          
 
          18. Get(...bool&) omitted
          
-
          Section: 22.2.2.1.1 [facet.num.get.members] Status: TC
- Submitter: Nathan Myers Date: 1998-08-06
          
+
          Section: 22.4.2.1.1 [facet.num.get.members] Status: TC1
+ Submitter: Nathan Myers Opened: 1998-08-06  Last modified: 2008-09-26
          
 
          View all other issues in [facet.num.get.members].
          
-
          View all issues with TC status.
          
+
          View all issues with TC1 status.
          
 
          Discussion:
          
 
          In the list of num_get<> non-virtual members on page 22-23, the member
 that parses bool values was omitted from the list of definitions of non-virtual
@@ -1361,9 +1507,9 @@ virtual is listed everywhere appropriate. 
          
 
 
 
          Proposed resolution:
          
-
          Add at the beginning of 22.2.2.1.1 [facet.num.get.members]
+
          Add at the beginning of 22.4.2.1.1 [facet.num.get.members]
 another get member for bool&, copied from the entry in 
-22.2.2.1 [locale.num.get].
          
+22.4.2.1 [locale.num.get].
          
 
 
 
@@ -1371,10 +1517,11 @@ another get member for bool&, copied from the entry in
 
 
          
 
          19. "Noconv" definition too vague
          
-
          Section: 22.2.1.4 [locale.codecvt] Status: TC
- Submitter: Nathan Myers Date: 1998-08-06
          
+
          Section: 22.4.1.4 [locale.codecvt] Status: TC1
+ Submitter: Nathan Myers Opened: 1998-08-06  Last modified: 2008-09-26
          
+
          View other active issues in [locale.codecvt].
          
 
          View all other issues in [locale.codecvt].
          
-
          View all issues with TC status.
          
+
          View all issues with TC1 status.
          
 
          Duplicate of: 10
          
 
          Discussion:
          
 
          
@@ -1388,7 +1535,7 @@ normatively what is done with the buffers.
 
          Proposed resolution:
          
 
          
 Change the entry for noconv in the table under paragraph 4 in section 
-22.2.1.4.2 [locale.codecvt.virtuals] to read:
+22.4.1.4.2 [locale.codecvt.virtuals] to read:
 
          
 
          
   
          noconv: internT and externT are the same type,
@@ -1408,9 +1555,9 @@ Change the entry for noconv in the table under paragraph 4 in section
 
 
          
 
          20. Thousands_sep returns wrong type
          
-
          Section: 22.2.3.1.2 [facet.numpunct.virtuals] Status: TC
- Submitter: Nathan Myers Date: 1998-08-06
          
-
          View all issues with TC status.
          
+
          Section: 22.4.3.1.2 [facet.numpunct.virtuals] Status: TC1
+ Submitter: Nathan Myers Opened: 1998-08-06  Last modified: 2008-09-26
          
+
          View all issues with TC1 status.
          
 
          Discussion:
          
 
          The synopsis for numpunct<>::do_thousands_sep, and the
 definition of numpunct<>::thousands_sep which calls it, specify
@@ -1419,7 +1566,7 @@ described as returning a "string_type". 
          
 
 
 
          Proposed resolution:
          
-
          In 22.2.3.1.2 [facet.numpunct.virtuals], above paragraph 2, change 
+
          In 22.4.3.1.2 [facet.numpunct.virtuals], above paragraph 2, change 
 "string_type" to "char_type". 
          
 
 
@@ -1428,10 +1575,10 @@ described as returning a "string_type". 
          
 
 
          
 
          21. Codecvt_byname<> instantiations
          
-
          Section: 22.1.1.1.1 [locale.category] Status: TC
- Submitter: Nathan Myers Date: 1998-08-06
          
+
          Section: 22.3.1.1.1 [locale.category] Status: TC1
+ Submitter: Nathan Myers Opened: 1998-08-06  Last modified: 2008-09-26
          
 
          View all other issues in [locale.category].
          
-
          View all issues with TC status.
          
+
          View all issues with TC1 status.
          
 
          Discussion:
          
 
          In the second table in the section, captioned "Required
 instantiations", the instantiations for codecvt_byname<>
@@ -1440,7 +1587,7 @@ locale by name from facets. 
          
 
 
 
          Proposed resolution:
          
-
          Add in 22.1.1.1.1 [locale.category] to the table captioned
+
          Add in 22.3.1.1.1 [locale.category] to the table captioned
 "Required instantiations", in the category "ctype"
 the lines 
          
 
@@ -1455,10 +1602,10 @@ codecvt_byname<wchar_t,char,mbstate_t>

    22. Member open vs. flags

    -

    Section: 27.8.1.9 [ifstream.members] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    +

    Section: 27.9.1.9 [ifstream.members] Status: TC1 + Submitter: Nathan Myers Opened: 1998-08-06 Last modified: 2008-09-26

    View all other issues in [ifstream.members].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    The description of basic_istream<>::open leaves unanswered questions about how it responds to or changes flags in the error status for the stream. A strict reading @@ -1469,7 +1616,7 @@ and eofbit on call to open().

    Proposed resolution:

    -

    In 27.8.1.9 [ifstream.members] paragraph 3, and in 27.8.1.13 [ofstream.members] paragraph 3, under open() effects, add a footnote: +

    In 27.9.1.9 [ifstream.members] paragraph 3, and in 27.9.1.13 [ofstream.members] paragraph 3, under open() effects, add a footnote:

    @@ -1493,12 +1640,212 @@ believes to have been the original intent.

    +
    +

    23. Num_get overflow result

    +

    Section: 22.4.2.1.2 [facet.num.get.virtuals] Status: CD1 + Submitter: Nathan Myers Opened: 1998-08-06 Last modified: 2008-09-26

    +

    View other active issues in [facet.num.get.virtuals].

    +

    View all other issues in [facet.num.get.virtuals].

    +

    View all issues with CD1 status.

    +

    Discussion:

    +

    The current description of numeric input does not account for the +possibility of overflow. This is an implicit result of changing the +description to rely on the definition of scanf() (which fails to +report overflow), and conflicts with the documented behavior of +traditional and current implementations.

    + +

    Users expect, when reading a character sequence that results in a +value unrepresentable in the specified type, to have an error +reported. The standard as written does not permit this.

    + +

    Further comments from Dietmar:

    + +

    +I don't feel comfortable with the proposed resolution to issue 23: It +kind of simplifies the issue to much. Here is what is going on: +

    + +

    +Currently, the behavior of numeric overflow is rather counter intuitive +and hard to trace, so I will describe it briefly: +

    + +
      +
    • + According to 22.4.2.1.2 [facet.num.get.virtuals] + paragraph 11 failbit is set if scanf() would + return an input error; otherwise a value is converted to the rules + of scanf. +
      • +
    • + scanf() is defined in terms of fscanf(). +
      • +
    • + fscanf() returns an input failure if during conversion no + character matching the conversion specification could be extracted + before reaching EOF. This is the only reason for fscanf() + to fail due to an input error and clearly does not apply to the case + of overflow. +
      • +
    • + Thus, the conversion is performed according to the rules of + fscanf() which basically says that strtod, + strtol(), etc. are to be used for the conversion. +
      • +
    • + The strtod(), strtol(), etc. functions consume as + many matching characters as there are and on overflow continue to + consume matching characters but also return a value identical to + the maximum (or minimum for signed types if there was a leading minus) + value of the corresponding type and set errno to ERANGE. +
      • +
    • + Thus, according to the current wording in the standard, overflows + can be detected! All what is to be done is to check errno + after reading an element and, of course, clearing errno + before trying a conversion. With the current wording, it can be + detected whether the overflow was due to a positive or negative + number for signed types. +
      • +
    + +

    Further discussion from Redmond:

    + +

    The basic problem is that we've defined our behavior, +including our error-reporting behavior, in terms of C90. However, +C90's method of reporting overflow in scanf is not technically an +"input error". The strto_* functions are more precise.

    + +

    There was general consensus that failbit should be set +upon overflow. We considered three options based on this:

    +
      +
    1. Set failbit upon conversion error (including overflow), and + don't store any value.
      2. +
    2. Set failbit upon conversion error, and also set errno to + indicated the precise nature of the error.
      3. +
    3. Set failbit upon conversion error. If the error was due to + overflow, store +-numeric_limits<T>::max() as an + overflow indication.
      4. +
    + +

    Straw poll: (1) 5; (2) 0; (3) 8.

    + + +

    Discussed at Lillehammer. General outline of what we want the + solution to look like: we want to say that overflow is an error, and + provide a way to distinguish overflow from other kinds of errors. + Choose candidate field the same way scanf does, but don't describe + the rest of the process in terms of format. If a finite input field + is too large (positive or negative) to be represented as a finite + value, then set failbit and assign the nearest representable value. + Bill will provide wording.

    + +

    +Discussed at Toronto: +N2327 +is in alignment with the direction we wanted to go with in Lillehammer. Bill +to work on. +

    + + + +

    Proposed resolution:

    + +

    +Change 22.4.2.1.2 [facet.num.get.virtuals], end of p3: +

    + +
    +

    +Stage 3: The result of stage 2 processing can be one of +The sequence of chars accumulated in stage 2 (the field) is +converted to a numeric value by the rules of one of the functions declared +in the header <cstdlib>: +

    +
      +
    • +A sequence of chars has been accumulated in stage 2 that is +converted (according to the rules of scanf) to a value of the +type of val. This value is stored in val and ios_base::goodbit is +stored in err. +For a signed integer value, the function strtoll. +
      • +
    • +The sequence of chars accumulated in stage 2 would have caused +scanf to report an input failure. ios_base::failbit is +assigned to err. +For an unsigned integer value, the function strtoull. +
      • +
    • +For a floating-point value, the function strtold. +
      • +
    +

    +The numeric value to be stored can be one of: +

    +
      +
    • zero, if the conversion function fails to convert the entire field. +ios_base::failbit is assigned to err.
      • +
    • the most positive representable value, if the field represents a value +too large positive to be represented in val. ios_base::failbit is assigned +to err.
      • +
    • the most negative representable value (zero for unsigned integer), if +the field represents a value too large negative to be represented in val. +ios_base::failbit is assigned to err.
      • +
    • the converted value, otherwise.
      • +
    + +

    +The resultant numeric value is stored in val. +

    +
    + +

    +Change 22.4.2.1.2 [facet.num.get.virtuals], p6-p7: +

    + +
    +
    iter_type do_get(iter_type in, iter_type end, ios_base& str, 
+                 ios_base::iostate& err, bool& val) const;
+
    +
    +

    +-6- Effects: If +(str.flags()&ios_base::boolalpha)==0 then input +proceeds as it would for a long except that if a value is being +stored into val, the value is determined according to the +following: If the value to be stored is 0 then false is stored. +If the value is 1 then true is stored. Otherwise +err|=ios_base::failbit is performed and no value true is +stored. and ios_base::failbit is assigned to err. +

    +

    +-7- Otherwise target sequences are determined "as if" by calling the +members falsename() and truename() of the facet +obtained by use_facet<numpunct<charT> +>(str.getloc()). Successive characters in the range +[in,end) (see 23.1.1) are obtained and matched +against corresponding positions in the target sequences only as +necessary to identify a unique match. The input iterator in is +compared to end only when necessary to obtain a character. If and +only if a target sequence is uniquely matched, val is set to the +corresponding value. Otherwise false is stored and ios_base::failbit +is assigned to err. +

    +
    +
    + + + + +

    24. "do_convert" doesn't exist

    -

    Section: 22.2.1.4 [locale.codecvt] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    +

    Section: 22.4.1.4 [locale.codecvt] Status: TC1 + Submitter: Nathan Myers Opened: 1998-08-06 Last modified: 2008-09-26

    +

    View other active issues in [locale.codecvt].

    View all other issues in [locale.codecvt].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Duplicate of: 72

    Discussion:

    The description of codecvt<>::do_out and do_in mentions a @@ -1508,8 +1855,8 @@ and do_out".

    Proposed resolution:

    -

    In 22.2.1.4 [locale.codecvt], paragraph 3, change -"do_convert" to "do_in or do_out". Also, in 22.2.1.4.2 [locale.codecvt.virtuals], change "do_convert()" to "do_in +

    In 22.4.1.4 [locale.codecvt], paragraph 3, change +"do_convert" to "do_in or do_out". Also, in 22.4.1.4.2 [locale.codecvt.virtuals], change "do_convert()" to "do_in or do_out".

    @@ -1518,10 +1865,10 @@ or do_out".

    25. String operator<< uses width() value wrong

    -

    Section: 21.3.8.9 [string.io] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    +

    Section: 21.4.8.9 [string.io] Status: TC1 + Submitter: Nathan Myers Opened: 1998-08-06 Last modified: 2008-09-26

    View all other issues in [string.io].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Duplicate of: 67

    Discussion:

    In the description of operator<< applied to strings, the standard says that uses @@ -1530,7 +1877,7 @@ elsewhere; but this is inconsistent, as this allows no possibility of space for

    Proposed resolution:

    -

    Change 21.3.8.9 [string.io] paragraph 4 from:
    +

    Change 21.4.8.9 [string.io] paragraph 4 from:

        "... where n is the smaller of os.width() and str.size(); ..."
    @@ -1546,10 +1893,10 @@ to:

    26. Bad sentry example

    -

    Section: 27.6.1.1.3 [istream::sentry] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    +

    Section: 27.7.1.1.3 [istream::sentry] Status: TC1 + Submitter: Nathan Myers Opened: 1998-08-06 Last modified: 2008-09-26

    View all other issues in [istream::sentry].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    In paragraph 6, the code in the example:

    @@ -1576,7 +1923,7 @@ sequence without examining it.)

    Proposed resolution:

    -

    Remove the example above from 27.6.1.1.3 [istream::sentry] +

    Remove the example above from 27.7.1.1.3 [istream::sentry] paragraph 6.

    @@ -1594,10 +1941,10 @@ example, which might well still contain errors.

    27. String::erase(range) yields wrong iterator

    -

    Section: 21.3.6.5 [string::erase] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    +

    Section: 21.4.6.5 [string::erase] Status: TC1 + Submitter: Nathan Myers Opened: 1998-08-06 Last modified: 2008-09-26

    View all other issues in [string::erase].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    The string::erase(iterator first, iterator last) is specified to return an element one place beyond the next element after the last one erased. E.g. for the string @@ -1606,7 +1953,7 @@ while 'd' has not been erased.

    Proposed resolution:

    -

    In 21.3.6.5 [string::erase], paragraph 10, change:

    +

    In 21.4.6.5 [string::erase], paragraph 10, change:

    Returns: an iterator which points to the element immediately following _last_ prior to @@ -1626,10 +1973,10 @@ while 'd' has not been erased.

    28. Ctype<char>is ambiguous

    -

    Section: 22.2.1.3.2 [facet.ctype.char.members] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    +

    Section: 22.4.1.3.2 [facet.ctype.char.members] Status: TC1 + Submitter: Nathan Myers Opened: 1998-08-06 Last modified: 2008-09-26

    View all other issues in [facet.ctype.char.members].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Duplicate of: 236

    Discussion:

    The description of the vector form of ctype<char>::is can be interpreted to mean @@ -1645,7 +1992,7 @@ vec[].

    Proposed resolution:

    -

    Change 22.2.1.3.2 [facet.ctype.char.members], paragraph 4, to read

    +

    Change 22.4.1.3.2 [facet.ctype.char.members], paragraph 4, to read

    Effects: The second form, for all *p in the range [low, high), assigns into vec[p-low] @@ -1658,21 +2005,21 @@ vec[].

    29. Ios_base::init doesn't exist

    -

    Section: 27.3.1 [narrow.stream.objects] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    +

    Section: 27.4.1 [narrow.stream.objects] Status: TC1 + Submitter: Nathan Myers Opened: 1998-08-06 Last modified: 2008-09-26

    View all other issues in [narrow.stream.objects].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    -

    Sections 27.3.1 [narrow.stream.objects] and 27.3.2 [wide.stream.objects] mention +

    Sections 27.4.1 [narrow.stream.objects] and 27.4.2 [wide.stream.objects] mention a function ios_base::init, which is not defined. Probably they mean -basic_ios<>::init, defined in 27.4.4.1 [basic.ios.cons], +basic_ios<>::init, defined in 27.5.4.1 [basic.ios.cons], paragraph 3.

    Proposed resolution:

    [R12: modified to include paragraph 5.]

    -

    In 27.3.1 [narrow.stream.objects] paragraph 2 and 5, change

    +

    In 27.4.1 [narrow.stream.objects] paragraph 2 and 5, change

    ios_base::init

    @@ -1684,7 +2031,7 @@ paragraph 3.

    basic_ios<char>::init

    -

    Also, make a similar change in 27.3.2 [wide.stream.objects] except it +

    Also, make a similar change in 27.4.2 [wide.stream.objects] except it should read

    @@ -1697,17 +2044,17 @@ should read

    30. Wrong header for LC_*

    -

    Section: 22.1.1.1.1 [locale.category] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    +

    Section: 22.3.1.1.1 [locale.category] Status: TC1 + Submitter: Nathan Myers Opened: 1998-08-06 Last modified: 2008-09-26

    View all other issues in [locale.category].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    Paragraph 2 implies that the C macros LC_CTYPE etc. are defined in <cctype>, where they are in fact defined elsewhere to appear in <clocale>.

    Proposed resolution:

    -

    In 22.1.1.1.1 [locale.category], paragraph 2, change +

    In 22.3.1.1.1 [locale.category], paragraph 2, change "<cctype>" to read "<clocale>".

    @@ -1716,10 +2063,10 @@ where they are in fact defined elsewhere to appear in <clocale>.

    31. Immutable locale values

    -

    Section: 22.1.1 [locale] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    +

    Section: 22.3.1 [locale] Status: TC1 + Submitter: Nathan Myers Opened: 1998-08-06 Last modified: 2008-09-26

    View all other issues in [locale].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Duplicate of: 378

    Discussion:

    Paragraph 6, says "An instance of locale is @@ -1729,7 +2076,7 @@ are manifestly assignable.

    Proposed resolution:

    -

    In 22.1.1 [locale] replace paragraph 6

    +

    In 22.3.1 [locale] replace paragraph 6

    An instance of locale is immutable; once a facet @@ -1752,9 +2099,9 @@ are manifestly assignable.

    32. Pbackfail description inconsistent

    -

    Section: 27.5.2.4.4 [streambuf.virt.pback] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all issues with TC status.

    +

    Section: 27.6.2.4.4 [streambuf.virt.pback] Status: TC1 + Submitter: Nathan Myers Opened: 1998-08-06 Last modified: 2008-09-26

    +

    View all issues with TC1 status.

    Discussion:

    The description of the required state before calling virtual member basic_streambuf<>::pbackfail requirements is inconsistent with the conditions @@ -1771,7 +2118,7 @@ Specifically, the latter says it calls pbackfail if:

    Proposed resolution:

    -

    In 27.5.2.4.4 [streambuf.virt.pback], paragraph 1, change:

    +

    In 27.6.2.4.4 [streambuf.virt.pback], paragraph 1, change:

    "traits::eq(*gptr(),traits::to_char_type( c))"

    @@ -1795,10 +2142,11 @@ the argument value.

    33. Codecvt<> mentions from_type

    -

    Section: 22.2.1.4 [locale.codecvt] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    +

    Section: 22.4.1.4 [locale.codecvt] Status: TC1 + Submitter: Nathan Myers Opened: 1998-08-06 Last modified: 2008-09-26

    +

    View other active issues in [locale.codecvt].

    View all other issues in [locale.codecvt].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Duplicate of: 43

    Discussion:

    In the table defining the results from do_out and do_in, the specification for the @@ -1813,7 +2161,7 @@ an internT for do_out.

    Proposed resolution:

    -

    In 22.2.1.4.2 [locale.codecvt.virtuals] paragraph 4, replace the definition +

    In 22.4.1.4.2 [locale.codecvt.virtuals] paragraph 4, replace the definition in the table for the case of _error_ with

    @@ -1826,10 +2174,10 @@ in the table for the case of _error_ with

    34. True/falsename() not in ctype<>

    -

    Section: 22.2.2.2.2 [facet.num.put.virtuals] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    +

    Section: 22.4.2.2.2 [facet.num.put.virtuals] Status: TC1 + Submitter: Nathan Myers Opened: 1998-08-06 Last modified: 2008-09-26

    View all other issues in [facet.num.put.virtuals].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    In paragraph 19, Effects:, members truename() and falsename are used from facet ctype<charT>, but it has no such members. Note that this is also a problem in @@ -1837,7 +2185,7 @@ ctype<charT>, but it has no such members. Note that this is also a problem

    Proposed resolution:

    -

    In 22.2.2.2.2 [facet.num.put.virtuals], paragraph 19, in the Effects: +

    In 22.4.2.2.2 [facet.num.put.virtuals], paragraph 19, in the Effects: clause for member put(...., bool), replace the initialization of the string_type value s as follows:

    @@ -1852,17 +2200,17 @@ string_type s = val ? np.truename() : np.falsename();

    35. No manipulator unitbuf in synopsis

    -

    Section: 27.4 [iostreams.base] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all issues with TC status.

    +

    Section: 27.5 [iostreams.base] Status: TC1 + Submitter: Nathan Myers Opened: 1998-08-06 Last modified: 2008-09-26

    +

    View all issues with TC1 status.

    Discussion:

    -

    In 27.4.5.1 [fmtflags.manip], we have a definition for a manipulator +

    In 27.5.5.1 [fmtflags.manip], we have a definition for a manipulator named "unitbuf". Unlike other manipulators, it's not listed in synopsis. Similarly for "nounitbuf".

    Proposed resolution:

    -

    Add to the synopsis for <ios> in 27.4 [iostreams.base], after +

    Add to the synopsis for <ios> in 27.5 [iostreams.base], after the entry for "nouppercase", the prototypes:

    @@ -1876,10 +2224,10 @@ ios_base& nounitbuf(ios_base& str);

    36. Iword & pword storage lifetime omitted

    -

    Section: 27.4.2.5 [ios.base.storage] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    +

    Section: 27.5.2.5 [ios.base.storage] Status: TC1 + Submitter: Nathan Myers Opened: 1998-08-06 Last modified: 2008-09-26

    View all other issues in [ios.base.storage].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    In the definitions for ios_base::iword and pword, the lifetime of the storage is specified badly, so that an implementation which only keeps the last value stored appears @@ -1892,7 +2240,7 @@ member with a different index ...

    Proposed resolution:

    -

    Add in 27.4.2.5 [ios.base.storage], in both paragraph 2 and also in +

    Add in 27.5.2.5 [ios.base.storage], in both paragraph 2 and also in paragraph 4, replace the sentence:

    @@ -1917,10 +2265,10 @@ paragraph 4, replace the sentence:

    37. Leftover "global" reference

    -

    Section: 22.1.1 [locale] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    +

    Section: 22.3.1 [locale] Status: TC1 + Submitter: Nathan Myers Opened: 1998-08-06 Last modified: 2008-09-26

    View all other issues in [locale].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    In the overview of locale semantics, paragraph 4, is the sentence

    @@ -1934,7 +2282,7 @@ from an old draft.

    Proposed resolution:

    -

    In 22.1.1 [locale], paragraph 4, delete the parenthesized +

    In 22.3.1 [locale], paragraph 4, delete the parenthesized expression

    @@ -1947,9 +2295,9 @@ expression

    38. Facet definition incomplete

    -

    Section: 22.1.2 [locale.global.templates] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all issues with TC status.

    +

    Section: 22.3.2 [locale.global.templates] Status: TC1 + Submitter: Nathan Myers Opened: 1998-08-06 Last modified: 2008-09-26

    +

    View all issues with TC1 status.

    Discussion:

    It has been noticed by Esa Pulkkinen that the definition of "facet" is incomplete. In particular, a class derived from @@ -1971,7 +2319,7 @@ reads:

    Requires: Facet is a facet class whose definition - contains the public static member id as defined in 22.1.1.1.2 [locale.facet].

    + contains the public static member id as defined in 22.3.1.1.2 [locale.facet].

    [ @@ -1989,9 +2337,9 @@ contains (not inherits) the public static member

    39. istreambuf_iterator<>::operator++(int) definition garbled

    -

    Section: 24.5.3.4 [istreambuf.iterator::op++] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all issues with TC status.

    +

    Section: 24.6.3.4 [istreambuf.iterator::op++] Status: TC1 + Submitter: Nathan Myers Opened: 1998-08-06 Last modified: 2008-09-26

    +

    View all issues with TC1 status.

    Discussion:

    Following the definition of istreambuf_iterator<>::operator++(int) in paragraph 3, the standard contains three lines of garbage text left over from a previous edit.

    @@ -2004,7 +2352,7 @@ return(tmp);

    Proposed resolution:

    -

    In 24.5.3.4 [istreambuf.iterator::op++], delete the three lines of code at the +

    In 24.6.3.4 [istreambuf.iterator::op++], delete the three lines of code at the end of paragraph 3.

    @@ -2013,10 +2361,10 @@ end of paragraph 3.

    40. Meaningless normative paragraph in examples

    -

    Section: 22.2.8 [facets.examples] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    +

    Section: 22.4.8 [facets.examples] Status: TC1 + Submitter: Nathan Myers Opened: 1998-08-06 Last modified: 2008-09-26

    View all other issues in [facets.examples].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    Paragraph 3 of the locale examples is a description of part of an implementation technique that has lost its referent, and doesn't mean @@ -2024,7 +2372,7 @@ anything.

    Proposed resolution:

    -

    Delete 22.2.8 [facets.examples] paragraph 3 which begins "This +

    Delete 22.4.8 [facets.examples] paragraph 3 which begins "This initialization/identification system depends...", or (at the editor's option) replace it with a place-holder to keep the paragraph numbering the same.

    @@ -2035,20 +2383,20 @@ numbering the same.

    41. Ios_base needs clear(), exceptions()

    -

    Section: 27.4.2 [ios.base] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    +

    Section: 27.5.2 [ios.base] Status: TC1 + Submitter: Nathan Myers Opened: 1998-08-06 Last modified: 2008-09-26

    View all other issues in [ios.base].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Duplicate of: 157

    Discussion:

    -

    The description of ios_base::iword() and pword() in 27.4.2.4 [ios.members.static], say that if they fail, they "set badbit, +

    The description of ios_base::iword() and pword() in 27.5.2.4 [ios.members.static], say that if they fail, they "set badbit, which may throw an exception". However, ios_base offers no interface to set or to test badbit; those interfaces are defined in basic_ios<>.

    Proposed resolution:

    -

    Change the description in 27.4.2.5 [ios.base.storage] in +

    Change the description in 27.5.2.5 [ios.base.storage] in paragraph 2, and also in paragraph 4, as follows. Replace

    @@ -2075,11 +2423,11 @@ setstate(badbit).]

    42. String ctors specify wrong default allocator

    -

    Section: 21.3 [basic.string] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    +

    Section: 21.4 [basic.string] Status: TC1 + Submitter: Nathan Myers Opened: 1998-08-06 Last modified: 2008-09-26

    View other active issues in [basic.string].

    View all other issues in [basic.string].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    The basic_string<> copy constructor:

    @@ -2098,7 +2446,7 @@ it, so it might better be removed.

    Proposed resolution:

    -

    In 21.3 [basic.string], replace the declaration of the copy +

    In 21.4 [basic.string], replace the declaration of the copy constructor as follows:

    @@ -2107,7 +2455,7 @@ basic_string(const basic_string& str, size_type pos, size_type n = npos, const Allocator& a = Allocator());
    -

    In 21.3.1 [string.require], replace the copy constructor declaration +

    In 21.4.1 [string.require], replace the copy constructor declaration as above. Add to paragraph 5, Effects:

    @@ -2122,7 +2470,7 @@ just an unfortunate design choice.

    The LWG considered two other possible resolutions:

    -

    A. In 21.3 [basic.string], replace the declaration of the copy +

    A. In 21.4 [basic.string], replace the declaration of the copy constructor as follows:

    @@ -2132,7 +2480,7 @@ basic_string(const basic_string& str, size_type pos, size_type n, const Allocator& a);
    -

    In 21.3.1 [string.require], replace the copy constructor declaration +

    In 21.4.1 [string.require], replace the copy constructor declaration as above. Add to paragraph 5, Effects:

    @@ -2140,7 +2488,7 @@ as above. Add to paragraph 5, Effects:

    value str.get_allocator().

    -

    B. In 21.3 [basic.string], and also in 21.3.1 [string.require], replace +

    B. In 21.4 [basic.string], and also in 21.4.1 [string.require], replace the declaration of the copy constructor as follows:

    @@ -2164,10 +2512,11 @@ reflects the LWG consensus.

    44. Iostreams use operator== on int_type values

    -

    Section: 27 [input.output] Status: WP - Submitter: Nathan Myers Date: 1998-08-06

    +

    Section: 27 [input.output] Status: CD1 + Submitter: Nathan Myers Opened: 1998-08-06 Last modified: 2008-09-26

    +

    View other active issues in [input.output].

    View all other issues in [input.output].

    -

    View all issues with WP status.

    +

    View all issues with CD1 status.

    Discussion:

    Many of the specifications for iostreams specify that character values or their int_type equivalents are compared using operators == @@ -2415,9 +2764,9 @@ change uses of == and != to use the traits members instead.

    46. Minor Annex D errors

    -

    Section: D.7 [depr.str.strstreams] Status: TC - Submitter: Brendan Kehoe Date: 1998-06-01

    -

    View all issues with TC status.

    +

    Section: D.7 [depr.str.strstreams] Status: TC1 + Submitter: Brendan Kehoe Opened: 1998-06-01 Last modified: 2008-09-26

    +

    View all issues with TC1 status.

    Discussion:

    See lib-6522 and edit-814.

    Proposed resolution:

    @@ -2448,10 +2797,10 @@ int_type:

    47. Imbue() and getloc() Returns clauses swapped

    -

    Section: 27.4.2.3 [ios.base.locales] Status: TC - Submitter: Matt Austern Date: 1998-06-21

    +

    Section: 27.5.2.3 [ios.base.locales] Status: TC1 + Submitter: Matt Austern Opened: 1998-06-21 Last modified: 2008-09-26

    View all other issues in [ios.base.locales].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    Section 27.4.2.3 specifies how imbue() and getloc() work. That section has two RETURNS clauses, and they make no sense as @@ -2461,7 +2810,7 @@ accident?

    Proposed resolution:

    -

    In 27.4.2.3 [ios.base.locales] swap paragraphs 2 and 4.

    +

    In 27.5.2.3 [ios.base.locales] swap paragraphs 2 and 4.

    @@ -2469,10 +2818,10 @@ accident?

    48. Use of non-existent exception constructor

    -

    Section: 27.4.2.1.1 [ios::failure] Status: TC - Submitter: Matt Austern Date: 1998-06-21

    +

    Section: 27.5.2.1.1 [ios::failure] Status: TC1 + Submitter: Matt Austern Opened: 1998-06-21 Last modified: 2008-09-26

    View all other issues in [ios::failure].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    27.4.2.1.1, paragraph 2, says that class failure initializes the base class, exception, with exception(msg). Class exception (see @@ -2480,7 +2829,7 @@ base class, exception, with exception(msg). Class exception (see

    Proposed resolution:

    -

    Replace 27.4.2.1.1 [ios::failure], paragraph 2, with

    +

    Replace 27.5.2.1.1 [ios::failure], paragraph 2, with

    EFFECTS: Constructs an object of class failure.

    @@ -2492,9 +2841,9 @@ base class, exception, with exception(msg). Class exception (see

    49. Underspecification of ios_base::sync_with_stdio

    -

    Section: 27.4.2.4 [ios.members.static] Status: WP - Submitter: Matt Austern Date: 1998-06-21

    -

    View all issues with WP status.

    +

    Section: 27.5.2.4 [ios.members.static] Status: CD1 + Submitter: Matt Austern Opened: 1998-06-21 Last modified: 2008-09-26

    +

    View all issues with CD1 status.

    Discussion:

    Two problems

    @@ -2510,7 +2859,7 @@ guesses, but that's another matter.)

    Proposed resolution:

    -

    Change the following sentence in 27.4.2.4 [ios.members.static] +

    Change the following sentence in 27.5.2.4 [ios.members.static] returns clause from:

    @@ -2526,7 +2875,7 @@ returns clause from:

    false.

    -

    Add the following immediately after 27.4.2.4 [ios.members.static], +

    Add the following immediately after 27.5.2.4 [ios.members.static], paragraph 2:

    @@ -2579,10 +2928,10 @@ on the two streams can be mixed arbitrarily.]

    50. Copy constructor and assignment operator of ios_base

    -

    Section: 27.4.2 [ios.base] Status: TC - Submitter: Matt Austern Date: 1998-06-21

    +

    Section: 27.5.2 [ios.base] Status: TC1 + Submitter: Matt Austern Opened: 1998-06-21 Last modified: 2008-09-26

    View all other issues in [ios.base].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    As written, ios_base has a copy constructor and an assignment operator. (Nothing in the standard says it doesn't have one, and all @@ -2605,7 +2954,7 @@ semantics (e.g. what happens to the iarray and parray stuff).

    Proposed resolution:

    -

    In 27.4.2 [ios.base], class ios_base, specify the copy +

    In 27.5.2 [ios.base], class ios_base, specify the copy constructor and operator= members as being private.

    @@ -2619,11 +2968,11 @@ outweighs any benefit of allowing ios_base objects to be copyable.

    51. Requirement to not invalidate iterators missing

    -

    Section: 23.1 [container.requirements] Status: TC - Submitter: David Vandevoorde Date: 1998-06-23

    +

    Section: 23.2 [container.requirements] Status: TC1 + Submitter: David Vandevoorde Opened: 1998-06-23 Last modified: 2008-09-26

    View other active issues in [container.requirements].

    View all other issues in [container.requirements].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    The std::sort algorithm can in general only sort a given sequence by moving around values. The list<>::sort() member on the other @@ -2680,18 +3029,18 @@ of"

    52. Small I/O problems

    -

    Section: 27.4.3.2 [fpos.operations] Status: TC - Submitter: Matt Austern Date: 1998-06-23

    -

    View all issues with TC status.

    +

    Section: 27.5.3.2 [fpos.operations] Status: TC1 + Submitter: Matt Austern Opened: 1998-06-23 Last modified: 2008-09-26

    +

    View all issues with TC1 status.

    Discussion:

    -

    First, 27.4.4.1 [basic.ios.cons], table 89. This is pretty obvious: +

    First, 27.5.4.1 [basic.ios.cons], table 89. This is pretty obvious: it should be titled "basic_ios<>() effects", not "ios_base() effects".

    [The second item is a duplicate; see issue 6 for resolution.]

    -

    Second, 27.4.3.2 [fpos.operations] table 88 . There are a couple +

    Second, 27.5.3.2 [fpos.operations] table 88 . There are a couple different things wrong with it, some of which I've already discussed with Jerry, but the most obvious mechanical sort of error is that it uses expressions like P(i) and p(i), without ever defining what sort @@ -2708,7 +3057,7 @@ arithmetic is possible.)

    Proposed resolution:

    -

    Change 27.4.4.1 [basic.ios.cons] table 89 title from +

    Change 27.5.4.1 [basic.ios.cons] table 89 title from "ios_base() effects" to "basic_ios<>() effects".

    @@ -2718,10 +3067,10 @@ effects".

    53. Basic_ios destructor unspecified

    -

    Section: 27.4.4.1 [basic.ios.cons] Status: TC - Submitter: Matt Austern Date: 1998-06-23

    +

    Section: 27.5.4.1 [basic.ios.cons] Status: TC1 + Submitter: Matt Austern Opened: 1998-06-23 Last modified: 2008-09-26

    View all other issues in [basic.ios.cons].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    There's nothing in 27.4.4 saying what basic_ios's destructor does. The important question is whether basic_ios::~basic_ios() destroys @@ -2729,7 +3078,7 @@ rdbuf().

    Proposed resolution:

    -

    Add after 27.4.4.1 [basic.ios.cons] paragraph 2:

    +

    Add after 27.5.4.1 [basic.ios.cons] paragraph 2:

    virtual ~basic_ios();

    @@ -2740,7 +3089,7 @@ rdbuf().

    Rationale:

    The LWG reviewed the additional question of whether or not rdbuf(0) may set badbit. The answer is -clearly yes; it may be set via clear(). See 27.4.4.2 [basic.ios.members], paragraph 6. This issue was reviewed at length +clearly yes; it may be set via clear(). See 27.5.4.2 [basic.ios.members], paragraph 6. This issue was reviewed at length by the LWG, which removed from the original proposed resolution a footnote which incorrectly said "rdbuf(0) does not set badbit".

    @@ -2751,10 +3100,10 @@ footnote which incorrectly said "rdbuf(0) does not set

    54. Basic_streambuf's destructor

    -

    Section: 27.5.2.1 [streambuf.cons] Status: TC - Submitter: Matt Austern Date: 1998-06-25

    +

    Section: 27.6.2.1 [streambuf.cons] Status: TC1 + Submitter: Matt Austern Opened: 1998-06-25 Last modified: 2008-09-26

    View all other issues in [streambuf.cons].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    The class synopsis for basic_streambuf shows a (virtual) destructor, but the standard doesn't say what that destructor does. My @@ -2763,7 +3112,7 @@ explicitly.

    Proposed resolution:

    -

    Add after 27.5.2.1 [streambuf.cons] paragraph 2:

    +

    Add after 27.6.2.1 [streambuf.cons] paragraph 2:

    virtual  ~basic_streambuf();

    @@ -2776,10 +3125,11 @@ explicitly.

    55. Invalid stream position is undefined

    -

    Section: 27 [input.output] Status: TC - Submitter: Matt Austern Date: 1998-06-26

    +

    Section: 27 [input.output] Status: TC1 + Submitter: Matt Austern Opened: 1998-06-26 Last modified: 2008-09-26

    +

    View other active issues in [input.output].

    View all other issues in [input.output].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    Several member functions in clause 27 are defined in certain circumstances to return an "invalid stream position", a term @@ -2801,33 +3151,33 @@ should not be changed. Here are the three places where "invalid stream position" should not be changed:

    -

    27.7.1.4 [stringbuf.virtuals], paragraph 14
    - 27.8.1.5 [filebuf.virtuals], paragraph 14
    +

    27.8.1.4 [stringbuf.virtuals], paragraph 14
    + 27.9.1.5 [filebuf.virtuals], paragraph 14
    D.7.1.3 [depr.strstreambuf.virtuals], paragraph 17

    Proposed resolution:

    -

    In 27.5.2.4.2 [streambuf.virt.buffer], paragraph 4, change "Returns an +

    In 27.6.2.4.2 [streambuf.virt.buffer], paragraph 4, change "Returns an object of class pos_type that stores an invalid stream position (_lib.iostreams.definitions_)" to "Returns pos_type(off_type(-1))".

    -

    In 27.5.2.4.2 [streambuf.virt.buffer], paragraph 6, change "Returns +

    In 27.6.2.4.2 [streambuf.virt.buffer], paragraph 6, change "Returns an object of class pos_type that stores an invalid stream position" to "Returns pos_type(off_type(-1))".

    -

    In 27.7.1.4 [stringbuf.virtuals], paragraph 13, change "the object +

    In 27.8.1.4 [stringbuf.virtuals], paragraph 13, change "the object stores an invalid stream position" to "the return value is pos_type(off_type(-1))".

    -

    In 27.8.1.5 [filebuf.virtuals], paragraph 13, change "returns an +

    In 27.9.1.5 [filebuf.virtuals], paragraph 13, change "returns an invalid stream position (27.4.3)" to "returns pos_type(off_type(-1))"

    -

    In 27.8.1.5 [filebuf.virtuals], paragraph 15, change "Otherwise +

    In 27.9.1.5 [filebuf.virtuals], paragraph 15, change "Otherwise returns an invalid stream position (_lib.iostreams.definitions_)" to "Otherwise returns pos_type(off_type(-1))"

    @@ -2846,10 +3196,10 @@ stores an invalid stream position" to "the return value is

    56. Showmanyc's return type

    -

    Section: 27.5.2 [streambuf] Status: TC - Submitter: Matt Austern Date: 1998-06-29

    +

    Section: 27.6.2 [streambuf] Status: TC1 + Submitter: Matt Austern Opened: 1998-06-29 Last modified: 2008-09-26

    View all other issues in [streambuf].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    The class summary for basic_streambuf<>, in 27.5.2, says that showmanyc has return type int. However, 27.5.2.4.3 says that its @@ -2858,7 +3208,7 @@ return type is streamsize.

    Proposed resolution:

    Change showmanyc's return type in the -27.5.2 [streambuf] class summary to streamsize.

    +27.6.2 [streambuf] class summary to streamsize.

    @@ -2866,9 +3216,9 @@ return type is streamsize.

    57. Mistake in char_traits

    -

    Section: 21.1.3.4 [char.traits.specializations.wchar.t] Status: TC - Submitter: Matt Austern Date: 1998-07-01

    -

    View all issues with TC status.

    +

    Section: 21.2.3.4 [char.traits.specializations.wchar.t] Status: TC1 + Submitter: Matt Austern Opened: 1998-07-01 Last modified: 2008-09-26

    +

    View all issues with TC1 status.

    Discussion:

    21.1.3.2, paragraph 3, says "The types streampos and wstreampos may be different if the implementation supports no shift @@ -2885,7 +3235,7 @@ char_traits<wchar_t>::state_type must both be mbstate_t.

    Proposed resolution:

    -

    Remove the sentence in 21.1.3.4 [char.traits.specializations.wchar.t] paragraph 3 which +

    Remove the sentence in 21.2.3.4 [char.traits.specializations.wchar.t] paragraph 3 which begins "The types streampos and wstreampos may be different..." .

    @@ -2895,9 +3245,9 @@ different..." .

    59. Ambiguity in specification of gbump

    -

    Section: 27.5.2.3.2 [streambuf.get.area] Status: TC - Submitter: Matt Austern Date: 1998-07-28

    -

    View all issues with TC status.

    +

    Section: 27.6.2.3.2 [streambuf.get.area] Status: TC1 + Submitter: Matt Austern Opened: 1998-07-28 Last modified: 2008-09-26

    +

    View all issues with TC1 status.

    Discussion:

    27.5.2.3.1 says that basic_streambuf::gbump() "Advances the next pointer for the input sequence by n."

    @@ -2913,7 +3263,7 @@ former interpretation.)

    Proposed resolution:

    -

    Change 27.5.2.3.2 [streambuf.get.area] paragraph 4 gbump effects from:

    +

    Change 27.6.2.3.2 [streambuf.get.area] paragraph 4 gbump effects from:

    Effects: Advances the next pointer for the input sequence by n.

    @@ -2925,7 +3275,7 @@ former interpretation.)

    Effects: Adds n to the next pointer for the input sequence.

    -

    Make the same change to 27.5.2.3.3 [streambuf.put.area] paragraph 4 pbump +

    Make the same change to 27.6.2.3.3 [streambuf.put.area] paragraph 4 pbump effects.

    @@ -2934,10 +3284,10 @@ effects.

    60. What is a formatted input function?

    -

    Section: 27.6.1.2.1 [istream.formatted.reqmts] Status: TC - Submitter: Matt Austern Date: 1998-08-03

    +

    Section: 27.7.1.2.1 [istream.formatted.reqmts] Status: TC1 + Submitter: Matt Austern Opened: 1998-08-03 Last modified: 2008-09-26

    View all other issues in [istream.formatted.reqmts].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Duplicate of: 162, 163, 166

    Discussion:

    Paragraph 1 of 27.6.1.2.1 contains general requirements for all @@ -2971,18 +3321,18 @@ that the "Common requirements" listed in section 27.6.1.2.1 apply to them.

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

    It is not clear which functions are to be considered unformatted input functions. As written, it seems -that all functions in 27.6.1.3 [istream.unformatted] are unformatted input +that all functions in 27.7.1.3 [istream.unformatted] are unformatted input functions. However, it does not really make much sense to construct a sentry object for gcount(), sync(), ... Also it is unclear what happens to the gcount() if @@ -3247,10 +3597,10 @@ VI of that paper.

    61. Ambiguity in iostreams exception policy

    -

    Section: 27.6.1.3 [istream.unformatted] Status: TC - Submitter: Matt Austern Date: 1998-08-06

    +

    Section: 27.7.1.3 [istream.unformatted] Status: TC1 + Submitter: Matt Austern Opened: 1998-08-06 Last modified: 2008-09-26

    View all other issues in [istream.unformatted].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    The introduction to the section on unformatted input (27.6.1.3) says that every unformatted input function catches all exceptions that @@ -3296,10 +3646,10 @@ resolution as better standardese.

    62. Sync's return value

    -

    Section: 27.6.1.3 [istream.unformatted] Status: TC - Submitter: Matt Austern Date: 1998-08-06

    +

    Section: 27.7.1.3 [istream.unformatted] Status: TC1 + Submitter: Matt Austern Opened: 1998-08-06 Last modified: 2008-09-26

    View all other issues in [istream.unformatted].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    The Effects clause for sync() (27.6.1.3, paragraph 36) says that it "calls rdbuf()->pubsync() and, if that function returns -1 @@ -3310,7 +3660,7 @@ traits::int_type while the return type of sync() is int.

    Proposed resolution:

    -

    In 27.6.1.3 [istream.unformatted], paragraph 36, change "returns +

    In 27.7.1.3 [istream.unformatted], paragraph 36, change "returns traits::eof()" to "returns -1".

    @@ -3320,10 +3670,10 @@ traits::int_type while the return type of sync() is int.

    63. Exception-handling policy for unformatted output

    -

    Section: 27.6.2.7 [ostream.unformatted] Status: TC - Submitter: Matt Austern Date: 1998-08-11

    +

    Section: 27.7.2.7 [ostream.unformatted] Status: TC1 + Submitter: Matt Austern Opened: 1998-08-11 Last modified: 2008-09-26

    View all other issues in [ostream.unformatted].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    Clause 27 details an exception-handling policy for formatted input, unformatted input, and formatted output. It says nothing for @@ -3363,10 +3713,10 @@ input, unformatted input, and formatted output.

    64. Exception handling in basic_istream::operator>>(basic_streambuf*)

    -

    Section: 27.6.1.2.3 [istream::extractors] Status: TC - Submitter: Matt Austern Date: 1998-08-11

    +

    Section: 27.7.1.2.3 [istream::extractors] Status: TC1 + Submitter: Matt Austern Opened: 1998-08-11 Last modified: 2008-09-26

    View all other issues in [istream::extractors].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    27.6.1.2.3, paragraph 13, is ambiguous. It can be interpreted two different ways, depending on whether the second sentence is read as an @@ -3374,7 +3724,7 @@ elaboration of the first.

    Proposed resolution:

    -

    Replace 27.6.1.2.3 [istream::extractors], paragraph 13, which begins +

    Replace 27.7.1.2.3 [istream::extractors], paragraph 13, which begins "If the function inserts no characters ..." with:

    @@ -3392,10 +3742,10 @@ elaboration of the first.

    66. Strstreambuf::setbuf

    -

    Section: D.7.1.3 [depr.strstreambuf.virtuals] Status: TC - Submitter: Matt Austern Date: 1998-08-18

    +

    Section: D.7.1.3 [depr.strstreambuf.virtuals] Status: TC1 + Submitter: Matt Austern Opened: 1998-08-18 Last modified: 2008-09-26

    View all other issues in [depr.strstreambuf.virtuals].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    D.7.1.3, paragraph 19, says that strstreambuf::setbuf "Performs an operation that is defined separately for each class @@ -3421,10 +3771,10 @@ with:

    68. Extractors for char* should store null at end

    -

    Section: 27.6.1.2.3 [istream::extractors] Status: TC - Submitter: Angelika Langer Date: 1998-07-14

    +

    Section: 27.7.1.2.3 [istream::extractors] Status: TC1 + Submitter: Angelika Langer Opened: 1998-07-14 Last modified: 2008-09-26

    View all other issues in [istream::extractors].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    Extractors for char* (27.6.1.2.3) do not store a null character after the extracted character sequence whereas the unformatted @@ -3437,7 +3787,7 @@ said a null is stored.

    Proposed resolution:

    -

    27.6.1.2.3 [istream::extractors], paragraph 7, change the last list +

    27.7.1.2.3 [istream::extractors], paragraph 7, change the last list item from:

    @@ -3459,10 +3809,10 @@ item from:

    69. Must elements of a vector be contiguous?

    -

    Section: 23.2.6 [vector] Status: TC - Submitter: Andrew Koenig Date: 1998-07-29

    +

    Section: 23.3.6 [vector] Status: TC1 + Submitter: Andrew Koenig Opened: 1998-07-29 Last modified: 2008-09-26

    View all other issues in [vector].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    The issue is this: Must the elements of a vector be in contiguous memory?

    @@ -3473,7 +3823,7 @@ debugging implementations)

    Proposed resolution:

    -

    Add the following text to the end of 23.2.6 [vector], +

    Add the following text to the end of 23.3.6 [vector], paragraph 1.

    @@ -3492,10 +3842,10 @@ directly defined in the standard. Discussion included:

    • An operational definition similar to the above proposed resolution is - already used for valarray (26.5.2.3 [valarray.access]).
      • + already used for valarray (26.6.2.3 [valarray.access]).
    • There is no need to explicitly consider a user-defined operator& - because elements must be copyconstructible (23.1 [container.requirements] para 3) - and copyconstructible (20.1.1 [utility.arg.requirements]) specifies + because elements must be copyconstructible (23.2 [container.requirements] para 3) + and copyconstructible (X [utility.arg.requirements]) specifies requirements for operator&.
    • There is no issue of one-past-the-end because of language rules.
    @@ -3506,10 +3856,10 @@ directly defined in the standard. Discussion included:

    70. Uncaught_exception() missing throw() specification

    -

    Section: 18.7 [support.exception], 18.7.4 [uncaught] Status: TC - Submitter: Steve Clamage Date: 1998-08-03

    +

    Section: 18.8 [support.exception], 18.8.4 [uncaught] Status: TC1 + Submitter: Steve Clamage Opened: 1998-08-03 Last modified: 2008-09-26

    View all other issues in [support.exception].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    In article 3E04@pratique.fr, Valentin Bonnard writes:

    @@ -3523,20 +3873,20 @@ exception safety is very important.

    Proposed resolution:

    -

    In 15.5.3 [except.uncaught], paragraph 1, 18.7 [support.exception], -and 18.7.4 [uncaught], add "throw()" to uncaught_exception().

    +

    In 15.5.3 [except.uncaught], paragraph 1, 18.8 [support.exception], +and 18.8.4 [uncaught], add "throw()" to uncaught_exception().

    71. Do_get_monthname synopsis missing argument

    -

    Section: 22.2.5.1 [locale.time.get] Status: TC - Submitter: Nathan Myers Date: 1998-08-13

    -

    View all issues with TC status.

    +

    Section: 22.4.5.1 [locale.time.get] Status: TC1 + Submitter: Nathan Myers Opened: 1998-08-13 Last modified: 2008-09-26

    +

    View all issues with TC1 status.

    Discussion:

    The locale facet member time_get<>::do_get_monthname -is described in 22.2.5.1.2 [locale.time.get.virtuals] with five arguments, +is described in 22.4.5.1.2 [locale.time.get.virtuals] with five arguments, consistent with do_get_weekday and with its specified use by member get_monthname. However, in the synopsis, it is specified instead with four arguments. The missing argument is the "end" iterator @@ -3544,7 +3894,7 @@ value.

    Proposed resolution:

    -

    In 22.2.5.1 [locale.time.get], add an "end" argument to +

    In 22.4.5.1 [locale.time.get], add an "end" argument to the declaration of member do_monthname as follows:

      virtual iter_type do_get_monthname(iter_type s, iter_type end, ios_base&,
@@ -3555,10 +3905,11 @@ the declaration of member do_monthname as follows:
    
 
 
    
 
    74. Garbled text for codecvt::do_max_length
    
-
    Section: 22.2.1.4 [locale.codecvt] Status: TC
- Submitter: Matt Austern Date: 1998-09-08
    
+
    Section: 22.4.1.4 [locale.codecvt] Status: TC1
+ Submitter: Matt Austern Opened: 1998-09-08  Last modified: 2008-09-26
    
+
    View other active issues in [locale.codecvt].
    
 
    View all other issues in [locale.codecvt].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    The text of codecvt::do_max_length's "Returns"
 clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced
@@ -3566,7 +3917,7 @@ parentheses and a spurious n.
    
 
 
 
    Proposed resolution:
    
-
    Replace 22.2.1.4.2 [locale.codecvt.virtuals] paragraph 11 with the
+
    Replace 22.4.1.4.2 [locale.codecvt.virtuals] paragraph 11 with the
 following:
    
 
 
    
@@ -3582,11 +3933,12 @@ following:
    
 
 
    
 
    75. Contradiction in codecvt::length's argument types
    
-
    Section: 22.2.1.4 [locale.codecvt] Status: TC
+
    Section: 22.4.1.4 [locale.codecvt] Status: TC1
  Submitter:  Matt
-Austern Date: 1998-09-18
    
+Austern Opened: 1998-09-18  Last modified: 2008-09-26
    
+
    View other active issues in [locale.codecvt].
    
 
    View all other issues in [locale.codecvt].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    The class synopses for classes codecvt<> (22.2.1.5)
 and codecvt_byname<> (22.2.1.6) say that the first
@@ -3602,7 +3954,7 @@ then we must also add text saying how do_length changes its
 
 
 
    Proposed resolution:
    
-
    In 22.2.1.4 [locale.codecvt], and also in 22.2.1.5 [locale.codecvt.byname],
+
    In 22.4.1.4 [locale.codecvt], and also in 22.4.1.5 [locale.codecvt.byname],
 change the stateT argument type on both member
 length() and member do_length() from 
    
 
@@ -3616,7 +3968,7 @@ change the stateT argument type on both member
   
    stateT&
    
 
    
 
-
    In 22.2.1.4.2 [locale.codecvt.virtuals], add to the definition for member
+
    In 22.4.1.4.2 [locale.codecvt.virtuals], add to the definition for member
 do_length a paragraph:
    
 
 
    
@@ -3631,10 +3983,11 @@ change the stateT argument type on both member
 
 
    
 
    76. Can a codecvt facet always convert one internal character at a time?
    
-
    Section: 22.2.1.4 [locale.codecvt] Status: WP
- Submitter: Matt Austern Date: 1998-09-25
    
+
    Section: 22.4.1.4 [locale.codecvt] Status: CD1
+ Submitter: Matt Austern Opened: 1998-09-25  Last modified: 2008-09-26
    
+
    View other active issues in [locale.codecvt].
    
 
    View all other issues in [locale.codecvt].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    This issue concerns the requirements on classes derived from
 codecvt, including user-defined classes. What are the
@@ -3670,8 +4023,8 @@ sequence of M external characters that maps to a sequence of
 subsequence that maps to N-1 internal characters.) 
    
 
 
    Some of the wording in the standard, such as the description of
-codecvt::do_max_length (22.2.1.4.2 [locale.codecvt.virtuals],
-paragraph 11) and basic_filebuf::underflow (27.8.1.5 [filebuf.virtuals], paragraph 3) suggests that it must always be
+codecvt::do_max_length (22.4.1.4.2 [locale.codecvt.virtuals],
+paragraph 11) and basic_filebuf::underflow (27.9.1.5 [filebuf.virtuals], paragraph 3) suggests that it must always be
 possible to pick off internal characters one at a time from a sequence
 of external characters. However, this is never explicitly stated one
 way or the other. 
    
@@ -3686,11 +4039,11 @@ and several of codecvt's member functions. 
    
 
 
 
    Proposed resolution:
    
-
    Add the following text as a new paragraph, following 22.2.1.4.2 [locale.codecvt.virtuals] paragraph 2:
    
+
    Add the following text as a new paragraph, following 22.4.1.4.2 [locale.codecvt.virtuals] paragraph 2:
    
 
 
    
 
    A codecvt facet that is used by basic_filebuf
-(27.8 [file.streams]) must have the property that if
    
+(27.9 [file.streams]) must have the property that if
    
 
        do_out(state, from, from_end, from_next, to, to_lim, to_next)
 
    
 
    would return ok, where from != from_end, then 
    
@@ -3754,16 +4107,16 @@ return value.]
    
 
 
    
 
    78. Typo: event_call_back
    
-
    Section: 27.4.2 [ios.base] Status: TC
- Submitter: Nico Josuttis Date: 1998-09-29
    
+
    Section: 27.5.2 [ios.base] Status: TC1
+ Submitter: Nico Josuttis Opened: 1998-09-29  Last modified: 2008-09-26
    
 
    View all other issues in [ios.base].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    typo: event_call_back should be event_callback   
    
 
 
 
    Proposed resolution:
    
-
    In the 27.4.2 [ios.base] synopsis change
+
    In the 27.5.2 [ios.base] synopsis change
 "event_call_back" to "event_callback". 
    
 
 
@@ -3771,22 +4124,22 @@ return value.]
    
 
 
    
 
    79. Inconsistent declaration of polar()
    
-
    Section: 26.3.1 [complex.synopsis], 26.3.7 [complex.value.ops] Status: TC
- Submitter: Nico Josuttis Date: 1998-09-29
    
-
    View all other issues in [complex.synopsis].
    
-
    View all issues with TC status.
    
+
    Section: 26.4.1 [complex.syn], 26.4.7 [complex.value.ops] Status: TC1
+ Submitter: Nico Josuttis Opened: 1998-09-29  Last modified: 2009-03-21
    
+
    View all other issues in [complex.syn].
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
-
    In 26.3.1 [complex.synopsis] polar is declared as follows:
    
+
    In 26.4.1 [complex.syn] polar is declared as follows:
    
 
       template<class T> complex<T> polar(const T&, const T&); 
    
 
-
    In 26.3.7 [complex.value.ops] it is declared as follows:
    
+
    In 26.4.7 [complex.value.ops] it is declared as follows:
    
 
       template<class T> complex<T> polar(const T& rho, const T& theta = 0); 
    
 
 
    Thus whether the second parameter is optional is not clear. 
    
 
 
 
    Proposed resolution:
    
-
    In 26.3.1 [complex.synopsis] change:
    
+
    In 26.4.1 [complex.syn] change:
    
 
       template<class T> complex<T> polar(const T&, const T&);
    
 
 
    to:
    
@@ -3798,10 +4151,10 @@ return value.]
    
 
 
    
 
    80. Global Operators of complex declared twice
    
-
    Section: 26.3.1 [complex.synopsis], 26.3.2 [complex] Status: TC
- Submitter: Nico Josuttis Date: 1998-09-29
    
-
    View all other issues in [complex.synopsis].
    
-
    View all issues with TC status.
    
+
    Section: 26.4.1 [complex.syn], 26.4.2 [complex] Status: TC1
+ Submitter: Nico Josuttis Opened: 1998-09-29  Last modified: 2009-03-21
    
+
    View all other issues in [complex.syn].
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    Both 26.2.1 and 26.2.2 contain declarations of global operators for
 class complex. This redundancy should be removed.
    
@@ -3815,11 +4168,11 @@ class complex. This redundancy should be removed.
    
 
 
    
 
    83. String::npos vs. string::max_size()
    
-
    Section: 21.3 [basic.string] Status: TC
- Submitter: Nico Josuttis Date: 1998-09-29
    
+
    Section: 21.4 [basic.string] Status: TC1
+ Submitter: Nico Josuttis Opened: 1998-09-29  Last modified: 2008-09-26
    
 
    View other active issues in [basic.string].
    
 
    View all other issues in [basic.string].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Duplicate of: 89
    
 
    Discussion:
    
 
    Many string member functions throw if size is getting or exceeding
@@ -3831,7 +4184,7 @@ lacks some clarifications here.
    
 
 
 
    Proposed resolution:
    
-
    After 21.3 [basic.string] paragraph 4 ("The functions
+
    After 21.4 [basic.string] paragraph 4 ("The functions
 described in this clause...") add a new paragraph:
    
 
 
    
@@ -3849,10 +4202,11 @@ described in this clause...") add a new paragraph:
    
 
 
    
 
    86. String constructors don't describe exceptions
    
-
    Section: 21.3.1 [string.require] Status: TC
- Submitter: Nico Josuttis Date: 1998-09-29
    
+
    Section: 21.4.1 [string.require] Status: TC1
+ Submitter: Nico Josuttis Opened: 1998-09-29  Last modified: 2008-09-26
    
+
    View other active issues in [string.require].
    
 
    View all other issues in [string.require].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    The constructor from a range:
    
 
@@ -3866,7 +4220,7 @@ the range equals npos (or exceeds max_size(), see above). 
    
 
 
 
    Proposed resolution:
    
-
    In 21.3.1 [string.require], Strike throws paragraphs for
+
    In 21.4.1 [string.require], Strike throws paragraphs for
 constructors which say "Throws: length_error if n ==
 npos."
    
 
@@ -3881,10 +4235,10 @@ resolution for issue 90. Incorrect description of operator >> for strings
-
    Section: 21.3.8.9 [string.io] Status: TC
- Submitter: Nico Josuttis Date: 1998-09-29
    
+
    Section: 21.4.8.9 [string.io] Status: TC1
+ Submitter: Nico Josuttis Opened: 1998-09-29  Last modified: 2008-09-26
    
 
    View all other issues in [string.io].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    The effect of operator >> for strings contain the following item:
    
 
@@ -3895,7 +4249,7 @@ character c.
    
 
 
 
    Proposed resolution:
    
-
    In 21.3.8.9 [string.io] paragraph 1 Effects clause replace:
    
+
    In 21.4.8.9 [string.io] paragraph 1 Effects clause replace:
    
 
 
    
   
    isspace(c,getloc()) is true for the next available input character c.
    
@@ -3913,10 +4267,10 @@ character c.
    
 
 
    
 
    91. Description of operator>> and getline() for string<> might cause endless loop
    
-
    Section: 21.3.8.9 [string.io] Status: WP
- Submitter: Nico Josuttis Date: 1998-09-29
    
+
    Section: 21.4.8.9 [string.io] Status: CD1
+ Submitter: Nico Josuttis Opened: 1998-09-29  Last modified: 2008-09-26
    
 
    View all other issues in [string.io].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    Operator >> and getline() for strings read until eof()
 in the input stream is true. However, this might never happen, if the
@@ -3925,7 +4279,7 @@ changed into that it reads until !good() ? 
    
 
 
 
    Proposed resolution:
    
-
    In 21.3.8.9 [string.io], paragraph 1, replace:
    
+
    In 21.4.8.9 [string.io], paragraph 1, replace:
    
 
    
 Effects: Begins by constructing a sentry object k as if k were
 constructed by typename basic_istream<charT,traits>::sentry k( is). If
@@ -3937,7 +4291,7 @@ extracted and appended until any of the following occurs:
 
    
 
    with:
    
 
    
-Effects: Behaves as a formatted input function (27.6.1.2.1
+Effects: Behaves as a formatted input function (27.7.1.2.1
 [istream.formatted.reqmts]). After constructing a sentry object, if the
 sentry converts to true, calls str.erase() and then extracts
 characters from is and appends them to str as if by calling
@@ -3947,7 +4301,7 @@ str.max_size(). Characters are extracted and appended until any of the
 following occurs:
 
    
 
-
    In 21.3.8.9 [string.io], paragraph 6, replace
    
+
    In 21.4.8.9 [string.io], paragraph 6, replace
    
 
    
 Effects: Begins by constructing a sentry object k as if by typename
 basic_istream<charT,traits>::sentry k( is, true). If bool( k) is true,
@@ -3957,7 +4311,7 @@ following occurs:
 
    
 
    with:
    
 
    Effects: Behaves as an unformatted input function
-(27.6.1.3 [istream.unformatted]), except that it does not affect the
+(27.7.1.3 [istream.unformatted]), except that it does not affect the
 value returned
 by subsequent calls to basic_istream<>::gcount(). After
 constructing a sentry object, if the sentry converts to true, calls
@@ -3992,10 +4346,10 @@ functions do get characters from a streambuf.
    
 
 
    
 
    92. Incomplete Algorithm Requirements
    
-
    Section: 25 [algorithms] Status: WP
- Submitter: Nico Josuttis Date: 1998-09-29
    
+
    Section: 25 [algorithms] Status: CD1
+ Submitter: Nico Josuttis Opened: 1998-09-29  Last modified: 2008-09-26
    
 
    View all other issues in [algorithms].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    The standard does not state, how often a function object is copied,
 called, or the order of calls inside an algorithm. This may lead to
@@ -4101,12 +4455,12 @@ objects by algorithms is unspecified".  Consider placing in
 
 
    
 
    98. Input iterator requirements are badly written
    
-
    Section: 24.1.1 [input.iterators] Status: WP
- Submitter: AFNOR Date: 1998-10-07
    
+
    Section: 24.2.2 [input.iterators] Status: CD1
+ Submitter: AFNOR Opened: 1998-10-07  Last modified: 2008-09-26
    
 
    View all other issues in [input.iterators].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
-
    Table 72 in 24.1.1 [input.iterators] specifies semantics for
+
    Table 72 in 24.2.2 [input.iterators] specifies semantics for
 *r++ of:
    
 
 
       { T tmp = *r; ++r; return tmp; }
    
@@ -4125,7 +4479,7 @@ problem.
    
 
 
 
    Proposed resolution:
    
-
    In Table 72 in 24.1.1 [input.iterators], change the return type
+
    In Table 72 in 24.2.2 [input.iterators], change the return type
 for *r++ from T to "convertible to T".
    
 
 
@@ -4155,10 +4509,11 @@ for *r++ from T to "convertible to T".
    
 
 
    
 
    103. set::iterator is required to be modifiable, but this allows modification of keys
    
-
    Section: 23.1.4 [associative.reqmts] Status: WP
- Submitter: AFNOR Date: 1998-10-07
    
+
    Section: 23.2.4 [associative.reqmts] Status: CD1
+ Submitter: AFNOR Opened: 1998-10-07  Last modified: 2008-09-26
    
+
    View other active issues in [associative.reqmts].
    
 
    View all other issues in [associative.reqmts].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    Set::iterator is described as implementation-defined with a
 reference to the container requirement; the container requirement says
@@ -4174,7 +4529,7 @@ const_iterator. Set, for example, has the following: 
    
 
    typedef implementation defined iterator;
    
        // See _lib.container.requirements_
    
 
-
    23.1 [container.requirements] actually requires that iterator type pointing
+
    23.2 [container.requirements] actually requires that iterator type pointing
 to T (table 65). Disallowing user modification of keys by changing the
 standard to require an iterator for associative container to be the
 same as const_iterator would be overkill since that will unnecessarily
@@ -4187,7 +4542,7 @@ goes in line with trusting user knows what he is doing. 
    
 
 
    Other Options Evaluated: 
    
 
-
    Option A.   In 23.1.4 [associative.reqmts], paragraph 2, after
+
    Option A.   In 23.2.4 [associative.reqmts], paragraph 2, after
 first sentence, and before "In addition,...", add one line:
 
    
 
@@ -4195,7 +4550,7 @@ first sentence, and before "In addition,...", add one line:
   
    Modification of keys shall not change their strict weak ordering. 
    
 
    
 
-
    Option B. Add three new sentences to 23.1.4 [associative.reqmts]:
    
+
    Option B. Add three new sentences to 23.2.4 [associative.reqmts]:
    
 
 
    
   
    At the end of paragraph 5: "Keys in an associative container
@@ -4207,7 +4562,7 @@ first sentence, and before "In addition,...", add one line:
   type."
    
 
    
 
-
    Option C. To 23.1.4 [associative.reqmts], paragraph 3, which
+
    Option C. To 23.2.4 [associative.reqmts], paragraph 3, which
 currently reads:
    
 
 
    
@@ -4233,7 +4588,7 @@ currently reads:
    
 
 
 
    Proposed resolution:
    
-
    Add the following to 23.1.4 [associative.reqmts] at
+
    Add the following to 23.2.4 [associative.reqmts] at
 the indicated location:
    
 
 
    
@@ -4280,10 +4635,10 @@ conversion from iterator to const_iterator.
 
 
    
 
    106. Numeric library private members are implementation defined
    
-
    Section: 26.5.5 [template.slice.array] Status: TC
- Submitter: AFNOR Date: 1998-10-07
    
+
    Section: 26.6.5 [template.slice.array] Status: TC1
+ Submitter: AFNOR Opened: 1998-10-07  Last modified: 2008-09-26
    
 
    View all other issues in [template.slice.array].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    This is the only place in the whole standard where the implementation has to document
 something private.
    
@@ -4295,10 +4650,10 @@ Remove the comment which says "// remainder implementation defined" from:
 
    
 
 
      
-  
    • 26.5.5 [template.slice.array]
      • 
-  
    • 26.5.7 [template.gslice.array]
      • 
-  
    • 26.5.8 [template.mask.array]
      • 
-  
    • 26.5.9 [template.indirect.array]
      • 
+  
    • 26.6.5 [template.slice.array]
      • 
+  
    • 26.6.7 [template.gslice.array]
      • 
+  
    • 26.6.8 [template.mask.array]
      • 
+  
    • 26.6.9 [template.indirect.array]
      • 
 
    
 
 
@@ -4307,10 +4662,10 @@ Remove the comment which says "// remainder implementation defined" from:
 
 
    
 
    108. Lifetime of exception::what() return unspecified
    
-
    Section: 18.6.1 [type.info] Status: TC
- Submitter: AFNOR Date: 1998-10-07
    
+
    Section: 18.7.1 [type.info] Status: TC1
+ Submitter: AFNOR Opened: 1998-10-07  Last modified: 2008-09-26
    
 
    View all other issues in [type.info].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    In 18.6.1, paragraphs 8-9, the lifetime of the return value of
 exception::what() is left unspecified. This issue has implications
@@ -4319,7 +4674,7 @@ not throw bad_alloc.
    
 
 
 
    Proposed resolution:
    
-
    Add to 18.6.1 [type.info] paragraph 9 (exception::what notes
+
    Add to 18.7.1 [type.info] paragraph 9 (exception::what notes
 clause) the sentence:
    
 
 
    
@@ -4340,10 +4695,10 @@ returned by what().
 
 
    
 
    109. Missing binders for non-const sequence elements
    
-
    Section: D.8 [depr.lib.binders] Status: WP
- Submitter: Bjarne Stroustrup Date: 1998-10-07
    
+
    Section: D.8 [depr.lib.binders] Status: CD1
+ Submitter: Bjarne Stroustrup Opened: 1998-10-07  Last modified: 2008-09-26
    
 
    View all other issues in [depr.lib.binders].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
 
    There are no versions of binders that apply to non-const elements
@@ -4460,18 +4815,18 @@ Leave open - 1.]
    
 
 
    
 
    110. istreambuf_iterator::equal not const
    
-
    Section: 24.5.3 [istreambuf.iterator], 24.5.3.5 [istreambuf.iterator::equal] Status: TC
- Submitter: Nathan Myers Date: 1998-10-15
    
+
    Section: 24.6.3 [istreambuf.iterator], 24.6.3.5 [istreambuf.iterator::equal] Status: TC1
+ Submitter: Nathan Myers Opened: 1998-10-15  Last modified: 2008-09-26
    
 
    View all other issues in [istreambuf.iterator].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    Member istreambuf_iterator<>::equal is not declared
-"const", yet 24.5.3.6 [istreambuf.iterator::op==] says that operator==,
+"const", yet 24.6.3.6 [istreambuf.iterator::op==] says that operator==,
 which is const, calls it. This is contradictory. 
    
 
 
 
    Proposed resolution:
    
-
    In 24.5.3 [istreambuf.iterator] and also in 24.5.3.5 [istreambuf.iterator::equal],
+
    In 24.6.3 [istreambuf.iterator] and also in 24.6.3.5 [istreambuf.iterator::equal],
 replace:
    
 
 
    
@@ -4490,9 +4845,9 @@ replace:
    
 
 
    
 
    112. Minor typo in ostreambuf_iterator constructor
    
-
    Section: 24.5.4.1 [ostreambuf.iter.cons] Status: TC
- Submitter: Matt Austern Date: 1998-10-20
    
-
    View all issues with TC status.
    
+
    Section: 24.6.4.1 [ostreambuf.iter.cons] Status: TC1
+ Submitter: Matt Austern Opened: 1998-10-20  Last modified: 2008-09-26
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    The requires clause for ostreambuf_iterator's
 constructor from an ostream_type (24.5.4.1, paragraph 1)
@@ -4501,7 +4856,7 @@ reference, and references can't be null. 
    
 
 
 
    Proposed resolution:
    
-
    In 24.5.4.1 [ostreambuf.iter.cons]:
    
+
    In 24.6.4.1 [ostreambuf.iter.cons]:
    
 
 
    Move the current paragraph 1, which reads "Requires: s is not
 null.", from the first constructor to the second constructor.
    
@@ -4519,10 +4874,10 @@ reading:
    
 
 
    
 
    114. Placement forms example in error twice
    
-
    Section: 18.5.1.3 [new.delete.placement] Status: TC
- Submitter: Steve Clamage Date: 1998-10-28
    
+
    Section: 18.6.1.3 [new.delete.placement] Status: TC1
+ Submitter: Steve Clamage Opened: 1998-10-28  Last modified: 2008-09-26
    
 
    View all other issues in [new.delete.placement].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Duplicate of: 196
    
 
    Discussion:
    
 
    Section 18.5.1.3 contains the following example: 
    
@@ -4544,7 +4899,7 @@ likely to fail.
    
 
 
    Proposed resolution:
    
 
    Replace the first line of code in the example in 
-18.5.1.3 [new.delete.placement] with:
+18.6.1.3 [new.delete.placement] with:
 
    
 
 
    
@@ -4557,9 +4912,9 @@ likely to fail.
    
 
 
    
 
    115. Typo in strstream constructors
    
-
    Section: D.7.4.1 [depr.strstream.cons] Status: TC
- Submitter: Steve Clamage Date: 1998-11-02
    
-
    View all issues with TC status.
    
+
    Section: D.7.4.1 [depr.strstream.cons] Status: TC1
+ Submitter: Steve Clamage Opened: 1998-11-02  Last modified: 2008-09-26
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    D.7.4.1 strstream constructors paragraph 2 says: 
    
 
@@ -4589,10 +4944,10 @@ and the second condition to (mode&app)!=0.
    
 
 
    
 
    117. basic_ostream uses nonexistent num_put member functions
    
-
    Section: 27.6.2.6.2 [ostream.inserters.arithmetic] Status: WP
- Submitter: Matt Austern Date: 1998-11-20
    
+
    Section: 27.7.2.6.2 [ostream.inserters.arithmetic] Status: CD1
+ Submitter: Matt Austern Opened: 1998-11-20  Last modified: 2008-09-26
    
 
    View all other issues in [ostream.inserters.arithmetic].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    The effects clause for numeric inserters says that
 insertion of a value x, whose type is either bool,
@@ -4710,10 +5065,10 @@ example, printing short(-1) in hex format should yield 0xffff.)
    
 
 
    
 
    118. basic_istream uses nonexistent num_get member functions
    
-
    Section: 27.6.1.2.2 [istream.formatted.arithmetic] Status: WP
- Submitter: Matt Austern Date: 1998-11-20
    
+
    Section: 27.7.1.2.2 [istream.formatted.arithmetic] Status: CD1
+ Submitter: Matt Austern Opened: 1998-11-20  Last modified: 2008-09-26
    
 
    View all other issues in [istream.formatted.arithmetic].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    Formatted input is defined for the types short, unsigned short, int,
 unsigned int, long, unsigned long, float, double,
@@ -4725,7 +5080,7 @@ iostate err = 0;
 use_facet< numget >(loc).get(*this, 0, *this, err, val); 
 setstate(err);
    -

    According to section 22.2.2.1.1 [facet.num.get.members], however, +

    According to section 22.4.2.1.1 [facet.num.get.members], however, num_get<>::get() is only overloaded for the types bool, long, unsigned short, unsigned int, unsigned long, unsigned long, @@ -4736,7 +5091,7 @@ that 27.6.1.2.2 is using a nonexistent function for types

    Proposed resolution:

    -

    In 27.6.1.2.2 [istream.formatted.arithmetic] Arithmetic Extractors, remove the +

    In 27.7.1.2.2 [istream.formatted.arithmetic] Arithmetic Extractors, remove the two lines (1st and 3rd) which read:

    operator>>(short& val);
@@ -4780,12 +5135,12 @@ operator>>(int& val);

    119. Should virtual functions be allowed to strengthen the exception specification?

    -

    Section: 17.4.4.9 [res.on.exception.handling] Status: TC - Submitter: Judy Ward Date: 1998-12-15

    +

    Section: 17.6.4.10 [res.on.exception.handling] Status: TC1 + Submitter: Judy Ward Opened: 1998-12-15 Last modified: 2008-09-26

    View all other issues in [res.on.exception.handling].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    -

    Section 17.4.4.9 [res.on.exception.handling] states:

    +

    Section 17.6.4.10 [res.on.exception.handling] states:

    "An implementation may strengthen the exception-specification for a function by removing listed exceptions."

    @@ -4809,7 +5164,7 @@ public:

    Proposed resolution:

    -

    Change Section 17.4.4.9 [res.on.exception.handling] from:

    +

    Change Section 17.6.4.10 [res.on.exception.handling] from:

         "may strengthen the exception-specification for a function"

    @@ -4825,10 +5180,10 @@ exception-specification for a non-virtual function".

    120. Can an implementor add specializations?

    -

    Section: 17.4.3.2 [reserved.names] Status: WP - Submitter: Judy Ward Date: 1998-12-15

    +

    Section: 17.6.3.3 [reserved.names] Status: CD1 + Submitter: Judy Ward Opened: 1998-12-15 Last modified: 2008-09-26

    View all other issues in [reserved.names].

    -

    View all issues with WP status.

    +

    View all issues with CD1 status.

    Discussion:

    The original issue asked whether a library implementor could @@ -4876,7 +5231,7 @@ different explicit instantiations might be harmless.

    Proposed resolution:

    -

    Append to 17.4.3.2 [reserved.names] paragraph 1:

    +

    Append to 17.6.3.3 [reserved.names] paragraph 1:

    A program may explicitly instantiate any templates in the standard library only if the declaration depends on the name of a user-defined @@ -4895,7 +5250,7 @@ different explicit instantiations might be harmless.

    In light of the resolution to core issue 259, no normative changes in the library clauses are necessary. Add the following non-normative - note to the end of 17.4.3.2 [reserved.names] paragraph 1:

    + note to the end of 17.6.3.3 [reserved.names] paragraph 1:

    [Note: A program may explicitly instantiate standard library templates, even when an explicit instantiation does not depend on @@ -4940,10 +5295,10 @@ different explicit instantiations might be harmless.

    122. streambuf/wstreambuf description should not say they are specializations

    -

    Section: 27.5.2 [streambuf] Status: TC - Submitter: Judy Ward Date: 1998-12-15

    +

    Section: 27.6.2 [streambuf] Status: TC1 + Submitter: Judy Ward Opened: 1998-12-15 Last modified: 2008-09-26

    View all other issues in [streambuf].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    Section 27.5.2 describes the streambuf classes this way:

    @@ -4963,7 +5318,7 @@ specialized for the type wchar_t.

    Proposed resolution:

    -

    Remove 27.5.2 [streambuf] paragraphs 2 and 3 (the above two +

    Remove 27.6.2 [streambuf] paragraphs 2 and 3 (the above two sentences).

    @@ -4977,17 +5332,17 @@ typedefs and that is sufficient.

    123. Should valarray helper arrays fill functions be const?

    -

    Section: 26.5.5.3 [slice.arr.fill], 26.5.7.3 [gslice.array.fill], 26.5.8.3 [mask.array.fill], 26.5.9.3 [indirect.array.fill] Status: WP - Submitter: Judy Ward Date: 1998-12-15

    -

    View all issues with WP status.

    +

    Section: 26.6.5.3 [slice.arr.fill], 26.6.7.3 [gslice.array.fill], 26.6.8.3 [mask.array.fill], 26.6.9.3 [indirect.array.fill] Status: CD1 + Submitter: Judy Ward Opened: 1998-12-15 Last modified: 2008-09-26

    +

    View all issues with CD1 status.

    Discussion:

    One of the operator= in the valarray helper arrays is const and one is not. For example, look at slice_array. This operator= in Section -26.5.5.1 [slice.arr.assign] is const:

    +26.6.5.1 [slice.arr.assign] is const:

        void operator=(const valarray<T>&) const;

    -

    but this one in Section 26.5.5.3 [slice.arr.fill] is not:

    +

    but this one in Section 26.6.5.3 [slice.arr.fill] is not:

        void operator=(const T&);

    @@ -4996,7 +5351,7 @@ is not. For example, look at slice_array. This operator= in Section

    Proposed resolution:

    -

    26.5.5 [template.slice.array] Template class slice_array

    +

    26.6.5 [template.slice.array] Template class slice_array

    In the class template definition for slice_array, replace the member @@ -5008,7 +5363,7 @@ is not. For example, look at slice_array. This operator= in Section

    -

    26.5.5.3 [slice.arr.fill] slice_array fill function

    +

    26.6.5.3 [slice.arr.fill] slice_array fill function

    Change the function declaration

    @@ -5019,7 +5374,7 @@ is not. For example, look at slice_array. This operator= in Section
    -

    26.5.7 [template.gslice.array] Template class gslice_array

    +

    26.6.7 [template.gslice.array] Template class gslice_array

    In the class template definition for gslice_array, replace the member @@ -5031,7 +5386,7 @@ is not. For example, look at slice_array. This operator= in Section

    -

    26.5.7.3 [gslice.array.fill] gslice_array fill function

    +

    26.6.7.3 [gslice.array.fill] gslice_array fill function

    Change the function declaration

    @@ -5042,7 +5397,7 @@ is not. For example, look at slice_array. This operator= in Section
    -

    26.5.8 [template.mask.array] Template class mask_array

    +

    26.6.8 [template.mask.array] Template class mask_array

    In the class template definition for mask_array, replace the member @@ -5054,7 +5409,7 @@ is not. For example, look at slice_array. This operator= in Section

    -

    26.5.8.3 [mask.array.fill] mask_array fill function

    +

    26.6.8.3 [mask.array.fill] mask_array fill function

    Change the function declaration

    @@ -5065,7 +5420,7 @@ is not. For example, look at slice_array. This operator= in Section
    -

    26.5.9 [template.indirect.array] Template class indirect_array

    +

    26.6.9 [template.indirect.array] Template class indirect_array

    In the class template definition for indirect_array, replace the member @@ -5077,7 +5432,7 @@ is not. For example, look at slice_array. This operator= in Section

    -

    26.5.9.3 [indirect.array.fill] indirect_array fill function

    +

    26.6.9.3 [indirect.array.fill] indirect_array fill function

    Change the function declaration

    @@ -5106,18 +5461,18 @@ many existing implementations, both versions are already const.

    124. ctype_byname<charT>::do_scan_is & do_scan_not return type should be const charT*

    -

    Section: 22.2.1.2 [locale.ctype.byname] Status: TC - Submitter: Judy Ward Date: 1998-12-15

    +

    Section: 22.4.1.2 [locale.ctype.byname] Status: TC1 + Submitter: Judy Ward Opened: 1998-12-15 Last modified: 2008-09-26

    View all other issues in [locale.ctype.byname].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    -

    In Section 22.2.1.2 [locale.ctype.byname] +

    In Section 22.4.1.2 [locale.ctype.byname] ctype_byname<charT>::do_scan_is() and do_scan_not() are declared to return a const char* not a const charT*.

    Proposed resolution:

    -

    Change Section 22.2.1.2 [locale.ctype.byname] do_scan_is() and +

    Change Section 22.4.1.2 [locale.ctype.byname] do_scan_is() and do_scan_not() to return a const charT*.

    @@ -5127,20 +5482,20 @@ charT*.

    125. valarray<T>::operator!() return type is inconsistent

    -

    Section: 26.5.2 [template.valarray] Status: TC - Submitter: Judy Ward Date: 1998-12-15

    +

    Section: 26.6.2 [template.valarray] Status: TC1 + Submitter: Judy Ward Opened: 1998-12-15 Last modified: 2008-09-26

    View all other issues in [template.valarray].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    -

    In Section 26.5.2 [template.valarray] valarray<T>::operator!() +

    In Section 26.6.2 [template.valarray] valarray<T>::operator!() is -declared to return a valarray<T>, but in Section 26.5.2.5 +declared to return a valarray<T>, but in Section 26.6.2.5 [valarray.unary] it is declared to return a valarray<bool>. The latter appears to be correct.

    Proposed resolution:

    -

    Change in Section 26.5.2 [template.valarray] the declaration of +

    Change in Section 26.6.2 [template.valarray] the declaration of operator!() so that the return type is valarray<bool>.

    @@ -5149,14 +5504,14 @@ latter appears to be correct.

    126. typos in Effects clause of ctype::do_narrow()

    -

    Section: 22.2.1.1.2 [locale.ctype.virtuals] Status: TC - Submitter: Judy Ward Date: 1998-12-15

    +

    Section: 22.4.1.1.2 [locale.ctype.virtuals] Status: TC1 + Submitter: Judy Ward Opened: 1998-12-15 Last modified: 2008-09-26

    View all other issues in [locale.ctype.virtuals].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    Typos in 22.2.1.1.2 need to be fixed.

    Proposed resolution:

    -

    In Section 22.2.1.1.2 [locale.ctype.virtuals] change:

    +

    In Section 22.4.1.1.2 [locale.ctype.virtuals] change: 

       do_widen(do_narrow(c),0) == c
    @@ -5178,10 +5533,11 @@ latter appears to be correct.

    127. auto_ptr<> conversion issues

    -

    Section: D.9.1 [auto.ptr] Status: TC - Submitter: Greg Colvin Date: 1999-02-17

    +

    Section: D.9.1 [auto.ptr] Status: TC1 + Submitter: Greg Colvin Opened: 1999-02-17 Last modified: 2008-09-26

    +

    View other active issues in [auto.ptr].

    View all other issues in [auto.ptr].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    There are two problems with the current auto_ptr wording in the standard:

    @@ -5219,7 +5575,7 @@ object parameter may be bound to an rvalue [13.3.3.1.4/3]

    Tokyo: The LWG removed the following from the proposed resolution:

    -

    In 20.5.4 [meta.unary], paragraph 2, and 20.5.4.3 [meta.unary.prop], +

    In 20.6.4 [meta.unary], paragraph 2, and 20.6.4.3 [meta.unary.prop], paragraph 2, make the conversion to auto_ptr_ref const:

    template<class Y> operator auto_ptr_ref<Y>() const throw();
    @@ -5227,17 +5583,17 @@ object parameter may be bound to an rvalue [13.3.3.1.4/3]

    Proposed resolution:

    -

    In 20.5.4 [meta.unary], paragraph 2, move +

    In 20.6.4 [meta.unary], paragraph 2, move the auto_ptr_ref definition to namespace scope.

    -

    In 20.5.4 [meta.unary], paragraph 2, add +

    In 20.6.4 [meta.unary], paragraph 2, add a public assignment operator to the auto_ptr definition: 

    auto_ptr& operator=(auto_ptr_ref<X> r) throw();
    -

    Also add the assignment operator to 20.5.4.3 [meta.unary.prop]:

    +

    Also add the assignment operator to 20.6.4.3 [meta.unary.prop]: 

    auto_ptr& operator=(auto_ptr_ref<X> r) throw()
    @@ -5254,10 +5610,10 @@ a public assignment operator to the auto_ptr definition:

    129. Need error indication from seekp() and seekg()

    -

    Section: 27.6.1.3 [istream.unformatted], 27.6.2.5 [ostream.seeks] Status: TC - Submitter: Angelika Langer Date: 1999-02-22

    +

    Section: 27.7.1.3 [istream.unformatted], 27.7.2.5 [ostream.seeks] Status: TC1 + Submitter: Angelika Langer Opened: 1999-02-22 Last modified: 2008-09-26

    View all other issues in [istream.unformatted].

    -

    View all issues with TC status.

    +

    View all issues with TC1 status.

    Discussion:

    Currently, the standard does not specify how seekg() and seekp() indicate failure. They are not required to set failbit, and they can't @@ -5273,8 +5629,8 @@ stream state in case of failure.

    Proposed resolution:

    Add to the Effects: clause of  seekg() in -27.6.1.3 [istream.unformatted] and to the Effects: clause of seekp() in -27.6.2.5 [ostream.seeks]:

    +27.7.1.3 [istream.unformatted] and to the Effects: clause of seekp() in +27.7.2.5 [ostream.seeks]:

    In case of failure, the function calls setstate(failbit) (which may throw ios_base::failure). @@ -5290,10 +5646,11 @@ stream state in case of failure.

    130. Return type of container::erase(iterator) differs for associative containers

    -

    Section: 23.1.4 [associative.reqmts], 23.1.3 [sequence.reqmts] Status: DR - Submitter: Andrew Koenig Date: 1999-03-02

    +

    Section: 23.2.4 [associative.reqmts], 23.2.3 [sequence.reqmts] Status: CD1 + Submitter: Andrew Koenig Opened: 1999-03-02 Last modified: 2009-05-01

    +

    View other active issues in [associative.reqmts].

    View all other issues in [associative.reqmts].

    -

    View all issues with DR status.

    +

    View all issues with CD1 status.

    Duplicate of: 451

    Discussion:

    Table 67 (23.1.1) says that container::erase(iterator) returns an @@ -5307,7 +5664,7 @@ fail to meet the requirements for containers.

    Proposed resolution:

    -In 23.1.4 [associative.reqmts], in Table 69 Associative container +In 23.2.4 [associative.reqmts], in Table 69 Associative container requirements, change the return type of a.erase(q) from void to iterator. Change the assertion/not/pre/post-condition from "erases the element pointed to @@ -5318,7 +5675,7 @@ is returned."

    -In 23.1.4 [associative.reqmts], in Table 69 Associative container +In 23.2.4 [associative.reqmts], in Table 69 Associative container requirements, change the return type of a.erase(q1, q2) from void to iterator. Change the assertion/not/pre/post-condition from "erases the elements in the @@ -5327,10 +5684,10 @@ q2). Returns q2."

    -In 23.3.1 [map], in the map class synopsis; and -in 23.3.2 [multimap], in the multimap class synopsis; and -in 23.3.3 [set], in the set class synopsis; and -in 23.3.4 [multiset], in the multiset class synopsis: +In 23.4.1 [map], in the map class synopsis; and +in 23.4.2 [multimap], in the multimap class synopsis; and +in 23.4.3 [set], in the set class synopsis; and +in 23.4.4 [multiset], in the multiset class synopsis: change the signature of the first erase overload to 

       iterator erase(iterator position);
@@ -5370,9 +5727,9 @@ Redmond:  formally voted into WP.
 
 
    
 
    132. list::resize description uses random access iterators
    
-
    Section: 23.2.4.2 [list.capacity] Status: TC
- Submitter: Howard Hinnant Date: 1999-03-06
    
-
    View all issues with TC status.
    
+
    Section: 23.3.4.2 [list.capacity] Status: TC1
+ Submitter: Howard Hinnant Opened: 1999-03-06  Last modified: 2008-09-26
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    The description reads:
    
 
@@ -5389,7 +5746,7 @@ Redmond:  formally voted into WP.
 
 
 
    Proposed resolution:
    
-
    Change 23.2.4.2 [list.capacity] paragraph 1 to:
    
+
    Change 23.3.4.2 [list.capacity] paragraph 1 to:
    
 
 
    Effects:
    
 
@@ -5413,14 +5770,14 @@ no issue of exception safety with the proposed resolution.]
    
 
 
    
 
    133. map missing get_allocator()
    
-
    Section: 23.3.1 [map] Status: TC
- Submitter: Howard Hinnant Date: 1999-03-06
    
+
    Section: 23.4.1 [map] Status: TC1
+ Submitter: Howard Hinnant Opened: 1999-03-06  Last modified: 2008-09-26
    
 
    View all other issues in [map].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    The title says it all.
    
 
 
    Proposed resolution:
    
-
    Insert in 23.3.1 [map], paragraph 2,
+
    Insert in 23.4.1 [map], paragraph 2,
 after operator= in the map declaration:
    
 
 
        allocator_type get_allocator() const;
    
@@ -5430,9 +5787,9 @@ after operator= in the map declaration:
    
 
 
    
 
    134. vector constructors over specified
    
-
    Section: 23.2.6.1 [vector.cons] Status: TC
- Submitter: Howard Hinnant Date: 1999-03-06
    
-
    View all issues with TC status.
    
+
    Section: 23.3.6.1 [vector.cons] Status: TC1
+ Submitter: Howard Hinnant Opened: 1999-03-06  Last modified: 2008-09-26
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    The complexity description says: "It does at most 2N calls to the copy constructor
 of T and logN reallocations if they are just input iterators ...".
    
@@ -5442,7 +5799,7 @@ tradeoff for the implementor.
    
 
 
 
    Proposed resolution:
    
-
    Change 23.2.6.1 [vector.cons], paragraph 1 to:
    
+
    Change 23.3.6.1 [vector.cons], paragraph 1 to:
    
 
 
    -1- Complexity: The constructor template <class
 InputIterator> vector(InputIterator first, InputIterator last)
@@ -5464,10 +5821,10 @@ is greater than or equal to 2.
 
 
    
 
    136. seekp, seekg setting wrong streams?
    
-
    Section: 27.6.1.3 [istream.unformatted] Status: WP
- Submitter: Howard Hinnant Date: 1999-03-06
    
+
    Section: 27.7.1.3 [istream.unformatted] Status: CD1
+ Submitter: Howard Hinnant Opened: 1999-03-06  Last modified: 2008-09-26
    
 
    View all other issues in [istream.unformatted].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    I may be misunderstanding the intent, but should not seekg set only
 the input stream and seekp set only the output stream? The description
@@ -5540,12 +5897,12 @@ basic_filebuf<>::seekpos.]
    
 
 
    
 
    137. Do use_facet and has_facet look in the global locale?
    
-
    Section: 22.1.1 [locale] Status: TC
- Submitter: Angelika Langer Date: 1999-03-17
    
+
    Section: 22.3.1 [locale] Status: TC1
+ Submitter: Angelika Langer Opened: 1999-03-17  Last modified: 2008-09-26
    
 
    View all other issues in [locale].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
-
    Section 22.1.1 [locale] says:
    
+
    Section 22.3.1 [locale] says:
    
 
 
    -4- In the call to use_facet<Facet>(loc), the type argument
 chooses a facet, making available all members of the named type. If
@@ -5555,7 +5912,7 @@ check if a locale implements a particular facet with the template
 function has_facet<Facet>(). 
    
 
 
    This contradicts the specification given in section 
-22.1.2 [locale.global.templates]:
+22.3.2 [locale.global.templates]:
 

    
 template <class  Facet> const  Facet& use_facet(const
 locale&  loc); 
    
@@ -5581,10 +5938,11 @@ in the standard.
    
 
 
    
 
    139. Optional sequence operation table description unclear
    
-
    Section: 23.1.3 [sequence.reqmts] Status: TC
- Submitter: Andrew Koenig Date: 1999-03-30
    
+
    Section: 23.2.3 [sequence.reqmts] Status: TC1
+ Submitter: Andrew Koenig Opened: 1999-03-30  Last modified: 2008-09-26
    
+
    View other active issues in [sequence.reqmts].
    
 
    View all other issues in [sequence.reqmts].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    The sentence introducing the Optional sequence operation table
 (23.1.1 paragraph 12) has two problems:
    
@@ -5615,10 +5973,10 @@ with:
    
 
 
    
 
    141. basic_string::find_last_of, find_last_not_of say pos instead of xpos
    
-
    Section: 21.3.6.4 [string::insert], 21.3.6.6 [string::replace] Status: TC
- Submitter: Arch Robison Date: 1999-04-28
    
+
    Section: 21.4.6.4 [string::insert], 21.4.6.6 [string::replace] Status: TC1
+ Submitter: Arch Robison Opened: 1999-04-28  Last modified: 2008-09-26
    
 
    View all other issues in [string::insert].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they
 say:
    
@@ -5646,9 +6004,9 @@ proposed resolution.]
    
 
 
    
 
    142. lexicographical_compare complexity wrong
    
-
    Section: 25.3.8 [alg.lex.comparison] Status: TC
- Submitter: Howard Hinnant Date: 1999-06-20
    
-
    View all issues with TC status.
    
+
    Section: 25.5.8 [alg.lex.comparison] Status: TC1
+ Submitter: Howard Hinnant Opened: 1999-06-20  Last modified: 2008-09-26
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    The lexicographical_compare complexity is specified as:
    
 
    
@@ -5664,7 +6022,7 @@ right! (and Matt states this complexity in his book)
    
 
 
 
    Proposed resolution:
    
-
    Change 25.3.8 [alg.lex.comparison] complexity to:
    
+
    Change 25.5.8 [alg.lex.comparison] complexity to:
    
     
    
     At most 2*min((last1 - first1), (last2 - first2))
     applications of the corresponding comparison.
@@ -5689,12 +6047,12 @@ right! (and Matt states this complexity in his book)
    
 
 
    
 
    144. Deque constructor complexity wrong 
    
-
    Section: 23.2.2.1 [deque.cons] Status: TC
- Submitter: Herb Sutter Date: 1999-05-09
    
+
    Section: 23.3.2.1 [deque.cons] Status: TC1
+ Submitter: Herb Sutter Opened: 1999-05-09  Last modified: 2008-09-26
    
 
    View all other issues in [deque.cons].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
-
    In 23.2.2.1 [deque.cons] paragraph 6, the deque ctor that takes an iterator range appears
+
    In 23.3.2.1 [deque.cons] paragraph 6, the deque ctor that takes an iterator range appears
 to have complexity requirements which are incorrect, and which contradict the
 complexity requirements for insert(). I suspect that the text in question,
 below, was taken from vector:
    
@@ -5719,7 +6077,7 @@ insert?
    
 
 
 
    Proposed resolution:
    
-
    In 23.2.2.1 [deque.cons] paragraph 6, replace the Complexity description, including the
+
    In 23.3.2.1 [deque.cons] paragraph 6, replace the Complexity description, including the
 footnote, with the following text (which also corrects the "abd"
 typo):
    
 
    
@@ -5731,10 +6089,10 @@ typo):
    
 
 
    
 
    146. complex<T> Inserter and Extractor need sentries
    
-
    Section: 26.3.6 [complex.ops] Status: TC
- Submitter: Angelika Langer Date: 1999-05-12
    
+
    Section: 26.4.6 [complex.ops] Status: TC1
+ Submitter: Angelika Langer Opened: 1999-05-12  Last modified: 2008-09-26
    
 
    View all other issues in [complex.ops].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    The extractor for complex numbers is specified as: 
    
 
@@ -5794,7 +6152,7 @@ what the intent was. 
    
 
 
 
    Proposed resolution:
    
-
    After 26.3.6 [complex.ops] paragraph 14 (operator>>), add a
+
    After 26.4.6 [complex.ops] paragraph 14 (operator>>), add a
 Notes clause:
    
 
 
    
@@ -5818,10 +6176,10 @@ as written.
    
 
 
    
 
    147. Library Intro refers to global functions that aren't global
    
-
    Section: 17.4.4.3 [global.functions] Status: TC
- Submitter: Lois Goldthwaite Date: 1999-06-04
    
+
    Section: 17.6.4.4 [global.functions] Status: TC1
+ Submitter: Lois Goldthwaite Opened: 1999-06-04  Last modified: 2008-09-26
    
 
    View all other issues in [global.functions].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    The library had many global functions until 17.4.1.1 [lib.contents]
 paragraph 2 was added: 
    
@@ -5894,19 +6252,19 @@ was changed from "non-member" to "global or non-member.
 
 
    
 
    148. Functions in the example facet BoolNames should be const
    
-
    Section: 22.2.8 [facets.examples] Status: TC
- Submitter: Jeremy Siek Date: 1999-06-03
    
+
    Section: 22.4.8 [facets.examples] Status: TC1
+ Submitter: Jeremy Siek Opened: 1999-06-03  Last modified: 2008-09-26
    
 
    View all other issues in [facets.examples].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
-
    In 22.2.8 [facets.examples] paragraph 13, the do_truename() and
+
    In 22.4.8 [facets.examples] paragraph 13, the do_truename() and
 do_falsename() functions in the example facet BoolNames should be
 const. The functions they are overriding in
 numpunct_byname<char> are const. 
    
 
 
 
    Proposed resolution:
    
-
    In 22.2.8 [facets.examples] paragraph 13, insert "const" in
+
    In 22.4.8 [facets.examples] paragraph 13, insert "const" in
 two places:
    
 
    
   
    string do_truename() const { return "Oui Oui!"; }
    
@@ -5918,15 +6276,15 @@ two places:
    
 
 
    
 
    150. Find_first_of says integer instead of iterator 
    
-
    Section: 25.1.7 [alg.find.first.of] Status: TC
- Submitter: Matt McClure Date: 1999-06-30
    
+
    Section: 25.3.7 [alg.find.first.of] Status: TC1
+ Submitter: Matt McClure Opened: 1999-06-30  Last modified: 2008-09-26
    
 
    View all other issues in [alg.find.first.of].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
 
 
    Proposed resolution:
    
-
    Change 25.1.7 [alg.find.first.of] paragraph 2 from:
    
+
    Change 25.3.7 [alg.find.first.of] paragraph 2 from:
    
 
 
    
 
    Returns: The first iterator i in the range [first1, last1) such
@@ -5945,10 +6303,11 @@ that for some iterator j in the range [first2, last2) ...
    
 
 
    
 
    151. Can't currently clear() empty container
    
-
    Section: 23.1.3 [sequence.reqmts] Status: TC
- Submitter: Ed Brey Date: 1999-06-21
    
+
    Section: 23.2.3 [sequence.reqmts] Status: TC1
+ Submitter: Ed Brey Opened: 1999-06-21  Last modified: 2008-09-26
    
+
    View other active issues in [sequence.reqmts].
    
 
    View all other issues in [sequence.reqmts].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    For both sequences and associative containers, a.clear() has the
 semantics of erase(a.begin(),a.end()), which is undefined for an empty
@@ -5992,10 +6351,10 @@ iterators or certain kinds of iterators is unnecessary.
 
 
    
 
    152. Typo in scan_is() semantics
    
-
    Section: 22.2.1.1.2 [locale.ctype.virtuals] Status: TC
- Submitter: Dietmar Kühl Date: 1999-07-20
    
+
    Section: 22.4.1.1.2 [locale.ctype.virtuals] Status: TC1
+ Submitter: Dietmar Kühl Opened: 1999-07-20  Last modified: 2008-09-26
    
 
    View all other issues in [locale.ctype.virtuals].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    The semantics of scan_is() (paragraphs 4 and 6) is not exactly described
 because there is no function is() which only takes a character as
@@ -6004,7 +6363,7 @@ vague.
    
 
 
 
    Proposed resolution:
    
-
    In 22.2.1.1.2 [locale.ctype.virtuals] paragraphs 4 and 6, change the returns
+
    In 22.4.1.1.2 [locale.ctype.virtuals] paragraphs 4 and 6, change the returns
 clause from:
    
 
    
   
    "... such that is(*p)
@@ -6019,10 +6378,10 @@ would..."
    
 
 
    
 
    153. Typo in narrow() semantics
    
-
    Section: 22.2.1.3.2 [facet.ctype.char.members] Status: WP
- Submitter: Dietmar Kühl Date: 1999-07-20
    
+
    Section: 22.4.1.3.2 [facet.ctype.char.members] Status: CD1
+ Submitter: Dietmar Kühl Opened: 1999-07-20  Last modified: 2008-09-26
    
 
    View all other issues in [facet.ctype.char.members].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Duplicate of: 207
    
 
    Discussion:
    
 
    The description of the array version of narrow() (in
@@ -6037,7 +6396,7 @@ one of them.
    
 
 
 
    Proposed resolution:
    
-
    Change the returns clause in 22.2.1.3.2 [facet.ctype.char.members]
+
    Change the returns clause in 22.4.1.3.2 [facet.ctype.char.members]
 paragraph 10 from:
    
 
        Returns: do_widen(low, high, to).
    
 
@@ -6045,7 +6404,7 @@ paragraph 10 from:
    
 
        Returns: do_widen(c) or do_widen(low, high, to), 
 respectively.
    
 
-
    Change 22.2.1.3.2 [facet.ctype.char.members] paragraph 10 and 11 from:
    
+
    Change 22.4.1.3.2 [facet.ctype.char.members] paragraph 10 and 11 from:
    
 
            char        narrow(char c, char /*dfault*/) const;
         const char* narrow(const char* low, const char* high,
                            char /*dfault*/, char* to) const;
    
@@ -6079,11 +6438,11 @@ same paragraphs.]
    
 
 
    
 
    154. Missing double specifier for do_get()
    
-
    Section: 22.2.2.1.2 [facet.num.get.virtuals] Status: TC
- Submitter: Dietmar Kühl Date: 1999-07-20
    
+
    Section: 22.4.2.1.2 [facet.num.get.virtuals] Status: TC1
+ Submitter: Dietmar Kühl Opened: 1999-07-20  Last modified: 2008-09-26
    
 
    View other active issues in [facet.num.get.virtuals].
    
 
    View all other issues in [facet.num.get.virtuals].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    The table in paragraph 7 for the length modifier does not list the length
 modifier l to be applied if the type is double. Thus, the
@@ -6093,7 +6452,7 @@ is actually a problem I found quite often in production code, too).
    
 
 
 
    Proposed resolution:
    
-
    In 22.2.2.1.2 [facet.num.get.virtuals], paragraph 7, add a row in the Length
+
    In 22.4.2.1.2 [facet.num.get.virtuals], paragraph 7, add a row in the Length
 Modifier table to say that for double a length modifier
 l is to be used.
    
 
@@ -6106,18 +6465,18 @@ Modifier table to say that for double a length modifier
 
 
    
 
    155. Typo in naming the class defining the class Init
    
-
    Section: 27.3 [iostream.objects] Status: TC
- Submitter: Dietmar Kühl Date: 1999-07-20
    
+
    Section: 27.4 [iostream.objects] Status: TC1
+ Submitter: Dietmar Kühl Opened: 1999-07-20  Last modified: 2008-09-26
    
 
    View all other issues in [iostream.objects].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    There are conflicting statements about where the class
-Init is defined. According to 27.3 [iostream.objects] paragraph 2
-it is defined as basic_ios::Init, according to 27.4.2 [ios.base] it is defined as ios_base::Init.
    
+Init is defined. According to 27.4 [iostream.objects] paragraph 2
+it is defined as basic_ios::Init, according to 27.5.2 [ios.base] it is defined as ios_base::Init.
    
 
 
 
    Proposed resolution:
    
-
    Change 27.3 [iostream.objects] paragraph 2 from
+
    Change 27.4 [iostream.objects] paragraph 2 from
 "basic_ios::Init" to
 "ios_base::Init".
    
 
@@ -6131,19 +6490,19 @@ the change.
    
 
 
    
 
    156. Typo in imbue() description
    
-
    Section: 27.4.2.3 [ios.base.locales] Status: TC
- Submitter: Dietmar Kühl Date: 1999-07-20
    
+
    Section: 27.5.2.3 [ios.base.locales] Status: TC1
+ Submitter: Dietmar Kühl Opened: 1999-07-20  Last modified: 2008-09-26
    
 
    View all other issues in [ios.base.locales].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    There is a small discrepancy between the declarations of
-imbue(): in 27.4.2 [ios.base] the argument is passed as
-locale const& (correct), in 27.4.2.3 [ios.base.locales] it
+imbue(): in 27.5.2 [ios.base] the argument is passed as
+locale const& (correct), in 27.5.2.3 [ios.base.locales] it
 is passed as locale const (wrong).
    
 
 
 
    Proposed resolution:
    
-
    In 27.4.2.3 [ios.base.locales] change the imbue argument
+
    In 27.5.2.3 [ios.base.locales] change the imbue argument
 from "locale const" to "locale
 const&".
    
 
@@ -6152,10 +6511,10 @@ const&".
    
 
 
    
 
    158. Underspecified semantics for setbuf()
    
-
    Section: 27.5.2.4.2 [streambuf.virt.buffer] Status: TC
- Submitter: Dietmar Kühl Date: 1999-07-20
    
+
    Section: 27.6.2.4.2 [streambuf.virt.buffer] Status: TC1
+ Submitter: Dietmar Kühl Opened: 1999-07-20  Last modified: 2008-09-26
    
 
    View all other issues in [streambuf.virt.buffer].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    The default behavior of setbuf() is described only for the
 situation that gptr() != 0 && gptr() != egptr():
@@ -6170,7 +6529,7 @@ to do nothing.
    
 
 
 
    Proposed resolution:
    
-
    Change 27.5.2.4.2 [streambuf.virt.buffer], paragraph 3, Default behavior,
+
    Change 27.6.2.4.2 [streambuf.virt.buffer], paragraph 3, Default behavior,
 to: "Default behavior: Does nothing. Returns this."
    
 
 
@@ -6178,9 +6537,9 @@ to: "Default behavior: Does nothing. Returns this."
    
 
 
    
 
    159. Strange use of underflow()
    
-
    Section: 27.5.2.4.3 [streambuf.virt.get] Status: TC
- Submitter: Dietmar Kühl Date: 1999-07-20
    
-
    View all issues with TC status.
    
+
    Section: 27.6.2.4.3 [streambuf.virt.get] Status: TC1
+ Submitter: Dietmar Kühl Opened: 1999-07-20  Last modified: 2008-09-26
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    The description of the meaning of the result of
 showmanyc() seems to be rather strange: It uses calls to
@@ -6191,7 +6550,7 @@ be fixed to use sbumpc() instead.
    
 
 
 
    Proposed resolution:
    
-
    Change 27.5.2.4.3 [streambuf.virt.get] paragraph 1,
+
    Change 27.6.2.4.3 [streambuf.virt.get] paragraph 1,
 showmanyc()returns clause, by replacing the word
 "supplied" with the words "extracted from the
 stream".
    
@@ -6201,10 +6560,10 @@ stream".
    
 
 
    
 
    160. Typo: Use of non-existing function exception()
    
-
    Section: 27.6.1.1 [istream] Status: TC
- Submitter: Dietmar Kühl Date: 1999-07-20
    
+
    Section: 27.7.1.1 [istream] Status: TC1
+ Submitter: Dietmar Kühl Opened: 1999-07-20  Last modified: 2008-09-26
    
 
    View all other issues in [istream].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    The paragraph 4 refers to the function exception() which
 is not defined. Probably, the referred function is
@@ -6212,8 +6571,8 @@ is not defined. Probably, the referred function is
 
 
 
    Proposed resolution:
    
-
    In 27.6.1.1 [istream], 27.6.1.3 [istream.unformatted], paragraph 1,
-27.6.2.1 [ostream], paragraph 3, and 27.6.2.6.1 [ostream.formatted.reqmts],
+
    In 27.7.1.1 [istream], 27.7.1.3 [istream.unformatted], paragraph 1,
+27.7.2.1 [ostream], paragraph 3, and 27.7.2.6.1 [ostream.formatted.reqmts],
 paragraph 1, change "exception()" to
 "exceptions()".
    
 
@@ -6227,10 +6586,10 @@ is the correct spelling.]
    
 
 
    
 
    161. Typo: istream_iterator vs. istreambuf_iterator
    
-
    Section: 27.6.1.2.2 [istream.formatted.arithmetic] Status: TC
- Submitter: Dietmar Kühl Date: 1999-07-20
    
+
    Section: 27.7.1.2.2 [istream.formatted.arithmetic] Status: TC1
+ Submitter: Dietmar Kühl Opened: 1999-07-20  Last modified: 2008-09-26
    
 
    View all other issues in [istream.formatted.arithmetic].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    The note in the second paragraph pretends that the first argument
 is an object of type istream_iterator. This is wrong: It is
@@ -6238,7 +6597,7 @@ an object of type istreambuf_iterator.
    
 
 
 
    Proposed resolution:
    
-
    Change 27.6.1.2.2 [istream.formatted.arithmetic] from:
    
+
    Change 27.7.1.2.2 [istream.formatted.arithmetic] from:
    
 
    
   
    The first argument provides an object of the istream_iterator class...
    
 
    
@@ -6253,11 +6612,11 @@ an object of type istreambuf_iterator.
    
 
 
    
 
    164. do_put() has apparently unused fill argument
    
-
    Section: 22.2.5.3.2 [locale.time.put.virtuals] Status: TC
- Submitter: Angelika Langer Date: 1999-07-23
    
-
    View all issues with TC status.
    
+
    Section: 22.4.5.3.2 [locale.time.put.virtuals] Status: TC1
+ Submitter: Angelika Langer Opened: 1999-07-23  Last modified: 2008-09-26
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
-
    In 22.2.5.3.2 [locale.time.put.virtuals] the do_put() function is specified
+
    In 22.4.5.3.2 [locale.time.put.virtuals] the do_put() function is specified
 as taking a fill character as an argument, but the description of the
 function does not say whether the character is used at all and, if so,
 in which way. The same holds for any format control parameters that
@@ -6269,7 +6628,7 @@ signature of do_put() wrong, or is the effects clause incomplete?
    
 
 
 
    Proposed resolution:
    
-
    Add the following note after 22.2.5.3.2 [locale.time.put.virtuals]
+
    Add the following note after 22.4.5.3.2 [locale.time.put.virtuals]
 paragraph 2:
    
 
    
   
      [Note: the fill argument may be used in the implementation-defined  formats, or by derivations.  A space character is a reasonable default
@@ -6287,10 +6646,10 @@ argument since the standard doesn't say how it's used.
    
 
 
    
 
    165. xsputn(), pubsync() never called by basic_ostream members?
    
-
    Section: 27.6.2.1 [ostream] Status: WP
- Submitter: Dietmar Kühl Date: 1999-07-20
    
+
    Section: 27.7.2.1 [ostream] Status: CD1
+ Submitter: Dietmar Kühl Opened: 1999-07-20  Last modified: 2008-09-26
    
 
    View all other issues in [ostream].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    Paragraph 2 explicitly states that none of the basic_ostream
 functions falling into one of the groups "formatted output functions"
@@ -6347,10 +6706,10 @@ is allowed to call sync() while other functions are not.]
    
 
 
    
 
    167. Improper use of traits_type::length()
    
-
    Section: 27.6.2.6.4 [ostream.inserters.character] Status: WP
- Submitter: Dietmar Kühl Date: 1999-07-20
    
+
    Section: 27.7.2.6.4 [ostream.inserters.character] Status: CD1
+ Submitter: Dietmar Kühl Opened: 1999-07-20  Last modified: 2008-09-26
    
 
    View all other issues in [ostream.inserters.character].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    Paragraph 4 states that the length is determined using
 traits::length(s).  Unfortunately, this function is not
@@ -6362,7 +6721,7 @@ const*.
    
 
 
 
    Proposed resolution:
    
-
    Change 27.6.2.6.4 [ostream.inserters.character] paragraph 4 from:
    
+
    Change 27.7.2.6.4 [ostream.inserters.character] paragraph 4 from:
    
 
    
   
    Effects: Behaves like an formatted inserter (as described in
   lib.ostream.formatted.reqmts) of out. After a sentry object is
@@ -6427,10 +6786,10 @@ to char_traits<char>
    
 
 
    
 
    168. Typo: formatted vs. unformatted
    
-
    Section: 27.6.2.7 [ostream.unformatted] Status: TC
- Submitter: Dietmar Kühl Date: 1999-07-20
    
+
    Section: 27.7.2.7 [ostream.unformatted] Status: TC1
+ Submitter: Dietmar Kühl Opened: 1999-07-20  Last modified: 2008-09-26
    
 
    View all other issues in [ostream.unformatted].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    The first paragraph begins with a descriptions what has to be done
 in formatted output functions. Probably this is a typo and the
@@ -6438,7 +6797,7 @@ paragraph really want to describe unformatted output functions...
    
 
 
 
    Proposed resolution:
    
-
    In 27.6.2.7 [ostream.unformatted] paragraph 1, the first and last
+
    In 27.7.2.7 [ostream.unformatted] paragraph 1, the first and last
 sentences, change the word "formatted" to
 "unformatted":
    
 
    
@@ -6452,15 +6811,15 @@ sentences, change the word "formatted" to
 
 
    
 
    169. Bad efficiency of overflow() mandated
    
-
    Section: 27.7.1.4 [stringbuf.virtuals] Status: TC
- Submitter: Dietmar Kühl Date: 1999-07-20
    
+
    Section: 27.8.1.4 [stringbuf.virtuals] Status: TC1
+ Submitter: Dietmar Kühl Opened: 1999-07-20  Last modified: 2008-09-26
    
 
    View all other issues in [stringbuf.virtuals].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    Paragraph 8, Notes, of this section seems to mandate an extremely
 inefficient way of buffer handling for basic_stringbuf,
 especially in view of the restriction that basic_ostream
-member functions are not allowed to use xsputn() (see 27.6.2.1 [ostream]): For each character to be inserted, a new buffer
+member functions are not allowed to use xsputn() (see 27.7.2.1 [ostream]): For each character to be inserted, a new buffer
 is to be created.
     
 
    Of course, the resolution below requires some handling of
 simultaneous input and output since it is no longer possible to update
@@ -6469,7 +6828,7 @@ solution is to handle this in underflow().
    
 
 
 
    Proposed resolution:
    
-
    In 27.7.1.4 [stringbuf.virtuals] paragraph 8, Notes, insert the words
+
    In 27.8.1.4 [stringbuf.virtuals] paragraph 8, Notes, insert the words
 "at least" as in the following:
    
 
    
   
    To make a write position available, the function reallocates (or initially
@@ -6483,13 +6842,13 @@ solution is to handle this in underflow().
    
 
 
    
 
    170. Inconsistent definition of traits_type
    
-
    Section: 27.7.4 [stringstream] Status: TC
- Submitter: Dietmar Kühl Date: 1999-07-20
    
-
    View all issues with TC status.
    
+
    Section: 27.8.4 [stringstream] Status: TC1
+ Submitter: Dietmar Kühl Opened: 1999-07-20  Last modified: 2008-09-26
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
-
    The classes basic_stringstream (27.7.4 [stringstream]),
-basic_istringstream (27.7.2 [istringstream]), and
-basic_ostringstream (27.7.3 [ostringstream]) are inconsistent
+
    The classes basic_stringstream (27.8.4 [stringstream]),
+basic_istringstream (27.8.2 [istringstream]), and
+basic_ostringstream (27.8.3 [ostringstream]) are inconsistent
 in their definition of the type traits_type: For
 istringstream, this type is defined, for the other two it is
 not. This should be consistent.
    
@@ -6497,8 +6856,8 @@ not. This should be consistent.
    
 
 
    Proposed resolution:
    
 
    Proposed resolution:
     
    To the declarations of
-basic_ostringstream (27.7.3 [ostringstream]) and
-basic_stringstream (27.7.4 [stringstream]) add:
    
+basic_ostringstream (27.8.3 [ostringstream]) and
+basic_stringstream (27.8.4 [stringstream]) add:
    
 
    
 
    typedef traits traits_type;
    
 
    
@@ -6508,12 +6867,12 @@ not. This should be consistent.
    
 
 
    
 
    171. Strange seekpos() semantics due to joint position
    
-
    Section: 27.8.1.5 [filebuf.virtuals] Status: WP
- Submitter: Dietmar Kühl Date: 1999-07-20
    
+
    Section: 27.9.1.5 [filebuf.virtuals] Status: CD1
+ Submitter: Dietmar Kühl Opened: 1999-07-20  Last modified: 2008-09-26
    
 
    View all other issues in [filebuf.virtuals].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
-
    Overridden virtual functions, seekpos()
     
    In 27.8.1.1 [filebuf] paragraph 3, it is stated that a joint input and
+
    Overridden virtual functions, seekpos()
     
    In 27.9.1.1 [filebuf] paragraph 3, it is stated that a joint input and
 output position is maintained by basic_filebuf. Still, the
 description of seekpos() seems to talk about different file
 positions. In particular, it is unclear (at least to me) what is
@@ -6574,14 +6933,14 @@ paragraph 14 from:
    
 
 
    
 
    172. Inconsistent types for basic_istream::ignore()
    
-
    Section: 27.6.1.3 [istream.unformatted] Status: TC
- Submitter: Greg Comeau, Dietmar Kühl Date: 1999-07-23
    
+
    Section: 27.7.1.3 [istream.unformatted] Status: TC1
+ Submitter: Greg Comeau, Dietmar Kühl Opened: 1999-07-23  Last modified: 2008-09-26
    
 
    View all other issues in [istream.unformatted].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
-
    In 27.6.1.1 [istream] the function
+
    In 27.7.1.1 [istream] the function
 ignore() gets an object of type streamsize as first
-argument. However, in 27.6.1.3 [istream.unformatted]
+argument. However, in 27.7.1.3 [istream.unformatted]
 paragraph 23 the first argument is of type int.
    
 
 
    As far as I can see this is not really a contradiction because
@@ -6598,7 +6957,7 @@ numeric_limits<streamsize>::max.
    
 
 
 
    Proposed resolution:
    
-
    In 27.6.1.3 [istream.unformatted] paragraph 23 and 24, change both uses
+
    In 27.7.1.3 [istream.unformatted] paragraph 23 and 24, change both uses
 of int in the description of ignore() to
 streamsize.
    
 
@@ -6607,16 +6966,16 @@ of int in the description of ignore() to
 
 
    
 
    173. Inconsistent types for basic_filebuf::setbuf()
    
-
    Section: 27.8.1.5 [filebuf.virtuals] Status: TC
- Submitter: Greg Comeau, Dietmar Kühl Date: 1999-07-23
    
+
    Section: 27.9.1.5 [filebuf.virtuals] Status: TC1
+ Submitter: Greg Comeau, Dietmar Kühl Opened: 1999-07-23  Last modified: 2008-09-26
    
 
    View all other issues in [filebuf.virtuals].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
 
    
-In 27.8.1.1 [filebuf] the function setbuf() gets an
+In 27.9.1.1 [filebuf] the function setbuf() gets an
 object of type streamsize as second argument. However, in
-27.8.1.5 [filebuf.virtuals] paragraph 9 the second argument is of type
+27.9.1.5 [filebuf.virtuals] paragraph 9 the second argument is of type
 int.
 
    
 
@@ -6631,7 +6990,7 @@ as described in issue 
 
    174. Typo: OFF_T vs. POS_T
    
-
    Section: D.6 [depr.ios.members] Status: TC
- Submitter: Dietmar Kühl Date: 1999-07-23
    
+
    Section: D.6 [depr.ios.members] Status: TC1
+ Submitter: Dietmar Kühl Opened: 1999-07-23  Last modified: 2008-09-26
    
 
    View all other issues in [depr.ios.members].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    According to paragraph 1 of this section, streampos is the
 type OFF_T, the same type as streamoff. However, in
@@ -6660,10 +7019,10 @@ streampos;"
    
 
 
    
 
    175. Ambiguity for basic_streambuf::pubseekpos() and a few other functions.
    
-
    Section: D.6 [depr.ios.members] Status: TC
- Submitter: Dietmar Kühl Date: 1999-07-23
    
+
    Section: D.6 [depr.ios.members] Status: TC1
+ Submitter: Dietmar Kühl Opened: 1999-07-23  Last modified: 2008-09-26
    
 
    View all other issues in [depr.ios.members].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    According to paragraph 8 of this section, the methods
 basic_streambuf::pubseekpos(),
@@ -6689,10 +7048,10 @@ argument is not specified.
    
 
 
    
 
    176. exceptions() in ios_base...?
    
-
    Section: D.6 [depr.ios.members] Status: TC
- Submitter: Dietmar Kühl Date: 1999-07-23
    
+
    Section: D.6 [depr.ios.members] Status: TC1
+ Submitter: Dietmar Kühl Opened: 1999-07-23  Last modified: 2008-09-26
    
 
    View all other issues in [depr.ios.members].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    The "overload" for the function exceptions() in
 paragraph 8 gives the impression that there is another function of
@@ -6711,11 +7070,11 @@ function exceptions()into class basic_ios.
    
 
 
    
 
    179. Comparison of const_iterators to iterators doesn't work
    
-
    Section: 23.1 [container.requirements] Status: WP
- Submitter: Judy Ward Date: 1998-07-02
    
+
    Section: 23.2 [container.requirements] Status: CD1
+ Submitter: Judy Ward Opened: 1998-07-02  Last modified: 2008-09-26
    
 
    View other active issues in [container.requirements].
    
 
    View all other issues in [container.requirements].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    Currently the following will not compile on two well-known standard
 library implementations:
    
@@ -6791,7 +7150,7 @@ return i == ci;
 
 
 
    Proposed resolution:
    
-
    Insert this paragraph after 23.1 [container.requirements] paragraph 7:
    
+
    Insert this paragraph after 23.2 [container.requirements] paragraph 7:
    
 
    
   
    In the expressions
    
   
        i == j
@@ -6832,12 +7191,149 @@ separate issue.  (Issue 180. Container member iterator arguments constness has unintended consequences
+
    Section: 21.4 [basic.string] Status: CD1
+ Submitter: Dave Abrahams Opened: 1999-07-01  Last modified: 2008-09-26
    
+
    View other active issues in [basic.string].
    
+
    View all other issues in [basic.string].
    
+
    View all issues with CD1 status.
    
+
    Discussion:
    
+
    It is the constness of the container which should control whether
+it can be modified through a member function such as erase(), not the
+constness of the iterators. The iterators only serve to give
+positioning information.
    
+
+
    Here's a simple and typical example problem which is currently very
+difficult or impossible to solve without the change proposed
+below.
    
+
+
    Wrap a standard container C in a class W which allows clients to
+find and read (but not modify) a subrange of (C.begin(), C.end()]. The
+only modification clients are allowed to make to elements in this
+subrange is to erase them from C through the use of a member function
+of W.
    
+
+
    [
+post Bellevue, Alisdair adds:
+]
    
+
+
+
    
+
    
+This issue was implemented by
+N2350
+for everything but basic_string.
+
    
+
+
    
+Note that the specific example in this issue (basic_string) is the one place
+we forgot to amend in
+N2350,
+so we might open this issue for that
+single container?
+
    
+
    
+
+
    [
+Sophia Antipolis:
+]
    
+
+
+
    
+
    
+This was a fix that was intended for all standard library containers,
+and has been done for other containers, but string was missed.
+
    
+
    
+The wording updated.
+
    
+
    
+We did not make the change in replace, because this change would affect
+the implementation because the string may be written into. This is an
+issue that should be taken up by concepts.
+
    
+
    
+We note that the supplied wording addresses the initializer list provided in
+N2679.
+
    
+
    
+
+
+
+
    Proposed resolution:
    
+
    
+Update the following signature in the basic_string class template definition in
+21.4 [basic.string], p5:
+
    
+
    namespace std {
+  template<class charT, class traits = char_traits<charT>,
+    class Allocator = allocator<charT> >
+  class basic_string {
+
+    ...
+
+    iterator insert(const_iterator p, charT c);
+    void insert(const_iterator p, size_type n, charT c);
+    template<class InputIterator>
+      void insert(const_iterator p, InputIterator first, InputIterator last);
+    void insert(const_iterator p, initializer_list<charT>);
+
+    ...
+
+    iterator erase(const_iterator const_position);
+    iterator erase(const_iterator first, const_iterator last);
+
+    ...
+
+  };
+}
+
    
+
+
    
+Update the following signatures in 21.4.6.4 [string::insert]:
+
    
+
+
    iterator insert(const_iterator p, charT c);
+void insert(const_iterator p, size_type n, charT c);
+template<class InputIterator>
+  void insert(const_iterator p, InputIterator first, InputIterator last);
+void insert(const_iterator p, initializer_list<charT>);
+
    
+
+
    
+Update the following signatures in 21.4.6.5 [string::erase]:
+
    
+
+
    iterator erase(const_iterator const_position);
+iterator erase(const_iterator first, const_iterator last);
+
    
+
+
+
+
    Rationale:
    
+
    The issue was discussed at length. It was generally agreed that 1)
+There is no major technical argument against the change (although
+there is a minor argument that some obscure programs may break), and
+2) Such a change would not break const correctness. The concerns about
+making the change were 1) it is user detectable (although only in
+boundary cases), 2) it changes a large number of signatures, and 3) it
+seems more of a design issue that an out-and-out defect.
    
+
+
    The LWG believes that this issue should be considered as part of a
+general review of const issues for the next revision of the
+standard. Also see issue 200.
    
+
+
+
+
 
    
 
    181. make_pair() unintended behavior
    
-
    Section: 20.2.3 [pairs] Status: TC
- Submitter: Andrew Koenig Date: 1999-08-03
    
+
    Section: 20.3.3 [pairs] Status: TC1
+ Submitter: Andrew Koenig Opened: 1999-08-03  Last modified: 2008-09-26
    
+
    View other active issues in [pairs].
    
 
    View all other issues in [pairs].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    The claim has surfaced in Usenet that expressions such as
    
 
    
@@ -6851,7 +7347,7 @@ I doubt anyone intended that behavior...
 
 
 
    Proposed resolution:
    
-
    In 20.2 [utility], paragraph 1 change the following
+
    In 20.3 [utility], paragraph 1 change the following
 declaration of make_pair():
    
 
    
   
    template <class T1, class T2> pair<T1,T2> make_pair(const T1&, const T2&);
    
@@ -6860,7 +7356,7 @@ declaration of make_pair():
    
 
    
   
    template <class T1, class T2> pair<T1,T2> make_pair(T1, T2);
    
 
    
-
      In 20.2.3 [pairs] paragraph 7 and the line before, change:
    
+
      In 20.3.3 [pairs] paragraph 7 and the line before, change:
    
 
    
 
    template <class T1, class T2>
 pair<T1, T2> make_pair(const T1& x, const T2& y);
    
@@ -6893,14 +7389,15 @@ proposed resolution passed their test suites.
    
 
 
    
 
    182. Ambiguous references to size_t
    
-
    Section: 17 [library] Status: WP
- Submitter: Al Stevens Date: 1999-08-15
    
+
    Section: 17 [library] Status: CD1
+ Submitter: Al Stevens Opened: 1999-08-15  Last modified: 2008-09-26
    
+
    View other active issues in [library].
    
 
    View all other issues in [library].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    Many references to  size_t throughout the document
 omit the  std:: namespace qualification.
     
    For
-example, 17.4.3.5 [replacement.functions] paragraph 2:
    
+example, 17.6.3.6 [replacement.functions] paragraph 2:
    
 
    
 
     operator new(size_t)
  operator new(size_t, const std::nothrow_t&)
@@ -6910,7 +7407,7 @@ example, 17.4.3.5 [replacement.functions] paragraph 2:
    
 
 
 
    Proposed resolution:
    
-
       In 17.4.3.5 [replacement.functions] paragraph 2: replace:
    
+
       In 17.6.3.6 [replacement.functions] paragraph 2: replace:
    
 
    
 
         - operator new(size_t)
    
      - operator new(size_t, const std::nothrow_t&)
    
@@ -6987,7 +7484,7 @@ declaration of template <class charT> class ctype.
    
 
    The LWG believes correcting names like size_t and
 ptrdiff_t to std::size_t and std::ptrdiff_t
 to be essentially editorial.  There there can't be another size_t or
-ptrdiff_t meant anyway because, according to 17.4.3.2.4 [extern.types],
    
+ptrdiff_t meant anyway because, according to 17.6.3.3.4 [extern.types],
    
 
 
    
 For each type T from the Standard C library, the types ::T and std::T
@@ -7020,12 +7517,12 @@ them to be correct.]
    
 
 
    
 
    183. I/O stream manipulators don't work for wide character streams
    
-
    Section: 27.6.3 [std.manip] Status: WP
- Submitter: Andy Sawyer Date: 1999-07-07
    
+
    Section: 27.7.3 [std.manip] Status: CD1
+ Submitter: Andy Sawyer Opened: 1999-07-07  Last modified: 2008-09-26
    
 
    View all other issues in [std.manip].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
-
    27.6.3 [std.manip] paragraph 3 says (clause numbering added for
+
    27.7.3 [std.manip] paragraph 3 says (clause numbering added for
 exposition):
    
 
    
 
    Returns: An object s of unspecified type such that if [1] out is an (instance
@@ -7055,7 +7552,7 @@ basic_ostream as out"&
    
 
 
 
    Proposed resolution:
    
-
    Replace section 27.6.3 [std.manip] except paragraph 1 with the
+
    Replace section 27.7.3 [std.manip] except paragraph 1 with the
 following:
    
 
    
 
    2- The type designated smanip in each of the following function
@@ -7220,10 +7717,10 @@ checked by the LWG.]
    
 
 
    
 
    184. numeric_limits<bool> wording problems
    
-
    Section: 18.2.1.5 [numeric.special] Status: WP
- Submitter: Gabriel Dos Reis Date: 1999-07-21
    
+
    Section: 18.3.1.5 [numeric.special] Status: CD1
+ Submitter: Gabriel Dos Reis Opened: 1999-07-21  Last modified: 2008-09-26
    
 
    View all other issues in [numeric.special].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    bools are defined by the standard to be of integer types, as per
 3.9.1 [basic.fundamental] paragraph 7.  However "integer types"
@@ -7266,7 +7763,7 @@ numeric_limits<bool>::is_signed have similar problems.
    
 
 
 
    Proposed resolution:
    
-
    Append to the end of 18.2.1.5 [numeric.special]:
    
+
    Append to the end of 18.3.1.5 [numeric.special]:
    
 
    
   
    The specialization for bool shall be provided as follows:
    
   
        namespace std {
@@ -7326,12 +7823,12 @@ Josuttis provided the above wording.]
    
 
 
    
 
    185. Questionable use of term "inline"
    
-
    Section: 20.6 [function.objects] Status: WP
- Submitter: UK Panel Date: 1999-07-26
    
+
    Section: 20.7 [function.objects] Status: CD1
+ Submitter: UK Panel Opened: 1999-07-26  Last modified: 2008-09-26
    
 
    View all other issues in [function.objects].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
-
    Paragraph 4 of 20.6 [function.objects] says:
    
+
    Paragraph 4 of 20.7 [function.objects] says:
    
 
    
   
     [Example: To negate every element of a: transform(a.begin(), a.end(),
   a.begin(), negate<double>()); The corresponding functions will inline
@@ -7358,17 +7855,17 @@ not required elsewhere.
    
 
 
 
    Proposed resolution:
    
-
    In 20.6 [function.objects] paragraph 1, remove the sentence:
    
+
    In 20.7 [function.objects] paragraph 1, remove the sentence:
    
 
    
 
    They are important for the effective use of the library.
    
 
    
-
    Remove 20.6 [function.objects] paragraph 2, which reads:
    
+
    Remove 20.7 [function.objects] paragraph 2, which reads:
    
 
    
   
     Using function objects together with function templates
   increases the expressive power of the library as well as making the
   resulting code much more efficient.
    
 
    
-
    In 20.6 [function.objects] paragraph 4, remove the sentence:
    
+
    In 20.7 [function.objects] paragraph 4, remove the sentence:
    
 
    
   
    The corresponding functions will inline the addition and the
   negation.
    
@@ -7385,12 +7882,12 @@ not required elsewhere.
    
 
 
    
 
    186. bitset::set() second parameter should be bool
    
-
    Section: 23.3.5.2 [bitset.members] Status: WP
- Submitter: Darin Adler Date: 1999-08-13
    
+
    Section: 20.3.6.2 [bitset.members] Status: CD1
+ Submitter: Darin Adler Opened: 1999-08-13  Last modified: 2008-09-26
    
 
    View all other issues in [bitset.members].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
-
    In section 23.3.5.2 [bitset.members], paragraph 13 defines the
+
    In section 20.3.6.2 [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
 set the bit to true or false. The type of this second parameter should
@@ -7402,7 +7899,7 @@ translating 0 to false and any non-zero value to true.
    
 
 
 
    Proposed resolution:
    
-
    In 23.3.5 [template.bitset] Para 1 Replace:
    
+
    In 20.3.6 [template.bitset] Para 1 Replace:
    
 
    
 
    bitset<N>& set(size_t pos, int val = true ); 
    
 
    
@@ -7410,7 +7907,7 @@ translating 0 to false and any non-zero value to true.
    
 
    
   
    bitset<N>& set(size_t pos, bool val = true );
    
 
    
-
    In 23.3.5.2 [bitset.members] Para 12(.5) Replace:
    
+
    In 20.3.6.2 [bitset.members] Para 12(.5) Replace:
    
 
    
   
    bitset<N>& set(size_t pos, int val = 1 );
    
 
    
@@ -7439,10 +7936,10 @@ nonvirtual member of a standard library class.
    
 
 
    
 
    187. iter_swap underspecified
    
-
    Section: 25.2.3 [alg.swap] Status: WP
- Submitter: Andrew Koenig Date: 1999-08-14
    
+
    Section: 25.4.3 [alg.swap] Status: CD1
+ Submitter: Andrew Koenig Opened: 1999-08-14  Last modified: 2008-09-26
    
 
    View all other issues in [alg.swap].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    The description of iter_swap in 25.2.2 paragraph 7,says that it
 ``exchanges the values'' of the objects to which two iterators
@@ -7510,10 +8007,10 @@ one list to another.  That would surely be inappropriate.
    
 
 
    
 
    189. setprecision() not specified correctly
    
-
    Section: 27.4.2.2 [fmtflags.state] Status: TC
- Submitter: Andrew Koenig Date: 1999-08-25
    
+
    Section: 27.5.2.2 [fmtflags.state] Status: TC1
+ Submitter: Andrew Koenig Opened: 1999-08-25  Last modified: 2008-09-26
    
 
    View all other issues in [fmtflags.state].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    27.4.2.2 paragraph 9 claims that setprecision() sets the precision,
 and includes a parenthetical note saying that it is the number of
@@ -7529,7 +8026,7 @@ correct the statement in 27.4.2.2
    
 
 
 
    Proposed resolution:
    
-
    Remove from 27.4.2.2 [fmtflags.state], paragraph 9, the text
+
    Remove from 27.5.2.2 [fmtflags.state], paragraph 9, the text
 "(number of digits after the decimal point)".
    
 
 
@@ -7537,9 +8034,9 @@ correct the statement in 27.4.2.2
    
 
 
    
 
    193. Heap operations description incorrect
    
-
    Section: 25.3.6 [alg.heap.operations] Status: TC
- Submitter: Markus Mauhart Date: 1999-09-24
    
-
    View all issues with TC status.
    
+
    Section: 25.5.6 [alg.heap.operations] Status: TC1
+ Submitter: Markus Mauhart Opened: 1999-09-24  Last modified: 2008-09-26
    
+
    View all issues with TC1 status.
    
 
    Duplicate of: 216
    
 
    Discussion:
    
 
    25.3.6 [lib.alg.heap.operations] states two key properties of a heap [a,b), the first of them
@@ -7562,7 +8059,7 @@ priority AND time).
    
 
 
 
    Proposed resolution:
    
-
    Change 25.3.6 [alg.heap.operations] property (1) from:
    
+
    Change 25.5.6 [alg.heap.operations] property (1) from:
    
 
    
   
    (1) *a is the largest element
    
 
    
@@ -7577,10 +8074,10 @@ priority AND time).
    
 
 
    
 
    195. Should basic_istream::sentry's constructor ever set eofbit?
    
-
    Section: 27.6.1.1.3 [istream::sentry] Status: TC
- Submitter: Matt Austern Date: 1999-10-13
    
+
    Section: 27.7.1.1.3 [istream::sentry] Status: TC1
+ Submitter: Matt Austern Opened: 1999-10-13  Last modified: 2008-09-26
    
 
    View all other issues in [istream::sentry].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    Suppose that is.flags() & ios_base::skipws is nonzero.
 What should basic_istream<>::sentry's constructor do if it
@@ -7588,9 +8085,9 @@ reaches eof while skipping whitespace?  27.6.1.1.2/5 suggests it
 should set failbit. Should it set eofbit as well?  The standard
 doesn't seem to answer that question.
    
 
-
    On the one hand, nothing in 27.6.1.1.3 [istream::sentry] says that
+
    On the one hand, nothing in 27.7.1.1.3 [istream::sentry] says that
 basic_istream<>::sentry should ever set eofbit.  On the
-other hand, 27.6.1.1 [istream] paragraph 4 says that if
+other hand, 27.7.1.1 [istream] paragraph 4 says that if
 extraction from a streambuf "returns
 traits::eof(), then the input function, except as explicitly
 noted otherwise, completes its actions and does
@@ -7636,11 +8133,11 @@ returns traits::eof(), the function calls
 
 
    
 
    198. Validity of pointers and references unspecified after iterator destruction
    
-
    Section: 24.1 [iterator.requirements] Status: WP
- Submitter: Beman Dawes Date: 1999-11-03
    
-
    View other active issues in [iterator.requirements].
    
-
    View all other issues in [iterator.requirements].
    
-
    View all issues with WP status.
    
+
    Section: 24.2 [iterator.concepts] Status: CD1
+ Submitter: Beman Dawes Opened: 1999-11-03  Last modified: 2008-09-30
    
+
    View other active issues in [iterator.concepts].
    
+
    View all other issues in [iterator.concepts].
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 Is a pointer or reference obtained from an iterator still valid after
@@ -7688,14 +8185,14 @@ elements of containers.
    
 
 
    The standard itself assumes that pointers and references obtained
 from an iterator are still valid after iterator destruction or
-change. The definition of reverse_iterator::operator*(), 24.4.1.3.3 [reverse.iter.conv], which returns a reference, defines
+change. The definition of reverse_iterator::operator*(), 24.5.1.2.3 [reverse.iter.conv], which returns a reference, defines
 effects:
    
 
 
    
   
    Iterator tmp = current;
 return *--tmp;
    
 
    
-
    The definition of reverse_iterator::operator->(), 24.4.1.3.4
+
    The definition of reverse_iterator::operator->(), 24.5.1.2.4
 [reverse.iter.op.star], which returns a pointer, defines effects:
    
 
    
   
    return &(operator*());
    
@@ -7709,13 +8206,13 @@ implementation.
    
 
 
 
    Proposed resolution:
    
-
    Add a new paragraph to 24.1 [iterator.requirements]:
    
+
    Add a new paragraph to 24.2 [iterator.concepts]:
    
 
    
 Destruction of an iterator may invalidate pointers and references
 previously obtained from that iterator.
 
    
 
-
    Replace paragraph 1 of 24.4.1.3.3 [reverse.iter.conv] with:
    
+
    Replace paragraph 1 of 24.5.1.2.3 [reverse.iter.conv] with:
    
 
 
    
 
    Effects:
    
@@ -7728,7 +8225,7 @@ previously obtained from that iterator.
 [Note: This operation must use an auxiliary member variable,
 rather than a temporary variable, to avoid returning a reference that
 persists beyond the lifetime of its associated iterator.  (See
-24.1 [iterator.requirements].)  The name of this member variable is shown for
+24.2 [iterator.concepts].)  The name of this member variable is shown for
 exposition only.  --end note]
 
    
 
    
@@ -7746,7 +8243,7 @@ reformulated yet again to reflect this reality.]
    
 assumes its underlying iterator has persistent pointers and
 references.  Andy Koenig pointed out that it is possible to rewrite
 reverse_iterator so that it no longer makes such an assupmption.
-However, this issue is related to issue 299.  If we
+However, this issue is related to issue 299.  If we
 decide it is intentional that p[n] may return by value
 instead of reference when p is a Random Access Iterator,
 other changes in reverse_iterator will be necessary.]
    
@@ -7778,11 +8275,11 @@ predefined iterators are as strong as users expect.
    
 
 
    
 
    199. What does allocate(0) return?
    
-
    Section: 20.1.2 [allocator.requirements] Status: TC
- Submitter: Matt Austern Date: 1999-11-19
    
+
    Section: X [allocator.requirements] Status: TC1
+ Submitter: Matt Austern Opened: 1999-11-19  Last modified: 2008-09-26
    
 
    View other active issues in [allocator.requirements].
    
 
    View all other issues in [allocator.requirements].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    
 Suppose that A is a class that conforms to the
@@ -7814,10 +8311,10 @@ would be over-specification to mandate the return value.
 
 
    
 
    200. Forward iterator requirements don't allow constant iterators
    
-
    Section: 24.1.3 [forward.iterators] Status: WP
- Submitter: Matt Austern Date: 1999-11-19
    
+
    Section: 24.2.4 [forward.iterators] Status: CD1
+ Submitter: Matt Austern Opened: 1999-11-19  Last modified: 2008-09-26
    
 
    View all other issues in [forward.iterators].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 In table 74, the return type of the expression *a is given
@@ -7842,7 +8339,7 @@ otherwise const U&".
 
    [Tokyo: The LWG believes this is the tip of a larger iceberg;
 there are multiple const problems with the STL portion of the library
 and that these should be addressed as a single package.  Note
-that issue 180 has already been declared NAD Future for
+that issue 180 has already been declared NAD Future for
 that very reason.]
    
 
 
@@ -7860,10 +8357,10 @@ that we also need to worry about *r++ and a->m.]
    
 
 
    
 
    201. Numeric limits terminology wrong
    
-
    Section: 18.2.1 [limits] Status: WP
- Submitter: Stephen Cleary Date: 1999-12-21
    
+
    Section: 18.3.1 [limits] Status: CD1
+ Submitter: Stephen Cleary Opened: 1999-12-21  Last modified: 2008-09-26
    
 
    View all other issues in [limits].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 In some places in this section, the terms "fundamental types" and
@@ -7882,7 +8379,7 @@ specializations of numeric_limits.
 
    Proposed resolution:
    
 
 
    
-Change 18.2 [support.limits] to:
+Change 18.3 [support.limits] to:
 
    
 
 
    
@@ -7895,7 +8392,7 @@ characteristics of implementation-dependent fundamental
 
    
 
 
    
-Change 18.2.1 [limits] to:
+Change 18.3.1 [limits] to:
 
    
 
 
    
@@ -7918,7 +8415,7 @@ as complex<T> (26.3.2), shall not have specializations.
 
    
 
 
    
-Change 18.2.1.1 [numeric.limits] to:
+Change 18.3.1.1 [numeric.limits] to:
 
    
 
 
    
@@ -7936,10 +8433,11 @@ which do not.
 
 
    
 
    202. unique() effects unclear when predicate not an equivalence relation
    
-
    Section: 25.2.9 [alg.unique] Status: WP
- Submitter: Andrew Koenig Date: 2000-01-13
    
+
    Section: 25.4.9 [alg.unique] Status: CD1
+ Submitter: Andrew Koenig Opened: 2000-01-13  Last modified: 2008-09-26
    
+
    View other active issues in [alg.unique].
    
 
    View all other issues in [alg.unique].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 What should unique() do if you give it a predicate that is not an
@@ -8009,7 +8507,7 @@ In fact, the SGI implementation of unique() does neither: It yields 1,
 
 
 
    Proposed resolution:
    
-
    Change 25.2.9 [alg.unique] paragraph 1 to:
    
+
    Change 25.4.9 [alg.unique] paragraph 1 to:
    
 
    
 For a nonempty range, eliminates all but the first element from every
 consecutive group of equivalent elements referred to by the iterator
@@ -8044,7 +8542,7 @@ require another round of review.]
    
 
 
    Rationale:
    
 
    The LWG also considered an alternative resolution: change 
-25.2.9 [alg.unique] paragraph 1 to:
    
+25.4.9 [alg.unique] paragraph 1 to:
    
 
 
    
 For a nonempty range, eliminates all but the first element from every
@@ -8073,10 +8571,10 @@ existing implementations.
    
 
 
    
 
    206. operator new(size_t, nothrow) may become unlinked to ordinary operator new if ordinary version replaced
    
-
    Section: 18.5.1.1 [new.delete.single] Status: WP
- Submitter: Howard Hinnant Date: 1999-08-29
    
+
    Section: 18.6.1.1 [new.delete.single] Status: CD1
+ Submitter: Howard Hinnant Opened: 1999-08-29  Last modified: 2008-09-26
    
 
    View all other issues in [new.delete.single].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    As specified, the implementation of the nothrow version of operator
 new does not necessarily call the ordinary operator new, but may
@@ -8370,11 +8868,11 @@ his customers.
 
 
    
 
    208. Unnecessary restriction on past-the-end iterators
    
-
    Section: 24.1 [iterator.requirements] Status: TC
- Submitter: Stephen Cleary Date: 2000-02-02
    
-
    View other active issues in [iterator.requirements].
    
-
    View all other issues in [iterator.requirements].
    
-
    View all issues with TC status.
    
+
    Section: 24.2 [iterator.concepts] Status: TC1
+ Submitter: Stephen Cleary Opened: 2000-02-02  Last modified: 2008-09-30
    
+
    View other active issues in [iterator.concepts].
    
+
    View all other issues in [iterator.concepts].
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    In 24.1 paragraph 5, it is stated ". . . Dereferenceable and
 past-the-end values are always non-singular."
    
@@ -8389,7 +8887,7 @@ iterators obtained from different (generic) containers being not equal.
    
 
 
 
    Proposed resolution:
    
-
    Change 24.1 [iterator.requirements] paragraph 5, the last sentence, from:
    
+
    Change 24.2 [iterator.concepts] paragraph 5, the last sentence, from:
    
 
    
 
    Dereferenceable and past-the-end values are always non-singular.
    
 
    
@@ -8410,13 +8908,13 @@ iterators.  Null pointers are singular.
 
 
    
 
    209. basic_string declarations inconsistent
    
-
    Section: 21.3 [basic.string] Status: TC
- Submitter: Igor Stauder Date: 2000-02-11
    
+
    Section: 21.4 [basic.string] Status: TC1
+ Submitter: Igor Stauder Opened: 2000-02-11  Last modified: 2008-09-26
    
 
    View other active issues in [basic.string].
    
 
    View all other issues in [basic.string].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
-
    In Section 21.3 [basic.string] the basic_string member function
+
    In Section 21.4 [basic.string] the basic_string member function
 declarations use a consistent style except for the following functions:
    
 
    
   
    void push_back(const charT);
@@ -8431,7 +8929,7 @@ basic_string<charT,traits,Allocator>&
    
 
 
 
    Proposed resolution:
    
-
    In Section 21.3 [basic.string] change the basic_string member
+
    In Section 21.4 [basic.string] change the basic_string member
 function declarations push_back, assign, and swap to:
    
 
    
   
    void push_back(charT c); 
@@ -8453,10 +8951,10 @@ change.
 
 
    
 
    210. distance first and last confused
    
-
    Section: 25 [algorithms] Status: TC
- Submitter: Lisa Lippincott Date: 2000-02-15
    
+
    Section: 25 [algorithms] Status: TC1
+ Submitter: Lisa Lippincott Opened: 2000-02-15  Last modified: 2008-09-26
    
 
    View all other issues in [algorithms].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    In paragraph 9 of section 25 [algorithms], it is written:
    
 
    
@@ -8484,10 +8982,10 @@ former for consistency.
    
 
 
    
 
    211. operator>>(istream&, string&) doesn't set failbit
    
-
    Section: 21.3.8.9 [string.io] Status: TC
- Submitter: Scott Snyder Date: 2000-02-04
    
+
    Section: 21.4.8.9 [string.io] Status: TC1
+ Submitter: Scott Snyder Opened: 2000-02-04  Last modified: 2008-09-26
    
 
    View all other issues in [string.io].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    The description of the stream extraction operator for std::string (section
 21.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in
@@ -8502,14 +9000,14 @@ while (is >> str) ... ;
    
 
    
 
    (which tests failbit) is not required to terminate at EOF.
    
 
    Furthermore, this is inconsistent with other extraction operators,
-which do include this requirement. (See sections 27.6.1.2 [istream.formatted] and 27.6.1.3 [istream.unformatted]), where this
+which do include this requirement. (See sections 27.7.1.2 [istream.formatted] and 27.7.1.3 [istream.unformatted]), where this
 requirement is present, either explicitly or implicitly, for the
 extraction operators. It is also present explicitly in the description
-of getline (istream&, string&, charT) in section 21.3.8.9 [string.io] paragraph 8.)
    
+of getline (istream&, string&, charT) in section 21.4.8.9 [string.io] paragraph 8.)
    
 
 
 
    Proposed resolution:
    
-
    Insert new paragraph after paragraph 2 in section 21.3.8.9 [string.io]:
    
+
    Insert new paragraph after paragraph 2 in section 21.4.8.9 [string.io]:
    
 
    
 
 
    If the function extracts no characters, it calls
@@ -8522,10 +9020,11 @@ is.setstate(ios::failbit) which may throw ios_base::failure
 
 
    
 
    212. Empty range behavior unclear for several algorithms
    
-
    Section: 25.3.7 [alg.min.max] Status: TC
- Submitter: Nico Josuttis Date: 2000-02-26
    
+
    Section: 25.5.7 [alg.min.max] Status: TC1
+ Submitter: Nico Josuttis Opened: 2000-02-26  Last modified: 2008-09-26
    
+
    View other active issues in [alg.min.max].
    
 
    View all other issues in [alg.min.max].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    The standard doesn't specify what min_element() and max_element() shall
 return if the range is empty (first equals last). The usual implementations
@@ -8534,7 +9033,7 @@ next_permutation(), and prev_permutation().
    
 
 
 
    Proposed resolution:
    
-
    In 25.3.7 [alg.min.max] - Minimum and maximum, paragraphs 7 and
+
    In 25.5.7 [alg.min.max] - Minimum and maximum, paragraphs 7 and
 9, append: Returns last if first==last.
    
 
 
@@ -8549,10 +9048,10 @@ last.
    
 
 
    
 
    214. set::find() missing const overload
    
-
    Section: 23.3.3 [set], 23.3.4 [multiset] Status: WP
- Submitter: Judy Ward Date: 2000-02-28
    
+
    Section: 23.4.3 [set], 23.4.4 [multiset] Status: CD1
+ Submitter: Judy Ward Opened: 2000-02-28  Last modified: 2008-09-26
    
 
    View all other issues in [set].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Duplicate of: 450
    
 
    Discussion:
    
 
    The specification for the associative container requirements in
@@ -8567,7 +9066,7 @@ and multiset do not, all they have is:
    
 
 
    Proposed resolution:
    
 
    Change the prototypes for find(), lower_bound(), upper_bound(), and
-equal_range() in section 23.3.3 [set] and section 23.3.4 [multiset] to each have two overloads:
    
+equal_range() in section 23.4.3 [set] and section 23.4.4 [multiset] to each have two overloads:
    
 
    
   
    iterator find(const key_type & x);
 const_iterator find(const key_type & x) const;
    
@@ -8590,10 +9089,10 @@ equal_range.]
    
 
 
    
 
    217. Facets example (Classifying Japanese characters) contains errors
    
-
    Section: 22.2.8 [facets.examples] Status: TC
- Submitter: Martin Sebor Date: 2000-02-29
    
+
    Section: 22.4.8 [facets.examples] Status: TC1
+ Submitter: Martin Sebor Opened: 2000-02-29  Last modified: 2008-09-26
    
 
    View all other issues in [facets.examples].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    The example in 22.2.8, paragraph 11 contains the following errors:
    
 
    1) The member function `My::JCtype::is_kanji()' is non-const; the function
@@ -8644,9 +9143,9 @@ declared above.
    
 
 
    
 
    220. ~ios_base() usage valid?
    
-
    Section: 27.4.2.7 [ios.base.cons] Status: TC
- Submitter: Jonathan Schilling, Howard Hinnant Date: 2000-03-13
    
-
    View all issues with TC status.
    
+
    Section: 27.5.2.7 [ios.base.cons] Status: TC1
+ Submitter: Jonathan Schilling, Howard Hinnant Opened: 2000-03-13  Last modified: 2008-09-26
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    The pre-conditions for the ios_base destructor are described in 27.4.2.7
 paragraph 2:
    
@@ -8696,11 +9195,11 @@ initializations have taken place, the behavior is undefined.
    
 
 
    
 
    221. num_get<>::do_get stage 2 processing broken
    
-
    Section: 22.2.2.1.2 [facet.num.get.virtuals] Status: WP
- Submitter: Matt Austern Date: 2000-03-14
    
+
    Section: 22.4.2.1.2 [facet.num.get.virtuals] Status: CD1
+ Submitter: Matt Austern Opened: 2000-03-14  Last modified: 2008-09-26
    
 
    View other active issues in [facet.num.get.virtuals].
    
 
    View all other issues in [facet.num.get.virtuals].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    Stage 2 processing of numeric conversion is broken.
    
 
@@ -8744,10 +9243,11 @@ deliberately, with full knowledge of that limitation.
    
 
 
    
 
    222. Are throw clauses necessary if a throw is already implied by the effects clause?
    
-
    Section: 17.3.1.3 [structure.specifications] Status: TC
- Submitter: Judy Ward Date: 2000-03-17
    
+
    Section: 17.5.1.4 [structure.specifications] Status: TC1
+ Submitter: Judy Ward Opened: 2000-03-17  Last modified: 2008-09-26
    
+
    View other active issues in [structure.specifications].
    
 
    View all other issues in [structure.specifications].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    Section 21.3.6.8 describes the basic_string::compare function this way:
    
 
    
@@ -8764,7 +9264,7 @@ int compare(size_type pos1, size_type n1,
 
    
 
    and the constructor that's implicitly called by the above is
 defined to throw an out-of-range exception if pos > str.size(). See
-section 21.3.1 [string.require] paragraph 4.
    
+section 21.4.1 [string.require] paragraph 4.
    
 
 
    On the other hand, the compare function descriptions themselves don't have
 "Throws: " clauses and according to 17.3.1.3, paragraph 3, elements
@@ -8775,7 +9275,7 @@ missing?
    
 
 
 
    Proposed resolution:
    
-
    In 17.3.1.3 [structure.specifications] paragraph 3, the footnote 148 attached to
+
    In 17.5.1.4 [structure.specifications] paragraph 3, the footnote 148 attached to
 the sentence "Descriptions of function semantics contain the
 following elements (as appropriate):", insert the word
 "further" so that the foot note reads:
    
@@ -8798,15 +9298,15 @@ footnote.
    
 
 
    
 
    223. reverse algorithm should use iter_swap rather than swap
    
-
    Section: 25.2.10 [alg.reverse] Status: TC
- Submitter: Dave Abrahams Date: 2000-03-21
    
-
    View all issues with TC status.
    
+
    Section: 25.4.10 [alg.reverse] Status: TC1
+ Submitter: Dave Abrahams Opened: 2000-03-21  Last modified: 2008-09-26
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    Shouldn't the effects say "applies iter_swap to all pairs..."?
    
 
 
 
    Proposed resolution:
    
-
    In 25.2.10 [alg.reverse], replace:
    
+
    In 25.4.10 [alg.reverse], replace:
    
   
    
   Effects: For each non-negative integer i <= (last - first)/2, 
   applies swap to all pairs of iterators first + i, (last - i) - 1.
@@ -8822,10 +9322,11 @@ footnote.
    
 
 
    
 
    224. clear() complexity for associative containers refers to undefined N
    
-
    Section: 23.1.4 [associative.reqmts] Status: TC
- Submitter: Ed Brey Date: 2000-03-23
    
+
    Section: 23.2.4 [associative.reqmts] Status: TC1
+ Submitter: Ed Brey Opened: 2000-03-23  Last modified: 2008-09-26
    
+
    View other active issues in [associative.reqmts].
    
 
    View all other issues in [associative.reqmts].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    In the associative container requirements table in 23.1.2 paragraph 7,
 a.clear() has complexity "log(size()) + N". However, the meaning of N
@@ -8849,10 +9350,10 @@ cut-and-paste from the range version of erase.
    
 
 
    
 
    225. std:: algorithms use of other unqualified algorithms
    
-
    Section: 17.4.4.3 [global.functions] Status: WP
- Submitter: Dave Abrahams Date: 2000-04-01
    
+
    Section: 17.6.4.4 [global.functions] Status: CD1
+ Submitter: Dave Abrahams Opened: 2000-04-01  Last modified: 2008-09-26
    
 
    View all other issues in [global.functions].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    Are algorithms in std:: allowed to use other algorithms without qualification, so functions in
 user namespaces might be found through Koenig lookup?
    
@@ -8916,7 +9417,7 @@ qualification is sufficient to suppress Koenig lookup.]
    
 
 
    Proposed resolution:
    
 
    Add a paragraph and a note at the end of 
-17.4.4.3 [global.functions]:
    
+17.6.4.4 [global.functions]:
    
 
    
 
 
    Unless otherwise specified, no global or non-member function in the
@@ -8981,10 +9482,10 @@ resolution for this issue is in accordance with Howard's paper.]
    
 
 
    
 
    226. User supplied specializations or overloads of namespace std function templates
    
-
    Section: 17.4.3.2 [reserved.names] Status: WP
- Submitter: Dave Abrahams Date: 2000-04-01
    
+
    Section: 17.6.3.3 [reserved.names] Status: CD1
+ Submitter: Dave Abrahams Opened: 2000-04-01  Last modified: 2008-09-26
    
 
    View all other issues in [reserved.names].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    The issues are: 
    
 
    1. How can a 3rd party library implementor (lib1) write a version of a standard
@@ -9163,7 +9664,7 @@ resolution is the one proposed by Howard.]
    
   (such as iter_swap, swap_ranges, reverse, rotate, and sort) conform
   to that concept.  The Swappable concept will make it clear that
   these algorithms use unqualified lookup for the calls
-  to swap.  Also, in 26.5.3.3 [valarray.transcend] paragraph 1,
+  to swap.  Also, in 26.6.3.3 [valarray.transcend] paragraph 1,
   state that the valarray transcendentals use unqualified lookup.
    
 
 
@@ -9172,10 +9673,10 @@ resolution is the one proposed by Howard.]
    
 
 
    
 
    227. std::swap() should require CopyConstructible or DefaultConstructible arguments
    
-
    Section: 25.2.3 [alg.swap] Status: TC
- Submitter: Dave Abrahams Date: 2000-04-09
    
+
    Section: 25.4.3 [alg.swap] Status: TC1
+ Submitter: Dave Abrahams Opened: 2000-04-09  Last modified: 2008-09-26
    
 
    View all other issues in [alg.swap].
    
-
    View all issues with TC status.
    
+
    View all issues with TC1 status.
    
 
    Discussion:
    
 
    25.2.2 reads:
    
 
    
@@ -9225,17 +9726,17 @@ resolution is the one proposed by Howard.]
    
 
 
    
 
    228. Incorrect specification of "..._byname" facets
    
-
    Section: 22.2 [locale.categories] Status: WP
- Submitter: Dietmar Kühl Date: 2000-04-20
    
+
    Section: 22.4 [locale.categories] Status: CD1
+ Submitter: Dietmar Kühl Opened: 2000-04-20  Last modified: 2008-09-26
    
 
    View other active issues in [locale.categories].
    
 
    View all other issues in [locale.categories].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
-
    The sections 22.2.1.2 [locale.ctype.byname], 22.2.1.5
+
    The sections 22.4.1.2 [locale.ctype.byname], 22.4.1.5
 [locale.codecvt.byname],
-sref ref="22.2.1.6", 22.2.3.2 [locale.numpunct.byname], 22.2.4.2
-[locale.collate.byname], 22.2.5.4 [locale.time.put.byname], 22.2.6.4
-[locale.moneypunct.byname], and 22.2.7.2 [locale.messages.byname]
+sref ref="22.2.1.6", 22.4.3.2 [locale.numpunct.byname], 22.4.4.2
+[locale.collate.byname], 22.4.5.4 [locale.time.put.byname], 22.4.6.4
+[locale.moneypunct.byname], and 22.4.7.2 [locale.messages.byname]
 overspecify the
 definitions of the "..._byname" classes by listing a bunch
 of virtual functions. At the same time, no semantics of these
@@ -9357,12 +9858,12 @@ specialization it is not virtual.
    
         ~messages_byname();          //  virtual
        };
      }
    
-
    Remove section 22.2.1.4 [locale.codecvt] completely (because in
+
    Remove section 22.4.1.4 [locale.codecvt] completely (because in
 this case only those members are defined to be virtual which are
 defined to be virtual in 'ctype<cT>'.)
    
 
 
    [Post-Tokyo: Dietmar Kühl submitted this issue at the request of
-the LWG to solve the underlying problems raised by issue 138.]
    
+the LWG to solve the underlying problems raised by issue 138.]
    
 
 
 
    [Copenhagen: proposed resolution was revised slightly, to remove
@@ -9376,9 +9877,11 @@ three last virtual functions from messages_byname.]
    
 
 
    
 
    229. Unqualified references of other library entities
    
-
    Section: 17.4.1.1 [contents] Status: WP
- Submitter: Steve Clamage Date: 2000-04-19
    
-
    View all issues with WP status.
    
+
    Section: 17.6.1.1 [contents] Status: CD1
+ Submitter: Steve Clamage Opened: 2000-04-19  Last modified: 2008-09-26
    
+
    View other active issues in [contents].
    
+
    View all other issues in [contents].
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    Throughout the library chapters, the descriptions of library entities refer
 to other library entities without necessarily qualifying the names.
    
@@ -9441,10 +9944,11 @@ resolution for the current issue makes sense.]
    
 
 
    
 
    230. Assignable specified without also specifying CopyConstructible
    
-
    Section: 17 [library] Status: WP
- Submitter: Beman Dawes Date: 2000-04-26
    
+
    Section: 17 [library] Status: CD1
+ Submitter: Beman Dawes Opened: 2000-04-26  Last modified: 2008-09-26
    
+
    View other active issues in [library].
    
 
    View all other issues in [library].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    Issue 227 identified an instance (std::swap) where
 Assignable was specified without also specifying
@@ -9454,21 +9958,21 @@ determine if the same defect existed elsewhere.
    
 
    There are a number of places (see proposed resolution below) where
 Assignable is specified without also specifying
 CopyConstructible. There are also several cases where both are
-specified. For example, 26.4.1 [rand.req].
    
+specified. For example, X [rand.req].
    
 
 
 
    Proposed resolution:
    
-
    In  23.1 [container.requirements] table 65 for value_type:
+
    In  23.2 [container.requirements] table 65 for value_type:
 change "T is Assignable" to "T is CopyConstructible and
 Assignable"
 
    
 
-
    In 23.1.4 [associative.reqmts] table 69 X::key_type; change
+
    In 23.2.4 [associative.reqmts] table 69 X::key_type; change
 "Key is Assignable" to "Key is
 CopyConstructible and Assignable"
    
 
    
 
-
    In 24.1.2 [output.iterators] paragraph 1, change:
+
    In 24.2.3 [output.iterators] paragraph 1, change:
 
    
 
    
 
     A class or a built-in type X satisfies the requirements of an
@@ -9487,7 +9991,7 @@ Table 73:
 
    
 
 
    [Post-Tokyo: Beman Dawes submitted this issue at the request of
-the LWG.  He asks that the 25.2.5 [alg.replace] and 25.2.6 [alg.fill] changes be studied carefully, as it is not clear that
+the LWG.  He asks that the 25.4.5 [alg.replace] and 25.4.6 [alg.fill] changes be studied carefully, as it is not clear that
 CopyConstructible is really a requirement and may be
 overspecification.]
    
 
@@ -9511,10 +10015,10 @@ Copy Constructible property.
    
 
 
    
 
    231. Precision in iostream?
    
-
    Section: 22.2.2.2.2 [facet.num.put.virtuals] Status: WP
- Submitter: James Kanze, Stephen Clamage Date: 2000-04-25
    
+
    Section: 22.4.2.2.2 [facet.num.put.virtuals] Status: CD1
+ Submitter: James Kanze, Stephen Clamage Opened: 2000-04-25  Last modified: 2008-09-26
    
 
    View all other issues in [facet.num.put.virtuals].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    What is the following program supposed to output?
    
 
    #include <iostream>
@@ -9558,7 +10062,7 @@ of the anomalies of printf:-).
    
 
 
    Proposed resolution:
    
 
    
-Replace 22.2.2.2.2 [facet.num.put.virtuals], paragraph 11, with the following 
+Replace 22.4.2.2.2 [facet.num.put.virtuals], paragraph 11, with the following 
 sentence:
 
    
 
    
@@ -9594,10 +10098,10 @@ where precision is 0 and mode is %g.]
    
 
 
    
 
    232. "depends" poorly defined in 17.4.3.1
    
-
    Section: 17.4.3.2 [reserved.names] Status: WP
- Submitter: Peter Dimov Date: 2000-04-18
    
+
    Section: 17.6.3.3 [reserved.names] Status: CD1
+ Submitter: Peter Dimov Opened: 2000-04-18  Last modified: 2008-09-26
    
 
    View all other issues in [reserved.names].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    17.4.3.1/1 uses the term "depends" to limit the set of allowed
 specializations of standard templates to those that "depend on a
@@ -9647,10 +10151,11 @@ rationale.]
    
 
 
    
 
    233. Insertion hints in associative containers
    
-
    Section: 23.1.4 [associative.reqmts] Status: WP
- Submitter: Andrew Koenig Date: 2000-04-30
    
+
    Section: 23.2.4 [associative.reqmts] Status: CD1
+ Submitter: Andrew Koenig Opened: 2000-04-30  Last modified: 2008-09-26
    
+
    View other active issues in [associative.reqmts].
    
 
    View all other issues in [associative.reqmts].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Duplicate of: 192, 246
    
 
    Discussion:
    
 
    
@@ -9755,7 +10260,7 @@ is no longer needed (or reflected in the proposed wording below).
 
 
    
 Change the indicated rows of the "Associative container requirements" Table in
-23.1.4 [associative.reqmts] to:
+23.2.4 [associative.reqmts] to:
 
    
 
 
    
@@ -9798,10 +10303,10 @@ logarithmic in general, but amortized constant if t is inserted right <
 
 
    
 
    234. Typos in allocator definition
    
-
    Section: 20.7.5.1 [allocator.members] Status: WP
- Submitter: Dietmar Kühl Date: 2000-04-24
    
+
    Section: 20.8.6.1 [allocator.members] Status: CD1
+ Submitter: Dietmar Kühl Opened: 2000-04-24  Last modified: 2008-09-26
    
 
    View all other issues in [allocator.members].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    In paragraphs 12 and 13 the effects of construct() and
 destruct() are described as returns but the functions actually
@@ -9816,9 +10321,9 @@ return void.
    
 
 
    
 
    235. No specification of default ctor for reverse_iterator
    
-
    Section: 24.4.1.1 [reverse.iterator] Status: WP
- Submitter: Dietmar Kühl Date: 2000-04-24
    
-
    View all issues with WP status.
    
+
    Section: 24.5.1.1 [reverse.iterator] Status: CD1
+ Submitter: Dietmar Kühl Opened: 2000-04-24  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    The declaration of reverse_iterator lists a default
 constructor.  However, no specification is given what this constructor
@@ -9826,7 +10331,7 @@ should do.
    
 
 
 
    Proposed resolution:
    
-  
    In section 24.4.1.3.1 [reverse.iter.cons] add the following
+  
    In section 24.5.1.2.1 [reverse.iter.cons] add the following
   paragraph:
    
       
    
       
    reverse_iterator()
    
@@ -9846,10 +10351,10 @@ should do.
    
 
 
    
 
    237. Undefined expression in complexity specification
    
-
    Section: 23.2.2.1 [deque.cons] Status: WP
- Submitter: Dietmar Kühl Date: 2000-04-24
    
+
    Section: 23.3.2.1 [deque.cons] Status: CD1
+ Submitter: Dietmar Kühl Opened: 2000-04-24  Last modified: 2008-09-26
    
 
    View all other issues in [deque.cons].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    The complexity specification in paragraph 6 says that the complexity
 is linear in first - last. Even if operator-() is
@@ -9868,9 +10373,9 @@ would have to be last - first.
    
 
 
    
 
    238. Contradictory results of stringbuf initialization.
    
-
    Section: 27.7.1.1 [stringbuf.cons] Status: WP
- Submitter: Dietmar Kühl Date: 2000-05-11
    
-
    View all issues with WP status.
    
+
    Section: 27.8.1.1 [stringbuf.cons] Status: CD1
+ Submitter: Dietmar Kühl Opened: 2000-05-11  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    In 27.7.1.1 paragraph 4 the results of calling the constructor of
 'basic_stringbuf' are said to be str() == str. This is fine
@@ -9905,10 +10410,11 @@ in the standard.
    
 
 
    
 
    239. Complexity of unique() and/or unique_copy incorrect
    
-
    Section: 25.2.9 [alg.unique] Status: WP
- Submitter: Angelika Langer Date: 2000-05-15
    
+
    Section: 25.4.9 [alg.unique] Status: CD1
+ Submitter: Angelika Langer Opened: 2000-05-15  Last modified: 2008-09-26
    
+
    View other active issues in [alg.unique].
    
 
    View all other issues in [alg.unique].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    The complexity of unique and unique_copy are inconsistent with each
 other and inconsistent with the implementations.  The standard
@@ -9938,7 +10444,7 @@ twice.
    
 
 
 
    Proposed resolution:
    
-
    Change both complexity sections in 25.2.9 [alg.unique] to:
    
+
    Change both complexity sections in 25.4.9 [alg.unique] to:
    
 
 
    Complexity: For nonempty ranges, exactly last - first - 1
 applications of the corresponding predicate.
    
@@ -9950,9 +10456,10 @@ applications of the corresponding predicate.
    
 
 
    
 
    240. Complexity of adjacent_find() is meaningless
    
-
    Section: 25.1.8 [alg.adjacent.find] Status: WP
- Submitter: Angelika Langer Date: 2000-05-15
    
-
    View all issues with WP status.
    
+
    Section: 25.3.8 [alg.adjacent.find] Status: CD1
+ Submitter: Angelika Langer Opened: 2000-05-15  Last modified: 2008-09-26
    
+
    View all other issues in [alg.adjacent.find].
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    The complexity section of adjacent_find is defective:
    
 
@@ -9990,7 +10497,7 @@ an "as-if" specification.
    
 
 
 
    Proposed resolution:
    
-
    Change the complexity section in 25.1.8 [alg.adjacent.find] to:
    
+
    Change the complexity section in 25.3.8 [alg.adjacent.find] to:
    
 
    
 For a nonempty range, exactly min((i - first) + 1,
 (last - first) - 1) applications of the
@@ -10009,10 +10516,11 @@ bound.  The LWG preferred an exact count.]
    
 
 
    
 
    241. Does unique_copy() require CopyConstructible and Assignable?
    
-
    Section: 25.2.9 [alg.unique] Status: WP
- Submitter: Angelika Langer Date: 2000-05-15
    
+
    Section: 25.4.9 [alg.unique] Status: CD1
+ Submitter: Angelika Langer Opened: 2000-05-15  Last modified: 2008-09-26
    
+
    View other active issues in [alg.unique].
    
 
    View all other issues in [alg.unique].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
 
    Some popular implementations of unique_copy() create temporary
@@ -10024,7 +10532,7 @@ the value type is CopyConstructible and Assignable.
    
 specify any additional requirements that they impose on any of the
 types used by the algorithm. An example of an algorithm that creates
 temporary copies and correctly specifies the additional requirements
-is accumulate(), 26.4.1 [rand.req].
    
+is accumulate(), X [rand.req].
    
 
 
    Since the specifications of unique() and unique_copy() do not
 require CopyConstructible and Assignable of the InputIterator's value
@@ -10078,10 +10586,10 @@ minor as not to require re-review.
 
 
    
 
    242. Side effects of function objects
    
-
    Section: 25.2.4 [alg.transform], 26.4 [rand] Status: WP
- Submitter: Angelika Langer Date: 2000-05-15
    
+
    Section: 25.4.4 [alg.transform], 26.5 [rand] Status: CD1
+ Submitter: Angelika Langer Opened: 2000-05-15  Last modified: 2008-09-26
    
 
    View all other issues in [alg.transform].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    The algorithms transform(), accumulate(), inner_product(),
 partial_sum(), and adjacent_difference() require that the function
@@ -10266,10 +10774,10 @@ intentional.]
    
 
 
    
 
    243. get and getline when sentry reports failure
    
-
    Section: 27.6.1.3 [istream.unformatted] Status: WP
- Submitter: Martin Sebor Date: 2000-05-15
    
+
    Section: 27.7.1.3 [istream.unformatted] Status: CD1
+ Submitter: Martin Sebor Opened: 2000-05-15  Last modified: 2008-09-26
    
 
    View all other issues in [istream.unformatted].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    basic_istream<>::get(), and basic_istream<>::getline(),
 are unclear with respect to the behavior and side-effects of the named
@@ -10326,12 +10834,12 @@ Jerry Schwarz's message c++std-lib-7618.
    
 
 
    
 
    247. vector, deque::insert complexity
    
-
    Section: 23.2.6.4 [vector.modifiers] Status: WP
- Submitter: Lisa Lippincott Date: 2000-06-06
    
+
    Section: 23.3.6.4 [vector.modifiers] Status: CD1
+ Submitter: Lisa Lippincott Opened: 2000-06-06  Last modified: 2008-09-26
    
 
    View all other issues in [vector.modifiers].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
-
    Paragraph 2 of 23.2.6.4 [vector.modifiers] describes the complexity
+
    Paragraph 2 of 23.3.6.4 [vector.modifiers] describes the complexity
 of vector::insert:
    
 
    
    
@@ -10352,7 +10860,7 @@ 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.2.3 [deque.modifiers],
+complexity of inserting multiple elements (23.3.2.3 [deque.modifiers],
 paragraph 3):
    
 
    
    
@@ -10368,7 +10876,7 @@ paragraph 3):
    
 
 
    Proposed resolution:
    
 
-
    Change Paragraph 2 of 23.2.6.4 [vector.modifiers] to
    
+
    Change Paragraph 2 of 23.3.6.4 [vector.modifiers] to
    
    
    
    Complexity: The complexity is linear in the number of elements 
    inserted plus the distance to the end of the vector.
@@ -10379,7 +10887,7 @@ paragraph 3):
    
    rotate.]
    
 
 
-
    Change 23.2.2.3 [deque.modifiers], paragraph 3, to:
    
+
    Change 23.3.2.3 [deque.modifiers], paragraph 3, to:
    
 
    
    
    Complexity: The complexity is linear in the number of elements 
@@ -10404,9 +10912,9 @@ paragraph 3):
    
 
 
    
 
    248. time_get fails to set eofbit
    
-
    Section: 22.2.5 [category.time] Status: WP
- Submitter: Martin Sebor Date: 2000-06-22
    
-
    View all issues with WP status.
    
+
    Section: 22.4.5 [category.time] Status: CD1
+ Submitter: Martin Sebor Opened: 2000-06-22  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    There is no requirement that any of time_get member functions set
 ios::eofbit when they reach the end iterator while parsing their input.
@@ -10434,13 +10942,13 @@ input facets.
    
 
 
    
 
    250. splicing invalidates iterators
    
-
    Section: 23.2.4.4 [list.ops] Status: WP
- Submitter: Brian Parker  Date: 2000-07-14
    
+
    Section: 23.3.4.4 [list.ops] Status: CD1
+ Submitter: Brian Parker  Opened: 2000-07-14  Last modified: 2008-09-26
    
 
    View all other issues in [list.ops].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-Section 23.2.4.4 [list.ops] states that
+Section 23.3.4.4 [list.ops] states that
 
    
 
      void splice(iterator position, list<T, Allocator>& x);
 
    
@@ -10457,14 +10965,14 @@ after splice.
 
 
    Proposed resolution:
    
 
-
    Add a footnote to 23.2.4.4 [list.ops], paragraph 1:
    
+
    Add a footnote to 23.3.4.4 [list.ops], paragraph 1:
    
 
    
 [Footnote: As specified in  [default.con.req], paragraphs
 4-5, the semantics described in this clause applies only to the case
 where allocators compare equal.  --end footnote]
 
    
 
-
    In 23.2.4.4 [list.ops], replace paragraph 4 with:
    
+
    In 23.3.4.4 [list.ops], replace paragraph 4 with:
    
 
    
 Effects: Inserts the contents of x before position and x becomes 
 empty.  Pointers and references to the moved elements of x now refer to 
@@ -10473,7 +10981,7 @@ moved elements will continue to refer to their elements, but they now
 behave as iterators into *this, not into x.
 
    
 
-
    In 23.2.4.4 [list.ops], replace paragraph 7 with:
    
+
    In 23.3.4.4 [list.ops], replace paragraph 7 with:
    
 
    
 Effects: Inserts an element pointed to by i from list x before 
 position and removes the element from x. The result is unchanged if 
@@ -10483,7 +10991,7 @@ to refer to this same element but as a member of *this.  Iterators to *i
 behave as iterators into *this, not into x.
 
    
 
-
    In 23.2.4.4 [list.ops], replace paragraph 12 with:
    
+
    In 23.3.4.4 [list.ops], replace paragraph 12 with:
    
 
    
 Requires: [first, last) is a valid range in x. The result is 
 undefined if position is an iterator in the range [first, last).  
@@ -10509,9 +11017,9 @@ allocators compare nonequal is outside the scope of the standard.
    
 
 
    
 
    251. basic_stringbuf missing allocator_type
    
-
    Section: 27.7.1 [stringbuf] Status: WP
- Submitter: Martin Sebor Date: 2000-07-28
    
-
    View all issues with WP status.
    
+
    Section: 27.8.1 [stringbuf] Status: CD1
+ Submitter: Martin Sebor Opened: 2000-07-28  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    The synopsis for the template class basic_stringbuf
 doesn't list a typedef for the template parameter
@@ -10533,10 +11041,10 @@ basic_stringstream (27.7.4) the typedef:
    
 
 
    
 
    252. missing casts/C-style casts used in iostreams
    
-
    Section: 27.7 [string.streams] Status: WP
- Submitter: Martin Sebor Date: 2000-07-28
    
+
    Section: 27.8 [string.streams] Status: CD1
+ Submitter: Martin Sebor Opened: 2000-07-28  Last modified: 2008-09-26
    
 
    View all other issues in [string.streams].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    27.7.2.2, p1 uses a C-style cast rather than the more appropriate
 const_cast<> in the Returns clause for basic_istringstream<>::rdbuf().
@@ -10579,11 +11087,11 @@ issue is stylistic rather than a matter of correctness.
    
 
 
    
 
    253. valarray helper functions are almost entirely useless
    
-
    Section: 26.5.2.1 [valarray.cons], 26.5.2.2 [valarray.assign] Status: WP
- Submitter: Robert Klarer Date: 2000-07-31
    
+
    Section: 26.6.2.1 [valarray.cons], 26.6.2.2 [valarray.assign] Status: CD1
+ Submitter: Robert Klarer Opened: 2000-07-31  Last modified: 2008-09-26
    
 
    View other active issues in [valarray.cons].
    
 
    View all other issues in [valarray.cons].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    This discussion is adapted from message c++std-lib-7056 posted
 November 11, 1999.  I don't think that anyone can reasonably claim
@@ -10661,53 +11169,53 @@ classes are almost entirely useless.
    
 
    slice_array:
    
 
      
 
    •  Make the copy constructor and copy-assignment operator declarations
-     public in the slice_array class template definition in 26.5.5 [template.slice.array] 
      • 
-
    •  remove paragraph 3 of 26.5.5 [template.slice.array]
      • 
+     public in the slice_array class template definition in 26.6.5 [template.slice.array] 
+
    •  remove paragraph 3 of 26.6.5 [template.slice.array]
      • 
 
    •  remove the copy constructor declaration from  [cons.slice.arr]
      • 
 
    •  change paragraph 1 of  [cons.slice.arr] to read "This constructor is declared
     to be private.  This constructor need not be defined."
      • 
-
    •  remove the first sentence of paragraph 1 of 26.5.5.1 [slice.arr.assign]
      • 
+
    •  remove the first sentence of paragraph 1 of 26.6.5.1 [slice.arr.assign]
      • 
 
    •  Change the first three words of the second sentence of paragraph 1 of
-    26.5.5.1 [slice.arr.assign] to "These assignment operators have"
      • 
+    26.6.5.1 [slice.arr.assign] to "These assignment operators have"
 
    
 
 
    gslice_array:
    
 
      
 
    •  Make the copy constructor and copy-assignment operator declarations
-    public in the gslice_array class template definition in 26.5.7 [template.gslice.array] 
      • 
-
    •  remove the note in paragraph 3 of 26.5.7 [template.gslice.array]
      • 
+    public in the gslice_array class template definition in 26.6.7 [template.gslice.array] 
+
    •  remove the note in paragraph 3 of 26.6.7 [template.gslice.array]
      • 
 
    •  remove the copy constructor declaration from  [gslice.array.cons]
      • 
 
    •  change paragraph 1 of  [gslice.array.cons] to read "This constructor is declared
     to be private.  This constructor need not be defined."
      • 
-
    •  remove the first sentence of paragraph 1 of 26.5.7.1 [gslice.array.assign]
      • 
+
    •  remove the first sentence of paragraph 1 of 26.6.7.1 [gslice.array.assign]
      • 
 
    •  Change the first three words of the second sentence of paragraph 1 of
-    26.5.7.1 [gslice.array.assign] to "These assignment operators have"
      • 
+    26.6.7.1 [gslice.array.assign] to "These assignment operators have"
 
    
 
 
    mask_array:
    
 
      
 
    •  Make the copy constructor and copy-assignment operator declarations
-    public in the mask_array class template definition in 26.5.8 [template.mask.array] 
      • 
-
    •  remove the note in paragraph 2 of 26.5.8 [template.mask.array]
      • 
+    public in the mask_array class template definition in 26.6.8 [template.mask.array] 
+
    •  remove the note in paragraph 2 of 26.6.8 [template.mask.array]
      • 
 
    •  remove the copy constructor declaration from  [mask.array.cons]
      • 
 
    •  change paragraph 1 of  [mask.array.cons] to read "This constructor is declared
     to be private.  This constructor need not be defined."
      • 
-
    •  remove the first sentence of paragraph 1 of 26.5.8.1 [mask.array.assign]
      • 
+
    •  remove the first sentence of paragraph 1 of 26.6.8.1 [mask.array.assign]
      • 
 
    •  Change the first three words of the second sentence of paragraph 1 of
-    26.5.8.1 [mask.array.assign] to "These assignment operators have"
      • 
+    26.6.8.1 [mask.array.assign] to "These assignment operators have"
 
    
 
 
    indirect_array:
    
 
      
 
    • Make the copy constructor and copy-assignment operator declarations
-    public in the indirect_array class definition in 26.5.9 [template.indirect.array]
      • 
-
    •  remove the note in paragraph 2 of 26.5.9 [template.indirect.array]
      • 
+    public in the indirect_array class definition in 26.6.9 [template.indirect.array]
+
    •  remove the note in paragraph 2 of 26.6.9 [template.indirect.array]
      • 
 
    •  remove the copy constructor declaration from  [indirect.array.cons]
      • 
 
    •  change the descriptive text in  [indirect.array.cons] to read "This constructor is
     declared to be private.  This constructor need not be defined."
      • 
-
    •  remove the first sentence of paragraph 1 of 26.5.9.1 [indirect.array.assign]
      • 
+
    •  remove the first sentence of paragraph 1 of 26.6.9.1 [indirect.array.assign]
      • 
 
    •  Change the first three words of the second sentence of paragraph 1 of
-    26.5.9.1 [indirect.array.assign] to "These assignment operators have"
      • 
+    26.6.9.1 [indirect.array.assign] to "These assignment operators have"
 
    
 
    [Proposed resolution was modified in Santa Cruz: explicitly make
 copy constructor and copy assignment operators public, instead of
@@ -10733,9 +11241,9 @@ expectation.
    
 
 
    
 
    254. Exception types in clause 19 are constructed from std::string
    
-
    Section: 19.1 [std.exceptions], 27.4.2.1.1 [ios::failure] Status: WP
- Submitter: Dave Abrahams Date: 2000-08-01
    
-
    View all issues with WP status.
    
+
    Section: 19.2 [std.exceptions], 27.5.2.1.1 [ios::failure] Status: CD1
+ Submitter: Dave Abrahams Opened: 2000-08-01  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 Many of the standard exception types which implementations are
@@ -10836,8 +11344,8 @@ include:
    
 
 
      
 
    • Limit the size of a string that exception objects are required to
-throw: change the postconditions of 19.1.2 [domain.error] paragraph 3
-and 19.1.6 [runtime.error] paragraph 3 to something like this:
+throw: change the postconditions of 19.2.2 [domain.error] paragraph 3
+and 19.2.6 [runtime.error] paragraph 3 to something like this:
 "strncmp(what(), what_arg._str(), N) == 0, where N is an
 implementation defined constant no smaller than 256".
      • 
 
    • Allow the const string& constructor to throw, but not the
@@ -10856,7 +11364,7 @@ throw, the string must compare equal to the argument.
      • 
 
      Proposed resolution:
      
 
 
      
-Change 19.1.1 [logic.error]
+Change 19.2.1 [logic.error]
 
      
 
 
      
@@ -10884,7 +11392,7 @@ Change 19.1.1 [logic.error]
 
      
 
 
      
-Change 19.1.2 [domain.error]
+Change 19.2.2 [domain.error]
 
      
 
 
      
@@ -10912,7 +11420,7 @@ Change 19.1.2 [domain.error]
 
      
 
 
      
-Change 19.1.3 [invalid.argument]
+Change 19.2.3 [invalid.argument]
 
      
 
 
      
@@ -10940,7 +11448,7 @@ Change 19.1.3 [invalid.argument]
 
      
 
 
      
-Change 19.1.4 [length.error]
+Change 19.2.4 [length.error]
 
      
 
 
      
@@ -10968,7 +11476,7 @@ Change 19.1.4 [length.error]
 
      
 
 
      
-Change 19.1.5 [out.of.range]
+Change 19.2.5 [out.of.range]
 
      
 
 
      
@@ -10996,7 +11504,7 @@ Change 19.1.5 [out.of.range]
 
      
 
 
      
-Change 19.1.6 [runtime.error]
+Change 19.2.6 [runtime.error]
 
      
 
 
      
@@ -11024,7 +11532,7 @@ Change 19.1.6 [runtime.error]
 
      
 
 
      
-Change 19.1.7 [range.error]
+Change 19.2.7 [range.error]
 
      
 
 
      
@@ -11052,7 +11560,7 @@ Change 19.1.7 [range.error]
 
      
 
 
      
-Change 19.1.8 [overflow.error]
+Change 19.2.8 [overflow.error]
 
      
 
 
      
@@ -11080,7 +11588,7 @@ Change 19.1.8 [overflow.error]
 
      
 
 
      
-Change 19.1.9 [underflow.error]
+Change 19.2.9 [underflow.error]
 
      
 
 
      
@@ -11108,7 +11616,7 @@ Change 19.1.9 [underflow.error]
 
      
 
 
      
-Change 27.4.2.1.1 [ios::failure]
+Change 27.5.2.1.1 [ios::failure]
 
      
 
 
      
@@ -11183,11 +11691,11 @@ the need to explicit include or construct a std::string.
 
 
      
 
      256. typo in 27.4.4.2, p17: copy_event does not exist
      
-
      Section: 27.4.4.2 [basic.ios.members] Status: WP
- Submitter: Martin Sebor Date: 2000-08-21
      
+
      Section: 27.5.4.2 [basic.ios.members] Status: CD1
+ Submitter: Martin Sebor Opened: 2000-08-21  Last modified: 2008-09-26
      
 
      View other active issues in [basic.ios.members].
      
 
      View all other issues in [basic.ios.members].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 27.4.4.2, p17 says
@@ -11214,11 +11722,11 @@ copyfmt_event.
 
 
      
 
      258. Missing allocator requirement
      
-
      Section: 20.1.2 [allocator.requirements] Status: WP
- Submitter: Matt Austern Date: 2000-08-22
      
+
      Section: X [allocator.requirements] Status: CD1
+ Submitter: Matt Austern Opened: 2000-08-22  Last modified: 2008-09-26
      
 
      View other active issues in [allocator.requirements].
      
 
      View all other issues in [allocator.requirements].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 From lib-7752:
@@ -11324,10 +11832,10 @@ issue to Ready status to be voted into the WP at Kona.
 
 
      
 
      259. basic_string::operator[] and const correctness
      
-
      Section: 21.3.4 [string.capacity] Status: WP
- Submitter: Chris Newton  Date: 2000-08-27
      
+
      Section: 21.4.4 [string.capacity] Status: CD1
+ Submitter: Chris Newton  Opened: 2000-08-27  Last modified: 2008-09-26
      
 
      View all other issues in [string.capacity].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 Paraphrased from a message that Chris Newton posted to comp.std.c++:
@@ -11358,10 +11866,10 @@ In section 21.3.4, paragraph 1, change
 
 
      
 
      260. Inconsistent return type of istream_iterator::operator++(int)
      
-
      Section: 24.5.1.2 [istream.iterator.ops] Status: WP
- Submitter: Martin Sebor Date: 2000-08-27
      
+
      Section: 24.6.1.2 [istream.iterator.ops] Status: CD1
+ Submitter: Martin Sebor Opened: 2000-08-27  Last modified: 2008-09-26
      
 
      View all other issues in [istream.iterator.ops].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      The synopsis of istream_iterator::operator++(int) in 24.5.1 shows
 it as returning the iterator by value. 24.5.1.2, p5 shows the same
@@ -11384,10 +11892,10 @@ given the Effects clause below (since a temporary is returned). The
 
 
      
 
      261. Missing description of istream_iterator::operator!=
      
-
      Section: 24.5.1.2 [istream.iterator.ops] Status: WP
- Submitter: Martin Sebor Date: 2000-08-27
      
+
      Section: 24.6.1.2 [istream.iterator.ops] Status: CD1
+ Submitter: Martin Sebor Opened: 2000-08-27  Last modified: 2008-09-26
      
 
      View all other issues in [istream.iterator.ops].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 24.5.1, p3 lists the synopsis for
@@ -11421,9 +11929,9 @@ Add paragraph 7 to the end of section 24.5.1.2 with the following text:
 
 
      
 
      262. Bitmask operator ~ specified incorrectly
      
-
      Section: 17.3.2.1.2 [bitmask.types] Status: WP
- Submitter: Beman Dawes Date: 2000-09-03
      
-
      View all issues with WP status.
      
+
      Section: 17.5.2.1.3 [bitmask.types] Status: CD1
+ Submitter: Beman Dawes Opened: 2000-09-03  Last modified: 2008-09-26
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 The ~ operation should be applied after the cast to int_type.
@@ -11452,11 +11960,11 @@ to:
 
 
      
 
      263. Severe restriction on basic_string reference counting
      
-
      Section: 21.3 [basic.string] Status: WP
- Submitter: Kevlin Henney Date: 2000-09-04
      
+
      Section: 21.4 [basic.string] Status: CD1
+ Submitter: Kevlin Henney Opened: 2000-09-04  Last modified: 2008-09-26
      
 
      View other active issues in [basic.string].
      
 
      View all other issues in [basic.string].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 The note in paragraph 6 suggests that the invalidation rules for
@@ -11534,10 +12042,11 @@ Change the following sentence in 21.3 paragraph 5 from
 
 
      
 
      264. Associative container insert(i, j) complexity requirements are not feasible.
      
-
      Section: 23.1.4 [associative.reqmts] Status: WP
- Submitter: John Potter Date: 2000-09-07
      
+
      Section: 23.2.4 [associative.reqmts] Status: CD1
+ Submitter: John Potter Opened: 2000-09-07  Last modified: 2008-09-26
      
+
      View other active issues in [associative.reqmts].
      
 
      View all other issues in [associative.reqmts].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Duplicate of: 102
      
 
      Discussion:
      
 
      
@@ -11588,10 +12097,11 @@ linear in some special cases.
 
 
      
 
      265. std::pair::pair() effects overly restrictive
      
-
      Section: 20.2.3 [pairs] Status: WP
- Submitter: Martin Sebor Date: 2000-09-11
      
+
      Section: 20.3.3 [pairs] Status: CD1
+ Submitter: Martin Sebor Opened: 2000-09-11  Last modified: 2008-09-26
      
+
      View other active issues in [pairs].
      
 
      View all other issues in [pairs].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 I don't see any requirements on the types of the elements of the
@@ -11638,9 +12148,9 @@ the straightforward implementation is correct.
      
 
 
      
 
      266. bad_exception::~bad_exception() missing Effects clause
      
-
      Section: 18.7.2.1 [bad.exception] Status: WP
- Submitter: Martin Sebor Date: 2000-09-24
      
-
      View all issues with WP status.
      
+
      Section: 18.8.2.1 [bad.exception] Status: CD1
+ Submitter: Martin Sebor Opened: 2000-09-24  Last modified: 2008-09-26
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 The synopsis for std::bad_exception lists the function ~bad_exception()
@@ -11652,10 +12162,10 @@ clause is missing).
 
      Proposed resolution:
      
 
      
 Remove the destructor from the class synopses of 
-bad_alloc (18.5.2.1 [bad.alloc]),
-bad_cast (18.6.2 [bad.cast]),
-bad_typeid (18.6.3 [bad.typeid]),
-and bad_exception (18.7.2.1 [bad.exception]).
+bad_alloc (18.6.2.1 [bad.alloc]),
+bad_cast (18.7.3 [bad.cast]),
+bad_typeid (18.7.4 [bad.typeid]),
+and bad_exception (18.8.2.1 [bad.exception]).
 
      
 
 
@@ -11673,10 +12183,10 @@ described in clause 19.
 
 
      
 
      268. Typo in locale synopsis
      
-
      Section: 22.1.1 [locale] Status: WP
- Submitter: Martin Sebor Date: 2000-10-05
      
+
      Section: 22.3.1 [locale] Status: CD1
+ Submitter: Martin Sebor Opened: 2000-10-05  Last modified: 2008-09-26
      
 
      View all other issues in [locale].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      The synopsis of the class std::locale in 22.1.1 contains two typos:
 the semicolons after the declarations of the default ctor
@@ -11704,10 +12214,10 @@ are missing.
      
 
 
      
 
      270. Binary search requirements overly strict
      
-
      Section: 25.3.3 [alg.binary.search] Status: WP
- Submitter: Matt Austern Date: 2000-10-18
      
+
      Section: 25.5.3 [alg.binary.search] Status: CD1
+ Submitter: Matt Austern Opened: 2000-10-18  Last modified: 2008-09-26
      
 
      View all other issues in [alg.binary.search].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Duplicate of: 472
      
 
      Discussion:
      
 
      
@@ -11971,9 +12481,9 @@ part of that pair is the lower bound.
      
 
 
      
 
      271. basic_iostream missing typedefs
      
-
      Section: 27.6.1.5 [iostreamclass] Status: WP
- Submitter: Martin Sebor Date: 2000-11-02
      
-
      View all issues with WP status.
      
+
      Section: 27.7.1.5 [iostreamclass] Status: CD1
+ Submitter: Martin Sebor Opened: 2000-11-02  Last modified: 2008-09-26
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 Class template basic_iostream has no typedefs.  The typedefs it
@@ -11985,7 +12495,7 @@ basic_iostream<T>::traits_type is ambiguous.
 
      Proposed resolution:
      
 
 
      Add the following to basic_iostream's class synopsis in 
-27.6.1.5 [iostreamclass], immediately after public:
      
+27.7.1.5 [iostreamclass], immediately after public:
      
 
 
        // types:
   typedef charT                     char_type;
@@ -12000,10 +12510,10 @@ basic_iostream<T>::traits_type is ambiguous.
 
 
      
 
      272. Missing parentheses around subexpression
      
-
      Section: 27.4.4.3 [iostate.flags] Status: WP
- Submitter: Martin Sebor Date: 2000-11-02
      
+
      Section: 27.5.4.3 [iostate.flags] Status: CD1
+ Submitter: Martin Sebor Opened: 2000-11-02  Last modified: 2008-09-26
      
 
      View all other issues in [iostate.flags].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Duplicate of: 569
      
 
      Discussion:
      
 
      
@@ -12029,10 +12539,11 @@ Add parentheses like so: rdstate()==(state|ios_base::badbit).
 
 
      
 
      273. Missing ios_base qualification on members of a dependent class
      
-
      Section: 27 [input.output] Status: WP
- Submitter: Martin Sebor Date: 2000-11-02
      
+
      Section: 27 [input.output] Status: CD1
+ Submitter: Martin Sebor Opened: 2000-11-02  Last modified: 2008-09-26
      
+
      View other active issues in [input.output].
      
 
      View all other issues in [input.output].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      27.5.2.4.2, p4, and 27.8.1.6, p2, 27.8.1.7, p3, 27.8.1.9, p2,
 27.8.1.10, p3 refer to in and/or out w/o ios_base:: qualification.
@@ -12049,11 +12560,11 @@ members, i.e., ios_base.
      
 
 
      
 
      274. a missing/impossible allocator requirement
      
-
      Section: 20.1.2 [allocator.requirements] Status: WP
- Submitter: Martin Sebor Date: 2000-11-02
      
+
      Section: X [allocator.requirements] Status: CD1
+ Submitter: Martin Sebor Opened: 2000-11-02  Last modified: 2008-09-26
      
 
      View other active issues in [allocator.requirements].
      
 
      View all other issues in [allocator.requirements].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 I see that table 31 in 20.1.5, p3 allows T in std::allocator<T> to be of
@@ -12121,10 +12632,10 @@ excluded from the PR.]
      
 
 
      
 
      275. Wrong type in num_get::get() overloads
      
-
      Section: 22.2.2.1.1 [facet.num.get.members] Status: WP
- Submitter: Matt Austern Date: 2000-11-02
      
+
      Section: 22.4.2.1.1 [facet.num.get.members] Status: CD1
+ Submitter: Matt Austern Opened: 2000-11-02  Last modified: 2008-09-26
      
 
      View all other issues in [facet.num.get.members].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 In 22.2.2.1.1, we have a list of overloads for num_get<>::get().
@@ -12166,7 +12677,7 @@ the arguments it was given.
 
 
 
      Proposed resolution:
      
-
      In 22.2.2.1.1 [facet.num.get.members], change
      
+
      In 22.4.2.1.1 [facet.num.get.members], change
      
 
        iter_type get(iter_type in, iter_type end, ios_base& str,
                 ios_base::iostate& err, short& val) const;
 
      
@@ -12180,15 +12691,15 @@ the arguments it was given.
 
 
      
 
      276. Assignable requirement for container value type overly strict
      
-
      Section: 23.1 [container.requirements] Status: WP
- Submitter: Peter Dimov Date: 2000-11-07
      
+
      Section: 23.2 [container.requirements] Status: CD1
+ Submitter: Peter Dimov Opened: 2000-11-07  Last modified: 2008-09-26
      
 
      View other active issues in [container.requirements].
      
 
      View all other issues in [container.requirements].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 23.1/3 states that the objects stored in a container must be
-Assignable.  23.3.1 [map], paragraph 2,
+Assignable.  23.4.1 [map], paragraph 2,
 states that map satisfies all requirements for a container, while in
 the same time defining value_type as pair<const Key, T> - a type
 that is not Assignable.
@@ -12336,13 +12847,13 @@ implement vector::push_back in terms of
 
 
      
 
      278. What does iterator validity mean?
      
-
      Section: 23.2.4.4 [list.ops] Status: WP
- Submitter: P.J. Plauger Date: 2000-11-27
      
+
      Section: 23.3.4.4 [list.ops] Status: CD1
+ Submitter: P.J. Plauger Opened: 2000-11-27  Last modified: 2008-09-30
      
 
      View all other issues in [list.ops].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
-Section 23.2.4.4 [list.ops] states that
+Section 23.3.4.4 [list.ops] states that
 
      
 
        void splice(iterator position, list<T, Allocator>& x);
 
      
@@ -12370,7 +12881,7 @@ introduce separate terms for the two kinds of "validity."
 
 
 
      Proposed resolution:
      
-
      Add the following text to the end of section 24.1 [iterator.requirements],
+
      Add the following text to the end of section 24.2 [iterator.concepts],
 after paragraph 5:
      
 
      
 An invalid iterator is an iterator that may be
@@ -12406,9 +12917,9 @@ the wording.  Dave provided new wording.]
      
 
 
      
 
      280. Comparison of reverse_iterator to const reverse_iterator
      
-
      Section: 24.4.1 [reverse.iterators] Status: WP
- Submitter: Steve Cleary Date: 2000-11-27
      
-
      View all issues with WP status.
      
+
      Section: 24.5.1 [reverse.iterators] Status: CD1
+ Submitter: Steve Cleary Opened: 2000-11-27  Last modified: 2008-09-26
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 This came from an email from Steve Cleary to Fergus in reference to
@@ -12435,7 +12946,7 @@ that, I don't see how any user code could break."
 
 
      Proposed resolution:
      
 
      
-Section: 24.4.1.1 [reverse.iterator]
+Section: 24.5.1.1 [reverse.iterator]
 add/change the following declarations:
      
 
        A) Add a templated assignment operator, after the same manner
         as the templated copy constructor, i.e.:
@@ -12461,7 +12972,7 @@ add/change the following declarations:
      
 
      
 
      
 Also make the addition/changes for these signatures in 
-24.4.1.3 [reverse.iter.ops].
+24.5.1.2 [reverse.iter.ops].
 
      
 
 
      [
@@ -12486,15 +12997,16 @@ this solution is safe and correct.
 
 
      
 
      281. std::min() and max() requirements overly restrictive
      
-
      Section: 25.3.7 [alg.min.max] Status: WP
- Submitter: Martin Sebor Date: 2000-12-02
      
+
      Section: 25.5.7 [alg.min.max] Status: CD1
+ Submitter: Martin Sebor Opened: 2000-12-02  Last modified: 2008-09-26
      
+
      View other active issues in [alg.min.max].
      
 
      View all other issues in [alg.min.max].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Duplicate of: 486
      
 
      Discussion:
      
 
      The requirements in 25.3.7, p1 and 4 call for T to satisfy the
 requirements of LessThanComparable ( [lessthancomparable])
-and CopyConstructible (20.1.1 [utility.arg.requirements]).
+and CopyConstructible (X [utility.arg.requirements]).
 Since the functions take and return their arguments and result by
 const reference, I believe the CopyConstructible requirement
 is unnecessary.
@@ -12517,10 +13029,10 @@ is unnecessary.
 
 
      
 
      282. What types does numpunct grouping refer to?
      
-
      Section: 22.2.2.2.2 [facet.num.put.virtuals] Status: WP
- Submitter: Howard Hinnant Date: 2000-12-05
      
+
      Section: 22.4.2.2.2 [facet.num.put.virtuals] Status: CD1
+ Submitter: Howard Hinnant Opened: 2000-12-05  Last modified: 2008-09-26
      
 
      View all other issues in [facet.num.put.virtuals].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 Paragraph 16 mistakenly singles out integral types for inserting 
@@ -12535,7 +13047,7 @@ point numbers described under 22.2.3.1/2.
 
      
 For integral types, punct.thousands_sep() characters are inserted into 
 the sequence as determined by the value returned by punct.do_grouping() 
-using the method described in 22.2.3.1.2 [facet.numpunct.virtuals].
+using the method described in 22.4.3.1.2 [facet.numpunct.virtuals].
 
      
 
 
      To:
      
@@ -12543,7 +13055,7 @@ using the method described in 22.2.3.1.2 [facet.numpunct.virtuals].
 
      
 For arithmetic types, punct.thousands_sep() characters are inserted into 
 the sequence as determined by the value returned by punct.do_grouping() 
-using the method described in 22.2.3.1.2 [facet.numpunct.virtuals].
+using the method described in 22.4.3.1.2 [facet.numpunct.virtuals].
 
      
 
 
      [
@@ -12575,10 +13087,11 @@ Howard, Bill, Pete, Benjamin, Nathan, Dietmar, Boris, and Martin.]
      
 
 
      
 
      283. std::replace() requirement incorrect/insufficient
      
-
      Section: 25.2.5 [alg.replace] Status: WP
- Submitter: Martin Sebor Date: 2000-12-15
      
+
      Section: 25.4.5 [alg.replace] Status: CD1
+ Submitter: Martin Sebor Opened: 2000-12-15  Last modified: 2008-09-26
      
+
      View other active issues in [alg.replace].
      
 
      View all other issues in [alg.replace].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Duplicate of: 483
      
 
      Discussion:
      
 
      
@@ -12737,15 +13250,15 @@ imposing a greater restriction that what the standard currently says
 
 
      
 
      284. unportable example in 20.3.7, p6
      
-
      Section: 20.6.7 [comparisons] Status: WP
- Submitter: Martin Sebor Date: 2000-12-26
      
-
      View all issues with WP status.
      
+
      Section: 20.7.8 [comparisons] Status: CD1
+ Submitter: Martin Sebor Opened: 2000-12-26  Last modified: 2008-09-26
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
-
      The example in 20.6.7 [comparisons], p6 shows how to use the C
+
      The example in 20.7.8 [comparisons], p6 shows how to use the C
 library function strcmp() with the function pointer adapter
 ptr_fun(). But since it's unspecified whether the C library
 functions have extern "C" or extern
-"C++" linkage [17.4.2.2 [using.linkage]], and since
+"C++" linkage [17.6.2.3 [using.linkage]], and since
 function pointers with different the language linkage specifications
 (7.5 [dcl.link]) are incompatible, whether this example is
 well-formed is unspecified.
@@ -12753,7 +13266,7 @@ well-formed is unspecified.
 
 
 
      Proposed resolution:
      
-
      Change 20.6.7 [comparisons] paragraph 6 from:
      
+
      Change 20.7.8 [comparisons] paragraph 6 from:
      
 
      
   
      [Example:
      
   
          replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++");
@@ -12792,12 +13305,12 @@ it corresponds to the new code fragment.]
      
 
 
      
 
      285. minor editorial errors in fstream ctors
      
-
      Section: 27.8.1.7 [ifstream.cons] Status: WP
- Submitter: Martin Sebor Date: 2000-12-31
      
-
      View all issues with WP status.
      
+
      Section: 27.9.1.7 [ifstream.cons] Status: CD1
+ Submitter: Martin Sebor Opened: 2000-12-31  Last modified: 2008-09-26
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
-
      27.8.1.7 [ifstream.cons], p2, 27.8.1.11 [ofstream.cons], p2, and
-27.8.1.15 [fstream.cons], p2 say about the effects of each constructor:
+
      27.9.1.7 [ifstream.cons], p2, 27.9.1.11 [ofstream.cons], p2, and
+27.9.1.15 [fstream.cons], p2 say about the effects of each constructor:
 
      
 
 
      ... If that function returns a null pointer, calls
@@ -12805,7 +13318,7 @@ it corresponds to the new code fragment.]
      
 
      
 
 
      The parenthetical note doesn't apply since the ctors cannot throw an
-exception due to the requirement in 27.4.4.1 [basic.ios.cons], p3 
+exception due to the requirement in 27.5.4.1 [basic.ios.cons], p3 
 that exceptions() be initialized to ios_base::goodbit.
 
      
 
@@ -12821,10 +13334,10 @@ paragraphs mentioned above.
 
 
      
 
      286. <cstdlib> requirements missing size_t typedef
      
-
      Section: 25.4 [alg.c.library] Status: WP
- Submitter: Judy Ward Date: 2000-12-30
      
+
      Section: 25.6 [alg.c.library] Status: CD1
+ Submitter: Judy Ward Opened: 2000-12-30  Last modified: 2008-09-26
      
 
      View all other issues in [alg.c.library].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 The <cstdlib> header file contains prototypes for bsearch and
@@ -12851,9 +13364,9 @@ the type size_t <cstdlib> to Table 97 (section C.2).
 
 
      
 
      288. <cerrno> requirements missing macro EILSEQ
      
-
      Section: 19.3 [errno] Status: WP
- Submitter: Judy Ward Date: 2000-12-30
      
-
      View all issues with WP status.
      
+
      Section: 19.4 [errno] Status: CD1
+ Submitter: Judy Ward Opened: 2000-12-30  Last modified: 2008-09-26
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 ISO/IEC 9899:1990/Amendment1:1994 Section 4.3 States: "The list
@@ -12880,10 +13393,10 @@ and Table 95 (section C.2) "Standard Macros" to include EILSEQ.
 
 
      
 
      291. Underspecification of set algorithms
      
-
      Section: 25.3.5 [alg.set.operations] Status: WP
- Submitter: Matt Austern Date: 2001-01-03
      
+
      Section: 25.5.5 [alg.set.operations] Status: CD1
+ Submitter: Matt Austern Opened: 2001-01-03  Last modified: 2008-09-26
      
 
      View all other issues in [alg.set.operations].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 The standard library contains four algorithms that compute set
@@ -12937,7 +13450,7 @@ same way.
 
 
      Proposed resolution:
      
 
-
      Add the following to the end of 25.3.5.2 [set.union] paragraph 5:
      
+
      Add the following to the end of 25.5.5.2 [set.union] paragraph 5:
      
 
      
 If [first1, last1) contains m elements that are equivalent to
 each other and [first2, last2) contains n elements that are
@@ -12947,7 +13460,7 @@ from [first1, last1), and the last max(n-m, 0) of them from
 [first2, last2), in that order.
 
      
 
-
      Add the following to the end of 25.3.5.3 [set.intersection] paragraph 5:
      
+
      Add the following to the end of 25.5.5.3 [set.intersection] paragraph 5:
      
 
      
 If [first1, last1) contains m elements that are equivalent to each
 other and [first2, last2) contains n elements that are
@@ -12955,7 +13468,7 @@ equivalent to them, the first min(m, n) of those
 elements from [first1, last1) are copied to the output range.
 
      
 
-
      Add a new paragraph, Notes, after 25.3.5.4 [set.difference]
+
      Add a new paragraph, Notes, after 25.5.5.4 [set.difference]
 paragraph 4:
      
 
      
 If [first1, last1) contains m elements that are equivalent to each
@@ -12964,7 +13477,7 @@ equivalent to them, the last max(m-n, 0) elements from
 [first1, last1) are copied to the output range.
 
      
 
-
      Add a new paragraph, Notes, after 25.3.5.5 [set.symmetric.difference]
+
      Add a new paragraph, Notes, after 25.5.5.5 [set.symmetric.difference]
 paragraph 4:
      
 
      
 If [first1, last1) contains m elements that are equivalent to
@@ -12996,11 +13509,11 @@ m of these elements from [first2, last2) if m < n.
 
 
      
 
      292. effects of a.copyfmt (a)
      
-
      Section: 27.4.4.2 [basic.ios.members] Status: WP
- Submitter: Martin Sebor Date: 2001-01-05
      
+
      Section: 27.5.4.2 [basic.ios.members] Status: CD1
+ Submitter: Martin Sebor Opened: 2001-01-05  Last modified: 2008-09-26
      
 
      View other active issues in [basic.ios.members].
      
 
      View all other issues in [basic.ios.members].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      The Effects clause of the member function copyfmt() in
 27.4.4.2, p15 doesn't consider the case where the left-hand side
@@ -13036,11 +13549,11 @@ objects of rhs, except that...
 
 
      
 
      294. User defined macros and standard headers
      
-
      Section: 17.4.3.2.1 [macro.names] Status: WP
- Submitter: James Kanze Date: 2001-01-11
      
-
      View all issues with WP status.
      
+
      Section: 17.6.3.3.1 [macro.names] Status: CD1
+ Submitter: James Kanze Opened: 2001-01-11  Last modified: 2008-09-26
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
-
      Paragraph 2 of 17.4.3.2.1 [macro.names] reads: "A
+
      Paragraph 2 of 17.6.3.3.1 [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:
      
@@ -13056,12 +13569,12 @@ 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 [res.on.headers] paragraph 1, however,
+example.  In light of 17.6.4.2 [res.on.headers] paragraph 1, however,
 it isn't stringent enough.
      
 
 
 
      Proposed resolution:
      
-
      For 17.4.3.2.1 [macro.names], replace the current wording, which reads:
      
+
      For 17.6.3.3.1 [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
@@ -13095,10 +13608,10 @@ it isn't stringent enough.
      
 
 
      
 
      295. Is abs defined in <cmath>?
      
-
      Section: 26.7 [c.math] Status: WP
- Submitter: Jens Maurer Date: 2001-01-12
      
+
      Section: 26.8 [c.math] Status: CD1
+ Submitter: Jens Maurer Opened: 2001-01-12  Last modified: 2008-09-26
      
 
      View all other issues in [c.math].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 Table 80 lists the contents of the <cmath> header.  It does not
@@ -13111,7 +13624,7 @@ of abs() should be defined in <cmath>.
 
      Proposed resolution:
      
 
      
 Add abs to Table 80.  Also, remove the parenthetical list
-of functions "(abs(), div(), rand(), srand())" from 26.5 [numarray],
+of functions "(abs(), div(), rand(), srand())" from 26.6 [numarray],
 paragraph 1.
 
      
 
@@ -13133,9 +13646,9 @@ putting in <cstdlib>.  That's issue 297. const_mem_fun_t<>::argument_type should be const T*
-
      Section: 20.6.8 [logical.operations] Status: WP
- Submitter: Martin Sebor Date: 2001-01-06
      
-
      View all issues with WP status.
      
+
      Section: 20.7.9 [logical.operations] Status: CD1
+ Submitter: Martin Sebor Opened: 2001-01-06  Last modified: 2008-09-26
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      The class templates const_mem_fun_t in 20.5.8, p8 and
 const_mem_fun1_t
@@ -13216,9 +13729,9 @@ and the argument type itself, are not the same.
      
 
 
      
 
      298. ::operator delete[] requirement incorrect/insufficient
      
-
      Section: 18.5.1.2 [new.delete.array] Status: WP
- Submitter: John A. Pedretti Date: 2001-01-10
      
-
      View all issues with WP status.
      
+
      Section: 18.6.1.2 [new.delete.array] Status: CD1
+ Submitter: John A. Pedretti Opened: 2001-01-10  Last modified: 2008-09-26
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 The default behavior of operator delete[] described in 18.5.1.2, p12 -
@@ -13244,7 +13757,7 @@ For a null value of ptr , does nothing.
 Any other value of ptr shall be a value returned
 earlier by a call to the default operator new[](std::size_t).
 [Footnote: The value must not have been invalidated by an intervening
-call to operator delete[](void*) (17.4.3.8 [res.on.arguments]).
+call to operator delete[](void*) (17.6.3.9 [res.on.arguments]).
 --- end footnote]
 For such a non-null value of ptr , reclaims storage
 allocated by the earlier call to the default operator new[].
@@ -13266,13 +13779,13 @@ or operator delete(ptr, std::nothrow) respectively.
 
 
      
 
      300. list::merge() specification incomplete
      
-
      Section: 23.2.4.4 [list.ops] Status: WP
- Submitter: John Pedretti Date: 2001-01-23
      
+
      Section: 23.3.4.4 [list.ops] Status: CD1
+ Submitter: John Pedretti Opened: 2001-01-23  Last modified: 2008-09-26
      
 
      View all other issues in [list.ops].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
-The "Effects" clause for list::merge() (23.2.4.4 [list.ops], p23)
+The "Effects" clause for list::merge() (23.3.4.4 [list.ops], p23)
 appears to be incomplete: it doesn't cover the case where the argument
 list is identical to *this (i.e., this == &x). The requirement in the
 note in p24 (below) is that x be empty after the merge which is surely
@@ -13281,7 +13794,7 @@ unintended in this case.
 
 
 
      Proposed resolution:
      
-
      In 23.2.4.4 [list.ops], replace paragraps 23-25 with:
      
+
      In 23.3.4.4 [list.ops], replace paragraps 23-25 with:
      
 
      
 
      
 23 Effects: if (&x == this) does nothing; otherwise, merges the two
@@ -13310,7 +13823,7 @@ effects.
 
      
 
 
      [Copenhagen: The original proposed resolution did not fix all of
-the problems in 23.2.4.4 [list.ops], p22-25.  Three different
+the problems in 23.3.4.4 [list.ops], p22-25.  Three different
 paragraphs (23, 24, 25) describe the effects of merge.
 Changing p23, without changing the other two, appears to introduce
 contradictions.  Additionally, "merges the argument list into the
@@ -13327,10 +13840,11 @@ list" is excessively vague.]
      
 
 
      
 
      301. basic_string template ctor effects clause omits allocator argument
      
-
      Section: 21.3.1 [string.require] Status: WP
- Submitter: Martin Sebor Date: 2001-01-27
      
+
      Section: 21.4.1 [string.require] Status: CD1
+ Submitter: Martin Sebor Opened: 2001-01-27  Last modified: 2008-09-26
      
+
      View other active issues in [string.require].
      
 
      View all other issues in [string.require].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 The effects clause for the basic_string template ctor in 21.3.1, p15
@@ -13365,9 +13879,9 @@ a mistake.
 
 
      
 
      303. Bitset input operator underspecified
      
-
      Section: 23.3.5.3 [bitset.operators] Status: WP
- Submitter: Matt Austern Date: 2001-02-05
      
-
      View all issues with WP status.
      
+
      Section: 20.3.6.3 [bitset.operators] Status: CD1
+ Submitter: Matt Austern Opened: 2001-02-05  Last modified: 2008-09-26
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 In 23.3.5.3, we are told that bitset's input operator
@@ -13484,10 +13998,10 @@ consequence of the design choice.
      
 
 
      
 
      305. Default behavior of codecvt<wchar_t, char, mbstate_t>::length()
      
-
      Section: 22.2.1.5 [locale.codecvt.byname] Status: WP
- Submitter: Howard Hinnant Date: 2001-01-24
      
+
      Section: 22.4.1.5 [locale.codecvt.byname] Status: CD1
+ Submitter: Howard Hinnant Opened: 2001-01-24  Last modified: 2008-09-26
      
 
      View all other issues in [locale.codecvt.byname].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      22.2.1.5/3 introduces codecvt in part with:
      
 
@@ -13612,10 +14126,10 @@ example, and it would rule out a fixed-width encoding of UCS-4.
      
 
 
      
 
      306. offsetof macro and non-POD types
      
-
      Section: 18.1 [support.types] Status: WP
- Submitter: Steve Clamage Date: 2001-02-21
      
+
      Section: 18.2 [support.types] Status: CD1
+ Submitter: Steve Clamage Opened: 2001-02-21  Last modified: 2008-09-26
      
 
      View all other issues in [support.types].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
       
 
      Spliced together from reflector messages c++std-lib-8294 and -8295:
      
 
@@ -13650,16 +14164,16 @@ possible.]
      
 
 
      
 
      307. Lack of reference typedefs in container adaptors
      
-
      Section: 23.2.4 [list] Status: WP
- Submitter: Howard Hinnant Date: 2001-03-13
      
-
      View all issues with WP status.
      
+
      Section: 23.3.4 [list] Status: CD1
+ Submitter: Howard Hinnant Opened: 2001-03-13  Last modified: 2008-09-26
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
 
      From reflector message c++std-lib-8330.  See also lib-8317.
      
 
 
      
-The standard is currently inconsistent in 23.2.4.2 [list.capacity]
-paragraph 1 and 23.2.4.3 [list.modifiers] paragraph 1.
+The standard is currently inconsistent in 23.3.4.2 [list.capacity]
+paragraph 1 and 23.3.4.3 [list.modifiers] paragraph 1.
 23.2.3.3/1, for example, says:
 
      
 
@@ -13922,18 +14436,19 @@ and it was deliberately not adopted.  Nevertheless, the LWG believes
 
 
      
 
      308. Table 82 mentions unrelated headers
      
-
      Section: 27 [input.output] Status: WP
- Submitter: Martin Sebor Date: 2001-03-15
      
+
      Section: 27 [input.output] Status: CD1
+ Submitter: Martin Sebor Opened: 2001-03-15  Last modified: 2008-09-26
      
+
      View other active issues in [input.output].
      
 
      View all other issues in [input.output].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 Table 82 in section 27 mentions the header <cstdlib> for String
-streams (27.7 [string.streams]) and the headers <cstdio> and
-<cwchar> for File streams (27.8 [file.streams]). It's not clear
+streams (27.8 [string.streams]) and the headers <cstdio> and
+<cwchar> for File streams (27.9 [file.streams]). It's not clear
 why these headers are mentioned in this context since they do not
 define any of the library entities described by the
-subclauses. According to 17.4.1.1 [contents], only such headers
+subclauses. According to 17.6.1.1 [contents], only such headers
 are to be listed in the summary.
 
      
 
@@ -13945,7 +14460,7 @@ Table 82.
      
 
      [Copenhagen: changed the proposed resolution slightly.  The
 original proposed resolution also said to remove <cstdio> from
 Table 82.  However, <cstdio> is mentioned several times within
-section 27.8 [file.streams], including 27.8.2 [c.files].]
      
+section 27.9 [file.streams], including 27.9.2 [c.files].]
      
 
 
 
@@ -13954,10 +14469,10 @@ section 27.8 [file.streams], including 27.8.2 [c.files].]
      
 
 
      
 
      310. Is errno a macro?
      
-
      Section: 17.4.1.2 [headers], 19.3 [errno] Status: WP
- Submitter: Steve Clamage Date: 2001-03-21
      
+
      Section: 17.6.1.2 [headers], 19.4 [errno] Status: CD1
+ Submitter: Steve Clamage Opened: 2001-03-21  Last modified: 2008-09-26
      
 
      View all other issues in [headers].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
   
      
   Exactly how should errno be declared in a conforming C++ header?
@@ -14057,13 +14572,13 @@ to be a macro.
      
 
 
      
 
      311. Incorrect wording in basic_ostream class synopsis
      
-
      Section: 27.6.2.1 [ostream] Status: WP
- Submitter: Andy Sawyer Date: 2001-03-21
      
+
      Section: 27.7.2.1 [ostream] Status: CD1
+ Submitter: Andy Sawyer Opened: 2001-03-21  Last modified: 2008-09-26
      
 
      View all other issues in [ostream].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
-
      In 27.6.2.1 [ostream], the synopsis of class basic_ostream says:
      
+
      In 27.7.2.1 [ostream], the synopsis of class basic_ostream says:
      
 
 
        // partial specializationss
   template<class traits>
@@ -14080,14 +14595,14 @@ to be a macro.
      
 
 
 
      Proposed resolution:
      
-
      In the synopsis in 27.6.2.1 [ostream], remove the 
+
      In the synopsis in 27.7.2.1 [ostream], remove the 
 // partial specializationss comment.  Also remove the same 
 comment (correctly spelled, but still incorrect) from the synopsis in 
-27.6.2.6.4 [ostream.inserters.character].
+27.7.2.6.4 [ostream.inserters.character].
 
      
 
 
      [
-Pre-Redmond: added 27.6.2.6.4 [ostream.inserters.character] because of Martin's
+Pre-Redmond: added 27.7.2.6.4 [ostream.inserters.character] because of Martin's
 comment in c++std-lib-8939.
 ]
      
 
@@ -14099,13 +14614,14 @@ comment in c++std-lib-8939.
 
 
      
 
      312. Table 27 is missing headers
      
-
      Section: 20 [utilities] Status: WP
- Submitter: Martin Sebor Date: 2001-03-29
      
-
      View all issues with WP status.
      
+
      Section: 20 [utilities] Status: CD1
+ Submitter: Martin Sebor Opened: 2001-03-29  Last modified: 2008-09-26
      
+
      View all other issues in [utilities].
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      Table 27 in section 20 lists the header <memory> (only) for
 Memory (lib.memory) but neglects to mention the headers
-<cstdlib> and <cstring> that are discussed in 20.5.5 [meta.rel].
      
+<cstdlib> and <cstring> that are discussed in 20.6.5 [meta.rel].
      
 
 
 
      Proposed resolution:
      
@@ -14118,13 +14634,13 @@ as <memory>.
      
 
 
      
 
      315. Bad "range" in list::unique complexity
      
-
      Section: 23.2.4.4 [list.ops] Status: WP
- Submitter: Andy Sawyer Date: 2001-05-01
      
+
      Section: 23.3.4.4 [list.ops] Status: CD1
+ Submitter: Andy Sawyer Opened: 2001-05-01  Last modified: 2008-09-26
      
 
      View all other issues in [list.ops].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
-23.2.4.4 [list.ops], Para 21 describes the complexity of
+23.3.4.4 [list.ops], Para 21 describes the complexity of
 list::unique as: "If the range (last - first) is not empty, exactly
 (last - first) -1 applications of the corresponding predicate,
 otherwise no applications of the predicate)".
@@ -14145,10 +14661,11 @@ Change the "range" from (last - first) to [first, last).
 
 
      
 
      316. Vague text in Table 69
      
-
      Section: 23.1.4 [associative.reqmts] Status: WP
- Submitter: Martin Sebor Date: 2001-05-04
      
+
      Section: 23.2.4 [associative.reqmts] Status: CD1
+ Submitter: Martin Sebor Opened: 2001-05-04  Last modified: 2008-09-26
      
+
      View other active issues in [associative.reqmts].
      
 
      View all other issues in [associative.reqmts].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      Table 69 says this about a_uniq.insert(t):
      
 
@@ -14177,10 +14694,11 @@ takes place...
 
 
      
 
      317. Instantiation vs. specialization of facets
      
-
      Section: 22 [localization] Status: WP
- Submitter: Martin Sebor Date: 2001-05-04
      
+
      Section: 22 [localization] Status: CD1
+ Submitter: Martin Sebor Opened: 2001-05-04  Last modified: 2008-09-26
      
+
      View other active issues in [localization].
      
 
      View all other issues in [localization].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 The localization section of the standard refers to specializations of
@@ -14243,9 +14761,9 @@ change.
      
 
 
      
 
      318. Misleading comment in definition of numpunct_byname
      
-
      Section: 22.2.3.2 [locale.numpunct.byname] Status: WP
- Submitter: Martin Sebor Date: 2001-05-12
      
-
      View all issues with WP status.
      
+
      Section: 22.4.3.2 [locale.numpunct.byname] Status: CD1
+ Submitter: Martin Sebor Opened: 2001-05-12  Last modified: 2008-09-26
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      The definition of the numpunct_byname template contains the following
 comment:
      
@@ -14271,16 +14789,16 @@ resolution of library issue 319. Storage allocation wording confuses "Required behavior", "Requires"
-
      Section: 18.5.1.1 [new.delete.single], 18.5.1.2 [new.delete.array] Status: WP
- Submitter: Beman Dawes Date: 2001-05-15
      
+
      Section: 18.6.1.1 [new.delete.single], 18.6.1.2 [new.delete.array] Status: CD1
+ Submitter: Beman Dawes Opened: 2001-05-15  Last modified: 2008-09-26
      
 
      View all other issues in [new.delete.single].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
-
      The standard specifies 17.3.1.3 [structure.specifications] that "Required
+
      The standard specifies 17.5.1.4 [structure.specifications] that "Required
 behavior" elements describe "the semantics of a function definition
 provided by either the implementation or a C++ program."
      
 
-
      The standard specifies 17.3.1.3 [structure.specifications] that "Requires"
+
      The standard specifies 17.5.1.4 [structure.specifications] that "Requires"
 elements describe "the preconditions for calling the function."
      
 
 
      In the sections noted below, the current wording specifies
@@ -14291,7 +14809,7 @@ should be specified as "Requires".
      
 
 
      Proposed resolution:
      
 
-
      In 18.5.1.1 [new.delete.single] Para 12 Change:
      
+
      In 18.6.1.1 [new.delete.single] Para 12 Change:
      
 
      
   
      Required behavior: accept a value of ptr that is null or that was
   returned by an earlier call ...
      
@@ -14302,7 +14820,7 @@ should be specified as "Requires".
      
   earlier call ...
      
 
      
 
-
      In 18.5.1.2 [new.delete.array] Para 11 Change:
      
+
      In 18.6.1.2 [new.delete.array] Para 11 Change:
      
 
      
   
      Required behavior: accept a value of ptr that is null or that was
   returned by an earlier call ...
      
@@ -14319,13 +14837,13 @@ should be specified as "Requires".
      
 
 
      
 
      320. list::assign overspecified
      
-
      Section: 23.2.4.1 [list.cons] Status: WP
- Submitter: Howard Hinnant Date: 2001-05-17
      
+
      Section: 23.3.4.1 [list.cons] Status: CD1
+ Submitter: Howard Hinnant Opened: 2001-05-17  Last modified: 2008-09-26
      
 
      View all other issues in [list.cons].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
-Section 23.2.4.1 [list.cons], paragraphs 6-8 specify that list assign (both forms) have
+Section 23.3.4.1 [list.cons], paragraphs 6-8 specify that list assign (both forms) have
 the "effects" of a call to erase followed by a call to insert.
 
      
 
@@ -14351,7 +14869,7 @@ Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't.
 
 
 
      Proposed resolution:
      
-
      Change 23.2.4.1 [list.cons]/7 from:
      
+
      Change 23.3.4.1 [list.cons]/7 from:
      
 
 
      
 
      Effects:
      
@@ -14367,7 +14885,7 @@ Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't.
 
      Effects: Replaces the contents of the list with the range [first, last).
      
 
      
 
-
      In 23.1.3 [sequence.reqmts], in Table 67 (sequence requirements), 
+
      In 23.2.3 [sequence.reqmts], in Table 67 (sequence requirements), 
 add two new rows:
      
 
            a.assign(i,j)     void      pre: i,j are not iterators into a.
                                   Replaces elements in a with a copy
@@ -14378,7 +14896,7 @@ add two new rows:
      
                                   of t.
 
      
 
-
      Change 23.2.4.1 [list.cons]/8 from:
      
+
      Change 23.3.4.1 [list.cons]/8 from:
      
 
 
      
 
      Effects:
      
@@ -14416,11 +14934,11 @@ Changes not deemed serious enough to requre rereview.]
      
 
 
      
 
      321. Typo in num_get
      
-
      Section: 22.2.2.1.2 [facet.num.get.virtuals] Status: WP
- Submitter: Kevin Djang Date: 2001-05-17
      
+
      Section: 22.4.2.1.2 [facet.num.get.virtuals] Status: CD1
+ Submitter: Kevin Djang Opened: 2001-05-17  Last modified: 2008-09-26
      
 
      View other active issues in [facet.num.get.virtuals].
      
 
      View all other issues in [facet.num.get.virtuals].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 Section 22.2.2.1.2 at p7 states that "A length specifier is added to
@@ -14447,11 +14965,11 @@ to be "A length modifier is added ..."
 
 
      
 
      322. iterator and const_iterator should have the same value type
      
-
      Section: 23.1 [container.requirements] Status: WP
- Submitter: Matt Austern Date: 2001-05-17
      
+
      Section: 23.2 [container.requirements] Status: CD1
+ Submitter: Matt Austern Opened: 2001-05-17  Last modified: 2008-09-26
      
 
      View other active issues in [container.requirements].
      
 
      View all other issues in [container.requirements].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 It's widely assumed that, if X is a container,
@@ -14494,10 +15012,10 @@ requires that iterator_traits<const int*>::value_type is int.
 
 
      
 
      324. Do output iterators have value types?
      
-
      Section: 24.1.2 [output.iterators] Status: WP
- Submitter: Dave Abrahams Date: 2001-06-07
      
+
      Section: 24.2.3 [output.iterators] Status: CD1
+ Submitter: Dave Abrahams Opened: 2001-06-07  Last modified: 2008-09-26
      
 
      View all other issues in [output.iterators].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
 
      Table 73 suggests that output iterators have value types.  It 
@@ -14627,10 +15145,10 @@ decision.
      
 
 
      
 
      325. Misleading text in moneypunct<>::do_grouping
      
-
      Section: 22.2.6.3.2 [locale.moneypunct.virtuals] Status: WP
- Submitter: Martin Sebor Date: 2001-07-02
      
+
      Section: 22.4.6.3.2 [locale.moneypunct.virtuals] Status: CD1
+ Submitter: Martin Sebor Opened: 2001-07-02  Last modified: 2008-09-26
      
 
      View all other issues in [locale.moneypunct.virtuals].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      The Returns clause in 22.2.6.3.2, p3 says about
 moneypunct<charT>::do_grouping()
@@ -14692,10 +15210,10 @@ integers, not ASCII characters.
 
 
      
 
      327. Typo in time_get facet in table 52
      
-
      Section: 22.1.1.1.1 [locale.category] Status: WP
- Submitter: Tiki Wan Date: 2001-07-06
      
+
      Section: 22.3.1.1.1 [locale.category] Status: CD1
+ Submitter: Tiki Wan Opened: 2001-07-06  Last modified: 2008-09-26
      
 
      View all other issues in [locale.category].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Duplicate of: 447
      
 
      Discussion:
      
 
      The wchar_t versions of time_get and
@@ -14708,7 +15226,7 @@ InputIterator, since these are input facets.
      
 
      Proposed resolution:
      
 
      
 In table 52, required instantiations, in 
-22.1.1.1.1 [locale.category], change
      
+22.3.1.1.1 [locale.category], change
      
 
          time_get<wchar_t, OutputIterator>
     time_get_byname<wchar_t, OutputIterator>
 
      
@@ -14727,9 +15245,9 @@ a typo, wchart instead of wchar_t.]
      
 
 
      
 
      328. Bad sprintf format modifier in money_put<>::do_put()
      
-
      Section: 22.2.6.2.2 [locale.money.put.virtuals] Status: WP
- Submitter: Martin Sebor Date: 2001-07-07
      
-
      View all issues with WP status.
      
+
      Section: 22.4.6.2.2 [locale.money.put.virtuals] Status: CD1
+ Submitter: Martin Sebor Opened: 2001-07-07  Last modified: 2008-09-26
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      The sprintf format string , "%.01f" (that's the digit one), in the
 description of the do_put() member functions of the money_put facet in
@@ -14751,18 +15269,18 @@ modifier.
      
 
 
      
 
      329. vector capacity, reserve and reallocation
      
-
      Section: 23.2.6.2 [vector.capacity], 23.2.6.4 [vector.modifiers] Status: WP
- Submitter: Anthony Williams Date: 2001-07-13
      
+
      Section: 23.3.6.2 [vector.capacity], 23.3.6.4 [vector.modifiers] Status: CD1
+ Submitter: Anthony Williams Opened: 2001-07-13  Last modified: 2008-09-26
      
 
      View all other issues in [vector.capacity].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 There is an apparent contradiction about which circumstances can cause
-a reallocation of a vector in Section 23.2.6.2 [vector.capacity] and
-section 23.2.6.4 [vector.modifiers].
+a reallocation of a vector in Section 23.3.6.2 [vector.capacity] and
+section 23.3.6.4 [vector.modifiers].
 
      
 
-
      23.2.6.2 [vector.capacity],p5 says:
      
+
      23.3.6.2 [vector.capacity],p5 says:
      
 
      
 Notes: Reallocation invalidates all the references, pointers, and iterators
 referring to the elements in the sequence. It is guaranteed that no
@@ -14782,7 +15300,7 @@ greater than the size specified in the most recent call to reserve().
 
      then the implementation may reallocate the vector for the insert,
 as the size specified in the previous call to reserve was zero.
      
 
-
      However, the previous paragraphs (23.2.6.2 [vector.capacity], p1-2) state:
      
+
      However, the previous paragraphs (23.3.6.2 [vector.capacity], p1-2) state:
      
 
      
 
      
 (capacity) Returns: The total number of elements the vector
@@ -14798,7 +15316,7 @@ of capacity() otherwise...
 
      
 This implies that vec.capacity() is still 23, and so the insert()
 should not require a reallocation, as vec.size() is 0. This is backed
-up by 23.2.6.4 [vector.modifiers], p1:
+up by 23.3.6.4 [vector.modifiers], p1:
 
      
 
      
 (insert) Notes: Causes reallocation if the new size is greater than the old
@@ -14813,7 +15331,7 @@ than the old capacity, I think the intent is clear.
 
 
 
      Proposed resolution:
      
-
      Change the wording of 23.2.6.2 [vector.capacity] paragraph 5 to:
      
+
      Change the wording of 23.3.6.2 [vector.capacity] paragraph 5 to:
      
 
 
      
 Notes: Reallocation invalidates all the references, pointers, and
@@ -14846,13 +15364,13 @@ reallocation guarantees was inadvertant.
      
 
 
      
 
      331. bad declaration of destructor for ios_base::failure
      
-
      Section: 27.4.2.1.1 [ios::failure] Status: WP
- Submitter: PremAnand M. Rao Date: 2001-08-23
      
+
      Section: 27.5.2.1.1 [ios::failure] Status: CD1
+ Submitter: PremAnand M. Rao Opened: 2001-08-23  Last modified: 2008-09-26
      
 
      View all other issues in [ios::failure].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
-With the change in 17.4.4.9 [res.on.exception.handling] to state
+With the change in 17.6.4.10 [res.on.exception.handling] to state
    "An implementation may strengthen the exception-specification for a 
     non-virtual function by removing listed exceptions."
 (issue 119)
@@ -14867,7 +15385,7 @@ and the following declaration of ~failure() in ios_base::failure
        };
      }
 
      
-
      the class failure cannot be implemented since in 18.6.1 [type.info] the destructor of class exception has an empty
+
      the class failure cannot be implemented since in 18.7.1 [type.info] the destructor of class exception has an empty
 exception specification:
      
 
          namespace std {
        class exception {
@@ -14896,11 +15414,11 @@ of other classes derived from exception are handled.
      
 
 
      
 
      333. does endl imply synchronization with the device?
      
-
      Section: 27.6.2.8 [ostream.manip] Status: WP
- Submitter: PremAnand M. Rao Date: 2001-08-27
      
-
      View all issues with WP status.
      
+
      Section: 27.7.2.8 [ostream.manip] Status: CD1
+ Submitter: PremAnand M. Rao Opened: 2001-08-27  Last modified: 2008-09-26
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
-
      A footnote in 27.6.2.8 [ostream.manip] states:
      
+
      A footnote in 27.7.2.8 [ostream.manip] states:
      
 
      
     [Footnote: The effect of executing cout << endl is to insert a 
      newline character in the output sequence controlled by cout, then 
@@ -14927,7 +15445,7 @@ the behavior one way or the other.
 
 
 
      Proposed resolution:
      
-
      Remove footnote 300 from section 27.6.2.8 [ostream.manip].
      
+
      Remove footnote 300 from section 27.7.2.8 [ostream.manip].
      
 
 
 
      Rationale:
      
@@ -14945,10 +15463,10 @@ does.
      
 
 
      
 
      334. map::operator[] specification forces inefficient implementation
      
-
      Section: 23.3.1.2 [map.access] Status: WP
- Submitter: Andrea Griffini Date: 2001-09-02
      
+
      Section: 23.4.1.2 [map.access] Status: CD1
+ Submitter: Andrea Griffini Opened: 2001-09-02  Last modified: 2008-09-26
      
 
      View all other issues in [map.access].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 The current standard describes map::operator[] using a
@@ -15028,7 +15546,7 @@ non-conforming.
 
      Proposed resolution:
      
 
 
      
-Replace 23.3.1.2 [map.access] paragraph 1 with
+Replace 23.4.1.2 [map.access] paragraph 1 with
 
      
 
      
 
      
@@ -15068,12 +15586,12 @@ we are no longer defining operator[] in terms of
 
 
      
 
      335. minor issue with char_traits, table 37
      
-
      Section: 21.1.1 [char.traits.require] Status: WP
- Submitter: Andy Sawyer Date: 2001-09-06
      
-
      View all issues with WP status.
      
+
      Section: 21.2.1 [char.traits.require] Status: CD1
+ Submitter: Andy Sawyer Opened: 2001-09-06  Last modified: 2008-09-26
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
-Table 37, in 21.1.1 [char.traits.require], descibes char_traits::assign
+Table 37, in 21.2.1 [char.traits.require], descibes char_traits::assign
 as:
 
      
 
        X::assign(c,d)   assigns c = d.
@@ -15118,14 +15636,15 @@ and char_traits<wchar_t> in 21.1.3.2...)
 
 
      
 
      336. Clause 17 lack of references to deprecated headers
      
-
      Section: 17 [library] Status: WP
- Submitter: Detlef Vollmann Date: 2001-09-05
      
+
      Section: 17 [library] Status: CD1
+ Submitter: Detlef Vollmann Opened: 2001-09-05  Last modified: 2008-09-26
      
+
      View other active issues in [library].
      
 
      View all other issues in [library].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      From c++std-edit-873:
      
 
-
      17.4.1.2 [headers], Table 11.  In this table, the header
+
      17.6.1.2 [headers], Table 11.  In this table, the header
 <strstream> is missing.
      
 
 
      This shows a general problem: The whole clause 17 refers quite
@@ -15136,7 +15655,7 @@ library (though a deprecated one).
      
 
 
      Proposed resolution:
      
 
-
      To 17.4.1.2 [headers] Table 11, C++ Library Headers, add
+
      To 17.6.1.2 [headers] Table 11, C++ Library Headers, add
 "<strstream>".
      
 
 
      In the following places, change "clauses 17 through 27" to "clauses
@@ -15146,15 +15665,15 @@ library (though a deprecated one).
      
 
    • 1.2 [intro.refs] Normative references/1/footnote 1
      • 
 
    • 1.3 [intro.defs] Definitions/1
      • 
 
    • 7 [dcl.dcl] Library introduction/9
      • 
-
    • 17.3 [description] Method of description (Informative)/1
      • 
-
    • 17.3.2.1.3 [character.seq] Character sequences/1/bullet 2
      • 
-
    • 17.3.2.2 [functions.within.classes] Functions within classes/1
      • 
-
    • 17.3.2.3 [objects.within.classes] Private members/1/(2 places)
      • 
-
    • 17.4 [requirements] Library-wide requirements/1
      • 
-
    • 17.4.1.2 [headers] Headers/4
      • 
-
    • 17.4.3.5 [replacement.functions] Replacement functions/1
      • 
-
    • 17.4.4.3 [global.functions] Global or non-member functions/2
      • 
-
    • 17.4.4.7 [protection.within.classes] Protection within classes/1
      • 
+
    • 17.5 [description] Method of description (Informative)/1
      • 
+
    • 17.5.2.1.4 [character.seq] Character sequences/1/bullet 2
      • 
+
    • 17.5.2.2 [functions.within.classes] Functions within classes/1
      • 
+
    • 17.5.2.3 [objects.within.classes] Private members/1/(2 places)
      • 
+
    • 17.6 [requirements] Library-wide requirements/1
      • 
+
    • 17.6.1.2 [headers] Headers/4
      • 
+
    • 17.6.3.6 [replacement.functions] Replacement functions/1
      • 
+
    • 17.6.4.4 [global.functions] Global or non-member functions/2
      • 
+
    • 17.6.4.8 [protection.within.classes] Protection within classes/1
      • 
 
    
 
 
@@ -15165,17 +15684,18 @@ library (though a deprecated one).
    
 
 
    
 
    337. replace_copy_if's template parameter should be InputIterator
    
-
    Section: 25.2.5 [alg.replace] Status: WP
- Submitter: Detlef Vollmann Date: 2001-09-07
    
+
    Section: 25.4.5 [alg.replace] Status: CD1
+ Submitter: Detlef Vollmann Opened: 2001-09-07  Last modified: 2008-09-26
    
+
    View other active issues in [alg.replace].
    
 
    View all other issues in [alg.replace].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    From c++std-edit-876:
    
 
 
    
-In section 25.2.5 [alg.replace] before p4: The name of the first
+In section 25.4.5 [alg.replace] before p4: The name of the first
 parameter of template replace_copy_if should be "InputIterator"
-instead of "Iterator".  According to 17.3.2.1 [type.descriptions] p1 the
+instead of "Iterator".  According to 17.5.2.1 [type.descriptions] p1 the
 parameter name conveys real normative meaning.
 
    
 
@@ -15189,17 +15709,17 @@ parameter name conveys real normative meaning.
 
 
    
 
    338.  is whitespace allowed between `-' and a digit?
    
-
    Section: 22.2 [locale.categories] Status: WP
- Submitter: Martin Sebor Date: 2001-09-17
    
+
    Section: 22.4 [locale.categories] Status: CD1
+ Submitter: Martin Sebor Opened: 2001-09-17  Last modified: 2008-09-26
    
 
    View other active issues in [locale.categories].
    
 
    View all other issues in [locale.categories].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-From Stage 2 processing in 22.2.2.1.2 [facet.num.get.virtuals], p8 and 9 (the
+From Stage 2 processing in 22.4.2.1.2 [facet.num.get.virtuals], p8 and 9 (the
 original text or the text corrected by the proposed resolution of
 issue 221) it seems clear that no whitespace is allowed
-within a number, but 22.2.3.1 [locale.numpunct], p2, which gives the
+within a number, but 22.4.3.1 [locale.numpunct], p2, which gives the
 format for integer and floating point values, says that whitespace is
 optional between a plusminus and a sign.
 
    
@@ -15209,14 +15729,14 @@ The text needs to be clarified to either consistently allow or
 disallow whitespace between a plusminus and a sign. It might be
 worthwhile to consider the fact that the C library stdio facility does
 not permit whitespace embedded in numbers and neither does the C or
-C++ core language (the syntax of integer-literals is given in 2.13.1
-[lex.icon], that of floating-point-literals in 2.13.3 [lex.fcon] of the
+C++ core language (the syntax of integer-literals is given in 2.14.2
+[lex.icon], that of floating-point-literals in 2.14.4 [lex.fcon] of the
 C++ standard).
 
    
 
 
 
    Proposed resolution:
    
-
    Change the first part of 22.2.3.1 [locale.numpunct] paragraph 2 from:
    
+
    Change the first part of 22.4.3.1 [locale.numpunct] paragraph 2 from:
    
 
    
 
    
 The syntax for number formats is as follows, where digit
@@ -15253,10 +15773,10 @@ Integer values have the format:
 
 
 
    Rationale:
    
-
    It's not clear whether the format described in 22.2.3.1 [locale.numpunct] paragraph 2 has any normative weight: nothing in the
+
    It's not clear whether the format described in 22.4.3.1 [locale.numpunct] paragraph 2 has any normative weight: nothing in the
 standard says how, or whether, it's used.  However, there's no reason
 for it to differ gratuitously from the very specific description of
-numeric processing in 22.2.2.1.2 [facet.num.get.virtuals].  The proposed
+numeric processing in 22.4.2.1.2 [facet.num.get.virtuals].  The proposed
 resolution removes all mention of "whitespace" from that format.
    
 
 
@@ -15265,14 +15785,14 @@ resolution removes all mention of "whitespace" from that format.
    
 
 
    
 
    339. definition of bitmask type restricted to clause 27
    
-
    Section: 22.2.1 [category.ctype], 17.3.2.1.2 [bitmask.types] Status: WP
- Submitter: Martin Sebor Date: 2001-09-17
    
+
    Section: 22.4.1 [category.ctype], 17.5.2.1.3 [bitmask.types] Status: CD1
+ Submitter: Martin Sebor Opened: 2001-09-17  Last modified: 2008-09-26
    
 
    View all other issues in [category.ctype].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
-
    The ctype_category::mask type is declared to be an enum in 22.2.1
+
    The ctype_category::mask type is declared to be an enum in 22.4.1
 [category.ctype] with p1 then stating that it is a bitmask type, most
-likely referring to the definition of bitmask type in 17.3.2.1.2
+likely referring to the definition of bitmask type in 17.5.2.1.3
 [bitmask.types], p1. However, the said definition only applies to
 clause 27, making the reference in 22.2.1 somewhat dubious.
 
    
@@ -15283,7 +15803,7 @@ clause 27, making the reference in 22.2.1 somewhat dubious.
     
    
     Several types defined in clause 27 are bitmask types. Each bitmask type
     can be implemented as an enumerated type that overloads certain operators,
-    as an integer type, or as a bitset (23.3.5 [template.bitset]).
+    as an integer type, or as a bitset (20.3.6 [template.bitset]).
     
    
 
    to read
    
     
    
@@ -15323,7 +15843,7 @@ following (note, in particluar, the cross-reference to 17.3.2.1.2 in
 }
 
    
 
-
    The type mask is a bitmask type (17.3.2.1.2 [bitmask.types]).
    
+
    The type mask is a bitmask type (17.5.2.1.3 [bitmask.types]).
    
 
    
 
 
    [Curaçao: The LWG notes that T above should be bold-italics to be
@@ -15339,10 +15859,10 @@ consistent with the rest of the standard.]
    
 
 
    
 
    340. interpretation of has_facet<Facet>(loc)
    
-
    Section: 22.1.1.1.1 [locale.category] Status: WP
- Submitter: Martin Sebor Date: 2001-09-18
    
+
    Section: 22.3.1.1.1 [locale.category] Status: CD1
+ Submitter: Martin Sebor Opened: 2001-09-18  Last modified: 2008-09-26
    
 
    View all other issues in [locale.category].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 It's unclear whether 22.1.1.1.1, p3 says that
@@ -15392,7 +15912,7 @@ to hold only for specializations of Facet from Table 52 on
 
 
 
    Proposed resolution:
    
-
    In 22.1.1.1.1 [locale.category], paragraph 3, change
+
    In 22.3.1.1.1 [locale.category], paragraph 3, change
 "that is a member of a standard category" to "shown in Table 51".
    
 
 
@@ -15411,10 +15931,10 @@ complete list of the ones we need.
    
 
 
    
 
    341. Vector reallocation and swap
    
-
    Section: 23.2.6.2 [vector.capacity] Status: WP
- Submitter: Anthony Williams Date: 2001-09-27
    
+
    Section: 23.3.6.2 [vector.capacity] Status: CD1
+ Submitter: Anthony Williams Opened: 2001-09-27  Last modified: 2008-09-26
    
 
    View all other issues in [vector.capacity].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    It is a common idiom to reduce the capacity of a vector by swapping it with
 an empty one:
    
@@ -15424,7 +15944,7 @@ an empty one:
    
   // vec is now empty, with minimal capacity
 
    
 
-
    However, the wording of 23.2.6.2 [vector.capacity]paragraph 5 prevents
+
    However, the wording of 23.3.6.2 [vector.capacity]paragraph 5 prevents
 the capacity of a vector being reduced, following a call to
 reserve(). This invalidates the idiom, as swap() is thus prevented
 from reducing the capacity. The proposed wording for issue 329 does not affect this.  Consequently, the example above
@@ -15433,7 +15953,7 @@ vec, and the contents be copied across. This is a linear-time
 operation.
    
 
 
    However, the container requirements state that swap must have constant
-complexity (23.1 [container.requirements] note to table 65).
    
+complexity (23.2 [container.requirements] note to table 65).
    
 
 
    This is an important issue, as reallocation affects the validity of
 references and iterators.
    
@@ -15457,7 +15977,7 @@ referred to one vector now refer to the other, and vice-versa.
 
 
 
    Proposed resolution:
    
-
    Add a new paragraph after 23.2.6.2 [vector.capacity] paragraph 5:
    
+
    Add a new paragraph after 23.3.6.2 [vector.capacity] paragraph 5:
    
 
    
 
      void swap(vector<T,Allocator>& x);
 
    
@@ -15486,20 +16006,20 @@ the two vectors, including their reallocation guarantees.
 
 
    
 
    345. type tm in <cwchar>
    
-
    Section: 21.5 [c.strings] Status: WP
- Submitter: Clark Nelson Date: 2001-10-19
    
+
    Section: 21.6 [c.strings] Status: CD1
+ Submitter: Clark Nelson Opened: 2001-10-19  Last modified: 2008-09-26
    
 
    View all other issues in [c.strings].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    C99, and presumably amendment 1 to C90, specify that <wchar.h>
-declares struct tm as an incomplete type. However, table 48 in 21.5
+declares struct tm as an incomplete type. However, table 48 in 21.6
 [c.strings] does not mention the type tm as being declared in
 <cwchar>. Is this omission intentional or accidental?
 
    
 
 
 
    Proposed resolution:
    
-
    In section 21.5 [c.strings], add "tm" to table 48.
    
+
    In section 21.6 [c.strings], add "tm" to table 48.
    
 
 
 
@@ -15507,11 +16027,11 @@ declares struct tm as an incomplete type. However, table 48 in 21.5
 
 
    
 
    346. Some iterator member functions should be const
    
-
    Section: 24.1 [iterator.requirements] Status: WP
- Submitter: Jeremy Siek Date: 2001-10-20
    
-
    View other active issues in [iterator.requirements].
    
-
    View all other issues in [iterator.requirements].
    
-
    View all issues with WP status.
    
+
    Section: 24.2 [iterator.concepts] Status: CD1
+ Submitter: Jeremy Siek Opened: 2001-10-20  Last modified: 2008-09-30
    
+
    View other active issues in [iterator.concepts].
    
+
    View all other issues in [iterator.concepts].
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    Iterator member functions and operators that do not change the state
 of the iterator should be defined as const member functions or as
@@ -15526,7 +16046,7 @@ make this more explicit and also fix a couple problems.
    
 
 
 
    Proposed resolution:
    
-
    In 24.1 [iterator.requirements] Change the first section of p9 from
+
    In 24.2 [iterator.concepts] Change the first section of p9 from
 "In the following sections, a and b denote values of X..." to
 "In the following sections, a and b denote values of type const X...".
    
 
@@ -15561,15 +16081,15 @@ the same problem appears there.]
    
 
 
    
 
    347. locale::category and bitmask requirements
    
-
    Section: 22.1.1.1.1 [locale.category] Status: WP
- Submitter: P.J. Plauger, Nathan Myers Date: 2001-10-23
    
+
    Section: 22.3.1.1.1 [locale.category] Status: CD1
+ Submitter: P.J. Plauger, Nathan Myers Opened: 2001-10-23  Last modified: 2008-09-26
    
 
    View all other issues in [locale.category].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-In 22.1.1.1.1 [locale.category] paragraph 1, the category members
+In 22.3.1.1.1 [locale.category] paragraph 1, the category members
 are described as bitmask elements.  In fact, the bitmask requirements
-in 17.3.2.1.2 [bitmask.types] don't seem quite right: none
+in 17.5.2.1.3 [bitmask.types] don't seem quite right: none
 and all are bitmask constants, not bitmask elements.
    
 
 
    In particular, the requirements for none interact poorly
@@ -15590,7 +16110,7 @@ changes beyond resolving the DR.
    
 
 
 
    Proposed resolution:
    
-
    Replace the first two paragraphs of 22.1.1.1 [locale.types] with:
    
+
    Replace the first two paragraphs of 22.3.1.1 [locale.types] with:
    
 
    
 
        typedef int category;
 
    
@@ -15637,7 +16157,7 @@ shown in Table 51:
 
 
    
 
    Option 2: 
    
-Replace the first paragraph of 22.1.1.1 [locale.types] with:
    
+Replace the first paragraph of 22.3.1.1 [locale.types] with:
    
 
    
 
    
 Valid category values include the enumerated values.  In addition, the
@@ -15664,9 +16184,9 @@ of the other enumerated values; implementations may add extra categories.]
 
 
    
 
    349. Minor typographical error in ostream_iterator
    
-
    Section: 24.5.2 [ostream.iterator] Status: WP
- Submitter: Andy Sawyer Date: 2001-10-24
    
-
    View all issues with WP status.
    
+
    Section: 24.6.2 [ostream.iterator] Status: CD1
+ Submitter: Andy Sawyer Opened: 2001-10-24  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    24.5.2 [lib.ostream.iterator] states:
    
 
        [...]
@@ -15682,7 +16202,7 @@ should be of type 'const charT*'.
    
 
 
    Proposed resolution:
    
 
    
-In 24.5.2 [ostream.iterator], replace const char* delim with
+In 24.6.2 [ostream.iterator], replace const char* delim with
 const charT* delim.
 
    
 
@@ -15692,9 +16212,9 @@ In 24.5.2 [ostream.iterator], replace const char* delim with
 
 
    
 
    352. missing fpos requirements
    
-
    Section: 21.1.2 [char.traits.typedefs] Status: WP
- Submitter: Martin Sebor Date: 2001-12-02
    
-
    View all issues with WP status.
    
+
    Section: 21.2.2 [char.traits.typedefs] Status: CD1
+ Submitter: Martin Sebor Opened: 2001-12-02  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 (1)
@@ -15748,10 +16268,11 @@ be considered NAD.
    
 
 
    
 
    354. Associative container lower/upper bound requirements
    
-
    Section: 23.1.4 [associative.reqmts] Status: WP
- Submitter: Hans Aberg Date: 2001-12-17
    
+
    Section: 23.2.4 [associative.reqmts] Status: CD1
+ Submitter: Hans Aberg Opened: 2001-12-17  Last modified: 2008-09-26
    
+
    View other active issues in [associative.reqmts].
    
 
    View all other issues in [associative.reqmts].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 Discussions in the thread "Associative container lower/upper bound
@@ -15788,7 +16309,7 @@ the intention (and not possible with the "const" versions).
 
 
    Proposed resolution:
    
 
-
    Change Table 69 of section 23.1.4 [associative.reqmts] indicated entries
+
    Change Table 69 of section 23.2.4 [associative.reqmts] indicated entries
 to:
    
 
 
    
@@ -15814,10 +16335,11 @@ key greater than k, or a.end() if such an element is not found.
 
 
    
 
    355. Operational semantics for a.back()
    
-
    Section: 23.1.3 [sequence.reqmts] Status: WP
- Submitter: Yaroslav Mironov Date: 2002-01-23
    
+
    Section: 23.2.3 [sequence.reqmts] Status: CD1
+ Submitter: Yaroslav Mironov Opened: 2002-01-23  Last modified: 2008-09-26
    
+
    View other active issues in [sequence.reqmts].
    
 
    View all other issues in [sequence.reqmts].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
 
    Table 68 "Optional Sequence Operations" in 23.1.1/12
@@ -15896,11 +16418,11 @@ LWG would like a new issue opened.]
    
 
 
    
 
    358. interpreting thousands_sep after a decimal_point
    
-
    Section: 22.2.2.1.2 [facet.num.get.virtuals] Status: WP
- Submitter: Martin Sebor Date: 2002-03-12
    
+
    Section: 22.4.2.1.2 [facet.num.get.virtuals] Status: CD1
+ Submitter: Martin Sebor Opened: 2002-03-12  Last modified: 2008-09-26
    
 
    View other active issues in [facet.num.get.virtuals].
    
 
    View all other issues in [facet.num.get.virtuals].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 I don't think thousands_sep is being treated correctly after
@@ -15957,9 +16479,9 @@ Change the first sentence of 22.2.2.1.2, p9 from
 
 
    
 
    359. num_put<>::do_put (..., bool) undocumented
    
-
    Section: 22.2.2.2.1 [facet.num.put.members] Status: WP
- Submitter: Martin Sebor Date: 2002-03-12
    
-
    View all issues with WP status.
    
+
    Section: 22.4.2.2.1 [facet.num.put.members] Status: CD1
+ Submitter: Martin Sebor Opened: 2002-03-12  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    22.2.2.2.1, p1:
    
 
@@ -16008,11 +16530,11 @@ the following:
 
 
 
    Proposed resolution:
    
-
    In 22.2.2.2.2 [facet.num.put.virtuals], just above paragraph 1, remove
+
    In 22.4.2.2.2 [facet.num.put.virtuals], just above paragraph 1, remove
   the bool overload.
    
 
 
    
-In 22.2.2.2.2 [facet.num.put.virtuals], p23, make the following changes
+In 22.4.2.2.2 [facet.num.put.virtuals], p23, make the following changes
 
    
 
 
    
@@ -16053,10 +16575,10 @@ be a requirement of gratuitous inefficiency.
 
 
    
 
    360. locale mandates inefficient implementation
    
-
    Section: 22.1.1 [locale] Status: WP
- Submitter: Martin Sebor Date: 2002-03-12
    
+
    Section: 22.3.1 [locale] Status: CD1
+ Submitter: Martin Sebor Opened: 2002-03-12  Last modified: 2008-09-26
    
 
    View all other issues in [locale].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 22.1.1, p7 (copied below) allows iostream formatters and extractors
@@ -16103,10 +16625,10 @@ prevents locale from being implemented efficiently.
 
 
    
 
    362. bind1st/bind2nd type safety
    
-
    Section: D.8 [depr.lib.binders] Status: WP
- Submitter: Andrew Demkin Date: 2002-04-26
    
+
    Section: D.8 [depr.lib.binders] Status: CD1
+ Submitter: Andrew Demkin Opened: 2002-04-26  Last modified: 2008-09-26
    
 
    View all other issues in [depr.lib.binders].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 The definition of bind1st() (D.8 [depr.lib.binders]) can result in
@@ -16167,10 +16689,10 @@ as a reinterpret_cast, thus masking the error.
 
 
    
 
    363. Missing exception specification in 27.4.2.1.1
    
-
    Section: 27.4.2.1.1 [ios::failure] Status: WP
- Submitter: Walter Brown and Marc Paterno Date: 2002-05-20
    
+
    Section: 27.5.2.1.1 [ios::failure] Status: CD1
+ Submitter: Walter Brown and Marc Paterno Opened: 2002-05-20  Last modified: 2008-09-26
    
 
    View all other issues in [ios::failure].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 The destructor of ios_base::failure should have an empty throw
@@ -16194,13 +16716,13 @@ declared in this way.
 
 
    
 
    364. Inconsistent wording in 27.5.2.4.2
    
-
    Section: 27.5.2.4.2 [streambuf.virt.buffer] Status: WP
- Submitter: Walter Brown, Marc Paterno Date: 2002-05-10
    
+
    Section: 27.6.2.4.2 [streambuf.virt.buffer] Status: CD1
+ Submitter: Walter Brown, Marc Paterno Opened: 2002-05-10  Last modified: 2008-09-26
    
 
    View all other issues in [streambuf.virt.buffer].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-27.5.2.4.2 [streambuf.virt.buffer] paragraph 1 is inconsistent with the Effects
+27.6.2.4.2 [streambuf.virt.buffer] paragraph 1 is inconsistent with the Effects
 clause for seekoff.
 
    
 
@@ -16240,10 +16762,11 @@ for each class derived from basic_streambuf in this clause
 
 
    
 
    365. Lack of const-qualification in clause 27
    
-
    Section: 27 [input.output] Status: WP
- Submitter: Walter Brown, Marc Paterno Date: 2002-05-10
    
+
    Section: 27 [input.output] Status: CD1
+ Submitter: Walter Brown, Marc Paterno Opened: 2002-05-10  Last modified: 2008-09-26
    
+
    View other active issues in [input.output].
    
 
    View all other issues in [input.output].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 Some stream and streambuf member functions are declared non-const,
@@ -16293,10 +16816,10 @@ way by providing both overloads; this would be a conforming extension.
    
 
 
    
 
    369. io stream objects and static ctors
    
-
    Section: 27.3 [iostream.objects] Status: WP
- Submitter: Ruslan Abdikeev Date: 2002-07-08
    
+
    Section: 27.4 [iostream.objects] Status: CD1
+ Submitter: Ruslan Abdikeev Opened: 2002-07-08  Last modified: 2008-09-26
    
 
    View all other issues in [iostream.objects].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 Is it safe to use standard iostream objects from constructors of
@@ -16365,7 +16888,7 @@ mention of an _instance_ of ios_base::Init in Standard.
 
 
    Proposed resolution:
    
 
-
    Add to 27.3 [iostream.objects], p2, immediately before the last sentence
+
    Add to 27.4 [iostream.objects], p2, immediately before the last sentence
 of the paragraph, the following two sentences:
    
 
 
    
@@ -16405,13 +16928,13 @@ do to ensure that stream objects are constructed during startup.
    
 
 
    
 
    370. Minor error in basic_istream::get
    
-
    Section: 27.6.1.3 [istream.unformatted] Status: WP
- Submitter: Ray Lischner Date: 2002-07-15
    
+
    Section: 27.7.1.3 [istream.unformatted] Status: CD1
+ Submitter: Ray Lischner Opened: 2002-07-15  Last modified: 2008-09-26
    
 
    View all other issues in [istream.unformatted].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    Defect report for description of basic_istream::get (section
-27.6.1.3 [istream.unformatted]), paragraph 15. The description for the
+27.7.1.3 [istream.unformatted]), paragraph 15. The description for the
 get function
 with the following signature:
    
 
@@ -16451,11 +16974,11 @@ with the following signature:
    
 
 
    
 
    371. Stability of multiset and multimap member functions
    
-
    Section: 23.1 [container.requirements] Status: WP
- Submitter: Frank Compagner Date: 2002-07-20
    
+
    Section: 23.2 [container.requirements] Status: CD1
+ Submitter: Frank Compagner Opened: 2002-07-20  Last modified: 2008-09-26
    
 
    View other active issues in [container.requirements].
    
 
    View all other issues in [container.requirements].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 The requirements for multiset and multimap containers (23.1
@@ -16514,7 +17037,7 @@ erase_if() member function that much greater.
 
 
    Proposed resolution:
    
 
-
    Add the following to the end of 23.1.4 [associative.reqmts] paragraph 4: 
+
    Add the following to the end of 23.2.4 [associative.reqmts] paragraph 4: 
 "For multiset and multimap, insertand erase
   are stable: they preserve the relative ordering of equivalent
   elements.
     
@@ -16545,24 +17068,24 @@ wording.]
    
 
 
    
 
    373. Are basic_istream and basic_ostream to use (exceptions()&badbit) != 0 ?
    
-
    Section: 27.6.1.2.1 [istream.formatted.reqmts], 27.6.2.6.1 [ostream.formatted.reqmts] Status: WP
- Submitter: Keith Baker Date: 2002-07-23
    
+
    Section: 27.7.1.2.1 [istream.formatted.reqmts], 27.7.2.6.1 [ostream.formatted.reqmts] Status: CD1
+ Submitter: Keith Baker Opened: 2002-07-23  Last modified: 2008-09-26
    
 
    View all other issues in [istream.formatted.reqmts].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
 
    
-In 27.6.1.2.1 [istream.formatted.reqmts] and 27.6.2.6.1 [ostream.formatted.reqmts]
+In 27.7.1.2.1 [istream.formatted.reqmts] and 27.7.2.6.1 [ostream.formatted.reqmts]
 (exception()&badbit) != 0 is used in testing for rethrow, yet
-exception() is the constructor to class std::exception in 18.6.1 [type.info] that has no return type. Should member function
-exceptions() found in 27.4.4 [ios] be used instead?
+exception() is the constructor to class std::exception in 18.7.1 [type.info] that has no return type. Should member function
+exceptions() found in 27.5.4 [ios] be used instead?
 
    
 
 
 
 
    Proposed resolution:
    
 
    
-In 27.6.1.2.1 [istream.formatted.reqmts] and 27.6.2.6.1 [ostream.formatted.reqmts], change
+In 27.7.1.2.1 [istream.formatted.reqmts] and 27.7.2.6.1 [ostream.formatted.reqmts], change
 "(exception()&badbit) != 0" to "(exceptions()&badbit) != 0".
 
    
 
@@ -16576,13 +17099,13 @@ In 27.6.1.2.1 [istream.formatted.reqmts] and 27.6.2.6.1 [ostream.formatted.reqmt
 
 
    
 
    375. basic_ios should be ios_base in 27.7.1.3
    
-
    Section: 27.7.1.4 [stringbuf.virtuals] Status: WP
- Submitter: Ray Lischner Date: 2002-08-14
    
+
    Section: 27.8.1.4 [stringbuf.virtuals] Status: CD1
+ Submitter: Ray Lischner Opened: 2002-08-14  Last modified: 2008-09-26
    
 
    View all other issues in [stringbuf.virtuals].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-In Section 27.7.1.4 [stringbuf.virtuals]: Table 90, Table 91, and paragraph
+In Section 27.8.1.4 [stringbuf.virtuals]: Table 90, Table 91, and paragraph
 14 all contain references to "basic_ios::" which should be
 "ios_base::".
 
    
@@ -16602,13 +17125,13 @@ paragraph 14 to "ios_base".
 
 
    
 
    376. basic_streambuf semantics
    
-
    Section: 27.7.1.4 [stringbuf.virtuals] Status: WP
- Submitter: Ray Lischner Date: 2002-08-14
    
+
    Section: 27.8.1.4 [stringbuf.virtuals] Status: CD1
+ Submitter: Ray Lischner Opened: 2002-08-14  Last modified: 2008-09-26
    
 
    View all other issues in [stringbuf.virtuals].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-In Section 27.7.1.4 [stringbuf.virtuals], Table 90, the implication is that
+In Section 27.8.1.4 [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.
    
 
@@ -16652,10 +17175,10 @@ are both true, but case 3 is false.
 
 
    
 
    379. nonsensical ctype::do_widen() requirement
    
-
    Section: 22.2.1.1.2 [locale.ctype.virtuals] Status: WP
- Submitter: Martin Sebor Date: 2002-09-06
    
+
    Section: 22.4.1.1.2 [locale.ctype.virtuals] Status: CD1
+ Submitter: Martin Sebor Opened: 2002-09-06  Last modified: 2008-09-26
    
 
    View all other issues in [locale.ctype.virtuals].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 The last sentence in 22.2.1.1.2, p11 below doesn't seem to make sense.
@@ -16686,7 +17209,7 @@ footnote 224.)
 
 
    Proposed resolution:
    
 
    
-Replace the last sentence of 22.2.1.1.2 [locale.ctype.virtuals], p11 with the
+Replace the last sentence of 22.4.1.1.2 [locale.ctype.virtuals], p11 with the
 following text:
 
    
 
           For any named ctype category with a ctype<char> facet ctc
@@ -16708,13 +17231,13 @@ following text:
 
 
    
 
    380. typos in codecvt tables 53 and 54
    
-
    Section: 22.2.1.5 [locale.codecvt.byname] Status: WP
- Submitter: Martin Sebor Date: 2002-09-06
    
+
    Section: 22.4.1.5 [locale.codecvt.byname] Status: CD1
+ Submitter: Martin Sebor Opened: 2002-09-06  Last modified: 2008-09-26
    
 
    View all other issues in [locale.codecvt.byname].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-Tables 53 and 54 in 22.2.1.5 [locale.codecvt.byname] are both titled "convert
+Tables 53 and 54 in 22.4.1.5 [locale.codecvt.byname] are both titled "convert
 result values," when surely "do_in/do_out result values" must have
 been intended for Table 53 and "do_unshift result values" for Table
 54.
@@ -16746,10 +17269,10 @@ elements was needed to terminate a sequence given the value of state."
 
 
    
 
    381. detection of invalid mbstate_t in codecvt
    
-
    Section: 22.2.1.5 [locale.codecvt.byname] Status: WP
- Submitter: Martin Sebor Date: 2002-09-06
    
+
    Section: 22.4.1.5 [locale.codecvt.byname] Status: CD1
+ Submitter: Martin Sebor Opened: 2002-09-06  Last modified: 2008-09-26
    
 
    View all other issues in [locale.codecvt.byname].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 All but one codecvt member functions that take a state_type argument
@@ -16810,10 +17333,10 @@ values, or that choose to detect any other kind of error, may return
 
 
    
 
    383. Bidirectional iterator assertion typo
    
-
    Section: 24.1.4 [bidirectional.iterators] Status: WP
- Submitter: ysapir (submitted via comp.std.c++) Date: 2002-10-17
    
+
    Section: 24.2.5 [bidirectional.iterators] Status: CD1
+ Submitter: ysapir (submitted via comp.std.c++) Opened: 2002-10-17  Last modified: 2008-09-26
    
 
    View all other issues in [bidirectional.iterators].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 Following a discussion on the boost list regarding end iterators and
@@ -16826,8 +17349,8 @@ with that discussion.
 I have checked this newsgroup, as well as attempted a search of the
 Active/Defect/Closed Issues List on the site for the words "s is
 derefer" so I believe this has not been proposed before.  Furthermore,
-the "Lists by Index" mentions only DR 299 on section
-24.1.4, and DR 299 is not related to this issue.
+the "Lists by Index" mentions only DR 299 on section
+24.1.4, and DR 299 is not related to this issue.
 
    
 
 
    
@@ -16879,13 +17402,13 @@ Change the guarantee to "postcondition: r is dereferenceable."
 
 
    
 
    384. equal_range has unimplementable runtime complexity
    
-
    Section: 25.3.3.3 [equal.range] Status: WP
- Submitter: Hans Bos Date: 2002-10-18
    
+
    Section: 25.5.3.3 [equal.range] Status: CD1
+ Submitter: Hans Bos Opened: 2002-10-18  Last modified: 2008-09-26
    
 
    View all other issues in [equal.range].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-Section 25.3.3.3 [equal.range]
+Section 25.5.3.3 [equal.range]
 states that at most 2 * log(last - first) + 1
 comparisons are allowed for equal_range.
 
    
@@ -16924,13 +17447,13 @@ but 2log(distance) + 4 for the worst case).
 
 
 
    Proposed resolution:
    
-
    In 25.3.3.1 [lower.bound]/4, change log(last - first) + 1
+
    In 25.5.3.1 [lower.bound]/4, change log(last - first) + 1
 to log2(last - first) + O(1).
    
 
-
    In 25.3.3.2 [upper.bound]/4, change log(last - first) + 1
+
    In 25.5.3.2 [upper.bound]/4, change log(last - first) + 1
 to log2(last - first) + O(1).
    
 
-
    In 25.3.3.3 [equal.range]/4, change 2*log(last - first) + 1
+
    In 25.5.3.3 [equal.range]/4, change 2*log(last - first) + 1
 to 2*log2(last - first) + O(1).
    
 
 
    [Matt provided wording]
    
@@ -16951,11 +17474,11 @@ to 2*log2(last - first) + O(1).
    
 
 
    
 
    386. Reverse iterator's operator[] has impossible return type
    
-
    Section: 24.4.1.3.11 [reverse.iter.op-=] Status: DR
- Submitter: Matt Austern Date: 2002-10-23
    
-
    View all issues with DR status.
    
+
    Section: 24.5.1.2.11 [reverse.iter.op-=] Status: CD1
+ Submitter: Matt Austern Opened: 2002-10-23  Last modified: 2009-05-01
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
-
    In 24.4.1.3.11 [reverse.iter.op-=], reverse_iterator<>::operator[] 
+
    In 24.5.1.2.11 [reverse.iter.op-=], reverse_iterator<>::operator[] 
 is specified as having a return type of reverse_iterator::reference,
 which is the same as iterator_traits<Iterator>::reference.
 (Where Iterator is the underlying iterator type.)
    
@@ -16967,7 +17490,7 @@ which is the same as iterator_traits<Iterator>::reference.
   to Iterator's value type.  The return type specified for
   reverse_iterator's operator[] would thus appear to be impossible.
    
 
-
    With the resolution of issue 299, the type of
+
    With the resolution of issue 299, the type of
   a[n] will continue to be required (for random access
   iterators) to be convertible to the value type, and also a[n] =
   t will be a valid expression.  Implementations of
@@ -16981,7 +17504,7 @@ which is the same as iterator_traits<Iterator>::reference.
 
 
    Proposed resolution:
    
 
-
    In 24.4.1.2 [reverse.iter.requirements] change:
    
+
    In  [reverse.iter.requirements] change:
    
 
 
    
 
    reference operator[](difference_type n) const;
@@ -16991,7 +17514,7 @@ which is the same as iterator_traits<Iterator>::reference.
 
    to:
    
 
 
    
-
    unspecified operator[](difference_type n) const; // see 24.1.5 [random.access.iterators]
+
    unspecified operator[](difference_type n) const; // see 24.2.6 [random.access.iterators]
 
    
 
    
 
@@ -17012,12 +17535,169 @@ Comments from Dave Abrahams: IMO we should resolve 386 by just saying
 
 
 
+
    
+
    387. std::complex over-encapsulated
    
+
    Section: 26.4 [complex.numbers] Status: CD1
+ Submitter: Gabriel Dos Reis Opened: 2002-11-08  Last modified: 2008-09-26
    
+
    View all other issues in [complex.numbers].
    
+
    View all issues with CD1 status.
    
+
    Discussion:
    
+
    
+The absence of explicit description of std::complex<T> layout
+makes it imposible to reuse existing software developed in traditional
+languages like Fortran or C with unambigous and commonly accepted
+layout assumptions.  There ought to be a way for practitioners to
+predict with confidence the layout of std::complex<T> whenever T
+is a numerical datatype.  The absence of ways to access individual
+parts of a std::complex<T> object as lvalues unduly promotes
+severe pessimizations. For example, the only way to change,
+independently, the real and imaginary parts is to write something like
+
    
+
+
    complex<T> z;
+// ...
+// set the real part to r
+z = complex<T>(r, z.imag());
+// ...
+// set the imaginary part to i
+z = complex<T>(z.real(), i);
+
    
+
+
    
+At this point, it seems appropriate to recall that a complex number
+is, in effect, just a pair of numbers with no particular invariant to
+maintain.  Existing practice in numerical computations has it that a
+complex number datatype is usually represented by Cartesian
+coordinates. Therefore the over-encapsulation put in the specification
+of std::complex<> is not justified.
+
    
+
+
+
+
    Proposed resolution:
    
+
    Add the following requirements to 26.4 [complex.numbers] as 26.3/4:
    
+
    
+
    If z is an lvalue expression of type cv std::complex<T> then
    
+
+
      
+
    • the expression reinterpret_cast<cv T(&)[2]>(z)
+is well-formed; and
      • 
+
    • reinterpret_cast<cv T(&)[2]>(z)[0]designates the
+real part of z; and
      • 
+
    • reinterpret_cast<cv T(&)[2]>(z)[1]designates the
+imaginary part of z.
      • 
+
    
+
+
    
+Moreover, if a is an expression of pointer type cv complex<T>*
+and the expression a[i] is well-defined for an integer expression
+i then:
+
    
+
+
      
+
    • reinterpret_cast<cv T*>(a)[2*i] designates the real
+part of a[i]; and
      • 
+
    • reinterpret_cast<cv T*>(a)[2*i+1] designates the
+imaginary part of a[i].
      • 
+
    
+
    
+
+
    
+In 26.4.2 [complex] and 26.4.3 [complex.special] add the following member functions
+(changing T to concrete types as appropriate for the specializations).
+
    
+
+
    void real(T);
+void imag(T);
+
    
+
+
    
+Add to 26.4.4 [complex.members]
+
    
+
+
    
+
    T real() const;
+
    
+
    
+Returns: the value of the real component
+
    
+
    void real(T val);
+
    
+
    
+Assigns val to the real component.
+
    
+
    T imag() const;
+
    
+
    
+Returns: the value of the imaginary component
+
    
+
    void imag(T val);
+
    
+
    
+Assigns val to the imaginary component.
+
    
+
    
+
+
    [Kona: The layout guarantee is absolutely necessary for C
+  compatibility.  However, there was disagreement about the other part
+  of this proposal: retrieving elements of the complex number as
+  lvalues.  An alternative: continue to have real() and imag() return
+  rvalues, but add set_real() and set_imag().  Straw poll: return
+  lvalues - 2, add setter functions - 5.  Related issue: do we want
+  reinterpret_cast as the interface for converting a complex to an
+  array of two reals, or do we want to provide a more explicit way of
+  doing it?  Howard will try to resolve this issue for the next
+  meeting.]
    
+
+
+
    [pre-Sydney: Howard summarized the options in n1589.]
    
+
+
+
    [
+Bellevue:
+]
    
+
+
+
    
+Second half of proposed wording replaced and moved to Ready.
+
    
+
+
    [
+Pre-Sophia Antipolis, Howard adds:
+]
    
+
+
+
    
+Added the members to 26.4.3 [complex.special] and changed from Ready to Review.
+
    
+
+
    [
+Post-Sophia Antipolis:
+]
    
+
+
+
    
+Moved from WP back to Ready so that the "and 26.4.3 [complex.special]" in the proposed
+resolution can be officially applied.
+
    
+
+
+
+
    Rationale:
    
+
    The LWG believes that C99 compatibility would be enough
+justification for this change even without other considerations.  All
+existing implementations already have the layout proposed here.
    
+
+
+
+
+
 
    
 
    389. Const overload of valarray::operator[] returns by value
    
-
    Section: 26.5.2.3 [valarray.access] Status: WP
- Submitter: Gabriel Dos Reis Date: 2002-11-08
    
+
    Section: 26.6.2.3 [valarray.access] Status: CD1
+ Submitter: Gabriel Dos Reis Opened: 2002-11-08  Last modified: 2008-09-26
    
 
    View all other issues in [valarray.access].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Duplicate of: 77
    
 
    Discussion:
    
 
    Consider the following program:
    
@@ -17061,8 +17741,8 @@ should not return a const T&.
    
 
 
 
    Proposed resolution:
    
-
    In the class synopsis in 26.5.2 [template.valarray], and in
-26.5.2.3 [valarray.access] just above paragraph 1, change
    
+
    In the class synopsis in 26.6.2 [template.valarray], and in
+26.6.2.3 [valarray.access] just above paragraph 1, change
    
 
      T operator[](size_t const);
 
    
 
    to
    
@@ -17088,19 +17768,19 @@ impact on allowable optimizations.
    
 
 
    
 
    391. non-member functions specified as const
    
-
    Section: 22.1.3.2 [conversions] Status: WP
- Submitter: James Kanze Date: 2002-12-10
    
-
    View all issues with WP status.
    
+
    Section: 22.3.3.2 [conversions] Status: CD1
+ Submitter: James Kanze Opened: 2002-12-10  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 The specifications of toupper and tolower both specify the functions as
 const, althought they are not member functions, and are not specified as
-const in the header file synopsis in section 22.1 [locales].
+const in the header file synopsis in section 22.3 [locales].
 
    
 
 
 
    Proposed resolution:
    
-
    In 22.1.3.2 [conversions], remove const from the function
+
    In 22.3.3.2 [conversions], remove const from the function
   declarations of std::toupper and std::tolower
    
 
 
@@ -17111,20 +17791,20 @@ const in the header file synopsis in section 22.1 [locales].
 
 
    
 
    395. inconsistencies in the definitions of rand() and random_shuffle()
    
-
    Section: 26.7 [c.math] Status: WP
- Submitter: James Kanze Date: 2003-01-03
    
+
    Section: 26.8 [c.math] Status: CD1
+ Submitter: James Kanze Opened: 2003-01-03  Last modified: 2008-09-26
    
 
    View all other issues in [c.math].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-In 26.7 [c.math], the C++ standard refers to the C standard for the
+In 26.8 [c.math], the C++ standard refers to the C standard for the
 definition of rand(); in the C standard, it is written that "The
 implementation shall behave as if no library function calls the rand
 function."
 
    
 
 
    
-In 25.2.12 [alg.random.shuffle], there is no specification as to
+In 25.4.12 [alg.random.shuffle], there is no specification as to
 how the two parameter version of the function generates its random
 value.  I believe that all current implementations in fact call rand()
 (in contradiction with the requirement avove); if an implementation does
@@ -17163,15 +17843,149 @@ implementation is permitted to use rand.]
 
 
 
+
    
+
    396. what are characters zero and one
    
+
    Section: 20.3.6.1 [bitset.cons] Status: CD1
+ Submitter: Martin Sebor Opened: 2003-01-05  Last modified: 2008-09-26
    
+
    View all other issues in [bitset.cons].
    
+
    View all issues with CD1 status.
    
+
    Discussion:
    
+    
    
+23.3.5.1, p6 [lib.bitset.cons] talks about a generic character
+having the value of 0 or 1 but there is no definition of what
+that means for charT other than char and wchar_t. And even for
+those two types, the values 0 and 1 are not actually what is
+intended -- the values '0' and '1' are. This, along with the
+converse problem in the description of to_string() in 23.3.5.2,
+p33, looks like a defect remotely related to DR 303.
+    
    
+    
    
+http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#303
+    
    
+    
    23.3.5.1:
+  -6-  An element of the constructed string has value zero if the
+       corresponding character in str, beginning at position pos,
+       is 0. Otherwise, the element has the value one.
+    
    
+    
    23.3.5.2:
+  -33-  Effects: Constructs a string object of the appropriate
+        type and initializes it to a string of length N characters.
+        Each character is determined by the value of its
+        corresponding bit position in *this. Character position N
+        ?- 1 corresponds to bit position zero. Subsequent decreasing
+        character positions correspond to increasing bit positions.
+        Bit value zero becomes the character 0, bit value one becomes
+        the character 1.
+    
    
+    
    
+Also note the typo in 23.3.5.1, p6: the object under construction
+is a bitset, not a string.
+    
    
+
+
    [
+Sophia Antipolis:
+]
    
+
+
+
    
+
    
+We note that bitset has been moved from section 23 to section 20, by
+another issue (842) previously resolved at this meeting.
+
    
+
    
+Disposition: move to ready.
+
    
+
    
+We request that Howard submit a separate issue regarding the three to_string overloads.
+
    
+
    
+
+  
+
+
    Proposed resolution:
    
+
    Change the constructor's function declaration immediately before 
+20.3.6.1 [bitset.cons] p3 to:
    
+
        template <class charT, class traits, class Allocator>
+    explicit
+    bitset(const basic_string<charT, traits, Allocator>& str,
+           typename basic_string<charT, traits, Allocator>::size_type pos = 0,
+           typename basic_string<charT, traits, Allocator>::size_type n =
+             basic_string<charT, traits, Allocator>::npos,
+           charT zero = charT('0'), charT one = charT('1'))
+
    
+
    Change the first two sentences of 20.3.6.1 [bitset.cons] p6 to: "An
+element of the constructed string has value 0 if the corresponding
+character in str, beginning at position pos,
+is zero. Otherwise, the element has the value 1.
    
+
+
    Change the text of the second sentence in 23.3.5.1, p5 to read:
+    "The function then throws invalid_argument if any of the rlen
+    characters in str beginning at position pos is other than zero
+    or one. The function uses traits::eq() to compare the character
+    values."
+
    
+
+
    Change the declaration of the to_string member function
+  immediately before 20.3.6.2 [bitset.members] p33 to:
    
+
        template <class charT, class traits, class Allocator>
+    basic_string<charT, traits, Allocator> 
+    to_string(charT zero = charT('0'), charT one = charT('1')) const;
+
    
+
    Change the last sentence of 20.3.6.2 [bitset.members] p33 to: "Bit
+  value 0 becomes the character zero, bit value 1 becomes the
+  character one.
    
+
    Change 20.3.6.3 [bitset.operators] p8 to:
    
+
    Returns:
     
+
      os << x.template to_string<charT,traits,allocator<charT> >(
+      use_facet<ctype<charT> >(os.getloc()).widen('0'),
+      use_facet<ctype<charT> >(os.getloc()).widen('1'));
+
    
+
+
+
    Rationale:
    
+
    There is a real problem here: we need the character values of '0'
+  and '1', and we have no way to get them since strings don't have
+  imbued locales. In principle the "right" solution would be to
+  provide an extra object, either a ctype facet or a full locale,
+  which would be used to widen '0' and '1'. However, there was some
+  discomfort about using such a heavyweight mechanism.  The proposed
+  resolution allows those users who care about this issue to get it
+  right.
    
+
    We fix the inserter to use the new arguments.  Note that we already
+  fixed the analogous problem with the extractor in issue 303.
    
+
+
+
+
    [
+post Bellevue:
+]
    
+
+
+
    
+We are happy with the resolution as proposed, and we move this to Ready.
+
    
+
+
    [
+Howard adds:
+]
    
+
+
+
    
+The proposed wording neglects the 3 newer to_string overloads.
+
    
+
+
+
+
 
    
 
    400. redundant type cast in lib.allocator.members
    
-
    Section: 20.7.5.1 [allocator.members] Status: WP
- Submitter: Markus Mauhart Date: 2003-02-27
    
+
    Section: 20.8.6.1 [allocator.members] Status: CD1
+ Submitter: Markus Mauhart Opened: 2003-02-27  Last modified: 2008-09-26
    
 
    View all other issues in [allocator.members].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-20.7.5.1 [allocator.members] allocator members, contains
+20.8.6.1 [allocator.members] allocator members, contains
 the following 3 lines:
 
    
 
@@ -17199,11 +18013,11 @@ Replace "((T*) p)" with "p".
 
 
    
 
    401.  incorrect type casts in table 32 in lib.allocator.requirements
    
-
    Section: 20.1.2 [allocator.requirements] Status: WP
- Submitter: Markus Mauhart Date: 2003-02-27
    
+
    Section: X [allocator.requirements] Status: CD1
+ Submitter: Markus Mauhart Opened: 2003-02-27  Last modified: 2008-09-26
    
 
    View other active issues in [allocator.requirements].
    
 
    View all other issues in [allocator.requirements].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 I think that in par2 of  [default.con.req] the last two
@@ -17283,21 +18097,21 @@ issue to Ready status to be voted into the WP at Kona.
 
 
    
 
    402. wrong new expression in [some_]allocator::construct
    
-
    Section: 20.1.2 [allocator.requirements], 20.7.5.1 [allocator.members] Status: WP
- Submitter: Markus Mauhart Date: 2003-02-27
    
+
    Section: X [allocator.requirements], 20.8.6.1 [allocator.members] Status: CD1
+ Submitter: Markus Mauhart Opened: 2003-02-27  Last modified: 2008-09-26
    
 
    View other active issues in [allocator.requirements].
    
 
    View all other issues in [allocator.requirements].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 This applies to the new expression that is contained in both par12 of
-20.7.5.1 [allocator.members] and in par2 (table 32) of  [default.con.req].
+20.8.6.1 [allocator.members] and in par2 (table 32) of  [default.con.req].
 I think this new expression is wrong, involving unintended side
 effects.
 
    
 
 
-
    20.7.5.1 [allocator.members]  contains the following 3 lines:
    
+
    20.8.6.1 [allocator.members]  contains the following 3 lines:
    
 
 
      11 Returns: the largest value N for which the call allocate(N,0) might succeed.
      void construct(pointer p, const_reference val);
@@ -17350,38 +18164,38 @@ Replace "new" with "::new" in both cases.
 
 
    
 
    403. basic_string::swap should not throw exceptions
    
-
    Section: 21.3.6.8 [string::swap] Status: WP
- Submitter: Beman Dawes Date: 2003-03-25
    
+
    Section: 21.4.6.8 [string::swap] Status: CD1
+ Submitter: Beman Dawes Opened: 2003-03-25  Last modified: 2008-09-26
    
 
    View all other issues in [string::swap].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
 
    
-std::basic_string, 21.3 [basic.string] paragraph 2 says that
+std::basic_string, 21.4 [basic.string] paragraph 2 says that
 basic_string "conforms to the requirements of a Sequence, as specified
 in (23.1.1)." The sequence requirements specified in (23.1.1) to not
 include any prohibition on swap members throwing exceptions.
 
    
 
 
    
-Section 23.1 [container.requirements] paragraph 10 does limit conditions under
+Section 23.2 [container.requirements] paragraph 10 does limit conditions under
 which exceptions may be thrown, but applies only to "all container
 types defined in this clause" and so excludes basic_string::swap
 because it is defined elsewhere.
 
    
 
 
    
-Eric Niebler points out that 21.3 [basic.string] paragraph 5 explicitly
+Eric Niebler points out that 21.4 [basic.string] paragraph 5 explicitly
 permits basic_string::swap to invalidates iterators, which is
-disallowed by 23.1 [container.requirements] paragraph 10. Thus the standard would
+disallowed by 23.2 [container.requirements] paragraph 10. Thus the standard would
 be contradictory if it were read or extended to read as having
-basic_string meet 23.1 [container.requirements] paragraph 10 requirements.
+basic_string meet 23.2 [container.requirements] paragraph 10 requirements.
 
    
 
 
    
 Yet several LWG members have expressed the belief that the original
 intent was that basic_string::swap should not throw exceptions as
-specified by 23.1 [container.requirements] paragraph 10, and that the standard is
+specified by 23.2 [container.requirements] paragraph 10, and that the standard is
 unclear on this issue. The complexity of basic_string::swap is
 specified as "constant time", indicating the intent was to avoid
 copying (which could cause a bad_alloc or other exception). An
@@ -17391,7 +18205,7 @@ exception-safe code.
 
 
    
 Note: There remains long standing concern over whether or not it is
-possible to reasonably meet the 23.1 [container.requirements] paragraph 10 swap
+possible to reasonably meet the 23.2 [container.requirements] paragraph 10 swap
 requirements when allocators are unequal. The specification of
 basic_string::swap exception requirements is in no way intended to
 address, prejudice, or otherwise impact that concern.
@@ -17405,7 +18219,7 @@ address, prejudice, or otherwise impact that concern.
 
 
    Proposed resolution:
    
 
    
-In 21.3.6.8 [string::swap], add a throws clause:
+In 21.4.6.8 [string::swap], add a throws clause:
 
    
 
 
    
@@ -17418,9 +18232,9 @@ Throws: Shall not throw exceptions.
 
 
    
 
    404. May a replacement allocation function be declared inline?
    
-
    Section: 17.4.3.5 [replacement.functions], 18.5.1 [new.delete] Status: WP
- Submitter: Matt Austern Date: 2003-04-24
    
-
    View all issues with WP status.
    
+
    Section: 17.6.3.6 [replacement.functions], 18.6.1 [new.delete] Status: CD1
+ Submitter: Matt Austern Opened: 2003-04-24  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 The eight basic dynamic memory allocation functions (single-object
@@ -17432,12 +18246,12 @@ in preference to the implementation's definition.
 
 
    
 Three different parts of the standard mention requirements on
-replacement functions: 17.4.3.5 [replacement.functions], 18.5.1.1 [new.delete.single]
-and 18.5.1.2 [new.delete.array], and 3.7.2 [basic.stc.auto].
+replacement functions: 17.6.3.6 [replacement.functions], 18.6.1.1 [new.delete.single]
+and 18.6.1.2 [new.delete.array], and 3.7.3 [basic.stc.auto].
 
    
 
 
    None of these three places say whether a replacement function may
-  be declared inline.  18.5.1.1 [new.delete.single] paragraph 2 specifies a
+  be declared inline.  18.6.1.1 [new.delete.single] paragraph 2 specifies a
   signature for the replacement function, but that's not enough:
   the inline specifier is not part of a function's signature.
   One might also reason from 7.1.2 [dcl.fct.spec] paragraph 2, which
@@ -17450,7 +18264,7 @@ and 18.5.1.2 [new.delete.array], and 3.7.2 [basic.stc.auto].
 
 
    Proposed resolution:
    
 
    
-Add a new sentence to the end of 17.4.3.5 [replacement.functions] paragraph 3:
+Add a new sentence to the end of 17.6.3.6 [replacement.functions] paragraph 3:
 "The program's definitions shall not be specified as inline.
 No diagnostic is required."
 
    
@@ -17475,13 +18289,13 @@ believed to be of limited value.
 
 
    
 
    405. qsort and POD
    
-
    Section: 25.4 [alg.c.library] Status: WP
- Submitter: Ray Lischner Date: 2003-04-08
    
+
    Section: 25.6 [alg.c.library] Status: CD1
+ Submitter: Ray Lischner Opened: 2003-04-08  Last modified: 2008-09-26
    
 
    View all other issues in [alg.c.library].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-Section 25.4 [alg.c.library] describes bsearch and qsort, from the C
+Section 25.6 [alg.c.library] describes bsearch and qsort, from the C
 standard library. Paragraph 4 does not list any restrictions on qsort,
 but it should limit the base parameter to point to POD.  Presumably,
 qsort sorts the array by copying bytes, which requires POD.
@@ -17490,7 +18304,7 @@ qsort sorts the array by copying bytes, which requires POD.
 
 
    Proposed resolution:
    
 
    
-In 25.4 [alg.c.library] paragraph 4, just after the declarations and
+In 25.6 [alg.c.library] paragraph 4, just after the declarations and
 before the nonnormative note, add these words: "both of which have the
 same behavior as the original declaration.  The behavior is undefined
 unless the objects in the array pointed to by base are of POD
@@ -17507,10 +18321,10 @@ type."
 
 
    
 
    406. vector::insert(s) exception safety
    
-
    Section: 23.2.6.4 [vector.modifiers] Status: DR
- Submitter: Dave Abrahams Date: 2003-04-27
    
+
    Section: 23.3.6.4 [vector.modifiers] Status: CD1
+ Submitter: Dave Abrahams Opened: 2003-04-27  Last modified: 2009-05-01
    
 
    View all other issues in [vector.modifiers].
    
-
    View all issues with DR status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 There is a possible defect in the standard: the standard text was
@@ -17524,7 +18338,7 @@ existing implementation.
 
 
 
    Proposed resolution:
    
-
    Replace 23.2.6.4 [vector.modifiers] paragraph 1 with:
    
+
    Replace 23.3.6.4 [vector.modifiers] paragraph 1 with:
    
 
    
   1- Notes: Causes reallocation if the new size is greater than the
   old capacity. If no reallocation happens, all the iterators and
@@ -17543,14 +18357,14 @@ existing implementation.
 
 
    
 
    407. Can singular iterators be destroyed?
    
-
    Section: 24.1 [iterator.requirements] Status: WP
- Submitter: Nathan Myers Date: 2003-06-03
    
-
    View other active issues in [iterator.requirements].
    
-
    View all other issues in [iterator.requirements].
    
-
    View all issues with WP status.
    
+
    Section: 24.2 [iterator.concepts] Status: CD1
+ Submitter: Nathan Myers Opened: 2003-06-03  Last modified: 2008-09-30
    
+
    View other active issues in [iterator.concepts].
    
+
    View all other issues in [iterator.concepts].
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-Clause 24.1 [iterator.requirements], paragraph 5, says that the only expression
+Clause 24.2 [iterator.concepts], paragraph 5, says that the only expression
 that is defined for a singular iterator is "an assignment of a
 non-singular value to an iterator that holds a singular value".  This 
 means that destroying a singular iterator (e.g. letting an automatic
@@ -17572,13 +18386,13 @@ of a non-singular value to an iterator that holds a singular value."
 
 
    
 
    409. Closing an fstream should clear error state
    
-
    Section: 27.8.1.9 [ifstream.members], 27.8.1.13 [ofstream.members] Status: DR
- Submitter: Nathan Myers Date: 2003-06-03
    
+
    Section: 27.9.1.9 [ifstream.members], 27.9.1.13 [ofstream.members] Status: CD1
+ Submitter: Nathan Myers Opened: 2003-06-03  Last modified: 2009-05-01
    
 
    View all other issues in [ifstream.members].
    
-
    View all issues with DR status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-A strict reading of 27.8.1 [fstreams] shows that opening or
+A strict reading of 27.9.1 [fstreams] shows that opening or
 closing a basic_[io]fstream does not affect the error bits.  This
 means, for example, that if you read through a file up to EOF, and
 then close the stream and reopen it at the beginning of the file,
@@ -17597,7 +18411,7 @@ language, those considerations no longer apply.
 
 
    Proposed resolution:
    
 
-
    Change 27.8.1.9 [ifstream.members], para. 3 from:
    
+
    Change 27.9.1.9 [ifstream.members], para. 3 from:
    
 
 
    
 Calls rdbuf()->open(s,mode|in). If that function returns a null
@@ -17612,7 +18426,7 @@ returns a null pointer, calls setstate(failbit) (which may throw
 ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
 
    
 
-
    Change 27.8.1.13 [ofstream.members], para. 3 from:
    
+
    Change 27.9.1.13 [ofstream.members], para. 3 from:
    
 
 
    Calls rdbuf()->open(s,mode|out). If that function
 returns a null pointer, calls setstate(failbit) (which may throw
@@ -17626,7 +18440,7 @@ returns a null pointer, calls setstate(failbit) (which may throw
 ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
 
    
 
-
    Change 27.8.1.17 [fstream.members], para. 3 from:
    
+
    Change 27.9.1.17 [fstream.members], para. 3 from:
    
 
 
    Calls rdbuf()->open(s,mode), If that function returns
 a null pointer, calls setstate(failbit), (which may throw
@@ -17662,22 +18476,22 @@ flags.]
    
 
 
    
 
    410. Missing semantics for stack and queue comparison operators
    
-
    Section: 23.2.4.1 [list.cons], 23.2.4.3 [list.modifiers] Status: WP
- Submitter: Hans Bos Date: 2003-06-07
    
+
    Section: 23.3.4.1 [list.cons], 23.3.4.3 [list.modifiers] Status: CD1
+ Submitter: Hans Bos Opened: 2003-06-07  Last modified: 2008-09-26
    
 
    View all other issues in [list.cons].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-Sections 23.2.4.1 [list.cons] and 23.2.4.3 [list.modifiers] list
+Sections 23.3.4.1 [list.cons] and 23.3.4.3 [list.modifiers] list
 comparison operators (==, !=, <, <=, >, =>) for queue and
-stack.  Only the semantics for queue::operator== (23.2.4.1 [list.cons] par2) and queue::operator< (23.2.4.1 [list.cons]
+stack.  Only the semantics for queue::operator== (23.3.4.1 [list.cons] par2) and queue::operator< (23.3.4.1 [list.cons]
 par3) are defined.
 
    
 
 
 
    Proposed resolution:
    
 
-
    Add the following new paragraphs after 23.2.4.1 [list.cons]
+
    Add the following new paragraphs after 23.3.4.1 [list.cons]
   paragraph 3:
    
 
 
    
@@ -17700,7 +18514,7 @@ par3) are defined.
 
 
    
 
-
    Add the following paragraphs at the end of 23.2.4.3 [list.modifiers]:
    
+
    Add the following paragraphs at the end of 23.3.4.3 [list.modifiers]:
    
 
 
    
 
@@ -17746,13 +18560,13 @@ supposed to do, but we ought to spell it out.
    
 
 
    
 
    411. Wrong names of set member functions
    
-
    Section: 25.3.5 [alg.set.operations] Status: WP
- Submitter: Daniel Frey Date: 2003-07-09
    
+
    Section: 25.5.5 [alg.set.operations] Status: CD1
+ Submitter: Daniel Frey Opened: 2003-07-09  Last modified: 2008-09-26
    
 
    View all other issues in [alg.set.operations].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-25.3.5 [alg.set.operations] paragraph 1 reads:
+25.5.5 [alg.set.operations] paragraph 1 reads:
 "The semantics of the set operations are generalized to multisets in a 
 standard way by defining union() to contain the maximum number of 
 occurrences of every element, intersection() to contain the minimum, and 
@@ -17774,14 +18588,14 @@ set_intersection(), not union() and intersection().
 
 
    
 
    412. Typo in 27.4.4.3
    
-
    Section: 27.4.4.3 [iostate.flags] Status: WP
- Submitter: Martin Sebor Date: 2003-07-10
    
+
    Section: 27.5.4.3 [iostate.flags] Status: CD1
+ Submitter: Martin Sebor Opened: 2003-07-10  Last modified: 2008-09-26
    
 
    View all other issues in [iostate.flags].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Duplicate of: 429
    
 
    Discussion:
    
 
    
-The Effects clause in 27.4.4.3 [iostate.flags] paragraph 5 says that the
+The Effects clause in 27.5.4.3 [iostate.flags] paragraph 5 says that the
 function only throws if the respective bits are already set prior to
 the function call. That's obviously not the intent. The typo ought to
 be corrected and the text reworded as: "If (state &
@@ -17791,7 +18605,7 @@ exceptions()) == 0, returns. ..."
 
 
    Proposed resolution:
    
 
    
-In 27.4.4.3 [iostate.flags] paragraph 5, replace "If (rdstate() &
+In 27.5.4.3 [iostate.flags] paragraph 5, replace "If (rdstate() &
 exceptions()) == 0" with "If ((state | (rdbuf() ? goodbit : badbit))
 & exceptions()) == 0".
 
    
@@ -17810,10 +18624,10 @@ exceptions()) == 0" with "If ((state | (rdbuf() ? goodbit : badbit))
 
 
    
 
    413. Proposed resolution to LDR#64 still wrong
    
-
    Section: 27.6.1.2.3 [istream::extractors] Status: DR
- Submitter: Bo Persson Date: 2003-07-13
    
+
    Section: 27.7.1.2.3 [istream::extractors] Status: CD1
+ Submitter: Bo Persson Opened: 2003-07-13  Last modified: 2009-05-01
    
 
    View all other issues in [istream::extractors].
    
-
    View all issues with DR status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 The second sentence of the proposed resolution says:
@@ -17868,10 +18682,10 @@ then the caught exception is rethrown.
 
 
    
 
    414. Which iterators are invalidated by v.erase()?
    
-
    Section: 23.2.6.4 [vector.modifiers] Status: WP
- Submitter: Matt Austern Date: 2003-08-19
    
+
    Section: 23.3.6.4 [vector.modifiers] Status: CD1
+ Submitter: Matt Austern Opened: 2003-08-19  Last modified: 2008-09-26
    
 
    View all other issues in [vector.modifiers].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 Consider the following code fragment:
@@ -17923,7 +18737,7 @@ techniques.)
 
 
    Proposed resolution:
    
 
    
-In 23.2.6.4 [vector.modifiers] paragraph 3, change "Invalidates all the
+In 23.3.6.4 [vector.modifiers] paragraph 3, change "Invalidates all the
 iterators and references after the point of the erase" to
 "Invalidates iterators and references at or after the point of the
 erase". 
@@ -17943,9 +18757,9 @@ erase".
 
 
    
 
    415. behavior of std::ws
    
-
    Section: 27.6.1.4 [istream.manip] Status: WP
- Submitter: Martin Sebor Date: 2003-09-18
    
-
    View all issues with WP status.
    
+
    Section: 27.7.1.4 [istream.manip] Status: CD1
+ Submitter: Martin Sebor Opened: 2003-09-18  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 According to 27.6.1.4, the ws() manipulator is not required to construct
@@ -17961,7 +18775,7 @@ doesn't affect the stream's gcount).
 
 
    Proposed resolution:
    
 
    
-Add to 27.6.1.4 [istream.manip], immediately before the first sentence
+Add to 27.7.1.4 [istream.manip], immediately before the first sentence
 of paragraph 1, the following text:
 
    
 
@@ -17982,9 +18796,9 @@ of paragraph 1, the following text:
 
 
    
 
    416. definitions of XXX_MIN and XXX_MAX macros in climits
    
-
    Section: 18.2.2 [c.limits] Status: WP
- Submitter: Martin Sebor Date: 2003-09-18
    
-
    View all issues with WP status.
    
+
    Section: 18.3.2 [c.limits] Status: CD1
+ Submitter: Martin Sebor Opened: 2003-09-18  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
         
    
 
@@ -18037,7 +18851,7 @@ where the actual type is easily detectable by overload resolution.
 
    Proposed resolution:
    
 
 
    
-Change 18.2.2 [c.limits], paragraph 2:
+Change 18.3.2 [c.limits], paragraph 2:
 
    
 
 
    
@@ -18052,10 +18866,10 @@ to match the type to which they refer.--end note]
 
 
    
 
    420. is std::FILE a complete type?
    
-
    Section: 27.8.1 [fstreams] Status: WP
- Submitter: Martin Sebor Date: 2003-09-18
    
+
    Section: 27.9.1 [fstreams] Status: CD1
+ Submitter: Martin Sebor Opened: 2003-09-18  Last modified: 2008-09-26
    
 
    View all other issues in [fstreams].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 7.19.1, p2, of C99 requires that the FILE type only be declared in
@@ -18071,7 +18885,7 @@ allowed to just declare it without providing a full definition?
 
 
 
    Proposed resolution:
    
-
    In the first sentence of 27.8.1 [fstreams] paragraph 2, change
+
    In the first sentence of 27.9.1 [fstreams] paragraph 2, change
   "defined" to "declared".
    
 
 
@@ -18086,10 +18900,10 @@ allowed to just declare it without providing a full definition?
 
 
    
 
    422. explicit specializations of member functions of class templates
    
-
    Section: 17.4.3.2 [reserved.names] Status: WP
- Submitter: Martin Sebor Date: 2003-09-18
    
+
    Section: 17.6.3.3 [reserved.names] Status: CD1
+ Submitter: Martin Sebor Opened: 2003-09-18  Last modified: 2008-09-26
    
 
    View all other issues in [reserved.names].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 It has been suggested that 17.4.3.1, p1 may or may not allow programs to
@@ -18106,7 +18920,7 @@ the program) by relying on the "as if" rule.
 
    Proposed resolution:
    
 
 
    
-  Add the following sentence to 17.4.3.2 [reserved.names], p1:
+  Add the following sentence to 17.6.3.3 [reserved.names], p1:
 
    
 
 
    
@@ -18154,9 +18968,9 @@ use the right wording.]
    
 
 
    
 
    425. return value of std::get_temporary_buffer
    
-
    Section: 20.7.8 [temporary.buffer] Status: WP
- Submitter: Martin Sebor Date: 2003-09-18
    
-
    View all issues with WP status.
    
+
    Section: 20.8.9 [temporary.buffer] Status: CD1
+ Submitter: Martin Sebor Opened: 2003-09-18  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 The standard is not clear about the requirements on the value returned from
@@ -18169,7 +18983,7 @@ is when the argument is less than 0.
 
 
 
    Proposed resolution:
    
-
    Change 20.5.3 [meta.help] paragraph 2 from "...or a pair of 0
+
    Change 20.6.3 [meta.help] paragraph 2 from "...or a pair of 0
 values if no storage can be obtained" to "...or a pair of 0 values if
 no storage can be obtained or if n <= 0."
    
 
    [Kona: Matt provided wording]
    
@@ -18180,10 +18994,10 @@ no storage can be obtained or if n <= 0."
    
 
 
    
 
    426. search_n(), fill_n(), and generate_n() with negative n
    
-
    Section: 25.1.12 [alg.search], 25.2.6 [alg.fill], 25.2.7 [alg.generate] Status: WP
- Submitter: Martin Sebor Date: 2003-09-18
    
+
    Section: 25.3.12 [alg.search], 25.4.6 [alg.fill], 25.4.7 [alg.generate] Status: CD1
+ Submitter: Martin Sebor Opened: 2003-09-18  Last modified: 2008-09-26
    
 
    View all other issues in [alg.search].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 The complexity requirements for these function templates are incorrect
@@ -18260,10 +19074,10 @@ or 0 otherwise) assignments.
 
 
    
 
    428. string::erase(iterator) validity
    
-
    Section: 21.3.6.5 [string::erase] Status: WP
- Submitter: Martin Sebor Date: 2003-09-18
    
+
    Section: 21.4.6.5 [string::erase] Status: CD1
+ Submitter: Martin Sebor Opened: 2003-09-18  Last modified: 2008-09-26
    
 
    View all other issues in [string::erase].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 23.1.1, p3 along with Table 67 specify as a prerequisite for a.erase(q)
@@ -18282,7 +19096,7 @@ which is most likely not the intent.
 
 
 
    Proposed resolution:
    
-
    Remove 21.3.6.5 [string::erase] paragraph 5.
    
+
    Remove 21.4.6.5 [string::erase] paragraph 5.
    
 
 
 
    Rationale:
    
@@ -18298,10 +19112,10 @@ which is most likely not the intent.
 
 
    
 
    432. stringbuf::overflow() makes only one write position available
    
-
    Section: 27.7.1.4 [stringbuf.virtuals] Status: WP
- Submitter: Christian W Brock Date: 2003-09-24
    
+
    Section: 27.8.1.4 [stringbuf.virtuals] Status: CD1
+ Submitter: Christian W Brock Opened: 2003-09-24  Last modified: 2008-09-26
    
 
    View all other issues in [stringbuf.virtuals].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    27.7.1.3 par 8 says:
    
 
    
@@ -18519,7 +19333,7 @@ newoff + off to the next pointer xnext .
 
    
 
    
 -12- _ If (newoff + off) < 0, or if (newoff + off) refers to an
-uninitialized character (as defined in 27.7.1.3 [stringbuf.members]
+uninitialized character (as defined in 27.8.1.3 [stringbuf.members]
 paragraph 1), the positioning operation fails. Otherwise, the function
 assigns xbeg + newoff + off to the next pointer xnext .
 
    
@@ -18584,10 +19398,10 @@ initialized range.
    
 
 
    
 
    434. bitset::to_string() hard to use
    
-
    Section: 23.3.5.2 [bitset.members] Status: DR
- Submitter: Martin Sebor Date: 2003-10-15
    
+
    Section: 20.3.6.2 [bitset.members] Status: CD1
+ Submitter: Martin Sebor Opened: 2003-10-15  Last modified: 2009-05-01
    
 
    View all other issues in [bitset.members].
    
-
    View all issues with DR status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 It has been pointed out a number of times that the bitset to_string() member
@@ -18639,10 +19453,10 @@ to_string() member function template:
    
 
 
    
 
    435. bug in DR 25
    
-
    Section: 21.3.8.9 [string.io] Status: WP
- Submitter: Martin Sebor Date: 2003-10-15
    
+
    Section: 21.4.8.9 [string.io] Status: CD1
+ Submitter: Martin Sebor Opened: 2003-10-15  Last modified: 2008-09-26
    
 
    View all other issues in [string.io].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
 
    
@@ -18703,9 +19517,9 @@ iostreams where the operator does truncate).
 
 
    
 
    436. are cv-qualified facet types valid facets?
    
-
    Section: 22.1.1.1.2 [locale.facet] Status: WP
- Submitter: Martin Sebor Date: 2003-10-15
    
-
    View all issues with WP status.
    
+
    Section: 22.3.1.1.2 [locale.facet] Status: CD1
+ Submitter: Martin Sebor Opened: 2003-10-15  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 Is "const std::ctype<char>" a valid template argument to has_facet, use_facet,
@@ -18737,13 +19551,14 @@ text.]
    
 
 
    
 
    438. Ambiguity in the "do the right thing" clause
    
-
    Section: 23.1.3 [sequence.reqmts] Status: DR
- Submitter: Howard Hinnant Date: 2003-10-20
    
+
    Section: 23.2.3 [sequence.reqmts] Status: CD1
+ Submitter: Howard Hinnant Opened: 2003-10-20  Last modified: 2009-05-01
    
+
    View other active issues in [sequence.reqmts].
    
 
    View all other issues in [sequence.reqmts].
    
-
    View all issues with DR status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
-
    Section 23.1.3 [sequence.reqmts], paragraphs 9-11, fixed up the problem
+
    Section 23.2.3 [sequence.reqmts], paragraphs 9-11, fixed up the problem
 noticed with statements like:
    
 
    vector<int> v(10, 1);
 
    
@@ -18941,7 +19756,7 @@ T implicit_cast(const U& u)
 
 
    Proposed resolution:
    
 
-
    Replace 23.1.3 [sequence.reqmts] paragraphs 9 - 11 with:
    
+
    Replace 23.2.3 [sequence.reqmts] paragraphs 9 - 11 with:
    
 
 
    For every sequence defined in this clause and in clause lib.strings:
    
 
@@ -19077,20 +19892,20 @@ implicitly convertible to B.
 
 
    
 
    441. Is fpos::state const?
    
-
    Section: 27.4.3 [fpos] Status: WP
- Submitter: Vincent Leloup Date: 2003-11-17
    
+
    Section: 27.5.3 [fpos] Status: CD1
+ Submitter: Vincent Leloup Opened: 2003-11-17  Last modified: 2008-09-26
    
 
    View all other issues in [fpos].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-In section 27.4.3.1 [fpos.members] fpos<stateT>::state() is declared
-non const, but in section 27.4.3 [fpos] it is declared const.
+In section 27.5.3.1 [fpos.members] fpos<stateT>::state() is declared
+non const, but in section 27.5.3 [fpos] it is declared const.
 
    
 
 
 
    Proposed resolution:
    
 
    
-In section 27.4.3.1 [fpos.members], change the declaration of 
+In section 27.5.3.1 [fpos.members], change the declaration of 
 fpos<stateT>::state() to const.
 
    
 
@@ -19100,14 +19915,14 @@ In section 27.4.3.1 [fpos.members], change the declaration of
 
 
    
 
    442. sentry::operator bool() inconsistent signature
    
-
    Section: 27.6.2.4 [ostream::sentry] Status: WP
- Submitter: Vincent Leloup Date: 2003-11-18
    
+
    Section: 27.7.2.4 [ostream::sentry] Status: CD1
+ Submitter: Vincent Leloup Opened: 2003-11-18  Last modified: 2008-09-26
    
 
    View other active issues in [ostream::sentry].
    
 
    View all other issues in [ostream::sentry].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-In section 27.6.2.4 [ostream::sentry] paragraph 4, in description part
+In section 27.7.2.4 [ostream::sentry] paragraph 4, in description part
 basic_ostream<charT, traits>::sentry::operator bool() is declared
 as non const, but in section 27.6.2.3, in synopsis it is declared
 const.
@@ -19116,7 +19931,7 @@ const.
 
 
    Proposed resolution:
    
 
    
-In section 27.6.2.4 [ostream::sentry] paragraph 4, change the declaration
+In section 27.7.2.4 [ostream::sentry] paragraph 4, change the declaration
 of sentry::operator bool() to const.
 
    
 
@@ -19126,13 +19941,13 @@ of sentry::operator bool() to const.
 
 
    
 
    443. filebuf::close() inconsistent use of EOF
    
-
    Section: 27.8.1.4 [filebuf.members] Status: WP
- Submitter: Vincent Leloup Date: 2003-11-20
    
+
    Section: 27.9.1.4 [filebuf.members] Status: CD1
+ Submitter: Vincent Leloup Opened: 2003-11-20  Last modified: 2008-09-26
    
 
    View all other issues in [filebuf.members].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-In section 27.8.1.4 [filebuf.members] par6, in effects description of
+In section 27.9.1.4 [filebuf.members] par6, in effects description of
 basic_filebuf<charT, traits>::close(), overflow(EOF) is used twice;
 should be overflow(traits::eof()).
 
    
@@ -19149,13 +19964,13 @@ Change overflow(EOF) to overflow(traits::eof()).
 
 
    
 
    444. Bad use of casts in fstream
    
-
    Section: 27.8.1 [fstreams] Status: DR
- Submitter: Vincent Leloup Date: 2003-11-20
    
+
    Section: 27.9.1 [fstreams] Status: CD1
+ Submitter: Vincent Leloup Opened: 2003-11-20  Last modified: 2009-05-01
    
 
    View all other issues in [fstreams].
    
-
    View all issues with DR status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
-
    27.8.1.9 [ifstream.members] p1, 27.8.1.13 [ofstream.members] p1,
-27.8.1.17 [fstream.members] p1 seems have same problem as exposed in
+
    27.9.1.9 [ifstream.members] p1, 27.9.1.13 [ofstream.members] p1,
+27.9.1.17 [fstream.members] p1 seems have same problem as exposed in
 LWG issue
 252.
 
    
@@ -19208,9 +20023,10 @@ LWG issue
 
 
    
 
    445. iterator_traits::reference unspecified for some iterator categories
    
-
    Section: 24.3.1 [iterator.traits] Status: DR
- Submitter: Dave Abrahams Date: 2003-12-09
    
-
    View all issues with DR status.
    
+
    Section: D.10.1 [iterator.traits] Status: CD1
+ Submitter: Dave Abrahams Opened: 2003-12-09  Last modified: 2009-05-01
    
+
    View all other issues in [iterator.traits].
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 The standard places no restrictions at all on the reference type
@@ -19305,7 +20121,7 @@ so I've changed the wording to say that those types may be
 
 
    Proposed resolution:
    
 
-
    In 24.3.1 [iterator.traits], after:
    
+
    In D.10.1 [iterator.traits], after:
    
 
 
    
 be defined as the iterator's difference type, value type and iterator
@@ -19324,7 +20140,7 @@ is, the same type as the type of *a and a->,
 respectively.
    
 
    
 
-
    In 24.3.1 [iterator.traits], change:
    
+
    In D.10.1 [iterator.traits], change:
    
 
 
    
 In the case of an output iterator, the types
    
@@ -19345,7 +20161,7 @@ iterator_traits<Iterator>::pointer
 
    may be defined as void.
    
 
    
 
-
    In 24.5.3 [istreambuf.iterator], change:
    
+
    In 24.6.3 [istreambuf.iterator], change:
    
 
    
 
    typename traits::off_type, charT*, charT&>
 
    
@@ -19373,10 +20189,11 @@ needed to be changed.
 
 
    
 
    448. Random Access Iterators over abstract classes
    
-
    Section: 24.1.5 [random.access.iterators] Status: WP
- Submitter: Dave Abrahams Date: 2004-01-07
    
+
    Section: 24.2.6 [random.access.iterators] Status: CD1
+ Submitter: Dave Abrahams Opened: 2004-01-07  Last modified: 2008-09-26
    
+
    View other active issues in [random.access.iterators].
    
 
    View all other issues in [random.access.iterators].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 Table 76, the random access iterator requirement table, says that the
@@ -19397,10 +20214,10 @@ Change the return type to "convertible to T const&".
 
 
    
 
    449. Library Issue 306 Goes Too Far
    
-
    Section: 18.1 [support.types] Status: WP
- Submitter: Pete Becker Date: 2004-01-15
    
+
    Section: 18.2 [support.types] Status: CD1
+ Submitter: Pete Becker Opened: 2004-01-15  Last modified: 2008-09-26
    
 
    View all other issues in [support.types].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    Original text:
    
 
    
@@ -19439,10 +20256,10 @@ undefined."
 
 
    
 
    453. basic_stringbuf::seekoff need not always fail for an empty stream
    
-
    Section: 27.7.1.4 [stringbuf.virtuals] Status: WP
- Submitter: Bill Plauger Date: 2004-01-30
    
+
    Section: 27.8.1.4 [stringbuf.virtuals] Status: CD1
+ Submitter: Bill Plauger Opened: 2004-01-30  Last modified: 2008-09-26
    
 
    View all other issues in [stringbuf.virtuals].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
      pos_type basic_stringbuf::seekoff(off_type, ios_base::seekdir,
                                     ios_base::openmode);
@@ -19482,10 +20299,10 @@ is nonzero, the positioning operation fails.
 
 
    
 
    455. cerr::tie() and wcerr::tie() are overspecified
    
-
    Section: 27.3 [iostream.objects] Status: DR
- Submitter: Bill Plauger Date: 2004-01-30
    
+
    Section: 27.4 [iostream.objects] Status: CD1
+ Submitter: Bill Plauger Opened: 2004-01-30  Last modified: 2009-05-01
    
 
    View all other issues in [iostream.objects].
    
-
    View all issues with DR status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 Both cerr::tie() and wcerr::tie() are obliged to be null at program
@@ -19524,10 +20341,10 @@ Its state is otherwise the same as required for basic_ios<wchar_t>::init
 
 
    
 
    456. Traditional C header files are overspecified
    
-
    Section: 17.4.1.2 [headers] Status: WP
- Submitter: Bill Plauger Date: 2004-01-30
    
+
    Section: 17.6.1.2 [headers] Status: CD1
+ Submitter: Bill Plauger Opened: 2004-01-30  Last modified: 2008-09-26
    
 
    View all other issues in [headers].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
 
    The C++ Standard effectively requires that the traditional C headers
@@ -19615,7 +20432,7 @@ declaring C names in headers.
 
 
    Proposed resolution:
    
 
    
-Add to 17.4.1.2 [headers], para. 4:
+Add to 17.6.1.2 [headers], para. 4:
 
    
 
 
    
@@ -19643,7 +20460,7 @@ as if each name placed in the Standard library namespace by the corresponding
 namespace scope. of the namespace std and is followed
 by an explicit using-declaration (7.3.3 [namespace.udecl]).
 It is unspecified whether these names are first declared or defined within
-namespace scope (3.3.5 [basic.scope.namespace]) of the namespace
+namespace scope (3.3.6 [basic.scope.namespace]) of the namespace
 std and are then injected into the global namespace scope by explicit
 using-declarations (7.3.3 [namespace.udecl]).
 
    
@@ -19664,10 +20481,10 @@ names within the namespace std. -- end example]
 
 
    
 
    457. bitset constructor: incorrect number of initialized bits
    
-
    Section: 23.3.5.1 [bitset.cons] Status: DR
- Submitter: Dag Henriksson Date: 2004-01-30
    
+
    Section: 20.3.6.1 [bitset.cons] Status: CD1
+ Submitter: Dag Henriksson Opened: 2004-01-30  Last modified: 2009-05-01
    
 
    View all other issues in [bitset.cons].
    
-
    View all issues with DR status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 The constructor from unsigned long says it initializes "the first M
@@ -19684,7 +20501,7 @@ guaranteed to have any corresponding bit values in val.
 
 
 
    Proposed resolution:
    
-
    In 23.3.5.1 [bitset.cons] paragraph 2, change "M is the smaller of
+
    In 20.3.6.1 [bitset.cons] paragraph 2, change "M is the smaller of
   N and the value CHAR_BIT * sizeof (unsigned long). (249)" to
   "M is the smaller of N and the number of bits in
   the value representation (section 3.9 [basic.types]) of unsigned
@@ -19697,10 +20514,10 @@ guaranteed to have any corresponding bit values in val.
 
 
    
 
    460. Default modes missing from basic_fstream member specifications
    
-
    Section: 27.8.1 [fstreams] Status: DR
- Submitter: Ben Hutchings Date: 2004-04-01
    
+
    Section: 27.9.1 [fstreams] Status: CD1
+ Submitter: Ben Hutchings Opened: 2004-04-01  Last modified: 2009-05-01
    
 
    View all other issues in [fstreams].
    
-
    View all issues with DR status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 The second parameters of the non-default constructor and of the open
@@ -19714,14 +20531,14 @@ that it is intended to be callable with one argument.
 
 
 
    Proposed resolution:
    
-
    In 27.8.1.15 [fstream.cons], change
    
+
    In 27.9.1.15 [fstream.cons], change
    
 
      explicit basic_fstream(const char* s, ios_base::openmode mode); 
 
    
 
    to
    
 
      explicit basic_fstream(const char* s,
                          ios_base::openmode mode = ios_base::in|ios_base::out);
 
    
-
    In 27.8.1.17 [fstream.members], change
    
+
    In 27.9.1.17 [fstream.members], change
    
 
      void open(const char*s, ios_base::openmode mode); 
 
    
 
    to
    
@@ -19735,9 +20552,9 @@ that it is intended to be callable with one argument.
 
 
    
 
    461. time_get hard or impossible to implement
    
-
    Section: 22.2.5.1.2 [locale.time.get.virtuals] Status: WP
- Submitter: Bill Plauger Date: 2004-03-23
    
-
    View all issues with WP status.
    
+
    Section: 22.4.5.1.2 [locale.time.get.virtuals] Status: CD1
+ Submitter: Bill Plauger Opened: 2004-03-23  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 Template time_get currently contains difficult, if not impossible,
@@ -19840,10 +20657,10 @@ An implementation may also accept additional implementation-defined formats.
 
 
    
 
    464. Suggestion for new member functions in standard containers
    
-
    Section: 23.2.6 [vector], 23.3.1 [map] Status: WP
- Submitter: Thorsten Ottosen Date: 2004-05-12
    
+
    Section: 23.3.6 [vector], 23.4.1 [map] Status: CD1
+ Submitter: Thorsten Ottosen Opened: 2004-05-12  Last modified: 2008-09-26
    
 
    View all other issues in [vector].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
 
    To add slightly more convenience to vector<T> and map<Key,T> we should consider to add
    
@@ -19870,14 +20687,14 @@ at() (which will then throw if the vector is empty). 
 
 
 
    Proposed resolution:
    
-
    In 23.2.6 [vector], add the following to the vector
+
    In 23.3.6 [vector], add the following to the vector
   synopsis after "element access" and before "modifiers":
    
 
      // [lib.vector.data] data access
   pointer       data();
   const_pointer data() const;
 
    
 
-
    Add a new subsection of 23.2.6 [vector]:
    
+
    Add a new subsection of 23.3.6 [vector]:
    
 
    
 
    23.2.4.x vector data access
    
 
       pointer       data();
@@ -19889,13 +20706,13 @@ at() (which will then throw if the vector is empty). 
 
    Throws: Nothing.
    
 
    
 
-
    In 23.3.1 [map], add the following to the map
+
    In 23.4.1 [map], add the following to the map
 synopsis immediately after the line for operator[]:
    
 
      T&       at(const key_type& x);
   const T& at(const key_type& x) const;
 
    
 
-
    Add the following to 23.3.1.2 [map.access]:
    
+
    Add the following to 23.4.1.2 [map.access]:
    
 
    
 
      T&       at(const key_type& x);
   const T& at(const key_type& x) const;
@@ -19921,15 +20738,15 @@ synopsis immediately after the line for operator[]:
    
 
 
    
 
    465. Contents of <ciso646>
    
-
    Section: 17.4.1.2 [headers] Status: WP
- Submitter: Steve Clamage Date: 2004-06-03
    
+
    Section: 17.6.1.2 [headers] Status: CD1
+ Submitter: Steve Clamage Opened: 2004-06-03  Last modified: 2008-09-26
    
 
    View all other issues in [headers].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    C header <iso646.h> defines macros for some operators, such as
 not_eq for !=.
    
 
-
    Section 17.4.1.2 [headers] "Headers" says that except as noted in
+
    Section 17.6.1.2 [headers] "Headers" says that except as noted in
 clauses 18 through 27, the <cname> C++ header contents are the same
 as the C header <name.h>. In particular, table 12 lists
 <ciso646> as a C++ header.
    
@@ -19968,9 +20785,9 @@ or <ciso646> has no effect. 
    
 
 
    
 
    467. char_traits::lt(), compare(), and memcmp()
    
-
    Section: 21.1.3.1 [char.traits.specializations.char] Status: WP
- Submitter: Martin Sebor Date: 2004-06-28
    
-
    View all issues with WP status.
    
+
    Section: 21.2.3.1 [char.traits.specializations.char] Status: CD1
+ Submitter: Martin Sebor Opened: 2004-06-28  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
 
    
@@ -20019,10 +20836,10 @@ imposed by Table 37 on compare() when char is signed.
 
 
    
 
    468. unexpected consequences of ios_base::operator void*()
    
-
    Section: 27.4.4.3 [iostate.flags] Status: WP
- Submitter: Martin Sebor Date: 2004-06-28
    
+
    Section: 27.5.4.3 [iostate.flags] Status: CD1
+ Submitter: Martin Sebor Opened: 2004-06-28  Last modified: 2008-09-26
    
 
    View all other issues in [iostate.flags].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
 
    The program below is required to compile but when run it typically
@@ -20091,10 +20908,10 @@ the value need not be valid.
 
 
    
 
    469. vector<bool> ill-formed relational operators
    
-
    Section: 23.2.6 [vector] Status: DR
- Submitter: Martin Sebor Date: 2004-06-28
    
+
    Section: 23.3.6 [vector] Status: CD1
+ Submitter: Martin Sebor Opened: 2004-06-28  Last modified: 2009-05-01
    
 
    View all other issues in [vector].
    
-
    View all issues with DR status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
 
    
@@ -20118,10 +20935,10 @@ vector<bool> from [lib.vector.bool].
 
 
    
 
    474. confusing Footnote 297
    
-
    Section: 27.6.2.6.4 [ostream.inserters.character] Status: WP
- Submitter: Martin Sebor Date: 2004-07-01
    
+
    Section: 27.7.2.6.4 [ostream.inserters.character] Status: CD1
+ Submitter: Martin Sebor Opened: 2004-07-01  Last modified: 2008-09-26
    
 
    View all other issues in [ostream.inserters.character].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
 
    
@@ -20142,10 +20959,11 @@ 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.4 [alg.foreach] Status: WP
- Submitter: Stephan T. Lavavej, Jaakko Jarvi Date: 2004-07-09
    
+
    Section: 25.3.4 [alg.foreach] Status: CD1
+ Submitter: Stephan T. Lavavej, Jaakko Jarvi Opened: 2004-07-09  Last modified: 2008-09-26
    
+
    View other active issues in [alg.foreach].
    
 
    View all other issues in [alg.foreach].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 It is not clear whether the function object passed to for_each is allowed to
@@ -20207,7 +21025,7 @@ passed to for_each modify its argument.
    
 
 
 
    Proposed resolution:
    
-
    Add a nonnormative note to the Effects in 25.1.4 [alg.foreach]: If
+
    Add a nonnormative note to the Effects in 25.3.4 [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.
@@ -20227,10 +21045,10 @@ passed to it.
 
 
    
 
    478. Should forward iterator requirements table have a line for r->m?
    
-
    Section: 24.1.3 [forward.iterators] Status: WP
- Submitter: Dave Abrahams Date: 2004-07-11
    
+
    Section: 24.2.4 [forward.iterators] Status: CD1
+ Submitter: Dave Abrahams Opened: 2004-07-11  Last modified: 2008-09-26
    
 
    View all other issues in [forward.iterators].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Duplicate of: 477
    
 
    Discussion:
    
 
    
@@ -20296,9 +21114,9 @@ This is a defect because it constrains an lvalue to returning a modifiable lvalu
 
 
    
 
    488. rotate throws away useful information
    
-
    Section: 25.2.11 [alg.rotate] Status: WP
- Submitter: Howard Hinnant Date: 2004-11-22
    
-
    View all issues with WP status.
    
+
    Section: 25.4.11 [alg.rotate] Status: CD1
+ Submitter: Howard Hinnant Opened: 2004-11-22  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 rotate takes 3 iterators:  first, middle and last which point into a
@@ -20345,14 +21163,14 @@ a significant benefit to the change.
                 ForwardIterator last);
 
    
 
-
    In 25.2.11 [alg.rotate], change:
    
+
    In 25.4.11 [alg.rotate], change:
    
 
 
      template<class ForwardIterator>
     void ForwardIterator rotate(ForwardIterator first, ForwardIterator middle,
                 ForwardIterator last);
 
    
 
-
    In 25.2.11 [alg.rotate] insert a new paragraph after p1:
    
+
    In 25.4.11 [alg.rotate] insert a new paragraph after p1:
    
 
 
    
 
    Returns: first + (last - middle).
    
@@ -20382,10 +21200,11 @@ Toronto: moved to Ready.
 
 
    
 
    495. Clause 22 template parameter requirements
    
-
    Section: 22 [localization] Status: WP
- Submitter: Beman Dawes Date: 2005-01-10
    
+
    Section: 22 [localization] Status: CD1
+ Submitter: Beman Dawes Opened: 2005-01-10  Last modified: 2008-09-26
    
+
    View other active issues in [localization].
    
 
    View all other issues in [localization].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    It appears that there are no requirements specified for many of the
 template parameters in clause 22. It looks like this issue has never
@@ -20421,7 +21240,7 @@ for Intl.
 
 
 
    Proposed resolution:
    
-
    Change 17.3.2.1 [type.descriptions], paragraph 1, from:
    
+
    Change 17.5.2.1 [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
@@ -20458,13 +21277,13 @@ requirements of charT (described in 21 [strings]).
 
 
    
 
    496. Illegal use of "T" in vector<bool>
    
-
    Section: 23.2.6 [vector] Status: WP
- Submitter: richard@ex-parrot.com Date: 2005-02-10
    
+
    Section: 23.3.6 [vector] Status: CD1
+ Submitter: richard@ex-parrot.com Opened: 2005-02-10  Last modified: 2008-09-26
    
 
    View all other issues in [vector].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-In the synopsis of the std::vector<bool> specialisation in 23.2.6 [vector],
+In the synopsis of the std::vector<bool> specialisation in 23.3.6 [vector],
 the non-template assign() function has the signature
    
 
 
      void assign( size_type n, const T& t );
@@ -20482,10 +21301,10 @@ the non-template assign() function has the signature
    
 
 
    
 
    497. meaning of numeric_limits::traps for floating point types
    
-
    Section: 18.2.1.2 [numeric.limits.members] Status: WP
- Submitter: Martin Sebor Date: 2005-03-02
    
+
    Section: 18.3.1.2 [numeric.limits.members] Status: CD1
+ Submitter: Martin Sebor Opened: 2005-03-02  Last modified: 2008-09-26
    
 
    View all other issues in [numeric.limits.members].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
 
    18.2.1.2, p59 says this much about the traps member of numeric_limits:
    
@@ -20545,10 +21364,10 @@ at runtime.
 
 
    
 
    505. Result_type in random distribution requirements
    
-
    Section: 26.4.1 [rand.req], TR1 5.1.1 [tr.rand.req] Status: WP
- Submitter: Walter Brown Date: 2005-07-03
    
+
    Section: X [rand.req], TR1 5.1.1 [tr.rand.req] Status: CD1
+ Submitter: Walter Brown Opened: 2005-07-03  Last modified: 2008-09-26
    
 
    View all other issues in [rand.req].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 Table 17: Random distribution requirements
@@ -20586,10 +21405,11 @@ Berlin:  Voted to WP.  N1932 adopts the proposed resolution:  see Table 5 row 1.
 
 
    
 
    507. Missing requirement for variate_generator::operator()
    
-
    Section: 26.4 [rand], TR1 5.1.3 [tr.rand.var] Status: WP
- Submitter: Walter Brown Date: 2005-07-03
    
+
    Section: 26.5 [rand], TR1 5.1.3 [tr.rand.var] Status: CD1
+ Submitter: Walter Brown Opened: 2005-07-03  Last modified: 2008-09-26
    
+
    View other active issues in [rand].
    
 
    View all other issues in [rand].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 Paragraph 11 of [tr.rand.var] equires that the member template
@@ -20628,10 +21448,10 @@ Precondition:  distribution().operator()(e,value) is well-formed.
 
 
    
 
    508. Bad parameters for ranlux64_base_01
    
-
    Section: 26.4.5 [rand.predef], TR1 5.1.5 [tr.rand.predef] Status: WP
- Submitter: Walter Brown Date: 2005-07-03
    
+
    Section: 26.5.5 [rand.predef], TR1 5.1.5 [tr.rand.predef] Status: CD1
+ Submitter: Walter Brown Opened: 2005-07-03  Last modified: 2008-09-26
    
 
    View all other issues in [rand.predef].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 The fifth of these engines with predefined parameters, ranlux64_base_01,
@@ -20712,11 +21532,11 @@ just above paragraph 5.
 
 
    
 
    518. Are insert and erase stable for unordered_multiset and unordered_multimap?
    
-
    Section: 23.1.5 [unord.req], TR1 6.3.1 [tr.unord.req] Status: WP
- Submitter: Matt Austern Date: 2005-07-03
    
+
    Section: 23.2.5 [unord.req], TR1 6.3.1 [tr.unord.req] Status: CD1
+ Submitter: Matt Austern Opened: 2005-07-03  Last modified: 2008-09-26
    
 
    View other active issues in [unord.req].
    
 
    View all other issues in [unord.req].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 Issue 371 deals with stability of multiset/multimap under insert and erase
@@ -20743,7 +21563,7 @@ Wording for the proposed resolution is taken from the equivalent text for associ
 
    
 
 
    
-Change 23.1.5 [unord.req], Unordered associative containers, paragraph 6 to:
+Change 23.2.5 [unord.req], Unordered associative containers, paragraph 6 to:
 
    
 
 
    
@@ -20759,7 +21579,7 @@ preserve the relative ordering of equivalent elements.
 
    
 
 
    
-Change 23.1.5 [unord.req], Unordered associative containers, paragraph 8 to:
+Change 23.2.5 [unord.req], Unordered associative containers, paragraph 8 to:
 
    
 
 
    
@@ -20781,11 +21601,11 @@ preserves the relative ordering of equivalent elements.
    
 
 
    
 
    519. Data() undocumented
    
-
    Section: 23.2.1 [array], TR1 6.2.2 [tr.array.array] Status: WP
- Submitter: Pete Becker Date: 2005-07-03
    
+
    Section: 23.3.1 [array], TR1 6.2.2 [tr.array.array] Status: CD1
+ Submitter: Pete Becker Opened: 2005-07-03  Last modified: 2008-09-26
    
 
    View other active issues in [array].
    
 
    View all other issues in [array].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 array<>::data() is present in the class synopsis, but not documented.
@@ -20816,9 +21636,9 @@ of data() is unspecified.
 
 
    
 
    520. Result_of and pointers to data members
    
-
    Section: 20.6.11.1 [func.bind], TR1 3.6 [tr.func.bind] Status: WP
- Submitter: Pete Becker Date: 2005-07-03
    
-
    View all issues with WP status.
    
+
    Section: 20.7.12.1 [func.bind], TR1 3.6 [tr.func.bind] Status: CD1
+ Submitter: Pete Becker Opened: 2005-07-03  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 In the original proposal for binders, the return type of bind() when
@@ -20859,9 +21679,10 @@ Peter provided wording.
 
 
    
 
    521. Garbled requirements for argument_type in reference_wrapper
    
-
    Section: 20.6.5 [refwrap], TR1 2.1.2 [tr.util.refwrp.refwrp] Status: WP
- Submitter: Pete Becker Date: 2005-07-03
    
-
    View all issues with WP status.
    
+
    Section: 20.7.5 [refwrap], TR1 2.1.2 [tr.util.refwrp.refwrp] Status: CD1
+ Submitter: Pete Becker Opened: 2005-07-03  Last modified: 2008-09-26
    
+
    View all other issues in [refwrap].
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 2.1.2/3, second bullet item currently says that reference_wrapper<T> is
@@ -20928,12 +21749,114 @@ function's cv-qualifiers); the type T1 is cv T0*
 
 
 
+
    
+
    522. Tuple doesn't define swap
    
+
    Section: 20.5 [tuple], TR1 6.1 [tr.tuple] Status: CD1
+ Submitter: Andy Koenig Opened: 2005-07-03  Last modified: 2008-09-26
    
+
    View all other issues in [tuple].
    
+
    View all issues with CD1 status.
    
+
    Discussion:
    
+
    
+Tuple doesn't define swap().  It should.
+
    
+
    [
+Berlin: Doug to provide wording.
+]
    
+
+
    [
+Batavia: Howard to provide wording.
+]
    
+
+
    [
+Toronto: Howard to provide wording (really this time).
+]
    
+
+
+
    [
+Bellevue:  Alisdair provided wording.
+]
    
+
+
+
+
+
    Proposed resolution:
    
+
+
    
+Add these signatures to 20.5 [tuple]
+
    
+
+
    template <class... Types>
+  void swap(tuple<Types...>& x, tuple<Types...>& y);
+template <class... Types>
+  void swap(tuple<Types...>&& x, tuple<Types...>& y);
+template <class... Types>
+  void swap(tuple<Types...>& x, tuple<Types...>&& y); 
+
    
+
+
    
+Add this signature to 20.5.2 [tuple.tuple]
+
    
+
+
    void swap(tuple&&);
+
    
+
+
    
+Add the following two sections to the end of the tuple clauses
+
    
+
+
    
+
    
+20.3.1.7 tuple swap [tuple.swap]
+
    
+
+
    void swap(tuple&& rhs); 
+
    
+
+
    
+
    
+Requires: Each type in Types shall be Swappable.
+
    
+
    
+Effects: Calls swap for each element in *this and its corresponding element
+in rhs.
+
    
+
    
+Throws: Nothing, unless one of the element-wise swap calls throw an
+exception. 
+
    
+
    
+
+
    
+20.3.1.8 tuple specialized algorithms [tuple.special]
+
    
+
+
    template <class... Types>
+  void swap(tuple<Types...>& x, tuple<Types...>& y);
+template <class... Types>
+  void swap(tuple<Types...>&& x, tuple<Types...>& y);
+template <class... Types>
+  void swap(tuple<Types...>& x, tuple<Types...>&& y); 
+
    
+
+
    
+
    
+Effects: x.swap(y)
+
    
+
    
+
    
+
+
+
+
+
+
 
    
 
    524. regex named character classes and case-insensitivity don't mix
    
-
    Section: 28 [re] Status: WP
- Submitter: Eric Niebler Date: 2005-07-01
    
+
    Section: 28 [re] Status: CD1
+ Submitter: Eric Niebler Opened: 2005-07-01  Last modified: 2008-09-26
    
+
    View other active issues in [re].
    
 
    View all other issues in [re].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 This defect is also being discussed on the Boost developers list. The 
@@ -21008,11 +21931,11 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
    
 
    527. tr1::bind has lost its Throws clause
    
-
    Section: 20.6.11.1.3 [func.bind.bind], TR1 3.6.3 [tr.func.bind.bind] Status: WP
- Submitter: Peter Dimov Date: 2005-10-01
    
+
    Section: 20.7.12.1.3 [func.bind.bind], TR1 3.6.3 [tr.func.bind.bind] Status: CD1
+ Submitter: Peter Dimov Opened: 2005-10-01  Last modified: 2008-09-26
    
 
    View other active issues in [func.bind.bind].
    
 
    View all other issues in [func.bind.bind].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 The original bind proposal gives the guarantee that tr1::bind(f, t1,
@@ -21076,7 +21999,7 @@ throws an exception.
 
 
    Proposed resolution:
    
 
    
-In 20.6.11.1.3 [func.bind.bind], add a new paragraph after p2:
+In 20.7.12.1.3 [func.bind.bind], add a new paragraph after p2:
 
    
 
 
    
@@ -21085,7 +22008,7 @@ in the BoundArgs... pack expansion throws an exception.
 
    
 
 
    
-In 20.6.11.1.3 [func.bind.bind], add a new paragraph after p4:
+In 20.7.12.1.3 [func.bind.bind], add a new paragraph after p4:
 
    
 
 
    
@@ -21100,17 +22023,17 @@ in the BoundArgs... pack expansion throws an exception.
 
 
    
 
    530. Must elements of a string be contiguous?
    
-
    Section: 21.3 [basic.string] Status: WP
- Submitter: Matt Austern Date: 2005-11-15
    
+
    Section: 21.4 [basic.string] Status: CD1
+ Submitter: Matt Austern Opened: 2005-11-15  Last modified: 2008-09-26
    
 
    View other active issues in [basic.string].
    
 
    View all other issues in [basic.string].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    Issue 69, which was incorporated into C++03, mandated
    that the elements of a vector must be stored in contiguous memory.
    Should the same also apply to basic_string?
    
 
-
    We almost require contiguity already. Clause 23.3.4 [multiset]
+
    We almost require contiguity already. Clause 23.4.4 [multiset]
   defines operator[] as data()[pos]. What's missing
   is a similar guarantee if we access the string's elements via the
   iterator interface.
    
@@ -21125,7 +22048,7 @@ in the BoundArgs... pack expansion throws an exception.
 
 
 
    Proposed resolution:
    
-
    Add the following text to the end of 21.3 [basic.string],
+
    Add the following text to the end of 21.4 [basic.string],
 paragraph 2. 
    
 
 
    
@@ -21154,10 +22077,10 @@ more design choices.
 
 
    
 
    531. array forms of unformatted input functions
    
-
    Section: 27.6.1.3 [istream.unformatted] Status: WP
- Submitter: Martin Sebor Date: 2005-11-23
    
+
    Section: 27.7.1.3 [istream.unformatted] Status: CD1
+ Submitter: Martin Sebor Opened: 2005-11-23  Last modified: 2008-09-26
    
 
    View all other issues in [istream.unformatted].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 The array forms of unformatted input functions don't seem to have well-defined
@@ -21230,10 +22153,10 @@ writing to out of bounds memory when n == 0.  Martin provided fix.
 
 
    
 
    533. typo in 2.2.3.10/1
    
-
    Section: 20.7.12.2.11 [util.smartptr.getdeleter], TR1 2.2.3.10 [tr.util.smartptr.getdeleter] Status: DR
- Submitter: Paolo Carlini Date: 2005-11-09
    
+
    Section: 20.8.13.2.11 [util.smartptr.getdeleter], TR1 2.2.3.10 [tr.util.smartptr.getdeleter] Status: CD1
+ Submitter: Paolo Carlini Opened: 2005-11-09  Last modified: 2009-05-01
    
 
    View all other issues in [util.smartptr.getdeleter].
    
-
    View all issues with DR status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 I'm seeing something that looks like a typo. The Return of get_deleter
@@ -21261,11 +22184,11 @@ If *this p owns a deleter d...
 
 
    
 
    534. Missing basic_string members
    
-
    Section: 21.3 [basic.string] Status: WP
- Submitter: Alisdair Meredith Date: 2005-11-16
    
+
    Section: 21.4 [basic.string] Status: CD1
+ Submitter: Alisdair Meredith Opened: 2005-11-16  Last modified: 2008-09-26
    
 
    View other active issues in [basic.string].
    
 
    View all other issues in [basic.string].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 OK, we all know std::basic_string is bloated and already has way too
@@ -21396,10 +22319,10 @@ Berlin: Has support.  Alisdair provided wording.
 
 
    
 
    535. std::string::swap specification poorly worded
    
-
    Section: 21.3.6.8 [string::swap] Status: WP
- Submitter: Beman Dawes Date: 2005-12-14
    
+
    Section: 21.4.6.8 [string::swap] Status: CD1
+ Submitter: Beman Dawes Opened: 2005-12-14  Last modified: 2008-09-26
    
 
    View all other issues in [string::swap].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 std::string::swap currently says for effects and postcondition:
@@ -21443,10 +22366,10 @@ characters that were was in s,
 
 
    
 
    537. Typos in the signatures in 27.6.1.3/42-43 and 27.6.2.4
    
-
    Section: 27.6.1.3 [istream.unformatted] Status: WP
- Submitter: Paolo Carlini Date: 2006-02-12
    
+
    Section: 27.7.1.3 [istream.unformatted] Status: CD1
+ Submitter: Paolo Carlini Opened: 2006-02-12  Last modified: 2008-09-26
    
 
    View all other issues in [istream.unformatted].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 In the most recent working draft, I'm still seeing:
@@ -21497,10 +22420,11 @@ After 27.6.2.4p3 change:
 
 
    
 
    538. 241 again: Does unique_copy() require CopyConstructible and Assignable?
    
-
    Section: 25.2.9 [alg.unique] Status: WP
- Submitter: Howard Hinnant Date: 2006-02-09
    
+
    Section: 25.4.9 [alg.unique] Status: CD1
+ Submitter: Howard Hinnant Opened: 2006-02-09  Last modified: 2008-09-26
    
+
    View other active issues in [alg.unique].
    
 
    View all other issues in [alg.unique].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 I believe I botched the resolution of
@@ -21555,10 +22479,10 @@ Otherwise CopyConstructible is not required.
 
 
    
 
    540. shared_ptr<void>::operator*()
    
-
    Section: 20.7.12.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] Status: WP
- Submitter: Martin Sebor Date: 2005-10-15
    
+
    Section: 20.8.13.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] Status: CD1
+ Submitter: Martin Sebor Opened: 2005-10-15  Last modified: 2008-09-26
    
 
    View all other issues in [util.smartptr.shared.obs].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 I'm trying to reconcile the note in tr.util.smartptr.shared.obs, p6
@@ -21613,11 +22537,11 @@ definition) of the function shall be well-formed.
 
 
    
 
    541. shared_ptr template assignment and void
    
-
    Section: 20.7.12.2 [util.smartptr.shared], TR1 2.2.3 [tr.util.smartptr.shared] Status: WP
- Submitter: Martin Sebor Date: 2005-10-16
    
+
    Section: 20.8.13.2 [util.smartptr.shared], TR1 2.2.3 [tr.util.smartptr.shared] Status: CD1
+ Submitter: Martin Sebor Opened: 2005-10-16  Last modified: 2008-09-26
    
 
    View other active issues in [util.smartptr.shared].
    
 
    View all other issues in [util.smartptr.shared].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 Is the void specialization of the template assignment operator taking
@@ -21694,10 +22618,10 @@ public:
 
 
    
 
    542. shared_ptr observers
    
-
    Section: 20.7.12.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] Status: WP
- Submitter: Martin Sebor Date: 2005-10-18
    
+
    Section: 20.8.13.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] Status: CD1
+ Submitter: Martin Sebor Opened: 2005-10-18  Last modified: 2008-09-26
    
 
    View all other issues in [util.smartptr.shared.obs].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 Peter Dimov wrote:
@@ -21734,7 +22658,7 @@ capture the intent.
 
 
    Proposed resolution:
    
 
    
-Change 20.7.12.2.5 [util.smartptr.shared.obs] p12:
+Change 20.8.13.2.5 [util.smartptr.shared.obs] p12:
 
    
 
    
 [Note: use_count() is not necessarily efficient. Use only for
@@ -21742,7 +22666,7 @@ debugging and testing purposes, not for production code. --end note
 
    
 
 
    
-Change 20.7.12.3.5 [util.smartptr.weak.obs] p3:
+Change 20.8.13.3.5 [util.smartptr.weak.obs] p3:
 
    
 
    
 [Note: use_count() is not necessarily efficient. Use only for
@@ -21755,9 +22679,9 @@ debugging and testing purposes, not for production code. --end note
 
 
    
 
    543. valarray slice default constructor
    
-
    Section: 26.5.4 [class.slice] Status: WP
- Submitter: Howard Hinnant Date: 2005-11-03
    
-
    View all issues with WP status.
    
+
    Section: 26.6.4 [class.slice] Status: CD1
+ Submitter: Howard Hinnant Opened: 2005-11-03  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 If one explicitly constructs a slice or glice with the default
@@ -21797,11 +22721,11 @@ There is a similar question and wording for gslice at 26.3.6.1p1.
 
 
    Proposed resolution:
    
 
-
    [Martin suggests removing the second sentence in 26.5.4.1 [cons.slice] as well.]
    
+
    [Martin suggests removing the second sentence in 26.6.4.1 [cons.slice] as well.]
    
 
 
 
    
-Change 26.5.4.1 [cons.slice]:
+Change 26.6.4.1 [cons.slice]:
 
    
 
 
    
@@ -21813,7 +22737,7 @@ takes a start, length, and stride parameter.
 
    
 
 
    
-Change 26.5.6.1 [gslice.cons]:
+Change 26.6.6.1 [gslice.cons]:
 
    
 
 
    
@@ -21831,10 +22755,10 @@ lengths, and strides, as explained in the previous section.
 
 
    
 
    545. When is a deleter deleted?
    
-
    Section: 20.7.12.2.11 [util.smartptr.getdeleter], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] Status: WP
- Submitter: Matt Austern Date: 2006-01-10
    
+
    Section: 20.8.13.2.11 [util.smartptr.getdeleter], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] Status: CD1
+ Submitter: Matt Austern Opened: 2006-01-10  Last modified: 2008-09-26
    
 
    View all other issues in [util.smartptr.getdeleter].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 The description of ~shared_ptr doesn't say when the shared_ptr's deleter, if
@@ -21849,7 +22773,7 @@ instances). We should say which it is.
 
 
    Proposed resolution:
    
 
    
-Add after the first sentence of 20.7.12.2.11 [util.smartptr.getdeleter]/1:
+Add after the first sentence of 20.8.13.2.11 [util.smartptr.getdeleter]/1:
 
    
 
    
 
    
@@ -21869,10 +22793,10 @@ This can happen if the implementation doesn't destroy the deleter until all
 
 
    
 
    550. What should the return type of pow(float,int) be?
    
-
    Section: 26.7 [c.math] Status: WP
- Submitter: Howard Hinnant Date: 2006-01-12
    
+
    Section: 26.8 [c.math] Status: CD1
+ Submitter: Howard Hinnant Opened: 2006-01-12  Last modified: 2008-09-26
    
 
    View all other issues in [c.math].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 Assuming we adopt the
@@ -21984,7 +22908,7 @@ wording provided.
 
 
    Proposed resolution:
    
 
    
-Change 26.7 [c.math] p10:
+Change 26.8 [c.math] p10:
 
    
 
 
    
@@ -22007,9 +22931,9 @@ The added signatures are:
 
 
    
 
    551. <ccomplex>
    
-
    Section: 26.3.11 [cmplxh], TR1 8.3 [tr.c99.cmplxh] Status: WP
- Submitter: Howard Hinnant Date: 2006-01-23
    
-
    View all issues with WP status.
    
+
    Section: 26.4.11 [cmplxh], TR1 8.3 [tr.c99.cmplxh] Status: CD1
+ Submitter: Howard Hinnant Opened: 2006-01-23  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 Previously xxx.h was parsable by C++.  But in the case of C99's <complex.h>
@@ -22068,9 +22992,10 @@ note]
 
 
    
 
    552. random_shuffle and its generator
    
-
    Section: 25.2.12 [alg.random.shuffle] Status: WP
- Submitter: Martin Sebor Date: 2006-01-25
    
-
    View all issues with WP status.
    
+
    Section: 25.4.12 [alg.random.shuffle] Status: CD1
+ Submitter: Martin Sebor Opened: 2006-01-25  Last modified: 2008-09-26
    
+
    View all other issues in [alg.random.shuffle].
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 ...is specified to shuffle its range by calling swap but not how
@@ -22109,14 +23034,14 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
    
 
    559. numeric_limits<const T>
    
-
    Section: 18.2.1 [limits] Status: WP
- Submitter: Martin Sebor Date: 2006-02-19
    
+
    Section: 18.3.1 [limits] Status: CD1
+ Submitter: Martin Sebor Opened: 2006-02-19  Last modified: 2008-09-26
    
 
    View all other issues in [limits].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
         
    
 
-18.2.1 [limits], p2 requires implementations  to provide specializations of the
+18.3.1 [limits], p2 requires implementations  to provide specializations of the
 numeric_limits template for  each scalar type. While this
 could be interepreted to include cv-qualified forms of such types such
 an  interepretation   is  not  reflected   in  the  synopsis   of  the
@@ -22159,7 +23084,7 @@ template <class T> class numeric_limits<const volatile T>;
 
         
    
 
-Add  a new paragraph  to the  end of  18.2.1.1 [numeric.limits], with  the following
+Add  a new paragraph  to the  end of  18.3.1.1 [numeric.limits], with  the following
 text:
 
         
    
@@ -22184,9 +23109,9 @@ automatically.
 
 
    
 
    561. inserter overly generic
    
-
    Section: 24.4.2.6.5 [inserter] Status: WP
- Submitter: Howard Hinnant Date: 2006-02-21
    
-
    View all issues with WP status.
    
+
    Section: 24.7.6.5 [inserter] Status: CD1
+ Submitter: Howard Hinnant Opened: 2006-02-21  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 The declaration of std::inserter is:
@@ -22350,10 +23275,10 @@ correct in the absence of concepts. Proposed Disposition: Ready
 
 
    
 
    562. stringbuf ctor inefficient
    
-
    Section: 27.7 [string.streams] Status: WP
- Submitter: Martin Sebor Date: 2006-02-23
    
+
    Section: 27.8 [string.streams] Status: CD1
+ Submitter: Martin Sebor Opened: 2006-02-23  Last modified: 2008-09-26
    
 
    View all other issues in [string.streams].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
         
    
 
@@ -22445,10 +23370,10 @@ Kona (2007) Moved to Ready.
 
 
    
 
    563. stringbuf seeking from end
    
-
    Section: 27.7.1.4 [stringbuf.virtuals] Status: WP
- Submitter: Martin Sebor Date: 2006-02-23
    
+
    Section: 27.8.1.4 [stringbuf.virtuals] Status: CD1
+ Submitter: Martin Sebor Opened: 2006-02-23  Last modified: 2008-09-26
    
 
    View all other issues in [stringbuf.virtuals].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 According to  Table 92  (unchanged by issue  432), when  (way ==
@@ -22503,10 +23428,10 @@ Kona (2007) Moved to Ready.
 
 
    
 
    566. array forms of unformatted input function undefined for zero-element arrays
    
-
    Section: 27.6.1.3 [istream.unformatted] Status: WP
- Submitter: Martin Sebor Date: 2006-02-23
    
+
    Section: 27.7.1.3 [istream.unformatted] Status: CD1
+ Submitter: Martin Sebor Opened: 2006-02-23  Last modified: 2008-09-26
    
 
    View all other issues in [istream.unformatted].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
         
    
 
@@ -22575,10 +23500,10 @@ location of the array.
 
 
    
 
    567. streambuf inserter and extractor should be unformatted
    
-
    Section: 27.6 [iostream.format] Status: WP
- Submitter: Martin Sebor Date: 2006-02-25
    
+
    Section: 27.7 [iostream.format] Status: CD1
+ Submitter: Martin Sebor Opened: 2006-02-25  Last modified: 2008-09-26
    
 
    View all other issues in [iostream.format].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
         
    
 
@@ -22642,10 +23567,10 @@ Kona (2007): Proposed Disposition: Ready
 
 
    
 
    574. DR 369 Contradicts Text
    
-
    Section: 27.3 [iostream.objects] Status: WP
- Submitter: Pete Becker Date: 2006-04-18
    
+
    Section: 27.4 [iostream.objects] Status: CD1
+ Submitter: Pete Becker Opened: 2006-04-18  Last modified: 2008-09-26
    
 
    View all other issues in [iostream.objects].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 lib.iostream.objects requires that the standard stream objects are never
@@ -22662,7 +23587,7 @@ not destroyed during program execution."
 
 
    Proposed resolution:
    
 
    
-Change 27.3 [iostream.objects]/1:
+Change 27.4 [iostream.objects]/1:
 
    
 
 
    
@@ -22682,7 +23607,7 @@ objects defined later in that translation unit.
 
 
 
    [
-Kona (2007): From 27.3 [iostream.objects]/2, strike the words "...and these stream objects
+Kona (2007): From 27.4 [iostream.objects]/2, strike the words "...and these stream objects
 shall be destroyed after the destruction of dynamically initialized
 non-local objects defined later in that translation unit." Proposed
 Disposition: Review
@@ -22694,9 +23619,10 @@ Disposition: Review
 
 
    
 
    575. the specification of ~shared_ptr is MT-unfriendly, makes implementation assumptions
    
-
    Section: 20.7.12.2.2 [util.smartptr.shared.dest], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] Status: WP
- Submitter: Peter Dimov Date: 2006-04-23
    
-
    View all issues with WP status.
    
+
    Section: 20.8.13.2.2 [util.smartptr.shared.dest], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] Status: CD1
+ Submitter: Peter Dimov Opened: 2006-04-23  Last modified: 2008-09-26
    
+
    View all other issues in [util.smartptr.shared.dest].
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 [tr.util.smartptr.shared.dest] says in its second bullet:
@@ -22772,10 +23698,10 @@ after *this is destroyed. --end note]
 
 
    
 
    576. find_first_of is overconstrained
    
-
    Section: 25.1.7 [alg.find.first.of] Status: WP
- Submitter: Doug Gregor Date: 2006-04-25
    
+
    Section: 25.3.7 [alg.find.first.of] Status: CD1
+ Submitter: Doug Gregor Opened: 2006-04-25  Last modified: 2008-09-26
    
 
    View all other issues in [alg.find.first.of].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 In 25.1.4 Find First [lib.alg.find.first], the two iterator type parameters to
@@ -22825,9 +23751,9 @@ template<class ForwardIterator1InputIterator1, class Fo
 
 
    
 
    577. upper_bound(first, last, ...) cannot return last
    
-
    Section: 25.3.3.2 [upper.bound] Status: WP
- Submitter: Seungbeom Kim Date: 2006-05-03
    
-
    View all issues with WP status.
    
+
    Section: 25.5.3.2 [upper.bound] Status: CD1
+ Submitter: Seungbeom Kim Opened: 2006-05-03  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 ISO/IEC 14882:2003 says:
@@ -22875,10 +23801,10 @@ conditions hold: !(value < *j) or comp(value, *j)
 
 
    
 
    578. purpose of hint to allocator::allocate()
    
-
    Section: 20.7.5.1 [allocator.members] Status: WP
- Submitter: Martin Sebor Date: 2006-05-17
    
+
    Section: 20.8.6.1 [allocator.members] Status: CD1
+ Submitter: Martin Sebor Opened: 2006-05-17  Last modified: 2008-09-26
    
 
    View all other issues in [allocator.members].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
         
    
 
@@ -22934,10 +23860,10 @@ adjacent element is often a good choice to pass for this argument.
 
 
    
 
    581. flush() not unformatted function
    
-
    Section: 27.6.2.7 [ostream.unformatted] Status: WP
- Submitter: Martin Sebor Date: 2006-06-14
    
+
    Section: 27.7.2.7 [ostream.unformatted] Status: CD1
+ Submitter: Martin Sebor Opened: 2006-06-14  Last modified: 2008-09-26
    
 
    View all other issues in [ostream.unformatted].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
         
    
 
@@ -22998,10 +23924,10 @@ Kona (2007): Proposed Disposition: Ready
 
 
    
 
    586. string inserter not a formatted function
    
-
    Section: 21.3.8.9 [string.io] Status: WP
- Submitter: Martin Sebor Date: 2006-06-22
    
+
    Section: 21.4.8.9 [string.io] Status: CD1
+ Submitter: Martin Sebor Opened: 2006-06-22  Last modified: 2008-09-26
    
 
    View all other issues in [string.io].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
         
    
 
@@ -23081,11 +24007,11 @@ indicates a failure.
 
 
    
 
    589. Requirements on iterators of member template functions of containers
    
-
    Section: 23.1 [container.requirements] Status: WP
- Submitter: Peter Dimov Date: 2006-08-02
    
+
    Section: 23.2 [container.requirements] Status: CD1
+ Submitter: Peter Dimov Opened: 2006-08-02  Last modified: 2008-09-26
    
 
    View other active issues in [container.requirements].
    
 
    View all other issues in [container.requirements].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Duplicate of: 536
    
 
    Discussion:
    
 
    
@@ -23142,10 +24068,10 @@ easy to fix this up as a safety net and as a clear statement of intent.
 
 
    
 
    593. __STDC_CONSTANT_MACROS
    
-
    Section: 18.3 [cstdint], TR1 8.22 [tr.c99.cstdint] Status: WP
- Submitter: Walter Brown Date: 2006-08-28
    
+
    Section: 18.4 [cstdint], TR1 8.22 [tr.c99.cstdint] Status: CD1
+ Submitter: Walter Brown Opened: 2006-08-28  Last modified: 2008-09-26
    
 
    View all other issues in [cstdint].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 Clause 18.3 of the current Working Paper (N2009) deals with the new C++ headers
@@ -23185,10 +24111,10 @@ particular, the symbols __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS
 
 
    
 
    595. TR1/C++0x: fabs(complex<T>) redundant / wrongly specified
    
-
    Section: 26.3.7 [complex.value.ops] Status: WP
- Submitter: Stefan Große Pawig Date: 2006-09-24
    
+
    Section: 26.4.7 [complex.value.ops] Status: CD1
+ Submitter: Stefan Große Pawig Opened: 2006-09-24  Last modified: 2009-03-21
    
 
    View all other issues in [complex.value.ops].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 TR1 introduced, in the C compatibility chapter, the function
@@ -23305,14 +24231,14 @@ Bill believes that abs() is a suitable overload. We should remove fabs().
 
    Proposed resolution:
    
 
 
    
-Change the synopsis in 26.3.1 [complex.synopsis]:
+Change the synopsis in 26.4.1 [complex.syn]:
 
    
 
 
    template<class T> complex<T> fabs(const complex<T>&);
 
    
 
 
    
-Remove 26.3.7 [complex.value.ops], p7:
+Remove 26.4.7 [complex.value.ops], p7:
 
    
 
 
    
@@ -23338,13 +24264,13 @@ Proposed Disposition: Ready
 
 
    
 
    596. 27.8.1.3 Table 112 omits "a+" and "a+b" modes
    
-
    Section: 27.8.1.4 [filebuf.members] Status: WP
- Submitter: Thomas Plum Date: 2006-09-26
    
+
    Section: 27.9.1.4 [filebuf.members] Status: CD1
+ Submitter: Thomas Plum Opened: 2006-09-26  Last modified: 2008-09-26
    
 
    View all other issues in [filebuf.members].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-In testing 27.8.1.4 [filebuf.members], Table 112 (in the latest N2009 draft), we invoke  
+In testing 27.9.1.4 [filebuf.members], Table 112 (in the latest N2009 draft), we invoke  
 
    
 
       ostr.open("somename", ios_base::out | ios_base::in | ios_base::app)
 
    
@@ -23390,7 +24316,7 @@ the same thing as "a+" already proposed in the issue.
 
 
    Proposed resolution:
    
 
    
-Add to the table "File open modes" in 27.8.1.4 [filebuf.members]:
+Add to the table "File open modes" in 27.9.1.4 [filebuf.members]:
 
    
 
 
    
@@ -23476,7 +24402,7 @@ Kona (2007) Added proposed wording and moved to Review.
 
    
 
    598. Decimal: Conversion to integral should truncate, not round.
    
 
    Section: TRDecimal 3.2 [trdec.types.types] Status: TRDec
- Submitter: Daniel Krugler Date: 2006-05-28
    
+ Submitter: Daniel Krugler Opened: 2006-05-28  Last modified: 2007-04-21
    
 
    View other active issues in [trdec.types.types].
    
 
    View all other issues in [trdec.types.types].
    
 
    View all issues with TRDec status.
    
@@ -23555,7 +24481,7 @@ Change the Returns: clause in 3.2.4.4 to:
 
    
 
    599. Decimal: Say "octets" instead of "bytes."
    
 
    Section: TRDecimal 3.1 [trdec.types.encodings] Status: TRDec
- Submitter: Daniel Krugler Date: 2006-05-28
    
+ Submitter: Daniel Krugler Opened: 2006-05-28  Last modified: 2007-04-21
    
 
    View all issues with TRDec status.
    
 
    Discussion:
    
 
    
@@ -23613,7 +24539,7 @@ decimal128 is a decimal128 number, which is encoded in 16 consecutive <
 
    
 
    600. Decimal: Wrong parameters for wcstod* functions
    
 
    Section: TRDecimal 3.9 [trdec.types.cwchar] Status: TRDec
- Submitter: Daniel Krugler Date: 2006-05-28
    
+ Submitter: Daniel Krugler Opened: 2006-05-28  Last modified: 2007-04-21
    
 
    View all issues with TRDec status.
    
 
    Discussion:
    
 
    
@@ -23646,7 +24572,7 @@ Change "3.9.1 Additions to <cwchar> synopsis" to:
 
    
 
    601. Decimal: numeric_limits typos
    
 
    Section: TRDecimal 3.3 [trdec.types.limits] Status: TRDec
- Submitter: Daniel Krugler Date: 2006-05-28
    
+ Submitter: Daniel Krugler Opened: 2006-05-28  Last modified: 2007-04-21
    
 
    View all issues with TRDec status.
    
 
    Discussion:
    
 
    
@@ -23688,7 +24614,7 @@ In "3.3 Additions to header <limits>" change numeric_limits&l
 
    
 
    602. Decimal: "generic floating type" not defined.
    
 
    Section: TRDecimal 3 [trdec.types] Status: TRDec
- Submitter: Daniel Krugler Date: 2006-05-28
    
+ Submitter: Daniel Krugler Opened: 2006-05-28  Last modified: 2007-04-21
    
 
    View all other issues in [trdec.types].
    
 
    View all issues with TRDec status.
    
 
    Discussion:
    
@@ -23717,7 +24643,7 @@ collectively described as the basic floating types.
 
    
 
    603. Decimal: Trivially simplifying decimal classes.
    
 
    Section: TRDecimal 3 [trdec.types] Status: TRDec
- Submitter: Martin Sebor Date: 2006-05-28
    
+ Submitter: Martin Sebor Opened: 2006-05-28  Last modified: 2007-04-21
    
 
    View all other issues in [trdec.types].
    
 
    View all issues with TRDec status.
    
 
    Discussion:
    
@@ -23836,7 +24762,7 @@ Change "3.2.4.1 construct/copy/destroy" as follows:
 
    
 
    604. Decimal: Storing a reference to a facet unsafe.
    
 
    Section: TRDecimal 3 [trdec.types] Status: TRDec
- Submitter: Martin Sebor Date: 2006-05-28
    
+ Submitter: Martin Sebor Opened: 2006-05-28  Last modified: 2007-07-25
    
 
    View all other issues in [trdec.types].
    
 
    View all issues with TRDec status.
    
 
    Discussion:
    
@@ -23958,7 +24884,7 @@ Redmond:  We would prefer to rename "extended" to "decimal".
 
    
 
    605. Decimal: <decfloat.h> doesn't live here anymore.
    
 
    Section: TRDecimal 3.4 [trdec.types.cdecfloat] Status: TRDec
- Submitter: Robert Klarer Date: 2006-10-17
    
+ Submitter: Robert Klarer Opened: 2006-10-17  Last modified: 2007-04-21
    
 
    View all issues with TRDec status.
    
 
    Discussion:
    
 
    
@@ -24013,11 +24939,10 @@ floating-point types decimal32, decimal64, and d
 
 
    
 
    607. Concern about short seed vectors
    
-
    Section: 26.4.7.1 [rand.util.seedseq] Status: WP
- Submitter: Charles Karney Date: 2006-10-26
    
-
    View other active issues in [rand.util.seedseq].
    
+
    Section: 26.5.7.1 [rand.util.seedseq] Status: CD1
+ Submitter: Charles Karney Opened: 2006-10-26  Last modified: 2008-09-26
    
 
    View all other issues in [rand.util.seedseq].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 Short seed vectors of 32-bit quantities all result in different states. However
@@ -24065,11 +24990,10 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
    
 
    608. Unclear seed_seq construction details
    
-
    Section: 26.4.7.1 [rand.util.seedseq] Status: WP
- Submitter: Charles Karney Date: 2006-10-26
    
-
    View other active issues in [rand.util.seedseq].
    
+
    Section: 26.5.7.1 [rand.util.seedseq] Status: CD1
+ Submitter: Charles Karney Opened: 2006-10-26  Last modified: 2008-09-26
    
 
    View all other issues in [rand.util.seedseq].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 In 26.4.7.1 [rand.util.seedseq] /6, the order of packing the inputs into b and the
@@ -24101,9 +25025,9 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
    
 
    609. missing static const
    
-
    Section: 26.4.4.2 [rand.adapt.ibits], TR1 5.1 [tr.rand] Status: WP
- Submitter: Walter E. Brown Date: 2006-11-02
    
-
    View all issues with WP status.
    
+
    Section: 26.5.4.2 [rand.adapt.ibits], TR1 5.1 [tr.rand] Status: CD1
+ Submitter: Walter E. Brown Opened: 2006-11-02  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 In preparing N2111, an error on my part resulted in the omission of the
@@ -24137,9 +25061,9 @@ and accept my apologies for the oversight.
 
 
    
 
    610. Suggested non-normative note for C++0x
    
-
    Section: 20.6.15.2.1 [func.wrap.func.con], TR1 3.7.2.1 [tr.func.wrap.func.con] Status: WP
- Submitter: Scott Meyers Date: 2006-11-02
    
-
    View all issues with WP status.
    
+
    Section: 20.7.16.2.1 [func.wrap.func.con], TR1 3.7.2.1 [tr.func.wrap.func.con] Status: CD1
+ Submitter: Scott Meyers Opened: 2006-11-02  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 My suggestion is that implementers of both tr1::function and its 
@@ -24208,9 +25132,10 @@ function pointer (a "bound member function").
 
 
    
 
    611. Standard library templates and incomplete types
    
-
    Section: 17.4.3.7 [res.on.functions] Status: WP
- Submitter: Nicola Musatti Date: 2006-11-13
    
-
    View all issues with WP status.
    
+
    Section: 17.6.3.8 [res.on.functions] Status: CD1
+ Submitter: Nicola Musatti Opened: 2006-11-13  Last modified: 2008-09-26
    
+
    View all other issues in [res.on.functions].
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 In the latest available draft standard 
@@ -24276,10 +25201,10 @@ component. 
 
 
    
 
    612. numeric_limits::is_modulo insufficiently defined
    
-
    Section: 18.2.1.2 [numeric.limits.members] Status: WP
- Submitter: Chris Jefferson Date: 2006-11-10
    
+
    Section: 18.3.1.2 [numeric.limits.members] Status: CD1
+ Submitter: Chris Jefferson Opened: 2006-11-10  Last modified: 2008-09-26
    
 
    View all other issues in [numeric.limits.members].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 18.2.1.2 55 states that "A type is modulo if it is possible to add two
@@ -24312,7 +25237,7 @@ happens to b modulo? A: the standard already seems to require that.
 
 
    Proposed resolution:
    
 
    
-Suggest 18.2.1.2 [numeric.limits.members], paragraph 57 is amended to:
+Suggest 18.3.1.2 [numeric.limits.members], paragraph 57 is amended to:
 
    
 
 
    
@@ -24331,13 +25256,13 @@ differs from the true value by an integer multiple of (max() - min() +
 
 
    
 
    613. max_digits10 missing from numeric_limits
    
-
    Section: 18.2.1.5 [numeric.special] Status: WP
- Submitter: Bo Persson Date: 2006-11-20
    
+
    Section: 18.3.1.5 [numeric.special] Status: CD1
+ Submitter: Bo Persson Opened: 2006-11-20  Last modified: 2008-09-26
    
 
    View all other issues in [numeric.special].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-Section 18.2.1.5 [numeric.special] starts out by saying that "All members shall be provided 
+Section 18.3.1.5 [numeric.special] starts out by saying that "All members shall be provided 
 for all specializations."
 
    
 
    
@@ -24379,7 +25304,7 @@ We are also missing a statement regarding for what specializations this member h
 
 
    Proposed resolution:
    
 
    
-Change and add after 18.2.1.2 [numeric.limits.members], p11:
+Change and add after 18.3.1.2 [numeric.limits.members], p11:
 
    
 
 
    
@@ -24396,7 +25321,7 @@ differ by only one epsilon are always differentiated.
 
    
 
 
    
-Change 18.2.1.5 [numeric.special], p2:
+Change 18.3.1.5 [numeric.special], p2:
 
    
 
 
    template<> class numeric_limits<float> { 
@@ -24409,7 +25334,7 @@ public:
 
    
 
 
    
-Change 18.2.1.5 [numeric.special], p3:
+Change 18.3.1.5 [numeric.special], p3:
 
    
 
 
    template<> class numeric_limits<bool> { 
@@ -24429,10 +25354,10 @@ public:
 
 
    
 
    616. missing 'typename' in ctype_byname
    
-
    Section: 22.2.1.2 [locale.ctype.byname] Status: WP
- Submitter: Bo Persson Date: 2006-12-16
    
+
    Section: 22.4.1.2 [locale.ctype.byname] Status: CD1
+ Submitter: Bo Persson Opened: 2006-12-16  Last modified: 2008-09-26
    
 
    View all other issues in [locale.ctype.byname].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 Section 22.2.1.2 defines the ctype_byname class template. It contains the 
@@ -24458,9 +25383,9 @@ as this is a dependent type, it should obviously be
 
 
    
 
    618. valarray::cshift() effects on empty array
    
-
    Section: 26.5.2.7 [valarray.members] Status: WP
- Submitter: Gabriel Dos Reis Date: 2007-01-10
    
-
    View all issues with WP status.
    
+
    Section: 26.6.2.7 [valarray.members] Status: CD1
+ Submitter: Gabriel Dos Reis Opened: 2007-01-10  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 I would respectfully request an issue be opened with the intention to
@@ -24470,7 +25395,7 @@ clarify the wording for size() == 0 for cshift.
 
 
    Proposed resolution:
    
 
    
-Change 26.5.2.7 [valarray.members], paragraph 10:
+Change 26.6.2.7 [valarray.members], paragraph 10:
 
    
 
 
    
@@ -24515,15 +25440,16 @@ Kona (2007) Changed proposed wording, added rationale and set to Review.
 
 
    
 
    619. Longjmp wording problem
    
-
    Section: 18.9 [support.runtime] Status: WP
- Submitter: Lawrence Crowl Date: 2007-01-12
    
-
    View all issues with WP status.
    
+
    Section: 18.10 [support.runtime] Status: CD1
+ Submitter: Lawrence Crowl Opened: 2007-01-12  Last modified: 2008-09-26
    
+
    View all other issues in [support.runtime].
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 The wording for longjmp is confusing.
 
    
 
    
-18.9 [support.runtime] -4- Other runtime support
+18.10 [support.runtime] -4- Other runtime support
 
    
 
    
 The function signature longjmp(jmp_buf jbuf, int val) has more restricted
@@ -24549,7 +25475,7 @@ caught only at the point of the setjmp, the behavior is undefined."
 In general, accept Bill Gibbons' recommendation,
 but add "call" to indicate that the undefined behavior
 comes from the dynamic call, not from its presence in the code.
-In 18.9 [support.runtime] paragraph 4, change
+In 18.10 [support.runtime] paragraph 4, change
 
    
 
 
    
@@ -24569,11 +25495,11 @@ undefined behavior if replacing the setjmp and longjmp by
 
 
    
 
    620. valid uses of empty valarrays
    
-
    Section: 26.5.2.1 [valarray.cons] Status: WP
- Submitter: Martin Sebor Date: 2007-01-20
    
+
    Section: 26.6.2.1 [valarray.cons] Status: CD1
+ Submitter: Martin Sebor Opened: 2007-01-20  Last modified: 2008-09-26
    
 
    View other active issues in [valarray.cons].
    
 
    View all other issues in [valarray.cons].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
         
    
 
@@ -24598,7 +25524,7 @@ language.
 
    Proposed resolution:
    
         
    
 
-Reword the Effects clause and Footnote 280 as follows (26.5.2.1 [valarray.cons]):
+Reword the Effects clause and Footnote 280 as follows (26.6.2.1 [valarray.cons]):
 
         
    
         
    
@@ -24639,10 +25565,10 @@ function.
 
 
    
 
    621. non-const copy assignment operators of helper arrays
    
-
    Section: 26.5 [numarray] Status: WP
- Submitter: Martin Sebor Date: 2007-01-20
    
+
    Section: 26.6 [numarray] Status: CD1
+ Submitter: Martin Sebor Opened: 2007-01-20  Last modified: 2008-09-26
    
 
    View all other issues in [numarray].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
         
    
 
@@ -24696,8 +25622,8 @@ Specifically,  make the following edits:
         
    
         
    
 
-Change     the    signature     in     26.5.5 [template.slice.array]    and
-26.5.5.1 [slice.arr.assign] as follows:
+Change     the    signature     in     26.6.5 [template.slice.array]    and
+26.6.5.1 [slice.arr.assign] as follows:
 
         
    
         
    @@ -24706,8 +25632,8 @@ Change     the    signature     in     26.5.5 [template.slice.array]    and
         
    
         
    
 
-Change     the     signature     in    26.5.7 [template.gslice.array]     and
-26.5.7.1 [gslice.array.assign] as follows:
+Change     the     signature     in    26.6.7 [template.gslice.array]     and
+26.6.7.1 [gslice.array.assign] as follows:
 
         
    
         
    @@ -24716,7 +25642,7 @@ Change     the     signature     in    26.5.7 [template.gslice.array]     and
         
    
         
    
 
-Change the  signature in 26.5.8 [template.mask.array]  and 26.5.8.1 [mask.array.assign] as
+Change the  signature in 26.6.8 [template.mask.array]  and 26.6.8.1 [mask.array.assign] as
 follows:
 
         
    
@@ -24726,8 +25652,8 @@ follows:
         
    
         
    
 
-Change     the     signature     in    26.5.9 [template.indirect.array] and
-26.5.9.1 [indirect.array.assign] as follows:
+Change     the     signature     in    26.6.9 [template.indirect.array] and
+26.6.9.1 [indirect.array.assign] as follows:
 
         
    
         
    @@ -24746,9 +25672,9 @@ Kona (2007) Added const qualification to the return types and set to Ready.
 
 
    
 
    622. behavior of filebuf dtor and close on error
    
-
    Section: 27.8.1.17 [fstream.members] Status: WP
- Submitter: Martin Sebor Date: 2007-01-20
    
-
    View all issues with WP status.
    
+
    Section: 27.9.1.17 [fstream.members] Status: CD1
+ Submitter: Martin Sebor Opened: 2007-01-20  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
         
    
 
@@ -24773,7 +25699,7 @@ dtor? Should the  dtor catch and swallow it or  should it propagate it
 to the caller?  The text doesn't  seem to provide any guidance in this
 regard  other  than  the  general  restriction on  throwing  (but  not
 propagating)  exceptions  from   destructors  of  library  classes  in
-17.4.4.9 [res.on.exception.handling].
+17.6.4.10 [res.on.exception.handling].
 
         
    
         
    
@@ -24841,7 +25767,7 @@ to catch and swallow any exceptions thrown by close().
         
    
 
 Specifically,   we   propose   to   make  the   following   edits   in
-27.8.1.4 [filebuf.members]:
+27.9.1.4 [filebuf.members]:
 
         
    
         
    
@@ -24873,7 +25799,7 @@ rethrown after closing the file.
         
    
         
    
 
-And to make the following edits in 27.8.1.2 [filebuf.cons].
+And to make the following edits in 27.9.1.2 [filebuf.cons].
 
         
    
         
    
@@ -24888,7 +25814,7 @@ And to make the following edits in 27.8.1.2 [filebuf.cons].
 close().    If  an   exception  occurs   during  the
 destruction of the object, including the call to close(),
 the     exception    is     caught    but     not     rethrown    (see
-17.4.4.9 [res.on.exception.handling]).
+17.6.4.10 [res.on.exception.handling]).
 
             
    
         
    
@@ -24899,13 +25825,13 @@ the     exception    is     caught    but     not     rethrown    (see
 
 
    
 
    623. pubimbue forbidden to call imbue
    
-
    Section: 27.1.1 [iostream.limits.imbue] Status: WP
- Submitter: Martin Sebor Date: 2007-01-20
    
-
    View all issues with WP status.
    
+
    Section: 27.2.1 [iostream.limits.imbue] Status: CD1
+ Submitter: Martin Sebor Opened: 2007-01-20  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
         
    
 
-27.1.1 [iostream.limits.imbue]  specifies  that  "no  function  described  in
+27.2.1 [iostream.limits.imbue]  specifies  that  "no  function  described  in
 clause 27 except  for ios_base::imbue causes any instance
 of                   basic_ios::imbue                  or
 basic_streambuf::imbue to be called."
@@ -24925,7 +25851,7 @@ to do just that: call basic_streambuf::imbue().
 
 To    fix   this,    rephrase    the   sentence    above   to    allow
 pubimbue to do what  it was designed to do. Specifically.
-change 27.1.1 [iostream.limits.imbue], p1 to read:
+change 27.2.1 [iostream.limits.imbue], p1 to read:
 
         
    
         
    
@@ -24943,9 +25869,9 @@ causes    any    instance    of    basic_ios::imbue    or
 
 
    
 
    624. valarray assignment and arrays of unequal length
    
-
    Section: 26.5.2.2 [valarray.assign] Status: WP
- Submitter: Martin Sebor Date: 2007-01-20
    
-
    View all issues with WP status.
    
+
    Section: 26.6.2.2 [valarray.assign] Status: CD1
+ Submitter: Martin Sebor Opened: 2007-01-20  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
         
    
 
@@ -24958,7 +25884,7 @@ undefined behavior.
         
    
 
 However, the generalized  subscripting assignment operators overloaded
-on slice_array  et al (26.5.2.2 [valarray.assign])  don't have any
+on slice_array  et al (26.6.2.2 [valarray.assign])  don't have any
 such restriction, leading  the reader to believe that  the behavior of
 these  overloads is  well defined  regardless  of the  lengths of  the
 arguments.
@@ -25016,7 +25942,7 @@ the thread starting at c++std-lib-17786.
 In order  to reflect  such views, the  standard must specify  that the
 size of the  array referred to by the argument  of the assignment must
 match the size of the array  under assignment, for example by adding a
-Requires clause to 26.5.2.2 [valarray.assign] as follows:
+Requires clause to 26.6.2.2 [valarray.assign] as follows:
 
         
    
         
    
@@ -25036,7 +25962,7 @@ to implement valarray efficiently.
 
 
    Proposed resolution:
    
 
    
-Insert new paragraph into 26.5.2.2 [valarray.assign]:
+Insert new paragraph into 26.6.2.2 [valarray.assign]:
 
    
 
 
    
@@ -25062,13 +25988,13 @@ These operators allow the results of a generalized subscripting operation to be
 
 
    
 
    628. Inconsistent definition of basic_regex constructor
    
-
    Section: 28.8 [re.regex] Status: WP
- Submitter: Bo Persson Date: 2007-01-23
    
+
    Section: 28.9 [re.regex] Status: CD1
+ Submitter: Bo Persson Opened: 2007-01-23  Last modified: 2008-09-26
    
 
    View all other issues in [re.regex].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-Section 28.8 [re.regex] lists a constructor
+Section 28.9 [re.regex] lists a constructor
 
    
 
 
    template<class InputIterator>
@@ -25077,14 +26003,14 @@ basic_regex(InputIterator first, InputIterator last,
 
    
 
 
    
-However, in section 28.8.2 [re.regex.construct], this constructor takes a 
+However, in section 28.9.2 [re.regex.construct], this constructor takes a 
 pair of ForwardIterator.
 
    
 
 
 
    Proposed resolution:
    
 
    
-Change 28.8.2 [re.regex.construct]:
+Change 28.9.2 [re.regex.construct]:
 
    
 
 
    template <class ForwardIterator InputIterator>
@@ -25097,17 +26023,111 @@ Change 28.8.2 [re.regex.construct]:
 
 
 
+
    
+
    629. complex insertion and locale dependence
    
+
    Section: 26.4.6 [complex.ops] Status: CD1
+ Submitter: Gabriel Dos Reis Opened: 2007-01-28  Last modified: 2008-09-26
    
+
    View all other issues in [complex.ops].
    
+
    View all issues with CD1 status.
    
+
    Discussion:
    
+
    
+is there an issue opened for (0,3) as complex number with
+the French local?  With the English local, the above parses as an
+imaginery complex number.  With the French locale it parses as a
+real complex number.
+
    
+
+
    
+Further notes/ideas from the lib-reflector, messages 17982-17984:
+
    
+
+
    
+
    
+Add additional entries in num_punct to cover the complex separator (French would be ';').
+
    
+
    
+Insert a space before the comma, which should eliminate the ambiguity.
+
    
+
    
+Solve the problem for ordered sequences in general, perhaps with a
+dedicated facet.  Then complex should use that solution.
+
    
+
    
+
+
    [
+Bellevue:
+]
    
+
+
+
    
+
    
+After much discussion, we agreed on the following: Add a footnote:
+
    
+
    
+[In a locale in which comma is being used as a decimal point character,
+inserting "showbase" into the output stream forces all outputs to show
+an explicit decimal point character; then all inserted complex sequences
+will extract unambiguously.]
+
    
+
    
+And move this to READY status.
+
    
+
    
+
+
    [
+Pre-Sophia Antipolis, Howard adds:
+]
    
+
+
+
    
+Changed "showbase" to "showpoint" and changed from Ready to Review.
+
    
+
+
    [
+Post-Sophia Antipolis:
+]
    
+
+
+
    
+
    
+I neglected to pull this issue from the formal motions page after the "showbase" to "showpoint" change.
+In Sophia Antipolis this change was reviewed by the LWG and the issue was set to Ready.  We subsequently
+voted the footnote into the WP with "showbase".
+
    
+
    
+I'm changing from WP back to Ready to pick up the "showbase" to "showpoint" change.
+
    
+
    
+
+
+
+
    Proposed resolution:
    
+
    
+Add a footnote to 26.4.6 [complex.ops] p16:
+
    
+
+
    
+[In a locale in which comma is being used as a decimal point character,
+inserting showpoint into the output stream forces all outputs to show
+an explicit decimal point character; then all inserted complex sequences
+will extract unambiguously.]
+
    
+
+
+
+
+
 
    
 
    634. allocator.address() doesn't work for types overloading operator&
    
-
    Section: 20.7.5.1 [allocator.members] Status: WP
- Submitter: Howard Hinnant Date: 2007-02-07
    
+
    Section: 20.8.6.1 [allocator.members] Status: CD1
+ Submitter: Howard Hinnant Opened: 2007-02-07  Last modified: 2008-09-26
    
 
    View all other issues in [allocator.members].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Duplicate of: 350
    
 
    Discussion:
    
 
 
    
-20.7.5.1 [allocator.members] says:
+20.8.6.1 [allocator.members] says:
 
    
 
    
 
    pointer address(reference x) const;
    
@@ -25119,7 +26139,7 @@ Change 28.8.2 [re.regex.construct]:
 
    
 
 
    
-20.7.5.1 [allocator.members] defines CopyConstructible which currently not
+20.8.6.1 [allocator.members] defines CopyConstructible which currently not
 only defines the semantics of copy construction, but also restricts what an overloaded
 operator& may do.  I believe proposals are in the works (such as concepts
 and rvalue reference) to decouple these two requirements.  Indeed it is not evident
@@ -25150,7 +26170,7 @@ is expected to make use of allocator::address mandatory for containers.
 
 
    Proposed resolution:
    
 
    
-Change 20.7.5.1 [allocator.members]:
+Change 20.8.6.1 [allocator.members]:
 
    
 
 
    
@@ -25192,12 +26212,12 @@ issue to Ready status to be voted into the WP at Kona.
 
 
    
 
    638. deque end invalidation during erase
    
-
    Section: 23.2.2.3 [deque.modifiers] Status: WP
- Submitter: Steve LoBasso Date: 2007-02-17
    
-
    View all issues with WP status.
    
+
    Section: 23.3.2.3 [deque.modifiers] Status: CD1
+ Submitter: Steve LoBasso Opened: 2007-02-17  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-The standard states at 23.2.2.3 [deque.modifiers]/4:
+The standard states at 23.3.2.3 [deque.modifiers]/4:
 
    
 
    deque erase(...)
 
    
@@ -25243,7 +26263,7 @@ iterators.
 
 
    Proposed resolution:
    
 
    
-Change 23.2.2.3 [deque.modifiers], p4:
+Change 23.3.2.3 [deque.modifiers], p4:
 
    
 
 
    
@@ -25288,13 +26308,13 @@ Spertus to evaluate and, if need be, file an issue.
 
 
    
 
    640. 27.6.2.5.2 does not handle (unsigned) long long
    
-
    Section: 27.6.2.6.2 [ostream.inserters.arithmetic] Status: WP
- Submitter: Daniel Krügler Date: 2007-02-17
    
+
    Section: 27.7.2.6.2 [ostream.inserters.arithmetic] Status: CD1
+ Submitter: Daniel Krügler Opened: 2007-02-17  Last modified: 2008-09-26
    
 
    View all other issues in [ostream.inserters.arithmetic].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-The arithmetic inserters are described in 27.6.2.6.2 [ostream.inserters.arithmetic].
+The arithmetic inserters are described in 27.7.2.6.2 [ostream.inserters.arithmetic].
 Although the section starts with a listing of the inserters including
 the new ones:
 
    
@@ -25321,7 +26341,7 @@ back.
 
 
    Proposed resolution:
    
 
    
-In 27.6.2.6.2 [ostream.inserters.arithmetic]/1 change the third sentence
+In 27.7.2.6.2 [ostream.inserters.arithmetic]/1 change the third sentence
 
    
 
 
    
@@ -25337,9 +26357,9 @@ occurs as if it performed the following code fragment:
 
 
    
 
    643. Impossible "as if" clauses
    
-
    Section: 27.8.1.1 [filebuf], 22.2.2.2.2 [facet.num.put.virtuals] Status: WP
- Submitter: Daniel Krügler Date: 2007-02-20
    
-
    View all issues with WP status.
    
+
    Section: 27.9.1.1 [filebuf], 22.4.2.2.2 [facet.num.put.virtuals] Status: CD1
+ Submitter: Daniel Krügler Opened: 2007-02-20  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
 The current standard 14882:2003(E) as well as N2134 have the
@@ -25348,7 +26368,7 @@ defects:
 
    
 
 
    
-27.8.1.1 [filebuf]/5 says:
+27.9.1.1 [filebuf]/5 says:
 
    
 
 
    
@@ -25367,13 +26387,13 @@ copyconstructible, so the codecvt construction should fail to compile.
 
    
 
 
    
-A similar issue arises in 22.2.2.2.2 [facet.num.put.virtuals]/15 for num_punct.
+A similar issue arises in 22.4.2.2.2 [facet.num.put.virtuals]/15 for num_punct.
 
    
 
 
 
    Proposed resolution:
    
 
    
-In 27.8.1.1 [filebuf]/5 change the "as if" code
+In 27.9.1.1 [filebuf]/5 change the "as if" code
 
    
 
 
    const codecvt<charT,char,typename traits::state_type>& a_codecvt =
@@ -25381,7 +26401,7 @@ In 27.8.1.1 [filebuf]/5 change the "as if" code
 
    
 
 
    
-In 22.2.2.2.2 [facet.num.put.virtuals]/15 (This is para 5 in N2134) change
+In 22.4.2.2.2 [facet.num.put.virtuals]/15 (This is para 5 in N2134) change
 
    
 
 
    
@@ -25403,21 +26423,21 @@ A local variable punct is initialized via
 
 
    
 
    646. const incorrect match_result members
    
-
    Section: 28.10.4 [re.results.form] Status: WP
- Submitter: Daniel Krügler Date: 2007-02-26
    
-
    View all issues with WP status.
    
+
    Section: 28.11.4 [re.results.form] Status: CD1
+ Submitter: Daniel Krügler Opened: 2007-02-26  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-28.10.4 [re.results.form] (root and para 3) in N2134 defines the two function template
+28.11.4 [re.results.form] (root and para 3) in N2134 defines the two function template
 members format as non-const functions, although they are declared
-as const in 28.10 [re.results]/3.
+as const in 28.11 [re.results]/3.
 
    
 
 
 
    Proposed resolution:
    
 
    
 Add the missing const specifier to both format overloads described
-in section 28.10.4 [re.results.form].
+in section 28.11.4 [re.results.form].
 
    
 
 
@@ -25426,24 +26446,24 @@ in section 28.10.4 [re.results.form].
 
 
    
 
    650. regex_token_iterator and const correctness
    
-
    Section: 28.12.2 [re.tokiter] Status: WP
- Submitter: Daniel Krügler Date: 2007-03-05
    
+
    Section: 28.13.2 [re.tokiter] Status: CD1
+ Submitter: Daniel Krügler Opened: 2007-03-05  Last modified: 2008-09-26
    
 
    View all other issues in [re.tokiter].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-Both the class definition of regex_token_iterator (28.12.2
-[re.tokiter]/6) and the latter member specifications (28.12.2.2
+Both the class definition of regex_token_iterator (28.13.2
+[re.tokiter]/6) and the latter member specifications (28.13.2.2
 [re.tokiter.comp]/1+2) declare both comparison operators as
 non-const functions. Furtheron, both dereference operators are
-unexpectedly also declared as non-const in 28.12.2 [re.tokiter]/6
-as well as in (28.12.2.3 [re.tokiter.deref]/1+2).
+unexpectedly also declared as non-const in 28.13.2 [re.tokiter]/6
+as well as in (28.13.2.3 [re.tokiter.deref]/1+2).
 
    
 
 
 
    Proposed resolution:
    
 
    
-1) In (28.12.2 [re.tokiter]/6) change the current declarations
+1) In (28.13.2 [re.tokiter]/6) change the current declarations
 
    
 
 
    bool operator==(const regex_token_iterator&) const;
@@ -25453,7 +26473,7 @@ const value_type* operator->() const;
 
    
 
 
    
-2) In 28.12.2.2 [re.tokiter.comp] change the following declarations
+2) In 28.13.2.2 [re.tokiter.comp] change the following declarations
 
    
 
 
    bool operator==(const regex_token_iterator& right) const;
@@ -25461,7 +26481,7 @@ bool operator!=(const regex_token_iterator& right) const;
 
    
 
 
    
-3) In 28.12.2.3 [re.tokiter.deref] change the following declarations
+3) In 28.13.2.3 [re.tokiter.deref] change the following declarations
 
    
 
 
    const value_type& operator*() const;
@@ -25481,17 +26501,17 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
    
 
    651. Missing preconditions for regex_token_iterator c'tors
    
-
    Section: 28.12.2.1 [re.tokiter.cnstr] Status: WP
- Submitter: Daniel Krügler Date: 2007-03-05
    
+
    Section: 28.13.2.1 [re.tokiter.cnstr] Status: CD1
+ Submitter: Daniel Krügler Opened: 2007-03-05  Last modified: 2008-09-26
    
 
    View all other issues in [re.tokiter.cnstr].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-The text provided in 28.12.2.1 [re.tokiter.cnstr]/2+3 describes
+The text provided in 28.13.2.1 [re.tokiter.cnstr]/2+3 describes
 the effects of the three non-default constructors of class
 template regex_token_iterator but is does not clarify which values
 are legal values for submatch/submatches. This becomes
-an issue, if one takes 28.12.2 [re.tokiter]/9 into account, which explains
+an issue, if one takes 28.13.2 [re.tokiter]/9 into account, which explains
 the notion of a "current match" by saying:
 
    
 
@@ -25510,7 +26530,7 @@ are legal arguments or not - it seems they are not.
 
    Proposed resolution:
    
 
    
 Add the following precondition paragraph just before the current
-28.12.2.1 [re.tokiter.cnstr]/2:
+28.13.2.1 [re.tokiter.cnstr]/2:
 
    
 
 
    
@@ -25530,22 +26550,22 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
    
 
    652. regex_iterator and const correctness
    
-
    Section: 28.12.1 [re.regiter] Status: WP
- Submitter: Daniel Krügler Date: 2007-03-05
    
-
    View all issues with WP status.
    
+
    Section: 28.13.1 [re.regiter] Status: CD1
+ Submitter: Daniel Krügler Opened: 2007-03-05  Last modified: 2008-09-26
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
-
    Both the class definition of regex_iterator (28.12.1 [re.regiter]/1)
-and the latter member specification (28.12.1.2 [re.regiter.comp]/1+2)
+
    Both the class definition of regex_iterator (28.13.1 [re.regiter]/1)
+and the latter member specification (28.13.1.2 [re.regiter.comp]/1+2)
 declare both comparison operators as
 non-const functions. Furtheron, both dereference operators are
-unexpectedly also declared as non-const in 28.12.1 [re.regiter]/1
-as well as in (28.12.1.3 [re.regiter.deref]/1+2).
+unexpectedly also declared as non-const in 28.13.1 [re.regiter]/1
+as well as in (28.13.1.3 [re.regiter.deref]/1+2).
 
    
 
 
 
    Proposed resolution:
    
 
    
-1) In (28.12.1 [re.regiter]/1) change the current declarations
+1) In (28.13.1 [re.regiter]/1) change the current declarations
 
    
 
 
    bool operator==(const regex_iterator&) const;
@@ -25555,7 +26575,7 @@ const value_type* operator->() const;
 
    
 
 
    
-2) In 28.12.1.3 [re.regiter.deref] change the following declarations
+2) In 28.13.1.3 [re.regiter.deref] change the following declarations
 
    
 
 
    const value_type& operator*() const;
@@ -25563,7 +26583,7 @@ const value_type* operator->() const;
 
    
 
 
    
-3) In 28.12.1.2 [re.regiter.comp] change the following declarations
+3) In 28.13.1.2 [re.regiter.comp] change the following declarations
 
    
 
 
    bool operator==(const regex_iterator& right) const;
@@ -25583,13 +26603,13 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
    
 
    654. Missing IO roundtrip for random number engines
    
-
    Section: 26.4.1.3 [rand.req.eng] Status: WP
- Submitter: Daniel Krügler Date: 2007-03-08
    
+
    Section: X [rand.req.eng] Status: CD1
+ Submitter: Daniel Krügler Opened: 2007-03-08  Last modified: 2009-05-01
    
 
    View all other issues in [rand.req.eng].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-Table 98 and para 5 in 26.4.1.3 [rand.req.eng] specify
+Table 98 and para 5 in X [rand.req.eng] specify
 the IO insertion and extraction semantic of random
 number engines. It can be shown, v.i., that the specification
 of the extractor cannot guarantee to fulfill the requirement
@@ -25630,41 +26650,41 @@ public:
   RanNumEngine() : state(42) {}
 
   bool operator==(RanNumEngine other) const {
-	  return state == other.state;
+      return state == other.state;
   }
 
   template <typename Ch, typename Tr>
   friend std::basic_ostream<Ch, Tr>& operator<<(std::basic_ostream<Ch, Tr>& os, RanNumEngine engine) {
-	Ch old = os.fill(os.widen(' ')); // Sets space character
-	std::ios_base::fmtflags f = os.flags();
-	os << std::dec << std::left << engine.state; // Adds ios_base::dec|ios_base::left
-	os.fill(old); // Undo
-	os.flags(f);
-	return os;
+    Ch old = os.fill(os.widen(' ')); // Sets space character
+    std::ios_base::fmtflags f = os.flags();
+    os << std::dec << std::left << engine.state; // Adds ios_base::dec|ios_base::left
+    os.fill(old); // Undo
+    os.flags(f);
+    return os;
   }
 
   template <typename Ch, typename Tr>
   friend std::basic_istream<Ch, Tr>& operator>>(std::basic_istream<Ch, Tr>& is, RanNumEngine& engine) {
        // Uncomment only for the fix.
 
-	//std::ios_base::fmtflags f = is.flags();
-	//is >> std::dec;
-	is >> engine.state;
-	//is.flags(f);
-	return is;
+    //std::ios_base::fmtflags f = is.flags();
+    //is >> std::dec;
+    is >> engine.state;
+    //is.flags(f);
+    return is;
   }
 };
 
 int main() {
-	std::stringstream s;
-	s << std::setfill('#'); // No problem
+    std::stringstream s;
+    s << std::setfill('#'); // No problem
         s << std::oct; // Yikes!
         // Here starts para 5 requirements:
-	RanNumEngine x;
-	s << x;
-	RanNumEngine v;
-	s >> v;
-	assert(x == v); // Fails: 42 == 34
+    RanNumEngine x;
+    s << x;
+    RanNumEngine v;
+    s >> v;
+    assert(x == v); // Fails: 42 == 34
 }
 
    
 
@@ -25713,13 +26733,13 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
    
 
    655. Signature of generate_canonical not useful
    
-
    Section: 26.4.7.2 [rand.util.canonical] Status: WP
- Submitter: Daniel Krügler Date: 2007-03-08
    
+
    Section: 26.5.7.2 [rand.util.canonical] Status: CD1
+ Submitter: Daniel Krügler Opened: 2007-03-08  Last modified: 2008-09-26
    
 
    View all other issues in [rand.util.canonical].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-In 26.4.2 [rand.synopsis] we have the declaration
+In 26.5.1 [rand.synopsis] we have the declaration
 
    
 
 
    template<class RealType, class UniformRandomNumberGenerator,
@@ -25762,12 +26782,12 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
    
 
    660. Missing Bitwise Operations
    
-
    Section: 20.6 [function.objects] Status: WP
- Submitter: Beman Dawes Date: 2007-04-02
    
+
    Section: 20.7 [function.objects] Status: CD1
+ Submitter: Beman Dawes Opened: 2007-04-02  Last modified: 2008-09-26
    
 
    View all other issues in [function.objects].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
-
    Section 20.6 [function.objects] provides function
+
    Section 20.7 [function.objects] provides function
 objects for some unary and binary 
 operations, but others are missing. In a LWG reflector discussion, beginning 
 with c++std-lib-18078, pros and cons of adding some of the missing operations 
@@ -25786,7 +26806,7 @@ resolution is limited to them.
    
 
 
 
    Proposed resolution:
    
-
    To 20.6 [function.objects], Function objects, paragraph 2, add to the header 
+
    To 20.7 [function.objects], Function objects, paragraph 2, add to the header 
 <functional> synopsis:
    
 
    
   
    template <class T> struct bit_and;
@@ -25823,13 +26843,13 @@ template <class T> struct bit_xor;
    
 
 
    
 
    661. New 27.6.1.2.2 changes make special extractions useless
    
-
    Section: 27.6.1.2.2 [istream.formatted.arithmetic] Status: WP
- Submitter: Daniel Krügler Date: 2007-04-01
    
+
    Section: 27.7.1.2.2 [istream.formatted.arithmetic] Status: CD1
+ Submitter: Daniel Krügler Opened: 2007-04-01  Last modified: 2008-09-26
    
 
    View all other issues in [istream.formatted.arithmetic].
    
-
    View all issues with WP status.
    
+
    View all issues with CD1 status.
    
 
    Discussion:
    
 
    
-To the more drastic changes of 27.6.1.2.2 [istream.formatted.arithmetic] in the current draft N2134 belong
+To the more drastic changes of 27.7.1.2.2 [istream.formatted.arithmetic] in the current draft N2134 belong
 the explicit description of the extraction of the types short and int in
 terms of as-if code fragments.
 
    
@@ -25845,7 +26865,7 @@ beginning of the if-statement to be valid C++.
 
  • I would like to ask whether the omission of a similar explicit
 extraction of unsigned short and unsigned int in terms of long -
 compared to their corresponding new insertions, as described in
-27.6.2.6.2 [ostream.inserters.arithmetic], is a deliberate decision or
+27.7.2.6.2 [ostream.inserters.arithmetic], is a deliberate decision or
 an
 oversight.
 
    • 
@@ -25856,7 +26876,7 @@ oversight.
 
      
 
    1. 
 
      
-In 27.6.1.2.2 [istream.formatted.arithmetic]/2 change the current as-if code fragment
+In 27.7.1.2.2 [istream.formatted.arithmetic]/2 change the current as-if code fragment
 
      
 
      typedef num_get<charT,istreambuf_iterator<charT,traits> > numget;
 iostate err = 0;
@@ -25872,7 +26892,7 @@ setstate(err);
 
      
 
 
      
-Similarily in 27.6.1.2.2 [istream.formatted.arithmetic]/3 change the current as-if fragment
+Similarily in 27.7.1.2.2 [istream.formatted.arithmetic]/3 change the current as-if fragment
 
      
 
 
      typedef num_get<charT,istreambuf_iterator<charT,traits> > numget;
@@ -25909,13 +26929,13 @@ is deliberate.
 
 
      
 
      664. do_unshift for codecvt<char, char, mbstate_t>
      
-
      Section: 22.2.1.4.2 [locale.codecvt.virtuals] Status: WP
- Submitter: Thomas Plum Date: 2007-04-16
      
+
      Section: 22.4.1.4.2 [locale.codecvt.virtuals] Status: CD1
+ Submitter: Thomas Plum Opened: 2007-04-16  Last modified: 2008-09-26
      
 
      View all other issues in [locale.codecvt.virtuals].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
-22.2.1.4.2 [locale.codecvt.virtuals], para 7 says (regarding do_unshift):
+22.4.1.4.2 [locale.codecvt.virtuals], para 7 says (regarding do_unshift):
 
      
 
 
      
@@ -25944,7 +26964,7 @@ instantiations of codecvt, it is overly restrictive to say that
 
 
      Proposed resolution:
      
 
      
-Change 22.2.1.4.2 [locale.codecvt.virtuals], p7:
+Change 22.4.1.4.2 [locale.codecvt.virtuals], p7:
 
      
 
 
      
@@ -25964,13 +26984,13 @@ mbstate_t> stores no characters.
 
 
      
 
      665. do_unshift return value
      
-
      Section: 22.2.1.4.2 [locale.codecvt.virtuals] Status: WP
- Submitter: Thomas Plum Date: 2007-04-16
      
+
      Section: 22.4.1.4.2 [locale.codecvt.virtuals] Status: CD1
+ Submitter: Thomas Plum Opened: 2007-04-16  Last modified: 2008-09-26
      
 
      View all other issues in [locale.codecvt.virtuals].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
-22.2.1.4.2 [locale.codecvt.virtuals], para 8 says:
+22.4.1.4.2 [locale.codecvt.virtuals], para 8 says:
 
      
 
 
      
@@ -25995,7 +27015,7 @@ C functions do.
 
 
      Proposed resolution:
      
 
      
-Change 22.2.1.4.2 [locale.codecvt.virtuals], p8:
+Change 22.4.1.4.2 [locale.codecvt.virtuals], p8:
 
      
 
 
      
@@ -26013,13 +27033,13 @@ Change 22.2.1.4.2 [locale.codecvt.virtuals], p8:
 
 
      
 
      666. moneypunct::do_curr_symbol()
      
-
      Section: 22.2.6.3.2 [locale.moneypunct.virtuals] Status: WP
- Submitter: Thomas Plum Date: 2007-04-16
      
+
      Section: 22.4.6.3.2 [locale.moneypunct.virtuals] Status: CD1
+ Submitter: Thomas Plum Opened: 2007-04-16  Last modified: 2008-09-26
      
 
      View all other issues in [locale.moneypunct.virtuals].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
-22.2.6.3.2 [locale.moneypunct.virtuals], para 4 footnote 257 says
+22.4.6.3.2 [locale.moneypunct.virtuals], para 4 footnote 257 says
 
      
 
 
      
@@ -26045,7 +27065,7 @@ four characters long.
 
 
      Proposed resolution:
      
 
      
-Change footnote 253 in 22.2.6.3.2 [locale.moneypunct.virtuals]:
+Change footnote 253 in 22.4.6.3.2 [locale.moneypunct.virtuals]:
 
      
 
 
      
@@ -26062,11 +27082,10 @@ four characters long, usually three letters and a space.
 
 
      
 
      672. Swappable requirements need updating
      
-
      Section: 20.1.1 [utility.arg.requirements] Status: WP
- Submitter: Howard Hinnant Date: 2007-05-04
      
-
      View other active issues in [utility.arg.requirements].
      
+
      Section: X [utility.arg.requirements] Status: CD1
+ Submitter: Howard Hinnant Opened: 2007-05-04  Last modified: 2008-09-26
      
 
      View all other issues in [utility.arg.requirements].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 The current Swappable is:
@@ -26153,7 +27172,7 @@ between two different types for the case that one is binding to a user-defined <
 
      Proposed resolution:
      
 
 
      
-Change 20.1.1 [utility.arg.requirements]:
+Change X [utility.arg.requirements]:
 
      
 
 
      
@@ -26207,7 +27226,7 @@ Kona (2007): We like the change to the Swappable requirements to use
 move semantics. The issue relating to the support of proxies is
 separable from the one relating to move semantics, and it's bigger than
 just swap. We'd like to address only the move semantics changes under
-this issue, and open a separated issue (742) to handle proxies. Also, there
+this issue, and open a separated issue (742) to handle proxies. Also, there
 may be a third issue, in that the current definition of Swappable does
 not permit rvalues to be operands to a swap operation, and Howard's
 proposed resolution would allow the right-most operand to be an rvalue,
@@ -26222,10 +27241,10 @@ swap to be rvalues).
 
 
      
 
      673. unique_ptr update
      
-
      Section: 20.7.11 [unique.ptr] Status: WP
- Submitter: Howard Hinnant Date: 2007-05-04
      
+
      Section: 20.8.12 [unique.ptr] Status: CD1
+ Submitter: Howard Hinnant Opened: 2007-05-04  Last modified: 2008-09-26
      
 
      View all other issues in [unique.ptr].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 Since the publication of
@@ -26344,7 +27363,7 @@ the proposed resolutions below.
 
    2. 
 
 
      
-Change 20.7.11.2 [unique.ptr.single]:
+Change 20.8.12.2 [unique.ptr.single]:
 
      
 
 
      template <class T, class D = default_delete<T>> class unique_ptr {
@@ -26355,7 +27374,7 @@ Change 20.7.11.2 [unique.ptr.single]:
 
      
 
 
      
-Change 20.7.11.2.4 [unique.ptr.single.observers]:
+Change 20.8.12.2.4 [unique.ptr.single.observers]:
 
      
 
 
      T& typename add_lvalue_reference<T>::type operator*() const;
@@ -26365,7 +27384,7 @@ Change 20.7.11.2.4 [unique.ptr.single.observers]:
 
 
    3. 
 
      
-Change 20.7.11.2 [unique.ptr.single]:
+Change 20.8.12.2 [unique.ptr.single]:
 
      
 
 
      template <class T, class D = default_delete<T>> class unique_ptr {
@@ -26397,7 +27416,7 @@ and CopyAssignable.
 
      
 
 
      
-Change 20.7.11.2.1 [unique.ptr.single.ctor]:
+Change 20.8.12.2.1 [unique.ptr.single.ctor]:
 
      
 
 
      unique_ptr(T* pointer p);
@@ -26437,7 +27456,7 @@ internally stored deleter which was constructed from
 
      
 
 
      
-Change 20.7.11.2.3 [unique.ptr.single.asgn]:
+Change 20.8.12.2.3 [unique.ptr.single.asgn]:
 
      
 
 
      
@@ -26450,7 +27469,7 @@ convertible to T* pointer.
 
      
 
 
      
-Change 20.7.11.2.4 [unique.ptr.single.observers]:
+Change 20.8.12.2.4 [unique.ptr.single.observers]:
 
      
 
 
      
@@ -26460,7 +27479,7 @@ Change 20.7.11.2.4 [unique.ptr.single.observers]:
 
      
 
 
      
-Change 20.7.11.2.5 [unique.ptr.single.modifiers]:
+Change 20.8.12.2.5 [unique.ptr.single.modifiers]:
 
      
 
 
      
@@ -26470,7 +27489,7 @@ Change 20.7.11.2.5 [unique.ptr.single.modifiers]:
 
      
 
 
      
-Change 20.7.11.3 [unique.ptr.runtime]:
+Change 20.8.12.3 [unique.ptr.runtime]:
 
      
 
 
      template <class T, class D> class unique_ptr<T[], D> {
@@ -26490,7 +27509,7 @@ public:
 
      
 
 
      
-Change 20.7.11.3.1 [unique.ptr.runtime.ctor]:
+Change 20.8.12.3.1 [unique.ptr.runtime.ctor]:
 
      
 
 
      
@@ -26509,7 +27528,7 @@ these members. -- end note]
 
      
 
 
      
-Change 20.7.11.3.3 [unique.ptr.runtime.modifiers]:
+Change 20.8.12.3.3 [unique.ptr.runtime.modifiers]:
 
      
 
 
      
@@ -26529,7 +27548,7 @@ templated overload. -- end note]
 
    4. 
 
 
      
-Change 20.7.11.2.1 [unique.ptr.single.ctor]:
+Change 20.8.12.2.1 [unique.ptr.single.ctor]:
 
      
 
 
      
@@ -26563,11 +27582,11 @@ required).
 
 
      
 
      674. shared_ptr interface changes for consistency with N1856
      
-
      Section: 20.7.12.2 [util.smartptr.shared] Status: WP
- Submitter: Peter Dimov Date: 2007-05-05
      
+
      Section: 20.8.13.2 [util.smartptr.shared] Status: CD1
+ Submitter: Peter Dimov Opened: 2007-05-05  Last modified: 2008-09-26
      
 
      View other active issues in [util.smartptr.shared].
      
 
      View all other issues in [util.smartptr.shared].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 N1856 does not propose
@@ -26579,7 +27598,7 @@ and to interoperate with unique_ptr as it does with auto_ptr.
 
      Proposed resolution:
      
 
 
      
-Change 20.7.12.2 [util.smartptr.shared] as follows:
+Change 20.8.13.2 [util.smartptr.shared] as follows:
 
      
 
 
      
@@ -26593,7 +27612,7 @@ template<class Y, class D> shared_ptr& operator=(unique_ptr<Y,D>
 
      
 
 
      
-Change 20.7.12.2.1 [util.smartptr.shared.const] as follows:
+Change 20.8.13.2.1 [util.smartptr.shared.const] as follows:
 
      
 
 
      
@@ -26601,7 +27620,7 @@ Change 20.7.12.2.1 [util.smartptr.shared.const] as follows:
 
      
 
 
      
-Add to 20.7.12.2.1 [util.smartptr.shared.const]:
+Add to 20.8.13.2.1 [util.smartptr.shared.const]:
 
      
 
 
      
@@ -26622,7 +27641,7 @@ Add to 20.7.12.2.1 [util.smartptr.shared.const]:
 
      
 
 
      
-Change 20.7.12.2.3 [util.smartptr.shared.assign] as follows:
+Change 20.8.13.2.3 [util.smartptr.shared.assign] as follows:
 
      
 
 
      
@@ -26630,7 +27649,7 @@ Change 20.7.12.2.3 [util.smartptr.shared.assign] as follows:
 
      
 
 
      
-Add to 20.7.12.2.3 [util.smartptr.shared.assign]:
+Add to 20.8.13.2.3 [util.smartptr.shared.assign]:
 
      
 
 
      
@@ -26658,13 +27677,122 @@ whether shared_ptr needs an rvalue swap.
 
 
 
+
      
+
      675. Move assignment of containers
      
+
      Section: 23.2 [container.requirements] Status: CD1
+ Submitter: Howard Hinnant Opened: 2007-05-05  Last modified: 2008-09-26
      
+
      View other active issues in [container.requirements].
      
+
      View all other issues in [container.requirements].
      
+
      View all issues with CD1 status.
      
+
      Discussion:
      
+
      
+James Hopkin pointed out to me that if vector<T> move assignment is O(1)
+(just a swap) then containers such as vector<shared_ptr<ostream>> might have
+the wrong semantics under move assignment when the source is not truly an rvalue, but a
+moved-from lvalue (destructors could run late).
+
      
+
+
      vector<shared_ptr<ostream>> v1;
+vector<shared_ptr<ostream>> v2;
+...
+v1 = v2;               // #1
+v1 = std::move(v2);    // #2
+
      
+
+
      
+Move semantics means not caring what happens to the source (v2 in this example).
+It doesn't mean not caring what happens to the target (v1).  In the above example
+both assignments should have the same effect on v1.  Any non-shared ostream's
+v1 owns before the assignment should be closed, whether v1 is undergoing
+copy assignment or move assignment.
+
      
+
+
      
+This implies that the semantics of move assignment of a generic container should be
+clear, swap instead of just swap.  An alternative which could achieve the same
+effect would be to move assign each element.  In either case, the complexity of move
+assignment needs to be relaxed to O(v1.size()).
+
      
+
+
      
+The performance hit of this change is not nearly as drastic as it sounds. 
+In practice, the target of a move assignment has always just been move constructed
+or move assigned from.  Therefore under clear, swap semantics (in
+this common use case) we are still achieving O(1) complexity.
+
      
+
+
+
+
      Proposed resolution:
      
+
      
+Change 23.2 [container.requirements]:
+
      
+
+
      
+
+
+
+
+
+
+
+
+
+
+
+
+
      Table 89: Container requirements
      expressionreturn typeoperational semanticsassertion/note pre/post-conditioncomplexity
      a = rv;X&All existing elements of a are either move assigned or destructeda shall be equal to the 
+value that rv had 
+before this construction
+(Note C) linear
      
+
+
      
+Notes: the algorithms swap(), equal() and
+lexicographical_compare() are defined in clause 25. Those
+entries marked "(Note A)" should have constant complexity. Those entries
+marked "(Note B)" have constant complexity unless
+allocator_propagate_never<X::allocator_type>::value is
+true, in which case they have linear complexity.
+Those entries
+marked "(Note C)" have constant complexity if a.get_allocator() ==
+rv.get_allocator() or if either
+allocator_propagate_on_move_assignment<X::allocator_type>::value
+is true or
+allocator_propagate_on_copy_assignment<X::allocator_type>::value
+is true and linear complexity otherwise.
+
      
+
      
+
+
+
+
      [
+post Bellevue Howard adds:
+]
      
+
+
+
      
+
      
+This issue was voted to WP in Bellevue, but accidently got stepped on by
+N2525
+which was voted to WP simulataneously.  Moving back to Open for the purpose of getting
+the wording right.  The intent of this issue and N2525 are not in conflict.
+
      
+
      
+
+
      [
+post Sophia Antipolis Howard updated proposed wording:
+]
      
+
+
+
+
+
 
      
 
      677. Weaknesses in seed_seq::randomize [rand.util.seedseq]
      
-
      Section: 26.4.7.1 [rand.util.seedseq] Status: WP
- Submitter: Charles Karney Date: 2007-05-15
      
-
      View other active issues in [rand.util.seedseq].
      
+
      Section: 26.5.7.1 [rand.util.seedseq] Status: CD1
+ Submitter: Charles Karney Opened: 2007-05-15  Last modified: 2008-09-26
      
 
      View all other issues in [rand.util.seedseq].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 seed_seq::randomize provides a mechanism for initializing random number
@@ -26765,13 +27893,13 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
      
 
      678. Changes for [rand.req.eng]
      
-
      Section: 26.4.1.3 [rand.req.eng] Status: WP
- Submitter: Charles Karney Date: 2007-05-15
      
+
      Section: X [rand.req.eng] Status: CD1
+ Submitter: Charles Karney Opened: 2007-05-15  Last modified: 2008-09-26
      
 
      View all other issues in [rand.req.eng].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
-Section 26.4.1.3 [rand.req.eng] Random number engine requirements:
+Section X [rand.req.eng] Random number engine requirements:
 
      
 
 
      
@@ -26789,7 +27917,7 @@ the case q.size() == 0.  This is undesirable for 4 reasons:
 
    5. It leads to the possibility of a collision in the state provided
     by some other X(q) with q.size() > 0.
      6. 
 
    6. It is inconsistent with the description of the X(q) in
-paragraphs 26.4.3.1 [rand.eng.lcong] p5, 26.4.3.2 [rand.eng.mers] p8, and 26.4.3.3 [rand.eng.sub] p10 where
+paragraphs 26.5.3.1 [rand.eng.lcong] p5, 26.5.3.2 [rand.eng.mers] p8, and 26.5.3.3 [rand.eng.sub] p10 where
 there is no special treatment of q.size() == 0.
      7. 
 
    7. The proposed replacement for seed_seq::randomize given above
     allows for the case q.size() == 0.
      8. 
@@ -26820,9 +27948,10 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
      
 
      679. resize parameter by value
      
-
      Section: 23.2 [sequences] Status: WP
- Submitter: Howard Hinnant Date: 2007-06-11
      
-
      View all issues with WP status.
      
+
      Section: 23.3 [sequences] Status: CD1
+ Submitter: Howard Hinnant Opened: 2007-06-11  Last modified: 2008-09-26
      
+
      View all other issues in [sequences].
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 The C++98 standard specifies that one member function alone of the containers
@@ -26902,7 +28031,7 @@ CodeWarrior library with no reports of problems which I am aware of.
 
 
      Proposed resolution:
      
 
      
-Change 23.2.2 [deque], p2:
+Change 23.3.2 [deque], p2:
 
      
 
 
      class deque {
@@ -26911,14 +28040,14 @@ Change 23.2.2 [deque], p2:
 
      
 
 
      
-Change 23.2.2.2 [deque.capacity], p3:
+Change 23.3.2.2 [deque.capacity], p3:
 
      
 
 
      void resize(size_type sz, const T& c);
 
      
 
 
      
-Change 23.2.4 [list], p2:
+Change 23.3.4 [list], p2:
 
      
 
 
      class list {
@@ -26927,14 +28056,14 @@ Change 23.2.4 [list], p2:
 
      
 
 
      
-Change 23.2.4.2 [list.capacity], p3:
+Change 23.3.4.2 [list.capacity], p3:
 
      
 
 
      void resize(size_type sz, const T& c);
 
      
 
 
      
-Change 23.2.6 [vector], p2:
+Change 23.3.6 [vector], p2:
 
      
 
 
      class vector {
@@ -26943,7 +28072,7 @@ Change 23.2.6 [vector], p2:
 
      
 
 
      
-Change 23.2.6.2 [vector.capacity], p11:
+Change 23.3.6.2 [vector.capacity], p11:
 
      
 
 
      void resize(size_type sz, const T& c);
@@ -26956,14 +28085,14 @@ Change 23.2.6.2 [vector.capacity], p11:
 
 
      
 
      680. move_iterator operator-> return
      
-
      Section: 24.4.3.1 [move.iterator] Status: WP
- Submitter: Howard Hinnant Date: 2007-06-11
      
-
      View all issues with WP status.
      
+
      Section: 24.5.3.1 [move.iterator] Status: CD1
+ Submitter: Howard Hinnant Opened: 2007-06-11  Last modified: 2008-09-26
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 move_iterator's operator-> return type pointer
 does not consistently match the type which is returned in the description
-in 24.4.3.3.5 [move.iter.op.ref].
+in 24.5.3.2.5 [move.iter.op.ref].
 
      
 
 
      template <class Iterator>
@@ -27007,7 +28136,7 @@ finds a non-class type, the second solution avoids the issue of an overloaded
 
 
      Proposed resolution:
      
 
      
-Change the synopsis in 24.4.3.1 [move.iterator]:
+Change the synopsis in 24.5.3.1 [move.iterator]:
 
      
 
 
      typedef typename iterator_traits<Iterator>::pointer pointer;
@@ -27020,19 +28149,19 @@ Change the synopsis in 24.4.3.1 [move.iterator]:
 
 
      
 
      681. Operator functions impossible to compare are defined in [re.submatch.op]
      
-
      Section: 28.9.2 [re.submatch.op] Status: WP
- Submitter: Nozomu Katoo Date: 2007-05-27
      
-
      View all issues with WP status.
      
+
      Section: 28.10.2 [re.submatch.op] Status: CD1
+ Submitter: Nozomu Katoo Opened: 2007-05-27  Last modified: 2009-05-01
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
-In 28.9.2 [re.submatch.op] of N2284, 
-operator functions numbered 31-42 seem impossible to compare.  E.g.: 
+In 28.10.2 [re.submatch.op] of N2284, 
+operator functions numbered 31-42 seem impossible to compare. E.g.: 
 
      
 
 
      
 
      template <class BiIter>
-    bool operator==(typename iterator_traits<BiIter>::value_type const& lhs,
-                    const sub_match<BiIter>& rhs);
+   bool operator==(typename iterator_traits<BiIter>::value_type const& lhs,
+                    const sub_match<BiIter>& rhs);
 
      
 
      
 
      
@@ -27044,9 +28173,9 @@ operator functions numbered 31-42 seem impossible to compare.  E.g.:
 
      
 When char* is used as BiIter, iterator_traits<BiIter>::value_type would be 
 char, so that lhs == rhs.str() ends up comparing a char value and an object 
-of std::basic_string<char>.  However, the behaviour of comparison between 
-these two types is not defined in 21.3.8 [string.nonmembers] of N2284.
- This applies when wchar_t* is used as BiIter. 
+of std::basic_string<char>.  However, the behaviour of comparison between 
+these two types is not defined in 21.4.8 [string.nonmembers] of N2284.
+ This applies when wchar_t* is used as BiIter. 
 
      
 
 
@@ -27068,26 +28197,27 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
      
 
      682. basic_regex ctor takes InputIterator or ForwardIterator?
      
-
      Section: 28.8.2 [re.regex.construct] Status: WP
- Submitter: Eric Niebler Date: 2007-06-03
      
-
      View all issues with WP status.
      
+
      Section: 28.9.2 [re.regex.construct] Status: CD1
+ Submitter: Eric Niebler Opened: 2007-06-03  Last modified: 2009-05-01
      
+
      View all other issues in [re.regex.construct].
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
-Looking at N2284, 28.8 [re.regex], p3 basic_regex class template synopsis shows this 
+Looking at N2284, 28.9 [re.regex], p3 basic_regex class template synopsis shows this 
 constructor: 
 
      
 
      template <class InputIterator>
-     basic_regex(InputIterator first, InputIterator last, 
-                 flag_type f = regex_constants::ECMAScript);
+     basic_regex(InputIterator first, InputIterator last, 
+                 flag_type f = regex_constants::ECMAScript);
 
      
 
 
      
-In 28.8.2 [re.regex.construct], p15, the constructor appears with this signature: 
+In 28.9.2 [re.regex.construct], p15, the constructor appears with this signature: 
 
      
 
 
      template <class ForwardIterator>
-     basic_regex(ForwardIterator first, ForwardIterator last, 
-                 flag_type f = regex_constants::ECMAScript);
+     basic_regex(ForwardIterator first, ForwardIterator last, 
+                 flag_type f = regex_constants::ECMAScript);
 
      
 
 
      
@@ -27101,7 +28231,7 @@ John adds:
 
 
      
 
      
-I think either could be implemented?  Although an input iterator would 
+I think either could be implemented?  Although an input iterator would 
 probably require an internal copy of the string being made.
 
      
 
      
@@ -27129,9 +28259,9 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
      
 
      685. reverse_iterator/move_iterator difference has invalid signatures
      
-
      Section: 24.4.1.3.19 [reverse.iter.opdiff], 24.4.3.3.14 [move.iter.nonmember] Status: WP
- Submitter: Bo Persson Date: 2007-06-10
      
-
      View all issues with WP status.
      
+
      Section: 24.5.1.2.19 [reverse.iter.opdiff], 24.5.3.2.14 [move.iter.nonmember] Status: CD1
+ Submitter: Bo Persson Opened: 2007-06-10  Last modified: 2008-09-26
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 In C++03 the difference between two reverse_iterators
@@ -27143,7 +28273,7 @@ is possible to compute only if both iterators have the same base
 iterator. The result type is the difference_type of the base iterator. 
 
      
 
      
-In the current draft, the operator is defined as 24.4.1.3.19 [reverse.iter.opdiff] 
+In the current draft, the operator is defined as 24.5.1.2.19 [reverse.iter.opdiff] 
 
      
 
      template<class Iterator1, class Iterator2> 
 typename reverse_iterator<Iterator>::difference_type 
@@ -27161,13 +28291,13 @@ implementation choose one of them? Which one?
 
      
 
      
 The same problem now also appears in operator-() for move_iterator
-24.4.3.3.14 [move.iter.nonmember]. 
+24.5.3.2.14 [move.iter.nonmember]. 
 
      
 
 
 
      Proposed resolution:
      
 
      
-Change the synopsis in 24.4.1.1 [reverse.iterator]:
+Change the synopsis in 24.5.1.1 [reverse.iterator]:
 
      
 
 
      
@@ -27179,7 +28309,7 @@ Change the synopsis in 24.4.1.1 [reverse.iterator]:
 
      
 
 
      
-Change 24.4.1.3.19 [reverse.iter.opdiff]:
+Change 24.5.1.2.19 [reverse.iter.opdiff]:
 
      
 
 
      
@@ -27197,7 +28327,7 @@ Change 24.4.1.3.19 [reverse.iter.opdiff]:
 
 
 
      
-Change the synopsis in 24.4.3.1 [move.iterator]:
+Change the synopsis in 24.5.3.1 [move.iterator]:
 
      
 
 
      
@@ -27209,7 +28339,7 @@ Change the synopsis in 24.4.3.1 [move.iterator]:
 
      
 
 
      
-Change 24.4.3.3.14 [move.iter.nonmember]:
+Change 24.5.3.2.14 [move.iter.nonmember]:
 
      
 
 
      
@@ -27238,10 +28368,11 @@ goes in.
 
 
      
 
      687. shared_ptr conversion constructor not constrained
      
-
      Section: 20.7.12.2.1 [util.smartptr.shared.const], 20.7.12.3.1 [util.smartptr.weak.const] Status: WP
- Submitter: Peter Dimov Date: 2007-05-10
      
+
      Section: 20.8.13.2.1 [util.smartptr.shared.const], 20.8.13.3.1 [util.smartptr.weak.const] Status: CD1
+ Submitter: Peter Dimov Opened: 2007-05-10  Last modified: 2009-02-02
      
+
      View other active issues in [util.smartptr.shared.const].
      
 
      View all other issues in [util.smartptr.shared.const].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 Since all conversions from shared_ptr<T> to shared_ptr<U> have the same
@@ -27254,7 +28385,7 @@ void f( shared_ptr<int> );
 
 int main()
 {
-  f( shared_ptr<double>() ); // ambiguous
+  f( shared_ptr<double>() ); // ambiguous
 }
 
      
 
@@ -27267,7 +28398,7 @@ overload resolution when the pointer types are compatible.
 
 
      Proposed resolution:
      
 
      
-In 20.7.12.2.1 [util.smartptr.shared.const], change:
+In 20.8.13.2.1 [util.smartptr.shared.const], change:
 
      
 
 
      
@@ -27278,7 +28409,7 @@ to T*.
 
      
 
 
      
-In 20.7.12.3.1 [util.smartptr.weak.const], change:
+In 20.8.13.3.1 [util.smartptr.weak.const], change:
 
      
 
 
      
@@ -27304,10 +28435,10 @@ overload resolution unless Y* shall be
 
 
      
 
      689. reference_wrapper constructor overly constrained
      
-
      Section: 20.6.5.1 [refwrap.const] Status: WP
- Submitter: Peter Dimov Date: 2007-05-10
      
+
      Section: 20.7.5.1 [refwrap.const] Status: CD1
+ Submitter: Peter Dimov Opened: 2007-05-10  Last modified: 2008-09-26
      
 
      View all other issues in [refwrap.const].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 The constructor of reference_wrapper is currently explicit. The primary
@@ -27332,12 +28463,175 @@ proposed resolution of the previous issue is accepted, remove the
 
 
 
+
      
+
      691. const_local_iterator cbegin, cend missing from TR1
      
+
      Section: 23.5 [unord], TR1 6.3 [tr.hash] Status: CD1
+ Submitter: Joaquín M López Muńoz Opened: 2007-06-14  Last modified: 2008-09-26
      
+
      View all other issues in [unord].
      
+
      View all issues with CD1 status.
      
+
      Discussion:
      
+
      
+The last version of TR1 does not include the following member
+functions
+for unordered containers:
+
      
+
+
      const_local_iterator cbegin(size_type n) const;
+const_local_iterator cend(size_type n) const;
+
      
+
+
      
+which looks like an oversight to me. I've checked th TR1 issues lists
+and the latest working draft of the C++0x std (N2284) and haven't
+found any mention to these menfuns or to their absence.
+
      
+
      
+Is this really an oversight, or am I missing something?
+
      
+
+
+
+
      Proposed resolution:
      
+
      
+Add the following two rows to table 93 (unordered associative container
+requirements) in section 23.2.5 [unord.req]:
+
      
+
+
      
+
+
+
+
+
+
+ 
+
+
+ 
+
+
      Unordered associative container requirements (in addition to container)
      expression return type assertion/note pre/post-condition complexity
      b.cbegin(n) const_local_iterator n shall be in the range [0, bucket_count()). Note: [b.cbegin(n), b.cend(n)) is a valid range containing all of the elements in the nth bucket. Constant
      b.cend(n) const_local_iterator n shall be in the range [0, bucket_count()). Constant
      
+
      
+
+
      
+Add to the synopsis in 23.5.1 [unord.map]:
+
      
+
+
      const_local_iterator cbegin(size_type n) const;
+const_local_iterator cend(size_type n) const;
+
      
+
+
      
+Add to the synopsis in 23.5.2 [unord.multimap]:
+
      
+
+
      const_local_iterator cbegin(size_type n) const;
+const_local_iterator cend(size_type n) const;
+
      
+
+
      
+Add to the synopsis in 23.5.3 [unord.set]:
+
      
+
+
      const_local_iterator cbegin(size_type n) const;
+const_local_iterator cend(size_type n) const;
+
      
+
+
      
+Add to the synopsis in 23.5.4 [unord.multiset]:
+
      
+
+
      const_local_iterator cbegin(size_type n) const;
+const_local_iterator cend(size_type n) const;
+
      
+
+
+
+
+
+
+
      
+
      692. get_money and put_money should be formatted I/O functions
      
+
      Section: 27.7.4 [ext.manip] Status: CD1
+ Submitter: Martin Sebor Opened: 2007-06-22  Last modified: 2008-09-26
      
+
      View all other issues in [ext.manip].
      
+
      View all issues with CD1 status.
      
+
      Discussion:
      
+
      
+In a private email Bill Plauger notes:
+
      
+
      
+I  believe that  the function  that  implements get_money
+[from N2072]
+should behave  as a  formatted input function,  and the  function that
+implements put_money should  behave as a formatted output
+function. This  has implications regarding the  skipping of whitespace
+and the handling of errors, among other things.
+
      
+
      
+The words  don't say that  right now and  I'm far from  convinced that
+such a change is editorial.
+
      
+
      
+Martin's response:
+
      
+
      
+I agree that the manipulators should handle exceptions the same way as
+formatted I/O functions do. The text in N2072 assumes so but the
+Returns clause explicitly omits exception handling for the sake
+of brevity. The spec should be clarified to that effect.
+
      
+
      
+As for dealing  with whitespace, I also agree it  would make sense for
+the extractors  and inserters involving the new  manipulators to treat
+it the same way as formatted I/O.
+
      
+
+
+
      Proposed resolution:
      
+
      
+Add  a new  paragraph immediately  above  p4 of 27.7.4 [ext.manip] with  the
+following text:
+
      
+
      
+Effects:  The   expression  in >> get_money(mon, intl)
+described below behaves as a formatted input function (as
+described in 27.7.1.2.1 [istream.formatted.reqmts]).
+
      
+
      
+Also change p4 of 27.7.4 [ext.manip] as follows:
+
      
+
      
+Returns: An object s of unspecified type such that
+if in is  an object of type basic_istream<charT,
+traits>    then    the    expression   in >> get_money(mon, intl) behaves as a formatted input function
+that    calls    f(in, mon, intl)    were
+called. The function f can be defined as...
+
      
+
+
+
      [
+post Bellevue:
+]
      
+
+
+
      
+We recommend moving immediately to Review. We've looked at the issue and
+have a consensus that the proposed resolution is correct, but want an
+iostream expert to sign off. Alisdair has taken the action item to putt
+this up on the reflector for possible movement by Howard to Tenatively
+Ready.
+
      
+
+
+
+
 
      
 
      693. std::bitset::all() missing
      
-
      Section: 23.3.5 [template.bitset] Status: WP
- Submitter: Martin Sebor Date: 2007-06-22
      
+
      Section: 20.3.6 [template.bitset] Status: CD1
+ Submitter: Martin Sebor Opened: 2007-06-22  Last modified: 2008-09-26
      
+
      View other active issues in [template.bitset].
      
 
      View all other issues in [template.bitset].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 The  bitset class template  provides the  member function
@@ -27360,7 +28654,7 @@ the first word with a zero bit).
 
      Proposed resolution:
      
 
      
 Add  a declaration of the new  member function all() to the
-defintion of the bitset template in 23.3.5 [template.bitset], p1,
+defintion of the bitset template in 20.3.6 [template.bitset], p1,
 right above the declaration of any() as shown below:
 
      
 
@@ -27372,7 +28666,7 @@ bool none() const;
 
      
 
 
      
-Add a description of the new member function to the end of 23.3.5.2 [bitset.members] with the following text:
+Add a description of the new member function to the end of 20.3.6.2 [bitset.members] with the following text:
 
      
 
      
 bool all() const;
@@ -27413,10 +28707,11 @@ is onecount() == 0.
 
 
      
 
      694. std::bitset and long long
      
-
      Section: 23.3.5 [template.bitset] Status: WP
- Submitter: Martin Sebor Date: 2007-06-22
      
+
      Section: 20.3.6 [template.bitset] Status: CD1
+ Submitter: Martin Sebor Opened: 2007-06-22  Last modified: 2008-09-26
      
+
      View other active issues in [template.bitset].
      
 
      View all other issues in [template.bitset].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 Objects of the  bitset class template specializations can
@@ -27453,7 +28748,7 @@ explicit bitset(
 
      
 
      
 
      
-Make a corresponding change in 23.3.5.1 [bitset.cons], p2:
+Make a corresponding change in 20.3.6.1 [bitset.cons], p2:
 
      
 
      
 
      
@@ -27476,7 +28771,7 @@ Additionally, introduce a new member function to_ullong()
 to make  it possible to  convert bitset to values  of the
 new  type. Add  the following  declaration  to the  definition of  the
 template, immediate  after the declaration  of to_ulong()
-in 23.3.5 [template.bitset], p1, as shown below:
+in 20.3.6 [template.bitset], p1, as shown below:
 
      
 
      
 
      // element access:
@@ -27489,7 +28784,7 @@ basic_string<charT, traits, Allocator> to_string() const;
 
      
 
      
 
      
-And add a description of  the new member function to 23.3.5.2 [bitset.members],
+And add a description of  the new member function to 20.3.6.2 [bitset.members],
 below  the  description of  the  existing to_ulong()  (if
 possible), with the following text:
 
      
@@ -27513,9 +28808,9 @@ cannot be represented as type unsigned long long.
 
 
      
 
      695. ctype<char>::classic_table() not accessible
      
-
      Section: 22.2.1.3 [facet.ctype.special] Status: WP
- Submitter: Martin Sebor Date: 2007-06-22
      
-
      View all issues with WP status.
      
+
      Section: 22.4.1.3 [facet.ctype.special] Status: CD1
+ Submitter: Martin Sebor Opened: 2007-06-22  Last modified: 2008-09-26
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 The   ctype<char>::classic_table()   static  member
@@ -27552,7 +28847,7 @@ function table().
 Make     the    ctype<char>::classic_table()    and
 ctype<char>::table()  member  functions  public  by
 moving their declarations into the public section of the definition of
-specialization in 22.2.1.3 [facet.ctype.special] as shown below:
+specialization in 22.4.1.3 [facet.ctype.special] as shown below:
 
      
 
      
 
        static locale::id id;
@@ -27571,12 +28866,91 @@ virtual char do_toupper(char c) const;
 
 
 
+
      
+
      698. system_error needs const char* constructors
      
+
      Section: 19.5.5.1 [syserr.syserr.overview] Status: CD1
+ Submitter: Daniel Krügler Opened: 2007-06-24  Last modified: 2008-09-26
      
+
      View all issues with CD1 status.
      
+
      Discussion:
      
+
      
+In 19.5.5.1 [syserr.syserr.overview] we have the class definition of
+std::system_error. In contrast to all exception classes, which
+are constructible with a what_arg string (see 19.2 [std.exceptions],
+or ios_base::failure in 27.5.2.1.1 [ios::failure]), only overloads with with
+const string& are possible. For consistency with the re-designed
+remaining exception classes this class should also provide
+c'tors which accept a const char* what_arg string.
+
      
+
      
+Please note that this proposed addition makes sense even
+considering the given implementation hint for what(), because
+what_arg is required to be set as what_arg of the base class
+runtime_error, which now has the additional c'tor overload
+accepting a const char*.
+
      
+
+
+
      Proposed resolution:
      
+
      
+This proposed wording assumes issue 832 has been accepted and applied to the working paper.
+
      
+
+
      
+Change 19.5.5.1 [syserr.syserr.overview] Class system_error overview, as indicated:
+
      
+
+
      public:
+  system_error(error_code ec, const string& what_arg);
+  system_error(error_code ec, const char* what_arg);
+  system_error(error_code ec);
+  system_error(int ev, const error_category* ecat,
+      const string& what_arg);
+  system_error(int ev, const error_category* ecat,
+      const char* what_arg);
+  system_error(int ev, const error_category* ecat);
+
      
+
+
      
+To 19.5.5.2 [syserr.syserr.members] Class system_error members add:
+
      
+
+
      
+
      system_error(error_code ec, const char* what_arg);
+
      
+
      
+
      
+Effects: Constructs an object of class system_error.
+
      
+
      
+Postconditions: code() == ec and strcmp(runtime_error::what(), what_arg) == 0.
+
      
+
      
+
+
      system_error(int ev, const error_category* ecat, const char* what_arg);
+
      
+
+
      
+
      
+Effects: Constructs an object of class system_error.
+
      
+
      
+Postconditions: code() == error_code(ev, ecat) and strcmp(runtime_error::what(), what_arg) == 0.
+
      
+
      
+
      
+
+
+
+
+
+
 
      
 
      699. N2111 changes min/max
      
-
      Section: 26.4 [rand] Status: WP
- Submitter: P.J. Plauger Date: 2007-07-01
      
+
      Section: 26.5 [rand] Status: CD1
+ Submitter: P.J. Plauger Opened: 2007-07-01  Last modified: 2008-09-26
      
+
      View other active issues in [rand].
      
 
      View all other issues in [rand].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 N2111
@@ -27612,11 +28986,10 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
      
 
      700. N1856 defines struct identity
      
-
      Section: 20.2.2 [forward] Status: WP
- Submitter: P.J. Plauger Date: 2007-07-01
      
-
      View other active issues in [forward].
      
+
      Section: 20.3.2 [forward] Status: CD1
+ Submitter: P.J. Plauger Opened: 2007-07-01  Last modified: 2008-09-26
      
 
      View all other issues in [forward].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 N1856
@@ -27629,7 +29002,7 @@ if we could avoid this name clash for backward compatibility.
 
 
      Proposed resolution:
      
 
      
-Change 20.2.2 [forward]:
+Change 20.3.2 [forward]:
 
      
 
 
      
@@ -27658,10 +29031,10 @@ Change 20.2.2 [forward]:
 
 
      
 
      703. map::at() need a complexity specification
      
-
      Section: 23.3.1.2 [map.access] Status: WP
- Submitter: Joe Gottman Date: 2007-07-03
      
+
      Section: 23.4.1.2 [map.access] Status: CD1
+ Submitter: Joe Gottman Opened: 2007-07-03  Last modified: 2008-09-26
      
 
      View all other issues in [map.access].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 map::at() need a complexity specification.
@@ -27670,7 +29043,7 @@ Change 20.2.2 [forward]:
 
 
      Proposed resolution:
      
 
      
-Add the following to the specification of map::at(), 23.3.1.2 [map.access]:
+Add the following to the specification of map::at(), 23.4.1.2 [map.access]:
 
      
 
      
 
      
@@ -27684,14 +29057,14 @@ Add the following to the specification of map::at(), 23.3.1.2 [map.acce
 
 
      
 
      705. type-trait decay incompletely specified
      
-
      Section: 20.5.7 [meta.trans.other] Status: WP
- Submitter: Thorsten Ottosen Date: 2007-07-08
      
+
      Section: 20.6.7 [meta.trans.other] Status: CD1
+ Submitter: Thorsten Ottosen Opened: 2007-07-08  Last modified: 2008-09-26
      
 
      View other active issues in [meta.trans.other].
      
 
      View all other issues in [meta.trans.other].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
-The current working draft has a type-trait decay in 20.5.7 [meta.trans.other].
+The current working draft has a type-trait decay in 20.6.7 [meta.trans.other].
 
      
 
 
      
@@ -27705,7 +29078,7 @@ cv-qualification, as pass-by-value does.
 
 
      Proposed resolution:
      
 
      
-In 20.5.7 [meta.trans.other] change the last sentence:
+In 20.6.7 [meta.trans.other] change the last sentence:
 
      
 
 
      
@@ -27713,7 +29086,7 @@ Otherwise the  member typedef type equals remove_cv<U
 
      
 
 
      
-In 20.4.1.3 [tuple.creation]/1 change:
+In 20.5.2.2 [tuple.creation]/1 change:
 
      
 
 
      
@@ -27736,14 +29109,15 @@ is X& if Ui equals
 
 
      
 
      706. make_pair() should behave as make_tuple() wrt. reference_wrapper()
      
-
      Section: 20.2.3 [pairs] Status: WP
- Submitter: Thorsten Ottosen Date: 2007-07-08
      
+
      Section: 20.3.3 [pairs] Status: CD1
+ Submitter: Thorsten Ottosen Opened: 2007-07-08  Last modified: 2008-09-26
      
+
      View other active issues in [pairs].
      
 
      View all other issues in [pairs].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
-The current draft has make_pair() in 20.2.3 [pairs]/16
-and make_tuple() in 20.4.1.3 [tuple.creation].
+The current draft has make_pair() in 20.3.3 [pairs]/16
+and make_tuple() in 20.5.2.2 [tuple.creation].
 make_tuple() detects the presence of
 reference_wrapper<X> arguments and "unwraps" the reference in
 such cases. make_pair() would OTOH create a
@@ -27755,7 +29129,7 @@ confusion.
 
 
      Proposed resolution:
      
 
      
-In 20.2 [utility] change the synopsis for make_pair() to read
+In 20.3 [utility] change the synopsis for make_pair() to read
 
      
 
 
      template <class T1, class T2>
@@ -27763,8 +29137,8 @@ In 20.2 [utility] change the synopsis for make_pair() to read
 
      
 
 
      
-In 20.2.3 [pairs]/16 change the declaration to match the above synopsis.
-Then change the 20.2.3 [pairs]/17 to:
+In 20.3.3 [pairs]/16 change the declaration to match the above synopsis.
+Then change the 20.3.3 [pairs]/17 to:
 
      
 
 
      
@@ -27783,13 +29157,79 @@ Then change the 20.2.3 [pairs]/17 to:
 
 
 
+
      
+
      709. char_traits::not_eof has wrong signature
      
+
      Section: 21.2.3 [char.traits.specializations] Status: CD1
+ Submitter: Bo Persson Opened: 2007-08-13  Last modified: 2008-09-26
      
+
      View all other issues in [char.traits.specializations].
      
+
      View all issues with CD1 status.
      
+
      Discussion:
      
+
      
+The changes made for constexpr in 21.2.3 [char.traits.specializations] have 
+not only changed the not_eof function from pass by const reference to 
+pass by value, it has also changed the parameter type from int_type to 
+char_type.
+
      
+
      
+This doesn't work for type char, and is inconsistent with the 
+requirements in Table 56, Traits requirements, 21.2.1 [char.traits.require].
+
      
+
+
      
+Pete adds:
+
      
+
+
      
+For what it's worth, that may not have been an intentional change. 
+N2349, which detailed the changes for adding constant expressions to 
+the library, has strikeout bars through the const and the & that 
+surround the char_type argument, but none through char_type itself. 
+So the intention may have been just to change to pass by value, with 
+text incorrectly copied from the standard.
+
      
+
+
+
+
      Proposed resolution:
      
+
      
+Change the signature in 21.2.3.1 [char.traits.specializations.char],
+21.2.3.2 [char.traits.specializations.char16_t], 21.2.3.3 [char.traits.specializations.char32_t],
+and 21.2.3.4 [char.traits.specializations.wchar.t] to
+
      
+
+
      static constexpr int_type not_eof(char_type int_type c);
+
      
+
+
+
+
      [
+Bellevue:
+]
      
+
+
+
      
+Resolution: NAD editorial - up to Pete's judgment
+
      
+
+
      [
+Post Sophia Antipolis
+]
      
+
+
+
      
+Moved from Pending NAD Editorial to Review.  The proposed wording appears to be correct but non-editorial.
+
      
+
+
+
+
 
      
 
      710. Missing postconditions
      
-
      Section: 20.7.12.2 [util.smartptr.shared] Status: WP
- Submitter: Peter Dimov Date: 2007-08-24
      
+
      Section: 20.8.13.2 [util.smartptr.shared] Status: CD1
+ Submitter: Peter Dimov Opened: 2007-08-24  Last modified: 2008-09-26
      
 
      View other active issues in [util.smartptr.shared].
      
 
      View all other issues in [util.smartptr.shared].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 A discussion on
@@ -27819,7 +29259,7 @@ editor should consider rewording "If w is the return value...", e. g. as
 
 
      Proposed resolution:
      
 
      
-Add to 20.7.12.2.1 [util.smartptr.shared.const]:
+Add to 20.8.13.2.1 [util.smartptr.shared.const]:
 
      
 
 
      
@@ -27835,7 +29275,7 @@ shall be empty. r.get() == 0.
 
      
 
 
      
-Add to 20.7.12.2.10 [util.smartptr.shared.cast]:
+Add to 20.8.13.2.10 [util.smartptr.shared.cast]:
 
      
 
 
      
@@ -27878,7 +29318,7 @@ the aliasing constructor as follows:
 
      
 
 
      
-Change 20.7.12.2.10 [util.smartptr.shared.cast]:
+Change 20.8.13.2.10 [util.smartptr.shared.cast]:
 
      
 
 
      
@@ -27925,16 +29365,15 @@ in the aliasing constructor postcondition "by reference".
 
 
      
 
      712. seed_seq::size no longer useful
      
-
      Section: 26.4.7.1 [rand.util.seedseq] Status: WP
- Submitter: Marc Paterno Date: 2007-08-25
      
-
      View other active issues in [rand.util.seedseq].
      
+
      Section: 26.5.7.1 [rand.util.seedseq] Status: CD1
+ Submitter: Marc Paterno Opened: 2007-08-25  Last modified: 2008-09-26
      
 
      View all other issues in [rand.util.seedseq].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 One of the motivations for incorporating seed_seq::size()
 was to simplify the wording
-in other parts of 26.4 [rand].
+in other parts of 26.5 [rand].
 As a side effect of resolving related issues,
 all such references
 to seed_seq::size() will have been excised.
@@ -27968,14 +29407,105 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
 
      
-
      715. minmax_element complexity is too lax
      
-
      Section: 25.3.7 [alg.min.max] Status: WP
- Submitter: Matt Austern Date: 2007-08-30
      
-
      View all other issues in [alg.min.max].
      
-
      View all issues with WP status.
      
+
      713. sort() complexity is too lax
      
+
      Section: 25.5.1.1 [sort] Status: CD1
+ Submitter: Matt Austern Opened: 2007-08-30  Last modified: 2008-09-26
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
-The complexity for minmax_element (25.3.7 [alg.min.max] par 16) says "At most max(2 *
+The complexity of sort() is specified as "Approximately N
+log(N) (where N == last - first ) comparisons on the
+average", with no worst case complicity specified. The intention was to
+allow a median-of-three quicksort implementation, which is usually O(N
+log N) but can be quadratic for pathological inputs. However, there is
+no longer any reason to allow implementers the freedom to have a
+worst-cast-quadratic sort algorithm. Implementers who want to use
+quicksort can use a variant like David Musser's "Introsort" (Software
+Practice and Experience 27:983-993, 1997), which is guaranteed to be O(N
+log N) in the worst case without incurring additional overhead in the
+average case. Most C++ library implementers already do this, and there
+is no reason not to guarantee it in the standard.
+
      
+
+
+
      Proposed resolution:
      
+
      
+In 25.5.1.1 [sort], change the complexity to "O(N log N)", and remove footnote 266:
+
      
+
+
      
+
      
+Complexity: Approximately O(N log(N)) (where N == last - first )
+comparisons on the average.266)
+
      
+
      
+266)
+If the worst case behavior is important stable_sort() (25.3.1.2) or partial_sort()
+(25.3.1.3) should be used.
+
      
+
      
+
+
+
+
+
+
+
      
+
      714. search_n complexity is too lax
      
+
      Section: 25.3.12 [alg.search] Status: CD1
+ Submitter: Matt Austern Opened: 2007-08-30  Last modified: 2008-09-26
      
+
      View all other issues in [alg.search].
      
+
      View all issues with CD1 status.
      
+
      Discussion:
      
+
      
+The complexity for search_n (25.3.12 [alg.search] par 7) is specified as "At most
+(last - first ) * count applications of the corresponding predicate if
+count is positive, or 0 otherwise." This is unnecessarily pessimistic.
+Regardless of the value of count, there is no reason to examine any
+element in the range more than once.
+
      
+
+
+
      Proposed resolution:
      
+
      
+Change the complexity to "At most (last - first) applications of the corresponding predicate".
+
      
+
+
      
+
      template<class ForwardIterator, class Size, class T> 
+  ForwardIterator 
+    search_n(ForwardIterator first , ForwardIterator last , Size count , 
+             const T& value ); 
+
+template<class ForwardIterator, class Size, class T, 
+         class BinaryPredicate> 
+  ForwardIterator 
+    search_n(ForwardIterator first , ForwardIterator last , Size count , 
+             const T& value , BinaryPredicate pred );
+
      
+
      
+
      
+Complexity: At most (last - first ) * count applications of the corresponding predicate
+if count is positive, or 0 otherwise.
+
      
+
      
+
      
+
+
+
+
+
+
+
      
+
      715. minmax_element complexity is too lax
      
+
      Section: 25.5.7 [alg.min.max] Status: CD1
+ Submitter: Matt Austern Opened: 2007-08-30  Last modified: 2008-09-26
      
+
      View other active issues in [alg.min.max].
      
+
      View all other issues in [alg.min.max].
      
+
      View all issues with CD1 status.
      
+
      Discussion:
      
+
      
+The complexity for minmax_element (25.5.7 [alg.min.max] par 16) says "At most max(2 *
 (last - first ) - 2, 0) applications of the corresponding comparisons",
 i.e. the worst case complexity is no better than calling min_element and
 max_element separately. This is gratuitously inefficient. There is a
@@ -27986,7 +29516,7 @@ well known technique that does better: see section 9.1 of CLRS
 
 
      Proposed resolution:
      
 
      
-Change 25.3.7 [alg.min.max] to:
+Change 25.5.7 [alg.min.max] to:
 
      
 
 
      
@@ -28020,15 +29550,98 @@ corresponding comparisons predicate, where N is dis
 
 
 
+
      
+
      720. Omissions in constexpr usages
      
+
      Section: 23.3.1 [array], 20.3.6 [template.bitset] Status: CD1
+ Submitter: Daniel Krügler Opened: 2007-08-25  Last modified: 2008-09-26
      
+
      View other active issues in [array].
      
+
      View all other issues in [array].
      
+
      View all issues with CD1 status.
      
+
      Discussion:
      
+
        
+
      1. 
+The member function bool array<T,N>::empty() const should be a
+constexpr because this is easily to proof and to implement following it's operational
+semantics defined by Table 87 (Container requirements) which says: a.size() == 0.
+
        2. 
+
      2. 
+The member function bool bitset<N>::test() const must be a
+constexpr (otherwise it would violate the specification of constexpr
+bitset<N>::operator[](size_t) const, because it's return clause delegates to test()).
+
        3. 
+
      3. 
+I wonder how the constructor bitset<N>::bitset(unsigned long) can
+be declared as a constexpr. Current implementations usually have no such bitset
+c'tor which would fulfill the requirements of a constexpr c'tor because they have a
+non-empty c'tor body that typically contains for-loops or memcpy to compute the
+initialisation. What have I overlooked here?
+
        4. 
+
      
+
+
      [
+Sophia Antipolis:
+]
      
+
+
+
      
+
      
+We handle this as two parts
+
      
+
        
+
      1. 
+The proposed resolution is correct; move to ready.
+
        2. 
+
      2. 
+The issue points out a real problem, but the issue is larger than just
+this solution. We believe a paper is needed, applying the full new
+features of C++ (including extensible literals) to update std::bitset.
+We note that we do not consider this new work, and that is should be
+handled by the Library Working Group.
+
        3. 
+
      
+
      
+In order to have a consistent working paper, Alisdair and Daniel produced a new wording for the resolution.
+
      
+
      
+
+
+
+
      Proposed resolution:
      
+
        
+
      1. 
+
        In the class template definition of 23.3.1 [array]/p. 3 change
        
+
        constexpr bool empty() const;
+
        
+
        2. 
+
+
      2. 
+
        In the class template definition of 20.3.6 [template.bitset]/p. 1 change
        
+
        constexpr bool test(size_t pos ) const;
+
        
+
+
        
+and in 20.3.6.2 [bitset.members] change
+
        
+
+
        constexpr bool test(size_t pos ) const;
+
        
+
+
        3. 
+
      
+
+
+
+
+
 
      
 
      722. Missing [c.math] functions nanf and nanl
      
-
      Section: 26.7 [c.math] Status: WP
- Submitter: Daniel Krügler Date: 2007-08-27
      
+
      Section: 26.8 [c.math] Status: CD1
+ Submitter: Daniel Krügler Opened: 2007-08-27  Last modified: 2008-09-26
      
 
      View all other issues in [c.math].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
-In the listing of 26.7 [c.math], table 108: Header <cmath> synopsis I miss
+In the listing of 26.8 [c.math], table 108: Header <cmath> synopsis I miss
 the following C99 functions (from 7.12.11.2):
 
      
 
@@ -28044,7 +29657,7 @@ listed anywhere else)
 
 
      Proposed resolution:
      
 
      
-In 26.7 [c.math], table 108, section "Functions", add nanf and nanl
+In 26.8 [c.math], table 108, section "Functions", add nanf and nanl
 just after the existing entry nan.
 
      
 
@@ -28052,11 +29665,252 @@ just after the existing entry nan.
 
 
 
+
      
+
      728. Problem in [rand.eng.mers]/6
      
+
      Section: 26.5.3.2 [rand.eng.mers] Status: CD1
+ Submitter: Stephan Tolksdorf Opened: 2007-09-21  Last modified: 2008-09-26
      
+
      View all other issues in [rand.eng.mers].
      
+
      View all issues with CD1 status.
      
+
      Discussion:
      
+
      
+The mersenne_twister_engine is required to use a seeding method that is given 
+as an algorithm parameterized over the number of bits W. I doubt whether the given generalization 
+of an algorithm that was originally developed only for unsigned 32-bit integers is appropriate 
+for other bit widths. For instance, W could be theoretically 16 and UIntType a 16-bit integer, in 
+which case the given multiplier would not fit into the UIntType. Moreover, T. Nishimura and M. 
+Matsumoto have chosen a dif ferent multiplier for their 64 bit Mersenne Twister
+[reference].
+
      
+
+
      
+I see two possible resolutions: 
+
      
+
+
        
+
      1. Restrict the parameter W of the mersenne_twister_template to values of 32 or 64 and use the 
+multiplier from [the above reference] for the 64-bit case (my preference)
        2. 
+
      2. Interpret the state array for any W as a 32-bit array of appropriate length (and a specified byte 
+order) and always employ the 32-bit algorithm for seeding
+
        3. 
+
      
+
+
      
+See N2424
+for further discussion.
+
      
+
+
      [
+Bellevue:
+]
      
+
+
+
      
+
      
+Stephan Tolksdorf has additional comments on N2424. He comments: "there
+is a typo in the required behaviour for mt19937_64: It should be the
+10000th (not 100000th) invocation whose value is given, and the value
+should be 9981545732273789042 (not 14002232017267485025)." These values
+need checking.
+
      
+
      
+Take the proposed recommendation in N2424 and move to REVIEW.
+
      
+
      
+
+
+
+
+
      Proposed resolution:
      
+
+
      
+See N2424
+for the proposed resolution.
+
      
+
+
      [
+Stephan Tolksdorf adds pre-Bellevue:
+]
      
+
+
+
      
+I support the proposed resolution in
+N2424,
+but there is a typo in the
+required behaviour for mt19937_64: It should be the 10000th (not
+100000th) invocation whose value is given, and the value should be
+9981545732273789042 (not 14002232017267485025). The change to para. 8
+proposed by Charles Karney should also be included in the proposed
+wording.
+
      
+
+
      [
+Sophia Antipolis:
+]
      
+
+
+
      
+Note the main part of the issue is resolved by
+N2424.
+
      
+
+
+
+
+
+
+
      
+
      734. Unnecessary restriction in [rand.dist.norm.chisq]
      
+
      Section: 26.5.8.4.3 [rand.dist.norm.chisq] Status: CD1
+ Submitter: Stephan Tolksdorf Opened: 2007-09-21  Last modified: 2008-09-26
      
+
      View all issues with CD1 status.
      
+
      Discussion:
      
+
      
+chi_squared_distribution, fisher_f_distribution and student_t_distribution
+have parameters for the "degrees of freedom" n and m that are specified as integers. For the 
+following two reasons this is an unnecessary restriction: First, in many applications such as 
+Bayesian inference or Monte Carlo simulations it is more convenient to treat the respective param- 
+eters as continuous variables. Second, the standard non-naive algorithms (i.e. 
+O(1) algorithms) 
+for simulating from these distributions work with floating-point parameters anyway (all three 
+distributions could be easily implemented using the Gamma distribution, for instance).
+
      
+
+
      
+Similar arguments could in principle be made for the parameters t and k of the discrete 
+binomial_distribution and negative_binomial_distribution, though in both cases continuous
+parameters are less frequently used in practice and in case of the binomial_distribution
+the implementation would be significantly complicated by a non-discrete parameter (in most 
+implementations one would need an approximation of the log-gamma function instead of just the 
+log-factorial function).
+
      
+
+
      
+Possible resolution: For these reasons, I propose to change the type of the respective parameters 
+to double.
+
      
+
+
      [
+Bellevue:
+]
      
+
+
+
      
+In N2424. Not wildly enthusiastic, not really felt necessary. Less
+frequently used in practice. Not terribly bad either. Move to OPEN.
+
      
+
+
      [
+Sophia Antipolis:
+]
      
+
+
+
      
+
      
+Marc Paterno: The generalizations were explicitly left out when designing the facility. It's harder to test.
+
      
+
      
+Marc Paterno: Ask implementers whether floating-point is a significant burden.
+
      
+
      
+Alisdair: It's neater to do it now, do ask Bill Plauger.
+
      
+
      
+Disposition: move to review with the option for "NAD" if it's not straightforward to implement; unanimous consent.
+
      
+
      
+
+
+
+
      Proposed resolution:
      
+
      
+See N2424
+for the proposed resolution.
+
      
+
+
      [
+Stephan Tolksdorf adds pre-Bellevue:
+]
      
+
+
+
      
+
      
+In 26.5.8.4.3 [rand.dist.norm.chisq]:
+
      
+
+
      
+
      
+Delete ", where n is a positive integer" in the first paragraph.
+
      
+
+
      
+Replace both occurrences of "explicit chi_squared_distribution(int n = 1);"
+with "explicit chi_squared_distribution(RealType n = 1);".
+
      
+
+
      
+Replace both occurrences of "int n() const;" with "RealType n() const;".
+
      
+
+
      
+
+
      
+In 26.5.8.4.5 [rand.dist.norm.f]:
+
      
+
      
+
      
+Delete ", where m and n are positive integers" in the first paragraph.
+
      
+
+
      
+Replace both occurrences of
+
      
+
      explicit fisher_f_distribution(int m = 1, int n = 1);
+
      
+
      
+with
+
      
+
      explicit fisher_f_distribution(RealType m = 1, RealType n = 1);
+
      
+
+
      
+Replace both occurrences of "int m() const;" with "RealType m() const;".
+
      
+
+
      
+Replace both occurrences of "int n() const;" with "RealType n() const;".
+
      
+
      
+
+
      
+In 26.5.8.4.6 [rand.dist.norm.t]:
+
      
+
+
      
+
      
+Delete ", where n is a positive integer" in the first paragraph.
+
      
+
+
      
+Replace both occurrences of "explicit student_t_distribution(int n = 1);"
+with "explicit student_t_distribution(RealType n = 1);".
+
      
+
+
      
+Replace both occurrences of "int n() const;" with "RealType n() const;".
+
      
+
      
+
+
      
+
+
+
+
+
 
      
 
      740. Please remove *_ptr<T[N]>
      
-
      Section: 20.7.11.4 [unique.ptr.compiletime] Status: WP
- Submitter: Herb Sutter Date: 2007-10-04
      
-
      View all issues with WP status.
      
+
      Section: X [unique.ptr.compiletime] Status: CD1
+ Submitter: Herb Sutter Opened: 2007-10-04  Last modified: 2008-09-26
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 Please don't provide *_ptr<T[N]>. It doesn't enable any useful
@@ -28120,7 +29974,7 @@ straw poll unanimous move to Ready.
 
 
      Proposed resolution:
      
 
      
-Change the synopsis under 20.7.11 [unique.ptr] p2:
+Change the synopsis under 20.8.12 [unique.ptr] p2:
 
      
 
 
      ...
@@ -28135,13 +29989,13 @@ template<class T, class D> class unique_ptr<T[], D>;
 
      
 
 
      
-Remove the entire section 20.7.11.1.3 [unique.ptr.dltr.dflt2] default_delete<T[N]>.
+Remove the entire section 20.8.12.1.3 [unique.ptr.dltr.dflt2] default_delete<T[N]>.
 
      
 
 
      
-Remove the entire section 20.7.11.4 [unique.ptr.compiletime] unique_ptr for array objects with a compile time length
-and its subsections: 20.7.11.4.1 [unique.ptr.compiletime.dtor], 20.7.11.4.2 [unique.ptr.compiletime.observers],
-20.7.11.4.3 [unique.ptr.compiletime.modifiers].
+Remove the entire section X [unique.ptr.compiletime] unique_ptr for array objects with a compile time length
+and its subsections:  [unique.ptr.compiletime.dtor],  [unique.ptr.compiletime.observers],
+ [unique.ptr.compiletime.modifiers].
 
      
 
 
@@ -28151,9 +30005,9 @@ and its subsections: 20.7.11.4.1 [unique.ptr.compiletime.dtor], 20.7.11.4.2 [uni
 
 
      
 
      743. rvalue swap for shared_ptr
      
-
      Section: 20.7.12.2.9 [util.smartptr.shared.spec] Status: WP
- Submitter: Howard Hinnant Date: 2007-10-10
      
-
      View all issues with WP status.
      
+
      Section: 20.8.13.2.9 [util.smartptr.shared.spec] Status: CD1
+ Submitter: Howard Hinnant Opened: 2007-10-10  Last modified: 2008-09-26
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 When the LWG looked at 674 in Kona the following note was made:
@@ -28193,7 +30047,7 @@ Adopt issue as written.
 
 
      Proposed resolution:
      
 
      
-Change the synopsis in 20.7.12.2 [util.smartptr.shared]:
+Change the synopsis in 20.8.13.2 [util.smartptr.shared]:
 
      
 
 
      void swap(shared_ptr&& r);
@@ -28204,14 +30058,14 @@ template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>
 
      
 
 
      
-Change 20.7.12.2.4 [util.smartptr.shared.mod]:
+Change 20.8.13.2.4 [util.smartptr.shared.mod]:
 
      
 
 
      void swap(shared_ptr&& r);
 
      
 
 
      
-Change 20.7.12.2.9 [util.smartptr.shared.spec]:
+Change 20.8.13.2.9 [util.smartptr.shared.spec]:
 
      
 
 
      template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b);
@@ -28225,11 +30079,11 @@ template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>
 
 
      
 
      744. What is the lifetime of an exception pointed to by an exception_ptr?
      
-
      Section: 18.7.5 [propagation] Status: WP
- Submitter: Alisdair Meredith Date: 2007-10-10
      
+
      Section: 18.8.5 [propagation] Status: CD1
+ Submitter: Alisdair Meredith Opened: 2007-10-10  Last modified: 2008-09-26
      
 
      View other active issues in [propagation].
      
 
      View all other issues in [propagation].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 Without some lifetime guarantee, it is hard to know how this type can be
@@ -28271,7 +30125,7 @@ Move to Open.
 
 
      Proposed resolution:
      
 
      
-Change 18.7.5 [propagation]/7:
+Change 18.8.5 [propagation]/7:
 
      
 
 
      
@@ -28294,11 +30148,11 @@ each time it is called. --end note]
 
 
      
 
      746. current_exception may fail with bad_alloc
      
-
      Section: 18.7.5 [propagation] Status: WP
- Submitter: Alisdair Meredith Date: 2007-10-10
      
+
      Section: 18.8.5 [propagation] Status: CD1
+ Submitter: Alisdair Meredith Opened: 2007-10-10  Last modified: 2008-09-26
      
 
      View other active issues in [propagation].
      
 
      View all other issues in [propagation].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 I understand that the attempt to copy an exception may run out of memory,
@@ -28350,7 +30204,7 @@ Accept the broad view and move to ready
 
 
      Proposed resolution:
      
 
      
-Add the following exemption clause to 17.4.4.9 [res.on.exception.handling]:
+Add the following exemption clause to 17.6.4.10 [res.on.exception.handling]:
 
      
 
 
      
@@ -28365,10 +30219,11 @@ exception handler for the base type.
 
 
      
 
      749. Currently has_nothrow_copy_constructor<T>::value is true if T has 'a' nothrow copy constructor.
      
-
      Section: 20.5.4.3 [meta.unary.prop] Status: WP
- Submitter: Alisdair Meredith Date: 2007-10-10
      
+
      Section: 20.6.4.3 [meta.unary.prop] Status: CD1
+ Submitter: Alisdair Meredith Opened: 2007-10-10  Last modified: 2008-09-26
      
+
      View other active issues in [meta.unary.prop].
      
 
      View all other issues in [meta.unary.prop].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 Unfortunately a class can have multiple copy constructors, and I believe to
@@ -28388,7 +30243,7 @@ For instance:
 
 
      Proposed resolution:
      
 
      
-Change 20.5.4.3 [meta.unary.prop]:
+Change 20.6.4.3 [meta.unary.prop]:
 
      
 
 
      
@@ -28434,13 +30289,190 @@ throw any exceptions or T is an array of such a class type.
 
 
 
      
-
      755. std::vector and std:string lack explicit shrink-to-fit operations
      
-
      Section: 23.2.6.2 [vector.capacity], 21.3.4 [string.capacity] Status: WP
- Submitter: Beman Dawes Date: 2007-10-31
      
-
      View all other issues in [vector.capacity].
      
+
      752. Allocator complexity requirement
      
+
      Section: X [allocator.requirements] Status: WP
+ Submitter: Hans Boehm Opened: 2007-10-11  Last modified: 2009-03-09
      
+
      View other active issues in [allocator.requirements].
      
+
      View all other issues in [allocator.requirements].
      
 
      View all issues with WP status.
      
 
      Discussion:
      
 
      
+Did LWG recently discuss X [allocator.requirements]-2, which states that "All the operations
+on the allocators are expected to be amortized constant time."?
+
      
+
      
+As I think I pointed out earlier, this is currently fiction for
+allocate() if it has to obtain memory from the OS, and it's unclear to
+me how to interpret this for construct() and destroy() if they deal with
+large objects.  Would it be controversial to officially let these take
+time linear in the size of the object, as they already do in real life?
+
      
+
      
+Allocate() more blatantly takes time proportional to the size of the
+object if you mix in GC.  But it's not really a new problem, and I think
+we'd be confusing things by leaving the bogus requirements there.  The
+current requirement on allocate() is generally not important anyway,
+since it takes O(size) to construct objects in the resulting space.
+There are real performance issues here, but they're all concerned with
+the constants, not the asymptotic complexity.
+
      
+
+
+
      Proposed resolution:
      
+
      
+Change X [allocator.requirements]/2:
+
      
+
+
      
+
      
+-2- Table 39 describes the requirements on types manipulated through
+allocators. All the operations on the allocators are expected to be
+amortized constant time. Table 40 describes the
+requirements on allocator types.
+
      
+
      
+
+
+
+
+
+
      
+
      753. Move constructor in draft
      
+
      Section: X [utility.arg.requirements] Status: WP
+ Submitter: Yechezkel Mett Opened: 2007-10-14  Last modified: 2009-03-09
      
+
      View all other issues in [utility.arg.requirements].
      
+
      View all issues with WP status.
      
+
      Discussion:
      
+
      
+The draft standard n2369 uses the term move constructor in a few
+places, but doesn't seem to define it.
+
      
+
+
      
+MoveConstructible requirements are defined in Table 33 in X [utility.arg.requirements] as
+follows:
+
      
+
+
      
+
+
+
+
+
+
+
+
+
+
+
+
      MoveConstructible requirements
      expression post-condition
      T t = rv t is equivalent to the value of rv before the construction
      [Note: There is no requirement on the value of rv after the 
+construction. -- end note]
      
+
      
+
+
      
+(where rv is a non-const rvalue of type T).
+
      
+
+
      
+So I assume the move constructor is the constructor that would be used
+in filling the above requirement.
+
      
+
+
      
+For vector::reserve, vector::resize and the vector modifiers given in
+23.3.6.4 [vector.modifiers] we have
+
      
+
+
      
+Requires: If value_type has a move constructor, that constructor shall
+not throw any exceptions.
+
      
+
+
      
+Firstly "If value_type has a move constructor" is superfluous; every
+type which can be put into a vector has a move constructor (a copy
+constructor is also a move constructor). Secondly it means that for
+any value_type which has a throwing copy constructor and no other move
+constructor these functions cannot be used -- which I think will come
+as a shock to people who have been using such types in vector until
+now!
+
      
+
+
      
+I can see two ways to correct this. The simpler, which is presumably
+what was intended, is to say "If value_type has a move constructor and
+no copy constructor, the move constructor shall not throw any
+exceptions" or "If value_type has a move constructor which changes the
+value of its parameter,".
+
      
+
+
      
+The other alternative is add to MoveConstructible the requirement that
+the expression does not throw. This would mean that not every type
+that satisfies the CopyConstructible requirements also satisfies the
+MoveConstructible requirements. It would mean changing requirements in
+various places in the draft to allow either MoveConstructible or
+CopyConstructible, but I think the result would be clearer and
+possibly more concise too.
+
      
+
+
+
      Proposed resolution:
      
+
      
+Add new defintions to 17.3 [definitions]:
+
      
+
+
      
+
      
+move constructor
+
      
+
      
+a constructor which accepts only rvalue arguments of that type, and modifies the rvalue as a
+side effect during the construction.
+
      
+
      
+move assignment operator
+
      
+
      
+an assignment operator which accepts only rvalue arguments of that type, and modifies the rvalue as a
+side effect during the assignment.
+
      
+
      
+move assignment
+
      
+
      
+use of the move assignment operator.
+
      
+
      
+
+
      [
+Howard adds post-Bellevue:
+]
      
+
+
+
      
+
      
+Unfortunately I believe the wording recommended by the LWG in Bellevue is incorrect.  reserve et. al. will use a move constructor
+if one is available, else it will use a copy constructor.  A type may have both.  If the move constructor is
+used, it must not throw.  If the copy constructor is used, it can throw.  The sentence in the proposed wording
+is correct without the recommended insertion.  The Bellevue LWG recommended moving this issue to Ready.  I am
+unfortunately pulling it back to Open.  But I'm drafting wording to atone for this egregious action. :-)
+
      
+
      
+
+
+
+
+
+
+
      
+
      755. std::vector and std:string lack explicit shrink-to-fit operations
      
+
      Section: 23.3.6.2 [vector.capacity], 21.4.4 [string.capacity] Status: CD1
+ Submitter: Beman Dawes Opened: 2007-10-31  Last modified: 2008-09-26
      
+
      View all other issues in [vector.capacity].
      
+
      View all issues with CD1 status.
      
+
      Discussion:
      
+
      
 A std::vector can be shrunk-to-fit via the swap idiom:
 
      
 
@@ -28489,9 +30521,9 @@ takes no arguments to keep the solution simple and focused.
 
 
      Proposed resolution:
      
 
      
-To Class template basic_string 21.3 [basic.string] synopsis,
-Class template vector 23.2.6 [vector] synopsis, and Class
-vector<bool> 23.2.7 [vector.bool] synopsis, add:
+To Class template basic_string 21.4 [basic.string] synopsis,
+Class template vector 23.3.6 [vector] synopsis, and Class
+vector<bool> 23.3.7 [vector.bool] synopsis, add:
 
      
 
 
          
@@ -28499,8 +30531,8 @@ void shrink_to_fit();
 
      
 
 
      
-To basic_string capacity 21.3.4 [string.capacity] and vector
-capacity 23.2.6.2 [vector.capacity], add:
+To basic_string capacity 21.4.4 [string.capacity] and vector
+capacity 23.3.6.2 [vector.capacity], add:
 
      
 
 
      
@@ -28515,7 +30547,7 @@ allow latitude for implementation-specific optimizations.
 
      
 
 
      [
-850 has been added to deal with this issue with respect to deque.
+850 has been added to deal with this issue with respect to deque.
 ]
      
 
 
@@ -28524,15 +30556,257 @@ allow latitude for implementation-specific optimizations.
 
 
 
      
-
      759. A reference is not an object
      
-
      Section: 23.1 [container.requirements] Status: WP
- Submitter: Jens Maurer Date: 2007-11-06
      
-
      View other active issues in [container.requirements].
      
-
      View all other issues in [container.requirements].
      
+
      758. shared_ptr and nullptr
      
+
      Section: 20.8.13.2 [util.smartptr.shared] Status: WP
+ Submitter: Joe Gottman Opened: 2007-10-31  Last modified: 2009-03-09
      
+
      View other active issues in [util.smartptr.shared].
      
+
      View all other issues in [util.smartptr.shared].
      
 
      View all issues with WP status.
      
 
      Discussion:
      
 
      
-23.1 [container.requirements] says:
+Consider the following program:
+
      
+
+
      int main() {
+   shared_ptr<int> p(nullptr); 
+   return 0;
+}
+
      
+
+
      
+This program will fail to compile because shared_ptr uses the following 
+template constructor to construct itself from pointers:
+
      
+
+
      template <class Y> shared_ptr(Y *);
+
      
+
+
      
+According
+to N2431,
+the conversion from nullptr_t to Y * is not
+deducible, so the above constructor will not be found.  There are similar problems with the
+constructors that take a pointer and a deleter or a
+pointer, a deleter and an allocator, as well as the
+corresponding forms of reset(). Note that N2435
+will solve this problem for constructing from just nullptr, but not for constructors that use
+deleters or allocators or for reset().
+
      
+
+
      
+In the case of the functions that take deleters, there is the additional
+question of what argument should be passed to the deleter when it is
+eventually called.  There are two reasonable possibilities: nullptr or
+static_cast<T *>(0), where T is the template argument of the
+shared_ptr.  It is not immediately clear which of these is better.  If
+D::operator() is a template function similar to shared_ptr's
+constructor, then d(static_cast<T*>(0)) will compile and d(nullptr)
+will not.  On the other hand, if D::operator()() takes a parameter that
+is a pointer to some type other that T (for instance U* where U derives
+from T) then d(nullptr) will compile and d(static_cast<T *>(0)) may not.
+
      
+
+
      [
+Bellevue:
+]
      
+
+
+
      
+
      
+The general idea is right, we need to be able to pass a nullptr to a
+shared_ptr, but there are a few borderline editorial issues here. (For
+example, the single-argument nullptr_t constructor in the class synopsis
+isn't marked explicit, but it is marked explicit in the proposed wording
+for 20.6.6.2.1. There is a missing empty parenthesis in the form that
+takes a nullptr_t, a deleter, and an allocator.)
+
      
+
      
+More seriously: this issue says that a shared_ptr constructed from a
+nullptr is empty. Since "empty" is undefined, it's hard to know whether
+that's right. This issue is pending on handling that term better.
+
      
+
      
+Peter suggests definition of empty should be "does not own anything"
+
      
+
      
+Is there an editorial issue that post-conditions should refer to get() =
+nullptr, rather than get() = 0?
+
      
+
      
+No strong feeling towards accept or NAD, but prefer to make a decision than leave it open.
+
      
+
      
+Seems there are no technical merits between NAD and Ready, comes down to
+"Do we intentially want to allow/disallow null pointers with these
+functions". Staw Poll - support null pointers 5 - No null pointers 0
+
      
+
      
+Move to Ready, modulo editorial comments
+
      
+
      
+
+
      [
+post Bellevue Peter adds:
+]
      
+
+
+
      
+
      
+The following wording changes are less intrusive:
+
      
+
+
      
+In 20.8.13.2.1 [util.smartptr.shared.const], add:
+
      
+
+
      shared_ptr(nullptr_t);
+
      
+
+
      
+after:
+
      
+
+
      shared_ptr();
+
      
+
+
      
+(Absence of explicit intentional.)
+
      
+
+
      
+px.reset( nullptr ) seems a somewhat contrived way to write px.reset(), so
+I'm not convinced of its utility.
+
      
+
      
+It's similarly not clear to me whether the deleter constructors need to be
+extended to take nullptr, but if they need to:
+
      
+
      
+Add
+
      
+
+
      template<class D> shared_ptr(nullptr_t p, D d);
+template<class D, class A> shared_ptr(nullptr_t p, D d, A a);
+
      
+
+
      
+after
+
      
+
+
      template<class Y, class D> shared_ptr(Y* p, D d);
+template<class Y, class D, class A> shared_ptr(Y* p, D d, A a);
+
      
+
+
      
+Note that this changes the semantics of the new constructors such that they
+consistently call d(p) instead of d((T*)0) when p is nullptr.
+
      
+
      
+The ability to be able to pass 0/NULL to a function that takes a shared_ptr
+has repeatedly been requested by users, but the other additions that the
+proposed resolution makes are not supported by real world demand or
+motivating examples.
+
      
+
      
+It might be useful to split the obvious and non-controversial nullptr_t
+constructor into a separate issue. Waiting for "empty" to be clarified is
+unnecessary; this is effectively an alias for the default constructor.
+
      
+
      
+
+
      [
+Sophia Antipolis:
+]
      
+
+
+
      
+
      
+We want to remove the reset functions from the proposed resolution.
+
      
+
      
+The remaining proposed resolution text (addressing the constructors) are wanted.
+
      
+
      
+Disposition: move to review. The review should check the wording in the then-current working draft.
+
      
+
      
+
+
+
+
      Proposed resolution:
      
+
      
+In 20.8.13.2 [util.smartptr.shared] p4, add to the definition/synopsis
+of shared_ptr:
+
      
+
+
      template<class D> shared_ptr(nullptr_t p, D d);
+template<class D, class A> shared_ptr(nullptr_t p, D d, A a);
+
      
+
+
      
+after
+
      
+
+
      template<class Y, class D> shared_ptr(Y* p, D d);
+template<class Y, class D, class A> shared_ptr(Y* p, D d, A a);
+
      
+
+
      
+In 20.8.13.2.1 [util.smartptr.shared.const] add:
+
      
+
+
      template<class D> shared_ptr(nullptr_t p, D d);
+template<class D, class A> shared_ptr(nullptr_t p, D d, A a);
+
      
+
+
      
+after
+
      
+
+
      template<class Y, class D> shared_ptr(Y* p, D d);
+template<class Y, class D, class A> shared_ptr(Y* p, D d, A a);
+
      
+
+
      
+(reusing the following paragraphs 20.8.13.2.1 [util.smartptr.shared.const]/9-13 that speak of p.)
+
      
+
+
      
+In 20.8.13.2.1 [util.smartptr.shared.const]/10,  change
+
      
+
+
      
+Effects: Constructs a shared_ptr object that owns the
+pointer object p and the deleter d. The second 
+constructor shall use a copy of a to allocate memory for internal use.
+
      
+
+
+
      Rationale:
      
+
      [
+San Francisco:
+]
      
+
+
+
      
+"pointer" is changed to "object" to handle the fact that nullptr_t isn't a pointer.
+
      
+
+
+
+
+
+
+
      
+
      759. A reference is not an object
      
+
      Section: 23.2 [container.requirements] Status: CD1
+ Submitter: Jens Maurer Opened: 2007-11-06  Last modified: 2008-09-26
      
+
      View other active issues in [container.requirements].
      
+
      View all other issues in [container.requirements].
      
+
      View all issues with CD1 status.
      
+
      Discussion:
      
+
      
+23.2 [container.requirements] says:
 
      
 
 
      
@@ -28557,7 +30831,7 @@ an element of that container; no diagnostic required.
 
 
      Proposed resolution:
      
 
      
-Change 23.1 [container.requirements]:
+Change 23.2 [container.requirements]:
 
      
 
 
      
@@ -28576,9 +30850,9 @@ diagnostic required.
 
 
      
 
      761. unordered_map needs an at() member function
      
-
      Section: 23.4.1.2 [unord.map.elem] Status: WP
- Submitter: Joe Gottman Date: 2007-11-15
      
-
      View all issues with WP status.
      
+
      Section: 23.5.1.2 [unord.map.elem] Status: CD1
+ Submitter: Joe Gottman Opened: 2007-11-15  Last modified: 2008-09-26
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 The new member function at() was recently added to std::map().  It acts 
@@ -28593,7 +30867,7 @@ in std::unordered_map.
 
 
      Proposed resolution:
      
 
      
-Add the following functions to the definition of unordered_map under "lookup" (23.4.1 [unord.map]):
+Add the following functions to the definition of unordered_map under "lookup" (23.5.1 [unord.map]):
 
      
 
 
      mapped_type& at(const key_type& k);
@@ -28601,7 +30875,7 @@ const mapped_type &at(const key_type &k) const;
 
      
 
 
      
-Add the following definitions to 23.4.1.2 [unord.map.elem]:
+Add the following definitions to 23.5.1.2 [unord.map.elem]:
 
      
 
 
      
@@ -28631,15 +30905,320 @@ Bellevue:  Editorial note: the "(unique)" differs from map.
 
 
 
      
-
      766. Inconsistent exception guarantees between ordered and unordered associative containers
      
-
      Section: 23.1 [container.requirements], 23.1.5.1 [unord.req.except] Status: WP
- Submitter: Ion Gaztańaga Date: 2007-12-22
      
-
      View other active issues in [container.requirements].
      
-
      View all other issues in [container.requirements].
      
-
      View all issues with WP status.
      
+
      762. std::unique_ptr requires complete type?
      
+
      Section: 20.8.12 [unique.ptr] Status: CD1
+ Submitter: Daniel Krügler Opened: 2007-11-30  Last modified: 2008-09-26
      
+
      View all other issues in [unique.ptr].
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
-23.1 [container.requirements]p10 states:
+In contrast to the proposed std::shared_ptr, std::unique_ptr
+does currently not support incomplete types, because it
+gives no explicit grant - thus instantiating unique_ptr with
+an incomplete pointee type T automatically belongs to
+undefined behaviour according to 17.6.3.8 [res.on.functions]/2, last
+bullet. This is an unnecessary restriction and prevents
+many well-established patterns - like the bridge pattern -
+for std::unique_ptr.
+
      
+
+
      [
+Bellevue:
+]
      
+
+
+
      
+Move to open. The LWG is comfortable with the intent of allowing
+incomplete types and making unique_ptr more like shared_ptr, but we are
+not comfortable with the wording. The specification for unique_ptr
+should be more like that of shared_ptr. We need to know, for individual
+member functions, which ones require their types to be complete. The
+shared_ptr specification is careful to say that for each function, and
+we need the same level of care here. We also aren't comfortable with the
+"part of the operational semantic" language; it's not used elsewhere in
+the standard, and it's not clear what it means. We need a volunteer to
+produce new wording.
+
      
+
+
+
      Proposed resolution:
      
+
      
+The proposed changes in the following revision refers to the current state of
+N2521 including the assumption that X [unique.ptr.compiletime] will be removed
+according to the current state of 740.
+
      
+
      
+The specialization unique_ptr<T[]> has some more restrictive constraints on
+type-completeness on T than unique_ptr<T>. The following proposed wordings
+try to cope with that. If the committee sees less usefulness on relaxed
+constraints on unique_ptr<T[]>, the alternative would be to stop this relaxation
+e.g. by adding one further bullet to 20.8.12.3 [unique.ptr.runtime]/1:
+"T shall be a complete type, if used as template argument of
+unique_ptr<T[], D>
+
      
+
      
+This issue has some overlap with 673, but it seems not to cause any
+problems with this one,
+because 673 adds only optional requirements on D that do not conflict
+with the here discussed
+ones, provided that D::pointer's operations (including default
+construction, copy construction/assignment,
+and pointer conversion) are specified not to throw, otherwise this
+would have impact on the
+current specification of unique_ptr.
+
      
+
+
        
+
      1. 
+
        
+In 20.8.12 [unique.ptr]/2 add as the last sentence to the existing para:
+
        
+
+
        
+The unique_ptr provides a semantics of strict ownership. A
+unique_ptr owns the object it holds a pointer to. A
+unique_ptr is not CopyConstructible, nor
+CopyAssignable, however it is MoveConstructible and
+MoveAssignable. The template parameter T of
+unique_ptr may be an incomplete type. [ Note: The
+uses of unique_ptr include providing exception safety for
+dynamically allcoated memory, passing ownership of dynamically allocated
+memory to a function, and returning dynamically allocated memory from a
+function. -- end note ]
+
        
+
        2. 
+
+
      2. 
+
        
+20.8.12.2.1 [unique.ptr.single.ctor]/1: No changes necessary.
+
        
+
+
        
+
        [
+N.B.: We only need the requirement that D is DefaultConstructible.
+The current wording says just this.
+]
        
+
+
        
+
        3. 
+
+
      3. 
+
        
+In 20.8.12.2.1 [unique.ptr.single.ctor]/5 change the requires clause to say:
+
        
+
+
        
+
        
+Requires: The expression D()(p) shall be well formed. The default constructor
+of D shall not throw an exception.
+D must not be a reference type.
+
+D shall be default constructible, and that construction
+shall not throw an exception.
+
+
        
+
        [
+N.B.: There is no need that the expression D()(p) is well-formed at
+this point. I assume that the current wording is based on the
+corresponding shared_ptr wording. In case of shared_ptr this
+requirement is necessary, because the corresponding c'tor *can* fail
+and must invoke delete p/d(p) in this case. Unique_ptr is simpler in
+this regard. The *only* functions that must insist on well-formedness
+and well-definedness of the expression get_deleter()(get()) are (1)
+the destructor and (2) reset. The reasoning for the wording change to
+explicitly require DefaultConstructible of D is to guarantee that
+invocation of
+D's default c'tor is both well-formed and well-defined. Note also that
+we do *not* need the
+requirement that T must be complete, also in contrast to shared_ptr.
+Shared_ptr needs this, because it's c'tor is a template c'tor which
+potentially requires Convertible<Y*, X*>, which
+again requires Completeness of Y, if !SameType<X, Y>
+]
        
+
+
        
+
        4. 
+
+
      4. 
+
        
+Merge 20.8.12.2.1 [unique.ptr.single.ctor]/12+13 thereby removing the sentence
+of 12, but transferring the "requires" to 13:
+
        
+
+
        
+
        
+Requires: If D is not an lvalue-reference type then[..]
+
        
+
        [
+N.B.: For the same reasons as for (3), there is no need that d(p) is
+well-formed/well-defined at this point. The current wording guarantees
+all what we need, namely that the initialization of both the T*
+pointer and the D deleter are well-formed and well-defined.
+]
        
+
+
        
+
        5. 
+
+
      5. 
+20.8.12.2.1 [unique.ptr.single.ctor]/17: No changes necessary.
+
        6. 
+
      6. 
+
        20.8.12.2.1 [unique.ptr.single.ctor]/21:
        
+
+
        
+Requires: If D is not a reference type, construction of
+the deleter D from an rvalue of type E shall be well
+formed and shall not throw an exception. If D is a reference
+type, then E shall be the same type as D (diagnostic
+required). U* shall be implicitly convertible to T*.
+[Note: These requirements imply that T and U
+be complete types. -- end note]
+
        
+
+
        [
+N.B.: The current wording of 21 already implicitly guarantees that U
+is completely defined, because it requires that Convertible<U*, T*> is
+true. If the committee wishes this explicit requirement can be added,
+e.g. "U shall be a complete type."
+]
        
+
+
        7. 
+
+
      7. 
+
        
+20.8.12.2.2 [unique.ptr.single.dtor]: Just before p1 add a new paragraph:
+
        
+
        
+
        
+Requires: The expression get_deleter()(get()) shall be well-formed,
+shall have well-defined behavior, and shall not throw exceptions.
+[Note: The use of default_delete requires T to
+be a complete type. -- end note]
+
        
+
        [
+N.B.: This requirement ensures that the whole responsibility on
+type-completeness of T is delegated to this expression.
+]
        
+
+
        
+
        8. 
+
+
      8. 
+
        
+20.8.12.2.3 [unique.ptr.single.asgn]/1: No changes necessary, except the
+current editorial issue, that "must shall" has to be changed to
+"shall", but this change is not a special part of this resolution.
+
        
+
+
        [
+N.B. The current wording is sufficient, because we can delegate all
+further requirements on the requirements of the effects clause
+]
        
+
+
        9. 
+
+
      9. 
+
        
+20.8.12.2.3 [unique.ptr.single.asgn]/6:
+
        
+
+
        
+Requires: Assignment of the deleter D from an rvalue
+D shall not throw an exception. U* shall be implicitly
+convertible to T*.
+[Note: These requirements imply that T and U
+be complete types. -- end note]
+
        
+
+
        [
+N.B.: The current wording of p. 6 already implicitly guarantees that
+U is completely defined, because it requires that Convertible<U*, T*>
+is true, see (6)+(8).
+]
        
+
+
        10. 
+
+
      10. 
+
        
+20.8.12.2.3 [unique.ptr.single.asgn]/11: No changes necessary.
+
        
+
        [
+N.B.: Delegation to requirements of effects clause is sufficient.
+]
        
+
+
        11. 
+
+
      11. 
+20.8.12.2.4 [unique.ptr.single.observers]/1+4+7+9+11:
+
        12. 
+
+
        
+
        T* operator->() const;
        
+
        
+Note: Use typically requires T shall be complete. -- end note]
+
        
+
        
+
+
      12. 
+20.8.12.2.5 [unique.ptr.single.modifiers]/1: No changes necessary.
+
        13. 
+
+
      13. 
+
        
+20.8.12.2.5 [unique.ptr.single.modifiers]/4: Just before p. 4 add a new paragraph:
+
        
+
        
+Requires: The expression get_deleter()(get()) shall be well-formed,
+shall have well-defined behavior, and shall not throw exceptions.
+
        
+
        14. 
+
+
      14. 
+20.8.12.2.5 [unique.ptr.single.modifiers]/7: No changes necessary.
+
        15. 
+
+
      15. 
+
        
+20.8.12.3 [unique.ptr.runtime]: Add one additional bullet on paragraph 1:
+
        
+
+
        
+
        
+A specialization for array types is provided with a slightly altered interface.
+
        
+
+
          
+
        • 
+...
+
          • 
+
        • 
+T shall be a complete type.
+
          • 
+
        
+
        
+
        16. 
+
      
+
+
      [
+post Bellevue: Daniel provided revised wording.
+]
      
+
+
+
+
+
+
+
+
      
+
      766. Inconsistent exception guarantees between ordered and unordered associative containers
      
+
      Section: 23.2 [container.requirements], 23.2.5.1 [unord.req.except] Status: CD1
+ Submitter: Ion Gaztańaga Opened: 2007-12-22  Last modified: 2008-09-26
      
+
      View other active issues in [container.requirements].
      
+
      View all other issues in [container.requirements].
      
+
      View all issues with CD1 status.
      
+
      Discussion:
      
+
      
+23.2 [container.requirements]p10 states:
 
      
 
 
      
@@ -28657,12 +31236,12 @@ additional requirements:
 
      
 
 
      
-23.2.2.3 [deque.modifiers] and 23.2.6.4 [vector.modifiers] offer
+23.3.2.3 [deque.modifiers] and 23.3.6.4 [vector.modifiers] offer
 additional guarantees for deque/vector insert() and
-erase() members. However, 23.1 [container.requirements]p10
-does not mention 23.1.5.1 [unord.req.except] that specifies exception
+erase() members. However, 23.2 [container.requirements]p10
+does not mention 23.2.5.1 [unord.req.except] that specifies exception
 safety guarantees
-for unordered containers. In addition, 23.1.5.1 [unord.req.except]p1
+for unordered containers. In addition, 23.2.5.1 [unord.req.except]p1
 offers the following guaratee for
 erase():
 
      
@@ -28677,9 +31256,9 @@ Summary:
 
      
 
 
      
-According to 23.1 [container.requirements]p10 no
+According to 23.2 [container.requirements]p10 no
 erase() function should throw an exception unless otherwise
-specified. Although does not explicitly mention 23.1.5.1 [unord.req.except], this section offers additional guarantees
+specified. Although does not explicitly mention 23.2.5.1 [unord.req.except], this section offers additional guarantees
 for unordered containers, allowing erase() to throw if
 predicate or hash function throws.
 
      
@@ -28723,7 +31302,7 @@ exception or swallow it, leaving the object registered.
 
 
      Proposed resolution:
      
 
      
-Create a new sub-section of 23.1.4 [associative.reqmts] (perhaps [associative.req.except]) titled "Exception
+Create a new sub-section of 23.2.4 [associative.reqmts] (perhaps [associative.req.except]) titled "Exception
 safety guarantees".
 
      
 
@@ -28748,7 +31327,7 @@ assignment operator of the container's Pred object (if any).
 
      
 
 
      
-Change 23.1.5.1 [unord.req.except]p1:
+Change 23.2.5.1 [unord.req.except]p1:
 
      
 
 
      
@@ -28760,7 +31339,7 @@ unless that exception is thrown by the container's Hash or Pred object
 
      
 
 
      
-Change 23.1 [container.requirements]p10 to add references to new sections:
+Change 23.2 [container.requirements]p10 to add references to new sections:
 
      
 
 
      
@@ -28771,7 +31350,7 @@ the following additional requirements:
 
      
 
 
      
-Change 23.1 [container.requirements]p10 referring to swap:
+Change 23.2 [container.requirements]p10 referring to swap:
 
      
 
 
      
@@ -28791,14 +31370,15 @@ Compare object (if any; see [associative.reqmts]).
 
 
      
 
      768. Typos in [atomics]?
      
-
      Section: 29.3.3 [atomics.types.generic] Status: WP
- Submitter: Alberto Ganesh Barbati Date: 2007-12-28
      
-
      View all issues with WP status.
      
+
      Section: 29.5.3 [atomics.types.generic] Status: CD1
+ Submitter: Alberto Ganesh Barbati Opened: 2007-12-28  Last modified: 2008-09-26
      
+
      View all other issues in [atomics.types.generic].
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 in the latest publicly available draft, paper
 N2641,
-in section 29.3.3 [atomics.types.generic], the following specialization of the template
+in section 29.5.3 [atomics.types.generic], the following specialization of the template
 atomic<> is provided for pointers:
 
      
 
@@ -28882,7 +31462,7 @@ initialization.
 
 
      Proposed resolution:
      
 
      
-Change the synopsis in 29.3.3 [atomics.types.generic]:
+Change the synopsis in 29.5.3 [atomics.types.generic]:
 
      
 
 
      template <class T> struct atomic<T*> : atomic_address { 
@@ -28915,11 +31495,101 @@ Change the synopsis in 29.3.3 [atomics.types.generic]:
 
 
 
+
      
+
      769. std::function should use nullptr_t instead of "unspecified-null-pointer-type"
      
+
      Section: 20.7.16.2 [func.wrap.func] Status: CD1
+ Submitter: Daniel Krügler Opened: 2008-01-10  Last modified: 2008-09-26
      
+
      View other active issues in [func.wrap.func].
      
+
      View all other issues in [func.wrap.func].
      
+
      View all issues with CD1 status.
      
+
      Discussion:
      
+
      
+N2461 already replaced in 20.7.16.2 [func.wrap.func] it's originally proposed
+(implicit) conversion operator to "unspecified-bool-type" by the new
+explicit bool conversion, but the inverse conversion should also
+use the new std::nullptr_t type instead of "unspecified-null-pointer-
+type".
+
      
+
+
+
      Proposed resolution:
      
+
+
      
+In 20.7 [function.objects], header <functional> synopsis replace:
+
      
+
+
      template<class R, class... ArgTypes>
+  bool operator==(const function<R(ArgTypes...)>&, unspecified-null-pointer-type nullptr_t);
+template<class R, class... ArgTypes>
+  bool operator==(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>&);
+template<class R, class... ArgTypes>
+  bool operator!=(const function<R(ArgTypes...)>&, unspecified-null-pointer-type nullptr_t);
+template<class R, class... ArgTypes>
+  bool operator!=(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>&);
+
      
+
+
      
+In the class function synopsis of 20.7.16.2 [func.wrap.func] replace
+
      
+
+
      function(unspecified-null-pointer-type nullptr_t);
+...
+function& operator=(unspecified-null-pointer-type nullptr_t);
+
      
+
+
      
+In 20.7.16.2 [func.wrap.func], "Null pointer comparisons" replace:
+
      
+
+
      template <class R, class... ArgTypes>
+  bool operator==(const function<R(ArgTypes...)>&, unspecified-null-pointer-type nullptr_t);
+template <class R, class... ArgTypes>
+  bool operator==(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>&);
+template <class R, class... ArgTypes>
+  bool operator!=(const function<R(ArgTypes...)>&, unspecified-null-pointer-type nullptr_t);
+template <class R, class... ArgTypes>
+  bool operator!=(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>&);
+
      
+
+
      
+In 20.7.16.2.1 [func.wrap.func.con], replace
+
      
+
+
      function(unspecified-null-pointer-type nullptr_t);
+...
+function& operator=(unspecified-null-pointer-type nullptr_t);
+
      
+
+
      
+In 20.7.16.2.6 [func.wrap.func.nullptr], replace
+
      
+
+
      template <class R, class... ArgTypes>
+  bool operator==(const function<R(ArgTypes...)>& f, unspecified-null-pointer-type nullptr_t);
+template <class R, class... ArgTypes>
+  bool operator==(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>& f);
+
      
+
+
      
+and replace
+
      
+
+
      template <class R, class... ArgTypes>
+  bool operator!=(const function<R(ArgTypes...)>& f, unspecified-null-pointer-type nullptr_t);
+template <class R, class... ArgTypes>
+  bool operator!=(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>& f);
+
      
+
+
+
+
+
+
 
      
 
      770. std::function should use rvalue swap
      
-
      Section: 20.6.15 [func.wrap] Status: WP
- Submitter: Daniel Krügler Date: 2008-01-10
      
-
      View all issues with WP status.
      
+
      Section: 20.7.16 [func.wrap] Status: CD1
+ Submitter: Daniel Krügler Opened: 2008-01-10  Last modified: 2008-09-26
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 It is expected that typical implementations of std::function will
@@ -28931,7 +31601,7 @@ this class to rvalue swappability.
 
 
      Proposed resolution:
      
 
      
-In 20.6 [function.objects], header <functional> synopsis, just below of
+In 20.7 [function.objects], header <functional> synopsis, just below of
 
      
 
 
      template<class R, class... ArgTypes>
@@ -28943,14 +31613,14 @@ template<class R, class... ArgTypes>
 
      
 
 
      
-In 20.6.15.2 [func.wrap.func] class function definition, change
+In 20.7.16.2 [func.wrap.func] class function definition, change
 
      
 
 
      void swap(function&&);
 
      
 
 
      
-In 20.6.15.2 [func.wrap.func], just below of
+In 20.7.16.2 [func.wrap.func], just below of
 
      
 
 
      template <class R, class... ArgTypes>
@@ -28962,14 +31632,14 @@ template <class R, class... ArgTypes>
 
      
 
 
      
-In 20.6.15.2.2 [func.wrap.func.mod] change
+In 20.7.16.2.2 [func.wrap.func.mod] change
 
      
 
 
      void swap(function&& other);
 
      
 
 
      
-In 20.6.15.2.7 [func.wrap.func.alg] add the two overloads
+In 20.7.16.2.7 [func.wrap.func.alg] add the two overloads
 
      
 
 
      template<class R, class... ArgTypes>
@@ -28983,11 +31653,158 @@ template<class R, class... ArgTypes>
 
 
 
+
      
+
      771. Impossible throws clause in [string.conversions]
      
+
      Section: 21.5 [string.conversions] Status: CD1
+ Submitter: Daniel Krügler Opened: 2008-01-13  Last modified: 2008-09-26
      
+
      View all other issues in [string.conversions].
      
+
      View all issues with CD1 status.
      
+
      Discussion:
      
+
      
+The new to_string and to_wstring functions described in 21.5 [string.conversions]
+have throws clauses (paragraphs 8 and 16) which say:
+
      
+
+
      
+Throws: nothing
+
      
+
+
      
+Since all overloads return either a std::string or a std::wstring by value
+this throws clause is impossible to realize in general, since the basic_string
+constructors can fail due to out-of-memory conditions. Either these throws
+clauses should be removed or should be more detailled like:
+
      
+
+
      
+Throws: Nothing if the string construction throws nothing
+
      
+
+
      
+Further there is an editorial issue in p. 14: All three to_wstring
+overloads return a string, which should be wstring instead (The
+header <string> synopsis of 21.3 [string.classes] is correct in this
+regard).
+
      
+
+
+
+
      Proposed resolution:
      
+
      
+In 21.5 [string.conversions], remove the paragraphs 8 and 16.
+
      
+
+
      
+
      string to_string(long long val); 
+string to_string(unsigned long long val); 
+string to_string(long double val); 
+
      
+
      
+Throws: nothing
+
      
+
      
+
+
      
+
      wstring to_wstring(long long val); 
+wstring to_wstring(unsigned long long val); 
+wstring to_wstring(long double val); 
+
      
+
      
+Throws: nothing
+
      
+
      
+
+
+
+
+
+
+
      
+
      772.  Impossible return clause in [string.conversions]
      
+
      Section: 21.5 [string.conversions] Status: CD1
+ Submitter: Daniel Krügler Opened: 2008-01-13  Last modified: 2008-09-26
      
+
      View all other issues in [string.conversions].
      
+
      View all issues with CD1 status.
      
+
      Discussion:
      
+
      
+The return clause 21.5 [string.conversions]/paragraph 15 of the new to_wstring
+overloads says:
+
      
+
+
      
+Returns: each function returns a wstring object holding the character
+representation of the value of its argument that would be generated by
+calling wsprintf(buf, fmt, val) with a format specifier of L"%lld", L"%ulld",
+or L"%f", respectively.
+
      
+
+
      
+Problem is: There does not exist any wsprintf function in C99 (I checked
+the 2nd edition of ISO 9899, and the first and the second corrigenda from
+2001-09-01 and 2004-11-15). What probably meant here is the function
+swprintf from <wchar.h>/<cwchar>, but this has the non-equivalent
+declaration:
+
      
+
+
      int swprintf(wchar_t * restrict s, size_t n,
+const wchar_t * restrict format, ...);
+
      
+
+
      
+therefore the paragraph needs to mention the size_t parameter n.
+
      
+
+
+
+
      Proposed resolution:
      
+
      
+Change the current wording of 21.5 [string.conversions]/p. 15 to:
+
      
+
+
      
+Returns: eEach function returns a
+wstring object holding the character representation of the
+value of its argument that would be generated by calling
+wsswprintf(buf, bufsz, fmt,
+val) with a format specifier fmt of L"%lld",
+L"%ulld", or L"%f", respectively, where buf
+designates an internal character buffer of sufficient size bufsz.
+
      
+
+
      
+[Hint to the editor: The resolution also adds to mention the name of
+the format specifier "fmt"]
+
      
+
+
      
+I also would like to remark that the current wording of it's equivalent
+paragraph 7 should also mention the meaning of buf and fmt.
+
      
+
+
      
+Change the current wording of 21.5 [string.conversions]/p. 7 to:
+
      
+
+
      
+Returns: eEach function returns a string object holding the
+character representation of the value of its argument that would be
+generated by calling sprintf(buf, fmt, val) with a format specifier fmt of
+"%lld", "%ulld", or "%f", respectively, where buf designates an internal
+character buffer of sufficient size.
+
      
+
+
+
+
+
+
 
      
 
      775. Tuple indexing should be unsigned?
      
-
      Section: 20.4.1.4 [tuple.helper] Status: WP
- Submitter: Alisdair Meredith Date: 2008-01-16
      
-
      View all issues with WP status.
      
+
      Section: 20.5.2.3 [tuple.helper] Status: CD1
+ Submitter: Alisdair Meredith Opened: 2008-01-16  Last modified: 2008-09-26
      
+
      View other active issues in [tuple.helper].
      
+
      View all other issues in [tuple.helper].
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 The tuple element access API identifies the element in the sequence
@@ -29023,7 +31840,7 @@ problem as all elements are of type T.
 
 
      Proposed resolution:
      
 
      
-Update header <utility> synopsis in 20.2 [utility]
+Update header <utility> synopsis in 20.3 [utility]
 
      
 
      // 20.2.3, tuple-like access to pair:
 template <class T> class tuple_size;
@@ -29039,7 +31856,7 @@ template<intsize_t I, class T1, class T2>
   const Ptypename tuple_element<I, std::pair<T1, T2> >::type & get(const std::pair<T1, T2>&);
 
      
 
      
-Update 20.2.3 [pairs] Pairs
+Update 20.3.3 [pairs] Pairs
 
      
 
      template<intsize_t I, class T1, class T2>
   Ptypename tuple_element<I, std::pair<T1, T2> >::type & get(pair<T1, T2>&);
@@ -29058,7 +31875,7 @@ template<intsize_t I, class T1, class T2>
 
 
 
      
-Update header <tuple> synopsis in 20.4 [tuple] with a APIs as below:
+Update header <tuple> synopsis in 20.5 [tuple] with a APIs as below:
 
      
 
      template <intsize_t I, class T> class tuple_element; // undefined
 template <intsize_t I, class... Types> class tuple_element<I, tuple<Types...> >;
@@ -29071,7 +31888,7 @@ template <intsize_t I, class ... types>
 
      
 
 
      
-Update 20.4.1.4 [tuple.helper] Tuple helper classes
+Update 20.5.2.3 [tuple.helper] Tuple helper classes
 
      
 
      template <intsize_t I, class... Types>
 class tuple_element<I, tuple<Types...> > {
@@ -29085,7 +31902,7 @@ public:
 2 Type: TI is the type of the Ith element of Types, where indexing is zero-based.
 
      
 
      
-Update 20.4.1.5 [tuple.elem] Element access
+Update 20.5.2.4 [tuple.elem] Element access
 
      
 
      template <intsize_t I, class... types >
 typename tuple_element<I, tuple<Types...> >::type& get(tuple<Types...>& t);
@@ -29110,7 +31927,7 @@ typename tuple_element<I, tuple<Types...> >::type const& get(con
 
 
 
      
-Update header <array> synopsis in 20.2 [utility]
+Update header <array> synopsis in 20.3 [utility]
 
      
 
      template <class T> class tuple_size; // forward declaration
 template <intsize_t I, class T> class tuple_element; // forward declaration
@@ -29125,7 +31942,7 @@ template <intsize_t I, class T, size_t N>
 
      
 
 
      
-Update 23.2.1.6 [array.tuple] Tuple interface to class template array
+Update 23.3.1.7 [array.tuple] Tuple interface to class template array
 
      
 
      tuple_element<size_t I, array<T, N> >::type
 
      
@@ -29169,12 +31986,106 @@ for pair is also unnecessary.
 
 
 
+
      
+
      776. Undescribed assign function of std::array
      
+
      Section: 23.3.1 [array] Status: CD1
+ Submitter: Daniel Krügler Opened: 2008-01-20  Last modified: 2008-09-26
      
+
      View other active issues in [array].
      
+
      View all other issues in [array].
      
+
      View all issues with CD1 status.
      
+
      Discussion:
      
+
      
+The class template array synopsis in 23.3.1 [array]/3 declares a member
+function
+
      
+
+
      void assign(const T& u);
+
      
+
+
      
+which's semantic is no-where described. Since this signature is
+not part of the container requirements, such a semantic cannot
+be derived by those.
+
      
+
+
      
+I found only one reference to this function in the issue list,
+588 where the question is raised:
+
      
+
+
      
+what's the effect of calling assign(T&) on a zero-sized array?
+
      
+
+
      
+which does not answer the basic question of this issue.
+
      
+
+
      
+If this function shall be part of the std::array, it's probable
+semantic should correspond to that of boost::array, but of
+course such wording must be added.
+
      
+
+
+
      Proposed resolution:
      
+
      
+Just after the section 23.3.1.4 [array.data] add the following new section:
+
      
+
+
      
+23.2.1.5 array::fill [array.fill]
+
      
+
+
      
+
      void fill(const T& u);
+
      
+
+
      
+1: Effects: fill_n(begin(), N, u)
+
      
+
      
+
+
      
+[N.B: I wonder, why class array does not have a "modifiers"
+section. If it had, then assign would naturally belong to it]
+
      
+
+
      
+Change the synopsis in 23.3.1 [array]/3:
+
      
+
+
      template <class T, size_t N>
+struct array { 
+  ...
+  void assign fill(const T& u);
+  ...
+
      
+
+
+
      [
+Bellevue:
+]
      
+
+
+
      
+
      
+Suggest substituting "fill" instead of "assign".
+
      
+
      
+Set state to Review given substitution of "fill" for "assign".
+
      
+
      
+
+
+
+
 
      
 
      777. Atomics Library Issue
      
-
      Section: 29.4 [atomics.types.operations] Status: WP
- Submitter: Lawrence Crowl Date: 2008-01-21
      
+
      Section: 29.6 [atomics.types.operations] Status: CD1
+ Submitter: Lawrence Crowl Opened: 2008-01-21  Last modified: 2008-09-26
      
 
      View all other issues in [atomics.types.operations].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 The load functions are defined as
@@ -29245,10 +32156,10 @@ C A::load(memory_order order = memory_order_seq_cst) const volatile;
 
 
      
 
      778. std::bitset does not have any constructor taking a string literal
      
-
      Section: 23.3.5.1 [bitset.cons] Status: WP
- Submitter: Thorsten Ottosen Date: 2008-01-24
      
+
      Section: 20.3.6.1 [bitset.cons] Status: CD1
+ Submitter: Thorsten Ottosen Opened: 2008-01-24  Last modified: 2008-09-26
      
 
      View all other issues in [bitset.cons].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Duplicate of: 116
      
 
      Discussion:
      
 
      
@@ -29271,14 +32182,14 @@ to std::bitset.
 
 
      Proposed resolution:
      
 
      
-Add to synopsis in 23.3.5 [template.bitset]
+Add to synopsis in 20.3.6 [template.bitset]
 
      
 
 
      explicit bitset( const char* str );
 
      
 
 
      
-Add to synopsis in 23.3.5.1 [bitset.cons]
+Add to synopsis in 20.3.6.1 [bitset.cons]
 
      
 
 
      explicit bitset( const char* str );
@@ -29294,14 +32205,44 @@ Add to synopsis in 23.3.5.1 [bitset.cons]
 
 
 
      
-
      781. std::complex should add missing C99 functions
      
-
      Section: 26.3.7 [complex.value.ops] Status: WP
- Submitter: Daniel Krügler Date: 2008-01-26
      
-
      View all other issues in [complex.value.ops].
      
-
      View all issues with WP status.
      
+
      779. Resolution of #283 incomplete
      
+
      Section: 25.4.8 [alg.remove] Status: CD1
+ Submitter: Daniel Krügler Opened: 2008-01-25  Last modified: 2008-09-26
      
+
      View all other issues in [alg.remove].
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
-A comparision of the N2461 header <complex> synopsis ([complex.synopsis])
+The resolution of 283 did not resolve similar necessary changes for algorithm
+remove_copy[_if],
+which seems to be an oversight.
+
      
+
+
+
      Proposed resolution:
      
+
      
+In 25.4.8 [alg.remove]/p.6, replace the N2461 requires clause with:
+
      
+
+
      
+Requires: Type T is EqualityComparable (31). The ranges [first,last)
+and [result,result + (last - first)) shall not overlap. The expression *result = *first shall be
+valid.
+
      
+
+
+
+
+
+
+
      
+
      781. std::complex should add missing C99 functions
      
+
      Section: 26.4.7 [complex.value.ops] Status: CD1
+ Submitter: Daniel Krügler Opened: 2008-01-26  Last modified: 2009-03-21
      
+
      View all other issues in [complex.value.ops].
      
+
      View all issues with CD1 status.
      
+
      Discussion:
      
+
      
+A comparision of the N2461 header <complex> synopsis ([complex.syn])
 with the C99 standard (ISO 9899, 2nd edition and the two corrigenda) show
 some complex functions that are missing in C++. These are:
 
      
@@ -29328,7 +32269,7 @@ function).
 
 
      
 Please note also that the current entry polar
-in 26.3.9 [cmplx.over]/1
+in 26.4.9 [cmplx.over]/1
 should be removed from the mentioned overload list. It does not make sense to require that a
 function already expecting scalar arguments
 should cast these arguments into corresponding
@@ -29339,7 +32280,7 @@ this function.
 
 
      Proposed resolution:
      
 
      
-In 26.3.1 [complex.synopsis] add just between the declaration of conj and fabs:
+In 26.4.1 [complex.syn] add just between the declaration of conj and fabs:
 
      
 
 
      template<class T> complex<T> conj(const complex<T>&);
@@ -29348,7 +32289,7 @@ template<class T> complex<T> fabs(const complex<T>&);
 
      
 
 
      
-In 26.3.7 [complex.value.ops] just after p.6 (return clause of conj) add:
+In 26.4.7 [complex.value.ops] just after p.6 (return clause of conj) add:
 
      
 
 
      
@@ -29362,7 +32303,7 @@ subclause 7.3.9.4."
 
      
 
 
      
-In 26.3.9 [cmplx.over]/1, add one further entry proj to
+In 26.4.9 [cmplx.over]/1, add one further entry proj to
 the overload list.
 
      
 
@@ -29383,11 +32324,10 @@ imag          real
 
 
      
 
      782. Extended seed_seq constructor is useless
      
-
      Section: 26.4.7.1 [rand.util.seedseq] Status: WP
- Submitter: Daniel Krügler Date: 2008-01-27
      
-
      View other active issues in [rand.util.seedseq].
      
+
      Section: 26.5.7.1 [rand.util.seedseq] Status: CD1
+ Submitter: Daniel Krügler Opened: 2008-01-27  Last modified: 2009-05-01
      
 
      View all other issues in [rand.util.seedseq].
      
-
      View all issues with WP status.
      
+
      View all issues with CD1 status.
      
 
      Discussion:
      
 
      
 Part of the resolution of n2423, issue 8 was the proposal to
@@ -29412,7 +32352,7 @@ template arguments of function templates, this customization
 point via the second size_t template parameter is of no advantage,
 because u can never be deduced, and worse - because it is a
 constructor function template - it can also never be explicitly
-provided (14.8.1 [temp.arg.explicit]/7).
+provided (14.9.1 [temp.arg.explicit]/7).
 
      
 
 
      
@@ -29442,7 +32382,7 @@ Proposed Resolution: Accept Solution A.
 
      
 
 
      
-Issue 803 claims to make this issue moot.
+Issue 803 claims to make this issue moot.
 
      
 
 
@@ -29451,7 +32391,7 @@ Issue 
 
        
 
      1. 
 
        
-In 26.4.7.1 [rand.util.seedseq]/2, class seed_seq synopsis replace:
+In 26.5.7.1 [rand.util.seedseq]/2, class seed_seq synopsis replace:
 
        
 
 
        class seed_seq 
@@ -29474,20 +32414,20 @@ p.3 and p.4.
 
 
      2. 
 
        
-In 26.4.7.1 [rand.util.seedseq]/2, class seed_seq synopsis and in the
+In 26.5.7.1 [rand.util.seedseq]/2, class seed_seq synopsis and in the
 member description between p.3 and p.4 replace:
 
        
 
 
        template<class InputIterator,
   size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>
-	  seed_seq(InputIterator begin, InputIterator end);
+      seed_seq(InputIterator begin, InputIterator end);
 template<class InputIterator, size_t u>
 seed_seq(InputIterator begin, InputIterator end, implementation-defined s);
 
        
 
 
        
-In 26.4.2 [rand.synopsis], header <random> synopsis, immediately after the
-class seed_seq declaration and in 26.4.7.1 [rand.util.seedseq]/2, immediately
+In 26.5.1 [rand.synopsis], header <random> synopsis, immediately after the
+class seed_seq declaration and in 26.5.7.1 [rand.util.seedseq]/2, immediately
 after the class seed_seq definition add:
 
        
 
@@ -29496,7 +32436,7 @@ after the class seed_seq definition add:
 
        3. 
 
 
        
-In 26.4.7.1 [rand.util.seedseq], just before p.5 insert two paragraphs:
+In 26.5.7.1 [rand.util.seedseq], just before p.5 insert two paragraphs:
 
        
 
 
        
@@ -29513,7 +32453,7 @@ is called by the function make_seed_seq.
 
        
 
 
        
-In 26.4.7.1 [rand.util.seedseq], just after the last paragraph add:
+In 26.5.7.1 [rand.util.seedseq], just after the last paragraph add:
 
        
 
 
        
@@ -29540,9 +32480,10 @@ where u is used to construct an object s of implementation-def
 
 
        
 
        783. thread::id reuse
        
-
        Section: 30.2.1.1 [thread.thread.id] Status: WP
- Submitter: Hans Boehm Date: 2008-02-01
        
-
        View all issues with WP status.
        
+
        Section: 30.3.1.1 [thread.thread.id] Status: CD1
+ Submitter: Hans Boehm Opened: 2008-02-01  Last modified: 2008-09-26
        
+
        View all other issues in [thread.thread.id].
        
+
        View all issues with CD1 status.
        
 
        Discussion:
        
 
        
 The current working paper 
@@ -29598,7 +32539,7 @@ example:
 
 
        Proposed resolution:
        
 
        
-Add a sentence to 30.2.1.1 [thread.thread.id]/p1:
+Add a sentence to 30.3.1.1 [thread.thread.id]/p1:
 
        
 
 
        
@@ -29622,12 +32563,66 @@ terminated thread that can no longer be joined.
 
 
 
+
        
+
        787. complexity of binary_search
        
+
        Section: 25.5.3.4 [binary.search] Status: CD1
+ Submitter: Daniel Krügler Opened: 2007-09-08  Last modified: 2008-09-26
        
+
        View all issues with CD1 status.
        
+
        Discussion:
        
+
        
+In 25.5.3.4 [binary.search]/3 the complexity of binary_search is described as
+
        
+
+
        
+At most log(last - first) + 2 comparisons.
+
        
+
+
        
+This should be precised and brought in line with the nomenclature used for
+lower_bound, upper_bound, and equal_range.
+
        
+
+
        
+All existing libraries I'm aware of, delegate to
+lower_bound (+ one further comparison). Since
+issue 384
+has now WP status, the resolution of #787 should
+be brought in-line with 384 by changing the + 2
+to + O(1).
+
        
+
+
        [
+Sophia Antipolis:
+]
        
+
+
+
        
+Alisdair prefers to apply an upper bound instead of O(1), but that would
+require fixing for lower_bound, upper_bound etc. as well. If he really
+cares about it, he'll send an issue to Howard.
+
        
+
+
+
+
        Proposed resolution:
        
+
        
+Change 25.5.3.4 [binary.search]/3
+
        
+
+
        
+Complexity: At most log2(last - first) + 2 O(1) comparisons.
+
        
+
+
+
+
+
 
        
 
        789. xor_combine_engine(result_type) should be explicit
        
-
        Section: 26.4.4.4 [rand.adapt.xor] Status: WP
- Submitter: P.J. Plauger Date: 2008-02-09
        
+
        Section: X [rand.adapt.xor] Status: CD1
+ Submitter: P.J. Plauger Opened: 2008-02-09  Last modified: 2008-09-26
        
 
        View all other issues in [rand.adapt.xor].
        
-
        View all issues with WP status.
        
+
        View all issues with CD1 status.
        
 
        Discussion:
        
 
        
 xor_combine_engine(result_type) should be explicit. (Obvious oversight.)
@@ -29650,10 +32645,10 @@ adapter.
 
 
        Proposed resolution:
        
 
        
-Remove xor_combine_engine from synopsis of 26.4.2 [rand.synopsis].
+Remove xor_combine_engine from synopsis of 26.5.1 [rand.synopsis].
 
        
 
        
-Remove 26.4.4.4 [rand.adapt.xor] xor_combine_engine.
+Remove X [rand.adapt.xor] xor_combine_engine.
 
        
 
 
@@ -29662,11 +32657,10 @@ Remove 26.4.4.4 [rand.adapt.xor] xor_combine_engine.
 
 
        
 
        792. piecewise_constant_distribution is undefined for a range with just one endpoint
        
-
        Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: WP
- Submitter: P.J. Plauger Date: 2008-02-09
        
-
        View other active issues in [rand.dist.samp.pconst].
        
+
        Section: 26.5.8.5.2 [rand.dist.samp.pconst] Status: CD1
+ Submitter: P.J. Plauger Opened: 2008-02-09  Last modified: 2008-09-26
        
 
        View all other issues in [rand.dist.samp.pconst].
        
-
        View all issues with WP status.
        
+
        View all issues with CD1 status.
        
 
        Discussion:
        
 
        
 piecewise_constant_distribution is undefined for a range with just one
@@ -29676,7 +32670,7 @@ endpoint. (Probably should be the same as an empty range.)
 
 
        Proposed resolution:
        
 
        
-Change 26.4.8.5.2 [rand.dist.samp.pconst] paragraph 3b:
+Change 26.5.8.5.2 [rand.dist.samp.pconst] paragraph 3b:
 
        
 
 
        
@@ -29689,10 +32683,10 @@ b) If firstB == lastB or the sequence w has the length ze
 
 
        
 
        798. Refactoring of binders lead to interface breakage
        
-
        Section: D.8 [depr.lib.binders] Status: WP
- Submitter: Daniel Krügler Date: 2008-02-14
        
+
        Section: D.8 [depr.lib.binders] Status: CD1
+ Submitter: Daniel Krügler Opened: 2008-02-14  Last modified: 2008-09-26
        
 
        View all other issues in [depr.lib.binders].
        
-
        View all issues with WP status.
        
+
        View all issues with CD1 status.
        
 
        Discussion:
        
 
        
 N2521
@@ -29775,4 +32769,2702 @@ public:
 
 
 
+
        
+
        804. Some problems with classes error_code/error_condition
        
+
        Section: 19.5 [syserr] Status: CD1
+ Submitter: Daniel Krügler Opened: 2008-02-24  Last modified: 2008-09-26
        
+
        View all other issues in [syserr].
        
+
        View all issues with CD1 status.
        
+
        Discussion:
        
+
          
+
        1. 
+
          
+19.5.2.2 [syserr.errcode.overview]/1, class error_code and
+19.5.3.2 [syserr.errcondition.overview]/, class error_condition synopses
+declare an expository data member cat_:
+
          
+
          const error_category& cat_; // exposition only
+
          
+
          
+which is used to define the semantics of several members. The decision
+to use a member of reference type lead to several problems:
+
          
+
            
+
          1. 
+The classes are not (Copy)Assignable, which is probably not the intent.
+
            2. 
+
          2. 
+The post conditions of all modifiers from
+19.5.2.4 [syserr.errcode.modifiers] and 19.5.3.4 [syserr.errcondition.modifiers], resp.,
+cannot be fulfilled.
+
            3. 
+
          
+
          
+The simple fix would be to replace the reference by a pointer member.
+
          
+
          2. 
+
+
        2. 
+I would like to give the editorial remark that in both classes the
+constrained operator=
+overload (template with ErrorCodeEnum argument) makes in invalid
+usage of std::enable_if: By using the default value for the second enable_if
+parameter the return type would be defined to be void& even in otherwise
+valid circumstances - this return type must be explicitly provided (In
+error_condition the first declaration uses an explicit value, but of wrong
+type).
+
          3. 
+
+
        3. 
+The member function message throws clauses (
+19.5.1.2 [syserr.errcat.virtuals]/10, 19.5.2.5 [syserr.errcode.observers]/8, and
+19.5.3.5 [syserr.errcondition.observers]/6) guarantee "throws nothing",
+although
+they return a std::string by value, which might throw in out-of-memory
+conditions (see related issue 771).
+
          4. 
+
        
+
+
        [
+Sophia Antipolis:
+]
        
+
+
+
        
+
        
+Part A: NAD (editorial), cleared by the resolution of issue 832.
+
        
+
        
+Part B: Technically correct, save for typo. Rendered moot by the concept proposal 
+(N2620) NAD (editorial).
+
        
+
        
+Part C: We agree; this is consistent with the resolution of issue 721.
+
        
+
        
+Howard: please ping Beman, asking him to clear away parts A and B from
+the wording in the proposed resolution, so it is clear to the editor
+what needs to be applied to the working paper.
+
        
+
        
+Beman provided updated wording. Since issue 832 is not going
+forward, the provided wording includes resolution of part A.
+
        
+
        
+
+
+
+
        Proposed resolution:
        
+
+
        
+Resolution of part A:
+
        
+
        
+
        
+Change 19.5.2.2 [syserr.errcode.overview] Class error_code overview synopsis as indicated:
+
        
+
+
        private:
+  int val_;                    // exposition only
+  const error_category&* cat_; // exposition only
+
        
+
+
        
+Change 19.5.2.3 [syserr.errcode.constructors] Class error_code constructors as indicated:
+
        
+
+
        
+
        error_code();
+
        
+
        
+
        
+Effects: Constructs an object of type error_code.
+
        
+
        
+Postconditions: val_ == 0 and cat_ == &system_category.
+
        
+
        
+Throws: Nothing.
+
        
+
        
+
        error_code(int val, const error_category& cat);
+
        
+
        
+
        
+Effects: Constructs an object of type error_code.
+
        
+
        
+Postconditions: val_ == val and cat_ == &cat.
+
        
+
        
+Throws: Nothing.
+
        
+
        
+
        
+
+
        
+Change 19.5.2.4 [syserr.errcode.modifiers] Class error_code modifiers as indicated:
+
        
+
+
        
+
        void assign(int val, const error_category& cat);
+
        
+
        
+
        
+Postconditions: val_ == val and cat_ == &cat.
+
        
+
        
+Throws: Nothing.
+
        
+
        
+
        
+
+
        
+Change 19.5.2.5 [syserr.errcode.observers] Class error_code observers as indicated:
+
        
+
+
        
+const error_category& category() const;
+
        
+
        
+Returns: *cat_.
+
        
+
        
+Throws: Nothing.
+
        
+
        
+
        
+
+
        
+Change 19.5.3.2 [syserr.errcondition.overview] Class error_condition overview synopsis as indicated:
+
        
+
+
        private:
+  int val_;                    // exposition only
+  const error_category&* cat_; // exposition only
+
        
+
+
        
+Change 19.5.3.3 [syserr.errcondition.constructors] Class error_condition constructors as indicated:
+
        
+
        [
+(If the proposed resolution of issue 805 has already been applied, the
+name posix_category will have been changed to generic_category. That has
+no effect on this resolution.)
+]
        
+
+
+
        
+
        error_condition();
+
        
+
        
+
        
+Effects: Constructs an object of type error_condition.
+
        
+
        
+Postconditions: val_ == 0 and cat_ == &posix_category.
+
        
+
        
+Throws: Nothing.
+
        
+
        
+
        error_condition(int val, const error_category& cat);
+
        
+
        
+
        
+Effects: Constructs an object of type error_condition.
+
        
+
        
+Postconditions: val_ == val and cat_ == &cat.
+
        
+
        
+Throws: Nothing.
+
        
+
        
+
        
+
+
        
+Change 19.5.3.4 [syserr.errcondition.modifiers] Class error_condition modifiers as indicated:
+
        
+
+
        
+void assign(int val, const error_category& cat);
+
        
+
        
+Postconditions: val_ == val and cat_ == &cat.
+
        
+
        
+Throws: Nothing.
+
        
+
        
+
        
+
+
        
+Change 19.5.3.5 [syserr.errcondition.observers] Class error_condition observers as indicated:
+
        
+
+
        
+const error_category& category() const;
+
        
+
        
+Returns: *cat_.
+
        
+
        
+Throws: Nothing.
+
        
+
        
+
        
+
        
+
+
        
+Resolution of part C:
+
        
+
+
        
+
+
        
+In 19.5.1.2 [syserr.errcat.virtuals], remove the throws clause p. 10.
+
        
+
+
        
+
        virtual string message(int ev) const = 0;
+
        
+
+
        
+
        
+Returns: A string that describes the error condition denoted by ev.
+
        
+
        
+Throws: Nothing.
+
        
+
        
+
        
+
+
        
+In 19.5.2.5 [syserr.errcode.observers], remove the throws clause p. 8.
+
        
+
+
        
+
        string message() const;
+
        
+
        
+
        
+Returns: category().message(value()).
+
        
+
        
+Throws: Nothing.
+
        
+
        
+
        
+
+
        
+In 19.5.3.5 [syserr.errcondition.observers], remove the throws clause p. 6.
+
        
+
+
        
+
        string message() const;
+
        
+
        
+
        
+Returns: category().message(value()).
+
        
+
        
+Throws: Nothing.
+
        
+
        
+
        
+
+
        
+
+
+
+
+
+
+
        
+
        805. posix_error::posix_errno concerns
        
+
        Section: 19.5 [syserr] Status: CD1
+ Submitter: Jens Maurer Opened: 2008-02-24  Last modified: 2008-09-26
        
+
        View all other issues in [syserr].
        
+
        View all issues with CD1 status.
        
+
        Discussion:
        
+
        
+19.5 [syserr]
+
        
+
+
        namespace posix_error {
+  enum posix_errno {
+    address_family_not_supported, // EAFNOSUPPORT
+    ...
+
        
+
+
        
+should rather use the new scoped-enum  facility (7.2 [dcl.enum]),
+which would avoid the necessity for a new posix_error
+namespace, if I understand correctly.
+
        
+
+
        [
+Further discussion:
+]
        
+
+
+
        
+
        
+See N2347,
+Strongly Typed Enums, since renamed Scoped Enums.
+
        
+
        
+Alberto Ganesh Barbati also raised this issue in private email, and also proposed the scoped-enum solution.
+
        
+
        
+Nick Stoughton asked in Bellevue that posix_error and posix_errno not be used as names. The LWG agreed.
+
        
+
        
+The wording for the Proposed resolution was provided by Beman Dawes.
+
        
+
        
+
+
+
        Proposed resolution:
        
+
        
+Change System error support 19.5 [syserr] as indicated:
+
        
+
+
        namespace posix_error {
+  enum posix_errno class errc {
+    address_family_not_supported, // EAFNOSUPPORT
+    ...
+    wrong_protocol_type, // EPROTOTYPE
+  };
+} // namespace posix_error
+
+template <> struct is_error_condition_enum<posix_error::posix_errno errc>
+  : public true_type {}
+
+namespace posix_error {
+  error_code make_error_code(posix_errno errc e);
+  error_condition make_error_condition(posix_errno errc e);
+} // namespace posix_error
+
        
+
+
        
+Change System error support 19.5 [syserr] :
+
        
+
+
        
+The is_error_code_enum and is_error_condition_enum templates may be
+specialized for user-defined types to indicate that such a type is
+eligible for class error_code and class error_condition automatic
+conversions, respectively.
+
        
+
+
        
+Change System error support 19.5 [syserr] and its subsections:
+
        
+
+
        
+
          
+
        • 
+remove all occurrences of posix_error::
+
          • 
+
        • 
+change all instances of posix_errno to errc
+
          • 
+
        • 
+change all instances of posix_category to generic_category
+
          • 
+
        • 
+change all instances of get_posix_category to get_generic_category
+
          • 
+
        
+
        
+
+
        
+Change Error category objects 19.5.1.5 [syserr.errcat.objects], paragraph 2:
+
        
+
+
        
+Remarks: The object's default_error_condition and equivalent virtual
+functions shall behave as specified for the class error_category. The
+object's name virtual function shall return a pointer to the string
+"POSIX" "generic".
+
        
+
+
        
+Change 19.5.2.6 [syserr.errcode.nonmembers] Class error_code non-member functions as indicated:
+
        
+
+
        
+
        error_code make_error_code(posix_errno errc e);
+
        
+
+
        
+Returns: error_code(static_cast<int>(e), posixgeneric_category).
+
        
+
        
+
+
        
+Change 19.5.3.6 [syserr.errcondition.nonmembers] Class error_condition non-member functions as indicated:
+
        
+
+
        
+
        error_condition make_error_condition(posix_errno errc e);
+
        
+
+
        
+Returns: error_condition(static_cast<int>(e), posixgeneric_category).
+
        
+
        
+
+
+
+
        Rationale:
        
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
        Names Considered
        portable
+Too non-specific. Did not wish to reserve such a common word in
+namespace std. Not quite the right meaning, either.
+
        portable_error
+Too long. Explicit qualification is always required for scoped enums, so
+a short name is desirable. Not quite the right meaning, either. May be
+misleading because *_error in the std lib is usually an exception class
+name.
+
        std_error
+Fairly short, yet explicit. But in fully qualified names like
+std::std_error::not_enough_memory, the std_ would be unfortunate. Not
+quite the right meaning, either. May be misleading because *_error in
+the std lib is usually an exception class name.
+
        generic
+Short enough. The category could be generic_category. Fully qualified
+names like std::generic::not_enough_memory read well. Reserving in
+namespace std seems dicey.
+
        generic_error
+Longish. The category could be generic_category. Fully qualified names
+like std::generic_error::not_enough_memory read well. Misleading because
+*_error in the std lib is usually an exception class name.
+
        generic_err
+A bit less longish. The category could be generic_category. Fully
+qualified names like std::generic_err::not_enough_memory read well.
+
        gen_err
+Shorter still. The category could be generic_category. Fully qualified
+names like std::gen_err::not_enough_memory read well.
+
        generr
+Shorter still. The category could be generic_category. Fully qualified
+names like std::generr::not_enough_memory read well.
+
        error
+Shorter still. The category could be generic_category. Fully qualified
+names like std::error::not_enough_memory read well. Do we want to use
+this general a name?
+
        err
+Shorter still. The category could be generic_category. Fully qualified
+names like std::err::not_enough_memory read well. Although alone it
+looks odd as a name, given the existing errno and namespace std names,
+it seems fairly intuitive.
+Problem: err is used throughout the standard library as an argument name
+and in examples as a variable name; it seems too confusing to add yet
+another use of the name.
+
        errc
+Short enough. The "c" stands for "constant". The category could be
+generic_category. Fully qualified names like
+std::errc::not_enough_memory read well. Although alone it looks odd as a
+name, given the existing errno and namespace std names, it seems fairly
+intuitive. There are no uses of errc in the current C++ standard.
+
        
+
+
+
+
+
+
        
+
        806. unique_ptr::reset effects incorrect, too permissive
        
+
        Section: 20.8.12.2.5 [unique.ptr.single.modifiers] Status: CD1
+ Submitter: Peter Dimov Opened: 2008-03-13  Last modified: 2008-09-26
        
+
        View other active issues in [unique.ptr.single.modifiers].
        
+
        View all other issues in [unique.ptr.single.modifiers].
        
+
        View all issues with CD1 status.
        
+
        Discussion:
        
+
        
+void unique_ptr::reset(T* p = 0) is currently specified as:
+
        
+
+
        
+Effects: If p == get() there are no effects. Otherwise get_deleter()(get()).
+
        
+
+
        
+There are two problems with this. One, if get() == 0 and p != 0, the
+deleter is called with a NULL pointer, and this is probably not what's
+intended (the destructor avoids calling the deleter with 0.)
+
        
+
+
        
+Two, the special check for get() == p is generally not needed and such a
+situation usually indicates an error in the client code, which is being
+masked. As a data point, boost::shared_ptr was changed to assert on such
+self-resets in 2001 and there were no complaints.
+
        
+
+
        
+One might think that self-resets are necessary for operator= to work; it's specified to perform
+
        
+
+
        reset( u.release() );
+
        
+
+
        
+and the self-assignment
+
        
+
+
        p = move(p);
+
        
+
+
        
+might appear to result in a self-reset. But it doesn't; the release() is
+performed first, zeroing the stored pointer. In other words, p.reset(
+q.release() ) works even when p and q are the same unique_ptr, and there
+is no need to special-case p.reset( q.get() ) to work in a similar
+scenario, as it definitely doesn't when p and q are separate.
+
        
+
+
+
+
        Proposed resolution:
        
+
+
        
+Change 20.8.12.2.5 [unique.ptr.single.modifiers]:
+
        
+
+
        
+
        void reset(T* p = 0);
+
        
+
        
+-4- Effects: If p == get() == 0 there are no effects. Otherwise get_deleter()(get()).
+
        
+
        
+
+
        
+Change 20.8.12.3.3 [unique.ptr.runtime.modifiers]:
+
        
+
+
        
+
        void reset(T* p = 0);
+
        
+
        
+
        ...
        
+
        
+-2- Effects: If p == get() == 0 there are no effects. Otherwise get_deleter()(get()).
+
        
+
        
+
        
+
+
+
+
+
+
+
        
+
        807. tuple construction should not fail unless its element's construction fails
        
+
        Section: 20.5.2.1 [tuple.cnstr] Status: CD1
+ Submitter: Howard Hinnant Opened: 2008-03-13  Last modified: 2008-09-26
        
+
        View other active issues in [tuple.cnstr].
        
+
        View all other issues in [tuple.cnstr].
        
+
        View all issues with CD1 status.
        
+
        Discussion:
        
+
        
+527 Added a throws clause to bind constructors.  I believe the same throws clause
+should be added to tuple except it ought to take into account move constructors as well.
+
        
+
+
+
        Proposed resolution:
        
+
        
+Add to 20.5.2.1 [tuple.cnstr]:
+
        
+
+
        
+
        
+For each tuple constructor and assignment operator, an exception is thrown only if the construction
+or assignment of one of the types in Types throws an exception.
+
        
+
        
+
+
+
+
+
+
        
+
        808. [forward] incorrect redundant specification
        
+
        Section: 20.3.2 [forward] Status: CD1
+ Submitter: Jens Maurer Opened: 2008-03-13  Last modified: 2008-09-26
        
+
        View all other issues in [forward].
        
+
        View all issues with CD1 status.
        
+
        Discussion:
        
+
        
+p4 (forward) says:
+
        
+
        
+Return type: If T is an lvalue-reference type, an lvalue; otherwise, an rvalue.
+
        
+
+
        
+First of all, lvalue-ness and rvalue-ness are properties of an expression,
+not of a type (see 3.10 [basic.lval]).  Thus, the phrasing "Return type" is wrong.
+Second, the phrase says exactly what the core language wording says for
+folding references in 14.4.1 [temp.arg.type]/p4  and for function return values
+in 5.2.2 [expr.call]/p10.  (If we feel the wording should be retained, it should
+at most be a note with cross-references to those sections.)
+
        
+
        
+The prose after the example talks about "forwarding as an int& (an lvalue)" etc.
+In my opinion, this is a category error:  "int&" is a type, "lvalue" is a
+property of an expression, orthogonal to its type.  (Btw, expressions cannot
+have reference type, ever.)
+
        
+
        
+Similar with move:
+
        
+
        
+Return type: an rvalue.
+
        
+
        
+is just wrong and also redundant.
+
        
+
+
+
        Proposed resolution:
        
+
        
+Change 20.3.2 [forward] as indicated:
+
        
+
+
        
+
        template <class T> T&& forward(typename identity<T>::type&& t);
+
        
+
+
        
+
        ...
        
+
        
+Return type: If T is an lvalue-reference type, an lvalue; otherwise, an rvalue.
+
        
+
        ...
        
+
        
+-7- In the first call to factory, A1 is deduced as int, so 2 is forwarded to A's constructor
+as an int&& (an rvalue). In the second call to factory, A1 is deduced
+as int&, so i is forwarded to A's constructor as an int& (an lvalue).
+In both cases, A2 is deduced as double, so 1.414 is forwarded to A's constructor as
+double&& (an rvalue).
+
        
+
        
+
+
        template <class T> typename remove_reference<T>::type&& move(T&& t);
+
        
+
+
        
+
        ...
        
+
        
+Return type:  an rvalue.
+
        
+
        
+
+
        
+
+
+
+
+
+
+
        
+
        809. std::swap should be overloaded for array types
        
+
        Section: 25.4.3 [alg.swap] Status: CD1
+ Submitter: Niels Dekker Opened: 2008-02-28  Last modified: 2008-09-26
        
+
        View all other issues in [alg.swap].
        
+
        View all issues with CD1 status.
        
+
        Discussion:
        
+
        
+For the sake of generic programming, the header <algorithm> should provide an
+overload of std::swap for array types:
+
        template<class T, size_t N> void swap(T (&a)[N], T (&b)[N]);
+
        
+
+
+
        
+It became apparent to me that this overload is missing, when I considered how to write a swap
+function for a generic wrapper class template.
+(Actually I was thinking of Boost's value_initialized.)
+Please look at the following template, W, and suppose that is intended to be a very
+generic wrapper:
+
        template<class T> class W {
+public:
+   T data;
+};
+
        
+Clearly W<T> is CopyConstructible and CopyAssignable, and therefore
+Swappable, whenever T is CopyConstructible and CopyAssignable.
+Moreover, W<T> is also Swappable when T is an array type
+whose element type is CopyConstructible and CopyAssignable.
+Still it is recommended to add a custom swap function template to such a class template,
+for the sake of efficiency and exception safety.
+(E.g., Scott Meyers, Effective C++, Third Edition, item 25: Consider support for a non-throwing
+swap.)
+This function template is typically written as follows:
+
        template<class T> void swap(W<T>& x, W<T>& y) {
+  using std::swap;
+  swap(x.data, y.data);
+}
+
        
+Unfortunately, this will introduce an undesirable inconsistency, when T is an array.
+For instance, W<std::string[8]> is Swappable, but the current Standard does not
+allow calling the custom swap function that was especially written for W!
+
        W<std::string[8]> w1, w2;  // Two objects of a Swappable type.
+std::swap(w1, w2);  // Well-defined, but inefficient.
+using std::swap;
+swap(w1, w2);  // Ill-formed, just because ADL finds W's swap function!!!
+
        
+
+W's swap function would try to call std::swap for an array,
+std::string[8], which is not supported by the Standard Library.
+This issue is easily solved by providing an overload of std::swap for array types.
+This swap function should be implemented in terms of swapping the elements of the arrays, so that
+it would be non-throwing for arrays whose element types have a non-throwing swap.
+
+
+
        
+Note that such an overload of std::swap should also support multi-dimensional
+arrays. Fortunately that isn't really an issue, because it would do so automatically, by
+means of recursion.
+
        
+
+
        
+For your information, there was a discussion on this issue at comp.lang.c++.moderated: [Standard
+Library] Shouldn't std::swap be overloaded for C-style arrays?
+
        
+
+
+
        Proposed resolution:
        
+
        
+Add an extra condition to the definition of Swappable requirements [swappable] in X [utility.arg.requirements]:
+
        
+
        
+- T is Swappable if T is an array type whose element type is Swappable.
+
        
+
        
+Add the following to 25.4.3 [alg.swap]:
+
        
+
        
+
        template<class T, size_t N> void swap(T (&a)[N], T (&b)[N]);
+
        
+
        
+Requires: Type T shall be Swappable.
+
        
+
        
+Effects: swap_ranges(a, a + N, b);
+
        
+
        
+
+
+
+
+
+
        
+
        813. "empty" undefined for shared_ptr
        
+
        Section: 20.8.13.2 [util.smartptr.shared] Status: CD1
+ Submitter: Matt Austern Opened: 2008-02-26  Last modified: 2008-09-26
        
+
        View other active issues in [util.smartptr.shared].
        
+
        View all other issues in [util.smartptr.shared].
        
+
        View all issues with CD1 status.
        
+
        Discussion:
        
+
        
+Several places in 20.8.13.2 [util.smartptr.shared] refer to an "empty" shared_ptr.
+However, that term is nowhere defined. The closest thing we have to a
+definition is that the default constructor creates an empty shared_ptr
+and that a copy of a default-constructed shared_ptr is empty. Are any
+other shared_ptrs empty? For example, is shared_ptr((T*) 0) empty? What
+are the properties of an empty shared_ptr? We should either clarify this
+term or stop using it.
+
        
+
        
+One reason it's not good enough to leave this term up to the reader's
+intuition is that, in light of
+N2351
+and issue 711, most readers'
+intuitive understanding is likely to be wrong. Intuitively one might
+expect that an empty shared_ptr is one that doesn't store a pointer,
+but, whatever the definition is, that isn't it.
+
+
+
        [
+Peter adds:
+]
        
+
+
+
        
+
        
+Or, what is an "empty" shared_ptr?
+
        
+
+
          
+
        • 
+
          
+Are any other shared_ptrs empty?
+
          
+
          
+Yes. Whether a given shared_ptr instance is empty or not is (*)
+completely specified by the last mutating operation on that instance.
+Give me an example and I'll tell you whether the shared_ptr is empty or
+not.
+
          
+
          
+(*) If it isn't, this is a legitimate defect.
+
          
+
          • 
+
+
        • 
+
          
+For example, is shared_ptr((T*) 0) empty?
+
          
+
          
+No. If it were empty, it would have a use_count() of 0, whereas it is
+specified to have an use_count() of 1.
+
          
+
          • 
+
+
        • 
+
          
+What are the properties of an empty shared_ptr?
+
          
+
          
+The properties of an empty shared_ptr can be derived from the
+specification. One example is that its destructor is a no-op. Another is
+that its use_count() returns 0. I can enumerate the full list if you
+really like.
+
          
+
          • 
+
+
        • 
+
          
+We should either clarify this term or stop using it.
+
          
+
          
+I don't agree with the imperative tone
+
          
+
          
+A clarification would be either a no-op - if it doesn't contradict the
+existing wording - or a big mistake if it does.
+
          
+
          
+I agree that a clarification that is formally a no-op may add value.
+
          
+
          • 
+
+
        • 
+
          
+However, that term is nowhere defined.
+
          
+
          
+Terms can be useful without a definition. Consider the following
+simplistic example. We have a type X with the following operations
+defined:
+
          
+
          X x;
+X x2(x);
+X f(X x);
+X g(X x1, X x2);
+
          
+
          
+A default-constructed value is green.
          
+A copy has the same color as the original.
          
+f(x) returns a red value if the argument is green, a green value otherwise.
          
+g(x1,x2) returns a green value if the arguments are of the same color, a red value otherwise.
+
          
+
+
          
+Given these definitions, you can determine the color of every instance
+of type X, even if you have absolutely no idea what green and red mean.
+
          
+
+
          
+Green and red are "nowhere defined" and completely defined at the same time.
+
          
+
          • 
+
        
+
+
        
+Alisdair's wording is fine.
+
        
+
        
+
+
+
        Proposed resolution:
        
+
        
+Append the following sentance to 20.8.13.2 [util.smartptr.shared]
+
        
+
        
+The shared_ptr class template stores a pointer, usually obtained
+via new. shared_ptr implements semantics of
+shared ownership; the last remaining owner of the pointer is responsible for
+destroying the object, or otherwise releasing  the resources associated with
+the stored pointer. A shared_ptr object that does not own
+a pointer is said to be empty.
+
        
+
+
+
+
+
+
        
+
        818. wording for memory ordering
        
+
        Section: 29.3 [atomics.order] Status: CD1
+ Submitter: Jens Maurer Opened: 2008-03-22  Last modified: 2008-09-26
        
+
        View all other issues in [atomics.order].
        
+
        View all issues with CD1 status.
        
+
        Discussion:
        
+
        
+29.3 [atomics.order] p1 says in the table that
+
        
+
+
        
+
+
+
+
+
+
+
+
+
        ElementMeaning
        memory_order_acq_relthe operation has both acquire and release semantics
        
+
        
+
+
        
+To my naked eye, that seems to imply that even an atomic read has both
+acquire and release semantics.
+
        
+
+
        
+Then, p1 says in the table:
+
        
+
+
        
+
+
+
+
+
+
+
+
+
        ElementMeaning
        memory_order_seq_cstthe operation has both acquire and release semantics,
+    and, in addition, has sequentially-consistent operation ordering
        
+
        
+
+
        
+So that seems to be "the same thing" as memory_order_acq_rel, with additional
+constraints.
+
        
+
+
        
+I'm then reading p2, where it says:
+
        
+
+
        
+The memory_order_seq_cst operations that load a value are acquire operations
+on the affected locations. The memory_order_seq_cst operations that store a value
+are release operations on the affected locations.
+
        
+
+
        
+That seems to imply that atomic reads only have acquire semantics.  If that
+is intended, does this also apply to memory_order_acq_rel and the individual
+load/store operations as well?
+
        
+
+
        
+Also, the table in p1 contains phrases with "thus" that seem to indicate
+consequences of normative wording in 1.10 [intro.multithread].  That shouldn't be in
+normative text, for the fear of redundant or inconsistent specification with
+the other normative text.
+
        
+
+
        
+Double-check 29.6 [atomics.types.operations] that each
+operation clearly says whether it's a load or a store operation, or
+both.  (It could be clearer, IMO.  Solution not in current proposed resolution.)
+
        
+
+
        
+29.3 [atomics.order] p2:  What's a "consistent execution"?  It's not defined in
+1.10 [intro.multithread], it's just used in notes there.
+
        
+
+
        
+And why does 29.6 [atomics.types.operations] p9 for "load" say:
+
        
+
+
+
        
+Requires: The order argument shall not be memory_order_acquire
+nor memory_order_acq_rel.
+
        
+
+
        
+(Since this is exactly the same restriction as for "store", it seems to be a typo.)
+
        
+
+
        
+And then: 29.6 [atomics.types.operations] p12:
+
        
+
+
        
+These operations are read-modify-write operations in the sense of the
+"synchronizes with" definition (1.10 [intro.multithread]), so both such an operation and the
+evaluation that produced the input value synchronize with any evaluation
+that reads the updated value.
+
        
+
+
        
+This is redundant with 1.10 [intro.multithread], see above for the reasoning.
+
        
+
+
        [
+San Francisco:
+]
        
+
+
+
        
+
        
+Boehm: "I don't think that this changes anything terribly substantive,
+but it improves the text."
+
        
+
        
+Note that "Rephrase the table in as [sic] follows..." should read
+"Replace the table in [atomics.order] with the following...."
+
        
+
        
+The proposed resolution needs more work. Crowl volunteered to address
+all of the atomics issues in one paper.
+
        
+
+
        
+This issue is addressed in
+N2783.
+
        
+
        
+
+
+
        Proposed resolution:
        
+
        
+edit 29.3 [atomics.order], paragraph 1 as follows.
+
        
+
+
        
+
        
+The enumeration memory_order
+specifies the detailed regular (non-atomic) memory synchronization order
+as defined in Clause 1.7 section 1.10
+and may provide for operation ordering.
+Its enumerated values and their meanings are as follows:
+
        
+
        
+
        
+
        For memory_order_relaxed,
        
+
        no operation orders memory.
        
+
        For memory_order_release,
+memory_order_acq_rel,
+and memory_order_seq_cst,
        
+
        a store operation performs a release operation
+on the affected memory location.
        
+
        For memory_order_consume,
        
+
        a load operation performs a consume operation
+on the affected memory location.
        
+
        For memory_order_acquire,
+memory_order_acq_rel,
+and memory_order_seq_cst,
        
+
        a load operation performs an acquire operation
+on the affected memory location.
        
+
        
+
        
+
        
+
+
        
+remove table 136 in 29.3 [atomics.order].
+
        
+
+
        
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
        Table 136 — memory_order effects
        ElementMeaning
        memory_order_relaxedthe operation does not order memory
        memory_order_releasethe operation
+performs a release operation on the affected memory location,
+thus making regular memory writes visible to other threads
+through the atomic variable to which it is applied
        memory_order_acquirethe operation
+performs an acquire operation on the affected memory location,
+thus making regular memory writes in other threads
+released through the atomic variable to which it is applied
+visible to the current thread
        memory_order_consumethe operation
+performs a consume operation on the affected memory location,
+thus making regular memory writes in other threads
+released through the atomic variable to which it is applied
+visible to the regular memory reads
+that are dependencies of this consume operation.
        memory_order_acq_relthe operation has both acquire and release semantics
        memory_order_seq_cstthe operation has both acquire and release semantics,
+and, in addition, has sequentially-consistent operation ordering
        
+
        
+
+
        
+edit 29.3 [atomics.order], paragraph 2 as follows.
+
        
+
+
        
+
        
+The memory_order_seq_cst operations that load a value
+are acquire operations on the affected locations.
+The memory_order_seq_cst operations that store a value
+are release operations on the affected locations.
+In addition, in a consistent execution,
+there There must be is
+a single total order S
+on all memory_order_seq_cst operations,
+consistent with the happens before order
+and modification orders for all affected locations,
+such that each memory_order_seq_cst operation
+observes either the last preceding modification
+according to this order S,
+or the result of an operation that is not memory_order_seq_cst.
+[Note:
+Although it is not explicitly required that S include locks,
+it can always be extended to an order
+that does include lock and unlock operations,
+since the ordering between those
+is already included in the happens before ordering.
+—end note]
+
        
+
        
+
+
+
+
+
+
+
        
+
        820. current_exception()'s interaction with throwing copy ctors
        
+
        Section: 18.8.5 [propagation] Status: CD1
+ Submitter: Stephan T. Lavavej Opened: 2008-03-26  Last modified: 2008-09-26
        
+
        View other active issues in [propagation].
        
+
        View all other issues in [propagation].
        
+
        View all issues with CD1 status.
        
+
        Discussion:
        
+
        
+As of N2521, the Working Paper appears to be silent about what
+current_exception() should do if it tries to copy the currently handled
+exception and its copy constructor throws.  18.8.5 [propagation]/7 says "If the
+function needs to allocate memory and the attempt fails, it returns an
+exception_ptr object that refers to an instance of bad_alloc.", but
+doesn't say anything about what should happen if memory allocation
+succeeds but the actual copying fails.
+
        
+
+
        
+I see three alternatives: (1) return an exception_ptr object that refers
+to an instance of some fixed exception type, (2) return an exception_ptr
+object that refers to an instance of the copy ctor's thrown exception
+(but if that has a throwing copy ctor, an infinite loop can occur), or
+(3) call terminate().
+
        
+
+
        
+I believe that terminate() is the most reasonable course of action, but
+before we go implement that, I wanted to raise this issue.
+
        
+
+
        [
+Peter's summary:
+]
        
+
+
+
        
+
        
+The current practice is to not have throwing copy constructors in
+exception classes, because this can lead to terminate() as described in
+15.5.1 [except.terminate]. Thus calling terminate() in this situation seems
+consistent and does not introduce any new problems.
+
        
+
+
        
+However, the resolution of core issue 475 may relax this requirement:
+
        
+
+
        
+The CWG agreed with the position that std::uncaught_exception() should
+return false during the copy to the exception object and that std::terminate()
+should not be called if that constructor exits with an exception.
+
        
+
+
        
+Since throwing copy constructors will no longer call terminate(), option
+(3) doesn't seem reasonable as it is deemed too drastic a response in a
+recoverable situation.
+
        
+
+
        
+Option (2) cannot be adopted by itself, because a potential infinite
+recursion will need to be terminated by one of the other options.
+
        
+
+
        
+
+
+
        Proposed resolution:
        
+
        
+Add the following paragraph after 18.8.5 [propagation]/7:
+
        
+
+
        
+
        
+Returns (continued): If the attempt to copy the current exception
+object throws an exception, the function returns an exception_ptr that
+refers to the thrown exception or, if this is not possible, to an
+instance of bad_exception.
+
        
+
        
+[Note: The copy constructor of the thrown exception may also fail, so
+the implementation is allowed to substitute a bad_exception to avoid
+infinite recursion. -- end note.]
+
        
+
        
+
+
+
+
        Rationale:
        
+
        [
+San Francisco:
+]
        
+
+
+
        
+
        
+Pete: there may be an implied assumption in the proposed wording that
+current_exception() copies the existing exception object; the
+implementation may not actually do that.
+
        
+
        
+Pete will make the required editorial tweaks to rectify this.
+
        
+
        
+
+
+
+
+
+
        
+
        821. Minor cleanup : unique_ptr
        
+
        Section: 20.8.12.3.3 [unique.ptr.runtime.modifiers] Status: WP
+ Submitter: Alisdair Meredith Opened: 2008-03-30  Last modified: 2009-03-09
        
+
        View all issues with WP status.
        
+
        Discussion:
        
+
        
+Reading resolution of LWG issue 673 I noticed the following:
+
        
+
+
        
+
        void reset(T* pointer p = 0 pointer());
+
        
+
+
        
+-1- Requires: Does not accept pointer types which are convertible
+to T* pointer (diagnostic
+required). [Note: One implementation technique is to create a private
+templated overload. -- end note]
+
        
+
        
+
+
        
+This could be cleaned up by mandating the overload as a public deleted
+function.  In addition, we should probably overload reset on nullptr_t
+to be a stronger match than the deleted overload. Words...
+
        
+
+
+
        Proposed resolution:
        
+
        
+Add to class template definition in 20.8.12.3 [unique.ptr.runtime]
+
        
+
+
        
+
        // modifiers 
+pointer release(); 
+void reset(pointer p = pointer()); 
+void reset( nullptr_t );
+template< typename U > void reset( U ) = delete;
+void swap(unique_ptr&& u);
+
        
+
        
+
+
        
+Update 20.8.12.3.3 [unique.ptr.runtime.modifiers]
+
        
+
+
        
+
        void reset(pointer p = pointer());
+void reset(nullptr_t);
+
        
+
+
        
+-1- Requires: Does not accept pointer types which are convertible
+to pointer (diagnostic
+required). [Note: One implementation technique is to create a private
+templated overload. -- end note]
+
        
+
        
+Effects: If get() == nullptr there are no effects. Otherwise get_deleter()(get()). 
+
        
+
        ...
        
+
        
+
+
        [
+Note this wording incorporates resolutions for 806 (New) and 673 (Ready).
+]
        
+
+
+
+
+
+
+
        
+
        823. identity<void> seems broken
        
+
        Section: 20.3.2 [forward] Status: CD1
+ Submitter: Walter Brown Opened: 2008-04-09  Last modified: 2008-09-26
        
+
        View all other issues in [forward].
        
+
        View all issues with CD1 status.
        
+
        Discussion:
        
+
        
+N2588 seems to have added an operator() member function to the
+identity<> helper in 20.3.2 [forward].  I believe this change makes it no
+longer possible to instantiate identity<void>, as it would require
+forming a reference-to-void type as this operator()'s parameter type.
+
        
+
+
        
+Suggested resolution:  Specialize identity<void> so as not to require
+the member function's presence.
+
        
+
+
        [
+Sophia Antipolis:
+]
        
+
+
+
        
+
        
+Jens: suggests to add a requires clause to avoid specializing on void.
+
        
+
        
+Alisdair: also consider cv-qualified void.
+
        
+
        
+Alberto provided proposed wording.
+
        
+
        
+
+
+
        Proposed resolution:
        
+
        
+Change definition of identity in 20.3.2 [forward], paragraph 2, to:
+
        
+
+
        template <class T>  struct identity {
+    typedef T type;
+
+    requires ReferentType<T>
+      const T& operator()(const T& x) const;
+  };
+
        
+
        ...
        
+
          requires ReferentType<T>
+    const T& operator()(const T& x) const;
+
        
+
+
+
        Rationale:
        
+
        
+The point here is to able to write T& given T and ReferentType is
+precisely the concept that guarantees so, according to N2677
+(Foundational concepts). Because of this, it seems preferable than an
+explicit check for cv void using SameType/remove_cv as it was suggested
+in Sophia. In particular, Daniel remarked that there may be types other
+than cv void which aren't referent types (int[], perhaps?).
+
        
+
+
+
+
+
+
        
+
        824. rvalue ref issue with basic_string inserter
        
+
        Section: 21.4.8.9 [string.io] Status: CD1
+ Submitter: Alisdair Meredith Opened: 2008-04-10  Last modified: 2008-09-26
        
+
        View all other issues in [string.io].
        
+
        View all issues with CD1 status.
        
+
        Discussion:
        
+
        
+In the current working paper, the <string> header synopsis at the end of
+21.3 [string.classes] lists a single operator<< overload
+for basic_string.
+
        
+
+
        template<class charT, class traits, class Allocator>
+ basic_ostream<charT, traits>&
+   operator<<(basic_ostream<charT, traits>&& os,
+              const basic_string<charT,traits,Allocator>& str);
+
        
+
+
        
+The definition in 21.4.8.9 [string.io] lists two:
+
        
+
+
        template<class charT, class traits, class Allocator>
+ basic_ostream<charT, traits>&
+   operator<<(basic_ostream<charT, traits>& os,
+              const basic_string<charT,traits,Allocator>& str);
+
+template<class charT, class traits, class Allocator>
+ basic_ostream<charT, traits>&
+   operator<<(basic_ostream<charT, traits>&& os,
+              const basic_string<charT,traits,Allocator>& str);
+
        
+
+
        
+I believe the synopsis in 21.3 [string.classes] is correct, and the first of the two
+signatures in 21.4.8.9 [string.io] should be deleted.
+
        
+
+
+
        Proposed resolution:
        
+
        
+Delete the first of the two signatures in 21.4.8.9 [string.io]:
+
        
+
+
        template<class charT, class traits, class Allocator>
+ basic_ostream<charT, traits>&
+   operator<<(basic_ostream<charT, traits>& os,
+              const basic_string<charT,traits,Allocator>& str);
+
+template<class charT, class traits, class Allocator>
+ basic_ostream<charT, traits>&
+   operator<<(basic_ostream<charT, traits>&& os,
+              const basic_string<charT,traits,Allocator>& str);
+
        
+
+
+
+
+
+
        
+
        829. current_exception wording unclear about exception type
        
+
        Section: 18.8.5 [propagation] Status: CD1
+ Submitter: Beman Dawes Opened: 2008-04-20  Last modified: 2008-09-26
        
+
        View other active issues in [propagation].
        
+
        View all other issues in [propagation].
        
+
        View all issues with CD1 status.
        
+
        Discussion:
        
+
        Consider this code:
        
+
+
        
+
        exception_ptr xp;
        
+
        try {do_something(); }
+
+catch (const runtime_error& ) {xp = current_exception();}
+
+...
+
+rethrow_exception(xp);
        
+
        
+
+
        
+Say do_something() throws an exception object of type 
+range_error. What is the type of the exception object thrown by 
+rethrow_exception(xp) above? It must have a type of range_error; 
+if it were of type runtime_error it still isn't possible to 
+propagate an exception and the exception_ptr/current_exception/rethrow_exception 
+machinery serves no useful purpose.
+
        
+
+
        
+Unfortunately, the current wording does not explicitly say that. Different 
+people read the current wording and come to different conclusions. While it may 
+be possible to deduce the correct type from the current wording, it would be 
+much clearer to come right out and explicitly say what the type of the referred 
+to exception is.
+
        
+
+
        [
+Peter adds:
+]
        
+
+
+
        
+
        
+I don't like the proposed resolution of 829. The normative text is
+unambiguous that the exception_ptr refers to the currently handled
+exception. This term has a standard meaning, see 15.3 [except.handle]/8; this is the
+exception that throw; would rethrow, see 15.1 [except.throw]/7.
+
        
+
        
+A better way to address this is to simply add the non-normative example
+in question as a clarification. The term currently handled exception
+should be italicized and cross-referenced. A [Note: the currently
+handled exception is the exception that a throw expression without an
+operand (15.1 [except.throw]/7) would rethrow. --end note] is also an option.
+
        
+
        
+
+
+
+
        Proposed resolution:
        
+
+
        
+After 18.8.5 [propagation] , paragraph 7, add the indicated text:
+
        
+
+
        
+
        exception_ptr current_exception();
        
+
+
        
+
        
+Returns: exception_ptr object that refers 
+to the currently handled exception (15.3 [except.handle]) or a copy of the currently handled 
+exception, or a null exception_ptr object if no exception is being handled. If 
+the function needs to allocate memory and the attempt fails, it returns an
+exception_ptr object that refers to an instance of bad_alloc. 
+It is unspecified whether the return values of two successive calls to
+current_exception refer to the same exception object. 
+[Note: that is, it 
+is unspecified whether current_exception
+creates a new copy each time it is called.
+-- end note]
+
        
+
+
        
+Throws: nothing.
+
        
+
+
        
+
        
+
+
+
+
+
+
+
        
+
        842. ConstructibleAsElement and bit containers
        
+
        Section: 23.2 [container.requirements], 23.3.7 [vector.bool], 20.3.6 [template.bitset] Status: CD1
+ Submitter: Howard Hinnant Opened: 2008-06-03  Last modified: 2008-09-26
        
+
        View other active issues in [container.requirements].
        
+
        View all other issues in [container.requirements].
        
+
        View all issues with CD1 status.
        
+
        Discussion:
        
+
        
+23.2 [container.requirements]/p3 says:
+
        
+
+
        
+Objects stored in these components shall be constructed using
+construct_element (20.6.9). For each operation that inserts an
+element of type T into a container (insert,
+push_back, push_front, emplace, etc.) with
+arguments args... T shall be ConstructibleAsElement,
+as described in table 88. [Note: If the component is instantiated
+with a scoped allocator of type A (i.e., an allocator for which
+is_scoped_allocator<A>::value is true), then
+construct_element may pass an inner allocator argument to
+T's constructor. -- end note]
+
        
+
+
        
+However vector<bool, A> (23.3.7 [vector.bool]) and bitset<N> 
+(20.3.6 [template.bitset]) store bits, not bools, and bitset<N>
+does not even have an allocator.  But these containers are governed by this clause.  Clearly this
+is not implementable.
+
        
+
+
+
        Proposed resolution:
        
+
        
+Change 23.2 [container.requirements]/p3:
+
        
+
+
        
+Objects stored in these components shall be constructed using
+construct_element (20.6.9), unless otherwise specified.
+For each operation that inserts an
+element of type T into a container (insert,
+push_back, push_front, emplace, etc.) with
+arguments args... T shall be ConstructibleAsElement,
+as described in table 88. [Note: If the component is instantiated
+with a scoped allocator of type A (i.e., an allocator for which
+is_scoped_allocator<A>::value is true), then
+construct_element may pass an inner allocator argument to
+T's constructor. -- end note]
+
        
+
+
        
+Change 23.3.7 [vector.bool]/p2:
+
        
+
+
        
+Unless described below, all operations have the same requirements and semantics as the primary vector template, 
+except that operations dealing with the bool value type map to bit values in the container storage,
+and construct_element (23.2 [container.requirements]) is not used to construct these values.
+
        
+
+
        
+Move 20.3.6 [template.bitset] to clause 20.
+
        
+
+
+
+
+
+
+
        
+
        843.  Reference Closure
        
+
        Section: 20.7.18.1 [func.referenceclosure.cons] Status: CD1
+ Submitter: Lawrence Crowl Opened: 2008-06-02  Last modified: 2008-09-26
        
+
        View all issues with CD1 status.
        
+
        Discussion:
        
+
        
+The std::reference_closure type has a deleted copy assignment operator
+under the theory that references cannot be assigned, and hence the
+assignment of its reference member must necessarily be ill-formed.
+
        
+
        
+However, other types, notably std::reference_wrapper and std::function
+provide for the "copying of references", and thus the current definition
+of std::reference_closure seems unnecessarily restrictive.  In particular,
+it should be possible to write generic functions using both std::function
+and std::reference_closure, but this generality is much harder when
+one such type does not support assignment.
+
        
+
        
+The definition of reference_closure does not necessarily imply direct
+implementation via reference types.  Indeed, the reference_closure is
+best implemented via a frame pointer, for which there is no standard
+type.
+
        
+
        
+The semantics of assignment are effectively obtained by use of the
+default destructor and default copy assignment operator via
+
        
+
+
        x.~reference_closure(); new (x) reference_closure(y);
+
        
+
+
        
+So the copy assignment operator generates no significant real burden
+to the implementation.
+
        
+
+
+
        Proposed resolution:
        
+
        
+In 20.7.18 [func.referenceclosure] Class template reference_closure,
+replace the =delete in the copy assignment operator in the synopsis
+with =default.
+
        
+
+
        template<class R , class... ArgTypes > 
+  class reference_closure<R (ArgTypes...)> { 
+  public:
+     ...
+     reference_closure& operator=(const reference_closure&) = delete default;
+     ...
+
        
+
+
        
+In 20.7.18.1 [func.referenceclosure.cons] Construct, copy, destroy,
+add the member function description
+
        
+
+
        
+
        reference_closure& operator=(const reference_closure& f)
+
        
+
        
+
        
+Postcondition: *this is a copy of f.
+
        
+
        
+Returns: *this.
+
        
+
        
+
        
+
+
+
+
+
+
+
+
        
+
        844. complex pow return type is ambiguous
        
+
        Section: 26.4.9 [cmplx.over] Status: CD1
+ Submitter: Howard Hinnant Opened: 2008-06-03  Last modified: 2009-03-21
        
+
        View all other issues in [cmplx.over].
        
+
        View all issues with CD1 status.
        
+
        Discussion:
        
+
        
+The current working draft is in an inconsistent state.
+
        
+
+
        
+26.4.8 [complex.transcendentals] says that:
+
        
+
+
        
+pow(complex<float>(), int()) returns a complex<float>.
+
        
+
+
        
+26.4.9 [cmplx.over] says that:
+
        
+
+
        
+pow(complex<float>(), int()) returns a complex<double>.
+
        
+
+
        [
+Sophia Antipolis:
+]
        
+
+
+
        
+
        
+Since int promotes to double, and C99 doesn't have an int-based
+overload for pow, the C99 result is complex<double>, see also C99
+7.22, see also library issue 550.
+
        
+
        
+Special note: ask P.J. Plauger.
+
        
+
        
+Looks fine.
+
        
+
        
+
+
+
        Proposed resolution:
        
+
        
+Strike this pow overload in 26.4.1 [complex.syn] and in 26.4.8 [complex.transcendentals]:
+
        
+
+
        template<class T> complex<T> pow(const complex<T>& x, int y);
+
        
+
+
+
+
+
+
        
+
        845. atomics cannot support aggregate initialization
        
+
        Section: 29.5 [atomics.types] Status: CD1
+ Submitter: Alisdair Meredith Opened: 2008-06-03  Last modified: 2008-09-26
        
+
        View all other issues in [atomics.types].
        
+
        View all issues with CD1 status.
        
+
        Discussion:
        
+
        
+The atomic classes (and class templates) are required to support aggregate
+initialization (29.5.1 [atomics.types.integral]p2 / 29.5.2 [atomics.types.address]p1)
+yet also have user declared constructors, so cannot be aggregates.
+
        
+
        
+This problem might be solved with the introduction of the proposed
+initialization syntax at Antipolis, but the wording above should be altered.
+Either strike the sentence as redundant with new syntax, or refer to 'brace
+initialization'.
+
        
+
+
        [
+Jens adds:
+]
        
+
+
+
        
+
        
+Note that
+
        
+
        atomic_itype a1 = { 5 };
+
        
+
        
+would be aggregate-initialization syntax (now coming under the disguise
+of brace initialization), but would be ill-formed, because the corresponding
+constructor for atomic_itype is explicit.  This works, though:
+
        
+
        atomic_itype a2 { 6 };
+
        
+
+
        
+
+
        [
+San Francisco:
+]
        
+
+
+
        
+
        
+The preferred approach to resolving this is to remove the explicit
+specifiers from the atomic integral type constructors.
+
        
+
        
+Lawrence will provide wording.
+
        
+
        
+This issue is addressed in
+N2783.
+
        
+
        
+
+
+
+
        Proposed resolution:
        
+
        
+within the synopsis in 29.5.1 [atomics.types.integral] edit as follows.
+
        
+
+
        
+....
+typedef struct atomic_bool {
+....
+  constexpr explicit atomic_bool(bool);
+....
+typedef struct atomic_itype {
+....
+  constexpr explicit atomic_itype(integral);
+....
+
        
+
+
        
+edit 29.5.1 [atomics.types.integral] paragraph 2 as follows.
+
        
+
+
        
+The atomic integral types shall have standard layout.
+They shall each have a trivial default constructor,
+a constexpr explicit value constructor,
+a deleted copy constructor,
+a deleted copy assignment operator,
+and a trivial destructor.
+They shall each support aggregate initialization syntax.
+
        
+
+
        
+within the synopsis of 29.5.2 [atomics.types.address] edit as follows.
+
        
+
+
        
+....
+typedef struct atomic_address {
+....
+  constexpr explicit atomic_address(void*);
+....
+
        
+
+
        
+edit 29.5.2 [atomics.types.address] paragraph 1 as follows.
+
        
+
+
        
+The type atomic_address shall have standard layout.
+It shall have a trivial default constructor,
+a constexpr explicit value constructor,
+a deleted copy constructor,
+a deleted copy assignment operator,
+and a trivial destructor.
+It shall support aggregate initialization syntax.
+
        
+
+
        
+within the synopsis of 29.5.3 [atomics.types.generic] edit as follows.
+
        
+
+
        
+....
+template <class T> struct atomic {
+....
+  constexpr explicit atomic(T);
+....
+template <> struct atomic<integral> : atomic_itype {
+....
+  constexpr explicit atomic(integral);
+....
+template <> struct atomic<T*> : atomic_address {
+....
+  constexpr explicit atomic(T*);
+....
+
        
+
+
        
+edit 29.5.3 [atomics.types.generic] paragraph 2 as follows.
+
        
+
+
        
+Specializations of the atomic template
+shall have a deleted copy constructor,
+a deleted copy assignment operator,
+and a constexpr explicit value constructor.
+
        
+
+
+
+
+
+
+
        
+
        846. No definition for constructor
        
+
        Section: 29.5 [atomics.types] Status: CD1
+ Submitter: Alisdair Meredith Opened: 2008-06-03  Last modified: 2008-09-26
        
+
        View all other issues in [atomics.types].
        
+
        View all issues with CD1 status.
        
+
        Discussion:
        
+
        
+The atomic classes and class templates (29.5.1 [atomics.types.integral] /
+29.5.2 [atomics.types.address]) have a constexpr
+constructor taking a value of the appropriate type for that atomic.
+However, neither clause provides semantics or a definition for this
+constructor.  I'm not sure if the initialization is implied by use of
+constexpr keyword (which restricts the form of a constructor) but even if
+that is the case, I think it is worth spelling out explicitly as the
+inference would be far too subtle in that case.
+
        
+
+
        [
+San Francisco:
+]
        
+
+
+
        
+
        
+Lawrence will provide wording.
+
        
+
        
+This issue is addressed in
+N2783.
+
        
+
        
+
+
+
        Proposed resolution:
        
+
+
        
+before the description of ...is_lock_free,
+that is before 29.6 [atomics.types.operations] paragraph 4,
+add the following description.
+
        
+
+
        
+
        
+constexpr A::A(C desired);
+
        
+
        
+
        Effects:
        
+
        
+Initializes the object with the value desired.
+[Note:
+Construction is not atomic.
+—end note]
+
        
+
        
+
        
+
+
+
+
+
+
        
+
        848. missing std::hash specializations for std::bitset/std::vector<bool>
        
+
        Section: 20.7.17 [unord.hash] Status: CD1
+ Submitter: Thorsten Ottosen Opened: 2008-06-05  Last modified: 2008-09-26
        
+
        View other active issues in [unord.hash].
        
+
        View all other issues in [unord.hash].
        
+
        View all issues with CD1 status.
        
+
        Discussion:
        
+
        
+In the current working draft, std::hash<T> is specialized for builtin
+types and a few other types. Bitsets seems like one that is missing from
+the list, not because it cannot not be done by the user, but because it
+is hard or impossible to write an efficient implementation that works on
+32bit/64bit chunks at a time. For example, std::bitset is too much
+encapsulated in this respect.
+
        
+
+
+
        Proposed resolution:
        
+
        
+Add the following to the synopsis in 20.7 [function.objects]/2:
+
        
+
+
        template<class Allocator> struct hash<std::vector<bool,Allocator>>;
+template<size_t N> struct hash<std::bitset<N>>;
+
        
+
+
        
+Modify the last sentence of 20.7.17 [unord.hash]/1 to end with:
+
        
+
+
        
+... and std::string, std::u16string, std::u32string, std::wstring,
+std::error_code, std::thread::id, std::bitset, and std::vector<bool>.
+
        
+
+
+
+
+
+
+
        
+
        850. Should shrink_to_fit apply to std::deque?
        
+
        Section: 23.3.2.2 [deque.capacity] Status: CD1
+ Submitter: Niels Dekker Opened: 2008-06-05  Last modified: 2008-09-26
        
+
        View all other issues in [deque.capacity].
        
+
        View all issues with CD1 status.
        
+
        Discussion:
        
+
        
+Issue 755 added a shrink_to_fit function to std::vector and std::string.
+It did not yet deal with std::deque, because of the fundamental
+difference between std::deque and the other two container types. The
+need for std::deque may seem less evident, because one might think that
+for this container, the overhead is a small map, and some number of
+blocks that's bounded by a small constant.
+
        
+
        
+The container overhead can in fact be arbitrarily large (i.e. is not
+necessarily O(N) where N is the number of elements currently held by the
+deque).  As Bill Plauger noted in a reflector message, unless the map of
+block pointers is shrunk, it must hold at least maxN/B pointers where
+maxN is the maximum of N over the lifetime of the deque since its
+creation.  This is independent of how the map is implemented
+(vector-like circular buffer and all), and maxN bears no relation to N,
+the number of elements it currently holds.
+
        
+
        
+Hervé Brönnimann reports a situation where a deque of requests grew very
+large due to some temporary backup (the front request hanging), and the
+map of the deque grew quite large before getting back to normal.  Just
+to put some color on it, assuming a deque with 1K pointer elements in
+steady regime, that held, at some point in its lifetime, maxN=10M
+pointers, with one block holding 128 elements, the spine must be at
+least (maxN / 128), in that case 100K.   In that case, shrink-to-fit
+would allow to reuse about 100K which would otherwise never be reclaimed
+in the lifetime of the deque.
+
        
+
        
+An added bonus would be that it *allows* implementations to hang on to
+empty blocks at the end (but does not care if they do or not).  A
+shrink_to_fit would take care of both shrinks, and guarantee that at
+most O(B) space is used in addition to the storage to hold the N
+elements and the N/B block pointers.
+
        
+
+
+
        Proposed resolution:
        
+
        
+To Class template deque 23.3.2 [deque] synopsis, add:
+
        
+
        void shrink_to_fit();
+
        
+
+
        
+To deque capacity 23.3.2.2 [deque.capacity], add:
+
        
+
        void shrink_to_fit();
+
        
+
+
        
+Remarks: shrink_to_fit is a non-binding request to reduce memory
+use. [Note: The request is non-binding to allow latitude for
+implementation-specific optimizations. -- end note]
+
        
+
        
+
+
+
+
+
+
        
+
        852. unordered containers begin(n) mistakenly const
        
+
        Section: 23.5 [unord] Status: CD1
+ Submitter: Robert Klarer Opened: 2008-06-12  Last modified: 2008-09-26
        
+
        View all other issues in [unord].
        
+
        View all issues with CD1 status.
        
+
        Discussion:
        
+
        
+In 3 of the four unordered containers the local begin member is mistakenly declared const:
+
        
+
+
        local_iterator begin(size_type n) const;
+
        
+
+
+
        Proposed resolution:
        
+
        
+Change the synopsis in 23.5.1 [unord.map], 23.5.2 [unord.multimap], and 23.5.4 [unord.multiset]:
+
        
+
+
        local_iterator begin(size_type n) const;
+
        
+
+
+
+
+
+
        
+
        856. Removal of aligned_union
        
+
        Section: 20.6.7 [meta.trans.other] Status: CD1
+ Submitter: Jens Maurer Opened: 2008-06-12  Last modified: 2008-09-26
        
+
        View other active issues in [meta.trans.other].
        
+
        View all other issues in [meta.trans.other].
        
+
        View all issues with CD1 status.
        
+
        Discussion:
        
+
        
+With the arrival of extended unions 
+(N2544),
+there is no
+known use of aligned_union that couldn't be handled by
+the "extended unions" core-language facility.
+
        
+
+
+
        Proposed resolution:
        
+
        
+Remove the following signature from 20.6.2 [meta.type.synop]:
+
        
+
        template <std::size_t Len, class... Types> struct aligned_union;
+
        
+
+
        
+Remove the second row from table 51 in 20.6.7 [meta.trans.other],
+starting with:
+
        
+
+
        template <std::size_t Len,
+class... Types>
+struct aligned_union;
+
        
+
+
+
+
+
+
        
+
        858. Wording for Minimal Support for Garbage Collection
        
+
        Section: 20.8.13.7 [util.dynamic.safety] Status: CD1
+ Submitter: Pete Becker  Opened: 2008-06-21  Last modified: 2008-09-26
        
+
        View all other issues in [util.dynamic.safety].
        
+
        View all issues with CD1 status.
        
+
        Discussion:
        
+
        
+The first sentence of the Effects clause for undeclare_reachable seems
+to be missing some words. I can't parse
+
        
+
        
+... for all non-null p referencing the argument is no longer declared reachable...
+
        
+
        
+I take it the intent is that undeclare_reachable should be called only
+when there has been a corresponding call to declare_reachable. In
+particular, although the wording seems to allow it, I assume that code
+shouldn't call declare_reachable once then call undeclare_reachable
+twice.
+
        
+
        
+I don't know what "shall be live" in the Requires clause means.
+
        
+
        
+In the final Note for undeclare_reachable, what does "cannot be
+deallocated" mean? Is this different from "will not be able to collect"?
+
        
+
+
        
+For the wording on nesting of declare_reachable and
+undeclare_reachable, the words for locking and unlocking recursive
+mutexes probably are a good model.
+
        
+
+
        [
+San Francisco:
+]
        
+
+
+
        
+
        
+Nick: what does "shall be live" mean?
+
        
+
        
+Hans: I can provide an appropriate cross-reference to the Project Editor
+to clarify the intent.
+
        
+
        
+
+
+
        Proposed resolution:
        
+
        
+In 20.8.13.7 [util.dynamic.safety]
+(N2670,
+Minimal Support for Garbage Collection)
+
        
+
        
+Add at the beginning, before paragraph 39
+
        
+
+
        
+A complete object is declared reachable while the number of calls
+to declare_reachable with an argument referencing the object exceeds the
+number of undeclare_reachable calls with pointers to the same complete
+object.
+
        
+
+
        
+Change paragraph 42 (Requires clause for undeclare_reachable)
+
        
+
+
        
+If p is not null, declare_reachable(p) was previously called
+the complete object referenced by p shall have
+been previously declared reachable, and shall
+be live (3.8 [basic.life]) from the time of the call until the last undeclare_reachable(p)
+call on the object.
+
        
+
+
        
+Change the first sentence in paragraph 44 (Effects clause for
+undeclare_reachable):
+
        
+
+
        
+Effects: 
+Once the number of calls to
+undeclare_reachable(p) equals the number of calls to
+declare_reachable(p)
+for all non-null p referencing
+the argument is no longer declared reachable.  When this happens,
+pointers to the object referenced by p may not be subsequently
+dereferenced.
+
+After a call to undeclare_reachable(p), if p is not null and the object q
+referenced by p is no longer declared reachable, then
+dereferencing any pointer to q that is not safely derived
+results in undefined behavior.
+ ...
+
        
+
+
        
+Change the final note:
+
        
+
        
+[Note: It is expected that calls to declare_reachable(p)
+will consume a small amount of memory, in addition to that occupied
+by the referenced object,  until the matching call to
+undeclare_reachable(p) is encountered. In addition, the
+referenced object cannot be deallocated during this period, and garbage
+collecting implementations will not be able to collect the object while
+it is declared reachable. Long running programs should arrange
+that calls for short-lived objects are matched. --end
+note]
+
        
+
+
+
+
+
+
+
        
+
        866. Qualification of placement new-expressions
        
+
        Section: 20.8.11 [specialized.algorithms], 20.8.13.2.6 [util.smartptr.shared.create] Status: WP
+ Submitter: Alberto Ganesh Barbati Opened: 2008-07-14  Last modified: 2009-03-09
        
+
        View all other issues in [specialized.algorithms].
        
+
        View all issues with WP status.
        
+
        Discussion:
        
+
        
+LWG issue 402 replaced "new" with "::new" in the placement
+new-expression in 20.8.6.1 [allocator.members]. I believe the rationale
+given in 402 applies also to the following other contexts:
+
        
+
          
+
        • 
+
          
+in 20.8.11 [specialized.algorithms], all four algorithms unitialized_copy,
+unitialized_copy_n, unitialized_fill and unitialized_fill_n use
+the unqualified placement new-expression in some variation of the form:
+
          
+
          new  (static_cast<void*>(&*result)) typename  iterator_traits<ForwardIterator>::value_type(*first);
+
          
+
          • 
+
        • 
+
          
+in 20.8.13.2.6 [util.smartptr.shared.create] there is a reference to the unqualified placement new-expression:
+
          
+
          new  (pv)  T(std::forward<Args>(args)...),
+
          
+
          • 
+
        
+
        
+I suggest to add qualification in all those places. As far as I know,
+these are all the remaining places in the whole library that explicitly
+use a placement new-expression. Should other uses come out, they should
+be qualified as well.
+
        
+
        
+As an aside, a qualified placement new-expression does not need
+additional requirements to be compiled in a constrained context. By
+adding qualification, the HasPlacementNew concept introduced recently in
+N2677 (Foundational Concepts)
+would no longer be needed by library and
+should therefore be removed.
+
        
+
+
        [
+San Francisco:
+]
        
+
+
+
        
+Detlef: If we move this to Ready, it's likely that we'll forget about
+the side comment about the HasPlacementNew concept.
+
        
+
+
        [
+post San Francisco:
+]
        
+
+
+
        
+Daniel:  HasPlacementNew has been removed from
+N2774 (Foundational Concepts).
+
        
+
+
+
+
        Proposed resolution:
        
+
        
+Replace "new" with "::new" in:
+
        
+
          
+
        • 
+20.8.11.2 [uninitialized.copy], paragraphs 1 and 3
+
          • 
+
        • 
+20.8.11.3 [uninitialized.fill]  paragraph 1
+
          • 
+
        • 
+20.8.11.4 [uninitialized.fill.n] paragraph 1
+
          • 
+
        • 
+20.8.13.2.6 [util.smartptr.shared.create] once in paragraph 1 and twice in paragraph 2.
+
          • 
+
        
+
+
+
+
+
+
+
        
+
        882. duration non-member arithmetic requirements
        
+
        Section: 20.9.3.5 [time.duration.nonmember] Status: CD1
+ Submitter: Howard Hinnant Opened: 2008-09-08  Last modified: 2008-09-26
        
+
        View all other issues in [time.duration.nonmember].
        
+
        View all issues with CD1 status.
        
+
        Discussion:
        
+
        
+N2661
+specified the following requirements for the non-member duration
+arithmetic:
+
        
+
+
        
+
+
        template <class Rep1, class Period, class Rep2>
+  duration<typename common_type<Rep1, Rep2>::type, Period>
+  operator*(const duration<Rep1, Period>& d, const Rep2& s);
+
        
+
        
+Requires: Let CR represent the common_type of Rep1 and
+Rep2.  Both Rep1 and Rep2 shall be implicitly convertible
+to CR, diagnostic required.
+
        
+
+
        template <class Rep1, class Period, class Rep2>
+  duration<typename common_type<Rep1, Rep2>::type, Period>
+  operator*(const Rep1& s, const duration<Rep2, Period>& d);
+
        
+
+
        
+Requires: Let CR represent the common_type of
+Rep1 and Rep2. Both Rep1 and Rep2
+shall be implicitly convertible to CR, diagnostic required.
+
        
+
+
        template <class Rep1, class Period, class Rep2>
+  duration<typename common_type<Rep1, Rep2>::type, Period>
+  operator/(const duration<Rep1, Period>& d, const Rep2& s);
+
        
+
+
        
+Requires: Let CR represent the common_type of
+Rep1 and Rep2. Both Rep1 and Rep2 shall be
+implicitly convertible to CR, and Rep2 shall not be an
+instantiation of duration, diagnostic required.
+
        
+
+
        
+
+
        
+During transcription into the working paper, the requirements clauses on these
+three functions was changed to:
+
        
+
+
        
+Requires: CR(Rep1, Rep2) shall exist. Diagnostic required.
+
        
+
+
        
+This is a non editorial change with respect to
+N2661
+as user written representations which are used in duration need not be
+implicitly convertible to or from arithmetic types in order to interoperate with
+durations based on arithmetic types.  An explicit conversion will do
+fine for most expressions as long as there exists a common_type specialization
+relating the user written representation and the arithmetic type.  For example:
+
        
+
+
        class saturate
+{
+public:
+  explicit saturate(long long i);
+  ...
+};
+
+namespace std {
+
+template <>
+struct common_type<saturate, long long>
+{
+    typedef saturate type;
+};
+
+template <>
+struct common_type<long long, saturate>
+{
+    typedef saturate type;
+};
+
+}  // std
+
+millisecond ms(3);  // integral-based duration
+duration<saturate, milli> my_ms = ms;  // ok, even with explicit conversions
+my_ms = my_ms + ms;                    // ok, even with explicit conversions
+
        
+
+
        
+However, when dealing with multiplication of a duration and its representation,
+implicit convertibility is required between the rhs and the lhs's representation
+for the member *= operator:
+
        
+
+
        template <class Rep, class Period = ratio<1>> 
+class duration { 
+public: 
+   ...
+   duration& operator*=(const rep& rhs);
+   ...
+};
+...
+ms *= 2;               // ok, 2 is implicitly convertible to long long
+my_ms *= saturate(2);  // ok, rhs is lhs's representation
+my_ms *= 2;            // error, 2 is not implicitly convertible to saturate
+
        
+
+
        
+The last line does not (and should not) compile.  And we want non-member multiplication
+to have the same behavior as member arithmetic:
+
        
+
+
        my_ms = my_ms * saturate(2);  // ok, rhs is lhs's representation
+my_ms = my_ms * 2;            // should be error, 2 is not implicitly convertible to saturate
+
        
+
+
        
+The requirements clauses of
+N2661
+make the last line an error as expected.  However the latest working draft at
+this time
+(N2723)
+allows the last line to compile.
+
        
+
+
        
+All that being said, there does appear to be an error in these requirements clauses
+as specified by 
+N2661.
+
        
+
+
        
+Requires: ... Both Rep1 and Rep2 shall be implicitly convertible
+to CR, diagnostic required.
+
        
+
+
        
+It is not necessary for both Reps to be implicitly convertible to
+the CR.  It is only necessary for the rhs Rep to be implicitly
+convertible to the CR.  The Rep within the duration
+should be allowed to only be explicitly convertible to the CR.  The
+explicit-conversion-requirement is covered under 20.9.3.7 [time.duration.cast].
+
        
+
+
+
+
        Proposed resolution:
        
+
        
+Change the requirements clauses under 20.9.3.5 [time.duration.nonmember]:
+
        
+
+
        
+
+
        template <class Rep1, class Period, class Rep2>
+  duration<typename common_type<Rep1, Rep2>::type, Period>
+  operator*(const duration<Rep1, Period>& d, const Rep2& s);
+
        
+
+
        
+Requires: CR(Rep1, Rep2) shall exist.
+Rep2 shall be implicitly convertible to CR(Rep1, Rep2).
+Diagnostic required.
+
        
+
+
        template <class Rep1, class Period, class Rep2>
+  duration<typename common_type<Rep1, Rep2>::type, Period>
+  operator*(const Rep1& s, const duration<Rep2, Period>& d);
+
        
+
+
        
+Requiresd behavior: CR(Rep1, Rep2) shall exist.
+Rep1 shall be implicitly convertible to CR(Rep1, Rep2).
+Diagnostic required.
+
        
+
+
        template <class Rep1, class Period, class Rep2>
+  duration<typename common_type<Rep1, Rep2>::type, Period>
+  operator/(const duration<Rep1, Period>& d, const Rep2& s);
+
        
+
+
        
+Requires: CR(Rep1, Rep2) shall exist
+Rep2 shall be implicitly convertible to CR(Rep1, Rep2)
+and Rep2 shall not
+be an instantiation of duration. Diagnostic required.
+
        
+
+
        
+
+
+
+
+
+
        
+
        894. longjmp and destructors
        
+
        Section: 18.10 [support.runtime] Status: WP
+ Submitter: Lawrence Crowl, Alisdair Meredith Opened: 2008-09-17  Last modified: 2009-03-09
        
+
        View all other issues in [support.runtime].
        
+
        View all issues with WP status.
        
+
        Discussion:
        
+
        
+The interaction between longjmp and exceptions seems unnecessarily
+restrictive and not in keeping with existing practice.
+
        
+
+
+
        Proposed resolution:
        
+
        
+Edit paragraph 4 of 18.10 [support.runtime] as follows:
+
        
+
+
        
+The function signature longjmp(jmp_buf jbuf, int val) has more
+restricted behavior in this International Standard. A
+setjmp/longjmp call pair has undefined behavior if replacing the
+setjmp and longjmp by catch and
+throw would destroy
+invoke any non-trivial destructors for
+any automatic objects.
+
        
+
+
+
+
+
 
\ No newline at end of file
diff --git a/libstdc++-v3/doc/xml/manual/intro.xml b/libstdc++-v3/doc/xml/manual/intro.xml
index 9523195e2ba..560a0b54e9c 100644
--- a/libstdc++-v3/doc/xml/manual/intro.xml
+++ b/libstdc++-v3/doc/xml/manual/intro.xml
@@ -262,7 +262,7 @@ requirements of the license of GCC.
     Re-opening a file stream does not clear the state flags.
     
 
-    23:
+    23:
         Num_get overflow result
     
     Implement the proposed resolution.
@@ -461,7 +461,7 @@ requirements of the license of GCC.
         is specified in the conversion specification.
     
 
-    233:
+    233:
         Insertion hints in associative containers
     
     Implement N1780, first check before then check after, insert as close
@@ -576,7 +576,7 @@ requirements of the license of GCC.
     Add const overloads of is_open.
     
 
-    387:
+    387:
         std::complex over-encapsulated
     
     Add the real(T) and imag(T)
@@ -592,7 +592,7 @@ requirements of the license of GCC.
     Change it to return a const T&.
     
 
-    396:
+    396:
         what are characters zero and one
     
     Implement the proposed resolution.
@@ -723,7 +723,7 @@ requirements of the license of GCC.
     Add the missing operations.
     
 
-    691:
+    691:
         const_local_iterator cbegin, cend missing from TR1
     
     In C++0x mode add cbegin(size_type) and cend(size_type)
@@ -760,7 +760,7 @@ requirements of the license of GCC.
     Implement the int -> size_t replacements.
     
 
-    776:
+    776:
         Undescribed assign function of std::array
     
     In C++0x mode, remove assign, add fill.
@@ -772,13 +772,13 @@ requirements of the license of GCC.
     In C++0x mode, add std::proj.
     
 
-    809:
+    809:
         std::swap should be overloaded for array types
     
     Add the overload.
     
 
-    844:
+    844:
         complex pow return type is ambiguous
     
     In C++0x mode, remove the pow(complex<T>, int) signature.