From f4b18054750c51f01fa3bd61c4dc021050ecad3f Mon Sep 17 00:00:00 2001 From: paolo Date: Thu, 8 Nov 2007 10:19:57 +0000 Subject: [PATCH] 2007-11-08 Paolo Carlini * docs/html/ext/lwg-active.html: Update to Revision R52. * docs/html/ext/lwg-closed.html: Likewise. * docs/html/ext/lwg-defects.html: Likewise. * docs/html/ext/howto.html: Adjust. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@129994 138bc75d-0d04-0410-961f-82ee72b054a4 --- libstdc++-v3/ChangeLog | 7 + libstdc++-v3/docs/html/ext/howto.html | 2 +- libstdc++-v3/docs/html/ext/lwg-active.html | 9930 +++++++++++++++------------ libstdc++-v3/docs/html/ext/lwg-closed.html | 1141 ++- libstdc++-v3/docs/html/ext/lwg-defects.html | 2787 +++++++- 5 files changed, 9466 insertions(+), 4401 deletions(-) diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog index fd480597f31..4aa2237a570 100644 --- a/libstdc++-v3/ChangeLog +++ b/libstdc++-v3/ChangeLog @@ -1,3 +1,10 @@ +2007-11-08 Paolo Carlini + + * docs/html/ext/lwg-active.html: Update to Revision R52. + * docs/html/ext/lwg-closed.html: Likewise. + * docs/html/ext/lwg-defects.html: Likewise. + * docs/html/ext/howto.html: Adjust. + 2007-11-07 Paolo Carlini * include/tr1_impl/complex (fabs): In C++0x mode adjust diff --git a/libstdc++-v3/docs/html/ext/howto.html b/libstdc++-v3/docs/html/ext/howto.html index cb544aa24c0..e7f1f9a6e7a 100644 --- a/libstdc++-v3/docs/html/ext/howto.html +++ b/libstdc++-v3/docs/html/ext/howto.html @@ -626,7 +626,7 @@
Change it to be a formatted output function (i.e. catch exceptions).
-
660: +
660: Missing bitwise operations
Add the missing operations. diff --git a/libstdc++-v3/docs/html/ext/lwg-active.html b/libstdc++-v3/docs/html/ext/lwg-active.html index 8aec7335627..29e0d775bf3 100644 --- a/libstdc++-v3/docs/html/ext/lwg-active.html +++ b/libstdc++-v3/docs/html/ext/lwg-active.html @@ -1,22 +1,22 @@ C++ Standard Library Active Issues List + + - - +ins {background-color:#A0FFA0} +del {background-color:#FFA0A0} + - + - + @@ -27,7 +27,7 @@ del {background-color:#FFFFA0}
Doc. no.N2317=07-0177N2456=07-0326
Date:2007-06-242007-10-20
Project:Howard Hinnant <howard.hinnant@gmail.com>
-

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

+

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

Reference ISO/IEC IS 14882:1998(E)

Also see:

@@ -83,7 +83,7 @@ del {background-color:#FFFFA0}

Public information as to how to obtain a copy of the C++ Standard, join the standards committee, submit an issue, or comment on an issue can be found in the comp.std.c++ FAQ. - Public discussion of C++ Standard related issues occurs on news:comp.std.c++. + Public discussion of C++ Standard related issues occurs on news:comp.std.c++.

For committee members, files available on the committee's private @@ -94,6 +94,71 @@ del {background-color:#FFFFA0}

Revision History

@@ -197,7 +262,7 @@ del {background-color:#FFFFA0}
  • 592 issues total, up by 5.
  • Details:
    • @@ -227,8 +292,8 @@ del {background-color:#FFFFA0}
  • Details:
    • @@ -243,7 +308,7 @@ del {background-color:#FFFFA0}
  • 566 issues total, up by 31.
  • Details:
      -
    • Added new issues 536-566.
      • +
    • Added new issues 536-566.
    • Moved 342 from Ready to Open.
    • Reopened 309.
    • @@ -264,7 +329,7 @@ del {background-color:#FFFFA0}
  • R39: 2005-10-14 post-Mont Tremblant mailing. -Added new issues 526-528. +Added new issues 526-528. Moved issues 280, 461, 464, 465, 467, 468, 474, 496 from Ready to WP as per the vote from Mont Tremblant. Moved issues 247, 294, 342, 362, 369, 371, 376, 384, 475, 478, 495, 497 from Review to Ready. Moved issues 498, 504, 506, 509, 510, 511, 512, 513, 514 from New to Open. @@ -290,7 +355,7 @@ previously in "DR" status were moved to "WP". 2005-03 pre-Lillehammer mailing.
  • R34: -2005-01 mid-term mailing. Added new issues 488-494. +2005-01 mid-term mailing. Added new issues 488-494.
  • R33: 2004-11 post-Redmond mailing. Reflects actions taken in Redmond. @@ -703,10 +768,100 @@ upon overflow. We considered three options based on this:

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

    +
    +
    @@ -1364,7 +1519,6 @@ committee.

    342. seek and eofbit

    Section: 27.6.1.3 [istream.unformatted] Status: Open Submitter: Howard Hinnant Date: 2001-10-09

    -

    View other active issues in [istream.unformatted].

    View all other issues in [istream.unformatted].

    View all issues with Open status.

    Discussion:

    @@ -1830,7 +1984,6 @@ partial can only occur if (from_next != from_end)?

    387. std::complex over-encapsulated

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

    -

    View other active issues in [complex.numbers].

    View all other issues in [complex.numbers].

    View all issues with Open status.

    Discussion:

    @@ -1954,62 +2107,6 @@ existing implementations already have the layout proposed here.

    -

    393. do_in/do_out operation on state unclear

    -

    Section: 22.2.1.4.2 [locale.codecvt.virtuals] Status: New - Submitter: Alberto Barbati Date: 2002-12-24

    -

    View other active issues in [locale.codecvt.virtuals].

    -

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

    -

    View all issues with New status.

    -

    Discussion:

    -

    -this DR follows the discussion on the previous thread "codecvt::do_in -not consuming external characters". It's just a clarification issue -and not a request for a change. -

    -

    -Can do_in()/do_out() produce output characters without consuming input -characters as a result of operation on state? -

    - - -

    Proposed resolution:

    -

    -Add a note at the end of 22.2.1.5.2 [lib.locale.codecvt.virtuals], -paragraph 3: -

    - -

    -[Note: As a result of operations on state, it can return ok or partial -and set from_next == from and to_next != to. --end note] -

    - - -

    Rationale:

    -

    -The submitter believes that standard already provides an affirmative -answer to the question. However, the current wording has induced a few -library implementors to make the incorrect assumption that -do_in()/do_out() always consume at least one internal character when -they succeed. -

    - -

    -The submitter also believes that the proposed resolution is not in -conflict with the related issue 76. Moreover, by explicitly allowing -operations on state to produce characters, a codecvt implementation -may effectively implement N-to-M translations without violating the -"one character at a time" principle described in such issue. On a side -note, the footnote in the proposed resolution of issue 76 that -informally rules out N-to-M translations for basic_filebuf should be -removed if this issue is accepted as valid. -

    - - - - - - -

    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

    @@ -2249,6 +2346,12 @@ is the only one that can throw. PJP suggests specifying that sentry::~sentry() should internally catch any exceptions it might cause. ]

    + +

    [ +See 418 and 622 for related issues. +]

    + +

    Proposed resolution:

    @@ -2361,102 +2464,6 @@ end-of-file):
    -

    401. incorrect type casts in table 32 in lib.allocator.requirements

    -

    Section: 20.1.2 [allocator.requirements] Status: Open - Submitter: Markus Mauhart Date: 2003-02-27

    -

    View other active issues in [allocator.requirements].

    -

    View all other issues in [allocator.requirements].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -I think that in par2 of [default.con.req] the last two -lines of table 32 contain two incorrect type casts. The lines are ... -

    - -
      a.construct(p,t)   Effect: new((void*)p) T(t)
-  a.destroy(p)       Effect: ((T*)p)?->~T()
-
    - -

    -.... with the prerequisits coming from the preceding two paragraphs, especially -from table 31: -

    - -
      alloc<T>             a     ;// an allocator for T
-  alloc<T>::pointer    p     ;// random access iterator
-                              // (may be different from T*)
-  alloc<T>::reference  r = *p;// T&
-  T const&             t     ;
-
    - -

    -For that two type casts ("(void*)p" and "(T*)p") to be well-formed -this would require then conversions to T* and void* for all -alloc<T>::pointer, so it would implicitely introduce extra -requirements for alloc<T>::pointer, additionally to the only -current requirement (being a random access iterator). -

    - - -

    Proposed resolution:

    -

    -Change 20.1.2 [allocator.requirements], Table 35: Allocator requirements -last column of the row describing "a.construct(p,t)" to: -

    - -
    -

    -Effect: ::new((void*)p) T(t) -Constructs a copy of t at p. If t is an -rvalue, it is forwarded to T's constructor as an rvalue, else it -is forwarded as an lvalue. -

    -
    - -

    -Change 20.1.2 [allocator.requirements], Table 35: Allocator requirements -last column of the row describing "a.destroy(p)" to: -

    - -
    -

    -Effect: ((T*)p)->~T() -Destroys the object at p. -

    -
    - -

    -Note: Actually I would prefer to replace "((T*)p)?->dtor_name" with -"p?->dtor_name", but AFAICS this is not possible cause of an omission -in 13.5.6 [over.ref] (for which I have filed another DR on 29.11.2002). -

    - -

    [Kona: The LWG thinks this is somewhere on the border between - Open and NAD. The intend is clear: construct constructs an - object at the location p. It's reading too much into the - description to think that literally calling new is - required. Tweaking this description is low priority until we can do - a thorough review of allocators, and, in particular, allocators with - non-default pointer types.]

    - - -

    [ -Batavia: Proposed resolution changed to less code and more description. -]

    - - -

    [ -post Oxford: This would be rendered NAD Editorial by acceptance of -N2257. -]

    - - - - - - - -

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

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

    @@ -2653,6 +2660,12 @@ object throws. something even more drastic.]

    +

    [ +See 397 and 622 for related issues. +]

    + + +

    Proposed resolution:

    @@ -3318,6 +3331,31 @@ actual filename. 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. +

    +

    Proposed resolution:

    @@ -3939,100 +3977,6 @@ wording (I believe) x,a,b,c could be written to in any order.
    -

    488. rotate throws away useful information

    -

    Section: 25.2.11 [alg.rotate] Status: Open - Submitter: Howard Hinnant Date: 2004-11-22

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -rotate takes 3 iterators: first, middle and last which point into a -sequence, and rearranges the sequence such that the subrange [middle, -last) is now at the beginning of the sequence and the subrange [first, -middle) follows. The return type is void. -

    - -

    -In many use cases of rotate, the client needs to know where the -subrange [first, middle) starts after the rotate is performed. This -might look like: -

    -
      rotate(first, middle, last);
-  Iterator i = advance(first, distance(middle, last));
-
    - -

    -Unless the iterators are random access, the computation to find the -start of the subrange [first, middle) has linear complexity. However, -it is not difficult for rotate to return this information with -negligible additional computation expense. So the client could code: -

    -
      Iterator i = rotate(first, middle, last);
-
    - -

    -and the resulting program becomes significantly more efficient. -

    - -

    -While the backwards compatibility hit with this change is not zero, it -is very small (similar to that of lwg 130), and there is -a significant benefit to the change. -

    - - - -

    Proposed resolution:

    -

    In 25p2, change:

    -
      template<class ForwardIterator>
-    void rotate(ForwardIterator first, ForwardIterator middle,
-                ForwardIterator last);
-
    - -

    to:

    - -
      template<class ForwardIterator>
-    ForwardIterator rotate(ForwardIterator first, ForwardIterator middle,
-                           ForwardIterator last);
-
    - -

    In 25.2.10, change:

    - -
      template<class ForwardIterator>
-    void rotate(ForwardIterator first, ForwardIterator middle,
-                ForwardIterator last);
-
    - -

    to:

    - -
      template<class ForwardIterator>
-    ForwardIterator rotate(ForwardIterator first, ForwardIterator middle,
-                           ForwardIterator last);
-
    - -

    In 25.2.10 insert a new paragraph after p1:

    - -
    -

    Returns: first + (last - middle).

    -
    - -

    [ -The LWG agrees with this idea, but has one quibble: we want to make -sure not to give the impression that the function "advance" is -actually called, just that the nth iterator is returned. (Calling -advance is observable behavior, since users can specialize it for -their own iterators.) Howard will provide wording. -]

    - - -

    [Howard provided wording for mid-meeting-mailing Jun. 2005.]

    - - - - - - - -

    492. Invalid iterator arithmetic expressions

    Section: 23 [containers], 24 [iterators], 25 [algorithms] Status: Open Submitter: Thomas Mang Date: 2004-12-12

    @@ -4444,11 +4388,11 @@ Berlin: Bill to provide wording.

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

    -

    Section: 23.1.3 [unord.req], TR1 6.3.1 [tr.unord.req] Status: Open +

    Section: 23.1.3 [unord.req], TR1 6.3.1 [tr.unord.req] Status: Review Submitter: Matt Austern Date: 2005-07-03

    View other active issues in [unord.req].

    View all other issues in [unord.req].

    -

    View all issues with Open status.

    +

    View all issues with Review status.

    Discussion:

    Issue 371 deals with stability of multiset/multimap under insert and erase @@ -4460,6 +4404,14 @@ Moved to open (from review): There is no resolution. ]

    +

    [ +Toronto: We have a resolution now. Moved to Review. Some concern was noted +as to whether this conflicted with existing practice or not. An additional +concern was in specifying (partial) ordering for an unordered container. +]

    + + +

    Proposed resolution:

    @@ -4520,6 +4472,10 @@ Berlin: Doug to provide wording. Batavia: Howard to provide wording. ]

    +

    [ +Toronto: Howard to provide wording (really this time). +]

    + @@ -4533,7 +4489,6 @@ Batavia: Howard to provide wording.

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

    Section: 28 [re] Status: Open Submitter: Eric Niebler Date: 2005-07-01

    -

    View other active issues in [re].

    View all other issues in [re].

    View all issues with Open status.

    Discussion:

    @@ -4664,134 +4619,42 @@ Pete: Possible general problem with case insensitive ranges.
    -

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

    -

    Section: 28 [re] Status: Open - Submitter: Eric Niebler Date: 2005-07-01

    -

    View other active issues in [re].

    -

    View all other issues in [re].

    +

    527. tr1::bind has lost its Throws clause

    +

    Section: 20.5.11.1.3 [func.bind.bind], TR1 3.6.3 [tr.func.bind.bind] Status: Open + Submitter: Peter Dimov Date: 2005-10-01

    View all issues with Open status.

    Discussion:

    -This defect is also being discussed on the Boost developers list. The -full discussion can be found here: -http://lists.boost.org/boost/2005/07/29546.php -

    -

    --- Begin original message -- -

    -

    -Also, I may have found another issue, closely related to the one under -discussion. It regards case-insensitive matching of named character -classes. The regex_traits<> provides two functions for working with -named char classes: lookup_classname and isctype. To match a char class -such as [[:alpha:]], you pass "alpha" to lookup_classname and get a -bitmask. Later, you pass a char and the bitmask to isctype and get a -bool yes/no answer. -

    -

    -But how does case-insensitivity work in this scenario? Suppose we're -doing a case-insensitive match on [[:lower:]]. It should behave as if it -were [[:lower:][:upper:]], right? But there doesn't seem to be enough -smarts in the regex_traits interface to do this. -

    -

    -Imagine I write a traits class which recognizes [[:fubar:]], and the -"fubar" char class happens to be case-sensitive. How is the regex engine -to know that? And how should it do a case-insensitive match of a -character against the [[:fubar:]] char class? John, can you confirm this -is a legitimate problem? -

    -

    -I see two options: -

    -

    -1) Add a bool icase parameter to lookup_classname. Then, -lookup_classname( "upper", true ) will know to return lower|upper -instead of just upper. +The original bind proposal gives the guarantee that tr1::bind(f, t1, +..., tN) does not throw when the copy constructors of f, t1, ..., tN +don't.

    +

    -2) Add a isctype_nocase function +This guarantee is not present in the final version of TR1.

    +

    -I prefer (1) because the extra computation happens at the time the -pattern is compiled rather than when it is executed. -

    -

    --- End original message -- -

    - -

    -For what it's worth, John has also expressed his preference for option -(1) above. -

    - - -

    Proposed resolution:

    - - - - - -
    -

    525. type traits definitions not clear

    -

    Section: 20.4.4 [meta.unary], TR1 4.5 [tr.meta.unary] Status: Open - Submitter: Robert Klarer Date: 2005-07-11

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -It is not completely clear how the primary type traits deal with -cv-qualified types. And several of the secondary type traits -seem to be lacking a definition. +I'm pretty certain that we never removed it on purpose. Editorial omission? :-)

    [ -Berlin: Howard to provide wording. +Berlin: not quite editorial, needs proposed wording. ]

    - - -

    Proposed resolution:

    -

    -Wording provided in N2028. -A -revision (N2157) -provides more detail for motivation. -

    - - - - - -
    -

    527. tr1::bind has lost its Throws clause

    -

    Section: 20.5.10.1.3 [func.bind.bind], TR1 3.6.3 [tr.func.bind.bind] Status: Open - Submitter: Peter Dimov Date: 2005-10-01

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -The original bind proposal gives the guarantee that tr1::bind(f, t1, -..., tN) does not throw when the copy constructors of f, t1, ..., tN -don't. -

    - -

    -This guarantee is not present in the final version of TR1. -

    - -

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

    -

    [ -Berlin: not quite editorial, needs proposed wording. +Batavia: Doug to translate wording to variadic templates. ]

    +

    [ -Batavia: Doug to translate wording to variadic templates. +Toronto: We agree but aren't quite happy with the wording. The "t"'s no +longer refer to anything. Alan to provide improved wording. ]

    +

    Proposed resolution:

    In 20.5.10.1.3 [lib.func.bind.bind] ([tr.func.bind.bind]), add a new paragraph after p2: @@ -4814,77 +4677,6 @@ throws an exception.

    -

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

    -

    Section: 23.4 [unord], TR1 6.3.4 [tr.unord.unord] Status: Open - Submitter: Paolo Carlini Date: 2005-10-12

    -

    View other active issues in [unord].

    -

    View all other issues in [unord].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -while implementing the resolution of issue 6.19 I'm noticing the -following: according to 6.3.4.3/2 (and 6.3.4.5/2), for unordered_set and -unordered_multiset: -

    - -

    - "The iterator and const_iterator types are both const types. It is -unspecified whether they are the same type" -

    - -

    -Now, according to the resolution of 6.19, we have overloads of insert -with hint and erase (single and range) both for iterator and -const_iterator, which, AFAICS, can be meaningful at the same time *only* -if iterator and const_iterator *are* in fact different types. -

    -

    -Then, iterator and const_iterator are *required* to be different types? -Or that is an unintended consequence? Maybe the overloads for plain -iterators should be added only to unordered_map and unordered_multimap? -Or, of course, I'm missing something? -

    - - - -

    Proposed resolution:

    -

    -Add to 6.3.4.3p2 (and 6.3.4.5p2): -

    -

    -2 ... The iterator and const_iterator types are both const -constant iterator types. -It is unspecified whether they are the same type. -

    - -

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

    - -
    -

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

    -

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

    -
    - -

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

    - - - - - - - -

    529. The standard encourages redundant and confusing preconditions

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

    @@ -4971,83 +4763,6 @@ Alan provided the survey
    -

    531. array forms of unformatted input functions

    -

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

    -

    View other active issues in [istream.unformatted].

    -

    View all other issues in [istream.unformatted].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -The array forms of unformatted input functions don't seem to have well-defined -semantics for zero-element arrays in a couple of cases. The affected ones -(istream::get() and istream::getline()) are supposed to -terminate when (n - 1) characters are stored, which obviously can -never be true when (n == 0) holds to start with. See -c++std-lib-16071. -

    - - -

    Proposed resolution:

    -

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

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

    -Change 27.6.1.3, p9: -

    - -

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

    - -

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

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

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

    -

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

    - -

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

    - - - - - - - -

    539. partial_sum and adjacent_difference should mention requirements

    Section: 26.6.3 [partial.sum] Status: Open Submitter: Marc Schoolderman Date: 2006-02-06

    @@ -5209,10 +4924,9 @@ adding signatures to allow user to specify "accumulator".

    546. _Longlong and _ULonglong are integer types

    -

    Section: 26.4.1 [rand.req], TR1 5.1.1 [tr.rand.req] Status: New +

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

    -

    View all other issues in [rand.req].

    -

    View all issues with New status.

    +

    View all issues with Open status.

    Discussion:

    The TR sneaks in two new integer types, _Longlong and _Ulonglong, in [tr.c99]. @@ -5236,47 +4950,12 @@ list, so that people may use long long as a hash key.

    -

    548. May random_device block?

    -

    Section: 26.4.6 [rand.device], TR1 5.1.6 [tr.rand.device] Status: Open - Submitter: Matt Austern Date: 2006-01-10

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -Class random_device "produces non-deterministic random numbers", using some -external source of entropy. In most real-world systems, the amount of available -entropy is limited. Suppose that entropy has been exhausted. What is an -implementation permitted to do? In particular, is it permitted to block -indefinitely until more random bits are available, or is the implementation -required to detect failure immediately? This is not an academic question. On -Linux a straightforward implementation would read from /dev/random, and "When -the entropy pool is empty, reads to /dev/random will block until additional -environmental noise is gathered." Programmers need to know whether random_device -is permitted to (or possibly even required to?) behave the same way. -

    - -

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

    - - - - -

    Proposed resolution:

    -

    -

    - - - - - -

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

    -

    Section: 26.7 [c.math] Status: New +

    Section: 26.7 [c.math] Status: Open Submitter: Howard Hinnant Date: 2006-01-12

    View other active issues in [c.math].

    View all other issues in [c.math].

    -

    View all issues with New status.

    +

    View all issues with Open status.

    Discussion:

    Assuming we adopt the @@ -5325,98 +5004,64 @@ Fortran, C and TR1 and make the return type of pow(float,int) be double.

    +

    [ +Kona (2007): Other functions that are affected by this issue include +ldexp, scalbln, and scalbn. We also believe that there is a typo in +26.7/10: float nexttoward(float, long double); [sic] should be float +nexttoward(float, float); Proposed Disposition: Review (the proposed +resolution appears above, rather than below, the heading "Proposed +resolution") +]

    -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    551. <ccomplex>

    -

    Section: 26.3.11 [cmplxh], TR1 8.3 [tr.c99.cmplxh] Status: Ready - Submitter: Howard Hinnant Date: 2006-01-23

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -Previously xxx.h was parsable by C++. But in the case of C99's <complex.h> -it isn't. Otherwise we could model it just like <string.h>, <cstring>, <string>: -

    - -
      -
    • <string> : C++ API in namespace std
      • -
    • <cstring> : C API in namespace std
      • -
    • <string.h> : C API in global namespace
      • -
    - -

    -In the case of C's complex, the C API won't compile in C++. So we have: -

    - -
      -
    • <complex> : C++ API in namespace std
      • -
    • <ccomplex> : ?
      • -
    • <complex.h> : ?
      • -
    - -

    -The ? can't refer to the C API. TR1 currently says: -

    - -
      -
    • <complex> : C++ API in namespace std
      • -
    • <ccomplex> : C++ API in namespace std
      • -
    • <complex.h> : C++ API in global namespace
      • -
    - - - -

    Proposed resolution:

    +

    [ +

    +Howard, post Kona: +

    +

    -Change 26.3.11 [cmplxh]: -

    - +Unfortunately I strongly disagree with a part of the resolution +from Kona. I am moving from New to Open instead of to Review because I do not believe +we have consensus on the intent of the resolution. +

    +

    +This issue does not include ldexp, scalbln, and scalbn because +the second integral parameter in each of these signatures (from C99) is not a +generic parameter according to C99 7.22p2. The corresponding C++ overloads are +intended (as far as I know) to correspond directly to C99's definition of generic parameter. +

    +

    +For similar reasons, I do not believe that the second long double parameter of +nexttoward, nor the return type of this function, is in error. I believe the +correct signature is: +

    +
    float nexttoward(float, long double);
+
    +

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

    +which is what both the C++0X working paper and C99 state (as far as I currently understand). +

    +

    +This is really only about pow(float, int). And this is because C++98 took one +route (with pow only) and C99 took another (with many math functions in <tgmath.h>. +The proposed resolution basically says: C++98 got it wrong and C99 got it right; let's go with C99. +

    +] - - -
    -

    552. random_shuffle and its generator

    -

    Section: 25.2.12 [alg.random.shuffle] Status: New - Submitter: Martin Sebor Date: 2006-01-25

    -

    View all issues with New status.

    -

    Discussion:

    -

    -...is specified to shuffle its range by calling swap but not how -(or even that) it's supposed to use the RandomNumberGenerator -argument passed to it. -

    +

    Proposed resolution:

    -Shouldn't we require that the generator object actually be used -by the algorithm to obtain a series of random numbers and specify -how many times its operator() should be invoked by the algorithm? +Change 26.7 [c.math]

    +
    float pow(float, float); 
+float double pow(float, int);
+
    -

    Proposed resolution:

    -

    -

    @@ -5560,9 +5205,9 @@ responsible for avoiding conflicting declarations. -- end note]

    561. inserter overly generic

    -

    Section: 24.4.2.6.5 [inserter] Status: New +

    Section: 24.4.2.6.5 [inserter] Status: Ready Submitter: Howard Hinnant Date: 2006-02-21

    -

    View all issues with New status.

    +

    View all issues with Ready status.

    Discussion:

    The declaration of std::inserter is: @@ -5714,15 +5359,22 @@ Change 24.4.2.6.5: +

    [ +Kona (2007): This issue will probably be addressed as a part of the +concepts overhaul of the library anyway, but the proposed resolution is +correct in the absence of concepts. Proposed Disposition: Ready +]

    + +

    562. stringbuf ctor inefficient

    -

    Section: 27.7 [string.streams] Status: New +

    Section: 27.7 [string.streams] Status: Ready Submitter: Martin Sebor Date: 2006-02-23

    View all other issues in [string.streams].

    -

    View all issues with New status.

    +

    View all issues with Ready status.

    Discussion:

    @@ -5804,16 +5456,21 @@ s.size()) hold. +

    [ +Kona (2007) Moved to Ready. +]

    + +

    563. stringbuf seeking from end

    -

    Section: 27.7.1.4 [stringbuf.virtuals] Status: New +

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

    View other active issues in [stringbuf.virtuals].

    View all other issues in [stringbuf.virtuals].

    -

    View all issues with New status.

    +

    View all issues with Ready status.

    Discussion:

    According to Table 92 (unchanged by issue 432), when (way == @@ -5858,16 +5515,21 @@ pointer (xend high_mark - xbeg).

    +

    [ +Kona (2007) Moved to Ready. +]

    + +

    564. stringbuf seekpos underspecified

    -

    Section: 27.7.1.4 [stringbuf.virtuals] Status: New +

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

    View other active issues in [stringbuf.virtuals].

    View all other issues in [stringbuf.virtuals].

    -

    View all issues with New status.

    +

    View all issues with Open status.

    Discussion:

    The effects of the seekpos() member function of @@ -5903,14 +5565,32 @@ the effect is undefined.

    • +

    [ +Kona (2007): A pos_type is a position in a stream by +definition, so there is no ambiguity as to what it means. Proposed +Disposition: NAD +]

    + + +

    [ +Post-Kona Martin adds: +I'm afraid I disagree +with the Kona '07 rationale for marking it NAD. The only text +that describes precisely what it means to position the input +or output sequence is in seekoff(). The seekpos() Effects +clause is inadequate in comparison and the proposed resolution +plugs the hole by specifying seekpos() in terms of seekoff(). +]

    + +

    565. xsputn inefficient

    -

    Section: 27.5.2.4.5 [streambuf.virt.put] Status: New +

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

    -

    View all issues with New status.

    +

    View all issues with Open status.

    Discussion:

    @@ -5965,79 +5645,14 @@ same text as Footnote 292 to make it extra clear that derived classes are permitted to override xsputn() for efficiency.

    - - - - - -
    -

    566. array forms of unformatted input function undefined for zero-element arrays

    -

    Section: 27.6.1.3 [istream.unformatted] Status: Ready - Submitter: Martin Sebor Date: 2006-02-23

    -

    View other active issues in [istream.unformatted].

    -

    View all other issues in [istream.unformatted].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    - -The array forms of unformatted input functions don't have well-defined -semantics for zero-element arrays in a couple of cases. The affected -ones (istream::get() and getline()) are supposed to -terminate when (n - 1) characters are stored, which obviously -can never be true when (n == 0) to start with. - -

    - - -

    Proposed resolution:

    -

    - -I propose the following changes (references are relative to the -Working Draft (document N1804). - -

    -

    - -Change 27.6.1.3, p8 (istream::get()), bullet 1 as follows: - -

    -
    -

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

    -
    -

    - -Similarly, change 27.6.1.3, p18 (istream::getline()), bullet -3 as follows: - -

    -
    -

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

    -
    -

    - -Finally, change p21 as follows: - -

    -
    -

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

    -
    + + +

    [ +Kona (2007): We want to permit a streambuf that streams output directly +to a device without making calls to sputc or overflow. We believe that +has always been the intention of the committee. We believe that the +proposed wording doesn't accomplish that. Proposed Disposition: Open +]

    @@ -6045,11 +5660,11 @@ location of the array.

    567. streambuf inserter and extractor should be unformatted

    -

    Section: 27.6 [iostream.format] Status: New +

    Section: 27.6 [iostream.format] Status: Ready Submitter: Martin Sebor Date: 2006-02-25

    View other active issues in [iostream.format].

    View all other issues in [iostream.format].

    -

    View all issues with New status.

    +

    View all issues with Ready status.

    Discussion:

    @@ -6103,6 +5718,11 @@ And change 27.6.2.5.3, p7 as follows: +

    [ +Kona (2007): Proposed Disposition: Ready +]

    + + @@ -6155,6 +5775,10 @@ Portland: Jack will rewrite to propose a primary template that will work with other integral types. ]

    +

    [ +Toronto: issue has grown with addition of char16_t and char32_t. +]

    +

    Proposed resolution:

    @@ -6165,10 +5789,10 @@ to propose a primary template that will work with other integral types.

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

    -

    Section: 27.4.3 [fpos] Status: New +

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

    View all other issues in [fpos].

    -

    View all issues with New status.

    +

    View all issues with Open status.

    Discussion:

    There are two deficiencies related to file sizes: @@ -6201,6 +5825,12 @@ sufficient. But they seem a useful starting place for discussions, and they do represent existing practice.

    +

    [ +Kona (2007): We need a paper. It would be nice if someone proposed +clarifications to the definitions of pos_type and off_type. Currently +these definitions are horrible. Proposed Disposition: Open +]

    +

    Proposed resolution:

    @@ -6213,10 +5843,10 @@ represent existing practice.

    574. DR 369 Contradicts Text

    -

    Section: 27.3 [iostream.objects] Status: New +

    Section: 27.3 [iostream.objects] Status: Review Submitter: Pete Becker Date: 2006-04-18

    View all other issues in [iostream.objects].

    -

    View all issues with New status.

    +

    View all issues with Review status.

    Discussion:

    lib.iostream.objects requires that the standard stream objects are never @@ -6233,57 +5863,31 @@ not destroyed during program execution."

    Proposed resolution:

    -

    - - - - - -
    -

    577. upper_bound(first, last, ...) cannot return last

    -

    Section: 25.3.3.2 [upper.bound] Status: New - Submitter: Seungbeom Kim Date: 2006-05-03

    -

    View all issues with New status.

    -

    Discussion:

    -

    -ISO/IEC 14882:2003 says: +Change 27.3 [iostream.objects]/1:

    -25.3.3.2 upper_bound -

    -

    -Returns: The furthermost iterator i in the range -[first, last) such that -for any iterator j in the range [first, i) the following corresponding -conditions hold: !(value < *j) or comp(value, *j) == false. +-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.290) The objects are not destroyed during program +execution.291) If a translation unit includes <iostream&t; or explicitly +constructs an ios_base::Init object, these stream objects shall be +constructed before dynamic initialization of non-local objects defined +later in that translation unit, and these stream objects shall be +destroyed after the destruction of dynamically initialized non-local +objects defined later in that translation unit.

    -

    -From the description above, upper_bound cannot return last, since it's -not in the interval [first, last). This seems to be a typo, because if -value is greater than or equal to any other values in the range, or if -the range is empty, returning last seems to be the intended behaviour. -The corresponding interval for lower_bound is also [first, last]. -

    - - -

    Proposed resolution:

    -

    -Change [lib.upper.bound]: -

    - -
    -

    -Returns: The furthermost iterator i in the range -[first, last)] such that -for any iterator j in the range [first, i) the following corresponding -conditions hold: !(value < *j) or comp(value, *j) == false. -

    -
    +

    [ +Kona (2007): From 27.3 [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 +]

    @@ -6291,11 +5895,11 @@ conditions hold: !(value < *j) or comp(value, *j)

    579. erase(iterator) for unordered containers should not return an iterator

    -

    Section: 23.1.3 [unord.req] Status: New +

    Section: 23.1.3 [unord.req] Status: Open Submitter: Joaquín M López Muñoz Date: 2006-06-13

    View other active issues in [unord.req].

    View all other issues in [unord.req].

    -

    View all issues with New status.

    +

    View all issues with Open status.

    Discussion:

    See @@ -6346,6 +5950,21 @@ code. +

    Rationale:

    +

    +N2023 +was discussed in Portland and the consensus was that there appears to be +no need for either change proposed in the paper. The consensus opinion +was that since the iterator could serve as its own proxy, there appears +to be no need for the change. In general, "converts to" is undesirable +because it interferes with template matching. +

    + +

    +Post Toronto: There does not at this time appear to be consensus with the Portland consensus. +

    + + @@ -6502,10 +6121,10 @@ post Oxford: This would be rendered NAD Editorial by acceptance of

    581. flush() not unformatted function

    -

    Section: 27.6.2.7 [ostream.unformatted] Status: New +

    Section: 27.6.2.7 [ostream.unformatted] Status: Ready Submitter: Martin Sebor Date: 2006-06-14

    View all other issues in [ostream.unformatted].

    -

    View all issues with New status.

    +

    View all issues with Ready status.

    Discussion:

    @@ -6556,12 +6175,20 @@ not behave as an unformatted output function (as described in +

    [ +Kona (2007): Proposed Disposition: Ready +]

    + + +

    582. specialized algorithms and volatile storage

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

    +

    View other active issues in [uninitialized.copy].

    +

    View all other issues in [uninitialized.copy].

    View all issues with Open status.

    Discussion:

    @@ -6683,71 +6310,12 @@ effect by means of function template overloading.

    -

    583. div() for unsigned integral types

    -

    Section: 26.7 [c.math] Status: New - Submitter: Beman Dawes Date: 2006-06-15

    -

    View other active issues in [c.math].

    -

    View all other issues in [c.math].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -There is no div() function for unsigned integer types. -

    -

    -There are several possible resolutions. The simplest one is noted below. Other -possibilities include a templated solution. -

    - - -

    Proposed resolution:

    -

    -Add to 26.7 [lib.c.math] paragraph 8: -

    - -
    struct udiv_t div(unsigned, unsigned);
-struct uldiv_t div(unsigned long, unsigned long);
-struct ulldiv_t div(unsigned long long, unsigned long long);
-
    - - - - - - -
    -

    584. missing int pow(int,int) functionality

    -

    Section: 26.7 [c.math] Status: New - Submitter: Beman Dawes Date: 2006-06-15

    -

    View other active issues in [c.math].

    -

    View all other issues in [c.math].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -There is no pow() function for any integral type. -

    - - -

    Proposed resolution:

    -

    -Add something like: -

    - -
    template< typename T>
-T power( T x, int n );
-// requires: n >=0
-
    - - - - - -

    585. facet error reporting

    -

    Section: 22.2 [locale.categories] Status: New +

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

    View other active issues in [locale.categories].

    View all other issues in [locale.categories].

    -

    View all issues with New status.

    +

    View all issues with Open status.

    Discussion:

    @@ -6853,16 +6421,23 @@ case of a parse error, or both, respectively.

    + +

    [ +Kona (2007): We need to change the proposed wording to clarify that the +phrase "the get members" actually denotes get(), get_date(), etc. +Proposed Disposition: Open +]

    +

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

    -

    Section: 23.2.1 [array] Status: New +

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

    View other active issues in [array].

    View all other issues in [array].

    -

    View all issues with New status.

    +

    View all issues with Open status.

    Discussion:

    The wording used for section 23.2.1 [lib.array] seems to be subtly @@ -6998,59 +6573,11 @@ which, again, doesn't seem to consider fixed size containers

    - - - -
    -

    592. Incorrect treatment of rdbuf()->close() return type

    -

    Section: 27.8.1.9 [ifstream.members] Status: New - Submitter: Christopher Kohlhoff Date: 2006-08-17

    -

    View all other issues in [ifstream.members].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -I just spotted a minor problem in 27.8.1.7 -[lib.ifstream.members] para 4 and also 27.8.1.13 -[lib.fstream.members] para 4. In both places it says: -

    -
    -
    void close();
-
    -

    -Effects: Calls rdbuf()->close() and, if that function returns false, ... -

    -
    -

    -However, basic_filebuf::close() (27.8.1.2) returns a pointer to the -filebuf on success, null on failure, so I think it is meant to -say "if that function returns a null pointer". Oddly, it is -correct for basic_ofstream. -

    - - -

    Proposed resolution:

    -

    -Change 27.8.1.7 [lib.ifstream.members], p5: -

    - -

    -Effects: Calls rdbuf()->close() and, if that function -fails (returns false a null pointer), -calls setstate(failbit) (which may throw ios_base::failure -(27.4.4.3)). -

    - -

    -Change 27.8.1.13 [lib.fstream.members], p5: -

    - -

    -Effects: Calls rdbuf()->close() and, if that function -fails (returns false a null pointer), -calls setstate(failbit) (which may throw ios_base::failure -(27.4.4.3)). -

    - +

    [ +Kona (2007): requirements on zero sized tr1::arrays and other details +Issue 617: std::array is a sequence that doesn't satisfy the sequence +requirements? Alisdair will prepare a paper. Proposed Disposition: Open +]

    @@ -7058,11 +6585,9 @@ calls setstate(failbit) (which may throw ios_base::failure

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

    -

    Section: 26.3 [complex.numbers] Status: New +

    Section: 26.3.7 [complex.value.ops] Status: Ready Submitter: Stefan Große Pawig Date: 2006-09-24

    -

    View other active issues in [complex.numbers].

    -

    View all other issues in [complex.numbers].

    -

    View all issues with New status.

    +

    View all issues with Ready status.

    Discussion:

    TR1 introduced, in the C compatibility chapter, the function @@ -7130,8 +6655,8 @@ So either the return value of fabs() is specified wrongly, or fabs() does not behave the same as C99's cabs*().

    +Possible Resolutions -

    Proposed resolution:

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

    @@ -7168,18 +6693,50 @@ is already provided by the corresponding overloads of abs(). +

    Proposed resolution:

    + +

    +Change the synopsis in 26.3.1 [complex.synopsis]: +

    + +
    template<class T> complex<T> fabs(const complex<T>&);
+
    + +

    +Change 26.3.7 [complex.value.ops], p7: +

    + +
    +
    template<class T> complex<T> fabs(const complex<T>& x);
+
    +
    +

    +-7- Effects: Behaves the same as C99 function cabs, defined in subclause 7.3.8.1. +

    +
    +
    + + + +

    [ +Kona (2007): Change the return type of fabs(complex) to T. +Proposed Disposition: Ready +]

    + + +

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

    -

    Section: 27.8.1.4 [filebuf.members] Status: New +

    Section: 27.8.1.4 [filebuf.members] Status: Review Submitter: Thomas Plum Date: 2006-09-26

    View other active issues in [filebuf.members].

    View all other issues in [filebuf.members].

    -

    View all issues with New status.

    +

    View all issues with Review status.

    Discussion:

    -In testing 27.8.1.3, Table 112 (in the latest N2009 draft), we invoke +In testing 27.8.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)
    @@ -7224,40 +6781,119 @@ the same thing as "a+" already proposed in the issue.

    Proposed resolution:

    - - - - - -
    -

    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

    -

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

    -

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

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -In a private email, Daveed writes: -

    -
    -

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

    -Here is an example: +Add to the table "File open modes" in 27.8.1.4 [filebuf.members]:

    -
    -
    -		 struct S {
-		   S(_Decimal32 const&);  // Converting constructor
-		 };
-		 void f(S);
 
-		 void f(_Decimal64);
+
    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
     File open modes
    ios_base Flag combinationstdio equivalent
    binaryinouttruncapp 
        +     "w"
        +   + "a"
            + "a"
        + +   "w"
      +       "r"
      + +     "r+"
      + + +   "w+"
      + +   + "a+"
      +     + "a+"
    +   +     "wb"
    +   +   + "ab"
    +       + "ab"
    +   + +   "wb"
    + +       "rb"
    + + +     "r+b"
    + + + +   "w+b"
    + + +   + "a+b"
    + +     + "a+b"
    
+
    
+
+
+
+
    [
+Kona (2007) Added proposed wording and moved to Review.
+]
    
+
+
+
+
+
+
    
+
    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
    
+
    View other active issues in [trdec.types.types].
    
+
    View all other issues in [trdec.types.types].
    
+
    View all issues with Open status.
    
+
    Discussion:
    
+
    
+In a private email, Daveed writes:
+
    
+
    
+
    
+I am not familiar with the C TR, but my guess is that the
+class type approach still won't match a built-in type
+approach because the notion of "promotion" cannot be
+emulated by user-defined types.
+
    
+
    
+Here is an example:
+
    
+
    
+
    +		 struct S {
+		   S(_Decimal32 const&);  // Converting constructor
+		 };
+		 void f(S);
+
+		 void f(_Decimal64);
 
 		 void g(_Decimal32 d) {
 		   f(d);
@@ -7318,128 +6954,6 @@ C-to-C++ compatibility, since neither example can be expressed in C.
 
 
 
    
-
    604. Decimal: Storing a reference to a facet unsafe.
    
-
    Section: TRDecimal 3 [trdec.types] Status: Ready
- Submitter: Martin Sebor Date: 2006-05-28
    
-
    View all other issues in [trdec.types].
    
-
    View all issues with Ready status.
    
-
    Discussion:
    
-
    
-In c++std-lib-17197, Martin writes:
-
    
-
    
-The extended_num_get and extended_num_put facets are designed
-to store a reference to a num_get or num_put facet which the
-extended facets delegate the parsing and formatting of types
-other than decimal. One form of the extended facet's ctor (the
-default ctor and the size_t overload) obtains the reference
-from the global C++ locale while the other form takes this
-reference as an argument.
-
    
-
    
-The problem with storing a reference to a facet in another
-object (as opposed to storing the locale object in which the
-facet is installed) is that doing so bypasses the reference
-counting mechanism designed to prevent a facet that is still
-being referenced (i.e., one that is still installed in some
-locale) from being destroyed when another locale that contains
-it is destroyed. Separating a facet reference from the locale
-it comes from van make it cumbersome (and in some cases might
-even make it impossible) for programs to prevent invalidating
-the reference. (The danger of this design is highlighted in
-the paper.)
-
    
-
    
-This problem could be easily avoided by having the extended
-facets store a copy of the locale from which they would extract
-the base facet either at construction time or when needed. To
-make it possible, the forms of ctors of the extended facets that
-take a reference to the base facet would need to be changed to
-take a locale argument instead.
-
    
-
-
-
    Proposed resolution:
    
-
    
-1. Change the extended_num_get synopsis in 3.10.2 as follows:
-
    
-
                extended_num_get(const std::num_get<charT, InputIterator> std::locale & b, size_t refs = 0);
-
-            /* ... */
-
-            // const std::num_get<charT, InputIterator> & base;        exposition only
-            // std::locale baseloc;                                    exposition only
-
    
-
    
-2. Change the description of the above constructor in 3.10.2.1:
-
    
-
                extended_num_get(const std::num_get<charT, InputIterator> std::locale & b, size_t refs = 0);
-
-
    
-
    
-
    
-Effects: Constructs an extended_num_get facet as if by:
-
    
-
           extended_num_get(const std::num_get<charT, InputIterator> std::locale & b, size_t refs = 0)
-                : facet(refs), baseloc(b)
-                { /* ... */ }
-
-
    
-
    
-Notes: Care must be taken by the implementation to ensure that the lifetime of the facet referenced by base exceeds that of the resulting extended_num_get facet.
-
    
-
    
-
    
-3. Change the Returns: clause for do_get(iter_type, iter_type, ios_base &, ios_base::iostate &, bool &) const, et al to
-
    
-
    
-Returns: base std::use_facet<std::num_get<charT, InputIterator> >(baseloc).get(in, end, str, err, val). 
-
    
-
    
-4. Change the extended_num_put synopsis in 3.10.3 as follows:
-
    
-
                extended_num_put(const std::num_put<charT, OutputIterator> std::locale & b, size_t refs = 0);
-
-            /* ... */
-
-            // const std::num_put<charT, OutputIterator> & base;       exposition only
-            // std::locale baseloc;                                    exposition only
-
    
-
    
-5. Change the description of the above constructor in 3.10.3.1:
-
    
-
                extended_num_put(const std::num_put<charT, OutputIterator> std::locale & b, size_t refs = 0);
-
    
-
    
-
    
-Effects: Constructs an extended_num_put facet as if by:
-
    
-
           extended_num_put(const std::num_put<charT, OutputIterator> std::locale & b, size_t refs = 0)
-                : facet(refs), baseloc(b)
-                { /* ... */ }
-
-
    
-
    
-Notes: Care must be taken by the implementation to ensure that the lifetime of the facet referenced by base exceeds that of the resulting extended_num_put facet.
-
    
-
    
-
    
-6. Change the Returns: clause for do_put(iter_type, ios_base &, char_type, bool &) const, et al to
-
    
-
    
-Returns: base std::use_facet<std::num_put<charT, OutputIterator> >(baseloc).put(s, f, fill, val). 
-
    
-
-
    [
-Redmond:  We would prefer to rename "extended" to "decimal".
-]
    
-
-
-
-
-
-
-
    
 
    606. Decimal: allow narrowing conversions
    
 
    Section: TRDecimal 3.2 [trdec.types.types] Status: Open
  Submitter: Martin Sebor Date: 2006-06-15
    
@@ -7500,99 +7014,6 @@ Redmond: We prefer explicit conversions for narrowing and implicit for widening.
 
 
 
    
-
    607. Concern about short seed vectors
    
-
    Section: 26.4.7.1 [rand.util.seedseq], TR1 5.1 [tr.rand] Status: New
- Submitter: Charles Karney Date: 2006-10-26
    
-
    View other active issues in [rand.util.seedseq].
    
-
    View all other issues in [rand.util.seedseq].
    
-
    View all issues with New status.
    
-
    Discussion:
    
-
    
-Short seed vectors of 32-bit quantities all result in different states. However
-this is not true of seed vectors of 16-bit (or smaller) quantities.  For example
-these two seeds
-
    
-
-
    unsigned short seed = {1, 2, 3};
-unsigned short seed = {1, 2, 3, 0};
-
    
-
-
    
-both pack to
-
    
-
-
    unsigned seed = {0x20001, 0x3};
-
    
-
-
    
-yielding the same state.
-
    
-
-
-
    Proposed resolution:
    
-
    
-In 26.4.7.1[rand.util.seedseq]/8a, replace
-
    
-
-
    
-
    
-Set begin[0] to 5489 + sN.
-
    
-
    
-where N is the bit length of the sequence used to construct the
-seed_seq in 26.4.7.1/6 [rand.util.seedseq].  (This quantity is called n
-in 26.4.7.1/6 [rand.util.seedseq], but n has a different meaning in
-26.4.7.1/8 [rand.util.seedseq].  We have 32^(s-1) < N <= 32^s.)  Now
-
    
-
-
    unsigned short seed = {1, 2, 3, 0};
-unsigned seed = {0x20001, 0x3};
-
    
-
-
    
-are equivalent (N = 64), but
-
    
-
-
    unsigned short seed = {1, 2, 3};
-
    
-
-
    
-gives a distinct state (N = 48).
-
    
-
    
-
-
-
-
-
-
-
    
-
    608. Unclear seed_seq construction details
    
-
    Section: 26.4.7.1 [rand.util.seedseq], TR1 5.1 [tr.rand] Status: New
- Submitter: Charles Karney Date: 2006-10-26
    
-
    View other active issues in [rand.util.seedseq].
    
-
    View all other issues in [rand.util.seedseq].
    
-
    View all issues with New status.
    
-
    Discussion:
    
-
    
-In 26.4.7.1 [rand.util.seedseq] /6, the order of packing the inputs into b and the
-treatment of signed quantities is unclear. Better to spell it out.
-
    
-
-
-
    Proposed resolution:
    
-
    b = sum( unsigned(begin[i]) 2^(w i), 0 <= i < end-begin )
-
    
-
-
    
-where w is the bit-width of the InputIterator.
-
    
-
-
-
-
-
-
    
 
    612. numeric_limits::is_modulo insufficently defined
    
 
    Section: 18.2.1.2 [numeric.limits.members] Status: Open
  Submitter: Chris Jefferson Date: 2006-11-10
    
@@ -7644,6 +7065,7 @@ differs from the true value by an integer multiple of (max() - min() +
 
    614. std::string allocator requirements still inconsistent
    
 
    Section: 21.3 [basic.string] Status: Open
  Submitter: Bo Persson Date: 2006-12-05
    
+
    View other active issues in [basic.string].
    
 
    View all other issues in [basic.string].
    
 
    View all issues with Open status.
    
 
    Discussion:
    
@@ -7742,9 +7164,9 @@ std::array does have, but array isn't mentioned.
 
 
    
 
    618. valarray::cshift() effects on empty array
    
-
    Section: 26.5.2.7 [valarray.members] Status: New
+
    Section: 26.5.2.7 [valarray.members] Status: Review
  Submitter: Gabriel Dos Reis Date: 2007-01-10
    
-
    View all issues with New status.
    
+
    View all issues with Review status.
    
 
    Discussion:
    
 
    
 I would respectfully request an issue be opened with the intention to
@@ -7754,32 +7176,56 @@ clarify the wording for size() == 0 for cshift.
 
 
    Proposed resolution:
    
 
    
-Change 26.5.2.7 [valarray.members], paragraph 7:
+Change 26.5.2.7 [valarray.members], paragraph 10:
 
    
 
+
    
+
+
    valarray<T> cshift(int n) const;
+
    
+
+
    
 
    
 This function returns an object of class valarray<T>, of
-length size()., each of whose elements I is
+length size(), each of whose elements I is
 (*this)[(I + n ) % size()]. Thus, if element zero is taken as
 the leftmost element, a positive value of n shifts the elements
-circularly left n places. When
-size() is positive, each element at index I of the
-returned valarray is equivalent to (*this)[(I + n) % size()].
-Therefore cshift() returns an n-fold left cyclic
-rotation of the elements of *this.
+circularly left n places. that is a circular shift of *this. If
+element zero is taken as the leftmost element, a non-negative value of
+n shifts the elements circularly left n places and a
+negative value of n shifts the elements circularly right
+-n places.
+
    
+
    
+
    
+
+
+
+
    Rationale:
    
+
    
+We do not believe that there is any real ambiguity about what happens
+when size() == 0, but we do believe that spelling this out as a C++
+expression causes more trouble that it solves. The expression is
+certainly wrong when n < 0, since the sign of % with negative arguments
+is implementation defined.
 
    
 
 
+
    [
+Kona (2007) Changed proposed wording, added rationale and set to Review.
+]
    
+
+
 
 
 
 
    
 
    620. valid uses of empty valarrays
    
-
    Section: 26.5.2.1 [valarray.cons] Status: New
+
    Section: 26.5.2.1 [valarray.cons] Status: Ready
  Submitter: Martin Sebor Date: 2007-01-20
    
 
    View other active issues in [valarray.cons].
    
 
    View all other issues in [valarray.cons].
    
-
    View all issues with New status.
    
+
    View all issues with Ready status.
    
 
    Discussion:
    
         
    
 
@@ -7845,10 +7291,10 @@ function.
 
 
    
 
    621. non-const copy assignment operators of helper arrays
    
-
    Section: 26.5 [numarray] Status: New
+
    Section: 26.5 [numarray] Status: Ready
  Submitter: Martin Sebor Date: 2007-01-20
    
 
    View all other issues in [numarray].
    
-
    View all issues with New status.
    
+
    View all issues with Ready status.
    
 
    Discussion:
    
         
    
 
@@ -7866,6 +7312,27 @@ reference semantics (existing implementations vary widely).
 
         
    
 
+
    
+Pre-Kona, Martin adds:
+
    
+
+
    
+I realized that adding the const qualifier to the
+functions as I suggested would break the const correctness of the
+classes. A few possible solutions come to mind:
+
    
+
+
      
+
    1. Add the const qualifier to the return types of these functions.
      2. 
+
    2. Change the return type of all the functions to void to match
+the signatures of all the other assignment operators these classes
+define.
      3. 
+
    3. Prohibit the copy assignment of these classes by declaring the
+copy assignment operators private (as is done and documented by
+some implementations).
      4. 
+
    
+
+
 
 
    Proposed resolution:
    
         
    
@@ -7882,53 +7349,58 @@ Specifically,  make the following edits:
         
    
 
 Change     the    signature     in     26.5.5 [template.slice.array]    and
-26.5.5.2 [slice.arr.assign] as follows:
+26.5.5.1 [slice.arr.assign] as follows:
 
         
    
         
    -slice_array& operator= (const slice_array&) const;
+const slice_array& operator= (const slice_array&) const;
 
         
    
         
    
 
 Change     the     signature     in    26.5.7 [template.gslice.array]     and
-26.5.7.2 [gslice.array.assign] as follows:
+26.5.7.1 [gslice.array.assign] as follows:
 
         
    
         
    -gslice_array& operator= (const gslice_array&) const;
+const gslice_array& operator= (const gslice_array&) const;
 
         
    
         
    
 
-Change the  signature in 26.5.8 [template.mask.array]  and 26.5.8.2 [mask.array.assign] as
+Change the  signature in 26.5.8 [template.mask.array]  and 26.5.8.1 [mask.array.assign] as
 follows:
 
         
    
         
    -mask_array& operator= (const mask_array&) const;
+const mask_array& operator= (const mask_array&) const;
 
         
    
         
    
 
 Change     the     signature     in    26.5.9 [template.indirect.array] and
-26.5.9.2 [indirect.array.assign] as follows:
+26.5.9.1 [indirect.array.assign] as follows:
 
         
    
         
    -indirect_array& operator= (const indirect_array&) const;
+const indirect_array& operator= (const indirect_array&) const;
 
         
    
 
 
+
    [
+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: New
+
    Section: 27.8.1.17 [fstream.members] Status: Ready
  Submitter: Martin Sebor Date: 2007-01-20
    
-
    View all issues with New status.
    
+
    View all issues with Ready status.
    
 
    Discussion:
    
         
    
 
@@ -8000,6 +7472,12 @@ errors.
 
         
    
 
+
    [
+See 397 and 418 for related issues.
+]
    
+
+
+
 
 
    Proposed resolution:
    
         
    
@@ -8073,9 +7551,9 @@ the     exception    is     caught    but     not     rethrown    (see
 
 
    
 
    623. pubimbue forbidden to call imbue
    
-
    Section: 27.1.1 [iostream.limits.imbue] Status: New
+
    Section: 27.1.1 [iostream.limits.imbue] Status: Ready
  Submitter: Martin Sebor Date: 2007-01-20
    
-
    View all issues with New status.
    
+
    View all issues with Ready status.
    
 
    Discussion:
    
         
    
 
@@ -8117,9 +7595,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: New
+
    Section: 26.5.2.2 [valarray.assign] Status: Ready
  Submitter: Martin Sebor Date: 2007-01-20
    
-
    View all issues with New status.
    
+
    View all issues with Ready status.
    
 
    Discussion:
    
         
    
 
@@ -8176,9 +7654,6 @@ And see more history in
 N0280.
 
    
 
-
-
-
    Proposed resolution:
    
         
    
 
 It has  been argued in  discussions on the committee's  reflector that
@@ -8211,6 +7686,29 @@ to implement valarray efficiently.
         
    
 
 
+
    Proposed resolution:
    
+
    
+Insert new paragraph into 26.5.2.2 [valarray.assign]:
+
    
+
+
    
+
    valarray<T>& operator=(const slice_array<T>&); 
+valarray<T>& operator=(const gslice_array<T>&); 
+valarray<T>& operator=(const mask_array<T>&); 
+valarray<T>& operator=(const indirect_array<T>&);
+
    
+
    
+
    
+Requires: The length of the  array to which the argument refers
+equals size().
+
    
+
    
+These operators allow the results of a generalized subscripting operation to be assigned directly to a valarray.
+
    
+
    
+
    
+
+
 
 
 
@@ -8338,7 +7836,6 @@ Batavia:  Alan and Pete to work.
 
    626. new Remark clauses not documented
    
 
    Section: 17.3.1.3 [structure.specifications] Status: Open
  Submitter: Martin Sebor Date: 2007-01-20
    
-
    View other active issues in [structure.specifications].
    
 
    View all other issues in [structure.specifications].
    
 
    View all issues with Open status.
    
 
    Discussion:
    
@@ -8373,10 +7870,10 @@ Batavia:  Alan and Pete to work.
 
 
    
 
    627. Low memory and exceptions
    
-
    Section: 18.5.1.1 [new.delete.single] Status: New
+
    Section: 18.5.1.1 [new.delete.single] Status: Open
  Submitter: P.J. Plauger Date: 2007-01-23
    
 
    View all other issues in [new.delete.single].
    
-
    View all issues with New status.
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
 I recognize the need for nothrow guarantees in the exception reporting
@@ -8400,47 +7897,11 @@ footnote, but the wording has to be a bit vague. The idea is that if
 
 
 
    
-
    628. Inconsistent definition of basic_regex constructor
    
-
    Section: 28.8 [re.regex] Status: Ready
- Submitter: Bo Persson Date: 2007-01-23
    
-
    View all issues with Ready status.
    
-
    Discussion:
    
-
    
-Section 28.8 [re.regex] lists a constructor
-
    
-
-
    template<class InputIterator>
-basic_regex(InputIterator first, InputIterator last,
-                       flag_type f = regex_constants::ECMAScript);
-
    
-
-
    
-However, in section 28.8.2 [re.regex.construct], this constructor takes a 
-pair of ForwardIterator.
-
    
-
-
-
    Proposed resolution:
    
-
    
-Change 28.8.2 [re.regex.construct]:
-
    
-
-
    template <class ForwardIterator InputIterator>
-  basic_regex(ForwardIterator InputIterator first, ForwardIterator InputIterator last, 
-              flag_type f = regex_constants::ECMAScript);
-
    
-
-
-
-
-
-
-
    
 
    629. complex insertion and locale dependence
    
-
    Section: 26.3.6 [complex.ops] Status: New
+
    Section: 26.3.6 [complex.ops] Status: Open
  Submitter: Gabriel Dos Reis Date: 2007-01-28
    
 
    View all other issues in [complex.ops].
    
-
    View all issues with New status.
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
 is there an issue opened for (0,3) as complex number with
@@ -8478,11 +7939,11 @@ dedicated facet.  Then complex should use that solution.
 
 
    
 
    630. arrays of valarray
    
-
    Section: 26.5.2.1 [valarray.cons] Status: New
+
    Section: 26.5.2.1 [valarray.cons] Status: Open
  Submitter: Martin Sebor Date: 2007-01-28
    
 
    View other active issues in [valarray.cons].
    
 
    View all other issues in [valarray.cons].
    
-
    View all issues with New status.
    
+
    View all issues with Open status.
    
 
    Discussion:
    
         
    
 
@@ -8609,15 +8070,22 @@ performing the assignment.
         
 
 
+
    [
+Kona (2007): Gaby to propose wording for an alternative resolution in
+which you can assign to a valarray of size 0, but not to any other
+valarray whose size is unequal to the right hand side of the assignment.
+]
    
+
+
 
 
 
 
    
 
    631. conflicting requirements for BinaryPredicate
    
-
    Section: 25 [algorithms] Status: New
+
    Section: 25 [algorithms] Status: Open
  Submitter: James Kanze Date: 2007-01-31
    
 
    View all other issues in [algorithms].
    
-
    View all issues with New status.
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
 The general requirements for BinaryPredicate (in 25 [algorithms]/8) contradict the implied specific requirements for
@@ -8650,6 +8118,12 @@ In the description of lexicographical_compare, we have both
 *first1 )".
 
    
 
+
    [
+Toronto:  Moved to Open.  ConceptGCC seems to get lower_bound
+and upper_bound to work withoutt these changes.
+]
    
+
+
 
 
 
    Proposed resolution:
    
@@ -8694,11 +8168,11 @@ when you only need one, and which one.
 
 
    
 
    632. Time complexity of size() for std::set
    
-
    Section: 23.1 [container.requirements] Status: New
+
    Section: 23.1 [container.requirements] Status: Open
  Submitter: Lionel B Date: 2007-02-01
    
 
    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:
    
 
    
 A recent news group discussion:
@@ -8747,101 +8221,24 @@ away.
 
    
 
 
-
-
-
-
    
-
    634. allocator.address() doesn't work for types overloading operator&
    
-
    Section: 20.6.1.1 [allocator.members] Status: New
- Submitter: Howard Hinnant Date: 2007-02-07
    
-
    View all other issues in [allocator.members].
    
-
    View all issues with New status.
    
-
    Duplicate of: 350
    
-
    Discussion:
    
-
-
    
-20.6.1.1 [allocator.members] says:
-
    
-
    
-
    pointer address(reference x) const;
    
-
    
-
    
--1- Returns: &x.
-
    
-
    
-
    
-
-
    
-20.6.1.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
-that we should disallow overloading operator& to return something other
-than the address of *this.
-
    
-
-
    
-An example of when you want to overload operator& to return something
-other than the object's address is proxy references such as vector<bool>
-(or its replacement, currently code-named bit_vector).  Taking the address of
-such a proxy reference should logically yield a proxy pointer, which when dereferenced,
-yields a copy of the original proxy reference again.
-
    
-
-
    
-On the other hand, some code truly needs the address of an object, and not a proxy
-(typically for determining the identity of an object compared to a reference object).
-boost has long recognized this dilemma and solved it with 
-boost::addressof.
-It appears to me that this would be useful functionality for the default allocator.  Adopting
-this definition for allocator::address would free the standard of requiring
-anything special from types which overload operator&.  Issue 580
-is expected to make use of allocator::address mandatory for containers.
-
    
-
-
-
-
    Proposed resolution:
    
-
    
-Change 20.6.1.1 [allocator.members]:
-
    
-
-
    
-
    pointer address(reference x) const;
    
-
    
-
    
--1- Returns: &x. The actual address of x,
-even in the presence of an overloaded operator&.
-
    
-
    
-
-
    const_pointer address(address(const_reference x) const;
    
-
    
-
    
--2- Returns: &x. The actual address of x,
-even in the presence of an overloaded operator&.
-
    
-
    
-
    
-
 
    [
-post Oxford:  This would be rendered NAD Editorial by acceptance of
-N2257.
+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
+size() member of every container -- except possibly list -- should be
+O(1). Alan has volunteered to provide wording.
 ]
    
 
 
 
 
 
-
-
 
    
 
    635. domain of allocator::address
    
-
    Section: 20.1.2 [allocator.requirements] Status: New
+
    Section: 20.1.2 [allocator.requirements] Status: Open
  Submitter: Howard Hinnant Date: 2007-02-08
    
 
    View other active issues in [allocator.requirements].
    
 
    View all other issues in [allocator.requirements].
    
-
    View all issues with New status.
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
 The table of allocator requirements in 20.1.2 [allocator.requirements] describes
@@ -8907,54 +8304,22 @@ post Oxford:  This would be rendered NAD Editorial by acceptance of
 ]
    
 
 
+
    [
+Kona (2007):  This issue is section 8 of N2387.  There was some discussion of it but
+no resolution to this issue was recorded.  Moved to Open.
+]
    
 
 
 
 
 
-
    
-
    637. [c.math]/10 inconsistent return values
    
-
    Section: 26.7 [c.math] Status: New
- Submitter: Bo Persson Date: 2007-02-13
    
-
    View other active issues in [c.math].
    
-
    View all other issues in [c.math].
    
-
    View all issues with New status.
    
-
    Discussion:
    
-
    
-26.7 [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.
-
    
-
-
-
    Proposed resolution:
    
-
    
-Change 26.7 [c.math], paragraph 10,
-
    
-
-
    float int ilogb(float);
-float long lrint(float);
-float long lround(float);
-float long long llrint(float);
-float long long llround(float);
-
-long double int ilogb(long double);
-long double long lrint(long double);
-long double long lround(long double);
-long double long long llrint(long double);
-long double long long llround(long double);
-
    
-
-
-
 
 
 
    
 
    638. deque end invalidation during erase
    
-
    Section: 23.2.2.3 [deque.modifiers] Status: New
+
    Section: 23.2.2.3 [deque.modifiers] Status: Review
  Submitter: Steve LoBasso Date: 2007-02-17
    
-
    View all issues with New status.
    
+
    View all issues with Review status.
    
 
    Discussion:
    
 
    
 The standard states at 23.2.2.3 [deque.modifiers]/4:
@@ -8992,901 +8357,672 @@ pop_front() with size() == 1
 
 
    Proposed resolution:
    
 
    
+Change 23.2.2.3 [deque.modifiers], p4:
 
    
 
+
    
+
    iterator erase(const_iterator position); 
+iterator erase(const_iterator first, const_iterator last);
+
    
 
+
    
+
    
+-4- Effects: An erase in the middle of the deque
+invalidates all the iterators and references to elements of the
+deque and the past-the-end iterator. An erase at
+either end of the deque invalidates only the iterators and the
+references to the erased elements, except that erasing at the end
+also invalidates the past-the-end iterator.
+
    
+
    
+
    
 
 
 
-
    
-
    639. Still problems with exceptions during streambuf IO
    
-
    Section: 27.6.1.2.3 [istream::extractors], 27.6.2.6.3 [ostream.inserters] Status: New
- Submitter: Daniel Krügler Date: 2007-02-17
    
-
    View all other issues in [istream::extractors].
    
-
    View all issues with New status.
    
-
    Discussion:
    
-
    
-There already exist two active DR's for the wording of 27.6.1.2.3 [istream::extractors]/13
-from 14882:2003(E), namely 64 and 413.
-
    
+
    [
+Kona (2007): Proposed wording added and moved to Review.
+]
    
 
-
    
-Even with these proposed corrections, already maintained in N2134,
-I have the feeling, that the current wording does still not properly
-handle the "exceptional" situation. The combination of para 14
-
    
 
-
    
-"[..] Characters are extracted and inserted until
-any of the following occurs:
-
    
-
    
-[..]
-
    
-
    
-- an exception occurs (in which case the exception is caught)."
-
    
 
-
    
-and 15
-
    
 
-
    
-"If the function inserts no characters, it calls setstate(failbit),
-which
-may throw ios_base::failure (27.4.4.3). If it inserted no characters
-because it caught an exception thrown while extracting characters
-from *this and failbit is on in exceptions() (27.4.4.3), then the
-caught
-exception is rethrown."
-
    
 
+
    
+
    645. Missing members in match_results
    
+
    Section: 28.10 [re.results] Status: Review
+ Submitter: Daniel Krügler Date: 2007-02-26
    
+
    View other active issues in [re.results].
    
+
    View all other issues in [re.results].
    
+
    View all issues with Review status.
    
+
    Discussion:
    
 
    
-both in N2134 seems to imply that any exception, which occurs
-*after* at least one character has been inserted is caught and lost
-for
-ever. It seems that even if failbit is on in exceptions() rethrow is
-not
-allowed due to the wording "If it inserted no characters because it
-caught an exception thrown while extracting".
+According to the description given in 28.10 [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
+sequence/container tables 80 and 81 one recognizes the following
+missing operations:
 
    
 
 
    
-Is this behaviour by design?
+1) The members
 
    
 
+
    const_iterator rbegin() const;
+const_iterator rend() const;
+
    
+
 
    
-I would like to add that its output counterpart in 27.6.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
-compared to input::
+should exists because 23.1/10 demands these for containers
+(all sequences are containers) which support bidirectional
+iterators. Aren't these supported by match_result? This is not
+explicitely expressed, but it's somewhat implied by two arguments:
 
    
 
    
-1) Paragraph 8 says at its end:
+(a) Several typedefs delegate to
+iterator_traits<BidirectionalIterator>.
 
    
-
-
    
-"- an exception occurs while getting a character from sb."
-
    
-
 
    
-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.
+(b) The existence of const_reference operator[](size_type n) const
+implies even random-access iteration.
+I also suggest, that match_result should explicitly mention,
+which minimum iterator category is supported and if this does
+not include random-access the existence of operator[] is
+somewhat questionable.
 
    
-
 
    
-2) Paragraph 9 says:
+2) The new "convenience" members
 
    
-
-
    
-"If the function inserts no characters, it calls setstate(failbit)
-(which
-may throw ios_base::failure (27.4.4.3)). If an exception was thrown
-while extracting a character, the function sets failbit in error
-state,
-and if failbit is on in exceptions() the caught exception is
-rethrown."
-
    
-
+
    const_iterator cbegin() const;
+const_iterator cend() const;
+const_iterator crbegin() const;
+const_iterator crend() const;
+
    
 
    
-The sentence starting with "If an exception was thrown" seems to
-imply that such an exception *should* be caught before.
+should be added according to tables 80/81.
 
    
 
 
 
    Proposed resolution:
    
 
    
-(a) In 27.6.1.2.3 [istream::extractors]/15 (N2134) change the sentence
+Add the following members to the match_results synopsis after end() in 28.10 [re.results]
+para 3:
 
    
 
-
    
-If the function inserts no characters, it calls
-setstate(failbit), which may throw ios_base::failure
-(27.4.4.3). If it inserted no characters because it caught an
-exception thrown while extracting characters from *this
-an exception was thrown while extracting a character from
-*this, the function sets failbit in error state,
-and failbit is on in exceptions() (27.4.4.3), then the
-caught exception is rethrown.
-
    
+
    const_iterator cbegin() const; 
+const_iterator cend() const;
+
    
 
 
    
-(b) In 27.6.2.6.3 [ostream.inserters]/8 (N2134) change the sentence:
+In section 28.10.3 [re.results.acc] change:
 
    
 
 
    
+
    const_iterator begin() const;
+const_iterator cbegin() const;
+
    
+
    
 
    
-Gets characters from sb and inserts them in *this.
-Characters are read from sb and inserted until any of the
-following occurs:
+-7- Returns: A starting iterator that enumerates over all the sub-expressions stored in *this.
 
    
-
      
-
    • end-of-file occurs on the input sequence;
      • 
-
    • inserting in the output sequence fails (in which case the character to be inserted is not extracted);
      • 
-
    • an exception occurs while getting a character from sb (in which
-case the exception is caught).
      • 
-
    
 
    
 
-
-
-
-
-
-
    
-
    640. 27.6.2.5.2 does not handle (unsigned) long long
    
-
    Section: 27.6.2.6.2 [ostream.inserters.arithmetic] Status: Ready
- Submitter: Daniel Krügler Date: 2007-02-17
    
-
    View all other issues in [ostream.inserters.arithmetic].
    
-
    View all issues with Ready status.
    
-
    Discussion:
    
+
    const_iterator end() const;
+const_iterator cend() const;
+
    
+
    
 
    
-The arithmetic inserters are described in 27.6.2.6.2 [ostream.inserters.arithmetic].
-Although the section starts with a listing of the inserters including
-the new ones:
+-8- Returns: A terminating iterator that enumerates over all the sub-expressions stored in *this.
 
    
+
    
+
    
 
-
    operator<<(long long val );
-operator<<(unsigned long long val );
-
    
 
-
    
-the text in paragraph 1, which describes the corresponding effects
-of the inserters, depending on the actual type of val, does not
-handle the types long long and unsigned long long.
-
    
 
 
    [
-Alisdair: In addition to the (unsigned) long long problem, that whole paragraph
-misses any reference to extended integral types supplied by the
-implementation - one of the additions by core a couple of working papers
-back.
+Kona (2007): Voted to adopt proposed wording in
+N2409
+except removing the entry in the table container requirements.  Moved to Review.
 ]
    
 
 
 
 
-
    Proposed resolution:
    
-
    
-In 27.6.2.6.2 [ostream.inserters.arithmetic]/1 change the third sentence
-
    
-
-
    
-When val is of type bool, long, unsigned
-long, long long, unsigned long long, double,
-long double, or const void*, the formatting conversion
-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: Ready
- Submitter: Daniel Krügler Date: 2007-02-20
    
-
    View all issues with Ready status.
    
+
    653. Library reserved names
    
+
    Section: 1.2 [intro.refs] Status: Open
+ Submitter: Alisdair Meredith Date: 2007-03-08
    
+
    View all other issues in [intro.refs].
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
-The current standard 14882:2003(E) as well as N2134 have the
-following
-defects:
-
    
-
-
    
-27.8.1.1 [filebuf]/5 says:
 
    
-
 
    
 
    
-In order to support file I/O and multibyte/wide character conversion, conversions are performed using members of a 
-facet, referred to as a_codecvt in following sections, obtained "as if" by
-
    
-
    codecvt<charT,char,typename traits::state_type> a_codecvt =
-  use_facet<codecvt<charT,char,typename traits::state_type> >(getloc());
-
    
-
    
-
-
    
-use_facet returns a const facet reference and no facet is
-copyconstructible, so the codecvt construction should fail to compile.
+1.2 [intro.refs] Normative references
 
    
 
 
    
-A similar issue arises in 22.2.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
+The following standards contain provisions which, through reference in
+this text, constitute provisions of this Interna- tional Standard. At
+the time of publication, the editions indicated were valid. All
+standards are subject to revision, and parties to agreements based on
+this International Standard are encouraged to investigate the
+possibility of applying the most recent editions of the standards
+indicated below. Members of IEC and ISO maintain registers of currently
+valid International Standards.
 
    
 
-
    const codecvt<charT,char,typename traits::state_type>& a_codecvt =
-  use_facet<codecvt<charT,char,typename traits::state_type> >(getloc());
-
    
-
-
    
-In 22.2.2.2.2 [facet.num.put.virtuals]/15 (This is para 5 in N2134) change
-
    
+
      
+
    • Ecma International, ECMAScript Language Specification, Standard
+Ecma-262, third edition, 1999.
      • 
+
    • ISO/IEC 2382 (all parts), Information technology - Vocabulary
      • 
+
    • ISO/IEC 9899:1990, Programming languages - C
      • 
+
    • ISO/IEC 9899/Amd.1:1995, Programming languages - C, AMENDMENT 1: C
+Integrity
      • 
+
    • ISO/IEC 9899:1999, Programming languages - C
      • 
+
    • ISO/IEC 9899:1999/Cor.1:2001 Programming languages - C
      • 
+
    • ISO/IEC 9899:1999/Cor.2:2004 Programming languages - C
      • 
+
    • ISO/IEC 9945:2003, Information Technology-Portable Operating System
+Interface (POSIX)
      • 
+
    • ISO/IEC 10646-1:1993 Information technology - Universal Multiple-Octet
+Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual
+Plane
      • 
+
    
+
 
-
    
 
    
-A local variable punct is initialized via
+I'm not sure how many of those reserve naming patterns that might affect
+us, but I am equally sure I don't own a copy of any of these to check!
 
    
-
    const numpunct<charT>& punct = use_facet< numpunct<charT> >(str.getloc() );
-
    
-
    
-
 
    
-(Please note also the additional provided trailing semicolon)
+The point is to list the reserved naming patterns, rather than the
+individual names themselves - although we may want to list C keywords
+that are valid identifiers in C++ but likely to cause trouble in shared
+headers (e.g. restrict)
 
    
 
+
    [
+Kona (2007): Recommend NAD.  No one has identified a specific defect, just the possibility of one.
+]
    
 
 
+
    [
+Post-Kona: Alisdair request Open. A good example of the problem was a
+discussion of the system error proposal, where it was pointed out an all-caps
+identifier starting with a capital E conflicted with reserved macro names for
+both Posix and C.  I had absolutely no idea of this rule, and suspect I was
+not the only one in the room.
    
+
    
+Resolution will require someone with access to all the listed documents to
+research their respective name reservation rules, or people with access to
+specific documents add their rules to this issue until the list is complete.
+]
    
 
 
 
-
    
-
    644. Possible typos in 'function' description
    
-
    Section: 20.5.14.2.6 [func.wrap.func.undef] Status: Ready
- Submitter: Bo Persson Date: 2007-02-25
    
-
    View all issues with Ready status.
    
-
    Discussion:
    
-
    
-20.5.14.2.6 [func.wrap.func.undef]
-
    
-
    
-The note in paragraph 2 refers to 'undefined void operators', while the 
-section declares a pair of operators returning bool.
-
    
-
 
 
    Proposed resolution:
    
-
    
-Change 20.5.14.2 [func.wrap.func]
-
    
-
-
    ...
-private:
-   // 20.5.14.2.6 [func.wrap.func.undef], undefined operators:
-   template<class Function2> bool void operator==(const function<Function2>&);
-   template<class Function2> bool void operator!=(const function<Function2>&);
-};
-
    
-
-
    
-Change 20.5.14.2.6 [func.wrap.func.undef]
-
    
-
-
    template<class Function2> bool void operator==(const function<Function2>&);
-template<class Function2> bool void operator!=(const function<Function2>&);
-
    
 
 
 
 
 
 
    
-
    645. Missing members in match_results
    
-
    Section: 28.10 [re.results] Status: New
- Submitter: Daniel Krügler Date: 2007-02-26
    
-
    View other active issues in [re.results].
    
-
    View all other issues in [re.results].
    
-
    View all issues with New status.
    
+
    659. istreambuf_iterator should have an operator->()
    
+
    Section: 24.5.3 [istreambuf.iterator] Status: Open
+ Submitter: Niels Dekker Date: 2007-03-25
    
+
    View all other issues in [istreambuf.iterator].
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
-According to the description given in 28.10 [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
-sequence/container tables 80 and 81 one recognizes the following
-missing operations:
+Greg Herlihy has clearly demonstrated that a user defined input
+iterator should have an operator->(), even if its
+value type is a built-in type (comp.std.c++, "Re: Should any iterator
+have an operator->() in C++0x?", March 2007).  And as Howard
+Hinnant remarked in the same thread that the input iterator
+istreambuf_iterator doesn't have one, this must be a
+defect!
 
    
-
 
    
-1) The members
-
    
+Based on Greg's example, the following code demonstrates the issue:
+
     #include <iostream> 
+ #include <fstream>
+ #include <streambuf> 
 
-
    const_iterator rbegin() const;
-const_iterator rend() const;
-
    
+ typedef char C;
+ int main ()
+ {
+   std::ifstream s("filename", std::ios::in);
+   std::istreambuf_iterator<char> i(s);
+
+   (*i).~C();  // This is well-formed...
+   i->~C();  // ... so this should be supported!
+ }
+
    
 
 
    
-should exists because 23.1/10 demands these for containers
-(all sequences are containers) which support bidirectional
-iterators. Aren't these supported by match_result? This is not
-explicitely expressed, but it's somewhat implied by two arguments:
-
    
-
    
-(a) Several typedefs delegate to
-iterator_traits<BidirectionalIterator>.
-
    
-
    
-(b) The existence of const_reference operator[](size_type n) const
-implies even random-access iteration.
-I also suggest, that match_result should explicitly mention,
-which minimum iterator category is supported and if this does
-not include random-access the existence of operator[] is
-somewhat questionable.
+Of course, operator-> is also needed when the value_type of
+istreambuf_iterator is a class.
 
    
 
    
-2) The new "convenience" members
+The operator-> could be implemented in various ways.  For instance,
+by storing the current value inside the iterator, and returning its
+address.  Or by returning a proxy, like operator_arrow_proxy, from
+http://www.boost.org/boost/iterator/iterator_facade.hpp
 
    
-
    const_iterator cbegin() const;
-const_iterator cend() const;
-const_iterator crbegin() const;
-const_iterator crend() const;
-
    
 
    
-should be added according to tables 80/81.
+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++();
+
    
 
-
-
-
-
    
-
    646. const incorrect match_result members
    
-
    Section: 28.10.4 [re.results.form] Status: Ready
- Submitter: Daniel Krügler Date: 2007-02-26
    
-
    View all issues with Ready status.
    
-
    Discussion:
    
-
    
-28.10.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.
-
    
-
-
-
    Proposed resolution:
    
 
    
-Add the missing const specifier to both format overloads described
-in section 28.10.4 [re.results.form].
+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,
+but the proposed text also states that "operator-> may return a proxy."
+]
    
 
-
    
-
    647. Inconsistent regex_search params
    
-
    Section: 28.11.3 [re.alg.search] Status: New
- Submitter: Daniel Krügler Date: 2007-02-26
    
-
    View all issues with New status.
    
-
    Discussion:
    
-
    
-28.11.3 [re.alg.search]/5 declares
-
    
 
-
    template <class iterator, class charT, class traits>
-bool regex_search(iterator first, iterator last,
-                  const basic_regex<charT, traits>& e,
-                  regex_constants::match_flag_type flags =
-                      regex_constants::match_default);
-
    
+
    [
+Niels Dekker (mailed to Howard Hinnant):
+]
    
 
+
    
 
    
-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:
+The proposed resolution does
+not seem inconsistent to me. istreambuf_iterator::operator->() should
+have istreambuf_iterator::pointer as return type, and this return type
+may in fact be a proxy.
 
    
-
-
    template <class BidirectionalIterator, class charT, class traits>
-bool regex_search(BidirectionalIterator first, BidirectionalIterator last,
-                  const basic_regex<charT, traits>& e,
-                  regex_constants::match_flag_type flags =
-                      regex_constants::match_default);
-
    
-
-
-
    Proposed resolution:
    
 
    
-In 28.11.3 [re.alg.search]/5 replace all three occurences of param "iterator" with
-"BidirectionalIterator"
+AFAIK, the resolution of 445 ("iterator_traits::reference
+unspecified for some iterator categories") implies that for any iterator
+class Iter, the return type of operator->() is Iter::pointer, by
+definition.  I don't think Iter::pointer needs to be a raw pointer.
 
    
-
-
    template <class iterator BidirectionalIterator, class charT, class traits>
-  bool regex_search(iterator BidirectionalIterator first, iterator BidirectionalIterator last, 
-                    const basic_regex<charT, traits>& e, 
-                    regex_constants::match_flag_type flags = 
-                      regex_constants::match_default);
-
    
 
    
--6- Effects: Behaves "as if" by constructing an object what of
-type match_results<iterator
-BidirectionalIterator> and then returning the result
-of regex_search(first, last, what, e, flags).
+Still I wouldn't mind if the text "operator-> may return a proxy" would
+be removed from the resolution. I think it's up to the library
+implementation, how to implement istreambuf_iterator::operator->().  As
+longs as it behaves as expected: i->m should have the same effect as
+(*i).m. Even for an explicit destructor call, i->~C().  The main issue
+is just: istreambuf_iterator should have an operator->()!
 
    
 
    
 
 
 
 
-
 
    
-
    650. regex_token_iterator and const correctness
    
-
    Section: 28.12.2 [re.tokiter] Status: New
- Submitter: Daniel Krügler Date: 2007-03-05
    
-
    View all other issues in [re.tokiter].
    
-
    View all issues with New status.
    
+
    661. New 27.6.1.2.2 changes make special extractions useless
    
+
    Section: 27.6.1.2.2 [istream.formatted.arithmetic] Status: Ready
+ Submitter: Daniel Krügler Date: 2007-04-01
    
+
    View other active issues in [istream.formatted.arithmetic].
    
+
    View all other issues in [istream.formatted.arithmetic].
    
+
    View all issues with Ready 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
-[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).
+
    
+To the more drastic changes of 27.6.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.
 
    
 
+
      
+
    1. 
+The corresponding as-if extractions in paragraph 2 and 3 will never
+result in a change of the operator>> argument val, because the
+contents of the local variable lval is in no case written into val.
+Furtheron both fragments need a currently missing parentheses in the
+beginning of the if-statement to be valid C++.
+
      2. 
+
    2. 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
+an
+oversight.
+
      3. 
+
    
+
 
 
    Proposed resolution:
    
+
      
+
    1. 
 
      
-1) In (28.12.2 [re.tokiter]/6) change the current declarations
+In 27.6.1.2.2 [istream.formatted.arithmetic]/2 change the current as-if code fragment
 
      
-
-
      bool operator==(const regex_token_iterator&) const;
-bool operator!=(const regex_token_iterator&) const;
-const value_type& operator*() const;
-const value_type* operator->() const;
+
      typedef num_get<charT,istreambuf_iterator<charT,traits> > numget;
+iostate err = 0;
+long lval;
+use_facet<numget>(loc).get(*this, 0, *this, err, lval );
+if (err == 0) {
+  && if (lval < numeric_limits<short>::min() || numeric_limits<short>::max() < lval))
+      err = ios_base::failbit;
+  else
+    val = static_cast<short>(lval);
+}
+setstate(err);
 
      
 
 
      
-2) In 28.12.2.2 [re.tokiter.comp] change the following declarations
+Similarily in 27.6.1.2.2 [istream.formatted.arithmetic]/3 change the current as-if fragment
 
      
 
-
      bool operator==(const regex_token_iterator& right) const;
-bool operator!=(const regex_token_iterator& right) const;
+
      typedef num_get<charT,istreambuf_iterator<charT,traits> > numget;
+iostate err = 0;
+long lval;
+use_facet<numget>(loc).get(*this, 0, *this, err, lval );
+if (err == 0) {
+  && if (lval < numeric_limits<int>::min() || numeric_limits<int>::max() < lval))
+      err = ios_base::failbit;
+  else
+    val = static_cast<int>(lval);
+}
+setstate(err);
 
      
+
      2. 
+
    2. 
+---
+
      3. 
+
    
 
-
    
-3) In 28.12.2.3 [re.tokiter.deref] change the following declarations
-
    
-
-
    const value_type& operator*() const;
-const value_type* operator->() const;
-
    
+
+
    [
+Kona (2007): Note to the editor: the name lval in the call to use_facet
+is incorrectly italicized in the code fragments corresponding to
+operator>>(short &) and operator >>(int &). Also, val -- which appears
+twice on the line with the static_cast in the proposed resolution --
+should be italicized. Also, in response to part two of the issue: this
+is deliberate.
+]
    
 
 
 
 
 
 
    
-
    651. Missing preconditions for regex_token_iterator c'tors
    
-
    Section: 28.12.2.1 [re.tokiter.cnstr] Status: New
- Submitter: Daniel Krügler Date: 2007-03-05
    
-
    View all other issues in [re.tokiter.cnstr].
    
-
    View all issues with New status.
    
+
    664. do_unshift for codecvt<char, char, mbstate_t>
    
+
    Section: 22.2.1.4.2 [locale.codecvt.virtuals] Status: Ready
+ Submitter: Thomas Plum Date: 2007-04-16
    
+
    View other active issues in [locale.codecvt.virtuals].
    
+
    View all other issues in [locale.codecvt.virtuals].
    
+
    View all issues with Ready status.
    
 
    Discussion:
    
 
    
-The text provided in 28.12.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
-the notion of a "current match" by saying:
+22.2.1.4.2 [locale.codecvt.virtuals], para 7 says (regarding do_unshift):
 
    
 
 
    
-The current match is (*position).prefix() if subs[N]
-== -1, or (*position)[subs[N]] for any other value of
-subs[N].
+Effects: Places characters starting at to that should be appended to
+terminate a sequence when the current stateT is given by
+state.237) Stores no more than (to_limit -
+to) destination elements, and leaves the to_next
+pointer pointing one beyond the last element successfully stored.
+codecvt<char, char, mbstate_t> stores no characters.
 
    
 
 
    
-It's not clear to me, whether other negative values except -1
-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:
+The following objection has been raised:
 
    
 
 
    
-Requires: Each of the initialization values of subs must be >= -1.
+Since the C++ Standard permits a nontrivial conversion for the required
+instantiations of codecvt, it is overly restrictive to say that
+do_unshift must store no characters and return noconv.
 
    
 
-
-
-
-
-
    
-
    652. regex_iterator and const correctness
    
-
    Section: 28.12.1 [re.regiter] Status: New
- Submitter: Daniel Krügler Date: 2007-03-05
    
-
    View all issues with New 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)
-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).
-
    
-
-
-
    Proposed resolution:
    
 
    
-1) In (28.12.1 [re.regiter]/1) change the current declarations
+[Plum ref _222152Y50]
 
    
 
-
    bool operator==(const regex_iterator&) const;
-bool operator!=(const regex_iterator&) const;
-const value_type& operator*() const;
-const value_type* operator->() const;
-
    
 
+
    Proposed resolution:
    
 
    
-2) In 28.12.1.3 [re.regiter.deref] change the following declarations
+Change 22.2.1.4.2 [locale.codecvt.virtuals], p7:
 
    
 
-
    const value_type& operator*() const;
-const value_type* operator->() const;
-
    
-
+
    
 
    
-3) In 28.12.1.2 [re.regiter.comp] change the following declarations
+Effects: Places characters starting at to that should be
+appended to terminate a sequence when the current stateT is
+given by state.237) Stores no more than (to_limit -to)
+destination elements, and leaves the to_next pointer pointing one
+beyond the last element successfully stored. codecvt<char, char,
+mbstate_t> stores no characters.
 
    
-
-
    bool operator==(const regex_iterator& right) const;
-bool operator!=(const regex_iterator& right) const;
-
    
+
    
 
 
 
 
 
 
    
-
    653. Library reserved names
    
-
    Section: 1.2 [intro.refs] Status: New
- Submitter: Alisdair Meredith Date: 2007-03-08
    
-
    View all other issues in [intro.refs].
    
-
    View all issues with New status.
    
+
    665. do_unshift return value
    
+
    Section: 22.2.1.4.2 [locale.codecvt.virtuals] Status: Ready
+ Submitter: Thomas Plum Date: 2007-04-16
    
+
    View other active issues in [locale.codecvt.virtuals].
    
+
    View all other issues in [locale.codecvt.virtuals].
    
+
    View all issues with Ready status.
    
 
    Discussion:
    
 
    
+22.2.1.4.2 [locale.codecvt.virtuals], para 8 says:
 
    
-
    
+
+
    
+codecvt<char,char,mbstate_t>, returns noconv.
+
    
+
 
    
-1.2 [intro.refs] Normative references
+The following objection has been raised:
 
    
 
+
    
+Despite what the C++ Standard 
+says, unshift can't always return noconv for the default facets, since 
+they can be nontrivial. At least one implementation does whatever the 
+C functions do.
+
    
+
 
    
-The following standards contain provisions which, through reference in
-this text, constitute provisions of this Interna- tional Standard. At
-the time of publication, the editions indicated were valid. All
-standards are subject to revision, and parties to agreements based on
-this International Standard are encouraged to investigate the
-possibility of applying the most recent editions of the standards
-indicated below. Members of IEC and ISO maintain registers of currently
-valid International Standards.
+[Plum ref _222152Y62]
 
    
 
-
      
-
    • Ecma International, ECMAScript Language Specification, Standard
-Ecma-262, third edition, 1999.
      • 
-
    • ISO/IEC 2382 (all parts), Information technology - Vocabulary
      • 
-
    • ISO/IEC 9899:1990, Programming languages - C
      • 
-
    • ISO/IEC 9899/Amd.1:1995, Programming languages - C, AMENDMENT 1: C
-Integrity
      • 
-
    • ISO/IEC 9899:1999, Programming languages - C
      • 
-
    • ISO/IEC 9899:1999/Cor.1:2001 Programming languages - C
      • 
-
    • ISO/IEC 9899:1999/Cor.2:2004 Programming languages - C
      • 
-
    • ISO/IEC 9945:2003, Information Technology-Portable Operating System
-Interface (POSIX)
      • 
-
    • ISO/IEC 10646-1:1993 Information technology - Universal Multiple-Octet
-Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual
-Plane
      • 
-
    
-
    
 
+
    Proposed resolution:
    
 
    
-I'm not sure how many of those reserve naming patterns that might affect
-us, but I am equally sure I don't own a copy of any of these to check!
+Change 22.2.1.4.2 [locale.codecvt.virtuals], p8:
 
    
+
+
    
+
    Returns: An enumeration value, as summarized in Table 76:
    
+
    ...
    
 
    
-The point is to list the reserved naming patterns, rather than the
-individual names themselves - although we may want to list C keywords
-that are valid identifiers in C++ but likely to cause trouble in shared
-headers (e.g. restrict)
+codecvt<char,char,mbstate_t>, returns noconv.
 
    
+
    
 
 
-
    Proposed resolution:
    
-
 
 
 
 
 
    
-
    654. Missing IO roundtrip for random number engines
    
-
    Section: 26.4.1.3 [rand.req.eng] Status: New
- Submitter: Daniel Krügler Date: 2007-03-08
    
-
    View other active issues in [rand.req.eng].
    
-
    View all other issues in [rand.req.eng].
    
-
    View all issues with New status.
    
+
    666. moneypunct::do_curr_symbol()
    
+
    Section: 22.2.6.3.2 [locale.moneypunct.virtuals] Status: Ready
+ Submitter: Thomas Plum Date: 2007-04-16
    
+
    View all other issues in [locale.moneypunct.virtuals].
    
+
    View all issues with Ready status.
    
 
    Discussion:
    
 
    
-Table 98 and para 5 in 26.4.1.3 [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
-from para 5:
+22.2.6.3.2 [locale.moneypunct.virtuals], para 4 footnote 257 says
 
    
 
 
    
-If a textual representation written via os << x was
-subsequently read via is >> v, then x == v provided that
-there have been no intervening invocations of x or of v.
+257) For international 
+specializations (second template parameter true) this is always four 
+characters long, usually three letters and a space.
 
    
 
 
    
-The problem is, that the extraction process described in
-table 98 misses to specify that it will initially set the
-if.fmtflags to ios_base::dec, see table 104:
+The following objection has been raised:
 
    
 
 
    
-dec: converts integer input or generates integer output
-in decimal base
+The international currency 
+symbol is whatever the underlying locale says it is, not necessarily 
+four characters long.
 
    
 
 
    
-Proof: The following small program demonstrates the violation
-of requirements (exception safety not fulfilled):
+[Plum ref _222632Y41]
 
    
 
-
    #include <cassert>
-#include <ostream>
-#include <iostream>
-#include <iomanip>
-#include <sstream>
 
-class RanNumEngine {
-  int state;
-public:
-  RanNumEngine() : state(42) {}
+
    Proposed resolution:
    
+
    
+Change footnote 253 in 22.2.6.3.2 [locale.moneypunct.virtuals]:
+
    
 
-  bool operator==(RanNumEngine other) const {
-	  return state == other.state;
-  }
+
    
+
    
+253) For international specializations (second template
+parameter true) this is always typically
+four characters long, usually three letters and a space.
+
    
+
    
 
-  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;
-  }
 
-  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;
-  }
-};
 
-int main() {
-	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
-}
-
    
 
+
    
+
    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
    
+
    View other active issues in [locale.money.get.virtuals].
    
+
    View all other issues in [locale.money.get.virtuals].
    
+
    View all issues with Open status.
    
+
    Discussion:
    
 
    
-A second, minor issue seems to be, that the insertion
-description from table 98 unnecessarily requires the
-addition of ios_base::fixed (which only influences floating-point
-numbers). Its not entirely clear to me whether the proposed
-standard does require that the state of random number engines
-is stored in integral types or not, but I have the impression
-that this is the indent, see e.g. p. 3
+22.2.6.1.2 [locale.money.get.virtuals], para 1 says:
 
    
 
 
    
-The specification of each random number engine defines the
-size of its state in multiples of the size of its result_type.
+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.
 
    
 
 
    
-If other types than integrals are supported, then I wonder why
-no requirements are specified for the precision of the stream.
-
    
-
-
-
    Proposed resolution:
    
-
    
-1) In table 98 from 26.4.1.3 [rand.req.eng] in column "pre/post-condition",
-row expression "is >> x" change
+The following
+objection has been raised:
 
    
 
 
    
-Sets v's state as determined by
-reading its textual representation
-with is.fmtflags set to ios_base::dec
-from is.
+Some implementations interpret this to mean that a facet derived from
+ctype<wchar_t> can provide its own member do_widen(char)
+which produces e.g. L'@' for the "widened" minus sign, and that the
+'@' symbol will appear in the resulting sequence of digits.  Other
+implementations have assumed that one or more places in the standard permit the
+implementation to "hard-wire" L'-' as the "widened" minus sign.  Are
+both interpretations permissible, or only  one?
 
    
 
 
    
-2) In table 98 from 26.4.1.3 [rand.req.eng] in column "pre/post-condition",
-row expression "os << x" change
+[Plum ref _222612Y14]
 
    
 
-
    
-With os.fmtflags set to
-ios_base::dec|ios_base::fixed|ios_base::left and[..]
-
    
-
-
-
-
-
-
    
-
    655. Signature of generate_canonical not useful
    
-
    Section: 26.4.7.2 [rand.util.canonical] Status: New
- Submitter: Daniel Krügler Date: 2007-03-08
    
-
    View all issues with New status.
    
-
    Discussion:
    
 
    
-In 26.4.2 [rand.synopsis] we have the declaration
+Furthermore: if ct.widen('9') produces L'X' (a non-digit), does a
+parse fail if a '9' appears in the subject string? [Plum ref _22263Y33]
 
    
 
-
    template<class RealType, class UniformRandomNumberGenerator,
-  size_t bits>
-result_type generate_canonical(UniformRandomNumberGenerator& g);
-
    
+
    [
+Kona (2007): Bill and Dietmar to provide proposed wording.
+]
    
 
-
    
-Besides the "result_type" issue (already recognized by Bo Persson
-at Sun, 11 Feb 2007 05:26:47 GMT in this group) it's clear, that
-the template parameter order is not reasonably choosen: Obviously
-one always needs to specify all three parameters, although usually
-only two are required, namely the result type RealType and the
-wanted bits, because UniformRandomNumberGenerator can usually
-be deduced.
-
    
 
 
 
    Proposed resolution:
    
 
    
-In the header <random> synopsis 26.4.2 [rand.synopsis] as well as in the corresponding
-function description in 26.4.7.2 [rand.util.canonical]26.4.7.2 between para 2 and 3 change the
-declaration
 
    
 
-
    template<class RealType, class UniformRandomNumberGenerator, size_t bits, class UniformRandomNumberGenerator>
-RealType generate_canonical(UniformRandomNumberGenerator& g);
-
    
-
-
 
 
 
 
 
    
-
    657. unclear requirement about header inclusion
    
-
    Section: 17.4.2.1 [using.headers] Status: New
- Submitter: Gennaro Prota Date: 2007-03-14
    
-
    View all issues with New status.
    
+
    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
    
+
    View other active issues in [locale.money.get.virtuals].
    
+
    View all other issues in [locale.money.get.virtuals].
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
-17.4.2.1 [using.headers] states:
+22.2.6.1.2 [locale.money.get.virtuals], para 3 says:
 
    
 
 
    
-A translation unit shall include a header only outside of any
-external declaration or definition, [...]
+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.
 
    
 
 
    
-I see three problems with this requirement:
+The following
+objection has been raised:
 
    
 
-
      
-
    1. The C++ standard doesn't define what an "external declaration" or
-an "external definition" are (incidentally the C99 standard does, and
-has a sentence very similar to the above regarding header inclusion).
-
      
-I think the intent is that the #include directive shall lexically
-appear outside *any* declaration; instead, when the issue was pointed
-out on comp.std.c++ at least one poster interpreted "external
-declaration" as "declaration of an identifier with external linkage".
-If this were the correct interpretation, then the two inclusions below
-would be legal:
-
      
-
        // at global scope
-  static void f()
-  {
-# include <cstddef>
-  }
+
      
+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".
+
      
 
-  static void g()
-  {
-# include <stddef.h>
-  }
-
      
 
      
-(note that while the first example is unlikely to compile correctly,
-the second one may well do)
-
      2. 
-
-
    2. as the sentence stands, violations will require a diagnostic; is
-this the intent? It was pointed out on comp.std.c++ (by several
-posters) that at least one way to ensure a diagnostic exists:
-
      
-
      
-   [If there is an actual file for each header,] one simple way
-   to implement this would be to insert a reserved identifier
-   such as __begin_header  at the start of each standard header.
-   This reserved identifier would be ignored for all other
-   purposes, except that, at the appropriate point in phase 7, if
-   it is found inside an external definition, a diagnostic is
-   generated. There's many other similar ways to achieve the same
-   effect.
-   
      
-
                                       --James Kuyper, on comp.std.c++
-
      3. 
-
-
    3. is the term "header" meant to be limited to standard headers?
-Clause 17 is all about the library, but still the general question is
-interesting and affects one of the points in the explicit namespaces
-proposal (n1691):
+[Plum ref _222612Y32]
 
      
-
      
-    Those seeking to conveniently enable argument-dependent
-    lookups for all operators within an explicit namespace
-    could easily create a header file that does so:
-
          namespace mymath::
-    {
-        #include "using_ops.hpp"
-    }
-
      
-
      4. 
-
    
+
+
    [
+Kona (2007): Bill to provide proposed wording and interpretation of existing wording.
+]
    
+
+
 
 
 
    Proposed resolution:
    
@@ -9898,430 +9034,156 @@ proposal (658. Two unspecified function comparators in [function.objects]
-
    Section: 20.5 [function.objects] Status: New
- Submitter: Daniel Krügler Date: 2007-03-19
    
-
    View other active issues in [function.objects].
    
-
    View all other issues in [function.objects].
    
-
    View all issues with New status.
    
+
    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
    
+
    View other active issues in [locale.money.get.virtuals].
    
+
    View all other issues in [locale.money.get.virtuals].
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
-The header <functional> synopsis in 20.5 [function.objects]
-contains the following two free comparison operator templates
-for the function class template
+22.2.6.1.2 [locale.money.get.virtuals], para 3 sentence 4 says:
 
    
 
-
    template<class Function1, class Function2>
-void operator==(const function<Function1>&, const function<Function2>&);
-template<class Function1, class Function2>
-void operator!=(const function<Function1>&, const function<Function2>&);
-
    
+
    
+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.
+
    
 
 
    
-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.5.14.2 [func.wrap.func] and 20.5.14.2.6 [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.
+One interpretation is that an input sequence must match either the
+positive pattern or the negative pattern, and then in either event it
+is interpreted as positive.  The following objections has been raised:
 
    
 
+
    
+The input can successfully match only a positive sign, so the negative
+pattern is an unsuccessful match.
+
    
 
-
    Proposed resolution:
    
 
    
-Remove the above mentioned two function templates from
-the header <functional> synopsis (20.5 [function.objects])
+[Plum ref _222612Y34, 222612Y51b]
 
    
 
-
    template<class Function1, class Function2>
-void operator==(const function<Function1>&, const function<Function2>&);
-template<class Function1, class Function2>
-void operator!=(const function<Function1>&, const function<Function2>&);
-
    
+
    [
+Bill to provide proposed wording and interpretation of existing wording.
+]
    
 
 
 
 
+
    Proposed resolution:
    
+
    
+
    
 
 
-
    
-
    659. istreambuf_iterator should have an operator->()
    
-
    Section: 24.5.3 [istreambuf.iterator] Status: New
- Submitter: Niels Dekker Date: 2007-03-25
    
-
    View all other issues in [istreambuf.iterator].
    
-
    View all issues with New status.
    
-
    Discussion:
    
-
    
-Greg Herlihy has clearly demonstrated that a user defined input
-iterator should have an operator->(), even if its
-value type is a built-in type (comp.std.c++, "Re: Should any iterator
-have an operator->() in C++0x?", March 2007).  And as Howard
-Hinnant remarked in the same thread that the input iterator
-istreambuf_iterator doesn't have one, this must be a
-defect!
-
    
-
    
-Based on Greg's example, the following code demonstrates the issue:
-
     #include <iostream> 
- #include <fstream>
- #include <streambuf> 
-
- typedef char C;
- int main ()
- {
-   std::ifstream s("filename", std::ios::in);
-   std::istreambuf_iterator<char> i(s);
-
-   (*i).~C();  // This is well-formed...
-   i->~C();  // ... so this should be supported!
- }
-
    
 
-
    
-Of course, operator-> is also needed when the value_type of
-istreambuf_iterator is a class.
-
    
-
    
-The operator-> could be implemented in various ways.  For instance,
-by storing the current value inside the iterator, and returning its
-address.  Or by returning a proxy, like operator_arrow_proxy, from
-http://www.boost.org/boost/iterator/iterator_facade.hpp
-
    
-
    
-I hope that the resolution of this issue will contribute to getting a
-clear and consistent definition of iterator concepts.
-
    
 
 
-
    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.
    
+
    Discussion:
    
 
    
-Add to the synopsis in 24.5.3 [istreambuf.iterator]:
+22.2.6.3 [locale.moneypunct], para 2 says:
 
    
 
-
    charT operator*() const;
-pointer operator->() const;
-istreambuf_iterator<charT,traits>& operator++();
-
    
+
    
+The value space indicates that at least one space is required at 
+that position.
+
    
 
 
    
-Change 24.5.3 [istreambuf.iterator], p1:
+The following objection has been raised:
 
    
 
 
    
-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.
+Whitespace is optional when matching space. (See 22.2.6.1.2 [locale.money.get.virtuals], para 2.)
 
    
 
-
-
-
-
-
-
    
-
    660. Missing Bitwise Operations
    
-
    Section: 20.5 [function.objects] Status: New
- Submitter: Beman Dawes Date: 2007-04-02
    
-
    View other active issues in [function.objects].
    
-
    View all other issues in [function.objects].
    
-
    View all issues with New status.
    
-
    Discussion:
    
-
    Section 20.5 [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 
-were discussed. Bjarne Stroustrup commented "Why standardize what isn't used? 
-Yes, I see the chicken and egg problems here, but it would be nice to see a 
-couple of genuine uses before making additions."
    
-
    A number of libraries, including Rogue Wave, GNU, Adobe ASL, and Boost, have 
-already added these functions, either publicly or for internal use. For example, 
-Doug Gregor commented: "Boost will also add ... (|, &, ^) in 1.35.0, because we 
-need those function
-objects to represent various parallel 
-collective operations (reductions, prefix reductions, etc.) in the new Message 
-Passing Interface (MPI) library."
    
-
    Because the bitwise operators have the strongest use cases, the proposed 
-resolution is limited to them.
    
-
-
-
    Proposed resolution:
    
-
    To 20.5 [function.objects], Function objects, paragraph 2, add to the header 
-<functional> synopsis:
    
-
    
-  
    template <class T> struct bit_and;
-template <class T> struct bit_or;
-template <class T> struct bit_xor;
    
-
    
-
    At a location in clause 20 to be determined by the Project Editor, add:
    
-
    
-  
    The library provides basic function object classes for all of the bitwise 
-  operators in the language ([expr.bit.and], [expr.or], [exp.xor]).
    
-  
    template <class T> struct bit_and : binary_function<T,T,T> {
-  T operator()(const T& x , const T& y ) const;
-};
    
-  
    
-    
    operator() returns x & y .
    
-  
    
-  
    template <class T> struct bit_or : binary_function<T,T,T> {
-  T operator()(const T& x , const T& y ) const;
-};
    
-  
    
-    
    operator() returns x | y .
    
-  
    
-  
    template <class T> struct bit_xor : binary_function<T,T,T> {
-  T operator()(const T& x , const T& y ) const;
-};
    
-  
    
-    
    operator() returns x ^ y .
    
-  
    
-
    
-
-
-
-
-
-
    
-
    661. New 27.6.1.2.2 changes make special extractions useless
    
-
    Section: 27.6.1.2.2 [istream.formatted.arithmetic] Status: New
- Submitter: Daniel Krügler Date: 2007-04-01
    
-
    View other active issues in [istream.formatted.arithmetic].
    
-
    View all other issues in [istream.formatted.arithmetic].
    
-
    View all issues with New status.
    
-
    Discussion:
    
 
    
-To the more drastic changes of 27.6.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.
+[Plum ref _22263Y22]
 
    
 
-
      
-
    1. 
-The corresponding as-if extractions in paragraph 2 and 3 will never
-result in a change of the operator>> argument val, because the
-contents of the local variable lval is in no case written into val.
-Furtheron both fragments need a currently missing parentheses in the
-beginning of the if-statement to be valid C++.
-
      2. 
-
    2. 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
-an
-oversight.
-
      3. 
-
    
+
    [
+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:
    
-
      
-
    1. 
-
      
-In 27.6.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;
-long lval;
-use_facet<numget>(loc).get(*this, 0, *this, err, lval );
-if (err == 0) {
-  && if (lval < numeric_limits<short>::min() || numeric_limits<short>::max() < lval))
-      err = ios_base::failbit;
-  else
-    val = static_cast<short>(lval);
-}
-setstate(err);
-
      
 
+
+
      Proposed resolution:
      
 
      
-Similarily in 27.6.1.2.2 [istream.formatted.arithmetic]/3 change the current as-if fragment
 
      
 
-
      typedef num_get<charT,istreambuf_iterator<charT,traits> > numget;
-iostate err = 0;
-long lval;
-use_facet<numget>(loc).get(*this, 0, *this, err, lval );
-if (err == 0) {
-  && if (lval < numeric_limits<int>::min() || numeric_limits<int>::max() < lval))
-      err = ios_base::failbit;
-  else
-    val = static_cast<int>(lval);
-}
-setstate(err);
-
      
-
      2. 
-
    2. 
----
-
      3. 
-
    
-
 
 
 
 
 
    
-
    662. Inconsistent handling of incorrectly-placed thousands separators
    
-
    Section: 22.2.2.1.2 [facet.num.get.virtuals] Status: New
- Submitter: Cosmin Truta Date: 2007-04-05
    
-
    View other active issues in [facet.num.get.virtuals].
    
-
    View all other issues in [facet.num.get.virtuals].
    
-
    View all issues with New status.
    
+
    671. precision of hexfloat
    
+
    Section: 22.2.2.2.2 [facet.num.put.virtuals] Status: Open
+ Submitter: John Salmon Date: 2007-04-20
    
+
    View all other issues in [facet.num.put.virtuals].
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
-From Section 22.2.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.
-Since incorrectly-placed thousands separators are flagged as an extraction
-failure (by the means of failbit), we believe it is better not
-to store the value. A consistent strategy, in which any kind of extraction
-failure leaves the input item intact, is conceptually cleaner, is able to avoid
-corner-case traps, and is also more understandable from the programmer's point
-of view.
+I am trying to understand how TR1 supports hex float (%a) output.
 
    
 
    
-Here is a quote from "The C++ Programming Language (Special Edition)"
-by B. Stroustrup (Section D.4.2.3, pg. 897):
+As far as I can tell, it does so via the following:
 
    
-
    
-"If a value of the desired type could not be read, failbit is set in r.
-[...] An input operator will use r to determine how to set the state of its
-stream. If no error was encountered, the value read is assigned through v;
-otherwise, v is left unchanged."
-
    
 
    
-This statement implies that rdstate() alone is sufficient to
-determine whether an extracted value is to be assigned to the input item
-val passed to do_get. However, this is in disagreement
-with the current C++ Standard. The above-mentioned assumption is true in all
-cases, except when there are mismatches in digit grouping. In the latter case,
-the parsed value is assigned to val, and, at the same time, err
-is assigned to ios_base::failbit (essentially "lying" about the
-success of the operation). Is this intentional? The current behavior raises
-both consistency and usability concerns.
-
    
-
    
-Although digit grouping is outside the scope of scanf (on which
-the virtual methods of num_get are based), handling of grouping
-should be consistent with the overall behavior of scanf. The specification of
-scanf makes a distinction between input failures and matching
-failures, and yet both kinds of failures have no effect on the input items
-passed to scanf. A mismatch in digit grouping logically falls in
-the category of matching failures, and it would be more consistent, and less
-surprising to the user, to leave the input item intact whenever a failure is
-being signaled.
-
    
-
    
-The extraction of bool is another example outside the scope of
-scanf, and yet consistent, even in the event of a successful
-extraction of a long but a failed conversion from
-long to bool.
-
    
-
    
-Inconsistency is further aggravated by the fact that, when failbit is set,
-subsequent extraction operations are no-ops until failbit is
-explicitly cleared. Assuming that there is no explicit handling of
-rdstate() (as in cin>>i>>j) it is
-counter-intuitive to be able to extract an integer with mismatched digit
-grouping, but to be unable to extract another, properly-formatted integer
-that immediately follows.
-
    
-
    
-Moreover, setting failbit, and selectively assigning a value to
-the input item, raises usability problems. Either the strategy of
-scanf (when there is no extracted value in case of failure), or
-the strategy of the strtol family (when there is always an
-extracted value, and there are well-defined defaults in case of a failure) are
-easy to understand and easy to use. On the other hand, if failbit
-alone cannot consistently make a difference between a failed extraction, and a
-successful but not-quite-correct extraction whose output happens to be the same
-as the previous value, the programmer must resort to implementation tricks.
-Consider the following example:
-
    
-
        int i = old_i;
-    cin >> i;
-    if (cin.fail())
-        // can the value of i be trusted?
-        // what does it mean if i == old_i?
-        // ...
-
    
+8.15 Additions to header <locale> [tr.c99.locale]
+
    
 
    
-Last but not least, the current behvaior is not only confusing to the casual
-reader, but it has also been confusing to some book authors. Besides
-Stroustrup's book, other books (e.g. "Standard C++ IOStreams and Locales" by
-Langer and Kreft) are describing the same mistaken assumption. Although books
-are not to be used instead of the standard reference, the readers of these
-books, as well as the people who are generally familiar to scanf,
-are even more likely to misinterpret the standard, and expect the input items
-to remain intact when a failure occurs.
+In subclause 22.2.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after
+the line:
+floatfield == ios_base::scientific %E
 
    
-
-
-
    Proposed resolution:
    
-
 
    
-Change 22.2.2.1.2 [facet.num.get.virtuals]:
+add the two lines:
 
    
-
-
    
+
    floatfield == ios_base::fixed | ios_base::scientific && !uppercase %a
+floatfield == ios_base::fixed | ios_base::scientific %A 2
+
    
 
    
-Stage 3: The result of stage 2 processing can be one of
+[Note: The additional requirements on print and scan functions, later
+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]
 
    
-
      
-
    • 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.
      • 
-
-
    • The sequence of chars accumulated in stage 2 would have caused scanf to report an input failure. ios_base::failbit is assigned to err.
      • 
-
    
 
    
-In the first case, Ddigit grouping is checked.  That is, the positions of discarded separators is examined for consistency with use_facet<numpunct<charT> >(loc).grouping().  If they are not consistent then ios_base::failbit is assigned to err.  Otherwise, the value that was converted in stage 2 is stored in val and ios_base::goodbit is stored in err.
+Following the thread, in 22.2.2.2.2 [facet.num.put.virtuals], we find:
 
    
-
    
-
-
-
-
-
-
    
-
    663. Complexity Requirements
    
-
    Section: 17.3.1.3 [structure.specifications] Status: New
- Submitter: Thomas Plum Date: 2007-04-16
    
-
    View other active issues in [structure.specifications].
    
-
    View all other issues in [structure.specifications].
    
-
    View all issues with New status.
    
-
    Discussion:
    
 
    
-17.3.1.3 [structure.specifications] para 5 says
+For conversion from a floating-point type, if (flags & fixed) != 0 or
+if str.precision() > 0, then str.precision() is specified in the
+conversion specification.
 
    
-
-
    
--5- Complexity requirements specified in the library 
-clauses are upper bounds, and implementations that provide better
-complexity guarantees satisfy the requirements.
-
    
-
 
    
-The following
-objection has been raised:
+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
+tell me that the committee did not intend to mandate that hex floats
+(and doubles) should by default be printed as if by %.6a.
 
    
 
-
    
-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
-or until the Library group standardizes specific hard-and-fast
-formulae, we regard all the complexity requirements as subject to a 
-"fudge factor" without any intrinsic upper bound.
-
    
+
    [
+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
+distinguish between the default value of precision, and the precision
+value 6.
+]
    
+
 
-
    
-[Plum ref 
-_23213Y31 etc]
-
    
 
 
 
    Proposed resolution:
    
@@ -10329,886 +9191,3146 @@ _23213Y31 etc]
 
    
 
 
+
    [
+Kona (2007): Robert volunteers to propose wording.
+]
    
+
+
 
 
 
 
    
-
    664. do_unshift for codecvt<char, char, mbstate_t>
    
-
    Section: 22.2.1.4.2 [locale.codecvt.virtuals] Status: New
- Submitter: Thomas Plum Date: 2007-04-16
    
-
    View other active issues in [locale.codecvt.virtuals].
    
-
    View all other issues in [locale.codecvt.virtuals].
    
-
    View all issues with New status.
    
+
    672. Swappable requirements need updating
    
+
    Section: 20.1.1 [utility.arg.requirements] Status: Review
+ Submitter: Howard Hinnant Date: 2007-05-04
    
+
    View other active issues in [utility.arg.requirements].
    
+
    View all other issues in [utility.arg.requirements].
    
+
    View all issues with Review status.
    
 
    Discussion:
    
 
    
-22.2.1.4.2 [locale.codecvt.virtuals], para 7 says (regarding do_unshift):
+The current Swappable is:
 
    
 
-
    
-Effects: Places characters starting at to that should be appended to
-terminate a sequence when the current stateT is given by
-state.237) Stores no more than (to_limit -
-to) destination elements, and leaves the to_next
-pointer pointing one beyond the last element successfully stored.
-codecvt<char, char, mbstate_t> stores no characters.
-
    
-
+
    
+
+
+
+
+
+
    Table 37: Swappable requirements [swappable]
    expressionreturn typepost-condition
    swap(s,t)voidt has the value originally held by u, and u has the value originally 
+held by t
    
 
    
-The following objection has been raised:
+The Swappable requirement is met by satisfying one or more of the following conditions:
 
    
-
-
    
-Since the C++ Standard permits a nontrivial conversion for the required
-instantiations of codecvt, it is overly restrictive to say that
-do_unshift must store no characters and return noconv.
-
    
+
      
+
    • 
+T is Swappable if T satisfies the CopyConstructible requirements (Table 34) 
+and the CopyAssignable requirements (Table 36);
+
      • 
+
    • 
+T is Swappable if a namespace scope function named swap exists in the same 
+namespace as the definition of T, such that the expression swap(t,u) is valid 
+and has the semantics described in this table.
+
      • 
+
    
+
    
+
    
 
 
    
-[Plum ref _222152Y50]
+With the passage of rvalue reference into the language, Swappable needs to be updated to
+require only MoveConstructible and MoveAssignable.  This is a minimum.
 
    
 
-
-
    Proposed resolution:
    
 
    
+Additionally we may want to support proxy references such that the following code is acceptable:
 
    
 
+
    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);
+
    
 
-
    
-
    665. do_unshift return value
    
-
    Section: 22.2.1.4.2 [locale.codecvt.virtuals] Status: New
- Submitter: Thomas Plum Date: 2007-04-16
    
-
    View other active issues in [locale.codecvt.virtuals].
    
-
    View all other issues in [locale.codecvt.virtuals].
    
-
    View all issues with New status.
    
-
    Discussion:
    
 
    
-22.2.1.4.2 [locale.codecvt.virtuals], para 8 says:
+I.e. here is a call to swap which the user enables swapping between a proxy to a class and the class
+itself.  We do not need to anything in terms of implementation except not block their way with overly
+constrained concepts.  That is, the Swappable concept should be expanded to allow swapping
+between two different types for the case that one is binding to a user-defined swap.
 
    
 
-
    
-codecvt<char,char,mbstate_t>, returns noconv.
-
    
+
+
+
    Proposed resolution:
    
 
 
    
-The following objection has been raised:
+Change 20.1.1 [utility.arg.requirements]:
 
    
 
-
    
-Despite what the C++ Standard 
-says, unshift can't always return noconv for the default facets, since 
-they can be nontrivial. At least one implementation does whatever the 
-C functions do.
-
    
+
    
 
 
    
-[Plum ref _222152Y62]
+-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 is a type 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.
 
    
 
-
-
    Proposed resolution:
    
+
+
+
+
+
+
+
    Table 37: Swappable requirements [swappable]
    expressionreturn typepost-condition
    swap(s,t)voidt has the value originally
+held by u, and
+u has the value originally held
+by t
    
 
    
+The Swappable requirement is met by satisfying one or more of the following conditions:
 
    
+
      
+
    • 
+T is Swappable if T satisfies the
+CopyConstructible MoveConstructible
+requirements (Table 34 33) and the CopyAssignable MoveAssignable
+requirements (Table 36 35);
+
      • 
+
    • 
+T is Swappable if a namespace scope function named
+swap exists in the same namespace as the definition of
+T, such that the expression
+swap(t,u) is valid and has the
+semantics described in this table.
+
      • 
+
    
+
    
+
    
+
+
+
+
    [
+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
+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,
+but it would not allow the left-most operand to be an rvalue (some swap
+functions in the library have been overloaded to permit left operands to
+swap to be rvalues).
+]
    
 
 
 
 
 
 
    
-
    666. moneypunct::do_curr_symbol()
    
-
    Section: 22.2.6.3.2 [locale.moneypunct.virtuals] Status: New
- Submitter: Thomas Plum Date: 2007-04-16
    
-
    View all other issues in [locale.moneypunct.virtuals].
    
-
    View all issues with New status.
    
+
    673. unique_ptr update
    
+
    Section: 20.6.5 [unique.ptr] Status: Open
+ Submitter: Howard Hinnant Date: 2007-05-04
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
-22.2.6.3.2 [locale.moneypunct.virtuals], para 4 footnote 257 says
+Since the publication of
+N1856
+there have been a few small but significant advances which should be included into
+unique_ptr.  There exists a
+reference implmenation
+for all of these changes.
 
    
 
-
    
-257) For international 
-specializations (second template parameter true) this is always four 
-characters long, usually three letters and a space.
-
    
+
      
 
+
    • 
 
      
-The following objection has been raised:
+Even though unique_ptr<void> is not a valid use case (unlike for shared_ptr<void>),
+unexpected cases to crop up which require the instantiation of the interface of unique_ptr<void>
+even if it is never used.  For example see
+LWG 541 for how this accidently
+happened to auto_ptr.  I believe the most robust way to protect unique_ptr against this
+type of failure is to augment the return type of unique_ptr<T>:operator*() with
+add_lvalue_reference<T>::type.  This means that given an instantiated unique_ptr<void>
+the act of dereferencing it will simply return void instead of causing a compile time failure.
+This is simpler than creating a unique_ptr<void> specialization which isn't robust in the
+face of cv-qualified void types.
 
      
 
-
      
-The international currency 
-symbol is whatever the underlying locale says it is, not necessarily 
-four characters long.
-
      
-
 
      
-[Plum ref _222632Y41]
+This resolution also supports instantiations such as unique_ptr<void, free_deleter>
+which could be very useful to the client.
 
      
 
+
      • 
 
-
      Proposed resolution:
      
+
    • 
+
      
+Efforts have been made to better support containers and smart pointers in shared
+memory contexts.  One of the key hurdles in such support is not assuming that a
+pointer type is actually a T*.  This can easily be accomplished
+for unique_ptr by having the deleter define the pointer type:
+D::pointer.  Furthermore this type can easily be defaulted to
+T* should the deleter D choose not to define a pointer
+type (reference implementation
+here).
+This change has no run time overhead.  It has no interface overhead on
+authors of custom delter types.  It simply allows (but not requires)
+authors of custom deleter types to define a smart pointer for the
+storage type of unique_ptr if they find such functionality
+useful.  std::default_delete is an example of a deleter which
+defaults pointer to T* by simply ignoring this issue
+and not including a pointer typedef.
+
      
+
      • 
+
+
    • 
 
      
+When the deleter type is a function pointer then it is unsafe to construct
+a unique_ptr without specifying the function pointer in the constructor.
+This case is easy to check for with a static_assert assuring that the
+deleter is not a pointer type in those constructors which do not accept deleters.
 
      
 
+
      unique_ptr<A, void(*)(void*)> p(new A);  // error, no function given to delete the pointer!
+
      
 
+
      • 
 
+
    
 
+
    [
+Kona (2007): We don't like the solution given to the first bullet in
+light of concepts. The second bullet solves the problem of supporting
+fancy pointers for one library component only. The full LWG needs to
+decide whether to solve the problem of supporting fancy pointers
+piecemeal, or whether a paper addressing the whole library is needed. We
+think that the third bullet is correct.
+]
    
 
-
    
-
    667. money_get's widened minus sign
    
-
    Section: 22.2.6.1.2 [locale.money.get.virtuals] Status: New
- Submitter: Thomas Plum Date: 2007-04-16
    
-
    View other active issues in [locale.money.get.virtuals].
    
-
    View all other issues in [locale.money.get.virtuals].
    
-
    View all issues with New status.
    
-
    Discussion:
    
-
    
-22.2.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 
-from '0' through '9', inclusive) stored in digits.
-
    
+
    [
+Post Kona: Howard adds example user code related to the first bullet:
+]
    
 
-
    
-The following
-objection has been raised:
-
    
 
-
    
-Some implementations interpret this to mean that a facet derived from
-ctype<wchar_t> can provide its own member do_widen(char)
-which produces e.g. L'@' for the "widened" minus sign, and that the
-'@' symbol will appear in the resulting sequence of digits.  Other
-implementations have assumed that one or more places in the standard permit the
-implementation to "hard-wire" L'-' as the "widened" minus sign.  Are
-both interpretations permissible, or only  one?
-
    
+
    
+
    void legacy_code(void*, std::size_t);
 
-
    
-[Plum ref _222612Y14]
-
    
+void foo(std::size_t N)
+{
+    std::unique_ptr<void, void(*)(void*)> ptr(std::malloc(N), std::free);
+    legacy_code(ptr.get(), N);
+}   // unique_ptr used for exception safety purposes
+
    
+
    
 
 
    
-Furthermore: if ct.widen('9') produces L'X' (a non-digit), does a
-parse fail if a '9' appears in the subject string? [Plum ref _22263Y33]
+I.e. unique_ptr<void> is a useful tool that we don't want
+to disable with concepts.  The only part of unique_ptr<void> we
+want to disable (with concepts or by other means) are the two member functions:
 
    
 
+
    T& operator*() const;
+T* operator->() const;
+
    
+
+
 
 
    Proposed resolution:
    
-
    
-
    
 
+
    [
+I am grateful for the generous aid of Peter Dimov and Ion Gaztañaga in helping formulate and review
+the proposed resolutions below.
+]
    
 
 
+
      
+
    • 
 
+
      
+Change 20.6.5.2 [unique.ptr.single]:
+
      
+
+
      template <class T, class D = default_delete<T>> class unique_ptr {
+   ...
+   T& typename add_lvalue_reference<T>::type operator*() const;
+   ...
+};
+
      
 
-
      
-
      668. money_get's empty minus sign
      
-
      Section: 22.2.6.1.2 [locale.money.get.virtuals] Status: New
- Submitter: Thomas Plum Date: 2007-04-16
      
-
      View other active issues in [locale.money.get.virtuals].
      
-
      View all other issues in [locale.money.get.virtuals].
      
-
      View all issues with New status.
      
-
      Discussion:
      
 
      
-22.2.6.1.2 [locale.money.get.virtuals], para 3 says:
+Change 20.6.5.2.4 [unique.ptr.single.observers]:
 
      
 
-
      
-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.
-
      
+
      T& typename add_lvalue_reference<T>::type operator*() const;
+
      
+
+
      • 
 
+
    • 
 
      
-The following
-objection has been raised:
+Change 20.6.5.2 [unique.ptr.single]:
 
      
 
-
      
-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".
-
      
+
      template <class T, class D = default_delete<T>> class unique_ptr {
+public:
+  typedef implementation (see description below) pointer;
+   ...
+   explicit unique_ptr(T* pointer p);
+   ...
+   unique_ptr(T* pointer p, implementation defined (see description below) d);
+   unique_ptr(T* pointer p, implementation defined (see description below) d);
+   ...
+   T* pointer operator->() const;
+   T* pointer get() const;
+   ...
+   T* pointer release();
+   void reset(T* pointer p = 0 pointer());
+};
+
      
 
 
      
-[Plum ref _222612Y32]
+
+-3- If the type remove_reference<D>::type::pointer
+exists, then unique_ptr<T, D>::pointer is a typedef to
+remove_reference<D>::type::pointer.  Otherwise
+unique_ptr<T, D>::pointer is a typedef to T*.
+The type unique_ptr<T, D>::pointer must be CopyConstructible
+and CopyAssignable.
+
 
      
 
-
-
      Proposed resolution:
      
 
      
+Change 20.6.5.2.1 [unique.ptr.single.ctor]:
 
      
 
+
      unique_ptr(T* pointer p);
+...
+unique_ptr(T* pointer p, implementation defined d); 
+unique_ptr(T* pointer p, implementation defined d); 
+...
+unique_ptr(T* pointer p, const A& d);
+unique_ptr(T* pointer p, A&& d);
+...
+unique_ptr(T* pointer p, A& d); 
+unique_ptr(T* pointer p, A&& d);
+...
+unique_ptr(T* pointer p, const A& d); 
+unique_ptr(T* pointer p, const A&& d);
+...
+
      
 
+
      
+-23- Requires: If D is not a reference type,
+construction of the deleter D from an rvalue of type E
+must be well formed and not throw an exception. If D is a
+reference type, then E must be the same type as D
+(diagnostic required). U* unique_ptr<U,E>::pointer
+must be implicitly convertible to T*
+pointer.
+
      
 
+
      
+-25- Postconditions: get() == value u.get() had before
+the construction, modulo any required offset adjustments resulting from
+the cast from U*
+unique_ptr<U,E>::pointer to T*
+pointer. get_deleter() returns a reference to the
+internally stored deleter which was constructed from
+u.get_deleter().
+
      
 
-
-
      
-
      669. Equivalent postive and negative signs in money_get
      
-
      Section: 22.2.6.1.2 [locale.money.get.virtuals] Status: New
- Submitter: Thomas Plum Date: 2007-04-16
      
-
      View other active issues in [locale.money.get.virtuals].
      
-
      View all other issues in [locale.money.get.virtuals].
      
-
      View all issues with New status.
      
-
      Discussion:
      
 
      
-22.2.6.1.2 [locale.money.get.virtuals], para 3 sentence 4 says:
+Change 20.6.5.2.3 [unique.ptr.single.asgn]:
 
      
 
-
      
-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.
-
      
+
      
+
      
+-8- Requires: Assignment of the deleter D from an rvalue
+D must not throw an exception. U*
+unique_ptr<U,E>::pointer must be implicitly
+convertible to T* pointer.
+
      
+
      
 
 
      
-One interpretation is that an input sequence must match either the
-positive pattern or the negative pattern, and then in either event it
-is interpreted as positive.  The following objections has been raised:
+Change 20.6.5.2.4 [unique.ptr.single.observers]:
 
      
 
-
      
-The input can successfully match only a positive sign, so the negative
-pattern is an unsuccessful match.
-
      
+
      
+
      T* pointer operator->() const;
      
+...
+
      T* pointer get() const;
      
+
      
 
 
      
-[Plum ref _222612Y34, 222612Y51b]
+Change 20.6.5.2.5 [unique.ptr.single.modifiers]:
 
      
 
+
      
+
      T* pointer release();
      
+...
+
      void reset(T* pointer p = 0 pointer());
      
+
      
 
-
      Proposed resolution:
      
 
      
+Change 20.6.5.3 [unique.ptr.runtime]:
 
      
 
+
      template <class T, class D> class unique_ptr<T[], D> {
+public:
+  typedef implementation pointer;
+   ...
+   explicit unique_ptr(T* pointer p);
+   ...
+   unique_ptr(T* pointer p, implementation defined d);
+   unique_ptr(T* pointer p, implementation defined d);
+   ...
+   T* pointer get() const;
+   ...
+   T* pointer release();
+   void reset(T* pointer p = 0 pointer());
+};
+
      
 
+
      
+Change 20.6.5.3.1 [unique.ptr.runtime.ctor]:
+
      
 
+
      
+
      unique_ptr(T* pointer p);
+unique_ptr(T* pointer p, implementation defined d);
+unique_ptr(T* pointer p, implementation defined d);
+
      
 
+
      
+These constructors behave the same as in the primary template except
+that they do not accept pointer types which are convertible to
+T* pointer. [Note: One
+implementation technique is to create private templated overloads of
+these members. -- end note]
+
      
+
      
 
-
      
-
      670. money_base::pattern and space
      
-
      Section: 22.2.6.3 [locale.moneypunct] Status: New
- Submitter: Thomas Plum Date: 2007-04-16
      
-
      View all issues with New status.
      
-
      Discussion:
      
 
      
-22.2.6.3 [locale.moneypunct], para 2 says:
+Change 20.6.5.3.3 [unique.ptr.runtime.modifiers]:
 
      
 
-
      
-The value space indicates that at least one space is required at 
-that position.
-
      
+
      
+
      void reset(T* pointer p = 0 pointer());
+
      
 
 
      
-The following objection has been raised:
+-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]
 
      
-
-
      
-Whitespace is optional when matching space. (See 22.2.6.1.2 [locale.money.get.virtuals], para 2.)
-
      
+
      
 
 
      
-[Plum ref _22263Y22]
+Change 20.6.5.4 [unique.ptr.compiletime]:
 
      
 
+
      template <class T, class D,  size_t N> class unique_ptr<T[N], D> {
+public:
+  typedef implementation pointer;
+   ...
+   explicit unique_ptr(T* pointer p);
+   ...
+   unique_ptr(T* pointer p, implementation defined d);
+   unique_ptr(T* pointer p, implementation defined d);
+   ...
+   T* pointer get() const;
+   ...
+   T* pointer release();
+   void reset(T* pointer p = 0 pointer());
+};
+
      
 
-
      Proposed resolution:
      
 
      
+Change 20.6.5.4.3 [unique.ptr.compiletime.modifiers]:
 
      
 
+
      
+
      void reset(T* pointer p = 0 pointer());
+
      
 
+
      
+-1- Requires: Does not accept pointer types which are convertible
+to T* pointer (dignostic required). [Note: One implementation
+technique is to create a private templated overload. --end note]
+
      
 
+
      
 
+
      • 
+
+
    • 
 
-
      
-
      671. precision of hexfloat
      
-
      Section: 22.2.2.2.2 [facet.num.put.virtuals] Status: New
- Submitter: John Salmon Date: 2007-04-20
      
-
      View all other issues in [facet.num.put.virtuals].
      
-
      View all issues with New status.
      
-
      Discussion:
      
 
      
-I am trying to understand how TR1 supports hex float (%a) output.
+Change 20.6.5.2.1 [unique.ptr.single.ctor]:
 
      
+
+
      
+
      unique_ptr();
      
+
      
 
      
-As far as I can tell, it does so via the following:
+Requires: D must be default constructible, and that
+construction must not throw an exception. D must not be a
+reference type or pointer type (diagnostic required).
 
      
+
      
+
      unique_ptr(T* pointer p);
      
+
      
 
      
-8.15 Additions to header <locale> [tr.c99.locale]
+Requires:  The expression D()(p) must be well formed.
+The default constructor of D must not throw an exception.
+D must not be a reference type or pointer type (diagnostic
+required).
 
      
+
      
+
      
+
 
      
-In subclause 22.2.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after
-the line:
-floatfield == ios_base::scientific %E
-
      
-
      
-add the two lines:
-
      
-
      floatfield == ios_base::fixed | ios_base::scientific && !uppercase %a
-floatfield == ios_base::fixed | ios_base::scientific %A 2
-
      
-
      
-[Note: The additional requirements on print and scan functions, later
-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]
-
      
-
      
-Following the thread, in 22.2.2.2.2 [facet.num.put.virtuals], we find:
+Change 20.6.5.2.1 [unique.ptr.single.ctor]:
 
      
+
+
      
+
      unique_ptr();
      
+
      
 
      
-For conversion from a floating-point type, if (flags & fixed) != 0 or
-if str.precision() > 0, then str.precision() is specified in the
-conversion specification.
+Requires: D must be default constructible, and that
+construction must not throw an exception. D must not be a
+reference type or pointer type (diagnostic required).
 
      
+
      
+
      unique_ptr(T* pointer p);
      
+
      
 
      
-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
-tell me that the committee did not intend to mandate that hex floats
-(and doubles) should by default be printed as if by %.6a.
+Requires:  The expression D()(p) must be well formed.
+The default constructor of D must not throw an exception.
+D must not be a reference type or pointer type (diagnostic
+required).
 
      
+
      
+
      
 
-
      [
-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
-distinguish between the default value of precision, and the precision
-value 6.
-]
      
-
-
+
      • 
 
+
    
 
-
    Proposed resolution:
    
-
    
-
    
 
 
 
 
 
 
    
-
    672. Swappable requirements need updating
    
-
    Section: 20.1.1 [utility.arg.requirements] Status: New
- Submitter: Howard Hinnant Date: 2007-05-04
    
-
    View all other issues in [utility.arg.requirements].
    
-
    View all issues with New status.
    
+
    674. shared_ptr interface changes for consistency with N1856
    
+
    Section: 20.6.6.2 [util.smartptr.shared] Status: Ready
+ Submitter: Peter Dimov Date: 2007-05-05
    
+
    View other active issues in [util.smartptr.shared].
    
+
    View all other issues in [util.smartptr.shared].
    
+
    View all issues with Ready status.
    
 
    Discussion:
    
 
    
-The current Swappable is:
+N1856 does not propose
+any changes to shared_ptr. It needs to be updated to use a rvalue reference where appropriate
+and to interoperate with unique_ptr as it does with auto_ptr.
 
    
 
-
    
-
-
-
-
-
-
    Table 37: Swappable requirements [swappable]
    expressionreturn typepost-condition
    swap(s,t)voidt has the value originally held by u, and u has the value originally 
-held by t
    
+
+
    Proposed resolution:
    
+
 
    
-The Swappable requirement is met by satisfying one or more of the following conditions:
+Change 20.6.6.2 [util.smartptr.shared] as follows:
 
    
-
      
-
    • 
-T is Swappable if T satisfies the CopyConstructible requirements (Table 34) 
-and the CopyAssignable requirements (Table 36);
-
      • 
-
    • 
-T is Swappable if a namespace scope function named swap exists in the same 
-namespace as the definition of T, such that the expression swap(t,u) is valid 
-and has the semantics described in this table.
-
      • 
-
    
-
    
+
+
    
+
    template<class Y> explicit shared_ptr(auto_ptr<Y>&&& r);
+template<class Y, class D> explicit shared_ptr(const unique_ptr<Y,D>& r) = delete;
+template<class Y, class D> explicit shared_ptr(unique_ptr<Y,D>&& r);
+...
+template<class Y> shared_ptr& operator=(auto_ptr<Y>&&& r);
+template<class Y, class D> shared_ptr& operator=(const unique_ptr<Y,D>& r) = delete;
+template<class Y, class D> shared_ptr& operator=(unique_ptr<Y,D>&& r);
    
 
    
 
 
    
-With the passage of rvalue reference into the language, Swappable needs to be updated to
-require only MoveConstructible and MoveAssignable.  This is a minimum.
+Change 20.6.6.2.1 [util.smartptr.shared.const] as follows:
 
    
 
+
    
+
    template<class Y> shared_ptr(auto_ptr<Y>&&& r);
    
+
    
+
 
    
-Additionally we may want to support proxy references such that the following code is acceptable:
+Add to 20.6.6.2.1 [util.smartptr.shared.const]:
 
    
 
-
    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>);
+
    
+
    template<class Y, class D> shared_ptr(unique_ptr<Y, D>&& r);
    
+
    
 
-}  // Mine
+
    
+Effects: Equivalent to shared_ptr( r.release(), r.get_deleter() ) when D is
+          not a reference type, shared_ptr( r.release(), ref( r.get_deleter() ) )
+          otherwise.
+
    
 
-...
+
    
+Exception safety: If an exception is thrown, the constructor has no effect.
+
    
+
    
 
-Mine::proxied_iterator<Mine::A> i(...)
-Mine::A a;
-swap(*i1, a);
-
    
+
    
 
 
    
-I.e. here is a call to swap which the user enables swapping between a proxy to a class and the class
-itself.  We do not need to anything in terms of implementation except not block their way with overly
-constrained concepts.  That is, the Swappable concept should be expanded to allow swapping
-between two different types for the case that one is binding to a user-defined swap.
+Change 20.6.6.2.3 [util.smartptr.shared.assign] as follows:
 
    
 
-
-
-
    Proposed resolution:
    
+
    
+
    template<class Y> shared_ptr& operator=(auto_ptr<Y>&&& r);
    
+
    
 
 
    
-Change 20.1.1 [utility.arg.requirements]:
+Add to 20.6.6.2.3 [util.smartptr.shared.assign]:
 
    
 
 
    
+
    template<class Y, class D> shared_ptr& operator=(unique_ptr<Y,D>&& r);
    
 
-
    
--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; and v is a value of type V.
-
    
-
-
-
-
-
-
-
-
    Table 37: Swappable requirements [swappable]
    expressionreturn typepost-condition
    swap(s,tv)voidts has the value originally
-held by uv, and
-uv has the value originally held
-by ts
    
-
    
-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(ts,u v) is valid and has the
-semantics described in this table.
-
      • 
-
    
-
    
+
    
+
    
+-4- Effects: Equivalent to shared_ptr(std::move(r)).swap(*this).
+
    
+
    
+-5- Returns: *this.
+
    
 
    
 
-
    [Some editorial issues are also cleaned up by this resolution.]
    
-
+
    
 
-
    
 
-
    
 
+
    [
+Kona (2007): We may need to open an issue (743) to deal with the question of
+whether shared_ptr needs an rvalue swap.
+]
    
 
 
 
 
 
 
    
-
    673. unique_ptr update
    
-
    Section: 20.6.5 [unique.ptr] Status: New
- Submitter: Howard Hinnant Date: 2007-05-04
    
-
    View all issues with New status.
    
+
    675. Move assignment of containers
    
+
    Section: 23.1 [container.requirements] Status: Ready
+ 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 Ready status.
    
 
    Discussion:
    
 
    
-Since the publication of
-N1856
-there have been a few small but significant advances which should be included into
-unique_ptr.  There exists a
-reference implmenation
-for all of these changes.
+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).
 
    
 
-
      
-
-
    • 
-
      
-Even though unique_ptr<void> is not a valid use case (unlike for shared_ptr<void>),
-unexpected cases to crop up which require the instantiation of the interface of unique_ptr<void>
-even if it is never used.  For example see
-LWG 541 for how this accidently
-happened to auto_ptr.  I believe the most robust way to protect unique_ptr against this
-type of failure is to augment the return type of unique_ptr<T>:operator*() with
-add_lvalue_reference<T>::type.  This means that given an instantiated unique_ptr<void>
-the act of dereferencing it will simply return void instead of causing a compile time failure.
-This is simpler than creating a unique_ptr<void> specialization which isn't robust in the
-face of cv-qualified void types.
-
      
+
      vector<shared_ptr<ostream>> v1;
+vector<shared_ptr<ostream>> v2;
+...
+v1 = v2;               // #1
+v1 = std::move(v2);    // #2
+
      
 
 
      
-This resolution also supports instantiations such as unique_ptr<void, free_deleter>
-which could be very useful to the client.
+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 86: 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
+constant linear in a.size()
      
+
      
+
+
+
+
+
+
+
      
+
      676. Moving the unordered containers
      
+
      Section: 23.4 [unord] Status: Ready
+ Submitter: Howard Hinnant Date: 2007-05-05
      
+
      View other active issues in [unord].
      
+
      View all other issues in [unord].
      
+
      View all issues with Ready 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);
+
      
+
      
+
+
+
+
+
+
+
      
+
      679. resize parameter by value
      
+
      Section: 23.2 [sequences] Status: Ready
+ Submitter: Howard Hinnant Date: 2007-06-11
      
+
      View all issues with Ready status.
      
+
      Discussion:
      
+
      
+The C++98 standard specifies that one member function alone of the containers
+passes its parameter (T) by value instead of by const reference:
+
      
+
+
      void resize(size_type sz, T c = T());
+
      
+
+
      
+This fact has been discussed / debated repeatedly over the years, the first time
+being even before C++98 was ratified.  The rationale for passing this parameter by
+value has been:
+
      
+
+
      
+
      
+So that self referencing statements are guaranteed to work, for example:
+
      
+
      v.resize(v.size() + 1, v[0]);
+
      
+
      
+
+
      
+However this rationale is not convincing as the signature for push_back is:
+
      
+
+
      void push_back(const T& x);
+
      
+
+
      
+And push_back has similar semantics to resize (append).
+And push_back must also work in the self referencing case:
+
      
+
+
      v.push_back(v[0]);  // must work
+
      
+
+
      
+The problem with passing T by value is that it can be significantly more
+expensive than passing by reference.  The converse is also true, however when it is
+true it is usually far less dramatic (e.g. for scalar types).
+
      
+
+
      
+Even with move semantics available, passing this parameter by value can be expensive.
+Consider for example vector<vector<int>>:
+
      
+
+
      std::vector<int> x(1000);
+std::vector<std::vector<int>> v;
+...
+v.resize(v.size()+1, x);
+
      
+
+
      
+In the pass-by-value case, x is copied once to the parameter of
+resize.  And then internally, since the code can not know at compile
+time by how much resize is growing the vector, x is
+usually copied (not moved) a second time from resize's parameter into its proper place
+within the vector.
+
      
+
+
      
+With pass-by-const-reference, the x in the above example need be copied
+only once.  In this case, x has an expensive copy constructor and so any
+copies that can be saved represents a significant savings.
+
      
+
+
      
+If we can be efficient for push_back, we should be efficient for resize
+as well.  The resize taking a reference parameter has been coded and shipped in the
+CodeWarrior library with no reports of problems which I am aware of.
+
      
+
+
+
+
      Proposed resolution:
      
+
      
+Change 23.2.2 [deque], p2:
+
      
+
+
      class deque {
+   ...
+   void resize(size_type sz, const T& c);
+
      
+
+
      
+Change 23.2.2.2 [deque.capacity], p3:
+
      
+
+
      void resize(size_type sz, const T& c);
+
      
+
+
      
+Change 23.2.3 [list], p2:
+
      
+
+
      class list {
+   ...
+   void resize(size_type sz, const T& c);
+
      
+
+
      
+Change 23.2.3.2 [list.capacity], p3:
+
      
+
+
      void resize(size_type sz, const T& c);
+
      
+
+
      
+Change 23.2.5 [vector], p2:
+
      
+
+
      class vector {
+   ...
+   void resize(size_type sz, const T& c);
+
      
+
+
      
+Change 23.2.5.2 [vector.capacity], p11:
+
      
+
+
      void resize(size_type sz, const T& c);
+
      
+
+
+
+
+
+
+
      
+
      680. move_iterator operator-> return
      
+
      Section: 24.4.3.1 [move.iterator] Status: Ready
+ Submitter: Howard Hinnant Date: 2007-06-11
      
+
      View all issues with Ready 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].
+
      
+
+
      template <class Iterator>
+class move_iterator {
+public:
+    ...
+    typedef typename iterator_traits<Iterator>::pointer pointer;
+    ...
+    pointer operator->() const {return current;}
+    ...
+private: 
+    Iterator current; // exposition only
+};
+
      
+
+
+
      
+There are two possible fixes.
+
      
+
+
        
+
      1. pointer operator->() const {return &*current;}
        2. 
+
      2. typedef Iterator pointer;
        3. 
+
      
+
+
      
+The first solution is the one chosen by reverse_iterator.  A potential
+disadvantage of this is it may not work well with iterators which return a
+proxy on dereference and that proxy has overloaded operator&().  Proxy
+references often need to overloaad operator&() to return a proxy
+pointer.  That proxy pointer may or may not be the same type as the iterator's
+pointer type.
+
      
+
+
      
+By simply returning the Iterator and taking advantage of the fact that
+the language forwards calls to operator-> automatically until it
+finds a non-class type, the second solution avoids the issue of an overloaded
+operator&() entirely.
+
      
+
+
      Proposed resolution:
      
+
      
+Change the synopsis in 24.4.3.1 [move.iterator]:
+
      
+
+
      typedef typename iterator_traits<Iterator>::pointer pointer;
+
      
+
+
+
+
+
+
+
      
+
      684. Unclear which members of match_results should be used in comparison
      
+
      Section: 28.10 [re.results] Status: Review
+ Submitter: Nozomu Katoo Date: 2007-05-27
      
+
      View other active issues in [re.results].
      
+
      View all other issues in [re.results].
      
+
      View all issues with Review status.
      
+
      Discussion:
      
+
      
+In 28.4 [re.syn] of N2284, two template functions 
+are declared here: 
+
      
+
      // 28.10, class template match_results: 
+  <snip>
+// match_results comparisons 
+  template <class BidirectionalIterator, class Allocator> 
+    bool operator== (const match_results<BidirectionalIterator, Allocator>& m1, 
+                     const match_results<BidirectionalIterator, Allocator>& m2); 
+  template <class BidirectionalIterator, class Allocator> 
+    bool operator!= (const match_results<BidirectionalIterator, Allocator>& m1, 
+                     const match_results<BidirectionalIterator, Allocator>& m2); 
+
+// 28.10.6, match_results swap:
+
      
+
+
      
+But the details of these two bool operator functions (i.e., which members of
+match_results should be used in comparison) are not described in any
+following sections.
+
      
+
+
      [
+John adds:
+]
      
+
+
+
      
+That looks like a bug: operator== should return true only if
+the two objects refer to the same match - ie if one object was constructed as a
+copy of the other.
+
      
+
+
      [
+Kona (2007): Bill and Pete to add minor wording to that proposed in
+N2409.
+]
      
+
+
+
+
      Proposed resolution:
      
+
      
+Add a new section after 28.10.6 [re.results.swap], which reads:
+
      
+
      
+28.10.7 match_results non-member functions.
+
      
+
+
      
+
      template<class BidirectionalIterator, class Allocator> 
+  bool operator==(const match_results<BidirectionalIterator, Allocator>& m1, 
+                  const match_results<BidirectionalIterator, Allocator>& m2);
+
      
+
      
+
      
+Returns: true only if the two objects refer to the same match.
+
      
+
      
+
      
+
+
      
+
      template<class BidirectionalIterator, class Allocator> 
+  bool operator!=(const match_results<BidirectionalIterator, Allocator>& m1, 
+                  const match_results<BidirectionalIterator, Allocator>& m2);
+
      
+
      
+
      
+Returns: !(m1 == m2).
+
      
+
      
+
      
+
+
      
+
      template<class BidirectionalIterator, class Allocator> 
+  void swap(match_results<BidirectionalIterator, Allocator>& m1, 
+            match_results<BidirectionalIterator, Allocator>& m2);
+
      
+
      
+
      
+Returns: m1.swap(m2).
+
      
+
      
+
      
+
+
+
+
+
+
      
+
      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: Review
+ Submitter: Bo Persson Date: 2007-06-10
      
+
      View all issues with Review status.
      
+
      Discussion:
      
+
      
+In C++03 the difference between two reverse_iterators
+
      
+
      ri1 - ri2
+
      
+
      
+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] 
+
      
+
      template<class Iterator1, class Iterator2> 
+typename reverse_iterator<Iterator>::difference_type 
+   operator-(const reverse_iterator<Iterator1>& x, 
+                    const reverse_iterator<Iterator2>& y);
+
      
+
      
+The return type is the same as the C++03 one, based on the no longer 
+present Iterator template parameter. 
+
      
+
      
+Besides being slightly invalid, should this operator work only when 
+Iterator1 and Iterator2 has the same difference_type? Or should the 
+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]. 
+
      
+
+
+
      Proposed resolution:
      
+
      
+Change the synopsis in 24.4.1.1 [reverse.iterator]:
+
      
+
+
      
+
      template <class Iterator1, class Iterator2> 
+  typename reverse_iterator<Iterator>::difference_type auto operator-( 
+    const reverse_iterator<Iterator1>& x, 
+    const reverse_iterator<Iterator2>& y) -> decltype(operator-(Iterator1, Iterator2));
+
      
+
      
+
      
+Returns: y.current - x.current.
+
      
+
      
+
      
+
+
      
+Change 24.4.1.3.19 [reverse.iter.opdiff]:
+
      
+
+
      
+
      template <class Iterator1, class Iterator2> 
+  typename reverse_iterator<Iterator>::difference_type auto operator-( 
+    const reverse_iterator<Iterator1>& x, 
+    const reverse_iterator<Iterator2>& y) -> decltype(operator-(Iterator1, Iterator2));
+
      
+
      
+
      
+Returns: y.current - x.current.
+
      
+
      
+
      
+
+
+
      
+Change the synopsis in 24.4.3.1 [move.iterator]:
+
      
+
+
      
+
      template <class Iterator1, class Iterator2> 
+  typename move_iterator<Iterator>::difference_type auto operator-( 
+    const move_iterator<Iterator1>& x, 
+    const move_iterator<Iterator2>& y) -> decltype(operator-(Iterator1, Iterator2));
+
      
+
      
+
      
+Returns: y.current - x.current.
+
      
+
      
+
      
+
+
      
+Change 24.4.3.3.14 [move.iter.nonmember]:
+
      
+
+
      
+
      template <class Iterator1, class Iterator2> 
+  typename move_iterator<Iterator>::difference_type auto operator-( 
+    const move_iterator<Iterator1>& x, 
+    const move_iterator<Iterator2>& y) -> decltype(operator-(Iterator1, Iterator2));
+
      
+
      
+
      
+Returns: x.base() - y.base().
+
      
+
      
+
      
+
+
+
+
+
+
      
+
      686. Unique_ptr and shared_ptr fail to specify non-convertibility to int for unspecified-bool-type
      
+
      Section: 20.6.5.2.4 [unique.ptr.single.observers], 20.6.6.2.5 [util.smartptr.shared.obs] Status: Open
+ Submitter: Beman Dawes Date: 2007-06-14
      
+
      View all issues with Open status.
      
+
      Discussion:
      
+
      
+The standard library uses the operator unspecified-bool-type() const idiom in
+five places. In three of those places (20.5.15.2.3 [func.wrap.func.cap], function capacity 
+for example) the returned value is constrained to disallow
+unintended conversions to int. The standardese is
+
      
+
      
+The return type shall not be convertible to int.
+
      
+
      
+This constraint is omitted for unique_ptr and shared_ptr. It should be added for those.
+
      
+
+
+
      Proposed resolution:
      
+
      
+To the Returns paragraph for operator unspecified-bool-type()
+const
+of 20.6.5.2.4 [unique.ptr.single.observers] paragraph 11 and 20.6.6.2.5
+[util.smartptr.shared.obs] paragraph 16, add the sentence:
+
      
+
      
+The return type shall not be convertible to int.
+
      
+
+
+
      [
+Kona (2007): Uncertain if nullptr will address this issue.
+]
      
+
+
+
+
+
+
      
+
      687. shared_ptr conversion constructor not constrained
      
+
      Section: 20.6.6.2.1 [util.smartptr.shared.const], 20.6.6.3.1 [util.smartptr.weak.const] Status: Ready
+ Submitter: Peter Dimov Date: 2007-05-10
      
+
      View all issues with Ready status.
      
+
      Discussion:
      
+
      
+Since all conversions from shared_ptr<T> to shared_ptr<U> have the same
+rank regardless of the relationship between T and U, reasonable user
+code that works with raw pointers fails with shared_ptr:
+
      
+
+
      void f( shared_ptr<void> );
+void f( shared_ptr<int> );
+
+int main()
+{
+  f( shared_ptr<double>() ); // ambiguous
+}
+
      
+
+
      
+Now that we officially have enable_if, we can constrain the constructor
+and the corresponding assignment operator to only participate in the
+overload resolution when the pointer types are compatible.
+
      
+
+
+
      Proposed resolution:
      
+
      
+In 20.6.6.2.1 [util.smartptr.shared.const], change:
+
      
+
+
      
+-14- Requires: For the second constructor The
+second constructor shall not participate in the overload resolution
+unless Y* shall be is implicitly convertible
+to T*.
+
      
+
+
      
+In 20.6.6.3.1 [util.smartptr.weak.const], change:
+
      
+
+
      
+
      template<class Y> weak_ptr(shared_ptr<Y> const& r);
+weak_ptr(weak_ptr const& r);
+template<class Y> weak_ptr(weak_ptr<Y> const& r);
+weak_ptr(weak_ptr const& r);
+template<class Y> weak_ptr(weak_ptr<Y> const& r);
+template<class Y> weak_ptr(shared_ptr<Y> const& r);
+
      
+
      
+-4- Requires: For tThe second and
+third constructors, shall not participate in the
+overload resolution unless Y* shall be
+is implicitly convertible to T*.
+
      
+
      
+
+
+
+
+
+
+
      
+
      688. reference_wrapper, cref unsafe, allow binding to rvalues
      
+
      Section: 20.5.5.1 [refwrap.const] Status: Ready
+ Submitter: Peter Dimov Date: 2007-05-10
      
+
      View other active issues in [refwrap.const].
      
+
      View all other issues in [refwrap.const].
      
+
      View all issues with Ready status.
      
+
      Discussion:
      
+
      
+A reference_wrapper can be constructed from an rvalue, either by using
+the constructor, or via cref (and ref in some corner cases). This leads
+to a dangling reference being stored into the reference_wrapper object.
+Now that we have a mechanism to detect an rvalue, we can fix them to
+disallow this source of undefined behavior.
+
      
+
+
      
+Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
+
      
+
+
+
+
      Proposed resolution:
      
+
      
+In 20.5.5 [refwrap], add:
+
      
+
+
      private:
+  explicit reference_wrapper(T&&);
+
      
+
+
      
+In 20.5.5.1 [refwrap.const], add:
+
      
+
+
      
+
      explicit reference_wrapper(T&&);
+
      
+
      
+-?- Not defined to disallow creating a reference_wrapper from an rvalue.
+
      
+
      
+
+
      
+In the synopsis of <functional> (20.5.5 [refwrap]), change the declarations
+of ref and cref to:
+
      
+
+
      template<class T> reference_wrapper<T> ref(T&&);
+template<class T> reference_wrapper<const T> cref(const T&&);
+
      
+
+
      
+In 20.5.5.5 [refwrap.helpers], change:
+
      
+
+
      
+
      template<class T> reference_wrapper<T> ref(T&& t);
+
      
+
      
+
      
+-1- Requires: t shall be an lvalue.
+
      
+
      
+
      
+
+
      and change:
      
+
+
      
+
      template<class T> reference_wrapper<const T> cref(const T&& t);
+
      
+
      
+
      
+-6- Requires: t shall be an lvalue.
+
      
+
      
+
      
+
+
+
+
      [
+N2292
+addresses the first part of the resolution but not the second.
+]
      
+
+
+
+
+
+
      
+
      689. reference_wrapper constructor overly constrained
      
+
      Section: 20.5.5.1 [refwrap.const] Status: Ready
+ Submitter: Peter Dimov Date: 2007-05-10
      
+
      View other active issues in [refwrap.const].
      
+
      View all other issues in [refwrap.const].
      
+
      View all issues with Ready status.
      
+
      Discussion:
      
+
      
+The constructor of reference_wrapper is currently explicit. The primary
+motivation behind this is the safety problem with respect to rvalues,
+which is addressed by the proposed resolution of the previous issue.
+Therefore we should consider relaxing the requirements on the
+constructor since requests for the implicit conversion keep resurfacing.
+
      
+
      
+Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
+
      
+
+
+
      Proposed resolution:
      
+
      
+Remove the explicit from the constructor of reference_wrapper. If the
+proposed resolution of the previous issue is accepted, remove the
+explicit from the T&& constructor as well to keep them in sync.
+
      
+
+
+
+
+
+
      
+
      691. const_local_iterator cbegin, cend missing from TR1
      
+
      Section: 23.4 [unord], TR1 6.3 [tr.hash] Status: Review
+ 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 Review 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.3 [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: New
+ Submitter: Martin Sebor Date: 2007-06-22
      
+
      View all other issues in [ext.manip].
      
+
      View all issues with New 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...
+
      
+
+
+
+
+
+
      
+
      693. std::bitset::all() missing
      
+
      Section: 23.3.5 [template.bitset] Status: Ready
+ Submitter: Martin Sebor Date: 2007-06-22
      
+
      View other active issues in [template.bitset].
      
+
      View all other issues in [template.bitset].
      
+
      View all issues with Ready status.
      
+
      Discussion:
      
+
      
+The  bitset class template  provides the  member function
+any() to determine whether an  object of the type has any
+bits  set, and  the member  function none()  to determine
+whether all of an object's  bits are clear. However, the template does
+not   provide  a   corresponding  function   to  discover   whether  a
+bitset  object  has  all  its  bits  set.   While  it  is
+possible,  even easy,  to  obtain this  information  by comparing  the
+result of count()  with the result of size()
+for  equality  (i.e.,  via  b.count()  ==  b.size())  the
+operation  is   less  efficient   than  a  member   function  designed
+specifically  for that purpose  could be.   (count() must
+count  all non-zero bits  in a  bitset a  word at  a time
+while all() could stop counting as soon as it encountered
+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,
+right above the declaration of any() as shown below:
+
      
+
+
      bool operator!=(const bitset<N>& rhs) const;
+bool test(size_t pos) const;
+bool all() const;
+bool any() const;
+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:
+
      
+
      
+bool all() const;
+
      
+
      
+Returns: count() == size().
+
      
+
      
+
+
      
+In  addition,   change  the  description   of  any()  and
+none()   for  consistency   with   all()  as
+follows:
+
      
+
      
+bool any() const;
+
      
+
      
+
      
+Returns: true if any bit in *this
+is onecount() != 0.
+
      
+
      
+
      
+bool none() const;
+
      
+
      
+
      
+Returns: true if no bit in *this
+is onecount() == 0.
+
      
+
      
+
      
+
+
+
+
+
+
      
+
      694. std::bitset and long long
      
+
      Section: 23.3.5 [template.bitset] Status: Ready
+ Submitter: Martin Sebor Date: 2007-06-22
      
+
      View other active issues in [template.bitset].
      
+
      View all other issues in [template.bitset].
      
+
      View all issues with Ready status.
      
+
      Discussion:
      
+
      
+Objects of the  bitset class template specializations can
+be constructed from  and explicitly converted to values  of the widest
+C++ integer  type, unsigned long.   With the introduction
+of  long long into  the language  the template  should be
+enhanced to make it possible  to interoperate with values of this type
+as well, or  perhaps uintmax_t.  See c++std-lib-18274 for
+a brief discussion in support of this change.
+
      
+
+
+
      Proposed resolution:
      
+
      
+For simplicity,  instead of  adding overloads for  unsigned long
+long and dealing with possible ambiguities in the spec, replace
+the bitset ctor  that takes an unsigned long
+argument  with  one  taking  unsigned long  long  in  the
+definition  of the  template as  shown below.   (The  standard permits
+implementations  to add  overloads on  other integer  types  or employ
+template tricks to  achieve the same effect provided  they don't cause
+ambiguities or changes in behavior.)
+
      
+
      
+
      // [bitset.cons] constructors:
+bitset();
+bitset(unsigned long long val);
+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);
+
      
+
      
+
      
+Make a corresponding change in 23.3.5.1 [bitset.cons], p2:
+
      
+
      
+
      
+bitset(unsigned long long val);
+
      
+
      
+Effects:  Constructs   an  object  of   class  bitset<N>,
+initializing  the  first M  bit  positions to  the
+corresponding      bit     values      in     val.
+M is the  smaller of N and the
+number of bits in  the value representation (section [basic.types]) of
+unsigned   long long.   If  M <
+N  is  true,  the remaining  bit
+positions are initialized to zero.
+
      
+
      
+
+
      
+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:
+
      
+
      
+
      // element access:
+bool operator[](size_t pos) const; // for b[i];
+reference operator[](size_t pos); // for b[i];
+unsigned long to_ulong() const;
+unsigned long long to_ullong() const;
+template <class charT, class traits, class Allocator>
+basic_string<charT, traits, Allocator> to_string() const;
+
      
+
      
+
      
+And add a description of  the new member function to 23.3.5.2 [bitset.members],
+below  the  description of  the  existing to_ulong()  (if
+possible), with the following text:
+
      
+
      
+
      
+unsigned long long to_ullong() const;
+
      
+
      
+Throws:  overflow_error   if  the  integral  value
+x corresponding to  the bits in *this
+cannot be represented as type unsigned long long.
+
      
+
      
+Returns: x.
+
      
+
      
+
+
+
+
+
+
      
+
      695. ctype<char>::classic_table() not accessible
      
+
      Section: 22.2.1.3 [facet.ctype.special] Status: Ready
+ Submitter: Martin Sebor Date: 2007-06-22
      
+
      View all issues with Ready status.
      
+
      Discussion:
      
+
      
+The   ctype<char>::classic_table()   static  member
+function    returns    a    pointer    to   an    array    of    const
+ctype_base::mask    objects    (enums)   that    contains
+ctype<char>::table_size    elements.    The   table
+describes the properties of the character set in the "C" locale (i.e.,
+whether a  character at an index  given by its value  is alpha, digit,
+punct,   etc.),   and   is    typically   used   to   initialize   the
+ctype<char>  facet in the  classic "C"  locale (the
+protected      ctype<char>      member     function
+table()    then    returns     the    same    value    as
+classic_table()).
+
      
+
      
+However, while ctype<char>::table_size (the size of
+the   table)    is   a   public    static   const   member    of   the
+ctype<char>           specialization,           the
+classic_table() static member function is protected. That
+makes getting at the classic  data less than convenient (i.e., one has
+to create  a whole derived class just  to get at the  masks array). It
+makes  little sense  to expose  the size  of the  table in  the public
+interface while making the table itself protected, especially when the
+table is a constant object.
+
      
+
      
+The  same argument  can be  made for  the non-static  protected member
+function table().
+
      
+
+
+
      Proposed resolution:
      
+
      
+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:
+
      
+
      
+
        static locale::id id;
+  static const size_t table_size = IMPLEMENTATION_DEFINED;
+protected:
+  const mask* table() const throw();
+  static const mask* classic_table() throw();
+protected:
+
+~ctype(); // virtual
+virtual char do_toupper(char c) const;
+
      
+
      
+
+
+
+
+
+
      
+
      696. istream::operator>>(int&) broken
      
+
      Section: 27.6.1.2.2 [istream.formatted.arithmetic] Status: New
+ Submitter: Martin Sebor Date: 2007-06-23
      
+
      View other active issues in [istream.formatted.arithmetic].
      
+
      View all other issues in [istream.formatted.arithmetic].
      
+
      View all issues with New 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
+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
+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
+prevent the facet from storing the value.
 
      
 
-
      • 
 
-
    • 
+
      Proposed resolution:
      
 
      
-Efforts have been made to better support containers and smart pointers in shared
-memory contexts.  One of the key hurdles in such support is not assuming that a
-pointer type is actually a T*.  This can easily be accomplished
-for unique_ptr by having the deleter define the pointer type:
-D::pointer.  Furthermore this type can easily be defaulted to
-T* should the deleter D choose not to define a pointer
-type (reference implementation
-here).
-This change has no run time overhead.  It has no interface overhead on
-authors of custom delter types.  It simply allows (but not requires)
-authors of custom deleter types to define a smart pointer for the
-storage type of unique_ptr if they find such functionality
-useful.  std::default_delete is an example of a deleter which
-defaults pointer to T* by simply ignoring this issue
-and not including a pointer typedef.
 
      
-
      • 
 
-
    • 
+
+
+
+
+
      
+
      697. New <system_error> header leads to name clashes
      
+
      Section: 19.4 [syserr] Status: New
+ Submitter: Daniel Krügler Date: 2007-06-24
      
+
      View all issues with New status.
      
+
      Discussion:
      
 
      
-When the deleter type is a function pointer then it is unsafe to construct
-a unique_ptr without specifying the function pointer in the constructor.
-This case is easy to check for with a static_assert assuring that the
-deleter is not a pointer type in those constructors which do not accept deleters.
+The most recent state of 
+N2241
+as well as the current draft
+N2284
+(section 19.4 [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
+e.g. the following snippet invalid:
 
      
 
-
      unique_ptr<A, void(*)(void*)> p(new A);  // error, no function given to delete the pointer!
+
      #include <system_error>
+#include <stdexcept>
+
+void foo() { throw std::invalid_argument("Don't call us - we call you!"); }
 
      
 
-
      • 
+
      
+I propose that this enumeration type (and probably the remaining parts
+of
+<system_error> as well) should be moved into one additional inner
+namespace, e.g. sys or system to reduce foreseeable future clashes
+due
+to the great number of members that std::posix_errno already contains
+(Btw.: Why has the already proposed std::sys sub-namespace from
+N2066
+been rejected?). A further clash candidate seems to be
+std::protocol_error
+(a reasonable name for an exception related to a std network library,
+I guess).
+
      
+
+
      
+Another possible resolution would rely on the proposed strongly typed
+enums,
+as described in N2213.
+But maybe the forbidden implicit conversion to integral types would
+make
+these enumerators less attractive in this special case?
+
      
+
+
+
      Proposed resolution:
      
+
      
+
      
+
+
+
+
+
+
+
      
+
      698. Some system_error issues
      
+
      Section: 19.4.5.1 [syserr.syserr.overview] Status: New
+ Submitter: Daniel Krügler Date: 2007-06-24
      
+
      View all issues with New 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.
+
      
+
      
+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:
      
+
      
+
      
+
+
+
+
+
+
      
+
      700. N1856 defines struct identity
      
+
      Section: 20.2.2 [forward] Status: Ready
+ Submitter: P.J. Plauger Date: 2007-07-01
      
+
      View all issues with Ready status.
      
+
      Discussion:
      
+
      
+N1856
+defines struct identity in <utility> which clashes with
+the traditional definition of struct identity in <functional>
+(not standard, but a common extension from old STL). Be nice
+if we could avoid this name clash for backward compatibility.
+
      
+
+
+
      Proposed resolution:
      
+
      
+Change 20.2.2 [forward]:
+
      
+
+
      
+
      template <class T> struct identity
+{
+    typedef T type;
+    const T& operator()(const T& x) const;
+};
+
      
+
      
+
      const T& operator()(const T& x) const;
+
      
+
      
+
      
+Returns: x.
+
      
+
      
+
      
+
+
      
+
+
+
 
-
    
 
 
+
    
+
    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.
    
+
    Discussion:
    
+
    
+I see that the definition the associated Laguerre
+polynomials TR1 5.2.1.1 [tr.num.sf.Lnm] has been corrected since
+N1687.
+However, the draft standard only specifies ranks of integer value m,
+while the associated Laguerre polynomials are actually valid for real
+values of m > -1.  In the case of non-integer values of m, the
+definition  Ln(m) = (1/n!)exx-m (d/dx)n (e-xxm+n)
+must be used, which also holds for integer values of m.  See
+Abramowitz & Stegun, 22.11.6 for the general case, and 22.5.16-17 for
+the integer case.  In fact fractional values are most commonly used in
+physics, for example to m = +/- 1/2 to describe the harmonic
+oscillator in 1 dimension, and 1/2, 3/2, 5/2, ... in 3
+dimensions.
+
    
+
    
+If I am correct, the calculation of the more general case is no
+more difficult, and is in fact the function implemented in the GNU
+Scientific Library.  I would urge you to consider upgrading the 
+standard, either adding extra functions for real m or switching the
+current ones to double.
+
    
+
+
+
    Proposed resolution:
    
+
    
+
    
+
+
+
+
+
+
    
+
    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.
    
+
    Discussion:
    
+
    
+One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should  be
+|x| <= 1, not x >= 0.
    
+
+
+
    Proposed resolution:
    
+
    
+
    
+
+
+
+
+
+
    
+
    703. map::at() need a complexity specification
    
+
    Section: 23.3.1.2 [map.access] Status: Ready
+ Submitter: Joe Gottman Date: 2007-07-03
    
+
    View all other issues in [map.access].
    
+
    View all issues with Ready status.
    
+
    Discussion:
    
+
    
+map::at() need a complexity specification.
+
    
+
 
 
    Proposed resolution:
    
+
    
+Add the following to the specification of map::at(), 23.3.1.2 [map.access]:
+
    
+
    
+
    
+Complexity: logarithmic.
+
    
+
    
+
+
+
+
+
+
    
+
    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 requires 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 with non-Swappable allocators require value_type to be MoveConstructible and MoveAssignable.
+                                Associative containers with non-Swappable allocators require value_type to be MoveConstructible.
    swap(a,u)array requires value_type to be Swappable.
+                                Sequences with non-Swappable allocators require value_type to be Swappable, MoveConstructible and MoveAssignable.
+                                Associative containers with non-Swappable allocators require value_type to be MoveConstructible.
    
+
+
    
+
    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    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 sequences vector and deque also require 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.
    
 
 
    [
-I am grateful for the generous aid of Peter Dimov and Ion Gaztañaga in helping formulate and review
-the proposed resolutions below.
+Kona (2007): Howard and Alan to update requirements table in issue with emplace signatures.
 ]
    
 
 
-
      
-
    • 
 
-
      
-Change 20.6.5.2 [unique.ptr.single]:
-
      
 
-
      template <class T, class D = default_delete<T>> class unique_ptr {
-   ...
-   T& typename add_lvalue_reference<T>::type operator*() const;
-   ...
-};
-
      
+
      Proposed resolution:
      
+
+
+
+
+
+
+
      
+
      705. type-trait decay incompletely specified
      
+
      Section: 20.4.7 [meta.trans.other] Status: Ready
+ Submitter: Thorsten Ottosen Date: 2007-07-08
      
+
      View all issues with Ready status.
      
+
      Discussion:
      
+
      
+The current working draft has a type-trait decay in 20.4.7 [meta.trans.other].
+
      
+
+
      
+Its use is to turn C++03 pass-by-value parameters into efficient C++0x
+pass-by-rvalue-reference parameters. However, the current definition
+introduces an incompatible change where the cv-qualification of the
+parameter type is retained. The deduced type should loose such
+cv-qualification, as pass-by-value does.
+
      
+
+
+
      Proposed resolution:
      
+
      
+In 20.4.7 [meta.trans.other] change the last sentence:
+
      
+
+
      
+Otherwise the  member typedef type equals remove_cv<U>::type.
+
      
+
+
      
+In 20.3.1.2 [tuple.creation]/1 change:
+
      
+
+
      
+where each Vi in VTypes is X& if, for the
+corresponding type Ti in Types,
+remove_cv<remove_reference<Ti>::type>::type equals
+reference_wrapper<X>, otherwise Vi is
+decay<Ti>::type.
+Let Ui be decay<Ti>::type for each
+Ti in Types. Then each Vi in VTypes
+is X& if Ui equals
+reference_wrapper<X>, otherwise Vi is
+Ui.
+
      
+
+
+
+
+
 
+
      
+
      706. make_pair() should behave as make_tuple() wrt. reference_wrapper()
      
+
      Section: 20.2.3 [pairs] Status: Ready
+ Submitter: Thorsten Ottosen Date: 2007-07-08
      
+
      View all other issues in [pairs].
      
+
      View all issues with Ready status.
      
+
      Discussion:
      
 
      
-Change 20.6.5.2.4 [unique.ptr.single.observers]:
+The current draft has make_pair() in 20.2.3 [pairs]/16
+and make_tuple() in 20.3.1.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
+reference_wrapper<X> member. I suggest that the two
+functions are made to behave similar in this respect to minimize
+confusion.
 
      
 
-
      T& typename add_lvalue_reference<T>::type operator*() const;
-
      
-
-
      • 
 
-
    • 
+
      Proposed resolution:
      
 
      
-Change 20.6.5.2 [unique.ptr.single]:
+In 20.2 [utility] change the synopsis for make_pair() to read
 
      
 
-
      template <class T, class D = default_delete<T>> class unique_ptr {
-public:
-  typedef implementation (see description below) pointer;
-   ...
-   explicit unique_ptr(T* pointer p);
-   ...
-   unique_ptr(T* pointer p, implementation defined (see description below) d);
-   unique_ptr(T* pointer p, implementation defined (see description below) d);
-   ...
-   T* pointer operator->() const;
-   T* pointer get() const;
-   ...
-   T* pointer release();
-   void reset(T* pointer p = 0 pointer());
-};
+
      template <class T1, class T2>
+  pair<typename decay<T1>::type V1, typename decay<T2>::type V2> make_pair(T1&&, T2&&);
 
      
 
 
      
-
--3- If the type remove_reference<D>::type::pointer
-exists, then unique_ptr<T, D>::pointer is a typedef to
-remove_reference<D>::type::pointer.  Otherwise
-unique_ptr<T, D>::pointer is a typedef to T*.
-The type unique_ptr<T, D>::pointer must be CopyConstructible
-and CopyAssignable.
-
+In 20.2.3 [pairs]/16 change the declaration to match the above synopsis.
+Then change the 20.2.3 [pairs]/17 to:
 
      
 
+
      
 
      
-Change 20.6.5.2.1 [unique.ptr.single.ctor]:
+Returns: pair<typename decay<T1>::type V1,typename decay<T2>::type V2>(forward<T1>(x),forward<T2>(y)) where V1 and
+V2 are determined as follows: Let Ui be
+decay<Ti>::type for each Ti. Then each
+Vi is X& if Ui equals
+reference_wrapper<X>, otherwise Vi is
+Ui.
 
      
+
      
+
 
-
      unique_ptr(T* pointer p);
-...
-unique_ptr(T* pointer p, implementation defined d); 
-unique_ptr(T* pointer p, implementation defined d); 
-...
-unique_ptr(T* pointer p, const A& d);
-unique_ptr(T* pointer p, A&& d);
-...
-unique_ptr(T* pointer p, A& d); 
-unique_ptr(T* pointer p, A&& d);
-...
-unique_ptr(T* pointer p, const A& d); 
-unique_ptr(T* pointer p, const A&& d);
-...
-
      
 
-
      
--23- Requires: If D is not a reference type,
-construction of the deleter D from an rvalue of type E
-must be well formed and not throw an exception. If D is a
-reference type, then E must be the same type as D
-(diagnostic required). U* unique_ptr<U,E>::pointer
-must be implicitly convertible to T*
-pointer.
-
      
+
+
+
+
      
+
      707. null pointer constant for exception_ptr
      
+
      Section: 18.7.1 [exception] Status: Open
+ Submitter: Jens Maurer Date: 2007-07-20
      
+
      View all issues with Open status.
      
+
      Discussion:
      
 
 
      
--25- Postconditions: get() == value u.get() had before
-the construction, modulo any required offset adjustments resulting from
-the cast from U*
-unique_ptr<U,E>::pointer to T*
-pointer. get_deleter() returns a reference to the
-internally stored deleter which was constructed from
-u.get_deleter().
+From the Toronto Core wiki:
 
      
 
 
      
-Change 20.6.5.2.3 [unique.ptr.single.asgn]:
+What do you mean by "null pointer constant"? How do you guarantee that
+exception_ptr() == 1 doesn't work?  Do you even want to prevent that?
+What's the semantics?  What about void *p = 0; exception_ptr() == p?
+Maybe disallow those in the interface, but how do you do that with
+portable C++? Could specify just "make it work".
 
      
 
-
      
 
      
--8- Requires: Assignment of the deleter D from an rvalue
-D must not throw an exception. U*
-unique_ptr<U,E>::pointer must be implicitly
-convertible to T* pointer.
+Peter's response:
 
      
-
      
 
 
      
-Change 20.6.5.2.4 [unique.ptr.single.observers]:
+null pointer constant as defined in 4.10 [conv.ptr]. Intent is "just make it
+work", can be implemented as assignment operator taking a unique pointer
+to member, as in the unspecified bool type idiom.
 
      
 
-
      
-
      T* pointer operator->() const;
      
-...
-
      T* pointer get() const;
      
-
      
 
+
+
      Proposed resolution:
      
 
      
-Change 20.6.5.2.5 [unique.ptr.single.modifiers]:
 
      
 
-
      
-
      T* pointer release();
      
-...
-
      void reset(T* pointer p = 0 pointer());
      
-
      
 
+
+
+
+
      
+
      708. Locales need to be per thread and updated for POSIX changes
      
+
      Section: 22 [localization] Status: Open
+ Submitter: Peter Dimov Date: 2007-07-28
      
+
      View all other issues in [localization].
      
+
      View all issues with Open status.
      
+
      Discussion:
      
 
      
-Change 20.6.5.3 [unique.ptr.runtime]:
+The POSIX "Extended API Set Part 4,"
+
      
+
      
+http://www.opengroup.org/sib/details.tpl?id=C065
+
      
+
      
+introduces extensions to the C locale mechanism that
+allow multiple concurrent locales to be used in the same application
+by introducing a type locale_t that is very similar to
+std::locale, and a number of _l functions that make use of it.
+
      
+
      
+The global locale (set by setlocale) is now specified to be per-
+process. If a thread does not call uselocale, the global locale is
+in effect for that thread. It can install a per-thread locale by
+using uselocale.
+
      
+
      
+There is also a nice querylocale mechanism by which one can obtain
+the name (such as "de_DE") for a specific facet, even for combined
+locales, with no std::locale equivalent.
+
      
+
      
+std::locale should be harmonized with the new POSIX locale_t
+mechanism and provide equivalents for uselocale and querylocale.
 
      
 
-
      template <class T, class D> class unique_ptr<T[], D> {
-public:
-  typedef implementation pointer;
-   ...
-   explicit unique_ptr(T* pointer p);
-   ...
-   unique_ptr(T* pointer p, implementation defined d);
-   unique_ptr(T* pointer p, implementation defined d);
-   ...
-   T* pointer get() const;
-   ...
-   T* pointer release();
-   void reset(T* pointer p = 0 pointer());
-};
-
      
+
      [
+Kona (2007): Bill and Nick to provide wording.
+]
      
 
+
+
+
+
      Proposed resolution:
      
 
      
-Change 20.6.5.3.1 [unique.ptr.runtime.ctor]:
 
      
 
-
      
-
      unique_ptr(T* pointer p);
-unique_ptr(T* pointer p, implementation defined d);
-unique_ptr(T* pointer p, implementation defined d);
-
      
 
+
+
+
+
      
+
      709. char_traits::not_eof has wrong signature
      
+
      Section: 21.1.3 [char.traits.specializations] Status: New
+ Submitter: Bo Persson Date: 2007-08-13
      
+
      View all issues with New status.
      
+
      Discussion:
      
 
      
-These constructors behave the same as in the primary template except
-that they do not accept pointer types which are convertible to
-T* pointer. [Note: One
-implementation technique is to create private templated overloads of
-these members. -- end note]
+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].
 
      
-
      
 
 
      
-Change 20.6.5.3.3 [unique.ptr.runtime.modifiers]:
+Pete adds:
 
      
 
-
      
-
      void reset(T* pointer p = 0 pointer());
-
      
+
      
+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:
      
 
      
--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]
+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);
+
      
+
+
+
+
+
+
+
      
+
      710. Missing postconditions
      
+
      Section: 20.6.6.2 [util.smartptr.shared] Status: New
+ Submitter: Peter Dimov Date: 2007-08-24
      
+
      View other active issues in [util.smartptr.shared].
      
+
      View all other issues in [util.smartptr.shared].
      
+
      View all issues with New status.
      
+
      Discussion:
      
 
      
-Change 20.6.5.4 [unique.ptr.compiletime]:
+A discussion on
+comp.std.c++
+has identified a contradiction in the shared_ptr specification.
+The shared_ptr move constructor and the cast functions are
+missing postconditions for the get() accessor.
 
      
 
-
      template <class T, class D,  size_t N> class unique_ptr<T[N], D> {
-public:
-  typedef implementation pointer;
-   ...
-   explicit unique_ptr(T* pointer p);
-   ...
-   unique_ptr(T* pointer p, implementation defined d);
-   unique_ptr(T* pointer p, implementation defined d);
-   ...
-   T* pointer get() const;
-   ...
-   T* pointer release();
-   void reset(T* pointer p = 0 pointer());
-};
-
      
 
+
      Proposed resolution:
      
 
      
-Change 20.6.5.4.3 [unique.ptr.compiletime.modifiers]:
+Add to 20.6.6.2.1 [util.smartptr.shared.const]:
 
      
 
 
      
-
      void reset(T* pointer p = 0 pointer());
+
      shared_ptr(shared_ptr&& r);
+template<class Y> shared_ptr(shared_ptr<Y>&& r);
 
      
-
+
      
 
      
--1- Requires: Does not accept pointer types which are convertible
-to T* pointer (dignostic required). [Note: One implementation
-technique is to create a private templated overload. --end note]
+Postconditions:  *this shall contain the old value of r. r
+shall be empty. r.get() == 0.
 
      
-
+
      
 
      
 
-
      • 
-
-
    • 
+
      
+Add to 20.6.6.2.10 [util.smartptr.shared.cast]:
+
      
 
+
      
+
      template<class T, class U> shared_ptr<T> static_pointer_cast(shared_ptr<U> const& r);
+
      
+
      
 
      
-Change 20.6.5.2.1 [unique.ptr.single.ctor]:
+Postconditions: If w is the return value,
+w.get() == static_cast<T*>(r.get()) && w.use_count() == r.use_count().
 
      
+
      
+
      
 
 
      
-
      unique_ptr();
      
+
      template<class T, class U> shared_ptr<T> dynamic_pointer_cast(shared_ptr<U> const& r);
+
      
 
      
 
      
-Requires: D must be default constructible, and that
-construction must not throw an exception. D must not be a
-reference type or pointer type (diagnostic required).
+Postconditions: If w is the return value, w.get() == dynamic_cast<T*>(r.get()).
 
      
 
      
-
      unique_ptr(T* pointer p);
      
+
      
+
+
      
+
      template<class T, class U> shared_ptr<T> const_pointer_cast(shared_ptr<U> const& r);
+
      
 
      
 
      
-Requires:  The expression D()(p) must be well formed.
-The default constructor of D must not throw an exception.
-D must not be a reference type or pointer type (diagnostic
-required).
+Postconditions: If w is the return value,
+w.get() == const_cast<T*>(r.get()) && w.use_count() == r.use_count().
 
      
 
      
 
      
 
 
      
-Change 20.6.5.2.1 [unique.ptr.single.ctor]:
+Alberto Ganesh Barbati has written an
+alternative proposal
+where he suggests (among other things) that the casts be respecified in terms of
+the aliasing constructor as follows:
+
      
+
+
      
+Change 20.6.6.2.10 [util.smartptr.shared.cast]:
 
      
 
 
      
-
      unique_ptr();
      
+
      
+-2- Returns: If r is empty, an empty
+shared_ptr<T>; otherwise, a shared_ptr<T>
+object that stores static_cast<T*>(r.get()) and shares ownership with
+r. shared_ptr<T>(r, static_cast<T*>(r.get()).
+
      
+
      
+
 
      
 
      
-Requires: D must be default constructible, and that
-construction must not throw an exception. D must not be a
-reference type or pointer type (diagnostic required).
+-6- Returns:
 
      
+
        
+
      • When dynamic_cast<T*>(r.get()) returns a nonzero value,
+a shared_ptr<T> object that stores a copy 
+of it and shares ownership with r;
        • 
+
      • Otherwise, an empty shared_ptr<T> object.
        • 
+
      • If p = dynamic_cast<T*>(r.get()) is a non-null pointer, shared_ptr<T>(r, p);
        • 
+
      • Otherwise, shared_ptr<T>().
        • 
+
      
 
      
-
      unique_ptr(T* pointer p);
      
+
 
      
 
      
-Requires:  The expression D()(p) must be well formed.
-The default constructor of D must not throw an exception.
-D must not be a reference type or pointer type (diagnostic
-required).
+-10- Returns: If r is empty, an empty
+shared_ptr<T>; otherwise, a shared_ptr<T>
+object that stores const_cast<T*>(r.get()) and shares ownership with
+r. shared_ptr<T>(r, const_cast<T*>(r.get()).
 
      
 
      
-
    
-
-
 
-
+
    
+This takes care of the missing postconditions for the casts by bringing
+in the aliasing constructor postcondition "by reference".
+
    
 
 
 
@@ -11216,93 +12338,86 @@ required).
 
 
 
    
-
    674. shared_ptr interface changes for consistency with N1856
    
-
    Section: 20.6.6.2 [util.smartptr.shared] Status: New
- Submitter: Peter Dimov Date: 2007-05-05
    
-
    View all other issues in [util.smartptr.shared].
    
+
    711. Contradiction in empty shared_ptr
    
+
    Section: 20.6.6.2.5 [util.smartptr.shared.obs] Status: New
+ Submitter: Peter Dimov Date: 2007-08-24
    
+
    View all other issues in [util.smartptr.shared.obs].
    
 
    View all issues with New status.
    
 
    Discussion:
    
 
    
-N1856 does not propose
-any changes to shared_ptr. It needs to be updated to use a rvalue reference where appropriate
-and to interoperate with unique_ptr as it does with auto_ptr.
+A discussion on
+comp.std.c++
+has identified a contradiction in the shared_ptr specification.
+The note:
 
    
 
-
-
    Proposed resolution:
    
+
    
+[ Note: this constructor allows creation of an empty shared_ptr instance with a non-NULL stored pointer.
+-end note ]
+
    
 
 
    
-Change 20.6.6.2 [util.smartptr.shared] as follows:
+after the aliasing constructor
 
    
 
-
    
-
    template<class Y> explicit shared_ptr(auto_ptr<Y>&&& r);
-private:
-template<class Y, class D> explicit shared_ptr(const unique_ptr<Y,D>& r);
-public:
-template<class Y, class D> explicit shared_ptr(unique_ptr<Y,D>&& r);
-...
-template<class Y> shared_ptr& operator=(auto_ptr<Y>&&& r);
-
-private:
-template<class Y, class D> shared_ptr& operator=(const unique_ptr<Y,D>& r);
-public:
-template<class Y, class D> shared_ptr& operator=(unique_ptr<Y,D>&& r);
    
-
    
+
    template<class Y> shared_ptr(shared_ptr<Y> const& r, T *p);
+
    
 
 
    
-Change 20.6.6.2.1 [util.smartptr.shared.const] as follows:
+reflects the intent of
+N2351
+to, well, allow the creation of an empty shared_ptr
+with a non-NULL stored pointer.
 
    
 
-
    
-
    template<class Y> shared_ptr(auto_ptr<Y>&&& r);
    
-
    
-
 
    
-Add to 20.6.6.2.1 [util.smartptr.shared.const]:
+This is contradicted by the second sentence in the Returns clause of 20.6.6.2.5 [util.smartptr.shared.obs]:
 
    
 
 
    
-
    template<class Y, class D> shared_ptr(unique_ptr<Y, D>&& r);
    
-
    
-
-
    
-Effects: Equivalent to shared_ptr( r.release(), r.get_deleter() ) when D is
-          not a reference type, shared_ptr( r.release(), ref( r.get_deleter() ) )
-          otherwise.
-
    
-
-
    
-Exception safety: If an exception is thrown, the constructor has no effect.
-
    
+
    T* get() const;
+
    
+
    
+Returns: the stored pointer. Returns a null pointer if *this is empty.
+
    
 
    
 
-
    
 
+
+
    Proposed resolution:
    
 
    
-Change 20.6.6.2.3 [util.smartptr.shared.assign] as follows:
+In keeping the N2351 spirit and obviously my preference, change 20.6.6.2.5 [util.smartptr.shared.obs]:
 
    
 
 
    
-
    template<class Y> shared_ptr& operator=(auto_ptr<Y>&&& r);
    
+
    T* get() const;
+
    
+
    
+Returns: the stored pointer. Returns a null pointer if *this is empty.
+
    
 
    
 
 
    
-Add to 20.6.6.2.3 [util.smartptr.shared.assign]:
+Alternative proposed resolution: (I won't be happy if we do this, but it's possible):
 
    
 
-
    
-
    template<class Y, class D> shared_ptr& operator=(unique_ptr<Y,D>&& r);
    
+
    
+Change 20.6.6.2.1 [util.smartptr.shared.const]:
+
    
 
 
    
-
    
--4- Effects: Equivalent to shared_ptr(std::move(r)).swap(*this).
-
    
-
    
--5- Returns: *this.
-
    
+
    template<class Y> shared_ptr(shared_ptr<Y> const& r, T *p);
+
    
+
    
+
    
+Requires: If r is empty, p shall be 0.
+
    
+
    
+[ Note: this constructor allows creation of an empty shared_ptr
+instance with a non-NULL stored pointer. 
+-- end note ]
+
    
 
    
-
 
    
 
 
@@ -11311,73 +12426,88 @@ Add to 20.6.6.2.3 [util.smartptr.shared.assign]:
 
 
 
    
-
    675. Move assignment of containers
    
-
    Section: 23.1 [container.requirements] Status: New
- Submitter: Howard Hinnant Date: 2007-05-05
    
-
    View other active issues in [container.requirements].
    
-
    View all other issues in [container.requirements].
    
+
    713. sort() complexity is too lax
    
+
    Section: 25.3.1.1 [sort] Status: New
+ Submitter: Matt Austern Date: 2007-08-30
    
 
    View all issues with New 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).
+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.
 
    
 
-
    vector<shared_ptr<ostream>> v1;
-vector<shared_ptr<ostream>> v2;
-...
-v1 = v2;               // #1
-v1 = std::move(v2);    // #2
-
    
 
+
    Proposed resolution:
    
 
    
-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.
+In 25.3.1.1 [sort], change the complexity to "O(N log N)", and remove footnote 266:
 
    
 
+
    
 
    
-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()).
+Complexity: Approximately O(N log(N)) (where N == last - first )
+comparisons on the average.266)
 
    
-
 
    
-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.
+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.9 [alg.search] Status: New
+ Submitter: Matt Austern Date: 2007-08-30
    
+
    View all other issues in [alg.search].
    
+
    View all issues with New status.
    
+
    Discussion:
    
+
    
+The complexity for search_n (25.1.9 [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 23.1 [container.requirements]:
+Change the complexity to "At most (last - first) applications of the corresponding predicate".
 
    
 
 
    
-
-
-
-
-
-
-
-
-
-
-
-
-
    Table 86: 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
-constant linear
    
+
    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.
+
    
+
    
 
    
 
 
@@ -11386,605 +12516,652 @@ before this construction
 
 
 
    
-
    676. Moving the unordered containers
    
-
    Section: 23.4 [unord] Status: New
- Submitter: Howard Hinnant Date: 2007-05-05
    
-
    View other active issues in [unord].
    
-
    View all other issues in [unord].
    
+
    715. minmax_element complexity is too lax
    
+
    Section: 25.3.7 [alg.min.max] Status: New
+ Submitter: Matt Austern Date: 2007-08-30
    
+
    View all other issues in [alg.min.max].
    
 
    View all issues with New 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".
+The complexity for minmax_element (25.3.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
+well known technique that does better: see section 9.1 of CLRS
+(Introduction to Algorithms, by Cormen, Leiserson, Rivest, and Stein).
 
    
 
 
-
 
    Proposed resolution:
    
+
    
+Change 25.3.7 [alg.min.max] to:
+
    
 
+
    
+
    template<class ForwardIterator> 
+  pair<ForwardIterator, ForwardIterator> 
+    minmax_element(ForwardIterator first , ForwardIterator last); 
+template<class ForwardIterator, class Compare> 
+  pair<ForwardIterator, ForwardIterator> 
+    minmax_element(ForwardIterator first , ForwardIterator last , Compare comp);
+
    
+
    
 
    
-Add to 23.4 [unord]:
+Returns: make_pair(m, M), where m is
+min_element(first, last) or min_element(first, last,
+comp) the first iterator i in [first,
+last) such that no other element in the range is smaller, and
+where M is max_element(first, last) or
+max_element(first, last, comp) the last iterator
+i in [first, last) such that no other element in the
+range is larger.
+
    
+
    
+Complexity: At most max(2 * (last - first ) - 2, 0)
+max(⌊(3/2) (N-1)⌋, 0) applications of the
+corresponding comparisons predicate, where N is distance(first, last).
 
    
+
    
+
    
 
-
    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);
+
    
+
    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.
    
+
    Discussion:
    
+
    
+TR1 7.13 [tr.re.grammar]/3 and C++0x WP 28.13 [re.grammar]/3 say:
+
    
 
-...
+
    
+
    
+The following productions within the ECMAScript grammar are modified as follows:
+
    
 
-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); 
+
    CharacterClass ::
+[ [lookahead ∉ {^}] ClassRanges ]
+[ ^ ClassRanges ]
+
    
 
-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);
+
    
+This definition for CharacterClass appears to be exactly identical to that in ECMA-262.
+
    
 
-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);
+
    
+Was an actual modification intended here and accidentally omitted, or was this production accidentally included?
+
    
 
-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);
+
    Proposed resolution:
    
+
    
+Remove this mention of the CharacterClass production.
+
    
+
+
    CharacterClass ::
+[ [lookahead ∉ {^}] ClassRanges ]
+[ ^ ClassRanges ]
 
    
 
-
    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);
-
    
+
    
+
    717. Incomplete valarray::operator[] specification in [valarray.access]
    
+
    Section: 26.5.2.3 [valarray.access] Status: New
+ Submitter: Daniel Krügler Date: 2007-08-27
    
+
    View all other issues in [valarray.access].
    
+
    View all issues with New 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
+incompletely
+specified, because many requirements and guarantees should now also
+apply to the const overload. Most notably, the address and reference
+guarantees should be extended to the const overload case.
+
    
 
+
+
    Proposed resolution:
    
 
    
-Add to 23.4.1.1 [unord.map.cnstr]:
+Change 26.5.2.3 [valarray.access]:
 
    
 
 
    
-
    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.
-
-
    
-
    
+
    
+-1- When applied to a constant array, the subscript operator returns a
+reference to the corresponding element of the array. When applied to a
+non-constant array, tThe subscript operator returns a
+reference to the corresponding element of the array.
+
    
 
 
    
-Add to 23.4.1.2 [unord.map.elem]:
+-3- The expression &a[i+j] == &a[i] + j evaluates as true for all size_t i
+and size_t j such that i+j is less 
+than the length of the non-constant array a.
 
    
 
-
    
+
    
+-4- Likewise, the expression &a[i] != &b[j] evaluates
+as true for any two non-constant arrays a and
+b and for any size_t i and size_t j such that
+i is less than the length of a and j is less
+than the length of b. This property indicates an absence of
+aliasing and may be used to advantage by optimizing
+compilers.281)
+
    
 
-
    mapped_type& operator[](const key_type& k);
    
+
    
+-5- The reference returned by the subscript operator for an non-constant array is guaranteed to be valid until
+the member function resize(size_t, T) (26.5.2.7) is called for that array or until the lifetime 
+of that array ends, whichever happens first.
+
    
 
-
    
-
    ...
    
-
    
-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.
-
    
 
-
    
 
+
    
+
    718. basic_string is not a sequence
    
+
    Section: 21.3 [basic.string] Status: New
+ Submitter: Bo Persson Date: 2007-08-18
    
+
    View other active issues in [basic.string].
    
+
    View all other issues in [basic.string].
    
+
    View all issues with New status.
    
+
    Discussion:
    
+
    
+Paragraph 21.3 [basic.string]/3 states:
+
    
+
+
    
+
    
+The class template basic_string conforms to the requirements for a 
+Sequence (23.1.1) and for a Reversible Container (23.1).
+
    
 
    
 
 
    
-Add new section [unord.map.modifiers]:
+First of all, 23.1.1 [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.
 
    
 
-
    
-
    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.
-
    
+
    Proposed resolution:
    
+
    
+Remove this sentence, in recognition of the fact that basic_string is 
+not just a vector-light for literal types, but something quite 
+different, a string abstraction in its own right.
+
    
 
-
    
-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.
-
    
 
-
    
 
-
    
 
+
    
+
    719. std::is_literal type traits should be provided
    
+
    Section: 20.4 [meta] Status: New
+ Submitter: Daniel Krügler Date: 2007-08-25
    
+
    View all other issues in [meta].
    
+
    View all issues with New status.
    
+
    Discussion:
    
 
    
-Add to 23.4.1.3 [unord.map.swap]:
+Since the inclusion of constexpr in the standard draft N2369 we have
+a new type category "literal", which is defined in 3.9 [basic.types]/p.11:
 
    
 
 
    
-
    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);
-
    
+
    
+-11- A type is a literal type if it is:
+
    
+
      
+
    • a scalar type; or
      • 
+
    • a class type (clause 9) with
      
+
        
+
      • a trivial copy constructor,
        • 
+
      • a trivial destructor,
        • 
+
      • at least one constexpr constructor other than the copy constructor,
        • 
+
      • no virtual base classes, and
        • 
+
      • all non-static data members and base classes of literal types; or
        • 
+
      
+
      • 
+
    • an array of literal type.
      • 
+
    
 
    
 
-
    unordered_multimap
    
+
    
+I strongly suggest that the standard provides a type traits for
+literal types in 20.4.4.3 [meta.unary.prop] for several reasons:
+
    
+
+
      
+
    1. To keep the traits in sync with existing types.
      2. 
+
    2. I see many reasons for programmers to use this trait in template
+   code to provide optimized template definitions for these types,
+   see below.
      3. 
+
    3. A user-provided definition of this trait is practically impossible
+to write portably.
      4. 
+
    
 
 
    
-Change 23.4.2 [unord.multimap]:
+The special problem of reason (c) is that I don't see currently a
+way to portably test the condition for literal class types:
 
    
 
-
    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&&);
-    ...
-};
+
    
+
      
+
    • at least one constexpr constructor other than the copy constructor,
      • 
+
    
+
    
 
-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);
+
    
+Here follows a simply example to demonstrate it's usefulness:
+
    
 
-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 <typename T>
+constexpr typename std::enable_if<std::is_literal<T>::value, T>::type
+abs(T x) {
+  return x < T() ? -x : x;
+}
 
-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 <typename T>
+typename std::enable_if<!std::is_literal<T>::value, T>::type
+abs(const T& x) {
+  return x < T() ? -x : x;
+}
 
    
 
 
    
-Add to 23.4.2.1 [unord.multimap.cnstr]:
+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).
 
    
 
-
    
-
    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.
-
-
    
-
    
 
+
    Proposed resolution:
    
 
    
-Add new section [unord.multimap.modifiers]:
+In 20.4.2 [meta.type.synop] in the group "type properties",
+just below the line
 
    
 
-
    
-
    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);
-
    
+
    template <class T> struct is_pod;
+
    
 
-
    
-
    
-Requires: Those signatures taking a const value_type& parameter
-requires both the key_type and the mapped_type to be
-CopyConstructible.
-
    
+
    
+add a new one:
+
    
 
-
    
-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).
-
    
+
    template <class T> struct is_literal;
+
    
+
+
    
+In 20.4.4.3 [meta.unary.prop], table Type Property Predicates, just
+below the line for the is_pod property add a new line:
+
    
+
+
+
+
+
+
+
+
+
+
+
    TemplateConditionPreconditions
    template <class T> struct is_literal;T is a literal type (3.9)T shall be a complete type, an
+array of unknown bound, or
+(possibly cv-qualified) void.
    
+
+
+
+
+
+
+
    
+
    720. Omissions in constexpr usages
    
+
    Section: 23.2.1 [array], 23.3.5 [template.bitset] Status: New
+ Submitter: Daniel Krügler Date: 2007-08-25
    
+
    View other active issues in [array].
    
+
    View all other issues in [array].
    
+
    View all issues with New 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. 
+
    
 
-
    
-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.
-
    
-
    
 
-
    
+
    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;
+
      
 
 
      
-Add to 23.4.2.2 [unord.multimap.swap]:
+and in 23.3.5.2 [bitset.members] change
 
      
 
-
      
-
      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);
-
      
-
      
+
      constexpr bool test(size_t pos ) const;
+
      
+
+
      3. 
+
    
+
+
 
-
    unordered_set
    
 
+
+
    
+
    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.
    
+
    Discussion:
    
 
    
-Change 23.4.3 [unord.set]:
+Paragraph 3 says that the Codecvt template parameter shall meet the 
+requirements of std::codecvt, even though std::codecvt itself cannot 
+be used (because of a protected destructor).
 
    
 
-
    class unordered_set
+
    
+How are we going to explain this code to beginning programmers?
+
    
+
+
    template<class I, class E, class S>
+struct codecvt : std::codecvt<I, E, S>
 {
-    ...
-    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&&);
-    ...
+    ~codecvt()
+    { }
 };
 
-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);
+void main()
+{
+    std::wstring_convert<codecvt<wchar_t, char, std::mbstate_t> > compiles_ok;
+    
+    std::wstring_convert<std::codecvt<wchar_t, char, std::mbstate_t> >   not_ok;
+}
+
    
 
-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);
-
    
 
+
    Proposed resolution:
    
 
    
-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.
-
-
    
-
    
 
+
+
+
    
+
    722. Missing [c.math] functions nanf and nanl
    
+
    Section: 26.7 [c.math] Status: New
+ Submitter: Daniel Krügler Date: 2007-08-27
    
+
    View other active issues in [c.math].
    
+
    View all other issues in [c.math].
    
+
    View all issues with New status.
    
+
    Discussion:
    
 
    
-Add new section [unord.set.modifiers]:
+In the listing of 26.7 [c.math], table 108: Header <cmath> synopsis I miss
+the following C99 functions (from 7.12.11.2):
 
    
 
-
    
-
    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);
-
    
+
    float nanf(const char *tagp);
+long double nanl(const char *tagp);
+
    
 
-
    
+
    
+(Note: These functions cannot be overloaded and they are also not
+listed anywhere else)
+
    
 
-
    
-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.
-
    
+
    Proposed resolution:
    
+
    
+In 26.7 [c.math], table 108, section "Functions", add nanf and nanl
+just after the existing entry nan.
+
    
+
 
-
    
 
-
    
 
+
+
    
+
    723. basic_regex should be moveable
    
+
    Section: 28.8 [re.regex] Status: New
+ Submitter: Daniel Krügler Date: 2007-08-29
    
+
    View all other issues in [re.regex].
    
+
    View all issues with New status.
    
+
    Discussion:
    
 
    
-Add to 23.4.3.2 [unord.set.swap]:
+According to the current state of the standard draft, the class
+template basic_regex, as described in 28.8 [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
+use cases, where a factory function returns regex values,
+which would take advantage of moveabilities.
 
    
 
-
    
-
    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
    
 
+
    Proposed resolution:
    
+
      
+
    1. 
 
      
-Change 23.4.4 [unord.multiset]:
+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. 
 
-
      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&&);
-    ...
-};
+
    2. 
+
      Just after the copy c'tor:
      
+
      basic_regex(basic_regex&&);
+
      
+
      3. 
 
-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);
+
    3. 
+
      Just after the copy-assignment op.:
      
+
      basic_regex& operator=(basic_regex&&);
+
      
+
      4. 
 
-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);
+
    4. 
+
      Just after the first assign overload insert:
      
+
      basic_regex& assign(basic_regex&& that);
+
      
+
      5. 
 
-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);
+
    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. 
+
    
 
 
    
-Add to 23.4.4.1 [unord.multiset.cnstr]:
+Of course there would be need of corresponding proper standardese
+to describe these additions.
 
    
 
-
    
-
    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.
-
-
    
-
    
 
+
+
+
+
    
+
    724. DefaultConstructible is not defined
    
+
    Section: 20.1.1 [utility.arg.requirements] Status: New
+ 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 New status.
    
+
    Discussion:
    
+
    
+The DefaultConstructible requirement is referenced in
+several places in the August 2007 working draft
+N2369,
+but is not defined anywhere.
+
    
+
+
+
    Proposed resolution:
    
 
    
-Add new section [unord.multiset.modifiers]:
+In section 20.1.1 [utility.arg.requirements], before table 33, add the
+following table:
 
    
 
-
    
-
    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);
-
    
+
    Table 33: DefaultConstructible requirements
    
 
-
    
+
    
 
-
    
-Requires: Those signatures taking a const
-value_type& parameter requires the value_type to
-be CopyConstructible.
-
    
+
+ 
+  
+  
+ 
+ 
+  
+  
+ 
+
    
+  
    expression
    
+      		
+  
    post-condition
    
+  
    
+  
    T
+  t;
    
+  T()
    
+      		
+  
    T
+  is default constructed.
    
+  
    
 
-
    
-The signature taking InputIterator parameters requires
-CopyConstructible of value_type if the dereferenced
-InputIterator returns an lvalue or const rvalue
-value_type.
-
    
+
    
 
-
    
 
-
    
+
+
+
+
+
    
+
    725. Optional sequence container requirements column label
    
+
    Section: 23.1.1 [sequence.reqmts] Status: New
+ Submitter: David Abrahams Date: 2007-09-16
    
+
    View all other issues in [sequence.reqmts].
    
+
    View all issues with New status.
    
+
    Discussion:
    
+
    
+Table 90: (Optional sequence container operations) states the
+"assertion note pre/post-condition" of operator[] to be
+
    
+
+
    *(a.begin() + n)
+
    
 
 
    
-Add to 23.4.4.2 [unord.multiset.swap]:
+Surely that's meant to be "operational semantics?"
 
    
 
+
+
+
    Proposed resolution:
    
 
    
-
    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);
-
    
+
+
+
+
+
+
    Table 90: Optional sequence container operations
    expression return type assertion/note
    pre/post-condition
     operational semantics    		 container
    
 
    
 
 
@@ -11993,169 +13170,227 @@ Add to 23.4.4.2 [unord.multiset.swap]:
 
 
 
    
-
    677. Weaknesses in seed_seq::randomize [rand.util.seedseq]
    
-
    Section: 26.4.7.1 [rand.util.seedseq] Status: New
- Submitter: Charles Karney Date: 2007-05-15
    
-
    View other active issues in [rand.util.seedseq].
    
-
    View all other issues in [rand.util.seedseq].
    
+
    726. Missing regex_replace() overloads
    
+
    Section: 28.11.4 [re.alg.replace] Status: New
+ Submitter: Stephan T. Lavavej Date: 2007-09-22
    
+
    View other active issues in [re.alg.replace].
    
+
    View all other issues in [re.alg.replace].
    
 
    View all issues with New status.
    
 
    Discussion:
    
 
    
-seed_seq::randomize provides a mechanism for initializing random number
-engines which ideally would yield "distant" states when given "close"
-seeds.  The algorithm for seed_seq::randomize given in the current
-Working Draft for C++,
-N2284
-(2007-05-08), has 3 weaknesses
-
    
+Two overloads of regex_replace() are currently provided:
+
    
+
+
    template <class OutputIterator, class BidirectionalIterator, 
+    class traits, class charT> 
+  OutputIterator 
+  regex_replace(OutputIterator out, 
+                BidirectionalIterator first, BidirectionalIterator last, 
+                const basic_regex<charT, traits>& e, 
+                const basic_string<charT>& fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);
+ 
+template <class traits, class charT> 
+  basic_string<charT> 
+  regex_replace(const basic_string<charT>& s, 
+                const basic_regex<charT, traits>& e, 
+                const basic_string<charT>& fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);
+
    
 
 
      
+
    1. Overloads taking const charT * are provided for regex_match() and
+regex_search(), but not regex_replace().  This is inconsistent.
      2. 
 
    2. 
-
       Collisions in state.  Because of the way the state is initialized,
-    seeds of different lengths may result in the same state.  The
-    current version of seed_seq has the following properties:
      
-
        
-
      •   For a given s <= n, each of the 2^(32s) seed vectors results in a
-      distinct state.
        • 
-
      
-
      
-    The proposed algorithm (below) has the considerably stronger
-    properties:
      
-
        
-
      •    All of the (2^(32n)-1)/(2^32-1) seed vectors of lengths s < n
-      result in distinct states.
-
        • 
-
      •   All of the 2^(32n) seed vectors of length s == n result in
-      distinct states.
-
        • 
-
      
-
      3. 
-
    3. 
-
       Poor mixing of v's entropy into the state.  Consider v.size() == n
-    and hold v[n/2] thru v[n-1] fixed while varying v[0] thru v[n/2-1],
-    a total of 2^(16n) possibilities.  Because of the simple recursion
-    used in seed_seq, begin[n/2] thru begin[n-1] can take on only 2^64
-    possible states.
      
-
-
       The proposed algorithm uses a more complex recursion which results
-    in much better mixing.
      
-
      4. 
-
    4.  seed_seq::randomize is undefined for v.size() == 0.  The proposed
-    algorithm remedies this.
-
      5. 
-
    
+
    The absence of const charT * overloads prevents ordinary-looking code from compiling, such as:
    
+
+
    const string s("kitten");
+const regex r("en");
+cout << regex_replace(s, r, "y") << endl;
+
    
+
 
    
-The current algorithm for seed_seq::randomize is adapted by me from the
-initialization procedure for the Mersenne Twister by Makoto Matsumoto
-and Takuji Nishimura.  The weakness (2) given above was communicated to
-me by Matsumoto last year.
+The compiler error message will be something like "could not deduce
+template argument for 'const std::basic_string<_Elem> &' from 'const
+char[1]'".
 
    
+
 
    
-The proposed replacement for seed_seq::randomize is due to Mutsuo Saito,
-a student of Matsumoto, and is given in the implementation of the
-SIMD-oriented Fast Mersenne Twister random number generator SFMT.
-http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html
-http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/SFMT-src-1.2.tar.gz
+Users expect that anything taking a basic_string<charT> can also take a
+const charT *.  In their own code, when they write a function taking
+std::string (or std::wstring), they can pass a const char * (or const
+wchar_t *), thanks to basic_string's implicit constructor.  Because the
+regex algorithms are templated on charT, they can't rely on
+basic_string's implicit constructor (as the compiler error message
+indicates, template argument deduction fails first).
 
    
+
 
    
-See
-Mutsuo Saito,
-An Application of Finite Field: Design and Implementation of 128-bit
-Instruction-Based Fast Pseudorandom Number Generator,
-Master's Thesis, Dept. of Math., Hiroshima University (Feb. 2007)
-http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/M062821.pdf
+If a user figures out what the compiler error message means, workarounds
+are available - but they are all verbose.  Explicit template arguments
+could be given to regex_replace(), allowing basic_string's implicit
+constructor to be invoked - but charT is the last template argument, not
+the first, so this would be extremely verbose.  Therefore, constructing
+a basic_string from each C string is the simplest workaround.
 
    
+
+
+
  • 
+There is an efficiency consideration: constructing basic_strings can
+impose performance costs that could be avoided by a library
+implementation taking C strings and dealing with them directly. 
+(Currently, for replacement sources, C strings can be converted into
+iterator pairs at the cost of verbosity, but for format strings, there
+is no way to avoid constructing a basic_string.)
+
    • 
+
+
+
+
+
    Proposed resolution:
    
 
    
-One change has been made here, namely to treat the case of small n
-(setting t = (n-1)/2 for n < 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]:
 
    
+
+
    
+
    template <class OutputIterator, class BidirectionalIterator, 
+    class traits, class charT> 
+  OutputIterator 
+  regex_replace(OutputIterator out, 
+                BidirectionalIterator first, BidirectionalIterator last, 
+                const basic_regex<charT, traits>& e, 
+                const basic_string<charT>& fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);
+
+template <class OutputIterator, class BidirectionalIterator, 
+    class traits, class charT> 
+  OutputIterator 
+  regex_replace(OutputIterator out, 
+                BidirectionalIterator first, BidirectionalIterator last, 
+                const basic_regex<charT, traits>& e, 
+                const charT* fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);
+
    
+
    ...
    
+
    template <class traits, class charT> 
+  basic_string<charT> 
+  regex_replace(const basic_string<charT>& s, 
+                const basic_regex<charT, traits>& e, 
+                const basic_string<charT>& fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);
+
+template <class traits, class charT> 
+  basic_string<charT> 
+  regex_replace(const basic_string<charT>& s, 
+                const basic_regex<charT, traits>& e, 
+                const charT* fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);
+
+template <class traits, class charT> 
+  basic_string<charT> 
+  regex_replace(const charT* s, 
+                const basic_regex<charT, traits>& e, 
+                const basic_string<charT>& fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);
+
+template <class traits, class charT> 
+  basic_string<charT> 
+  regex_replace(const charT* s, 
+                const basic_regex<charT, traits>& e, 
+                const charT* fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);
+
    
+
    
+
+
+
+
+
+
+
    
+
    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
    
+
    View other active issues in [re.alg.replace].
    
+
    View all other issues in [re.alg.replace].
    
+
    View all issues with New status.
    
+
    Discussion:
    
 
    
-Since seed_seq was introduced relatively recently there is little cost
-in making this incompatible improvement to it.
+regex_match() and regex_search() take const basic_string<charT, ST,
+SA>&.  regex_replace() takes const basic_string<charT>&.  This prevents
+regex_replace() from accepting basic_strings with custom traits and
+allocators.
 
    
 
 
 
    Proposed resolution:
    
 
    
-The following is the proposed replacement of paragraph 8 of section
-26.4.7.1 [rand.util.seedseq]:
+Overloads of regex_replace() taking basic_string should be additionally
+templated on class ST, class SA and take const basic_string<charT, ST,
+SA>&.  Consistency with regex_match() and regex_search() would place
+class ST, class SA as the first template arguments; compatibility with
+existing code using TR1 and giving explicit template arguments to
+regex_replace() would place class ST, class SA as the last template
+arguments.
+
    
+
+
+
+
+
+
    
+
    728. Problem in [rand.eng.mers]/6
    
+
    Section: 26.4.3.2 [rand.eng.mers] Status: New
+ Submitter: Stephan Tolksdorf Date: 2007-09-21
    
+
    View all issues with New 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].
 
    
 
-
    
 
    
--8- Effects: With s = v.size() and n =
-end - begin, fills the supplied range [begin, end)
-according to the following algorithm in which each operation is to be
-carried out modulo 232, each indexing operator applied to
-begin is to be taken modulo n, each indexing
-operator applied to v is to be taken modulo s,
-and T(x) is defined as x xor (x
-rshift 30 27):
+I see two possible resolutions: 
 
    
 
 
      
-
    1. Set begin[0] to 5489 + s. Then,
-iteratively for k = 1, ... , n - 1, set
-begin[k] to
      
-
      1812433253 * T(begin[k-1]) + k.
-
      
-
      2. 
-
    2. With m as the larger of s and
-n, transform each element of the range (possibly more
-than once): iteratively for k = 0, ..., m - 1,
-set begin[k] to
      
-
      (begin[k] xor (1664525 * T(begin[k-1]))) + v[k] + (k mod s).
-
      
-
      3. 
-
    3. Transform each element of the range one last time, beginning
-where the previous step ended: iteratively for k = m
-mod n, ..., n - 1, 0, ..., (m - 1) mod
-n, set begin[k] to
      
-
      (begin[k] xor (1566083941 * T(begin[k-1]))) - k.
-
      
+
    4. 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)
      5. 
+
    5. 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
 
      6. 
 
    
 
-
    
-fill(begin, end, 0x8b8b8b8b);
-
-if (n >= 623)
-    t = 11;
-else if (n >= 68)
-    t = 7;
-else if (n >= 39)
-    t = 5;
-else if (n >= 7)
-    t = 3;
-else
-    t = (n-1)/2;
-
-p = (n-t)/2;
-q = p+t;
-
-m = max(s+1, n);
-for (k = 0; k < m; k += 1) {
-    r = 1664525 * T(begin[k] ^ begin[k+p] ^ begin[k-1]);
-    begin[k+p] += r;
-    r += k % n;
-    if (k == 0)
-        r += s;
-    else if (k <= s)
-        r += v[k-1];
-    begin[k+q] += r;
-    begin[k] = r;
-}
+
    
+See N2423
+for further discussion.
+
    
 
-for (k = m; k < m + n; k += 1) {
-    r = 1566083941 * T(begin[k] + begin[k+p] + begin[k-1]);
-    begin[k+p] ^= r;
-    r -= k % n;
-    begin[k+q] ^= r;
-    begin[k] = r;
-}
-
    
 
-
    
+
+
    Proposed resolution:
    
+
+
    
+See N2423
+for the proposed resolution.
+
    
 
 
 
@@ -12163,308 +13398,382 @@ for (k = m; k < m + n; k += 1) {
 
 
 
    
-
    678. Changes for [rand.req.eng]
    
+
    729. Problem in [rand.req.eng]/3
    
 
    Section: 26.4.1.3 [rand.req.eng] Status: New
- Submitter: Charles Karney Date: 2007-05-15
    
-
    View other active issues in [rand.req.eng].
    
+ Submitter: Stephan Tolksdorf Date: 2007-09-21
    
 
    View all other issues in [rand.req.eng].
    
 
    View all issues with New status.
    
 
    Discussion:
    
 
    
-Section 26.4.1.3 [rand.req.eng] Random number engine requirements:
+The 3rd table row in 26.4.1.3 [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 
+to either use a seeding method that completely depends on the result_type (see the discussion 
+of seeding for the mersenne_twister_engine in point T2 above) or at least to throw away "bits 
+of randomness" in the seed value if the result_type is smaller than the seed type. This seems 
+to be inappropriate for many modern random number generators, in particular F2-linear or 
+cryptographic ones, which operate on an internal bit array that in principle is independent of the 
+type of numbers returned.
 
    
 
 
    
-This change follows naturally from the proposed change to
-seed_seq::randomize in 677.
+Posible resolution: I propose to change the wording to a version similar to "Creates an 
+engine with initial state determined by static_cast<UintType>(s), where UintType is an 
+implementation specific unsigned integer type."
 
    
 
 
    
-In table 104 the description of X(q) contains a special treatment of
-the case q.size() == 0.  This is undesirable for 4 reasons:
+Additionally, the definition of s in 26.4.1.3 [rand.req.eng]/1 c) could be restricted to unsigned integer types.
 
    
 
-
      
-
    1. It replicates the functionality provided by X().
      2. 
-
    2. It leads to the possibility of a collision in the state provided
-    by some other X(q) with q.size() > 0.
      3. 
-
    3. 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
-there is no special treatment of q.size() == 0.
      4. 
-
    4. The proposed replacement for seed_seq::randomize given above
-    allows for the case q.size() == 0.
      5. 
-
    
+
    
+Similarly, the type of the seed in 26.4.1.4 [rand.req.adapt]/3 e) could be left unspecified.
+
    
 
+
    
+See N2423
+for further discussion.
+
    
 
 
-
    Proposed resolution:
    
 
+
    Proposed resolution:
    
 
    
-I recommend removing the special-case treatment of q.size() == 0.  Here
-is the replacement line for table 104 of section 26.4.1.3 [rand.req.eng]:
+See N2423
+for further discussion.
 
    
 
-
    
-
-
-
-
-
-
-
-
    X(q)272-
-With n = q.size(), creates an 
-engine u with initial state 
-determined as follows: If n is 0, u 
-== X(); otherwise, the Create an engine u with an initial state which
-depends on a sequence produced by 
-one call to q.randomize.
-
-O(max(n q.size(), size of state))
-
    
-
    
-
 
 
 
 
 
 
    
-
    679. resize parameter by value
    
-
    Section: 23.2 [sequences] Status: New
- Submitter: Howard Hinnant Date: 2007-06-11
    
+
    730. Comment on [rand.req.adapt]/3 e)
    
+
    Section: 26.4.1.4 [rand.req.adapt] Status: New
+ Submitter: Stephan Tolksdorf Date: 2007-09-21
    
 
    View all issues with New status.
    
 
    Discussion:
    
 
    
-The C++98 standard specifies that one member function alone of the containers
-passes its parameter (T) by value instead of by const reference:
+If an engine adaptor is invoked with an argument of type seed_seq, then all base 
+engines are specified to be seeded with this seed_seq. As seed_seq's randomization method is 
+qualified as constant, this procedure will ef fectively initialize all base engines with the same seed 
+(though the resulting state might still dif fer to a certain degree if the engines are of different types). 
+It is not clear whether this mode of operation is in general appropriate, hence -- as far as the 
+stated requirements are of general nature and not just specific to the engine adaptors provided by 
+the library -- it might be better to leave the behaviour unspecified, since the current definition of 
+seed_seq does not allow for a generally satisfying specification.
 
    
 
-
    void resize(size_type sz, T c = T());
-
    
-
 
    
-This fact has been discussed / debated repeatedly over the years, the first time
-being even before C++98 was ratified.  The rationale for passing this parameter by
-value has been:
+Posssible resolution: [As above]
 
    
 
-
    
 
    
-So that self referencing statements are guaranteed to work, for example:
+See N2423
+for further discussion.
 
    
-
    v.resize(v.size() + 1, v[0]);
-
    
-
    
 
-
    
-However this rationale is not convincing as the signature for push_back is:
-
    
 
-
    void push_back(const T& x);
-
    
 
+
    Proposed resolution:
    
 
    
-And push_back has similar semantics to resize (append).
-And push_back must also work in the self referencing case:
+See N2423
+for the proposed resolution.
 
    
 
-
    v.push_back(v[0]);  // must work
-
    
 
+
+
+
+
    
+
    731. proposal for a customizable seed_seq
    
+
    Section: 26.4.7.1 [rand.util.seedseq] Status: New
+ Submitter: Stephan Tolksdorf Date: 2007-09-21
    
+
    View all other issues in [rand.util.seedseq].
    
+
    View all issues with New status.
    
+
    Discussion:
    
 
    
-The problem with passing T by value is that it can be significantly more
-expensive than passing by reference.  The converse is also true, however when it is
-true it is usually far less dramatic (e.g. for scalar types).
+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 
+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. 
+
    
+
    
+In my opinion this is a pretty strong argument for extending the standard with a simple facility to 
+customize the seeding procedure. This could, for example, be done with the following minimal 
+changes:
 
    
 
 
    
-Even with move semantics available, passing this parameter by value can be expensive.
-Consider for example vector<vector<int>>:
+Possible resolution:
 
    
 
-
    std::vector<int> x(1000);
-std::vector<std::vector<int>> v;
-...
-v.resize(v.size()+1, x);
+
      
+
    1. 
+Turn the interface specification of 26.4.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).
+
      2. 
+
    2. 
+Provide the class seed_seq as a default implementation of the SeedSeq interface.
+
      3. 
+
    3. 
+
      
+Supplement the seed_seq with a traits class
+
      
+
      template <typename T> 
+struct is_seed_seq { static const bool value = false; }
 
      
+
      and the specialization
      
+
      template <> 
+struct is_seed_seq<seed_seq> { static const bool value = true; }
+
      
+
      which users can supplement with further specializations.
      
+
      4. 
+
    4. 
+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 
+could be done using the SFINAE technique).
+
      5. 
+
    
+
 
+
    Proposed resolution:
    
 
    
-In the pass-by-value case, x is copied once to the parameter of
-resize.  And then internally, since the code can not know at compile
-time by how much resize is growing the vector, x is
-usually copied (not moved) a second time from resize's parameter into its proper place
-within the vector.
+See N2423
+for the proposed resolution.
 
    
 
+
+
+
+
+
    
+
    732. Defect in [rand.dist.samp.genpdf]
    
+
    Section: 26.4.8.5.3 [rand.dist.samp.genpdf] Status: New
+ Submitter: Stephan Tolksdorf Date: 2007-09-21
    
+
    View all issues with New status.
    
+
    Discussion:
    
 
    
-With pass-by-const-reference, the x in the above example need be copied
-only once.  In this case, x has an expensive copy constructor and so any
-copies that can be saved represents a significant savings.
+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.
 
    
 
 
    
-If we can be efficient for push_back, we should be efficient for resize
-as well.  The resize taking a reference parameter has been coded and shipped in the
-CodeWarrior library with no reports of problems which I am aware of.
+Possible resolution: For these reasons, I propose to delete section 26.4.8.5.3 [rand.dist.samp.genpdf].
 
    
 
 
-
 
    Proposed resolution:
    
 
    
-Change 23.2.2 [deque], p2:
+See N2423
+for the proposed resolution.
 
    
 
-
    class deque {
-   ...
-   void resize(size_type sz, const T& c);
-
    
 
+
+
+
+
    
+
    733. Comment on [rand.req.dist]/9
    
+
    Section: 26.4.1.5 [rand.req.dist] Status: New
+ Submitter: Stephan Tolksdorf Date: 2007-09-21
    
+
    View all issues with New status.
    
+
    Discussion:
    
 
    
-Change 23.2.2.2 [deque.capacity], p3:
+The requirement "P shall have a declaration of the form typedef X distribution_- 
+type" effectively makes the use of inheritance for implementing distributions very inconvenient, 
+because the child of a distribution class in general will not satisfy this requirement. In my opinion 
+the benefits of having a typedef in the parameter class pointing back to the distribution class are 
+not worth the hassle this requirement causes. [In my code base I never made use of the nested 
+typedef but on several occasions could have profited from being able to use simple inheritance for 
+the implementation of a distribution class.]
 
    
 
-
    void resize(size_type sz, const T& c);
-
    
-
-
    Proposed resolution:
    
 
    
-Change 23.2.3 [list], p2:
+Proposed resolution: I propose to drop this requirement.
 
    
 
-
    class list {
-   ...
-   void resize(size_type sz, const T& c);
-
    
 
+
    Proposed resolution:
    
 
    
-Change 23.2.3.2 [list.capacity], p3:
+See N2423
+for the proposed resolution.
 
    
 
-
    void resize(size_type sz, const T& c);
-
    
 
-
    Proposed resolution:
    
+
+
+
+
    
+
    734. Unnecessary restriction in [rand.dist.norm.chisq]
    
+
    Section: 26.4.8.4.3 [rand.dist.norm.chisq] Status: New
+ Submitter: Stephan Tolksdorf Date: 2007-09-21
    
+
    View all issues with New status.
    
+
    Discussion:
    
 
    
-Change 23.2.5 [vector], p2:
+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).
 
    
 
-
    class vector {
-   ...
-   void resize(size_type sz, const T& c);
-
    
+
    
+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).
+
    
 
 
    
-Change 23.2.5.2 [vector.capacity], p11:
+Possible resolution: For these reasons, I propose to change the type of the respective parameters 
+to double.
 
    
 
-
    void resize(size_type sz, const T& c);
-
    
 
+
    Proposed resolution:
    
+
    
+See N2423
+for the proposed resolution.
+
    
 
 
 
 
 
 
    
-
    680. move_iterator operator-> return
    
-
    Section: 24.4.3.1 [move.iterator] Status: New
- Submitter: Howard Hinnant Date: 2007-06-11
    
+
    735. Unfortunate naming
    
+
    Section: 26.4.8.2.2 [rand.dist.bern.bin], 26.4.8.2.4 [rand.dist.bern.negbin] Status: New
+ Submitter: Stephan Tolksdorf Date: 2007-09-21
    
 
    View all issues with New 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 my opinion the choice of name for the t parameter of the binomial_distribution
+is very unfortunate. In virtually every internet reference, book and software implementation 
+this parameter is called n instead, see for example Wikipedia, Mathworld, Evans et al. (1993) 
+Statistical Distributions, 2nd E., Wiley, p. 38, the R statistical computing language, p. 926, 
+Mathematica and Matlab.
 
    
 
-
    template <class Iterator>
-class move_iterator {
-public:
-    ...
-    typedef typename iterator_traits<Iterator>::pointer pointer;
-    ...
-    pointer operator->() const {return current;}
-    ...
-private: 
-    Iterator current; // exposition only
-};
-
    
+
    
+Similarly, the choice of k for the parameter of the negative binomial distributions is rather unusual. 
+The most common choice for the negative binomial distribution seems to be r instead.
+
    
 
+
    
+Choosing unusual names for the parameters causes confusion among users and makes the 
+interface unnecessarily inconvenient to use.
+
    
 
 
    
-There are two possible fixes.
+Possible resolution: For these reasons, I propose to change the name of the respective parameters
+to n and r.
 
    
 
-
      
-
    1. pointer operator->() const {return &*current;}
      2. 
-
    2. typedef Iterator pointer;
      3. 
-
    
 
+
    Proposed resolution:
    
 
    
-The first solution is the one chosen by reverse_iterator.  A potential
-disadvantage of this is it may not work well with iterators which return a
-proxy on dereference and that proxy has overloaded operator&().  Proxy
-references often need to overloaad operator&() to return a proxy
-pointer.  That proxy pointer may or may not be the same type as the iterator's
-pointer type.
+See N2423
+for the proposed resolution.
 
    
 
+
+
+
+
+
    
+
    736. Comment on [rand.dist.samp.discrete]
    
+
    Section: 26.4.8.5.1 [rand.dist.samp.discrete] Status: New
+ Submitter: Stephan Tolksdorf Date: 2007-09-21
    
+
    View all issues with New status.
    
+
    Discussion:
    
+
      
+
    1. 
+The specification for discrete_distribution requires the member probabilities()
+to return a vector of standardized probabilities, which forces the implementation every time to 
+divide each probability by the sum of all probabilities, as the sum will in practice almost never be 
+exactly 1.0. This is unnecessarily inef ficient as the implementation would otherwise not need to 
+compute the standardized probabilities at all and could instead work with the non-standardized 
+probabilities and the sum. If there was no standardization the user would just get back the 
+probabilities that were previously supplied to the distribution object, which to me seems to be the 
+more obvious solution.
+
      2. 
+
    2. 
+The behaviour of discrete_distribution is not specified in case the number of given
+probabilities is larger than the maximum number representable by the IntType.
+
      3. 
+
    
+
 
    
-By simply returning the Iterator and taking advantage of the fact that
-the language forwards calls to operator-> automatically until it
-finds a non-class type, the second solution avoids the issue of an overloaded
-operator&() entirely.
+Possible resolution: I propose to change the specification such that the non-standardized 
+probabilities need to be returned and that an additional requirement is included for the number 
+of probabilities to be smaller than the maximum of IntType.
 
    
 
+
 
    Proposed resolution:
    
 
    
-Change the synopsis in 24.4.3.1 [move.iterator]:
+See N2423
+for the proposed resolution.
 
    
 
-
    typedef typename iterator_traits<Iterator>::pointer pointer;
-
    
-
-
 
 
 
 
 
    
-
    681. Operator functions impossible to compare are defined in [re.submatch.op]
    
-
    Section: 28.9.2 [re.submatch.op] Status: New
- Submitter: Nozomu Katoo Date: 2007-05-27
    
+
    737. Comment on [rand.dist.samp.pconst]
    
+
    Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: New
+ Submitter: Stephan Tolksdorf Date: 2007-09-21
    
 
    View all issues with New status.
    
 
    Discussion:
    
+
      
+
    1. 
+The discussion in point T11 above regarding probabilities() similarly applies 
+to the method densities() of piecewise_constant_distribution.
+
      2. 
+
    2. 
 
      
-In 28.9.2 [re.submatch.op] of N2284, 
-operator functions numbered 31-42 seem impossible to compare.  E.g.: 
+The design of the constructor
 
      
-
-
      
-
      template <class BiIter>
-    bool operator==(typename iterator_traits<BiIter>::value_type const& lhs,
-                    const sub_match<BiIter>& rhs);
-
      
-
      
+
      template <class InputIteratorB, class InputIteratorW> 
+piecewise_constant_distribution( InputIteratorB firstB, InputIteratorB lastB, 
+                                 InputIteratorW firstW);
+
      
 
      
--31- Returns: lhs == rhs.str().
+is unnecessarily unsafe, as there is no separate end-iterator given for the weights. I can't see 
+any performance or convenience reasons that would justify the risks inherent in such a function 
+interface, in particular the risk that input error might go unnoticed.
 
      
-
      
-
      
+
      3. 
+
    
 
 
    
-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. 
+Possible resolution: I propose to add an InputIteratorW lastW argument to the interface.
 
    
 
 
 
    Proposed resolution:
    
 
    
+See N2423
+for the proposed resolution.
 
    
 
 
@@ -12472,52 +13781,52 @@ these two types is not defined in 21.3.8 [string.nonmembers] of N2284.
 
 
 
    
-
    682. basic_regex ctor takes InputIterator or ForwardIterator?
    
-
    Section: 28.8.2 [re.regex.construct] Status: New
- Submitter: Eric Niebler Date: 2007-06-03
    
+
    738. Editorial issue in [rand.adapt.disc]/3
    
+
    Section: 26.4.4.1 [rand.adapt.disc] Status: New
+ Submitter: Stephan Tolksdorf Date: 2007-09-21
    
 
    View all issues with New status.
    
 
    Discussion:
    
 
    
-Looking at N2284, 28.8 [re.regex], p3 basic_regex class template synopsis shows this 
-constructor: 
+Since the template parameter p and r are of type size_t, the member n in the class 
+exposition should have type size_t, too.
 
    
-
    template <class InputIterator>
-     basic_regex(InputIterator first, InputIterator last, 
-                 flag_type f = regex_constants::ECMAScript);
-
    
 
+
+
    Proposed resolution:
    
 
    
-In 28.8.2 [re.regex.construct], p15, the constructor appears with this signature: 
+See N2423
+for the proposed resolution.
 
    
 
-
    template <class ForwardIterator>
-     basic_regex(ForwardIterator first, ForwardIterator last, 
-                 flag_type f = regex_constants::ECMAScript);
-
    
 
-
    
-ForwardIterator is probably correct, so the synopsis is wrong.
-
    
 
-
    [
-John adds:
-]
    
 
 
-
    
+
    
+
    739. Defect in [rand.util.canonical]/3
    
+
    Section: 26.4.7.2 [rand.util.canonical] Status: New
+ Submitter: Stephan Tolksdorf Date: 2007-09-21
    
+
    View all other issues in [rand.util.canonical].
    
+
    View all issues with New status.
    
+
    Discussion:
    
 
    
-I think either could be implemented?  Although an input iterator would 
-probably require an internal copy of the string being made.
+The complexity of generate_canonical is specified to be "exactly k=max(1, ceil(b/log2 
+R)) invocations of g". This terms involves a logarithm that is not rounded and hence can not (in 
+general) be computed at compile time. As this function template is performance critical, I propose 
+to replace ceil(b/log2 R) with ceil(b/floor(log2 R)).
 
    
+
 
    
-I have no strong feelings either way, although I think my original intent 
-was InputIterator. 
+See N2423
+for further discussion.
 
    
-
    
+
 
 
 
    Proposed resolution:
    
 
    
+See N2423
+for the proposed resolution.
 
    
 
 
@@ -12525,92 +13834,164 @@ was InputIterator.
 
 
 
    
-
    684. Unclear which members of match_results should be used in comparison
    
-
    Section: 28.10 [re.results] Status: New
- Submitter: Nozomu Katoo Date: 2007-05-27
    
-
    View other active issues in [re.results].
    
-
    View all other issues in [re.results].
    
+
    740. Please remove *_ptr<T[N]>
    
+
    Section: 20.6.5.4 [unique.ptr.compiletime] Status: New
+ Submitter: Herb Sutter Date: 2007-10-04
    
 
    View all issues with New status.
    
 
    Discussion:
    
 
    
-In 28.4 [re.syn] of N2284, two template functions 
-are declared here: 
+Please don't provide *_ptr<T[N]>. It doesn't enable any useful
+bounds-checking (e.g., you could imagine that doing op++ on a
+shared_ptr<T[N]> yields a shared_ptr<T[N-1]>, but that promising path
+immediately falters on op-- which can't reliably dereference because we
+don't know the lower bound). Also, most buffers you'd want to point to
+don't have a compile-time known size.
 
    
-
    // 28.10, class template match_results: 
-  <snip>
-// match_results comparisons 
-  template <class BidirectionalIterator, class Allocator> 
-    bool operator== (const match_results<BidirectionalIterator, Allocator>& m1, 
-                     const match_results<BidirectionalIterator, Allocator>& m2); 
-  template <class BidirectionalIterator, class Allocator> 
-    bool operator!= (const match_results<BidirectionalIterator, Allocator>& m1, 
-                     const match_results<BidirectionalIterator, Allocator>& m2); 
 
-// 28.10.6, match_results swap:
-
    
+
    
+To enable any bounds-checking would require run-time information, with
+the usual triplet: base (lower bound), current offset, and max offset
+(upper  bound). And I can sympathize with the point of view that you
+wouldn't want to require this on *_ptr itself. But please let's not
+follow the <T[N]> path, especially not with additional functions to
+query the bounds etc., because this sets wrong user expectations by
+embarking on a path that doesn't go all the way to bounds checking as it
+seems to imply.
+
    
 
 
    
-But the details of these two bool operator functions (i.e., which members of
-match_results should be used in comparison) are not described in any
-following sections.
+If bounds checking is desired, consider a checked_*_ptr instead (e.g.,
+checked_shared_ptr). And make the interfaces otherwise identical so that
+user code could easily #define/typedef between prepending checked_ on
+debug builds and not doing so on release builds (for example).
 
    
 
-
    [
-John adds:
-]
    
+
    
+Note that some may object that checked_*_ptr may seem to make the smart
+pointer more like vector, and we don't want two ways to spell vector. I
+don't agree, but if that were true that would be another reason to
+remove *_ptr<T[N]> which equally makes the smart pointer more like
+std::array. :-)
+
    
 
 
-
    
-That looks like a bug: operator== should return true only if
-the two objects refer to the same match - ie if one object was constructed as a
-copy of the other.
-
    
+
    Proposed resolution:
    
+
    
+Change the synopsis under 20.6.5 [unique.ptr] p2:
+
    
 
+
    ...
+template<class T> struct default_delete; 
+template<class T> struct default_delete<T[]>; 
+template<class T, size_t N> struct default_delete<T[N]>;
+
+template<class T, class D = default_delete<T>> class unique_ptr; 
+template<class T, class D> class unique_ptr<T[], D>; 
+template<class T, class D, size_t N> class unique_ptr<T[N], D>;
+...
+
    
+
+
    
+Remove the entire section 20.6.5.1.3 [unique.ptr.dltr.dflt2] default_delete<T[N]>.
+
    
 
-
    Proposed resolution:
    
 
    
+Remove the entire section 20.6.5.4 [unique.ptr.compiletime] unique_ptr for array objects with a compile time length
+and its subsections: 20.6.5.4.1 [unique.ptr.compiletime.dtor], 20.6.5.4.2 [unique.ptr.compiletime.observers],
+20.6.5.4.3 [unique.ptr.compiletime.modifiers].
 
    
 
 
 
 
 
+
 
    
-
    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: New
- Submitter: Bo Persson Date: 2007-06-10
    
+
    741. Const-incorrect get_deleter function for shared_ptr
    
+
    Section: 20.6.6.2.11 [util.smartptr.getdeleter] Status: New
+ Submitter: Daniel Krügler Date: 2007-09-27
    
+
    View all other issues in [util.smartptr.getdeleter].
    
 
    View all issues with New status.
    
 
    Discussion:
    
 
    
-In C++03 the difference between two reverse_iterators
+The following issue was raised by Alf P. Steinbach in c.l.c++.mod:
 
    
-
    ri1 - ri2
+
+
    
+According to the recent draft N2369, both the header memory synopsis
+of 20.6 [memory] and 20.6.6.2.11 [util.smartptr.getdeleter] declare:
+
    
+
+
    template<class D, class T> D* get_deleter(shared_ptr<T> const& p);
 
    
+
 
    
-is possible to compute only if both iterators have the same base 
-iterator. The result type is the difference_type of the base iterator. 
+This allows to retrieve the pointer to a mutable deleter of a const
+shared_ptr (if that owns one) and therefore contradicts the usual
+philosophy that associated functors are either read-only (e.g.
+key_comp or value_comp of std::map) or do at least reflect
+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.5.15.2 [func.wrap.func] or in 20.5.15.2.5 [func.wrap.func.targ] - do
+properly mirror the const-state of the owner.
 
    
+
+Possible proposed resolutions:
+
 
    
-In the current draft, the operator is defined as 24.4.1.3.19 [reverse.iter.opdiff] 
+Replace the declarations of get_deleter in the header <memory>
+synopsis of 20.6 [memory] and in 20.6.6.2.11 [util.smartptr.getdeleter] by one of the
+following alternatives (A) or (B):
 
    
-
    template<class Iterator1, class Iterator2> 
-typename reverse_iterator<Iterator>::difference_type 
-   operator-(const reverse_iterator<Iterator1>& x, 
-                    const reverse_iterator<Iterator2>& y);
+
+
      
+
    1. 
+Provide only the immutable variant. This would reflect the
+current praxis of container::get_allocator(), map::key_comp(), or
+map::value_comp.
+
+
      template<class D, class T> const D* get_deleter(shared_ptr<T> const& p);
 
      
+
      2. 
+
    2. 
+Just remove the function.
+
      3. 
+
    
+
 
    
-The return type is the same as the C++03 one, based on the no longer 
-present Iterator template parameter. 
+Alberto Ganesh Barbati adds:
+
    
+
+
      
+
    1. 
+
      
+Replace it with two functions:
 
      
+
      template <class D, class T> D get_deleter(shared_ptr<T> const&);
+template <class D, class T> bool has_deleter(shared_ptr<T> const&);
+
      
+
 
      
-Besides being slightly invalid, should this operator work only when 
-Iterator1 and Iterator2 has the same difference_type? Or should the 
-implementation choose one of them? Which one? 
+The first one would throw if D is the wrong type, while the latter would
+never throw. This approach would reflect the current praxis of
+use_facet/has_facet, with the twist of returning the deleter by value as
+container::get_allocator() do.
+
      
+
      2. 
+
    
+
+
    
+Peter Dimov adds:
 
    
+
+
    
 
    
-The same problem now also appears in operator-() for move_iterator
-24.4.3.3.14 [move.iter.nonmember]. 
+My favorite option is "not a defect". A, B and C break useful code.
 
    
+
    
+
 
 
 
    Proposed resolution:
    
@@ -12622,98 +14003,126 @@ The same problem now also appears in operator-() for move_iterator<
 
 
 
    
-
    686. Unique_ptr and shared_ptr fail to specify non-convertibility to int for unspecified-bool-type
    
-
    Section: 20.6.5.2.4 [unique.ptr.single.observers], 20.6.6.2.5 [util.smartptr.shared.obs] Status: New
- Submitter: Beman Dawes Date: 2007-06-14
    
+
    742. Enabling swap for proxy iterators
    
+
    Section: 20.1.1 [utility.arg.requirements] Status: New
+ 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 New status.
    
 
    Discussion:
    
 
    
-The standard library uses the operator unspecified-bool-type() const idiom in
-five places. In three of those places (20.5.14.2.3 [func.wrap.func.cap], function capacity 
-for example) the returned value is constrained to disallow
-unintended conversions to int. The standardese is
-
    
-
    
-The return type shall not be convertible to int.
-
    
-
    
-This constraint is omitted for unique_ptr and shared_ptr. It should be added for those.
+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.
 
    
 
-
-
    Proposed resolution:
    
 
    
-To the Returns paragraph for operator unspecified-bool-type()
-const
-of 20.6.5.2.4 [unique.ptr.single.observers] paragraph 11 and 20.6.6.2.5
-[util.smartptr.shared.obs] paragraph 16, add the sentence:
+This issue seeks to widen the Swappable requirement to support proxy iterators.  Here
+is example code:
 
    
-
    
-The return type shall not be convertible to int.
-
    
 
+
    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>);
 
-
    
-
    687. shared_ptr conversion constructor not constrained
    
-
    Section: 20.6.6.2.1 [util.smartptr.shared.const], 20.6.6.3.1 [util.smartptr.weak.const] Status: New
- Submitter: Peter Dimov Date: 2007-05-10
    
-
    View all issues with New status.
    
-
    Discussion:
    
-
    
-Since all conversions from shared_ptr<T> to shared_ptr<U> have the same
-rank regardless of the relationship between T and U, reasonable user
-code that works with raw pointers fails with shared_ptr:
-
    
+}  // Mine
 
-
    void f( shared_ptr<void> );
-void f( shared_ptr<int> );
+...
 
-int main()
-{
-  f( shared_ptr<double>() ); // ambiguous
-}
+Mine::proxied_iterator<Mine::A> i(...)
+Mine::A a;
+swap(*i1, a);
 
    
 
 
    
-Now that we officially have enable_if, we can constrain the constructor
-and the corresponding assignment operator to only participate in the
-overload resolution when the pointer types are compatible.
+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.
 
    
 
 
+
 
    Proposed resolution:
    
 
    
-In 20.6.6.2.1 [util.smartptr.shared.const], change:
+Change 20.1.1 [utility.arg.requirements]:
 
    
 
-
    
--14- Requires: For the second constructor The
-second constructor shall not participate in the overload resolution
-unless Y* shall be is convertible
-to T*.
-
    
+
    
 
 
    
-In 20.6.6.3.1 [util.smartptr.weak.const], change:
+-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.
 
    
 
-
    
-
    template<class Y> weak_ptr(shared_ptr<Y> const& r);
-weak_ptr(weak_ptr const& r);
-template<class Y> weak_ptr(weak_ptr<Y> const& r);
-weak_ptr(weak_ptr const& r);
-template<class Y> weak_ptr(weak_ptr<Y> const& r);
-template<class Y> weak_ptr(shared_ptr<Y> const& r);
-
    
-
    
--4- Requires: For tThe second and
-third constructors, shall not participate in the
-overload resolution unless Y* shall be
-is convertible to T*.
-
    
+
+
+
+
+
+
+
    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.
+
      • 
+
    
+
    
 
    
 
 
@@ -12722,105 +14131,86 @@ overload resolution unless Y* shall be
 
 
 
    
-
    688. reference_wrapper, cref unsafe, allow binding to rvalues
    
-
    Section: 20.5.5.1 [refwrap.const] Status: New
- Submitter: Peter Dimov Date: 2007-05-10
    
-
    View other active issues in [refwrap.const].
    
-
    View all other issues in [refwrap.const].
    
+
    743. rvalue swap for shared_ptr
    
+
    Section: 20.6.6.2.9 [util.smartptr.shared.spec] Status: New
+ Submitter: Howard Hinnant Date: 2007-10-10
    
 
    View all issues with New status.
    
 
    Discussion:
    
 
    
-A reference_wrapper can be constructed from an rvalue, either by using
-the constructor, or via cref (and ref in some corner cases). This leads
-to a dangling reference being stored into the reference_wrapper object.
-Now that we have a mechanism to detect an rvalue, we can fix them to
-disallow this source of undefined behavior.
+When the LWG looked at 674 in Kona the following note was made:
 
    
 
+
    
+We may need to open an issue to deal with the question of
+whether shared_ptr needs an rvalue swap.
+
    
 
-
    Proposed resolution:
    
 
    
-In 20.5.5 [refwrap], add:
+This issue was opened in response to that note.
 
    
 
-
    private:
-  explicit reference_wrapper(T&&);
-
    
-
 
    
-In 20.5.5.1 [refwrap.const], add:
+I believe allowing rvalue shared_ptrs to swap is both
+appropriate, and consistent with how other library components are currently specified.
 
    
 
-
    
-
    explicit reference_wrapper(T&&);
-
    
-
    
--?- Not defined to disallow creating a reference_wrapper from an rvalue.
-
    
-
    
 
+
+
    Proposed resolution:
    
 
    
-In the synopsis of <functional> (20.5.5 [refwrap]), change the declarations
-of ref and cref to:
+Change the synopsis in 20.6.6.2 [util.smartptr.shared]:
 
    
 
-
    template<class T> reference_wrapper<T> ref(T&&);
-template<class T> reference_wrapper<const T> cref(const T&&);
+
    void swap(shared_ptr&& r);
+...
+template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b);
+template<class T> void swap(shared_ptr<T>&& a, shared_ptr<T>& b);
+template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>&& b);
 
    
 
 
    
-In 20.5.5.5 [refwrap.helpers], change:
-
    
-
-
    
-
    template<class T> reference_wrapper<T> ref(T&& t);
-
    
-
    
-
    
--1- Requires: t shall be an lvalue.
+Change 20.6.6.2.4 [util.smartptr.shared.mod]:
 
    
-
    
-
    
 
-
    and change:
    
+
    void swap(shared_ptr&& r);
+
    
 
-
    
-
    template<class T> reference_wrapper<const T> cref(const T&& t);
-
    
-
    
 
    
--6- Requires: t shall be an lvalue.
+Change 20.6.6.2.9 [util.smartptr.shared.spec]:
 
    
-
    
-
    
 
+
    template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b);
+template<class T> void swap(shared_ptr<T>&& a, shared_ptr<T>& b);
+template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>&& b);
+
    
 
 
 
 
 
 
    
-
    689. reference_wrapper constructor overly constrained
    
-
    Section: 20.5.5.1 [refwrap.const] Status: New
- Submitter: Peter Dimov Date: 2007-05-10
    
-
    View other active issues in [refwrap.const].
    
-
    View all other issues in [refwrap.const].
    
+
    744. What is the lifetime of an exception pointed to by an exception_ptr?
    
+
    Section: 18.7.5 [propagation] Status: New
+ Submitter: Alisdair Meredith Date: 2007-10-10
    
+
    View other active issues in [propagation].
    
+
    View all other issues in [propagation].
    
 
    View all issues with New status.
    
 
    Discussion:
    
 
    
-The constructor of reference_wrapper is currently explicit. The primary
-motivation behind this is the safety problem with respect to rvalues,
-which is addressed by the proposed resolution of the previous issue.
-Therefore we should consider relaxing the requirements on the
-constructor since requests for the implicit conversion keep resurfacing.
+Without some lifetime guarantee, it is hard to know how this type can be
+used.  Very specifically, I don't see how the current wording would
+guarantee and exception_ptr caught at the end of one thread could be safely
+stored and rethrown in another thread - the original motivation for this
+API.
+
    
+
    
+(Peter Dimov agreed it should be clearer, maybe a non-normative note to
+explain?)
 
    
 
 
 
    Proposed resolution:
    
 
    
-Remove the explicit from the constructor of reference_wrapper. If the
-proposed resolution of the previous issue is accepted, remove the
-explicit from the T&& constructor as well to keep them in sync.
 
    
 
 
@@ -12828,66 +14218,61 @@ proposed resolution of the previous issue is accepted, remove the
 
 
 
    
-
    690. abs(long long) should return long long
    
-
    Section: 26.7 [c.math] Status: New
- Submitter: Niels Dekker Date: 2007-06-10
    
-
    View other active issues in [c.math].
    
-
    View all other issues in [c.math].
    
+
    745. copy_exception API slices.
    
+
    Section: 18.7.5 [propagation] Status: New
+ Submitter: Alisdair Meredith Date: 2007-10-10
    
+
    View other active issues in [propagation].
    
+
    View all other issues in [propagation].
    
 
    View all issues with New status.
    
 
    Discussion:
    
 
    
-Quoting the latest draft (n2135), 26.7 [c.math]: 
+It could be I did not understand the design rationale, but I thought
+copy_exception would produce an exception_ptr to the most-derived (dynamic)
+type of the passed exception.  Instead it slices, which appears to be less
+useful, and a likely source of FAQ questions in the future.
 
    
-
-
    
-
    
-The added signatures are:
-
    
-
    long abs(long); // labs()
-long abs(long long); // llabs()
-
    
-
    
 
    
-Shouldn't abs(long long) have long long as return type?
+(Peter Dimov suggests NAD)
 
    
 
 
 
    Proposed resolution:
    
 
    
-Change 26.7 [c.math]: 
 
    
-
    long long abs(long long); // llabs()
-
    
 
 
 
 
 
 
    
-
    691. const_local_iterator cbegin, cend missing from TR1
    
-
    Section: 23.4 [unord] Status: New
- Submitter: Joaquín M López Muñoz Date: 2007-06-14
    
-
    View other active issues in [unord].
    
-
    View all other issues in [unord].
    
+
    746. current_exception may fail with bad_alloc
    
+
    Section: 18.7.5 [propagation] Status: New
+ Submitter: Alisdair Meredith Date: 2007-10-10
    
+
    View other active issues in [propagation].
    
+
    View all other issues in [propagation].
    
 
    View all issues with New status.
    
 
    Discussion:
    
 
    
-The last version of TR1 does not include the following member
-functions
-for unordered containers:
+I understand that the attempt to copy an exception may run out of memory,
+but I believe this is the only part of the standard that mandates failure
+with specifically bad_alloc, as opposed to allowing an
+implementation-defined type derived from bad_alloc.  For instance, the Core
+language for a failed new expression is:
 
    
-
-
    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.
+Any other allocation function that fails to allocate storage shall indicate
+failure only by throwing an exception of a type that would match a handler
+(15.3) of type std::bad_alloc (18.5.2.1).
+
    
+
    
+
    
+I think we should allow similar freedom here (or add a blanket
+compatible-exception freedom paragraph in 17)
 
    
 
    
-Is this really an oversight, or am I missing something?
+I prefer the clause 17 approach myself, and maybe clean up any outstanding
+wording that could also rely on it.
 
    
 
 
@@ -12900,243 +14285,223 @@ Is this really an oversight, or am I missing something?
 
 
 
    
-
    692. get_money and put_money should be formatted I/O functions
    
-
    Section: 27.6.4 [ext.manip] Status: New
- Submitter: Martin Sebor Date: 2007-06-22
    
-
    View all other issues in [ext.manip].
    
+
    747. We have 3 separate type traits to identify classes supporting no-throw operations
    
+
    Section: 20.4.4.3 [meta.unary.prop] Status: New
+ Submitter: Alisdair Meredith Date: 2007-10-10
    
+
    View other active issues in [meta.unary.prop].
    
+
    View all other issues in [meta.unary.prop].
    
 
    View all issues with New status.
    
 
    Discussion:
    
 
    
-In a private email Bill Plauger notes:
+We have 3 separate type traits to identify classes supporting no-throw
+operations, which are very useful when trying to provide exception safety
+guarantees.  However, I'm not entirely clear on what the current wording
+requires of a conforming implementation.  To quote from
+has_nothrow_default_constructor:
 
    
 
    
-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.
+or T is a class type with a default constructor that is known not to throw
+any exceptions
+
    
+
    
+What level of magic do we expect to deduce if this is known?
 
    
 
    
-The words  don't say that  right now and  I'm far from  convinced that
-such a change is editorial.
-
    
+E.g.
+
    
+
+
    struct test{
+ int x;
+ test() : x() {}
+};
+
    
 
    
-Martin's response:
+Should I expect a conforming compiler to 
+ assert( has_nothrow_constructor<test>::value )
 
    
-
    
-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.
+
    
+Is this a QoI issue?
 
    
 
    
-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.
-
    
+Should I expect to 'know' only if-and-only-if there is an inline definition
+available?
+
    
+
    
+Should I never expect that to be true, and insist that the user supplies an
+empty throw spec if they want to assert the no-throw guarantee?
+
    
+
    
+It would be helpful to maybe have a footnote explaining what is required,
+but right now I don't know what to suggest putting in the footnote.
+
    
+
    
+(agreement since is that trivial ops and explicit no-throws are required.
+Open if QoI should be allowed to detect further)
+
    
 
 
 
    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...
-
    
 
 
 
 
 
 
    
-
    693. std::bitset::all() missing
    
-
    Section: 23.3.5 [template.bitset] Status: New
- Submitter: Martin Sebor Date: 2007-06-22
    
-
    View other active issues in [template.bitset].
    
-
    View all other issues in [template.bitset].
    
+
    748. The is_abstract type trait is defined by reference to 10.4.
    
+
    Section: 20.4.4.3 [meta.unary.prop] Status: New
+ Submitter: Alisdair Meredith Date: 2007-10-10
    
+
    View other active issues in [meta.unary.prop].
    
+
    View all other issues in [meta.unary.prop].
    
 
    View all issues with New status.
    
 
    Discussion:
    
 
    
-The  bitset class template  provides the  member function
-any() to determine whether an  object of the type has any
-bits  set, and  the member  function none()  to determine
-whether all of an object's  bits are clear. However, the template does
-not   provide  a   corresponding  function   to  discover   whether  a
-bitset  object  has  all  its  bits  set.   While  it  is
-possible,  even easy,  to  obtain this  information  by comparing  the
-result of count()  with the result of size()
-for  equality  (i.e.,  via  b.count()  ==  b.size())  the
-operation  is   less  efficient   than  a  member   function  designed
-specifically  for that purpose  could be.   (count() must
-count  all non-zero bits  in a  bitset a  word at  a time
-while all() could stop counting as soon as it encountered
-the first word with a zero bit).
+I am trying to decide is a pure virtual function is a necessary as well as
+sufficient requirement to be classified as abstract?
+
    
+
    
+For instance, is the following (non-polymorphic) type considered abstract?
+
    
+
    struct abstract {
+protected:
+ abstract(){}
+ abstract( abstract const & ) {}
+ ~abstract() {}
+};
+
    
+
    
+(Suggested that this may be NAD, with an editorial fix-up from Pete on the
+core wording to make clear that abstract requires a pure virtual function)
 
    
 
 
 
    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,
-right above the declaration of any() as shown below:
 
    
 
-
    bool operator!=(const bitset<N>& rhs) const;
-bool test(size_t pos) const;
-bool all() const;
-bool any() const;
-bool none() const;
-
    
 
+
+
+
+
    
+
    749. Currently has_nothrow_copy_constructor<T>::value is true if T has 'a' nothrow copy constructor.
    
+
    Section: 20.4.4.3 [meta.unary.prop] Status: New
+ Submitter: Alisdair Meredith Date: 2007-10-10
    
+
    View other active issues in [meta.unary.prop].
    
+
    View all other issues in [meta.unary.prop].
    
+
    View all issues with New status.
    
+
    Discussion:
    
 
    
-Add a description of the new member function to the end of 23.3.5.2 [bitset.members] with the following text:
+Unfortunately a class can have multiple copy constructors, and I believe to
+be useful this trait should only return true is ALL copy constructors are
+no-throw.
 
    
-
    
-bool all() const;
+
    
+For instance:
 
    
 
    
-Returns: count() == b.size().
-
    
+
    struct awkward {
+ awkward( const awkward & ) throw() {}
+ awkward( awkward & ) { throw "oops"; } };
+
    
 
    
 
+
+
    Proposed resolution:
    
 
    
-In  addition,   change  the  description   of  any()  and
-none()   for  consistency   with   all()  as
-follows:
-
    
-
    
-bool any() const;
-
    
-
    
-
    
-Returns: true if any bit in *this
-is onecount() != 0.
 
    
-
    
+
+
+
+
+
+
    
+
    750. The current definition for is_convertible requires that the type be
+implicitly convertible, so explicit constructors are ignored.
    
+
    Section: 20.4.5 [meta.rel] Status: New
+ Submitter: Alisdair Meredith Date: 2007-10-10
    
+
    View all issues with New status.
    
+
    Discussion:
    
 
    
-bool none() const;
+With the pending arrival of explicit conversion functions though, I'm
+wondering if we want an additional trait, is_explictly_convertible?
 
    
-
    
+
+
+
    Proposed resolution:
    
 
    
-Returns: true if no bit in *this
-is onecount() == 0.
 
    
-
    
-
    
 
 
 
 
 
 
    
-
    694. std::bitset and long long
    
-
    Section: 23.3.5 [template.bitset] Status: New
- Submitter: Martin Sebor Date: 2007-06-22
    
-
    View other active issues in [template.bitset].
    
-
    View all other issues in [template.bitset].
    
+
    751. change pass-by-reference members of vector<bool> to pass-by-value?
    
+
    Section: 23.2.6 [vector.bool] Status: New
+ Submitter: Alisdair Meredith Date: 2007-10-10
    
 
    View all issues with New status.
    
 
    Discussion:
    
 
    
-Objects of the  bitset class template specializations can
-be constructed from  and explicitly converted to values  of the widest
-C++ integer  type, unsigned long.   With the introduction
-of  long long into  the language  the template  should be
-enhanced to make it possible  to interoperate with values of this type
-as well, or  perhaps uintmax_t.  See c++std-lib-18274 for
-a brief discussion in support of this change.
+A number of vector<bool> members take const bool& as arguments.
+Is there any chance we could change them to pass-by-value or would I 
+be wasting everyone's time if wrote up an issue?
 
    
 
 
 
    Proposed resolution:
    
 
    
-For simplicity,  instead of  adding overloads for  unsigned long
-long and dealing with possible ambiguities in the spec, replace
-the bitset ctor  that takes an unsigned long
-argument  with  one  taking  unsigned long  long  in  the
-definition  of the  template as  shown below.   (The  standard permits
-implementations  to add  overloads on  other integer  types  or employ
-template tricks to  achieve the same effect provided  they don't cause
-ambiguities or changes in behavior.)
 
    
-
    
-
    // [bitset.cons] constructors:
-bitset();
-bitset(unsigned long long val);
-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);
-
    
-
    
+
+
+
+
+
+
    
+
    752. Allocator complexity requirement
    
+
    Section: 20.1.2 [allocator.requirements] Status: New
+ 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 New status.
    
+
    Discussion:
    
 
    
-Make a corresponding change in 23.3.5.1 [bitset.cons], p2:
+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."?
 
    
-
    
 
    
-bitset(unsigned long long val);
+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?
 
    
-
    
-Effects:  Constructs   an  object  of   class  bitset<N>,
-initializing  the  first M  bit  positions to  the
-corresponding      bit     values      in     val.
-M is the  smaller of N and the
-number of bits in  the value representation (section [basic.types]) of
-unsigned   long long.   If  M <
-N  is  true,  the remaining  bit
-positions are initialized to zero.
-
    
-
    
-
 
    
-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:
+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.
 
    
-
    
-
    // element access:
-bool operator[](size_t pos) const; // for b[i];
-reference operator[](size_t pos); // for b[i];
-unsigned long to_ulong() const;
-unsigned long long to_ullong() const;
-template <class charT, class traits, class Allocator>
-basic_string<charT, traits, Allocator> to_string() const;
-
    
-
    
+
+
+
    Proposed resolution:
    
 
    
-And add a description of  the new member function to 23.3.5.2 [bitset.members],
-below  the  description of  the  existing to_ulong()  (if
-possible), with the following text:
+Change 20.1.2 [allocator.requirements]/2:
 
    
+
 
    
 
    
-unsigned long long to_ullong() const;
+-2- Table 39 describes the requirements on types manipulated through
+allocators. All the operations on the allocators are expected to be
+amortized constant time, except that allocate and
+construct may require time proportional to the size of the
+object allocated or constructed. Table 40 describes the
+requirements on allocator types.
 
    
-
    
-Throws:  overflow_error   if  the  integral  value
-x corresponding to  the bits in *this
-cannot be represented as type unsigned long long.
-
    
-
    
-Returns: x.
-
    
 
    
 
 
@@ -13144,110 +14509,185 @@ cannot be represented as type unsigned long long.
 
 
 
    
-
    695. ctype<char>::classic_table() not accessible
    
-
    Section: 22.2.1.3 [facet.ctype.special] Status: New
- Submitter: Martin Sebor Date: 2007-06-22
    
+
    753. Move constructor in draft
    
+
    Section: 20.1.1 [utility.arg.requirements] Status: New
+ 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 New status.
    
 
    Discussion:
    
 
    
-The   ctype<char>::classic_table()   static  member
-function    returns    a    pointer    to   an    array    of    const
-ctype_base::mask    objects    (enums)   that    contains
-ctype<char>::table_size    elements.    The   table
-describes the properties of the character set in the "C" locale (i.e.,
-whether a  character at an index  given by its value  is alpha, digit,
-punct,   etc.),   and   is    typically   used   to   initialize   the
-ctype<char>  facet in the  classic "C"  locale (the
-protected      ctype<char>      member     function
-table()    then    returns     the    same    value    as
-classic_table()).
+The draft standard n2369 uses the term move constructor in a few
+places, but doesn't seem to define it.
 
    
+
 
    
-However, while ctype<char>::table_size (the size of
-the   table)    is   a   public    static   const   member    of   the
-ctype<char>           specialization,           the
-classic_table() static member function is protected. That
-makes getting at the classic  data less than convenient (i.e., one has
-to create  a whole derived class just  to get at the  masks array). It
-makes  little sense  to expose  the size  of the  table in  the public
-interface while making the table itself protected, especially when the
-table is a constant object.
+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]
    
+
    
+
 
    
-The  same argument  can be  made for  the non-static  protected member
-function table().
+(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.
+
    
 
-
    Proposed resolution:
    
 
    
-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:
+For vector::reserve, vector::resize and the vector modifiers given in
+23.2.5.4 [vector.modifiers] we have
 
    
-
    
-
      static locale::id id;
-  static const size_t table_size = IMPLEMENTATION_DEFINED;
-protected:
-  const mask* table() const throw();
-  static const mask* classic_table() throw();
-protected:
 
-~ctype(); // virtual
-virtual char do_toupper(char c) const;
-
    
+
    
+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:
    
+
    
+
    
+
 
 
 
 
 
    
-
    696. istream::operator>>(int&) broken
    
-
    Section: 27.6.1.2.2 [istream.formatted.arithmetic] Status: New
- Submitter: Martin Sebor Date: 2007-06-23
    
-
    View other active issues in [istream.formatted.arithmetic].
    
-
    View all other issues in [istream.formatted.arithmetic].
    
+
    754. Ambiguous return clause for std::uninitialized_copy
    
+
    Section: 20.6.4.1 [uninitialized.copy] Status: New
+ Submitter: Daniel Krügler Date: 2007-10-15
    
+
    View other active issues in [uninitialized.copy].
    
+
    View all other issues in [uninitialized.copy].
    
 
    View all issues with New status.
    
 
    Discussion:
    
 
    
-From message c++std-lib-17897:
+14882-2003, [lib.uninitialized.copy] is currently written as follows:
 
    
+
+
    
+
    template <class InputIterator, class ForwardIterator>
+  ForwardIterator uninitialized_copy(InputIterator first, InputIterator last,
+                                     ForwardIterator result);
+
    
+
    
 
    
-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
-conditions (in addition to containing a few typos).
+-1- Effects:
 
    
+
    for (; first != last; ++result, ++first)
+  new (static_cast<void*>(&*result))
+    typename iterator_traits<ForwardIterator>::value_type(*first);
+
    
 
    
-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).
+-2- Returns: result
 
    
+
    
+
    
+
 
    
-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.
+similarily for N2369, and its corresponding section
+20.6.4.1 [uninitialized.copy].
+
    
+
+
    
+It's not clear to me what the return clause is supposed to mean, I see
+two
+possible interpretations:
+
    
+
+
      
+
    1. 
+The notion of result is supposed to mean the value given by the
+function parameter result [Note to the issue editor: Please use italics for
+result].
+This seems somewhat implied by recognizing that both the function
+parameter
+and the name used in the clause do have the same italic font.
+
      2. 
+
    2. 
+The notion of "result" is supposed to mean the value of result
+after the
+preceding effects clause. This is in fact what all implementations I
+checked
+do (and which is probably it's intend, because it matches the
+specification of std::copy).
+
      3. 
+
    
+
+
    
+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]
+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
+synopsis or
+to the effects clause (or possibly other elements)? Fortunately most
+detailed
+descriptions are unambigious in this regard, e.g. this problem does
+not apply
+for std::copy.
 
    
 
 
+
 
    Proposed resolution:
    
 
    
+Change the wording of the return clause to say (20.6.4.1 [uninitialized.copy]):
+
    
+
+
    
+
    
+-2- Returns: The value of result after effects have taken place.
 
    
+
    
+
 
 
 
diff --git a/libstdc++-v3/docs/html/ext/lwg-closed.html b/libstdc++-v3/docs/html/ext/lwg-closed.html
index 4d0c76d702f..52184fb805e 100644
--- a/libstdc++-v3/docs/html/ext/lwg-closed.html
+++ b/libstdc++-v3/docs/html/ext/lwg-closed.html
@@ -1,22 +1,22 @@
 
 C++ Standard Library Closed Issues List
 
+
+
 
-
-
+ins {background-color:#A0FFA0}
+del {background-color:#FFA0A0}
+
 
-
+
-
+
@@ -27,7 +27,7 @@ del {background-color:#FFFFA0}
 
    
 
    
 Doc. no.N2319=07-0179N2458=07-0328
 
    
 
    
 Date:2007-06-242007-10-20
 
    
 
    
 Project:Howard Hinnant <howard.hinnant@gmail.com>
 
    
 
    
-
    C++ Standard Library Closed Issues List (Revision R49)
    
+
    C++ Standard Library Closed Issues List (Revision R52)
    
 
   
    Reference ISO/IEC IS 14882:1998(E)
    
   
    Also see:
    
@@ -49,6 +49,71 @@ del {background-color:#FFFFA0}
 
 
    Revision History
    
 
@@ -152,7 +217,7 @@ del {background-color:#FFFFA0}
 
  • 592 issues total, up by 5.
    • 
 
 
  • Details:
    • 
 
 
@@ -182,8 +247,8 @@ del {background-color:#FFFFA0}
 
  • Details:
    • 
@@ -198,7 +263,7 @@ del {background-color:#FFFFA0}
 
  • 566 issues total, up by 31.
    • 
 
 
  • Details:
      
-
    • Added new issues 536-566.
      • 
+
    • Added new issues 536-566.
      • 
 
    • Moved 342 from Ready to Open.
      • 
 
    • Reopened 309.
      • 
 
    • 
@@ -219,7 +284,7 @@ del {background-color:#FFFFA0}
 
 
  • R39: 
 2005-10-14 post-Mont Tremblant mailing.
-Added new issues 526-528.
+Added new issues 526-528.
 Moved issues 280, 461, 464, 465, 467, 468, 474, 496 from Ready to WP as per the vote from Mont Tremblant.
 Moved issues 247, 294, 342, 362, 369, 371, 376, 384, 475, 478, 495, 497 from Review to Ready.
 Moved issues 498, 504, 506, 509, 510, 511, 512, 513, 514 from New to Open.
@@ -245,7 +310,7 @@ previously in "DR" status were moved to "WP".
 2005-03 pre-Lillehammer mailing.
 
    • 
 
  • R34: 
-2005-01 mid-term mailing.  Added new issues 488-494.
+2005-01 mid-term mailing.  Added new issues 488-494.
 
    • 
 
  • R33: 
 2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
@@ -485,6 +550,7 @@ 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
    
+
    View other active issues in [basic.string].
    
 
    View all other issues in [basic.string].
    
 
    View all issues with NAD status.
    
 
    Discussion:
    
@@ -765,10 +831,10 @@ meaningless.
    
 
 
    
 
    77. Valarray operator[] const returning value
    
-
    Section: 26.5.2.3 [valarray.access] Status: NAD Future
+
    Section: 26.5.2.3 [valarray.access] Status: Dup
  Submitter: Levente Farkas Date: 1998-09-09
    
 
    View all other issues in [valarray.access].
    
-
    View all issues with NAD Future status.
    
+
    View all issues with Dup status.
    
 
    Duplicate of: 389
    
 
    Discussion:
    
 
    valarray:
    
@@ -1983,7 +2049,6 @@ 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
    
-
    View other active issues in [istream.unformatted].
    
 
    View all other issues in [istream.unformatted].
    
 
    View all issues with Dup status.
    
 
    Duplicate of: 60
    
@@ -4188,11 +4253,11 @@ operator< on any pair type which contains a pointer.
 
 
    
 
    350. allocator<>::address
    
-
    Section: 20.6.1.1 [allocator.members], 20.1.2 [allocator.requirements], 17.4.1.1 [contents] Status: NAD Future
+
    Section: 20.6.1.1 [allocator.members], 20.1.2 [allocator.requirements], 17.4.1.1 [contents] Status: Dup
  Submitter: Nathan Myers Date: 2001-10-25
    
 
    View all other issues in [allocator.members].
    
-
    View all issues with NAD Future status.
    
-
    Duplicate of: 634
    
+
    View all issues with Dup status.
    
+
    Duplicate of: 634
    
 
    Discussion:
    
 
    See c++std-lib-9006 and c++std-lib-9007.  This issue is taken
 verbatim from -9007.
    
@@ -4275,14 +4340,13 @@ exhibiting a problem.
    
 
    351. unary_negate and binary_negate: struct or class?
    
 
    Section: 20.5 [function.objects] Status: NAD Editorial
  Submitter: Dale Riley Date: 2001-11-12
    
-
    View other active issues in [function.objects].
    
 
    View all other issues in [function.objects].
    
 
    View all issues with NAD Editorial status.
    
 
    Discussion:
    
 
    
 In 20.5 [function.objects] the header <functional> synopsis declares
 the unary_negate and binary_negate function objects as struct.
-However in 20.5.9 [negators] the unary_negate and binary_negate
+However in 20.5.10 [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.
@@ -4293,7 +4357,7 @@ an editorial oversight.
 
 
 
    Proposed resolution:
    
-
    Change the synopsis to reflect the useage in 20.5.9 [negators]
    
+
    Change the synopsis to reflect the useage in 20.5.10 [negators]
    
 
 
    [Curaçao: Since the language permits "struct", the LWG
 views this as NAD. They suggest, however, that the Project Editor
@@ -5047,7 +5111,6 @@ 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 Future
  Submitter: Gabriel Dos Reis Date: 2002-11-08
    
-
    View other active issues in [complex.numbers].
    
 
    View all other issues in [complex.numbers].
    
 
    View all issues with NAD Future status.
    
 
    Discussion:
    
@@ -5099,6 +5162,7 @@ provide their own comparison function object.
    
 
    390. CopyConstructible requirements too strict
    
 
    Section: 20.1.1 [utility.arg.requirements] Status: NAD Future
  Submitter: Doug Gregor Date: 2002-10-24
    
+
    View other active issues in [utility.arg.requirements].
    
 
    View all other issues in [utility.arg.requirements].
    
 
    View all issues with NAD Future status.
    
 
    Discussion:
    
@@ -5228,10 +5292,72 @@ of input iterators.
    
 
 
 
    
+
    393. do_in/do_out operation on state unclear
    
+
    Section: 22.2.1.4.2 [locale.codecvt.virtuals] Status: Pending NAD Editorial
+ Submitter: Alberto Barbati Date: 2002-12-24
    
+
    View other active issues in [locale.codecvt.virtuals].
    
+
    View all other issues in [locale.codecvt.virtuals].
    
+
    View all issues with Pending NAD Editorial status.
    
+
    Discussion:
    
+
    
+this DR follows the discussion on the previous thread "codecvt::do_in
+not consuming external characters". It's just a clarification issue
+and not a request for a change.
+
    
+
    
+Can do_in()/do_out() produce output characters without consuming input 
+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], 
+paragraph 3:
+
    
+
+
    
+[Note: As a result of operations on state, it can return ok or partial 
+and set from_next == from and to_next != to. --end note]
+
    
+
+
+
    Rationale:
    
+
    
+The submitter believes that standard already provides an affirmative
+answer to the question. However, the current wording has induced a few
+library implementors to make the incorrect assumption that
+do_in()/do_out() always consume at least one internal character when
+they succeed.
+
    
+
+
    
+The submitter also believes that the proposed resolution is not in
+conflict with the related issue 76. Moreover, by explicitly allowing
+operations on state to produce characters, a codecvt implementation
+may effectively implement N-to-M translations without violating the
+"one character at a time" principle described in such issue. On a side
+note, the footnote in the proposed resolution of issue 76 that
+informally rules out N-to-M translations for basic_filebuf should be
+removed if this issue is accepted as valid.
+
    
+
+
+
    [
+Kona (2007): The proposed resolution is to add a note. Since this is
+non-normative, the issue is editorial, but we believe that the note is
+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
    
-
    View other active issues in [istream.unformatted].
    
 
    View all other issues in [istream.unformatted].
    
 
    View all issues with NAD status.
    
 
    Discussion:
    
@@ -8029,6 +8155,41 @@ Berlin: N1932 considers this NAD. This is a QOI issue.
 
 
 
    
+
    525. type traits definitions not clear
    
+
    Section: 20.4.4 [meta.unary], TR1 4.5 [tr.meta.unary] Status: NAD Editorial
+ Submitter: Robert Klarer Date: 2005-07-11
    
+
    View all issues with NAD Editorial status.
    
+
    Discussion:
    
+
    
+It is not completely clear how the primary type traits deal with
+cv-qualified types.  And several of the secondary type traits
+seem to be lacking a definition.
+
    
+
+
    [
+Berlin:  Howard to provide wording.
+]
    
+
+
+
+
    Proposed resolution:
    
+
    
+Wording provided in N2028.
+A
+revision (N2157)
+provides more detail for motivation.
+
    
+
+
+
    Rationale:
    
+Solved by revision (N2157)
+in the WP.
+
+
+
+
+
+
    
 
    526. Is it undefined if a function in the standard changes in parameters?
    
 
    Section: 23.1.1 [sequence.reqmts] Status: NAD
  Submitter: Chris Jefferson Date: 2005-09-14
    
@@ -8179,6 +8340,83 @@ template insert functions from self referencing.
    • 
 
 
 
    
+
    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].
    
+
    View all other issues in [unord].
    
+
    View all issues with NAD status.
    
+
    Discussion:
    
+
    
+while implementing the resolution of issue 6.19 I'm noticing the
+following: according to 6.3.4.3/2 (and 6.3.4.5/2), for unordered_set and
+unordered_multiset:
+
    
+
+
    
+    "The iterator and const_iterator types are both const types. It is
+unspecified whether they are the same type"
+
    
+
+
    
+Now, according to the resolution of 6.19, we have overloads of insert
+with hint and erase (single and range) both for iterator and
+const_iterator, which, AFAICS, can be meaningful at the same time *only*
+if iterator and const_iterator *are* in fact different types.
+
    
+
    
+Then, iterator and const_iterator are *required* to be different types?
+Or that is an unintended consequence? Maybe the overloads for plain
+iterators should be added only to unordered_map and unordered_multimap?
+Or, of course, I'm missing something?
+
    
+
+
+
+
    Proposed resolution:
    
+
    
+Add to 6.3.4.3p2 (and 6.3.4.5p2):
+
    
+
    
+2  ... The iterator and const_iterator types are both const
+constant iterator types.
+It is unspecified whether they are the same type. 
+
    
+
+
    
+Add a new subsection to 17.4.4 [lib.conforming]:
+
    
+
+
    
+
    
+An implementation shall not supply an overloaded function
+       signature specified in any library clause if such a signature
+       would be inherently ambiguous during overload resolution
+       due to two library types referring to the same type.
+
    
+
    
+       [Note: For example, this occurs when a container's iterator
+       and const_iterator types are the same. -- end note]
+
    
+
    
+
+
    [
+Post-Berlin: Beman supplied wording.
+]
    
+
+
+
+
+
    Rationale:
    
+Toronto:  The first issue has been fixed by N2350 (the insert and erase members
+are collapsed into one signature).  Alisdair to open a separate issue on the
+chapter 17 wording.
+
+
+
+
+
+
    
 
    532. Tuple comparison
    
 
    Section: 20.3.1.5 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] Status: Pending NAD Editorial
  Submitter: David Abrahams Date: 2005-11-29
    
@@ -8402,6 +8640,48 @@ 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
    
+
    View all issues with NAD status.
    
+
    Discussion:
    
+
    
+Class random_device "produces non-deterministic random numbers", using some
+external source of entropy. In most real-world systems, the amount of available
+entropy is limited. Suppose that entropy has been exhausted. What is an
+implementation permitted to do? In particular, is it permitted to block
+indefinitely until more random bits are available, or is the implementation
+required to detect failure immediately? This is not an academic question. On
+Linux a straightforward implementation would read from /dev/random, and "When
+the entropy pool is empty, reads to /dev/random will block until additional
+environmental noise is gathered." Programmers need to know whether random_device
+is permitted to (or possibly even required to?) behave the same way.
+
    
+
+
    [
+Berlin: Walter: N1932 considers this NAD. Does the standard specify whether std::cin
+may block?
+]
    
+
+
+
    
+See N2391 and
+N2423
+for some further discussion.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Adopt the proposed resolution in
+N2423 (NAD).
+
    
+
+
+
+
+
+
    
 
    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
    
@@ -8432,9 +8712,9 @@ 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: Pending NAD Editorial
+
    Section: 18.3.1 [cstdint.syn], TR1 8.22.1 [tr.c99.cstdint.syn] Status: NAD Editorial
  Submitter: Paolo Carlini Date: 2006-01-30
    
-
    View all issues with Pending NAD Editorial status.
    
+
    View all issues with NAD Editorial status.
    
 
    Discussion:
    
 
    
 In the synopsis, some types are identified as optional: int8_t, int16_t,
@@ -8792,10 +9072,10 @@ committee meant.
 
 
    
 
    571. Update C90 references to C99?
    
-
    Section: 1.2 [intro.refs] Status: Pending NAD Editorial
+
    Section: 1.2 [intro.refs] Status: NAD Editorial
  Submitter: Beman Dawes Date: 2006-04-08
    
 
    View all other issues in [intro.refs].
    
-
    View all issues with Pending NAD Editorial status.
    
+
    View all issues with NAD Editorial status.
    
 
    Discussion:
    
 
    
 1.2 Normative references [intro.refs] of the WP currently refers to ISO/IEC
@@ -8863,6 +9143,76 @@ is adopted.
 
 
 
    
+
    583. div() for unsigned integral types
    
+
    Section: 26.7 [c.math] Status: NAD
+ Submitter: Beman Dawes Date: 2006-06-15
    
+
    View other active issues in [c.math].
    
+
    View all other issues in [c.math].
    
+
    View all issues with NAD status.
    
+
    Discussion:
    
+
    
+There is no div() function for unsigned integer types.
+
    
+
    
+There are several possible resolutions.  The simplest one is noted below.  Other
+possibilities include a templated solution.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Add to 26.7 [lib.c.math] paragraph 8:
+
    
+
+
    struct udiv_t div(unsigned, unsigned);
+struct uldiv_t div(unsigned long, unsigned long);
+struct ulldiv_t div(unsigned long long, unsigned long long);
+
    
+
+
+
+
    Rationale:
    
+Toronto:  C99 does not have these unsigned versions because
+the signed version exist just to define the implementation-defined behavior
+of signed integer division.  Unsigned integer division has no implementation-defined
+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
    
+
    View other active issues in [c.math].
    
+
    View all other issues in [c.math].
    
+
    View all issues with NAD status.
    
+
    Discussion:
    
+
    
+There is no pow() function for any integral type.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Add something like:
+
    
+
+
    template< typename T>
+T power( T x, int n );
+// requires: n >=0
+
    
+
+
+
    Rationale:
    
+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
    
@@ -8899,6 +9249,7 @@ post Oxford: Noted that it is already fixed in
 
    590. Type traits implementation latitude should be removed for C++0x
    
 
    Section: 20.4 [meta], TR1 4.9 [tr.meta.req] Status: NAD Editorial
  Submitter: Beman Dawes Date: 2006-08-10
    
+
    View all other issues in [meta].
    
 
    View all issues with NAD Editorial status.
    
 
    Discussion:
    
 
    
@@ -8937,10 +9288,10 @@ current working draft.
 
 
    
 
    591. Misleading "built-in
    
-
    Section: 18.2.1.2 [numeric.limits.members] Status: Pending NAD Editorial
+
    Section: 18.2.1.2 [numeric.limits.members] Status: NAD Editorial
  Submitter: whyglinux Date: 2006-08-08
    
 
    View all other issues in [numeric.limits.members].
    
-
    View all issues with Pending NAD Editorial status.
    
+
    View all issues with NAD Editorial status.
    
 
    Discussion:
    
 
    
 18.2.1.2 numeric_limits members [lib.numeric.limits.members]
@@ -9005,9 +9356,70 @@ 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: Pending NAD Editorial
+ Submitter: Christopher Kohlhoff Date: 2006-08-17
    
+
    View all other issues in [ifstream.members].
    
+
    View all issues with Pending NAD Editorial status.
    
+
    Discussion:
    
+
    
+I just spotted a minor problem in 27.8.1.7
+[lib.ifstream.members] para 4 and also 27.8.1.13
+[lib.fstream.members] para 4. In both places it says:
+
    
+
    
+
    void close();
+
    
+
    
+Effects: Calls rdbuf()->close() and, if that function returns false, ...
+
    
+
    
+
    
+However, basic_filebuf::close() (27.8.1.2) returns a pointer to the
+filebuf on success, null on failure, so I think it is meant to
+say "if that function returns a null pointer". Oddly, it is
+correct for basic_ofstream.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Change 27.8.1.9 [ifstream.members], p5:
+
    
+
+
    
+Effects: Calls rdbuf()->close() and, if that function
+fails (returns false a null pointer),
+calls setstate(failbit) (which may throw ios_base::failure
+(27.4.4.3)).
+
    
+
+
    
+Change 27.8.1.17 [fstream.members], p5:
+
    
+
+
    
+Effects: Calls rdbuf()->close() and, if that function
+fails (returns false a null pointer),
+calls setstate(failbit) (which may throw ios_base::failure
+(27.4.4.3)).
+
    
+
+
+
+
    [
+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].
    
 
    View all other issues in [utility.arg.requirements].
    
 
    View all issues with Pending NAD Editorial status.
    
 
    Discussion:
    
@@ -9148,7 +9560,7 @@ will essentially rewrite this section and provide the desired semantics.
 
 
    
 
    615. Inconsistencies in Section 21.4
    
-
    Section: 21.4 [c.strings] Status: NAD Editorial
+
    Section: 21.5 [c.strings] Status: NAD Editorial
  Submitter: Bo Persson Date: 2006-12-11
    
 
    View all other issues in [c.strings].
    
 
    View all issues with NAD Editorial status.
    
@@ -9187,12 +9599,12 @@ Recommend NAD, editorial.  Send to Pete.
 
 
    
 
    633. Return clause mentions undefined "type()"
    
-
    Section: 20.5.14.2.5 [func.wrap.func.targ] Status: Pending NAD Editorial
+
    Section: 20.5.15.2.5 [func.wrap.func.targ] Status: NAD Editorial
  Submitter: Daniel Krügler Date: 2007-02-03
    
-
    View all issues with Pending NAD Editorial status.
    
+
    View all issues with NAD Editorial status.
    
 
    Discussion:
    
 
    
-20.5.14.2.5 [func.wrap.func.targ], p4 says:
+20.5.15.2.5 [func.wrap.func.targ], p4 says:
 
    
 
    
 Returns: If type() == typeid(T), a pointer to the stored
@@ -9208,7 +9620,7 @@ function type() in class template function nor in the global or
 
  • 
 Assuming that type should have been target_type(),
 this description would lead to false results, if T = cv
-void due to returns clause 20.5.14.2.5 [func.wrap.func.targ], p1.
+void due to returns clause 20.5.15.2.5 [func.wrap.func.targ], p1.
 
    • 
 
 
@@ -9216,7 +9628,7 @@ void due to returns clause 20.5.14.2.5 [func.wrap.func.targ], p1.
 
 
    Proposed resolution:
    
 
    
-Change 20.5.14.2.5 [func.wrap.func.targ], p4:
+Change 20.5.15.2.5 [func.wrap.func.targ], p4:
 
    
 
 
    
@@ -9237,10 +9649,10 @@ 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: Pending NAD Editorial
+
    Section: 26.5.2.3 [valarray.access] Status: NAD Editorial
  Submitter: Bo Persson Date: 2007-02-11
    
 
    View all other issues in [valarray.access].
    
-
    View all issues with Pending NAD Editorial status.
    
+
    View all issues with NAD Editorial status.
    
 
    Discussion:
    
 
    
 The signature of the const operator[] has been changed to return a const 
@@ -9265,15 +9677,197 @@ Pete recommends editorial fix.
 
 
 
    
-
    641. Editorial fix for 27.6.4 (N2134)
    
-
    Section: 27.6.4 [ext.manip] Status: Pending NAD Editorial
- Submitter: Daniel Krügler Date: 2007-02-18
    
-
    View all other issues in [ext.manip].
    
-
    View all issues with Pending NAD Editorial status.
    
+
    637. [c.math]/10 inconsistent return values
    
+
    Section: 26.7 [c.math] Status: NAD Editorial
+ Submitter: Bo Persson Date: 2007-02-13
    
+
    View other active issues in [c.math].
    
+
    View all other issues in [c.math].
    
+
    View all issues with NAD Editorial status.
    
 
    Discussion:
    
 
    
-The function f in para 4 (27.6.4 [ext.manip]) references an unknown strm
-in the following line:
+26.7 [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.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Change 26.7 [c.math], paragraph 10,
+
    
+
+
    float int ilogb(float);
+float long lrint(float);
+float long lround(float);
+float long long llrint(float);
+float long long llround(float);
+
+long double int ilogb(long double);
+long double long lrint(long double);
+long double long lround(long double);
+long double long long llrint(long double);
+long double long long llround(long double);
+
    
+
+
+
+
+
+
    
+
    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
    
+
    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
+from 14882:2003(E), namely 64 and 413.
+
    
+
+
    
+Even with these proposed corrections, already maintained in N2134,
+I have the feeling, that the current wording does still not properly
+handle the "exceptional" situation. The combination of para 14
+
    
+
+
    
+"[..] Characters are extracted and inserted until
+any of the following occurs:
+
    
+
    
+[..]
+
    
+
    
+- an exception occurs (in which case the exception is caught)."
+
    
+
+
    
+and 15
+
    
+
+
    
+"If the function inserts no characters, it calls setstate(failbit),
+which
+may throw ios_base::failure (27.4.4.3). If it inserted no characters
+because it caught an exception thrown while extracting characters
+from *this and failbit is on in exceptions() (27.4.4.3), then the
+caught
+exception is rethrown."
+
    
+
+
    
+both in N2134 seems to imply that any exception, which occurs
+*after* at least one character has been inserted is caught and lost
+for
+ever. It seems that even if failbit is on in exceptions() rethrow is
+not
+allowed due to the wording "If it inserted no characters because it
+caught an exception thrown while extracting".
+
    
+
+
    
+Is this behaviour by design?
+
    
+
+
    
+I would like to add that its output counterpart in 27.6.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
+compared to input::
+
    
+
    
+1) Paragraph 8 says at its end:
+
    
+
+
    
+"- an exception occurs while getting a character from sb."
+
    
+
+
    
+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.
+
    
+
+
    
+2) Paragraph 9 says:
+
    
+
+
    
+"If the function inserts no characters, it calls setstate(failbit)
+(which
+may throw ios_base::failure (27.4.4.3)). If an exception was thrown
+while extracting a character, the function sets failbit in error
+state,
+and if failbit is on in exceptions() the caught exception is
+rethrown."
+
    
+
+
    
+The sentence starting with "If an exception was thrown" seems to
+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
+
    
+
+
    
+If the function inserts no characters, it calls
+setstate(failbit), which may throw ios_base::failure
+(27.4.4.3). If it inserted no characters because it caught an
+exception thrown while extracting characters from *this
+an exception was thrown while extracting a character from
+*this, the function sets failbit in error state,
+and failbit is on in exceptions() (27.4.4.3), then the
+caught exception is rethrown.
+
    
+
+
    
+(b) In 27.6.2.6.3 [ostream.inserters]/8 (N2134) change the sentence:
+
    
+
+
    
+
    
+Gets characters from sb and inserts them in *this.
+Characters are read from sb and inserted until any of the
+following occurs:
+
    
+
      
+
    • end-of-file occurs on the input sequence;
      • 
+
    • inserting in the output sequence fails (in which case the character to be inserted is not extracted);
      • 
+
    • an exception occurs while getting a character from sb (in which
+case the exception is caught).
      • 
+
    
+
    
+
+
+
+
    Rationale:
    
+This extractor is described as a formatted input function so the
+exception behavior is already specified. There is additional behavior
+described in this section that applies to the case in which failbit is
+set. This doesn't contradict the usual exception behavior for formatted
+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 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
+in the following line:
 
    
 
 
    mg.get(Iter(str.rdbuf()), Iter(), intl, strm, err, mon);
@@ -9300,10 +9894,10 @@ Oxford:  Editorial.
 
 
    
 
    642. Invalidated fstream footnotes in N2134
    
-
    Section: 27.8.1.9 [ifstream.members], 27.8.1.13 [ofstream.members] Status: Pending NAD Editorial
+
    Section: 27.8.1.9 [ifstream.members], 27.8.1.13 [ofstream.members] Status: NAD Editorial
  Submitter: Daniel Krügler Date: 2007-02-20
    
 
    View all other issues in [ifstream.members].
    
-
    View all issues with Pending NAD Editorial status.
    
+
    View all issues with NAD Editorial status.
    
 
    Discussion:
    
 
    
 The standard wording of N2134 has extended the 14882:2003(E)
@@ -9369,10 +9963,70 @@ In 27.8.1.13 [ofstream.members], remove footnote:
 
 
 
    
+
    647. Inconsistent regex_search params
    
+
    Section: 28.11.3 [re.alg.search] Status: NAD Editorial
+ Submitter: Daniel Krügler Date: 2007-02-26
    
+
    View all issues with NAD Editorial status.
    
+
    Discussion:
    
+
    
+28.11.3 [re.alg.search]/5 declares
+
    
+
+
    template <class iterator, class charT, class traits>
+bool regex_search(iterator first, iterator last,
+                  const basic_regex<charT, traits>& e,
+                  regex_constants::match_flag_type flags =
+                      regex_constants::match_default);
+
    
+
+
    
+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:
+
    
+
+
    template <class BidirectionalIterator, class charT, class traits>
+bool regex_search(BidirectionalIterator first, BidirectionalIterator last,
+                  const basic_regex<charT, traits>& e,
+                  regex_constants::match_flag_type flags =
+                      regex_constants::match_default);
+
    
+
+
+
    Proposed resolution:
    
+
    
+In 28.11.3 [re.alg.search]/5 replace all three occurences of param "iterator" with
+"BidirectionalIterator"
+
    
+
+
    template <class iterator BidirectionalIterator, class charT, class traits>
+  bool regex_search(iterator BidirectionalIterator first, iterator BidirectionalIterator last, 
+                    const basic_regex<charT, traits>& e, 
+                    regex_constants::match_flag_type flags = 
+                      regex_constants::match_default);
+
    
+
    
+-6- Effects: Behaves "as if" by constructing an object what of
+type match_results<iterator
+BidirectionalIterator> and then returning the result
+of regex_search(first, last, what, e, flags).
+
    
+
    
+
+
+
    Rationale:
    
+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: Pending NAD Editorial
+
    Section: 28.12.1.1 [re.regiter.cnstr] Status: NAD Editorial
  Submitter: Daniel Krügler Date: 2007-03-03
    
-
    View all issues with Pending NAD Editorial status.
    
+
    View all issues with NAD Editorial status.
    
 
    Discussion:
    
 
    
 In 28.12.1.1 [re.regiter.cnstr]/2 the effects paragraph starts with:
@@ -9424,10 +10078,10 @@ 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: Pending NAD Editorial
+
    Section: 28.12.2.1 [re.tokiter.cnstr] Status: NAD Editorial
  Submitter: Daniel Krügler Date: 2007-03-03
    
 
    View all other issues in [re.tokiter.cnstr].
    
-
    View all issues with Pending NAD Editorial status.
    
+
    View all issues with NAD Editorial status.
    
 
    Discussion:
    
 
    
 In 28.12.2.1 [re.tokiter.cnstr]/1+2 both the constructor declaration
@@ -9526,10 +10180,10 @@ constructor sets *this to an end-of-sequence iterator.
 
 
    
 
    656. Typo in subtract_with_carry_engine declaration
    
-
    Section: 26.4.2 [rand.synopsis] Status: Pending NAD Editorial
+
    Section: 26.4.2 [rand.synopsis] Status: NAD Editorial
  Submitter: Daniel Krügler Date: 2007-03-08
    
 
    View all other issues in [rand.synopsis].
    
-
    View all issues with Pending NAD Editorial status.
    
+
    View all issues with NAD Editorial status.
    
 
    Discussion:
    
 
    
 26.4.2 [rand.synopsis] the header <random> synopsis
@@ -9557,6 +10211,331 @@ 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
    
+
    View all issues with NAD status.
    
+
    Discussion:
    
+
    
+17.4.2.1 [using.headers] states:
+
    
+
+
    
+A translation unit shall include a header only outside of any
+external declaration or definition, [...]
+
    
+
+
    
+I see three problems with this requirement:
+
    
+
+
      
+
    1. The C++ standard doesn't define what an "external declaration" or
+an "external definition" are (incidentally the C99 standard does, and
+has a sentence very similar to the above regarding header inclusion).
+
      
+I think the intent is that the #include directive shall lexically
+appear outside *any* declaration; instead, when the issue was pointed
+out on comp.std.c++ at least one poster interpreted "external
+declaration" as "declaration of an identifier with external linkage".
+If this were the correct interpretation, then the two inclusions below
+would be legal:
+
      
+
        // at global scope
+  static void f()
+  {
+# include <cstddef>
+  }
+
+  static void g()
+  {
+# include <stddef.h>
+  }
+
      
+
      
+(note that while the first example is unlikely to compile correctly,
+the second one may well do)
+
      2. 
+
+
    2. as the sentence stands, violations will require a diagnostic; is
+this the intent? It was pointed out on comp.std.c++ (by several
+posters) that at least one way to ensure a diagnostic exists:
+
      
+
      
+   [If there is an actual file for each header,] one simple way
+   to implement this would be to insert a reserved identifier
+   such as __begin_header  at the start of each standard header.
+   This reserved identifier would be ignored for all other
+   purposes, except that, at the appropriate point in phase 7, if
+   it is found inside an external definition, a diagnostic is
+   generated. There's many other similar ways to achieve the same
+   effect.
+   
      
+
                                       --James Kuyper, on comp.std.c++
+
      3. 
+
+
    3. is the term "header" meant to be limited to standard headers?
+Clause 17 is all about the library, but still the general question is
+interesting and affects one of the points in the explicit namespaces
+proposal (n1691):
+
      
+
      
+    Those seeking to conveniently enable argument-dependent
+    lookups for all operators within an explicit namespace
+    could easily create a header file that does so:
+
          namespace mymath::
+    {
+        #include "using_ops.hpp"
+    }
+
      
+
      4. 
+
    
+
+
+
    Proposed resolution:
    
+
    
+
    
+
+
+
    Rationale:
    
+We believe that the existing language does not cause any real confusion
+and any new formulation of the rules that we could come up with are
+unlikely to be better than what's already in the standard.
+
+
+
+
+
+
    
+
    658. Two unspecified function comparators in [function.objects]
    
+
    Section: 20.5 [function.objects] Status: NAD Editorial
+ Submitter: Daniel Krügler Date: 2007-03-19
    
+
    View all other issues in [function.objects].
    
+
    View all issues with NAD Editorial status.
    
+
    Discussion:
    
+
    
+The header <functional> synopsis in 20.5 [function.objects]
+contains the following two free comparison operator templates
+for the function class template
+
    
+
+
    template<class Function1, class Function2>
+void operator==(const function<Function1>&, const function<Function2>&);
+template<class Function1, class Function2>
+void operator!=(const function<Function1>&, const function<Function2>&);
+
    
+
+
    
+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.5.15.2 [func.wrap.func] and X [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.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Remove the above mentioned two function templates from
+the header <functional> synopsis (20.5 [function.objects])
+
    
+
+
    template<class Function1, class Function2>
+void operator==(const function<Function1>&, const function<Function2>&);
+template<class Function1, class Function2>
+void operator!=(const function<Function1>&, const function<Function2>&);
+
    
+
+
+
+
    Rationale:
    
+Fixed by
+N2292
+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
    
+
    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
+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.
+Since incorrectly-placed thousands separators are flagged as an extraction
+failure (by the means of failbit), we believe it is better not
+to store the value. A consistent strategy, in which any kind of extraction
+failure leaves the input item intact, is conceptually cleaner, is able to avoid
+corner-case traps, and is also more understandable from the programmer's point
+of view.
+
    
+
    
+Here is a quote from "The C++ Programming Language (Special Edition)"
+by B. Stroustrup (Section D.4.2.3, pg. 897):
+
    
+
    
+"If a value of the desired type could not be read, failbit is set in r.
+[...] An input operator will use r to determine how to set the state of its
+stream. If no error was encountered, the value read is assigned through v;
+otherwise, v is left unchanged."
+
    
+
    
+This statement implies that rdstate() alone is sufficient to
+determine whether an extracted value is to be assigned to the input item
+val passed to do_get. However, this is in disagreement
+with the current C++ Standard. The above-mentioned assumption is true in all
+cases, except when there are mismatches in digit grouping. In the latter case,
+the parsed value is assigned to val, and, at the same time, err
+is assigned to ios_base::failbit (essentially "lying" about the
+success of the operation). Is this intentional? The current behavior raises
+both consistency and usability concerns.
+
    
+
    
+Although digit grouping is outside the scope of scanf (on which
+the virtual methods of num_get are based), handling of grouping
+should be consistent with the overall behavior of scanf. The specification of
+scanf makes a distinction between input failures and matching
+failures, and yet both kinds of failures have no effect on the input items
+passed to scanf. A mismatch in digit grouping logically falls in
+the category of matching failures, and it would be more consistent, and less
+surprising to the user, to leave the input item intact whenever a failure is
+being signaled.
+
    
+
    
+The extraction of bool is another example outside the scope of
+scanf, and yet consistent, even in the event of a successful
+extraction of a long but a failed conversion from
+long to bool.
+
    
+
    
+Inconsistency is further aggravated by the fact that, when failbit is set,
+subsequent extraction operations are no-ops until failbit is
+explicitly cleared. Assuming that there is no explicit handling of
+rdstate() (as in cin>>i>>j) it is
+counter-intuitive to be able to extract an integer with mismatched digit
+grouping, but to be unable to extract another, properly-formatted integer
+that immediately follows.
+
    
+
    
+Moreover, setting failbit, and selectively assigning a value to
+the input item, raises usability problems. Either the strategy of
+scanf (when there is no extracted value in case of failure), or
+the strategy of the strtol family (when there is always an
+extracted value, and there are well-defined defaults in case of a failure) are
+easy to understand and easy to use. On the other hand, if failbit
+alone cannot consistently make a difference between a failed extraction, and a
+successful but not-quite-correct extraction whose output happens to be the same
+as the previous value, the programmer must resort to implementation tricks.
+Consider the following example:
+
    
+
        int i = old_i;
+    cin >> i;
+    if (cin.fail())
+        // can the value of i be trusted?
+        // what does it mean if i == old_i?
+        // ...
+
    
+
    
+Last but not least, the current behvaior is not only confusing to the casual
+reader, but it has also been confusing to some book authors. Besides
+Stroustrup's book, other books (e.g. "Standard C++ IOStreams and Locales" by
+Langer and Kreft) are describing the same mistaken assumption. Although books
+are not to be used instead of the standard reference, the readers of these
+books, as well as the people who are generally familiar to scanf,
+are even more likely to misinterpret the standard, and expect the input items
+to remain intact when a failure occurs.
+
    
+
+
+
    Proposed resolution:
    
+
+
    
+Change 22.2.2.1.2 [facet.num.get.virtuals]:
+
    
+
+
    
+
    
+Stage 3: The result of stage 2 processing can be one of
+
    
+
      
+
    • 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.
      • 
+
+
    • The sequence of chars accumulated in stage 2 would have caused scanf to report an input failure. ios_base::failbit is assigned to err.
      • 
+
    
+
    
+In the first case, Ddigit grouping is checked.  That is, the positions of discarded separators is examined for consistency with use_facet<numpunct<charT> >(loc).grouping().  If they are not consistent then ios_base::failbit is assigned to err.  Otherwise, the value that was converted in stage 2 is stored in val and ios_base::goodbit is stored in err.
+
    
+
    
+
+
+
    Rationale:
    
+post-Toronto: Changed from New to NAD at the request of the author.  The preferred solution of
+N2327
+makes this resolution obsolete.
+
+
+
+
+
+
    
+
    663. Complexity Requirements
    
+
    Section: 17.3.1.3 [structure.specifications] Status: NAD
+ Submitter: Thomas Plum Date: 2007-04-16
    
+
    View all other issues in [structure.specifications].
    
+
    View all issues with NAD status.
    
+
    Discussion:
    
+
    
+17.3.1.3 [structure.specifications] para 5 says
+
    
+
+
    
+-5- Complexity requirements specified in the library 
+clauses are upper bounds, and implementations that provide better
+complexity guarantees satisfy the requirements.
+
    
+
+
    
+The following
+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
+or until the Library group standardizes specific hard-and-fast
+formulae, we regard all the complexity requirements as subject to a 
+"fudge factor" without any intrinsic upper bound.
+
    
+
+
    
+[Plum ref 
+_23213Y31 etc]
+
    
+
+
+
    Proposed resolution:
    
+
    
+
    
+
+
+
    Rationale:
    
+Kona (2007): No specific instances of underspecification have been
+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
    
@@ -9605,4 +10584,44 @@ Yep, looks like a typo/administrative fix to me.
 
 
 
+
    
+
    690. abs(long long) should return long long
    
+
    Section: 26.7 [c.math] Status: NAD Editorial
+ Submitter: Niels Dekker Date: 2007-06-10
    
+
    View other active issues in [c.math].
    
+
    View all other issues in [c.math].
    
+
    View all issues with NAD Editorial status.
    
+
    Discussion:
    
+
    
+Quoting the latest draft (n2135), 26.7 [c.math]: 
+
    
+
+
    
+
    
+The added signatures are:
+
    
+
    long abs(long); // labs()
+long abs(long long); // llabs()
+
    
+
    
+
    
+Shouldn't abs(long long) have long long as return type?
+
    
+
+
+
    Proposed resolution:
    
+
    
+Change 26.7 [c.math]: 
+
    
+
    long long abs(long long); // llabs()
+
    
+
+
+
    Rationale:
    
+Had already been fixed in the WP by the time the LWG reviewed this.
+
+
+
+
+
 
\ No newline at end of file
diff --git a/libstdc++-v3/docs/html/ext/lwg-defects.html b/libstdc++-v3/docs/html/ext/lwg-defects.html
index 3f4b20c985e..cefbee652e6 100644
--- a/libstdc++-v3/docs/html/ext/lwg-defects.html
+++ b/libstdc++-v3/docs/html/ext/lwg-defects.html
@@ -1,22 +1,22 @@
 
 C++ Standard Library Defect Report List
 
+
+
 
-
-
+ins {background-color:#A0FFA0}
+del {background-color:#FFA0A0}
+
 
-
+
-
+
@@ -27,7 +27,7 @@ del {background-color:#FFFFA0}
 
    
 
    
 Doc. no.N2318=07-0178N2457=07-0327
 
    
 
    
 Date:2007-06-242007-10-20
 
    
 
    
 Project:Howard Hinnant <howard.hinnant@gmail.com>
 
    
 
    
-
    C++ Standard Library Defect Report List (Revision R49)
    
+
    C++ Standard Library Defect Report List (Revision R52)
    
 
   
    Reference ISO/IEC IS 14882:1998(E)
    
   
    Also see:
    
@@ -49,6 +49,71 @@ del {background-color:#FFFFA0}
 
 
    Revision History
    
 
@@ -152,7 +217,7 @@ del {background-color:#FFFFA0}
 
  • 592 issues total, up by 5.
    • 
 
 
  • Details:
    • 
 
 
@@ -182,8 +247,8 @@ del {background-color:#FFFFA0}
 
  • Details:
    • 
@@ -198,7 +263,7 @@ del {background-color:#FFFFA0}
 
  • 566 issues total, up by 31.
    • 
 
 
  • Details:
      
-
    • Added new issues 536-566.
      • 
+
    • Added new issues 536-566.
      • 
 
    • Moved 342 from Ready to Open.
      • 
 
    • Reopened 309.
      • 
 
    • 
@@ -219,7 +284,7 @@ del {background-color:#FFFFA0}
 
 
  • R39: 
 2005-10-14 post-Mont Tremblant mailing.
-Added new issues 526-528.
+Added new issues 526-528.
 Moved issues 280, 461, 464, 465, 467, 468, 474, 496 from Ready to WP as per the vote from Mont Tremblant.
 Moved issues 247, 294, 342, 362, 369, 371, 376, 384, 475, 478, 495, 497 from Review to Ready.
 Moved issues 498, 504, 506, 509, 510, 511, 512, 513, 514 from New to Open.
@@ -245,7 +310,7 @@ previously in "DR" status were moved to "WP".
 2005-03 pre-Lillehammer mailing.
 
    • 
 
  • R34: 
-2005-01 mid-term mailing.  Added new issues 488-494.
+2005-01 mid-term mailing.  Added new issues 488-494.
 
    • 
 
  • R33: 
 2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
@@ -1867,6 +1932,7 @@ setstate(badbit).]
    
 
    42. String ctors specify wrong default allocator
    
 
    Section: 21.3 [basic.string] Status: TC
  Submitter: Nathan Myers Date: 1998-08-06
    
+
    View other active issues in [basic.string].
    
 
    View all other issues in [basic.string].
    
 
    View all issues with TC status.
    
 
    Discussion:
    
@@ -3038,7 +3104,6 @@ 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
    
-
    View other active issues in [istream.unformatted].
    
 
    View all other issues in [istream.unformatted].
    
 
    View all issues with TC status.
    
 
    Discussion:
    
@@ -3088,7 +3153,6 @@ 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
    
-
    View other active issues in [istream.unformatted].
    
 
    View all other issues in [istream.unformatted].
    
 
    View all issues with TC status.
    
 
    Discussion:
    
@@ -3608,6 +3672,7 @@ 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
    
+
    View other active issues in [basic.string].
    
 
    View all other issues in [basic.string].
    
 
    View all issues with TC status.
    
 
    Duplicate of: 89
    
@@ -4768,17 +4833,17 @@ typedefs and that is sufficient. 
    
 
 
    
 
    123. Should valarray helper arrays fill functions be const?
    
-
    Section: 26.5.5.4 [slice.arr.fill], 26.5.7.4 [gslice.array.fill], 26.5.8.4 [mask.array.fill], 26.5.9.4 [indirect.array.fill] Status: WP
+
    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.
    
 
    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.2 [slice.arr.assign] is const: 
    
+26.5.5.1 [slice.arr.assign] is const: 
    
 
 
        void operator=(const valarray<T>&) const; 
    
 
-
    but this one in Section 26.5.5.4 [slice.arr.fill] is not: 
    
+
    but this one in Section 26.5.5.3 [slice.arr.fill] is not: 
    
 
 
        void operator=(const T&); 
    
 
@@ -4799,7 +4864,7 @@ is not. For example, look at slice_array. This operator= in Section
     
    • 
 
    
 
-
    26.5.5.4 [slice.arr.fill] slice_array fill function
    
+
    26.5.5.3 [slice.arr.fill] slice_array fill function
    
 
    
 
    
    Change the function declaration
    
@@ -4822,7 +4887,7 @@ is not. For example, look at slice_array. This operator= in Section
     
    
 
    
 
-
    26.5.7.4 [gslice.array.fill] gslice_array fill function
    
+
    26.5.7.3 [gslice.array.fill] gslice_array fill function
    
 
    
 
    
    Change the function declaration
    
@@ -4845,7 +4910,7 @@ is not. For example, look at slice_array. This operator= in Section
     
    
 
    
 
-
    26.5.8.4 [mask.array.fill] mask_array fill function
    
+
    26.5.8.3 [mask.array.fill] mask_array fill function
    
 
    
 
    
    Change the function declaration
    
@@ -4868,7 +4933,7 @@ is not. For example, look at slice_array. This operator= in Section
     
    
 
    
 
-
    26.5.9.4 [indirect.array.fill] indirect_array fill function
    
+
    26.5.9.3 [indirect.array.fill] indirect_array fill function
    
 
    
 
    
    Change the function declaration
    
@@ -5047,7 +5112,6 @@ 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
    
-
    View other active issues in [istream.unformatted].
    
 
    View all other issues in [istream.unformatted].
    
 
    View all issues with TC status.
    
 
    Discussion:
    
@@ -5146,7 +5210,12 @@ Matt provided wording.]
    
  of erase as well as the single-iterator form. Also, the wording is
  slightly different from the wording we have for sequences; there's no
  good reason for having a difference.  Matt provided new wording,
- which we will review at the next meeting.
+(reflected above) which we will review at the next meeting.
+]
    
+
+
+
    [
+Redmond:  formally voted into WP.
 ]
    
 
 
@@ -5253,7 +5322,6 @@ 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
    
-
    View other active issues in [istream.unformatted].
    
 
    View all other issues in [istream.unformatted].
    
 
    View all issues with WP status.
    
 
    Discussion:
    
@@ -6366,7 +6434,6 @@ 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
    
-
    View other active issues in [istream.unformatted].
    
 
    View all other issues in [istream.unformatted].
    
 
    View all issues with TC status.
    
 
    Discussion:
    
@@ -7119,7 +7186,6 @@ Josuttis provided the above wording.]
    
 
    185. Questionable use of term "inline"
    
 
    Section: 20.5 [function.objects] Status: WP
  Submitter: UK Panel Date: 1999-07-26
    
-
    View other active issues in [function.objects].
    
 
    View all other issues in [function.objects].
    
 
    View all issues with WP status.
    
 
    Discussion:
    
@@ -8204,6 +8270,7 @@ iterators.  Null pointers are singular.
 
    209. basic_string declarations inconsistent
    
 
    Section: 21.3 [basic.string] Status: TC
  Submitter: Igor Stauder Date: 2000-02-11
    
+
    View other active issues in [basic.string].
    
 
    View all other issues in [basic.string].
    
 
    View all issues with TC status.
    
 
    Discussion:
    
@@ -8537,7 +8604,6 @@ 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
    
-
    View other active issues in [structure.specifications].
    
 
    View all other issues in [structure.specifications].
    
 
    View all issues with TC status.
    
 
    Discussion:
    
@@ -10060,7 +10126,6 @@ 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
    
-
    View other active issues in [istream.unformatted].
    
 
    View all other issues in [istream.unformatted].
    
 
    View all issues with WP status.
    
 
    Discussion:
    
@@ -10456,12 +10521,12 @@ classes are almost entirely useless.
    
 
  •  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]
    • 
-
  •  remove the copy constructor declaration from 26.5.5.1 [cons.slice.arr]
    • 
-
  •  change paragraph 1 of 26.5.5.1 [cons.slice.arr] to read "This constructor is declared
+
  •  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.2 [slice.arr.assign]
    • 
+
  •  remove the first sentence of paragraph 1 of 26.5.5.1 [slice.arr.assign]
    • 
 
  •  Change the first three words of the second sentence of paragraph 1 of
-    26.5.5.2 [slice.arr.assign] to "These assignment operators have"
    • 
+    26.5.5.1 [slice.arr.assign] to "These assignment operators have"
 
 
 
    gslice_array:
    
@@ -10469,12 +10534,12 @@ classes are almost entirely useless.
    
 
  •  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]
    • 
-
  •  remove the copy constructor declaration from 26.5.7.1 [gslice.array.cons]
    • 
-
  •  change paragraph 1 of 26.5.7.1 [gslice.array.cons] to read "This constructor is declared
+
  •  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.2 [gslice.array.assign]
    • 
+
  •  remove the first sentence of paragraph 1 of 26.5.7.1 [gslice.array.assign]
    • 
 
  •  Change the first three words of the second sentence of paragraph 1 of
-    26.5.7.2 [gslice.array.assign] to "These assignment operators have"
    • 
+    26.5.7.1 [gslice.array.assign] to "These assignment operators have"
 
 
 
    mask_array:
    
@@ -10482,12 +10547,12 @@ classes are almost entirely useless.
    
 
  •  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]
    • 
-
  •  remove the copy constructor declaration from 26.5.8.1 [mask.array.cons]
    • 
-
  •  change paragraph 1 of 26.5.8.1 [mask.array.cons] to read "This constructor is declared
+
  •  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.2 [mask.array.assign]
    • 
+
  •  remove the first sentence of paragraph 1 of 26.5.8.1 [mask.array.assign]
    • 
 
  •  Change the first three words of the second sentence of paragraph 1 of
-    26.5.8.2 [mask.array.assign] to "These assignment operators have"
    • 
+    26.5.8.1 [mask.array.assign] to "These assignment operators have"
 
 
 
    indirect_array:
    
@@ -10495,12 +10560,12 @@ classes are almost entirely useless.
    
 
  • 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]
    • 
-
  •  remove the copy constructor declaration from 26.5.9.1 [indirect.array.cons]
    • 
-
  •  change the descriptive text in 26.5.9.1 [indirect.array.cons] to read "This constructor is
+
  •  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.2 [indirect.array.assign]
    • 
+
  •  remove the first sentence of paragraph 1 of 26.5.9.1 [indirect.array.assign]
    • 
 
  •  Change the first three words of the second sentence of paragraph 1 of
-    26.5.9.2 [indirect.array.assign] to "These assignment operators have"
    • 
+    26.5.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
@@ -11006,10 +11071,11 @@ copyfmt_event.
 
 
    
 
    258. Missing allocator requirement
    
-
    Section: 20.1.2 [allocator.requirements] Status: Pending WP
+
    Section: 20.1.2 [allocator.requirements] Status: WP
  Submitter: Matt Austern Date: 2000-08-22
    
 
    View other active issues in [allocator.requirements].
    
 
    View all other issues in [allocator.requirements].
    
+
    View all issues with WP status.
    
 
    Discussion:
    
 
    
 From lib-7752:
@@ -11081,15 +11147,9 @@ other issues related to allocator instances.]
    
 
 
    Proposed resolution:
    
 
    
-Add row to Table 35: Allocator requirements, right after the row defining operator!=:
-
    
-
-
    
-
    
-If a1 == a2 then Y(a1) == Y(a2)
+Accept proposed wording from
+N2436 part 3.
 
    
-
    
-
 
 
 
    [Lillehammer: Same conclusion as before: this should be
@@ -11101,6 +11161,21 @@ Batavia:  An allocator redesign is not forthcoming and thus we fixed this one is
 ]
    
 
 
+
    [
+Toronto:  Reopened at the request of the project editor (Pete) because the proposed
+wording did not fit within the indicated table.  The intent of the resolution remains
+unchanged.  Pablo to work with Pete on improved wording.
+]
    
+
+
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which
+was subsequently split out into a separate paper N2436 for the purposes of voting.
+The resolution in N2436 addresses this issue.  The LWG voted to accelerate this
+issue to Ready status to be voted into the WP at Kona.
+]
    
+
+
 
 
 
@@ -11236,6 +11311,7 @@ to:
 
    263. Severe restriction on basic_string reference counting
    
 
    Section: 21.3 [basic.string] Status: WP
  Submitter: Kevlin Henney Date: 2000-09-04
    
+
    View other active issues in [basic.string].
    
 
    View all other issues in [basic.string].
    
 
    View all issues with WP status.
    
 
    Discussion:
    
@@ -14728,6 +14804,7 @@ does.
    
 
    334. map::operator[] specification forces inefficient implementation
    
 
    Section: 23.3.1.2 [map.access] Status: WP
  Submitter: Andrea Griffini Date: 2001-09-02
    
+
    View all other issues in [map.access].
    
 
    View all issues with WP status.
    
 
    Discussion:
    
 
    
@@ -15266,20 +15343,20 @@ the two vectors, including their reallocation guarantees.
 
 
    
 
    345. type tm in <cwchar>
    
-
    Section: 21.4 [c.strings] Status: WP
+
    Section: 21.5 [c.strings] Status: WP
  Submitter: Clark Nelson Date: 2001-10-19
    
 
    View all other issues in [c.strings].
    
 
    View all issues with WP 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.4
+declares struct tm as an incomplete type. However, table 48 in 21.5
 [c.strings] does not mention the type tm as being declared in
 <cwchar>. Is this omission intentional or accidental?
 
    
 
 
 
    Proposed resolution:
    
-
    In section 21.4 [c.strings], add "tm" to table 48.
    
+
    In section 21.5 [c.strings], add "tm" to table 48.
    
 
 
 
@@ -16187,7 +16264,6 @@ 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
    
-
    View other active issues in [istream.unformatted].
    
 
    View all other issues in [istream.unformatted].
    
 
    View all issues with WP status.
    
 
    Discussion:
    
@@ -16982,6 +17058,90 @@ 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
    
+
    View other active issues in [allocator.requirements].
    
+
    View all other issues in [allocator.requirements].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+I think that in par2 of  [default.con.req] the last two
+lines of table 32 contain two incorrect type casts. The lines are ...
+
    
+
+
      a.construct(p,t)   Effect: new((void*)p) T(t)
+  a.destroy(p)       Effect: ((T*)p)?->~T()
+
    
+
+
    
+.... with the prerequisits coming from the preceding two paragraphs, especially
+from table 31:
+
    
+
+
      alloc<T>             a     ;// an allocator for T
+  alloc<T>::pointer    p     ;// random access iterator
+                              // (may be different from T*)
+  alloc<T>::reference  r = *p;// T&
+  T const&             t     ;
+
    
+
+
    
+For that two type casts ("(void*)p" and "(T*)p") to be well-formed
+this would require then conversions to T* and void* for all
+alloc<T>::pointer, so it would implicitely introduce extra
+requirements for alloc<T>::pointer, additionally to the only
+current requirement (being a random access iterator).
+
    
+
+
+
    Proposed resolution:
    
+
+
    
+Accept proposed wording from
+N2436 part 1.
+
    
+
+
    
+Note: Actually I would prefer to replace "((T*)p)?->dtor_name" with
+"p?->dtor_name", but AFAICS this is not possible cause of an omission
+in 13.5.6 [over.ref] (for which I have filed another DR on 29.11.2002).
+
    
+
+
    [Kona: The LWG thinks this is somewhere on the border between
+  Open and NAD.  The intend is clear: construct constructs an
+  object at the location p.  It's reading too much into the
+  description to think that literally calling new is
+  required.  Tweaking this description is low priority until we can do
+  a thorough review of allocators, and, in particular, allocators with
+  non-default pointer types.]
    
+
+
+
    [
+Batavia:  Proposed resolution changed to less code and more description.
+]
    
+
+
+
    [
+post Oxford:  This would be rendered NAD Editorial by acceptance of
+N2257.
+]
    
+
+
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which
+was subsequently split out into a separate paper N2436 for the purposes of voting.
+The resolution in N2436 addresses this issue.  The LWG voted to accelerate this
+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.6.1.1 [allocator.members] Status: WP
  Submitter: Markus Mauhart Date: 2003-02-27
    
@@ -17882,6 +18042,7 @@ no storage can be obtained or if n <= 0."
    
 
    426. search_n(), fill_n(), and generate_n() with negative n
    
 
    Section: 25.1.9 [alg.search], 25.2.6 [alg.fill], 25.2.7 [alg.generate] Status: WP
  Submitter: Martin Sebor Date: 2003-09-18
    
+
    View all other issues in [alg.search].
    
 
    View all issues with WP status.
    
 
    Discussion:
    
 
    
@@ -19140,11 +19301,11 @@ undefined."
 
 
    
 
    453. basic_stringbuf::seekoff need not always fail for an empty stream
    
-
    Section: 27.7.1.4 [stringbuf.virtuals] Status: DR
+
    Section: 27.7.1.4 [stringbuf.virtuals] Status: WP
  Submitter: Bill Plauger Date: 2004-01-30
    
 
    View other active issues in [stringbuf.virtuals].
    
 
    View all other issues in [stringbuf.virtuals].
    
-
    View all issues with DR status.
    
+
    View all issues with WP status.
    
 
    Discussion:
    
 
      pos_type basic_stringbuf::seekoff(off_type, ios_base::seekdir,
                                     ios_base::openmode);
@@ -19997,6 +20158,92 @@ 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.
    
+
    Discussion:
    
+
    
+rotate takes 3 iterators:  first, middle and last which point into a
+sequence, and rearranges the sequence such that the subrange [middle,
+last) is now at the beginning of the sequence and the subrange [first,
+middle) follows.  The return type is void. 
+
    
+
+
    
+In many use cases of rotate, the client needs to know where the
+subrange [first, middle) starts after the rotate is performed.  This
+might look like: 
+
    
+
      rotate(first, middle, last);
+  Iterator i = advance(first, distance(middle, last));
+
    
+
+
    
+Unless the iterators are random access, the computation to find the
+start of the subrange [first, middle) has linear complexity.  However,
+it is not difficult for rotate to return this information with
+negligible additional computation expense.  So the client could code: 
+
    
+
      Iterator i = rotate(first, middle, last);
+
    
+
+
    
+and the resulting program becomes significantly more efficient.
+
    
+
+
    
+While the backwards compatibility hit with this change is not zero, it
+is very small (similar to that of lwg 130), and there is
+a significant benefit to the change. 
+
    
+
+
+
+
    Proposed resolution:
    
+
    In 25 [algorithms] p2, change:
    
+
+
      template<class ForwardIterator>
+    void ForwardIterator rotate(ForwardIterator first, ForwardIterator middle,
+                ForwardIterator last);
+
    
+
+
    In 25.2.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:
    
+
+
    
+
    Returns: first + (last - middle).
    
+
    
+
+
    [
+The LWG agrees with this idea, but has one quibble: we want to make
+sure not to give the impression that the function "advance" is
+actually called, just that the nth iterator is returned.  (Calling
+advance is observable behavior, since users can specialize it for
+their own iterators.)  Howard will provide wording.
+]
    
+
+
+
    [Howard provided wording for mid-meeting-mailing Jun. 2005.]
    
+
+
+
    [
+Toronto: moved to Ready.
+]
    
+
+
+
+
+
+
+
+
    
 
    495. Clause 22 template parameter requirements
    
 
    Section: 22 [localization] Status: WP
  Submitter: Beman Dawes Date: 2005-01-10
    
@@ -20362,7 +20609,7 @@ of data() is unspecified.
 
 
    
 
    520. Result_of and pointers to data members
    
-
    Section: 20.5.10.1 [func.bind], TR1 3.6 [tr.func.bind] Status: WP
+
    Section: 20.5.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.
    
 
    Discussion:
    
@@ -20475,9 +20722,88 @@ function's cv-qualifiers); the type T1 is cv T0*
 
 
 
    
+
    524. regex named character classes and case-insensitivity don't mix
    
+
    Section: 28 [re] Status: WP
+ Submitter: Eric Niebler Date: 2005-07-01
    
+
    View all other issues in [re].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+This defect is also being discussed on the Boost developers list. The 
+full discussion can be found here:
+http://lists.boost.org/boost/2005/07/29546.php
+
    
+
    
+-- Begin original message --
+
    
+
    
+Also, I may have found another issue, closely related to the one under
+discussion. It regards case-insensitive matching of named character
+classes. The regex_traits<> provides two functions for working with
+named char classes: lookup_classname and isctype. To match a char class
+such as [[:alpha:]], you pass "alpha" to lookup_classname and get a
+bitmask. Later, you pass a char and the bitmask to isctype and get a
+bool yes/no answer.
+
    
+
    
+But how does case-insensitivity work in this scenario? Suppose we're
+doing a case-insensitive match on [[:lower:]]. It should behave as if it
+were [[:lower:][:upper:]], right? But there doesn't seem to be enough
+smarts in the regex_traits interface to do this.
+
    
+
    
+Imagine I write a traits class which recognizes [[:fubar:]], and the
+"fubar" char class happens to be case-sensitive. How is the regex engine
+to know that? And how should it do a case-insensitive match of a
+character against the [[:fubar:]] char class? John, can you confirm this
+is a legitimate problem?
+
    
+
    
+I see two options:
+
    
+
    
+1) Add a bool icase parameter to lookup_classname. Then,
+lookup_classname( "upper", true ) will know to return lower|upper
+instead of just upper.
+
    
+
    
+2) Add a isctype_nocase function
+
    
+
    
+I prefer (1) because the extra computation happens at the time the
+pattern is compiled rather than when it is executed.
+
    
+
    
+-- End original message --
+
    
+
+
    
+For what it's worth, John has also expressed his preference for option 
+(1) above.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Adopt the proposed resolution in
+N2409.
+
    
+
+
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]
    
+
+
+
+
+
+
    
 
    530. Must elements of a string be contiguous?
    
 
    Section: 21.3 [basic.string] Status: WP
  Submitter: Matt Austern Date: 2005-11-15
    
+
    View other active issues in [basic.string].
    
 
    View all other issues in [basic.string].
    
 
    View all issues with WP status.
    
 
    Discussion:
    
@@ -20528,8 +20854,84 @@ 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
    
+
    View all other issues in [istream.unformatted].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+The array forms of unformatted input functions don't seem to have well-defined
+semantics for zero-element arrays in a couple of cases. The affected ones
+(istream::get() and istream::getline()) are supposed to
+terminate when (n - 1) characters are stored, which obviously can
+never be true when (n == 0) holds to start with. See
+c++std-lib-16071.
+
    
+
+
+
    Proposed resolution:
    
+
    
+I suggest changing 27.6.1.3, p7 (istream::get()), bullet 1 to read:
+
    
+            
      
+                
    • 
+                    (n < 1) is true or (n - 1) characters
+                    are stored;
+                
      • 
+            
    
+
    
+Change 27.6.1.3, p9:
+
    
+
+
    
+If the function stores no characters, it calls setstate(failbit) (which
+may throw ios_base::failure (27.4.4.3)).  In any case, if (n
+> 0) is true it then stores a null character into the next
+successive location of the array.
+
    
+
+        
    
+
+and similarly p17 (istream::getline()), bullet 3 to:
+
+        
    
+            
      
+                
    • 
+                    (n < 1) is true or (n - 1) characters
+                    are stored (in which case the function calls
+                    setstate(failbit)).
+                
      • 
+            
    
+
+        
    
+
+In addition, to clarify that istream::getline() must not store the
+terminating NUL character unless the the array has non-zero size, Robert
+Klarer suggests in c++std-lib-16082 to change 27.6.1.3, p20 to read:
+
+        
    
+            
    
+
+In any case, provided (n > 0) is true, it then stores a null character
+(using charT()) into the next successive location of the array.
+
+            
    
+
+
    [
+post-Redmond:  Pete noticed that the current resolution for get requires
+writing to out of bounds memory when n == 0.  Martin provided fix.
+]
    
+
+
+
+
+
+
+
+
    
 
    533. typo in 2.2.3.10/1
    
-
    Section: 20.6.6.2.10 [util.smartptr.getdeleter], TR1 2.2.3.10 [tr.util.smartptr.getdeleter] Status: DR
+
    Section: 20.6.6.2.11 [util.smartptr.getdeleter], TR1 2.2.3.10 [tr.util.smartptr.getdeleter] Status: DR
  Submitter: Paolo Carlini Date: 2005-11-09
    
 
    View all other issues in [util.smartptr.getdeleter].
    
 
    View all issues with DR status.
    
@@ -20562,6 +20964,7 @@ 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
    
+
    View other active issues in [basic.string].
    
 
    View all other issues in [basic.string].
    
 
    View all issues with WP status.
    
 
    Discussion:
    
@@ -20743,7 +21146,6 @@ 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
    
-
    View other active issues in [istream.unformatted].
    
 
    View all other issues in [istream.unformatted].
    
 
    View all issues with WP status.
    
 
    Discussion:
    
@@ -20914,6 +21316,7 @@ definition) of the function shall be well-formed.
 
    541. shared_ptr template assignment and void
    
 
    Section: 20.6.6.2 [util.smartptr.shared], TR1 2.2.3 [tr.util.smartptr.shared] Status: WP
  Submitter: Martin Sebor Date: 2005-10-16
    
+
    View other active issues in [util.smartptr.shared].
    
 
    View all other issues in [util.smartptr.shared].
    
 
    View all issues with WP status.
    
 
    Discussion:
    
@@ -21129,7 +21532,7 @@ lengths, and strides, as explained in the previous section.
 
 
    
 
    545. When is a deleter deleted?
    
-
    Section: 20.6.6.2.10 [util.smartptr.getdeleter], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] Status: WP
+
    Section: 20.6.6.2.11 [util.smartptr.getdeleter], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] Status: WP
  Submitter: Matt Austern Date: 2006-01-10
    
 
    View all other issues in [util.smartptr.getdeleter].
    
 
    View all issues with WP status.
    
@@ -21147,7 +21550,7 @@ instances). We should say which it is.
 
 
    Proposed resolution:
    
 
    
-Add after the first sentence of 20.6.6.2.10 [util.smartptr.getdeleter]/1:
+Add after the first sentence of 20.6.6.2.11 [util.smartptr.getdeleter]/1:
 
    
 
    
 
    
@@ -21166,32 +21569,134 @@ This can happen if the implementation doesn't destroy the deleter until all
 
 
 
    
-
    559. numeric_limits<const T>
    
-
    Section: 18.2.1 [limits] Status: WP
- Submitter: Martin Sebor Date: 2006-02-19
    
-
    View all other issues in [limits].
    
+
    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.
    
 
    Discussion:
    
-        
    
+
    
+Previously xxx.h was parsable by C++.  But in the case of C99's <complex.h>
+it isn't.  Otherwise we could model it just like <string.h>, <cstring>, <string>:
+
    
 
-18.2.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
-<limits> header.
+
      
+
    • <string>   : C++ API in namespace std
      • 
+
    • <cstring>  : C API in namespace std
      • 
+
    • <string.h> : C API in global namespace
      • 
+
    
 
-        
    
-        
    
+
    
+In the case of C's complex, the C API won't compile in C++.  So we have:
+
    
 
-The absence  of specializations of the template  on cv-qualified forms
-of  fundamental types  makes numeric_limits  difficult to
-use in generic  code where the constness (or volatility)  of a type is
-not  always  immediately  apparent.  In  such  contexts,  the  primary
-template  ends   up  being   instantiated  instead  of   the  provided
-specialization, typically yielding unexpected behavior.
+
      
+
    • <complex>   : C++ API in namespace std
      • 
+
    • <ccomplex>  : ?
      • 
+
    • <complex.h> : ?
      • 
+
    
 
-        
    
-        
    
+
    
+The ? can't refer to the C API.  TR1 currently says:
+
    
+
+
      
+
    • <complex>   : C++ API in namespace std
      • 
+
    • <ccomplex>  : C++ API in namespace std
      • 
+
    • <complex.h> : C++ API in global namespace
      • 
+
    
+
+
+
+
    Proposed resolution:
    
+
    
+Change 26.3.11 [cmplxh]:
+
    
+
+
    
+
    
+The header behaves as if it includes the header
+<ccomplex>., and provides sufficient using
+declarations to declare in the global namespace all function and type names
+declared or defined in the neader <complex>.
+[Note: <complex.h> does not promote any interface
+into the global namespace as there is no C interface to promote. --end
+note]
+
    
+
    
+
+
+
+
+
+
+
    
+
    552. random_shuffle and its generator
    
+
    Section: 25.2.12 [alg.random.shuffle] Status: WP
+ Submitter: Martin Sebor Date: 2006-01-25
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+...is specified to shuffle its range by calling swap but not how
+(or even that) it's supposed to use the RandomNumberGenerator
+argument passed to it.
+
    
+
    
+Shouldn't we require that the generator object actually be used
+by the algorithm to obtain a series of random numbers and specify
+how many times its operator() should be invoked by the algorithm?
+
    
+
+
    
+See N2391 and
+N2423
+for some further discussion.
+
    
+
+
+
+
    Proposed resolution:
    
+
    
+Adopt the proposed resolution in
+N2423.
+
    
+
+
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]
    
+
+
+
+
+
+
    
+
    559. numeric_limits<const T>
    
+
    Section: 18.2.1 [limits] Status: WP
+ Submitter: Martin Sebor Date: 2006-02-19
    
+
    View all other issues in [limits].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+        
    
+
+18.2.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
+<limits> header.
+
+        
    
+        
    
+
+The absence  of specializations of the template  on cv-qualified forms
+of  fundamental types  makes numeric_limits  difficult to
+use in generic  code where the constness (or volatility)  of a type is
+not  always  immediately  apparent.  In  such  contexts,  the  primary
+template  ends   up  being   instantiated  instead  of   the  provided
+specialization, typically yielding unexpected behavior.
+
+        
    
+        
    
 
 Require   that  specializations   of   numeric_limits  on
 cv-qualified fundamental types have the same semantics as those on the
@@ -21241,6 +21746,78 @@ automatically.
 
 
 
    
+
    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
    
+
    View all other issues in [istream.unformatted].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+        
    
+
+The array forms of unformatted input functions don't have well-defined
+semantics for zero-element  arrays in a couple of  cases. The affected
+ones (istream::get() and  getline()) are supposed to
+terminate when (n - 1) characters are stored, which obviously
+can never be true when (n == 0) to start with.
+
+        
    
+
+
+
    Proposed resolution:
    
+        
    
+
+I  propose  the following  changes  (references  are  relative to  the
+Working Draft (document N1804).
+
+        
    
+        
    
+
+Change 27.6.1.3, p8 (istream::get()), bullet 1 as follows:
+
+        
    
+        
    
+            
    
+
+if  (n  < 1)  is  true  or   (n  -  1)
+characters are stored;
+
+            
    
+        
    
+        
    
+
+Similarly, change  27.6.1.3, p18 (istream::getline()), bullet
+3 as follows:
+
+        
    
+        
    
+            
    
+
+(n < 1) is  true or (n - 1) characters
+are     stored     (in    which     case     the    function     calls
+setstate(failbit)).
+
+            
    
+        
    
+        
    
+
+Finally, change p21 as follows:
+
+        
    
+        
    
+            
    
+
+In any  case, provided  (n > 0)  is true,  it then
+stores  a null  character  (using charT())  into  the next  successive
+location of the array.
+
+            
    
+        
    
+
+
+
+
+
+
    
 
    575. the specification of ~shared_ptr is MT-unfriendly, makes implementation assumptions
    
 
    Section: 20.6.6.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
    
@@ -21372,6 +21949,56 @@ 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.
    
+
    Discussion:
    
+
    
+ISO/IEC 14882:2003 says:
+
    
+
+
    
+
    
+25.3.3.2 upper_bound
+
    
+
    
+Returns: The furthermost iterator i in the range
+[first, last) such that
+for any iterator j in the range [first, i) the following corresponding
+conditions hold: !(value < *j) or comp(value, *j) == false.
+
    
+
    
+
+
    
+From the description above, upper_bound cannot return last, since it's
+not in the interval [first, last). This seems to be a typo, because if
+value is greater than or equal to any other values in the range, or if
+the range is empty, returning last seems to be the intended behaviour.
+The corresponding interval for lower_bound is also [first, last].
+
    
+
+
+
    Proposed resolution:
    
+
    
+Change [lib.upper.bound]:
+
    
+
+
    
+
    
+Returns: The furthermost iterator i in the range
+[first, last)] such that
+for any iterator j in the range [first, i) the following corresponding
+conditions hold: !(value < *j) or comp(value, *j) == false.
+
    
+
    
+
+
+
+
+
+
+
    
 
    578. purpose of hint to allocator::allocate()
    
 
    Section: 20.6.1.1 [allocator.members] Status: WP
  Submitter: Martin Sebor Date: 2006-05-17
    
@@ -21682,4 +22309,1976 @@ Change the Returns: clause in 3.2.2.4 to:
 Change the Returns: clause in 3.2.3.4 to:
 
    
 
    
-Returns: Returns the result of the conversion of *this to the type long long, as if performed by the expression llroundd64(*this) while the decimal rounding direction mode [3.5.2] FE_DEC_TOWARD_ZERO
    
\ No newline at end of file
+Returns: Returns the result of the conversion of *this to the type long long, as if performed by the expression llroundd64(*this) while the decimal rounding direction mode [3.5.2] FE_DEC_TOWARD_ZERO is in effect.
+
    
+
    
+Change the Returns: clause in 3.2.4.4 to:
+
    
+
    
+Returns: Returns the result of the conversion of *this to the type long long, as if performed by the expression llroundd64(*this) llroundd128(*this) while the decimal rounding direction mode [3.5.2] FE_DEC_TOWARD_ZERO is in effect.
+
    
+
+
+
+
+
+
+
    
+
    599. Decimal: Say "octets" instead of "bytes."
    
+
    Section: TRDecimal 3.1 [trdec.types.encodings] Status: TRDec
+ Submitter: Daniel Krugler Date: 2006-05-28
    
+
    View all issues with TRDec status.
    
+
    Discussion:
    
+
    
+Daniel writes in a private email:
+
    
+
+
    
+
    
+- 3.1 'Decimal type encodings' says in its note:
+
    
+
    "this implies that 
+sizeof(std::decimal::decimal32) == 4, 
+sizeof(std::decimal::decimal64) == 8, and 
+sizeof(std::decimal::decimal128) == 16."
+
    
+
    
+This is a wrong assertion, because the definition 
+of 'byte' in 1.7 'The C+ + memory model' of ISO 
+14882 (2nd edition) does not specify that a byte 
+must be necessarily 8 bits large, which would be 
+necessary to compare with the specified bit sizes 
+of the types decimal32, decimal64, and decimal128.
+
    
+
    
+
+
+
    Proposed resolution:
    
+
    
+Change 3.1 as follows:
+
    
+
    
+
    
+The three decimal encoding formats defined in IEEE-754R correspond to the three decimal floating types as follows:
+
    
+
      
+
    • 
+decimal32 is a decimal32 number, which is encoded in four consecutive bytes octets (32 bits)
+
      • 
+
    • 
+decimal64 is a decimal64 number, which is encoded in eight consecutive bytes octets (64 bits)
+
+
      • 
+
    • 
+decimal128 is a decimal128 number, which is encoded in 16 consecutive bytes octets (128 bits)
+
      • 
+
    
+
    
+[Note: this implies that sizeof(std::decimal::decimal32) == 4, sizeof(std::decimal::decimal64) == 8, and sizeof(std::decimal::decimal128) == 16.  --end note]
+
    
+
    
+
+
+
+
+
    
+
    600. Decimal: Wrong parameters for wcstod* functions
    
+
    Section: TRDecimal 3.9 [trdec.types.cwchar] Status: TRDec
+ Submitter: Daniel Krugler Date: 2006-05-28
    
+
    View all issues with TRDec status.
    
+
    Discussion:
    
+
    
+Daniel writes:
+
    
+
    
+- 3.9.1 'Additions to <cwchar>' provides wrong 
+signatures to the wcstod32, wcstod64, and 
+wcstod128 functions ([the parameters have type pointer-to-] char instead of wchar_t).
+
    
+
+
+
    Proposed resolution:
    
+
    
+Change "3.9.1 Additions to <cwchar> synopsis" to:
+
    
+
           namespace std {
+       namespace decimal {
+         // 3.9.2 wcstod functions:
+         decimal32  wcstod32  (const char wchar_t * nptr, char wchar_t ** endptr);
+         decimal64  wcstod64  (const char wchar_t * nptr, char wchar_t ** endptr);
+         decimal128 wcstod128 (const char wchar_t * nptr, char wchar_t ** endptr);
+       }
+       }
+
    
+
+
+
+
+
    
+
    601. Decimal: numeric_limits typos
    
+
    Section: TRDecimal 3.3 [trdec.types.limits] Status: TRDec
+ Submitter: Daniel Krugler Date: 2006-05-28
    
+
    View all issues with TRDec status.
    
+
    Discussion:
    
+
    
+Daniel writes in a private email:
+
    
+
+
    
+
    
+- 3.3 'Additions to header <limits>' contains two 
+errors in the specialisation of numeric_limits<decimal::decimal128>:
+
    
+
      
+
    1. The static member max() returns DEC128_MIN, this should be DEC128_MAX.
      2. 
+
    2. The static member digits is assigned to 384,
+this should be 34 (Probably mixed up with the
+max. exponent for decimal::decimal64).
      3. 
+
    
+
    
+
+
+
    Proposed resolution:
    
+
    
+In "3.3 Additions to header <limits>" change numeric_limits<decimal::decimal128> as follows:
+
    
+
            template<> class numeric_limits<decimal::decimal128> {
+          public:
+            static const bool is_specialized = true;
+
+            static decimal::decimal128 min() throw() { return DEC128_MIN; }
+            static decimal::decimal128 max() throw() { return DEC128_MIN; DEC128_MAX; }
+
+            static const int digits       = 384 34;
+            /* ... */
+
    
+
+
+
+
+
    
+
    602. Decimal: "generic floating type" not defined.
    
+
    Section: TRDecimal 3 [trdec.types] Status: TRDec
+ Submitter: Daniel Krugler Date: 2006-05-28
    
+
    View all other issues in [trdec.types].
    
+
    View all issues with TRDec status.
    
+
    Discussion:
    
+
    
+The document uses the term "generic floating types," but defines it nowhere.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Change the first paragraph of "3 Decimal floating-point types" as follows:
+
    
+
    
+This Technical Report introduces three decimal floating-point types, named
+decimal32, decimal64, and decimal128. The set of values of type decimal32 is a
+subset of the set of values of type decimal64; the set of values of the type
+decimal64 is a subset of the set of values of the type decimal128. Support for
+decimal128 is optional.  These types supplement the Standard C++ types
+float, double, and long double, which are
+collectively described as the basic floating types.
+
    
+
+
+
+
+
    
+
    603. Decimal: Trivially simplifying decimal classes.
    
+
    Section: TRDecimal 3 [trdec.types] Status: TRDec
+ Submitter: Martin Sebor Date: 2006-05-28
    
+
    View all other issues in [trdec.types].
    
+
    View all issues with TRDec status.
    
+
    Discussion:
    
+
    In c++std-lib-17198, Martin writes:
    
+
+
    
+Each of the three classes proposed in the paper (decimal32, decimal64,
+and decimal128) explicitly declares and specifies the semantics of its
+copy constructor, copy assignment operator, and destructor. Since the
+semantics of all three functions are identical to the trivial versions
+implicitly generated by the compiler in the absence of any declarations
+it is safe to drop them from the spec. This change would make the
+proposed classes consistent with other similar classes already in the
+standard (e.g., std::complex).
+
    
+
+
+
    Proposed resolution:
    
+
    
+Change "3.2.2 Class decimal32" as follows:
+
    
+
          namespace std {
+      namespace decimal {
+        class decimal32 {
+          public:
+            // 3.2.2.1 construct/copy/destroy:
+            decimal32();
+            decimal32(const decimal32 & d32);
+            decimal32 & operator=(const decimal32 & d32);
+            ~decimal32();
+            /* ... */
+
    
+
    
+Change "3.2.2.1 construct/copy/destroy" as follows:
+
    
+
            decimal32();
+
+    Effects: Constructs an object of type decimal32 with the value 0;
+
+        decimal32(const decimal32 & d32);
+        decimal32 & operator=(const decimal32 & d32);
+
+    Effects: Copies an object of type decimal32.
+
+        ~decimal32();
+
+    Effects: Destroys an object of type decimal32.
+
+
    
+
    
+Change "3.2.3 Class decimal64" as follows:
+
    
+
          namespace std {
+      namespace decimal {
+        class decimal64 {
+          public:
+            // 3.2.3.1 construct/copy/destroy:
+            decimal64();
+            decimal64(const decimal64 & d64);
+            decimal64 & operator=(const decimal64 & d64);
+            ~decimal64();
+            /* ... */
+
    
+
    
+Change "3.2.3.1 construct/copy/destroy" as follows:
+
    
+
            decimal64();
+
+    Effects: Constructs an object of type decimal64 with the value 0;
+
+        decimal64(const decimal64 & d64);
+        decimal64 & operator=(const decimal64 & d64);
+
+    Effects: Copies an object of type decimal64.
+
+        ~decimal64();
+
+    Effects: Destroys an object of type decimal64.
+
+
    
+
    
+Change "3.2.4 Class decimal128" as follows:
+
    
+
          namespace std {
+      namespace decimal {
+        class decimal128 {
+          public:
+            // 3.2.4.1 construct/copy/destroy:
+            decimal128();
+            decimal128(const decimal128 & d128);
+            decimal128 & operator=(const decimal128 & d128);
+            ~decimal128();
+            /* ... */
+
    
+
    
+Change "3.2.4.1 construct/copy/destroy" as follows:
+
    
+
            decimal128();
+
+    Effects: Constructs an object of type decimal128 with the value 0;
+
+        decimal128(const decimal128 & d128);
+        decimal128 & operator=(const decimal128 & d128);
+
+    Effects: Copies an object of type decimal128.
+
+        ~decimal128();
+
+    Effects: Destroys an object of type decimal128.
+
+
    
+
+
+
+
+
    
+
    604. Decimal: Storing a reference to a facet unsafe.
    
+
    Section: TRDecimal 3 [trdec.types] Status: TRDec
+ Submitter: Martin Sebor Date: 2006-05-28
    
+
    View all other issues in [trdec.types].
    
+
    View all issues with TRDec status.
    
+
    Discussion:
    
+
    
+In c++std-lib-17197, Martin writes:
+
    
+
    
+The extended_num_get and extended_num_put facets are designed
+to store a reference to a num_get or num_put facet which the
+extended facets delegate the parsing and formatting of types
+other than decimal. One form of the extended facet's ctor (the
+default ctor and the size_t overload) obtains the reference
+from the global C++ locale while the other form takes this
+reference as an argument.
+
    
+
    
+The problem with storing a reference to a facet in another
+object (as opposed to storing the locale object in which the
+facet is installed) is that doing so bypasses the reference
+counting mechanism designed to prevent a facet that is still
+being referenced (i.e., one that is still installed in some
+locale) from being destroyed when another locale that contains
+it is destroyed. Separating a facet reference from the locale
+it comes from van make it cumbersome (and in some cases might
+even make it impossible) for programs to prevent invalidating
+the reference. (The danger of this design is highlighted in
+the paper.)
+
    
+
    
+This problem could be easily avoided by having the extended
+facets store a copy of the locale from which they would extract
+the base facet either at construction time or when needed. To
+make it possible, the forms of ctors of the extended facets that
+take a reference to the base facet would need to be changed to
+take a locale argument instead.
+
    
+
+
+
    Proposed resolution:
    
+
    
+1. Change the extended_num_get synopsis in 3.10.2 as follows:
+
    
+
                extended_num_get(const std::num_get<charT, InputIterator> std::locale & b, size_t refs = 0);
+
+            /* ... */
+
+            // const std::num_get<charT, InputIterator> & base;        exposition only
+            // std::locale baseloc;                                    exposition only
+
    
+
    
+2. Change the description of the above constructor in 3.10.2.1:
+
    
+
                extended_num_get(const std::num_get<charT, InputIterator> std::locale & b, size_t refs = 0);
+
+
    
+
    
+
    
+Effects: Constructs an extended_num_get facet as if by:
+
    
+
           extended_num_get(const std::num_get<charT, InputIterator> std::locale & b, size_t refs = 0)
+                : facet(refs), baseloc(b)
+                { /* ... */ }
+
+
    
+
    
+Notes: Care must be taken by the implementation to ensure that the lifetime of the facet referenced by base exceeds that of the resulting extended_num_get facet.
+
    
+
    
+
    
+3. Change the Returns: clause for do_get(iter_type, iter_type, ios_base &, ios_base::iostate &, bool &) const, et al to
+
    
+
    
+Returns: base std::use_facet<std::num_get<charT, InputIterator> >(baseloc).get(in, end, str, err, val). 
+
    
+
    
+4. Change the extended_num_put synopsis in 3.10.3 as follows:
+
    
+
                extended_num_put(const std::num_put<charT, OutputIterator> std::locale & b, size_t refs = 0);
+
+            /* ... */
+
+            // const std::num_put<charT, OutputIterator> & base;       exposition only
+            // std::locale baseloc;                                    exposition only
+
    
+
    
+5. Change the description of the above constructor in 3.10.3.1:
+
    
+
                extended_num_put(const std::num_put<charT, OutputIterator> std::locale & b, size_t refs = 0);
+
    
+
    
+
    
+Effects: Constructs an extended_num_put facet as if by:
+
    
+
           extended_num_put(const std::num_put<charT, OutputIterator> std::locale & b, size_t refs = 0)
+                : facet(refs), baseloc(b)
+                { /* ... */ }
+
+
    
+
    
+Notes: Care must be taken by the implementation to ensure that the lifetime of the facet referenced by base exceeds that of the resulting extended_num_put facet.
+
    
+
    
+
    
+6. Change the Returns: clause for do_put(iter_type, ios_base &, char_type, bool &) const, et al to
+
    
+
    
+Returns: base std::use_facet<std::num_put<charT, OutputIterator> >(baseloc).put(s, f, fill, val). 
+
    
+
+
    [
+Redmond:  We would prefer to rename "extended" to "decimal".
+]
    
+
+
+
+
+
+
+
    
+
    605. Decimal: <decfloat.h> doesn't live here anymore.
    
+
    Section: TRDecimal 3.4 [trdec.types.cdecfloat] Status: TRDec
+ Submitter: Robert Klarer Date: 2006-10-17
    
+
    View all issues with TRDec status.
    
+
    Discussion:
    
+
    
+In Berlin, WG14 decided to drop the <decfloat.h> header. The
+contents of that header have been moved into <float.h>. For the
+sake of C compatibility, we should make corresponding changes.
+
    
+
+
+
    Proposed resolution:
    
+
    
+1. Change the heading of subclause 3.4, "Headers <cdecfloat> and <decfloat.h>" to "Additions to headers <cfloat> and <float.h>."
+
    
+
    
+2. Change the text of subclause 3.4 as follows:
+
    
+
    
+
    
+The standard C++ headers <cfloat> and <float.h> define characteristics of the floating-point types float, double, and long double.  Their contents remain unchanged by this Technical Report.
+
    
+
    
+Headers <cdecfloat> and <decfloat.h> define characteristics of the decimal floating-point types decimal32, decimal64, and decimal128.  As well, <decfloat.h> defines the convenience typedefs _Decimal32, _Decimal64, and _Decimal128, for compatibilty with the C programming language.
+
    
+
    
+The header <cfloat> is described in [tr.c99.cfloat].  The header <float.h>
+is described in [tr.c99.floath]. These headers are extended by this
+Technical Report to define characteristics of the decimal
+floating-point types decimal32, decimal64, and decimal128.  As well, <float.h> is extended to define the convenience typedefs _Decimal32, _Decimal64, and _Decimal128 for compatibility with the C programming language.
+
    
+
    
+
    
+3. Change the heading of subclause 3.4.1, "Header <cdecfloat> synopsis"  to "Additions to header <cfloat> synopsis."
+
    
+
    
+4. Change the heading of subclause 3.4.2, "Header <decfloat.h> synopsis" to "Additions to header <float.h> synopsis."
+
    
+
    
+5. Change the contents of 3.4.2 as follows:
+
    
+
          #include <cdecfloat>
+
+      // C-compatibility convenience typedefs:
+
+      typedef std::decimal::decimal32  _Decimal32;
+      typedef std::decimal::decimal64  _Decimal64;
+      typedef std::decimal::decimal128 _Decimal128;
+
    
+
+
+
+
+
+
    
+
    607. Concern about short seed vectors
    
+
    Section: 26.4.7.1 [rand.util.seedseq] Status: Pending WP
+ Submitter: Charles Karney Date: 2006-10-26
    
+
    View all other issues in [rand.util.seedseq].
    
+
    View all issues with Pending WP status.
    
+
    Discussion:
    
+
    
+Short seed vectors of 32-bit quantities all result in different states. However
+this is not true of seed vectors of 16-bit (or smaller) quantities.  For example
+these two seeds
+
    
+
+
    unsigned short seed = {1, 2, 3};
+unsigned short seed = {1, 2, 3, 0};
+
    
+
+
    
+both pack to
+
    
+
+
    unsigned seed = {0x20001, 0x3};
+
    
+
+
    
+yielding the same state.
+
    
+
+
    
+See N2391 and
+N2423
+for some further discussion.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Adopt the proposed resolution in
+N2423.
+
    
+
+
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]
    
+
+
+
+
+
+
    
+
    608. Unclear seed_seq construction details
    
+
    Section: 26.4.7.1 [rand.util.seedseq] Status: Pending WP
+ Submitter: Charles Karney Date: 2006-10-26
    
+
    View all other issues in [rand.util.seedseq].
    
+
    View all issues with Pending WP status.
    
+
    Discussion:
    
+
    
+In 26.4.7.1 [rand.util.seedseq] /6, the order of packing the inputs into b and the
+treatment of signed quantities is unclear. Better to spell it out.
+
    
+
+
    
+See N2391 and
+N2423
+for some further discussion.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Adopt the proposed resolution in
+N2423.
+
    
+
+
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]
    
+
+
+
+
+
+
    
+
    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.
    
+
    Discussion:
    
+
    
+In preparing N2111, an error on my part resulted in the omission of the
+following line from the template synopsis in the cited section:
+
    
+
+
    static const size_t word_size = w;
+
    
+
+
    
+(This same constant is found, for example, in 26.4.3.3 [rand.eng.sub].)
+
    
+
+
+
    Proposed resolution:
    
+
    
+Add the above declaration as the first line after the comment in [rand.adapt.ibits] p4:
+
    
+
+
    // engine characteristics
+static const size_t word_size = w;
+
    
+
+
    
+and accept my apologies for the oversight.
+
    
+
+
+
+
+
+
    
+
    610. Suggested non-normative note for C++0x
    
+
    Section: 20.5.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.
    
+
    Discussion:
    
+
    
+My suggestion is that implementers of both tr1::function and its 
+official C++0x successor be explicitly encouraged (but not required) to 
+optimize for the cases mentioned above, i.e., function pointers and 
+small function objects.  They could do this by using a small internal 
+buffer akin to the buffer used by implementations of the small string 
+optimization.  (That would make this the small functor optimization -- 
+SFO :-})  The form of this encouragement could be a note in the standard 
+akin to footnote 214 of the current standard.
+
    
+
+
    
+Dave Abrahams notes:
+
    
+
+
    
+"shall not throw exceptions" should really be "nothing," both to be more
+grammatical and to be consistent with existing wording in the standard.
+
    
+
+
    
+Doug Gregor comments: I think this is a good idea. Currently, implementations of
+tr1::function are required to have non-throwing constructors and assignment
+operators when the target function object is a function pointer or a
+reference_wrapper. The common case, however, is for a tr1::function to store
+either an empty function object or a member pointer + an object pointer.
+
    
+
    
+The function implementation in the upcoming Boost 1.34.0 uses the
+"SFO", so that the function objects for typical bind expressions like
+
    
+
    bind(&X::f, this, _1, _2, _3)
+
    
+
+
    
+do not require heap allocation when stored in a boost::function. I
+believe Dinkumware's implementation also performs this optimization.
+
    
+
+
+
+
    Proposed resolution:
    
+
    
+Revise 20.5.14.2.1 p6 [func.wrap.func.con] to add a note as follows:
+
    
+
+
    
+
    
+Throws: shall not throw exceptions if f's target is a function
+pointer or a function object passed via reference_wrapper. Otherwise,
+may throw bad_alloc or any exception thrown by the copy constructor of
+the stored function object.
+
    
+
    
+Note: Implementations are encouraged to avoid the use of dynamically
+allocated memory for "small" function objects, e.g., where f's target
+is an object holding only a pointer or reference to an object and a member
+function pointer (a "bound member function").
+
    
+
    
+
+
+
+
+
+
    
+
    611. Standard library templates and incomplete types
    
+
    Section: 17.4.3.6 [res.on.functions] Status: WP
+ Submitter: Nicola Musatti Date: 2006-11-13
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+In the latest available draft standard 
+(N2134)
+§ 17.4.3.6 [res.on.functions] states:
+
    
+
+
    
+
    
+-1- In certain cases (replacement functions, handler functions, operations on
+types used to instantiate standard library template components), the C++
+Standard Library depends on components supplied by a C++ program. If these
+components do not meet their requirements, the Standard places no requirements
+on the implementation.
+
    
+
+
    
+-2- In particular, the effects are undefined in the following cases:
+
    
+
    
+[...]
+
    
+
      
+
    • if an incomplete type (3.9) is used as a template argument when
+instantiating a template component. 
      • 
+
    
+
    
+
+
    
+This is contradicted by § 20.6.6.2/2 [util.smartptr.shared] which
+states:
+
    
+
+
    
+
    
+[...]
+
    
+
+
    
+The template parameter T of shared_ptr may be an incomplete type.
+
    
+
    
+
+
+
    Proposed resolution:
    
+
    
+Modify the last bullet of § 17.4.3.6/2 [res.on.functions] to allow for
+exceptions:
+
    
+
+
    
+
      
+
    • if an incomplete type (3.9) is used as a template argument when
+instantiating a template component, unless specifically allowed for the
+component. 
      • 
+
    
+
    
+
+
+
+
+
+
+
    
+
    613. max_digits10 missing from numeric_limits
    
+
    Section: 18.2.1.5 [numeric.special] Status: WP
+ Submitter: Bo Persson Date: 2006-11-20
    
+
    View all other issues in [numeric.special].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+Section 18.2.1.5 [numeric.special] starts out by saying that "All members shall be provided 
+for all specializations."
+
    
+
    
+Then it goes on to show specializations for float and bool, where one member 
+is missing (max_digits10).
+
    
+
+
    
+Maarten Kronenburg adds:
+
    
+
+
    
+I agree, just adding the comment that the exact number of decimal digits
+is digits * ln(radix) / ln(10), where probably this real number is
+rounded downward for digits10, and rounded upward for max_digits10
+(when radix=10, then digits10=max_digits10).
+Why not add this exact definition also to the standard, so the user
+knows what these numbers exactly mean.
+
    
+
+
    
+Howard adds:
+
    
+
+
    
+For reference, here are the correct formulas from
+N1822:
+
    
+
+
    digits10 = floor((digits-1) * log10(2))
+max_digits10 = ceil((1 + digits) * log10(2))
+
    
+
+
    
+We are also missing a statement regarding for what specializations this member has meaning.
+
    
+
+
+
+
    Proposed resolution:
    
+
    
+Change and add after 18.2.1.2 [numeric.limits.members], p11:
+
    
+
+
    
+
    static const int max_digits10;
    
+
    
+
    
+-11- Number of base 10 digits required to ensure that values which
+differ by only one epsilon are always differentiated.
+
    
+
    
+-12- Meaningful for all floating point types.
+
    
+
    
+
    
+
+
    
+Change 18.2.1.5 [numeric.special], p2:
+
    
+
+
    template<> class numeric_limits<float> { 
+public: 
+  static const bool is_specialized = true; 
+  ...
+  static const int digits10 = 6;
+  static const int max_digits10 = 9;
+  ...
+
    
+
+
    
+Change 18.2.1.5 [numeric.special], p3:
+
    
+
+
    template<> class numeric_limits<bool> { 
+public: 
+  static const bool is_specialized = true; 
+  ...
+  static const int digits10 = 0;
+  static const int max_digits10 = 0;
+  ...
+
    
+
+
+
+
+
+
+
+
    
+
    616. missing 'typename' in ctype_byname
    
+
    Section: 22.2.1.2 [locale.ctype.byname] Status: WP
+ Submitter: Bo Persson Date: 2006-12-16
    
+
    View all other issues in [locale.ctype.byname].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+Section 22.2.1.2 defines the ctype_byname class template. It contains the 
+line
+
    
+
+
    typedef ctype<charT>::mask   mask;
+
    
+
+
+
+
    Proposed resolution:
    
+
    
+as this is a dependent type, it should obviously be
+
    
+
+
    typedef typename ctype<charT>::mask   mask;
+
    
+
+
+
+
+
+
    
+
    619. Longjmp wording problem
    
+
    Section: 18.8 [support.runtime] Status: WP
+ Submitter: Lawrence Crowl Date: 2007-01-12
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+The wording for longjmp is confusing.
+
    
+
    
+18.8 [support.runtime] -4- Other runtime support
+
    
+
    
+The function signature longjmp(jmp_buf jbuf, int val) has more restricted
+behavior in this International Standard.  If any automatic objects would
+be destroyed by a thrown exception transferring control to another
+(destination) point in the program, then a call to longjmp(jbuf, val) that
+the throw point that transfers control to the same (destination) point has
+undefined behavior.
+
    
+
    
+Someone at Google thinks that should say "then a call to longjmp(jbuf, val)
+*at* the throw point that transfers control".
+
    
+
    
+Bill Gibbons thinks it should say something like "If any automatic objects
+would be destroyed by an exception thrown at the point of the longjmp and
+caught only at the point of the setjmp, the behavior is undefined."
+
    
+
+
+
    Proposed resolution:
    
+
    
+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.8 [support.runtime] paragraph 4, change
+
    
+
+
    
+The function signature longjmp(jmp_buf jbuf, int val) has more
+restricted behavior in this International Standard.  If any automatic
+objects would be destroyed by a thrown exception transferring control to another
+(destination) point in the program, then a call to longjmp(jbuf, val)
+that the throw point that transfers control to the same (destination) point has
+undefined behavior. A setjmp/longjmp call pair has
+undefined behavior if replacing the setjmp and longjmp by
+catch and throw would destroy any automatic objects.
+
    
+
+
+
+
+
+
    
+
    628. Inconsistent definition of basic_regex constructor
    
+
    Section: 28.8 [re.regex] Status: WP
+ Submitter: Bo Persson Date: 2007-01-23
    
+
    View all other issues in [re.regex].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+Section 28.8 [re.regex] lists a constructor
+
    
+
+
    template<class InputIterator>
+basic_regex(InputIterator first, InputIterator last,
+                       flag_type f = regex_constants::ECMAScript);
+
    
+
+
    
+However, in section 28.8.2 [re.regex.construct], this constructor takes a 
+pair of ForwardIterator.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Change 28.8.2 [re.regex.construct]:
+
    
+
+
    template <class ForwardIterator InputIterator>
+  basic_regex(ForwardIterator InputIterator first, ForwardIterator InputIterator last, 
+              flag_type f = regex_constants::ECMAScript);
+
    
+
+
+
+
+
+
+
    
+
    634. allocator.address() doesn't work for types overloading operator&
    
+
    Section: 20.6.1.1 [allocator.members] Status: WP
+ Submitter: Howard Hinnant Date: 2007-02-07
    
+
    View all other issues in [allocator.members].
    
+
    View all issues with WP status.
    
+
    Duplicate of: 350
    
+
    Discussion:
    
+
+
    
+20.6.1.1 [allocator.members] says:
+
    
+
    
+
    pointer address(reference x) const;
    
+
    
+
    
+-1- Returns: &x.
+
    
+
    
+
    
+
+
    
+20.6.1.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
+that we should disallow overloading operator& to return something other
+than the address of *this.
+
    
+
+
    
+An example of when you want to overload operator& to return something
+other than the object's address is proxy references such as vector<bool>
+(or its replacement, currently code-named bit_vector).  Taking the address of
+such a proxy reference should logically yield a proxy pointer, which when dereferenced,
+yields a copy of the original proxy reference again.
+
    
+
+
    
+On the other hand, some code truly needs the address of an object, and not a proxy
+(typically for determining the identity of an object compared to a reference object).
+boost has long recognized this dilemma and solved it with 
+boost::addressof.
+It appears to me that this would be useful functionality for the default allocator.  Adopting
+this definition for allocator::address would free the standard of requiring
+anything special from types which overload operator&.  Issue 580
+is expected to make use of allocator::address mandatory for containers.
+
    
+
+
+
+
    Proposed resolution:
    
+
    
+Change 20.6.1.1 [allocator.members]:
+
    
+
+
    
+
    pointer address(reference x) const;
    
+
    
+
    
+-1- Returns: &x. The actual address of object referenced by x,
+even in the presence of an overloaded operator&.
+
    
+
    
+
+
    const_pointer address(address(const_reference x) const;
    
+
    
+
    
+-2- Returns: &x. The actual address of object referenced by x,
+even in the presence of an overloaded operator&.
+
    
+
    
+
    
+
+
    [
+post Oxford:  This would be rendered NAD Editorial by acceptance of
+N2257.
+]
    
+
+
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which
+was subsequently split out into a separate paper N2436 for the purposes of voting.
+The resolution in N2436 addresses this issue.  The LWG voted to accelerate this
+issue to Ready status to be voted into the WP at Kona.
+]
    
+
+
+
+
+
+
+
+
    
+
    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
    
+
    View all other issues in [ostream.inserters.arithmetic].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+The arithmetic inserters are described in 27.6.2.6.2 [ostream.inserters.arithmetic].
+Although the section starts with a listing of the inserters including
+the new ones:
+
    
+
+
    operator<<(long long val );
+operator<<(unsigned long long val );
+
    
+
+
    
+the text in paragraph 1, which describes the corresponding effects
+of the inserters, depending on the actual type of val, does not
+handle the types long long and unsigned long long.
+
    
+
+
    [
+Alisdair: In addition to the (unsigned) long long problem, that whole paragraph
+misses any reference to extended integral types supplied by the
+implementation - one of the additions by core a couple of working papers
+back.
+]
    
+
+
+
+
+
    Proposed resolution:
    
+
    
+In 27.6.2.6.2 [ostream.inserters.arithmetic]/1 change the third sentence
+
    
+
+
    
+When val is of type bool, long, unsigned
+long, long long, unsigned long long, double,
+long double, or const void*, the formatting conversion
+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.
    
+
    Discussion:
    
+
    
+The current standard 14882:2003(E) as well as N2134 have the
+following
+defects:
+
    
+
+
    
+27.8.1.1 [filebuf]/5 says:
+
    
+
+
    
+
    
+In order to support file I/O and multibyte/wide character conversion, conversions are performed using members of a 
+facet, referred to as a_codecvt in following sections, obtained "as if" by
+
    
+
    codecvt<charT,char,typename traits::state_type> a_codecvt =
+  use_facet<codecvt<charT,char,typename traits::state_type> >(getloc());
+
    
+
    
+
+
    
+use_facet returns a const facet reference and no facet is
+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.
+
    
+
+
+
    Proposed resolution:
    
+
    
+In 27.8.1.1 [filebuf]/5 change the "as if" code
+
    
+
+
    const codecvt<charT,char,typename traits::state_type>& a_codecvt =
+  use_facet<codecvt<charT,char,typename traits::state_type> >(getloc());
+
    
+
+
    
+In 22.2.2.2.2 [facet.num.put.virtuals]/15 (This is para 5 in N2134) change
+
    
+
+
    
+
    
+A local variable punct is initialized via
+
    
+
    const numpunct<charT>& punct = use_facet< numpunct<charT> >(str.getloc() );
+
    
+
    
+
+
    
+(Please note also the additional provided trailing semicolon)
+
    
+
+
+
+
+
+
+
    
+
    644. Possible typos in 'function' description
    
+
    Section: X [func.wrap.func.undef] Status: Pending WP
+ Submitter: Bo Persson Date: 2007-02-25
    
+
    View all issues with Pending WP status.
    
+
    Discussion:
    
+
    
+X [func.wrap.func.undef]
+
    
+
    
+The note in paragraph 2 refers to 'undefined void operators', while the 
+section declares a pair of operators returning bool.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Change 20.5.15.2 [func.wrap.func]
+
    
+
+
    ...
+private:
+   // X [func.wrap.func.undef], 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]
+
    
+
+
    template<class Function2> bool void operator==(const function<Function2>&);
+template<class Function2> bool void operator!=(const function<Function2>&);
+
    
+
+
+
+
+
+
    
+
    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.
    
+
    Discussion:
    
+
    
+28.10.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.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Add the missing const specifier to both format overloads described
+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
    
+
    View all other issues in [re.tokiter].
    
+
    View all issues with WP 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
+[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).
+
    
+
+
+
    Proposed resolution:
    
+
    
+1) In (28.12.2 [re.tokiter]/6) change the current declarations
+
    
+
+
    bool operator==(const regex_token_iterator&) const;
+bool operator!=(const regex_token_iterator&) const;
+const value_type& operator*() const;
+const value_type* operator->() const;
+
    
+
+
    
+2) In 28.12.2.2 [re.tokiter.comp] change the following declarations
+
    
+
+
    bool operator==(const regex_token_iterator& right) const;
+bool operator!=(const regex_token_iterator& right) const;
+
    
+
+
    
+3) In 28.12.2.3 [re.tokiter.deref] change the following declarations
+
    
+
+
    const value_type& operator*() const;
+const value_type* operator->() const;
+
    
+
+
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
+is to adopt the proposed wording in this issue).
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]
    
+
+
+
+
+
+
    
+
    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
    
+
    View all other issues in [re.tokiter.cnstr].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+The text provided in 28.12.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
+the notion of a "current match" by saying:
+
    
+
+
    
+The current match is (*position).prefix() if subs[N]
+== -1, or (*position)[subs[N]] for any other value of
+subs[N].
+
    
+
+
    
+It's not clear to me, whether other negative values except -1
+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:
+
    
+
+
    
+Requires: Each of the initialization values of subs must be >= -1.
+
    
+
+
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
+is to adopt the proposed wording in this issue).
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]
    
+
+
+
+
+
+
    
+
    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.
    
+
    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)
+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).
+
    
+
+
+
    Proposed resolution:
    
+
    
+1) In (28.12.1 [re.regiter]/1) change the current declarations
+
    
+
+
    bool operator==(const regex_iterator&) const;
+bool operator!=(const regex_iterator&) const;
+const value_type& operator*() const;
+const value_type* operator->() const;
+
    
+
+
    
+2) In 28.12.1.3 [re.regiter.deref] change the following declarations
+
    
+
+
    const value_type& operator*() const;
+const value_type* operator->() const;
+
    
+
+
    
+3) In 28.12.1.2 [re.regiter.comp] change the following declarations
+
    
+
+
    bool operator==(const regex_iterator& right) const;
+bool operator!=(const regex_iterator& right) const;
+
    
+
+
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
+is to adopt the proposed wording in this issue).
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]
    
+
+
+
+
+
+
    
+
    654. Missing IO roundtrip for random number engines
    
+
    Section: 26.4.1.3 [rand.req.eng] Status: Pending WP
+ Submitter: Daniel Krügler Date: 2007-03-08
    
+
    View all other issues in [rand.req.eng].
    
+
    View all issues with Pending WP status.
    
+
    Discussion:
    
+
    
+Table 98 and para 5 in 26.4.1.3 [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
+from para 5:
+
    
+
+
    
+If a textual representation written via os << x was
+subsequently read via is >> v, then x == v provided that
+there have been no intervening invocations of x or of v.
+
    
+
+
    
+The problem is, that the extraction process described in
+table 98 misses to specify that it will initially set the
+if.fmtflags to ios_base::dec, see table 104:
+
    
+
+
    
+dec: converts integer input or generates integer output
+in decimal base
+
    
+
+
    
+Proof: The following small program demonstrates the violation
+of requirements (exception safety not fulfilled):
+
    
+
+
    #include <cassert>
+#include <ostream>
+#include <iostream>
+#include <iomanip>
+#include <sstream>
+
+class RanNumEngine {
+  int state;
+public:
+  RanNumEngine() : state(42) {}
+
+  bool operator==(RanNumEngine other) const {
+	  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;
+  }
+
+  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;
+  }
+};
+
+int main() {
+	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
+}
+
    
+
+
    
+A second, minor issue seems to be, that the insertion
+description from table 98 unnecessarily requires the
+addition of ios_base::fixed (which only influences floating-point
+numbers). Its not entirely clear to me whether the proposed
+standard does require that the state of random number engines
+is stored in integral types or not, but I have the impression
+that this is the indent, see e.g. p. 3
+
    
+
+
    
+The specification of each random number engine defines the
+size of its state in multiples of the size of its result_type.
+
    
+
+
    
+If other types than integrals are supported, then I wonder why
+no requirements are specified for the precision of the stream.
+
    
+
+
    
+See N2391 and
+N2423
+for some further discussion.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Adopt the proposed resolution in
+N2423.
+
    
+
+
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]
    
+
+
+
+
+
+
    
+
    655. Signature of generate_canonical not useful
    
+
    Section: 26.4.7.2 [rand.util.canonical] Status: Pending WP
+ Submitter: Daniel Krügler Date: 2007-03-08
    
+
    View all other issues in [rand.util.canonical].
    
+
    View all issues with Pending WP status.
    
+
    Discussion:
    
+
    
+In 26.4.2 [rand.synopsis] we have the declaration
+
    
+
+
    template<class RealType, class UniformRandomNumberGenerator,
+  size_t bits>
+result_type generate_canonical(UniformRandomNumberGenerator& g);
+
    
+
+
    
+Besides the "result_type" issue (already recognized by Bo Persson
+at Sun, 11 Feb 2007 05:26:47 GMT in this group) it's clear, that
+the template parameter order is not reasonably choosen: Obviously
+one always needs to specify all three parameters, although usually
+only two are required, namely the result type RealType and the
+wanted bits, because UniformRandomNumberGenerator can usually
+be deduced.
+
    
+
+
    
+See N2391 and
+N2423
+for some further discussion.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Adopt the proposed resolution in
+N2423.
+
    
+
+
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]
    
+
+
+
+
+
+
    
+
    660. Missing Bitwise Operations
    
+
    Section: 20.5 [function.objects] Status: WP
+ Submitter: Beman Dawes Date: 2007-04-02
    
+
    View all other issues in [function.objects].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    Section 20.5 [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 
+were discussed. Bjarne Stroustrup commented "Why standardize what isn't used? 
+Yes, I see the chicken and egg problems here, but it would be nice to see a 
+couple of genuine uses before making additions."
    
+
    A number of libraries, including Rogue Wave, GNU, Adobe ASL, and Boost, have 
+already added these functions, either publicly or for internal use. For example, 
+Doug Gregor commented: "Boost will also add ... (|, &, ^) in 1.35.0, because we 
+need those function
+objects to represent various parallel 
+collective operations (reductions, prefix reductions, etc.) in the new Message 
+Passing Interface (MPI) library."
    
+
    Because the bitwise operators have the strongest use cases, the proposed 
+resolution is limited to them.
    
+
+
+
    Proposed resolution:
    
+
    To 20.5 [function.objects], Function objects, paragraph 2, add to the header 
+<functional> synopsis:
    
+
    
+  
    template <class T> struct bit_and;
+template <class T> struct bit_or;
+template <class T> struct bit_xor;
    
+
    
+
    At a location in clause 20 to be determined by the Project Editor, add:
    
+
    
+  
    The library provides basic function object classes for all of the bitwise 
+  operators in the language ([expr.bit.and], [expr.or], [exp.xor]).
    
+  
    template <class T> struct bit_and : binary_function<T,T,T> {
+  T operator()(const T& x , const T& y ) const;
+};
    
+  
    
+    
    operator() returns x & y .
    
+  
    
+  
    template <class T> struct bit_or : binary_function<T,T,T> {
+  T operator()(const T& x , const T& y ) const;
+};
    
+  
    
+    
    operator() returns x | y .
    
+  
    
+  
    template <class T> struct bit_xor : binary_function<T,T,T> {
+  T operator()(const T& x , const T& y ) const;
+};
    
+  
    
+    
    operator() returns x ^ y .
    
+  
    
+
    
+
+
+
+
+
+
    
+
    677. Weaknesses in seed_seq::randomize [rand.util.seedseq]
    
+
    Section: 26.4.7.1 [rand.util.seedseq] Status: Pending WP
+ Submitter: Charles Karney Date: 2007-05-15
    
+
    View all other issues in [rand.util.seedseq].
    
+
    View all issues with Pending WP status.
    
+
    Discussion:
    
+
    
+seed_seq::randomize provides a mechanism for initializing random number
+engines which ideally would yield "distant" states when given "close"
+seeds.  The algorithm for seed_seq::randomize given in the current
+Working Draft for C++,
+N2284
+(2007-05-08), has 3 weaknesses
+
    
+
+
      
+
    1. 
+
       Collisions in state.  Because of the way the state is initialized,
+    seeds of different lengths may result in the same state.  The
+    current version of seed_seq has the following properties:
      
+
        
+
      •   For a given s <= n, each of the 2^(32s) seed vectors results in a
+      distinct state.
        • 
+
      
+
      
+    The proposed algorithm (below) has the considerably stronger
+    properties:
      
+
        
+
      •    All of the (2^(32n)-1)/(2^32-1) seed vectors of lengths s < n
+      result in distinct states.
+
        • 
+
      •   All of the 2^(32n) seed vectors of length s == n result in
+      distinct states.
+
        • 
+
      
+
      2. 
+
    2. 
+
       Poor mixing of v's entropy into the state.  Consider v.size() == n
+    and hold v[n/2] thru v[n-1] fixed while varying v[0] thru v[n/2-1],
+    a total of 2^(16n) possibilities.  Because of the simple recursion
+    used in seed_seq, begin[n/2] thru begin[n-1] can take on only 2^64
+    possible states.
      
+
+
       The proposed algorithm uses a more complex recursion which results
+    in much better mixing.
      
+
      3. 
+
    3.  seed_seq::randomize is undefined for v.size() == 0.  The proposed
+    algorithm remedies this.
+
      4. 
+
    
+
    
+The current algorithm for seed_seq::randomize is adapted by me from the
+initialization procedure for the Mersenne Twister by Makoto Matsumoto
+and Takuji Nishimura.  The weakness (2) given above was communicated to
+me by Matsumoto last year.
+
    
+
    
+The proposed replacement for seed_seq::randomize is due to Mutsuo Saito,
+a student of Matsumoto, and is given in the implementation of the
+SIMD-oriented Fast Mersenne Twister random number generator SFMT.
+http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html
+http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/SFMT-src-1.2.tar.gz
+
    
+
    
+See
+Mutsuo Saito,
+An Application of Finite Field: Design and Implementation of 128-bit
+Instruction-Based Fast Pseudorandom Number Generator,
+Master's Thesis, Dept. of Math., Hiroshima University (Feb. 2007)
+http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/M062821.pdf
+
    
+
    
+One change has been made here, namely to treat the case of small n
+(setting t = (n-1)/2 for n < 7).
+
    
+
    
+Since seed_seq was introduced relatively recently there is little cost
+in making this incompatible improvement to it.
+
    
+
+
    
+See N2391 and
+N2423
+for some further discussion.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Adopt the proposed resolution in
+N2423.
+
    
+
+
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]
    
+
+
+
+
+
+
    
+
    678. Changes for [rand.req.eng]
    
+
    Section: 26.4.1.3 [rand.req.eng] Status: WP
+ Submitter: Charles Karney Date: 2007-05-15
    
+
    View all other issues in [rand.req.eng].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+Section 26.4.1.3 [rand.req.eng] Random number engine requirements:
+
    
+
+
    
+This change follows naturally from the proposed change to
+seed_seq::randomize in 677.
+
    
+
+
    
+In table 104 the description of X(q) contains a special treatment of
+the case q.size() == 0.  This is undesirable for 4 reasons:
+
    
+
+
      
+
    1. It replicates the functionality provided by X().
      2. 
+
    2. It leads to the possibility of a collision in the state provided
+    by some other X(q) with q.size() > 0.
      3. 
+
    3. 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
+there is no special treatment of q.size() == 0.
      4. 
+
    4. The proposed replacement for seed_seq::randomize given above
+    allows for the case q.size() == 0.
      5. 
+
    
+
+
    
+See N2391 and
+N2423
+for some further discussion.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Adopt the proposed resolution in
+N2423.
+
    
+
+
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]
    
+
+
+
+
+
+
    
+
    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.
    
+
    Discussion:
    
+
    
+In 28.9.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);
+
    
+
    
+
    
+-31- Returns: lhs == rhs.str().
+
    
+
    
+
    
+
+
    
+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. 
+
    
+
+
+
    Proposed resolution:
    
+
    
+Adopt the proposed resolution in
+N2409.
+
    
+
+
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]
    
+
+
+
+
+
+
    
+
    682. basic_regex ctor takes InputIterator or ForwardIterator?
    
+
    Section: 28.8.2 [re.regex.construct] Status: Pending WP
+ Submitter: Eric Niebler Date: 2007-06-03
    
+
    View all issues with Pending WP status.
    
+
    Discussion:
    
+
    
+Looking at N2284, 28.8 [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);
+
    
+
+
    
+In 28.8.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);
+
    
+
+
    
+ForwardIterator is probably correct, so the synopsis is wrong.
+
    
+
+
    [
+John adds:
+]
    
+
+
+
    
+
    
+I think either could be implemented?  Although an input iterator would 
+probably require an internal copy of the string being made.
+
    
+
    
+I have no strong feelings either way, although I think my original intent 
+was InputIterator. 
+
    
+
    
+
+
+
    Proposed resolution:
    
+
    
+Adopt the proposed resolution in
+N2409.
+
    
+
+
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]
    
+
+
+
+
+
+
    
+
    699. N2111 changes min/max
    
+
    Section: 26.4 [rand] Status: WP
+ Submitter: P.J. Plauger Date: 2007-07-01
    
+
    View all other issues in [rand].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+N2111
+changes min/max in several places in random from member
+functions to static data members. I believe this introduces
+a needless backward compatibility problem between C++0X and
+TR1. I'd like us to find new names for the static data members,
+or perhaps change min/max to constexprs in C++0X.
+
    
+
+
    
+See N2391 and
+N2423
+for some further discussion.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Adopt the proposed resolution in
+N2423.
+
    
+
+
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]
    
+
+
+
+
+
+
    
+
    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 all other issues in [rand.util.seedseq].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+One of the motivations for incorporating seed_seq::size()
+was to simplify the wording
+in other parts of 26.4 [rand].
+As a side effect of resolving related issues,
+all such references
+to seed_seq::size() will have been excised.
+More importantly,
+the present specification is contradictory,
+as "The number of 32-bit units the object can deliver"
+is not the same as "the result of v.size()."
+
    
+
+
    
+See N2391 and
+N2423
+for some further discussion.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Adopt the proposed resolution in
+N2423.
+
    
+
+
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]
    
+
+
+
+
+
+
+
\ No newline at end of file
-- 
2.11.0