From 301a9fb249131bad2b88ddea549cfee9b577c9e0 Mon Sep 17 00:00:00 2001 From: Paolo Carlini Date: Wed, 21 May 2008 20:13:47 +0000 Subject: [PATCH] lwg-active.html: Update to Revision R56. 2008-05-21 Paolo Carlini * doc/html/ext/lwg-active.html: Update to Revision R56. * doc/html/ext/lwg-closed.html: Likewise. * doc/html/ext/lwg-defects.html: Likewise. From-SVN: r135737 --- libstdc++-v3/ChangeLog | 6 + libstdc++-v3/doc/html/ext/lwg-active.html | 12922 +++++++++++++------ libstdc++-v3/doc/html/ext/lwg-closed.html | 3551 ++++- libstdc++-v3/doc/html/ext/lwg-defects.html | 2455 +++- 4 files changed, 14150 insertions(+), 4784 deletions(-) diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog index c2b2ea60340..85195fb76f9 100644 --- a/libstdc++-v3/ChangeLog +++ b/libstdc++-v3/ChangeLog @@ -1,3 +1,9 @@ +2008-05-21 Paolo Carlini + + * doc/html/ext/lwg-active.html: Update to Revision R56. + * doc/html/ext/lwg-closed.html: Likewise. + * doc/html/ext/lwg-defects.html: Likewise. + 2008-05-20 Paolo Carlini PR c++/33979 (partial) diff --git a/libstdc++-v3/doc/html/ext/lwg-active.html b/libstdc++-v3/doc/html/ext/lwg-active.html index 29e0d775bf3..27e0ed263e4 100644 --- a/libstdc++-v3/doc/html/ext/lwg-active.html +++ b/libstdc++-v3/doc/html/ext/lwg-active.html @@ -12,11 +12,11 @@ del {background-color:#FFA0A0} - + - + @@ -27,7 +27,7 @@ del {background-color:#FFA0A0}
Doc. no.N2456=07-0326N2612=08-0122
Date:2007-10-202008-05-18
Project:Howard Hinnant <howard.hinnant@gmail.com>
-

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

+

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

Reference ISO/IEC IS 14882:1998(E)

Also see:

@@ -94,6 +94,89 @@ del {background-color:#FFA0A0}

Revision History

@@ -141,13 +224,13 @@ del {background-color:#FFA0A0}
  • 708 issues total, up by 12.
  • Details:
      -
    • Added the following New issues: 697, 698, 699, 700, 701, 702, 703, 704, 705, 706, 707, 708.
      • +
    • Added the following New issues: 697, 698, 699, 700, 701, 702, 703, 704, 705, 706, 707, 708.
    • Changed the following issues from New to NAD: 583, 584, 662.
    • Changed the following issues from Open to NAD: 528.
    • Changed the following issues from New to NAD Editorial: 637, 647, 658, 690.
    • Changed the following issues from Open to NAD Editorial: 525.
    • Changed the following issues from Pending NAD Editorial to NAD Editorial: 553, 571, 591, 633, 636, 641, 642, 648, 649, 656.
      • -
    • Changed the following issues from New to Open: 579, 631, 680.
      • +
    • Changed the following issues from New to Open: 579, 631, 680.
    • Changed the following issues from Pending WP to Open: 258.
    • Changed the following issues from Ready to Pending WP: 644.
    • Changed the following issues from New to Ready: 577, 660.
      • @@ -168,7 +251,7 @@ del {background-color:#FFA0A0}
    • 696 issues total, up by 20.
  • Details:
  • Details:
  • Details:
    • @@ -246,7 +329,7 @@ del {background-color:#FFA0A0}
  • Moved issues 520, 521, 530, 535, 537, 538, 540, 541 to WP.
  • Moved issues 504, 512, 516, 544, 549, 554, 555, 558 to NAD.
  • Moved issue 569 to Dup.
    • -
  • Moved issues 518, 523, 524, 542, 556, 557, 559, 597, 606 to Open.
    • +
  • Moved issues 518, 523, 524, 542, 556, 557, 559, 597, 606 to Open.
  • Moved issues 543, 545, 549, 549, 598 - 603, 605 to Ready.
  • Moved issues 531, 551, 604 to Review.
  • Added new issues 593-609.
    • @@ -290,9 +373,9 @@ del {background-color:#FFA0A0}
  • 574 issues total, up by 8.
  • Details:
  • Details:
    • @@ -368,12 +451,12 @@ new issues 463-478. +new issues 463-478.
  • R30: Post-Sydney mailing: reflects decisions made at the Sydney meeting. Voted all "Ready" issues from R29 into the working paper. -Added new issues 460-462. +Added new issues 460-462.
  • R29: Pre-Sydney mailing. Added new issues 441-457. @@ -518,7 +601,7 @@ of issue 83, 86, 91, 92, -109. Added issues 190 to +109. Added issues 190 to 195. (99-0033/D1209, 14 Oct 99)
  • R9: @@ -537,7 +620,7 @@ pre-Dublin updated: Added issues 138, 139 (31 Mar 99)
  • R6: -pre-Dublin mailing. Added issues 127, 128, +pre-Dublin mailing. Added issues 127, 128, and 129. (99-0007/N1194, 22 Feb 99)
  • R5: @@ -869,7 +952,7 @@ is assigned to err.

    96. Vector<bool> is not a container

    -

    Section: 23.2.5 [vector] Status: Open +

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

    View all other issues in [vector].

    View all issues with Open status.

    @@ -964,6 +1047,172 @@ users who want to continue using a bit-packed container. Alan and Beman to work +
    +

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

    +

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

    +

    View all other issues in [string.streams].

    +

    View all issues with Open status.

    +

    Discussion:

    +

    The following question came from Thorsten Herlemann:

    + +
    +

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

    +
    + +

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

    + +

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

    + +

    [ +post Bellevue: Alisdair requested to re-Open. +]

    + + + + +

    Proposed resolution:

    +

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

    + +

        openmode mode() const;

    + +

        Returns the current open mode.

    + +

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

    + + +

    Rationale:

    +

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

    + + + + + +
    +

    180. Container member iterator arguments constness has unintended consequences

    +

    Section: 23 [containers] Status: Open + Submitter: Dave Abrahams Date: 1999-07-01

    +

    View other active issues in [containers].

    +

    View all other issues in [containers].

    +

    View all issues with Open status.

    +

    Discussion:

    +

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

    + +

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

    + +

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

    + +

    [ +post Bellevue, Alisdair adds: +]

    + + +
    +

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

    + +

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

    +
    + + + +

    Proposed resolution:

    +

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

    + +

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

    + + +

    Rationale:

    +

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

    + +

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

    + + + + +
    +

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

    +

    Section: 25.3.7 [alg.min.max] Status: Open + Submitter: Mark Rintoul Date: 1999-08-26

    +

    View other active issues in [alg.min.max].

    +

    View all other issues in [alg.min.max].

    +

    View all issues with Open status.

    +

    Discussion:

    +

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

    + +

    [ +post Bellevue: Alisdair requested to re-Open. +]

    + + + + +

    Rationale:

    +

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

    + + + +

    255. Why do basic_streambuf<>::pbump() and gbump() take an int?

    Section: 27.5.2 [streambuf] Status: Open @@ -1210,7 +1459,6 @@ with a return type of convertible to T and operational semantics of

    309. Does sentry catch exceptions?

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

    -

    View other active issues in [iostream.format].

    View all other issues in [iostream.format].

    View all issues with Open status.

    Discussion:

    @@ -1759,6 +2007,19 @@ think that there are cases such as some of those above where it would be desirable to allow implementations to include only as much as necessary and not more.

    +

    [ +post Bellevue: +]

    + + +
    +Position taken in prior reviews is that the idea of a table of header +dependencies is a good one. Our view is that a full paper is needed to +do justice to this, and we've made that recommendation to the issue +author. +
    + +

    Proposed resolution:

    @@ -1982,10 +2243,10 @@ partial can only occur if (from_next != from_end)?

    387. std::complex over-encapsulated

    -

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

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

    View all other issues in [complex.numbers].

    -

    View all issues with Open status.

    +

    View all issues with Ready status.

    Discussion:

    The absence of explicit description of std::complex<T> layout @@ -2027,9 +2288,9 @@ of std::complex<> is not justified.

    • the expression reinterpret_cast<cv T(&)[2]>(z) is well-formed; and
      • -
    • reinterpret_cast<cvT(&)[2]>(z)[0]designates the +
    • reinterpret_cast<cv T(&)[2]>(z)[0]designates the real part of z; and
      • -
    • reinterpret_cast<cvT(&)[2]>(z)[1]designates the +
    • reinterpret_cast<cv T(&)[2]>(z)[1]designates the imaginary part of z.
    @@ -2040,45 +2301,47 @@ i then:

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

    In the header synopsis in 26.3.1 [complex.synopsis], replace

    -
      template<class T> T real(const complex<T>&);
-  template<class T> T imag(const complex<T>&);
-
    +

    +In 26.3.2 [complex] Add the member functions +

    -

    with

    +
    void real(T);
+void imag(T);
+
    -
      template<class T> const T& real(const complex<T>&);
-  template<class T>       T& real(      complex<T>&);
-  template<class T> const T& imag(const complex<T>&);
-  template<class T>       T& imag(      complex<T>&);
-
    +

    +Add to 26.3.4 [complex.members] +

    -

    In 26.3.7 [complex.value.ops] paragraph 1, change

    -
      template<class T> T real(const complex<T>&);
+
    
+
    T real() const;
 
    
-
    to
    
-
      template<class T> const T& real(const complex<T>&);
-  template<class T>       T& real(      complex<T>&);
+
    
+Returns: the value of the real component
+
    
+
    void real(T val);
 
    
-
    and change the Returns clause to "Returns: The real
-part of x.
    
-
-
    In 26.3.7 [complex.value.ops] paragraph 2, change
    
-
      template<class T> T imag(const complex<T>&);
+
    
+Assigns val to the real component.
+
    
+
    T imag() const;
 
    
-
    to
    
-
      template<class T> const T& imag(const complex<T>&);
-  template<class T>       T& imag(      complex<T>&);
+
    
+Returns: the value of the imaginary component
+
    
+
    void imag(T val);
 
    
-
    and change the Returns clause to "Returns: The imaginary
-part of x.
    
+
    
+Assigns val to the imaginary component.
+
    
+
    
 
 
    [Kona: The layout guarantee is absolutely necessary for C
   compatibility.  However, there was disagreement about the other part
@@ -2095,6 +2358,14 @@ part of x.
    
 
    [pre-Sydney: Howard summarized the options in n1589.]
    
 
 
+
    [
+Bellevue:
+]
    
+
+
+
    
+Second half of proposed wording replaced and moved to Ready.
+
    
 
 
 
    Rationale:
    
@@ -2215,6 +2486,7 @@ functions should be changed as proposed below.
 
    396. what are characters zero and one
    
 
    Section: 23.3.5.1 [bitset.cons] Status: Open
  Submitter: Martin Sebor Date: 2003-01-05
    
+
    View other active issues in [bitset.cons].
    
 
    View all other issues in [bitset.cons].
    
 
    View all issues with Open status.
    
 
    Discussion:
    
@@ -2305,6 +2577,15 @@ is zero. Otherwise, the element has the value 1.
    
 
 
 
+
    [
+post Bellevue:
+]
    
+
+
+
    
+We are happy with the resolution as proposed, and we move this to Ready.
+
    
+
 
 
 
@@ -2348,7 +2629,7 @@ sentry::~sentry() should internally catch any exceptions it might cause.
 
 
 
    [
-See 418 and 622 for related issues.
+See 418 and 622 for related issues.
 ]
    
 
 
@@ -2661,7 +2942,7 @@ object throws.
 
 
 
    [
-See 397 and 622 for related issues.
+See 397 and 622 for related issues.
 ]
    
 
 
@@ -3023,88 +3304,6 @@ ostream::write().
 
 
 
-
    
-
    424. normative notes
    
-
    Section: 17.3.1.1 [structure.summary] Status: Open
- Submitter: Martin Sebor Date: 2003-09-18
    
-
    View all issues with Open status.
    
-
    Discussion:
    
-
-
    
-The text in 17.3.1.1, p1 says:
-
    
-
-"Paragraphs labelled "Note(s):" or "Example(s):" are informative, other
-paragraphs are normative."
-
    
-
-The library section makes heavy use of paragraphs labeled "Notes(s),"
-some of which are clearly intended to be normative (see list 1), while
-some others are not (see list 2). There are also those where the intent
-is not so clear (see list 3).
-

    
-
-List 1 -- Examples of (presumably) normative Notes:
-
    
-
-20.6.1.1 [allocator.members], p3,
    
-20.6.1.1 [allocator.members], p10,
    
-21.3.2 [string.cons], p11,
    
-22.1.1.2 [locale.cons], p11,
    
-23.2.2.3 [deque.modifiers], p2,
    
-25.3.7 [alg.min.max], p3,
    
-26.3.6 [complex.ops], p15,
    
-27.5.2.4.3 [streambuf.virt.get], p7.
    
-
    
-
-List 2 -- Examples of (presumably) informative Notes:
-
    
-
-18.5.1.3 [new.delete.placement], p3,
    
-21.3.6.6 [string::replace], p14,
    
-22.2.1.4.2 [locale.codecvt.virtuals], p3,
    
-25.1.1 [alg.foreach], p4,
    
-26.3.5 [complex.member.ops], p1,
    
-27.4.2.5 [ios.base.storage], p6.
    
-
    
-
-List 3 -- Examples of Notes that are not clearly either normative
-or informative:
-
    
-
-22.1.1.2 [locale.cons], p8,
    
-22.1.1.5 [locale.statics], p6,
    
-27.5.2.4.5 [streambuf.virt.put], p4.
    
-
    
-
-None of these lists is meant to be exhaustive.
-
    
-
-
    [Definitely a real problem.  The big problem is there's material
-  that doesn't quite fit any of the named paragraph categories
-  (e.g. Effects).  Either we need a new kind of named
-  paragraph, or we need to put more material in unnamed paragraphs
-  jsut after the signature.  We need to talk to the Project Editor
-  about how to do this.
-]
    
-
-
-
-
    Proposed resolution:
    
-
    [Pete: I changed the paragraphs marked "Note" and "Notes" to use "Remark" and "Remarks".
-Fixed as editorial.  This change has been in the WD since the post-Redmond mailing, in 2004.
-Recommend NAD.]
    
-
-
    [
-Batavia:  We feel that the references in List 2 above should be changed from Remarks
-to Notes.  We also feel that those items in List 3 need to be double checked for
-the same change.  Alan and Pete to review.
-]
    
-
-
-
-
-
 
    
 
    427. stage 2 and rationale of DR 221
    
 
    Section: 22.2.2.1.2 [facet.num.get.virtuals] Status: Open
@@ -3184,8 +3383,155 @@ object (e.g., slice (2, 1, 1) for a valarray of size 1).
   need wording to express this decision.]
    
 
 
+
    [
+Bellevue:
+]
    
+
+
+
    
+Please note that the standard also fails to specify the behavior of
+slice_array and gslice_array in the valid case. Bill Plauger will
+endeavor to provide revised wording for slice_array and gslice_array.
+
    
+
+
    [
+post-Bellevue:  Bill provided wording.
+]
    
+
+
 
 
    Proposed resolution:
    
+
    
+Insert after 26.5.2.4 [valarray.sub], paragraph 1:
+
    
+
+
    
+
    
+The member operator is overloaded to provide several ways to select
+sequences
+of elements from among those controlled by *this. The first group of five
+member operators work in conjunction with various overloads of operator=
+(and other assigning operators) to allow selective replacement (slicing) of
+the controlled sequence. The selected elements must exist.
+
    
+
    
+The first member operator selects element off. For example:
+
    
+
+
    valarray<char> v0("abcdefghijklmnop", 16);
+v0[3] = 'A';
+// v0 == valarray<char>("abcAefghijklmnop", 16)
+
    
+
+
    
+The second member operator selects those elements of the controlled sequence
+designated by slicearr. For example:
+
    
+
+
    valarray<char> v0("abcdefghijklmnop", 16);
+valarray<char> v1("ABCDE", 5);
+v0[slice(2, 5, 3)] = v1;
+// v0 == valarray<char>("abAdeBghCjkDmnEp", 16)
+
    
+
+
    
+The third member operator selects those elements of the controlled sequence
+designated by gslicearr. For example:
+
    
+
+
    valarray<char> v0("abcdefghijklmnop", 16);
+valarray<char> v1("ABCDEF", 6);
+const size_t lv[] = {2, 3};
+const size_t dv[] = {7, 2};
+const valarray<size_t> len(lv, 2), str(dv, 2);
+v0[gslice(3, len, str)] = v1;
+// v0 == valarray<char>("abcAeBgCijDlEnFp", 16)
+
    
+
+
    
+The fourth member operator selects those elements of the controlled sequence
+designated by boolarr. For example:
+
    
+
+
    valarray<char> v0("abcdefghijklmnop", 16);
+valarray<char> v1("ABC", 3);
+const bool vb[] = {false, false, true, true, false, true};
+v0[valarray<bool>(vb, 6)] = v1;
+// v0 == valarray<char>("abABeCghijklmnop", 16)
+
    
+
+
    
+The fifth member operator selects those elements of the controlled sequence
+designated by indarr. For example:
+
    
+
+
    valarray<char> v0("abcdefghijklmnop", 16);
+valarray<char> v1("ABCDE", 5);
+const size_t vi[] = {7, 5, 2, 3, 8};
+v0[valarray<size_t>(vi, 5)] = v1;
+// v0 == valarray<char>("abCDeBgAEjklmnop", 16)
+
    
+
+
    
+The second group of five member operators each construct an object that
+represents the value(s) selected. The selected elements must exist.
+
    
+
+
    
+The sixth member operator returns the value of element off. For example:
+
    
+
+
    valarray<char> v0("abcdefghijklmnop", 16);
+// v0[3] returns 'd'
+
    
+
+
    
+The seventh member operator returns an object of class valarray<Ty>
+containing those elements of the controlled sequence designated by slicearr.
+For example:
+
    
+
+
    valarray<char> v0("abcdefghijklmnop", 16);
+// v0[slice(2, 5, 3)] returns valarray<char>("cfilo", 5)
+
    
+
+
    
+The eighth member operator selects those elements of the controlled sequence
+designated by gslicearr. For example:
+
    
+
+
    valarray<char> v0("abcdefghijklmnop", 16);
+const size_t lv[] = {2, 3};
+const size_t dv[] = {7, 2};
+const valarray<size_t> len(lv, 2), str(dv, 2);
+// v0[gslice(3, len, str)] returns
+//    valarray<char>("dfhkmo", 6)
+
    
+
+
    
+The ninth member operator selects those elements of the controlled sequence
+designated by boolarr. For example:
+
    
+
+
    valarray<char> v0("abcdefghijklmnop", 16);
+const bool vb[] = {false, false, true, true, false, true};
+// v0[valarray<bool>(vb, 6)] returns
+//    valarray<char>("cdf", 3)
+
    
+
+
    
+The last member operator selects those elements of the controlled sequence
+designated by indarr. For example:
+
    
+
+
    valarray<char> v0("abcdefghijklmnop", 16);
+const size_t vi[] = {7, 5, 2, 3, 8};
+// v0[valarray<size_t>(vi, 5)] returns
+//    valarray<char>("hfcdi", 5)
+
    
+
+
    
+
 
 
 
@@ -3312,6 +3658,7 @@ reachability.
 
    View other active issues in [filebuf.members].
    
 
    View all other issues in [filebuf.members].
    
 
    View all issues with Open status.
    
+
    Duplicate of: 105
    
 
    Discussion:
    
 
        basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode);
 
    
@@ -3421,6 +3768,33 @@ std::basic_string? (3) We might want to wait until we see Beman's
 filesystem library; we might decide that it obviates this.]
    
 
 
+
    [
+post Bellevue:
+]
    
+
+
+
    
+
    
+Move again to Ready.
+
    
+
    
+There is a timing issue here. Since the filesystem library will not be
+in C++0x, this should be brought forward. This solution would remain
+valid in the context of the proposed filesystem.
+
    
+
    
+This issue has been kicking around for a while, and the wchar_t addition
+alone would help many users. Thus, we suggest putting this on the
+reflector list with an invitation for someone to produce proposed
+wording that covers basic_fstream. In the meantime, we suggest that the
+proposed wording be adopted as-is.
+
    
+
    
+If more of the Lillehammer questions come back, they should be
+introduced as separate issues.
+
    
+
    
+
 
 
 
@@ -3563,157 +3937,414 @@ technique to perform the comparison:
    
 
 
 
    
-
    462. Destroying objects with static storage duration
    
-
    Section: 3.6.3 [basic.start.term], 18.3 [cstdint] Status: Open
- Submitter: Bill Plauger Date: 2004-03-23
    
+
    463. auto_ptr usability issues
    
+
    Section: D.9.1 [auto.ptr] Status: Open
+ Submitter: Rani Sharoni Date: 2003-12-07
    
+
    View all other issues in [auto.ptr].
    
 
    View all issues with Open status.
    
 
    Discussion:
    
+
 
    
-3.6.3 Termination spells out in detail the interleaving of static
-destructor calls and calls to functions registered with atexit. To
-match this behavior requires intimate cooperation between the code
-that calls destructors and the exit/atexit machinery. The former
-is tied tightly to the compiler; the latter is a primitive mechanism
-inherited from C that traditionally has nothing to do with static
-construction and destruction. The benefits of intermixing destructor
-calls with atexit handler calls is questionable at best, and very
-difficult to get right, particularly when mixing third-party C++
-libraries with different third-party C++ compilers and C libraries
-supplied by still other parties.
+TC1 CWG DR #84 effectively made the template<class Y> operator auto_ptr<Y>()
+member of auto_ptr (20.4.5.3/4) obsolete.
 
    
 
 
    
-I believe the right thing to do is defer all static destruction
-until after all atexit handlers are called. This is a change in
-behavior, but one that is likely visible only to perverse test
-suites. At the very least, we should permit deferred destruction
-even if we don't require it.
+The sole purpose of this obsolete conversion member is to enable copy
+initialization base from r-value derived (or any convertible types like
+cv-types) case:
+
    
+
    #include <memory>
+using std::auto_ptr;
+
+struct B {};
+struct D : B {};
+
+auto_ptr<D> source();
+int sink(auto_ptr<B>);
+int x1 = sink( source() ); // #1 EDG - no suitable copy constructor
+
    
+
+
    
+The excellent analysis of conversion operations that was given in the final
+auto_ptr proposal
+(http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf)
+explicitly specifies this case analysis (case 4). DR #84 makes the analysis
+wrong and actually comes to forbid the loophole that was exploited by the
+auto_ptr designers.
 
    
 
-
    [If this is to be changed, it should probably be changed by CWG.
-  At this point, however, the LWG is leaning toward NAD.  Implementing
-  what the standard says is hard work, but it's not impossible and
-  most vendors went through that pain years ago.  Changing this
-  behavior would be a user-visible change, and would break at least
-  one real application.]
    
+
    
+I didn't encounter any compliant compiler (e.g. EDG, GCC, BCC and VC) that
+ever allowed this case. This is probably because it requires 3 user defined
+conversions and in fact current compilers conform to DR #84.
+
    
+
+
    
+I was surprised to discover that the obsolete conversion member actually has
+negative impact of the copy initialization base from l-value derived
+case:
    
+
    auto_ptr<D> dp;
+int x2 = sink(dp); // #2 EDG - more than one user-defined conversion applies
+
    
+
+
    
+I'm sure that the original intention was allowing this initialization using
+the template<class Y> auto_ptr(auto_ptr<Y>& a) constructor (20.4.5.1/4) but
+since in this copy initialization it's merely user defined conversion (UDC)
+and the obsolete conversion member is UDC with the same rank (for the early
+overloading stage) there is an ambiguity between them.
+
    
+
+
    
+Removing the obsolete member will have impact on code that explicitly
+invokes it:
+
    
+
    int y = sink(source().operator auto_ptr<B>());
+
    
+
+
    
+IMHO no one ever wrote such awkward code and the reasonable workaround for
+#1 is:
+
    
+
    int y = sink( auto_ptr<B>(source()) );
+
    
+
+
    
+I was even more surprised to find out that after removing the obsolete
+conversion member the initialization was still ill-formed:
+int x3 = sink(dp); // #3 EDG - no suitable copy constructor
+
    
+
+
    
+This copy initialization semantically requires copy constructor which means
+that both template conversion constructor and the auto_ptr_ref conversion
+member (20.4.5.3/3) are required which is what was explicitly forbidden in
+DR #84. This is a bit amusing case in which removing ambiguity results with
+no candidates.
+
    
+
+
    
+I also found exception safety issue with auto_ptr related to auto_ptr_ref:
+
    
+
    int f(auto_ptr<B>, std::string);
+auto_ptr<B> source2();
+
+// string constructor throws while auto_ptr_ref
+// "holds" the pointer
+int x4 = f(source2(), "xyz"); // #4
+
    
+
+
    
+The theoretic execution sequence that will cause a leak:
+
    
+
      
+
    1. call auto_ptr<B>::operator auto_ptr_ref<B>()
      2. 
+
    2. call string::string(char const*) and throw
      3. 
+
    
+
+
    
+According to 20.4.5.3/3 and 20.4.5/2 the auto_ptr_ref conversion member
+returns auto_ptr_ref<Y> that holds *this and this is another defect since
+the type of *this is auto_ptr<X> where X might be different from Y. Several
+library vendors (e.g. SGI) implement auto_ptr_ref<Y> with Y* as member which
+is much more reasonable. Other vendor implemented auto_ptr_ref as
+defectively required and it results with awkward and catastrophic code:
+int oops = sink(auto_ptr<B>(source())); // warning recursive on all control
+paths
+
    
+
+
    
+Dave Abrahams noticed that there is no specification saying that
+auto_ptr_ref copy constructor can't throw.
+
    
+
+
    
+My proposal comes to solve all the above issues and significantly simplify
+auto_ptr implementation. One of the fundamental requirements from auto_ptr
+is that it can be constructed in an intuitive manner (i.e. like ordinary
+pointers) but with strict ownership semantics which yield that source
+auto_ptr in initialization must be non-const. My idea is to add additional
+constructor template with sole propose to generate ill-formed, diagnostic
+required, instance for const auto_ptr arguments during instantiation of
+declaration. This special constructor will not be instantiated for other
+types which is achievable using 14.8.2/2 (SFINAE). Having this constructor
+in hand makes the constructor template<class Y> auto_ptr(auto_ptr<Y> const&)
+legitimate since the actual argument can't be const yet non const r-value
+are acceptable.
+
    
+
+
    
+This implementation technique makes the "private auxiliary class"
+auto_ptr_ref obsolete and I found out that modern C++ compilers (e.g. EDG,
+GCC and VC) consume the new implementation as expected and allow all
+intuitive initialization and assignment cases while rejecting illegal cases
+that involve const auto_ptr arguments.
+
    
+
+
    The proposed auto_ptr interface:
    
+
+
    namespace std {
+    template<class X> class auto_ptr {
+    public:
+        typedef X element_type;
+
+        // 20.4.5.1 construct/copy/destroy:
+        explicit auto_ptr(X* p=0) throw();
+        auto_ptr(auto_ptr&) throw();
+        template<class Y> auto_ptr(auto_ptr<Y> const&) throw();
+        auto_ptr& operator=(auto_ptr&) throw();
+        template<class Y> auto_ptr& operator=(auto_ptr<Y>) throw();
+        ~auto_ptr() throw();
+
+        // 20.4.5.2 members:
+        X& operator*() const throw();
+        X* operator->() const throw();
+        X* get() const throw();
+        X* release() throw();
+        void reset(X* p=0) throw();
+
+    private:
+        template<class U>
+        auto_ptr(U& rhs, typename
+unspecified_error_on_const_auto_ptr<U>::type = 0);
+    };
+}
+
    
+
+
    
+One compliant technique to implement the unspecified_error_on_const_auto_ptr
+helper class is using additional private auto_ptr member class template like
+the following:
+
    
+
    template<typename T> struct unspecified_error_on_const_auto_ptr;
+
+template<typename T>
+struct unspecified_error_on_const_auto_ptr<auto_ptr<T> const>
+{ typedef typename auto_ptr<T>::const_auto_ptr_is_not_allowed type; };
+
    
+
+
    
+There are other techniques to implement this helper class that might work
+better for different compliers (i.e. better diagnostics) and therefore I
+suggest defining its semantic behavior without mandating any specific
+implementation. IMO, and I didn't found any compiler that thinks otherwise,
+14.7.1/5 doesn't theoretically defeat the suggested technique but I suggest
+verifying this with core language experts.
+
    
+
+
    Further changes in standard text:
    
+
    Remove section 20.4.5.3
    
+
+
    Change 20.4.5/2 to read something like:
+Initializing auto_ptr<X> from const auto_ptr<Y> will result with unspecified
+ill-formed declaration that will require unspecified diagnostic.
    
+
+
    Change 20.4.5.1/4,5,6 to read:
    
+
+
    template<class Y> auto_ptr(auto_ptr<Y> const& a) throw();
    
+
     4 Requires: Y* can be implicitly converted to X*.
    
+
     5 Effects: Calls const_cast<auto_ptr<Y>&>(a).release().
    
+
     6 Postconditions: *this holds the pointer returned from a.release().
    
+
+
    Change 20.4.5.1/10
    
+
    template<class Y> auto_ptr& operator=(auto_ptr<Y> a) throw();
+
    
+
    
+10 Requires: Y* can be implicitly converted to X*. The expression delete
+get() is well formed.
+
    
+
+
    LWG TC DR #127 is obsolete.
    
+
+
    
+Notice that the copy constructor and copy assignment operator should remain
+as before and accept non-const auto_ptr& since they have effect on the form
+of the implicitly declared copy constructor and copy assignment operator of
+class that contains auto_ptr as member per 12.8/5,10:
+
    
+
    struct X {
+    // implicit X(X&)
+    // implicit X& operator=(X&)
+    auto_ptr<D> aptr_;
+};
+
    
+
+
    
+In most cases this indicates about sloppy programming but preserves the
+current auto_ptr behavior.
+
    
+
+
    
+Dave Abrahams encouraged me to suggest fallback implementation in case that
+my suggestion that involves removing of auto_ptr_ref will not be accepted.
+In this case removing the obsolete conversion member to auto_ptr<Y> and
+20.4.5.3/4,5 is still required in order to eliminate ambiguity in legal
+cases. The two constructors that I suggested will co exist with the current
+members but will make auto_ptr_ref obsolete in initialization contexts.
+auto_ptr_ref will be effective in assignment contexts as suggested in DR
+#127 and I can't see any serious exception safety issues in those cases
+(although it's possible to synthesize such). auto_ptr_ref<X> semantics will
+have to be revised to say that it strictly holds pointer of type X and not
+reference to an auto_ptr for the favor of cases in which auto_ptr_ref<Y> is
+constructed from auto_ptr<X> in which X is different from Y (i.e. assignment
+from r-value derived to base).
+
    
+
+
    [Redmond: punt for the moment. We haven't decided yet whether we
+  want to fix auto_ptr for C++-0x, or remove it and replace it with
+  move_ptr and unique_ptr.]
    
 
 
 
    [
-Batavia:  Send to core with our recommendation that we should permit deferred
-destruction but not require it.
+Oxford 2007: Recommend NAD.  We're just going to deprecate it.  It still works for simple use cases
+and people know how to deal with it.  Going forward unique_ptr is the recommended
+tool.
 ]
    
 
 
 
    [
-Howard:  The course of action recommended in Batavia would undo LWG
-issue 3 and break current code implementing the "phoenix
-singleton". Search the net for "phoenix singleton atexit" to get a feel
-for the size of the adverse impact this change would have.  Below is
-sample code which implements the phoenix singleton and would break if
-atexit is changed in this way:
+2007-11-09: Reopened at the request of David Abrahams, Alisdair Meredith and Gabriel Dos Reis.
 ]
    
 
 
-
    #include <cstdlib>
-#include <iostream>
-#include <type_traits>
-#include <new>
-
-class A
-{
-    bool alive_;
-    A(const A&);
-    A& operator=(const A&);
-public:
-    A() : alive_(true) {std::cout << "A()\n";}
-    ~A() {alive_ = false; std::cout << "~A()\n";}
-    void use()
-    {
-        if (alive_)
-            std::cout << "A is alive\n";
-        else
-            std::cout << "A is dead\n";
-    }
-};
-
-void deallocate_resource();
-
-// This is the phoenix singleton pattern
-A& get_resource(bool create = true)
-{
-    static std::aligned_storage<sizeof(A), std::alignment_of<A>::value>::type buf;
-    static A* a;
-    if (create)
-    {
-        if (a != (A*)&buf)
-        {
-            a = ::new (&buf) A;
-            std::atexit(deallocate_resource);
-        }
-    }
-    else
-    {
-        a->~A();
-        a = (A*)&buf + 1;
-    }
-    return *a;
-}
-
-void deallocate_resource()
-{
-    get_resource(false);
-}
-
-void use_A(const char* message)
-{
-    A& a = get_resource();
-    std::cout << "Using A " << message << "\n";
-    a.use();
-}
-
-struct B
-{
-    ~B() {use_A("from ~B()");}
-};
-
-B b;
-
-int main()
-{
-    use_A("from main()");
-}
-
    
-
-
    
-The correct output is:
-
    
-
-
    A()
-Using A from main()
-A is alive
-~A()
-A()
-Using A from ~B()
-A is alive
-~A()
-
    
-
 
 
 
    Proposed resolution:
    
 
    
+Change the synopsis in D.9.1 [auto.ptr]:
 
    
 
+
    namespace std { 
+  template <class Y> struct auto_ptr_ref {};
+
+  // exposition only
+  template <class T> struct constant_object;
+
+  // exposition only
+  template <class T>
+  struct cannot_transfer_ownership_from
+    : constant_object<T> {};
+
+  template <class X> class auto_ptr { 
+  public: 
+    typedef X element_type; 
+
+    // D.9.1.1 construct/copy/destroy: 
+    explicit auto_ptr(X* p =0) throw(); 
+    auto_ptr(auto_ptr&) throw(); 
+    template<class Y> auto_ptr(auto_ptr<Y> const&) throw(); 
+    auto_ptr& operator=(auto_ptr&) throw(); 
+    template<class Y> auto_ptr& operator=(auto_ptr<Y>&) throw();
+    auto_ptr& operator=(auto_ptr_ref<X> r) throw();
+    ~auto_ptr() throw(); 
+
+    // D.9.1.2 members: 
+    X& operator*() const throw();
+    X* operator->() const throw();
+    X* get() const throw();
+    X* release() throw();
+    void reset(X* p =0) throw();
+
+    // D.9.1.3 conversions:
+    auto_ptr(auto_ptr_ref<X>) throw();
+    template<class Y> operator auto_ptr_ref<Y>() throw();
+    template<class Y> operator auto_ptr<Y>() throw();
+
+    // exposition only
+    template<class U>
+    auto_ptr(U& rhs, typename cannot_transfer_ownership_from<U>::error = 0);
+  }; 
+
+  template <> class auto_ptr<void> 
+  { 
+  public: 
+    typedef void element_type; 
+  }; 
+
+}
+
    
+
+
    
+Remove D.9.1.3 [auto.ptr.conv].
+
    
+
+
    
+Change D.9.1 [auto.ptr], p3:
+
    
+
+
    
+The auto_ptr provides a semantics of strict ownership. An
+auto_ptr owns the object it holds a pointer to. Copying an
+auto_ptr copies the pointer and transfers ownership to the
+destination. If more than one auto_ptr owns the same object at
+the same time the behavior of the program is undefined. Templates
+constant_object and cannot_transfer_ownership_from,
+and the final constructor of auto_ptr are for exposition only.
+For any types X and Y, initializing
+auto_ptr<X> from const auto_ptr<Y> is
+ill-formed, diagnostic required. [Note: The uses of
+auto_ptr include providing temporary exception-safety for
+dynamically allocated memory, passing ownership of dynamically allocated
+memory to a function, and returning dynamically allocated memory from a
+function. auto_ptr does not meet the CopyConstructible
+and Assignable requirements for Standard Library container
+elements and thus instantiating a Standard Library container with an
+auto_ptr results in undefined behavior. -- end note]
+
    
+
+
    
+Change D.9.1.1 [auto.ptr.cons], p5:
+
    
+
+
    
+
    template<class Y> auto_ptr(auto_ptr<Y> const& a) throw();
+
    
+
    
+
    
+Requires: Y* can be implicitly converted to X*.
+
    
+
    
+Effects: Calls const_cast<auto_ptr<Y>&>(a).release().
+
    
+
    
+Postconditions: *this holds the pointer returned from a.release().
+
    
+
    
+
    
+
+
    
+Change D.9.1.1 [auto.ptr.cons], p10:
+
    
+
+
    
+
    template<class Y> auto_ptr& operator=(auto_ptr<Y>& a) throw();
+
    
+
    
+
    
+Requires: Y* can be implicitly converted to X*.
+The expression delete get() is well formed.
+
    
+
    
+Effects: Calls reset(a.release()).
+
    
+
    
+Returns: *this.
+
    
+
    
+
    
+
+
 
 
 
 
 
    
 
    471. result of what() implementation-defined
    
-
    Section: 18.6.1 [type.info] Status: Open
+
    Section: 18.6.1 [type.info] Status: Ready
  Submitter: Martin Sebor Date: 2004-06-28
    
 
    View all other issues in [type.info].
    
-
    View all issues with Open status.
    
+
    View all issues with Ready status.
    
 
    Discussion:
    
 
 
    [lib.exception] specifies the following:
    
@@ -3757,6 +4388,36 @@ Batavia: Howard provided wording.
 ]
    
 
 
+
    [
+Bellevue:
+]
    
+
+
+
    
+
    
+Eric concerned this is unimplementable, due to nothrow guarantees.
+Suggested implementation would involve reference counting.
+
    
+
    
+Is the implied reference counting subtle enough to call out a note on
+implementation? Probably not.
+
    
+
    
+If reference counting required, could we tighten specification further
+to require same pointer value? Probably an overspecification, especially
+if exception classes defer evalutation of final string to calls to
+what().
+
    
+
    
+Remember issue moved open and not resolved at Batavia, but cannot
+remember who objected to canvas a disenting opinion - please speak up if
+you disagree while reading these minutes!
+
    
+
    
+Move to Ready as we are accepting words unmodified.
+
    
+
    
+
 
 
 
    Proposed resolution:
    
@@ -3980,6 +4641,7 @@ wording (I believe) x,a,b,c could be written to in any order.
 
    492. Invalid iterator arithmetic expressions
    
 
    Section: 23 [containers], 24 [iterators], 25 [algorithms] Status: Open
  Submitter: Thomas Mang Date: 2004-12-12
    
+
    View other active issues in [containers].
    
 
    View all other issues in [containers].
    
 
    View all issues with Open status.
    
 
    Discussion:
    
@@ -4142,6 +4804,16 @@ See DR 237. The resolution could then also read "Linear in last -
 first".
 
    
 
+
    [
+Bellevue:
+]
    
+
+
+
    
+Keep open and ask Bill to provide wording.
+
    
+
+
 
    Proposed resolution:
    
 
 
    [Lillehammer: Minor issue, but real. We have a blanket statement
@@ -4388,11 +5060,10 @@ 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: Review
+
    Section: 23.1.3 [unord.req], TR1 6.3.1 [tr.unord.req] Status: Ready
  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 Review status.
    
+
    View all issues with Ready status.
    
 
    Discussion:
    
 
    
 Issue 371 deals with stability of multiset/multimap under insert and erase
@@ -4459,6 +5130,8 @@ preserves the relative ordering of equivalent elements.
    
 
    522. Tuple doesn't define swap
    
 
    Section: 20.3 [tuple], TR1 6.1 [tr.tuple] Status: Open
  Submitter: Andy Koenig Date: 2005-07-03
    
+
    View other active issues in [tuple].
    
+
    View all other issues in [tuple].
    
 
    View all issues with Open status.
    
 
    Discussion:
    
 
    
@@ -4477,10 +5150,80 @@ Toronto: Howard to provide wording (really this time).
 ]
    
 
 
+
    [
+Bellevue:  Alisdair provided wording.
+]
    
+
+
 
 
 
    Proposed resolution:
    
 
+
    
+Add these signatures to 20.3 [tuple]
+
    
+
+
    template <class... Types>
+  void swap(tuple<Types...>& x, tuple<Types...>& y);
+template <class... Types>
+  void swap(tuple<Types...>&& x, tuple<Types...>& y);
+template <class... Types>
+  void swap(tuple<Types...>& x, tuple<Types...>&& y); 
+
    
+
+
    
+Add this signature to 20.3.1 [tuple.tuple]
+
    
+
+
    void swap(tuple&&);
+
    
+
+
    
+Add the following two sections to the end of the tuple clauses
+
    
+
+
    
+
    
+20.3.1.7 tuple swap [tuple.swap]
+
    
+
+
    void swap(tuple&& rhs); 
+
    
+
+
    
+
    
+Requires: Each type in Types shall be Swappable.
+
    
+
    
+Effects: Calls swap for each element in *this and its corresponding element
+in rhs.
+
    
+
    
+Throws: Nothing, unless one of the element-wise swap calls throw an
+exception. 
+
    
+
    
+
+
    
+20.3.1.8 tuple specialized algorithms [tuple.special]
+
    
+
+
    template <class... Types>
+  void swap(tuple<Types...>& x, tuple<Types...>& y);
+template <class... Types>
+  void swap(tuple<Types...>&& x, tuple<Types...>& y);
+template <class... Types>
+  void swap(tuple<Types...>& x, tuple<Types...>&& y); 
+
    
+
+
    
+
    
+Effects: x.swap(y)
+
    
+
    
+
    
+
+
 
 
 
@@ -4618,155 +5361,11 @@ Pete: Possible general problem with case insensitive ranges.
 
 
 
-
    
-
    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:
    
-
    
-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.
-]
    
-
-
-
    [
-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:
-
    
-
    
-Throws: Nothing unless one of the copy constructors of f, t1, t2, ..., tN
-throws an exception.
-
    
-
-
    
-Add a new paragraph after p4:
-
    
-
    
-Throws: nothing unless one of the copy constructors of f, t1, t2, ..., tN
-throws an exception.
-
    
-
-
-
-
-
-
    
-
    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
    
-
    View all issues with Open status.
    
-
    Discussion:
    
-
    
-17.4.3.8/1 says:
-
    
-
-
    
-Violation of the preconditions specified in a function's 
-Required behavior: paragraph results in undefined behavior unless the 
-function's Throws: paragraph specifies throwing an exception when the 
-precondition is violated.
-
    
-
-
    
-This implies that a precondition violation can lead to defined
-behavior.  That conflicts with the only reasonable definition of
-precondition: that a violation leads to undefined behavior.  Any other
-definition muddies the waters when it comes to analyzing program
-correctness, because precondition violations may be routinely done in
-correct code (e.g. you can use std::vector::at with the full
-expectation that you'll get an exception when your index is out of
-range, catch the exception, and continue).  Not only is it a bad
-example to set, but it encourages needless complication and redundancy
-in the standard.  For example:
-
    
-
-
      21 Strings library 
-  21.3.3 basic_string capacity
-
-  void resize(size_type n, charT c);
-
-  5 Requires: n <= max_size()
-  6 Throws: length_error if n > max_size().
-  7 Effects: Alters the length of the string designated by *this as follows:
-
    
-
-
    
-The Requires clause is entirely redundant and can be dropped.  We
-could make that simplifying change (and many others like it) even
-without changing 17.4.3.8/1; the wording there just seems to encourage
-the redundant and error-prone Requires: clause.
-
    
-
-
    [
-Batavia:  Alan and Pete to work.
-]
    
-
-
-
-
    Proposed resolution:
    
-
    
-1. Change 17.4.3.8/1 to read:
-
    
-
-
    
-Violation of the preconditions specified in a function's
-Required behavior: paragraph results in undefined behavior
-unless the function's Throws: paragraph specifies throwing
-an exception when the precondition is violated.
-
    
-
-
    
-2. Go through and remove redundant Requires: clauses.  Specifics to be
-   provided by Dave A.
-
    
-
-
    [
-Berlin: The LWG requests a detailed survey of part 2 of the proposed resolution.
-]
    
-
-
-
    [
-Alan provided the survey
-N2121.
-]
    
-
-
-
-
-
-
-
 
    
 
    539. partial_sum and adjacent_difference should mention requirements
    
-
    Section: 26.6.3 [partial.sum] Status: Open
+
    Section: 26.6.3 [partial.sum] Status: Review
  Submitter: Marc Schoolderman Date: 2006-02-06
    
-
    View all issues with Open status.
    
+
    View all issues with Review status.
    
 
    Discussion:
    
 
    
 There are some problems in the definition of partial_sum and
@@ -4912,12 +5511,38 @@ adding signatures to allow user to specify "accumulator".
 ]
    
 
 
+
    [
+Bellevue:
+]
    
+
+
+
    
+The intent of the algorithms is to perform their calculations using the type of the input iterator.
+Proposed wording provided.
+
    
 
 
 
    Proposed resolution:
    
 
    
+Add to section 26.6.3 [partial.sum] paragraph 4 the following two sentences:
 
    
 
+
    
+The type of *first shall meet the requirements of CopyConstructible?
+(20.1.3?) and Assignable (23.1?) types. The result of *i + *(i+1) or
+binary_op(*i, *(i+1)) shall be convertible to this type.
+
    
+
+
    
+Add to section 26.6.4 [adjacent.difference] paragraph 2 the following sentence:
+
    
+
+
    
+The type of *first shall meet the requirements of CopyConstructible?
+(20.1.3) and Assignable (23.1) types.
+
    
+
+
 
 
 
@@ -4951,11 +5576,11 @@ list, so that people may use long long as a hash key.
 
 
    
 
    550. What should the return type of pow(float,int) be?
    
-
    Section: 26.7 [c.math] Status: Open
+
    Section: 26.7 [c.math] Status: Ready
  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 Open status.
    
+
    View all issues with Ready status.
    
 
    Discussion:
    
 
    
 Assuming we adopt the
@@ -5015,52 +5640,73 @@ resolution")
 
 
 
    [
-
    
-Howard, post Kona:
-
    
+
    
+Howard, post Kona:
+
    
 
    
 
    
-Unfortunately I strongly disagree with a part of the resolution
+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
+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
+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);
-
    
+
    float nexttoward(float, long double);
+
    
 
    
 
    
-which is what both the C++0X working paper and C99 state (as far as I currently understand).
-
    
+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
+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.
-
    
+
    
 
    
-]
+]
    
 
 
+
    [
+Bellevue:
+]
    
+
+
+
    
+This signature was not picked up from C99. Instead, if one types
+pow(2.0f,2), the promotion rules will invoke "double pow(double,
+double)", which generally gives special treatment for integral
+exponents, preserving full accuracy of the result.  New proposed
+wording provided.
+
    
 
 
 
    Proposed resolution:
    
 
    
-Change 26.7 [c.math]
+Change 26.7 [c.math] p10:
 
    
 
-
    float pow(float, float); 
-float double pow(float, int);
+
    
+
    
+The added signatures are:
+
    
+
    ...
+float pow(float, int);
+...
+double pow(double, int);
+...
+long double pow(long double, int);
 
    
+
    
 
 
 
@@ -5128,406 +5774,10 @@ destroyed.
 
 
 
-
    
-
    557. TR1: div(_Longlong, _Longlong) vs div(intmax_t, intmax_t)
    
-
    Section: 18.3 [cstdint], TR1 8.22 [tr.c99.cstdint] Status: Open
- Submitter: Paolo Carlini Date: 2006-02-06
    
-
    View all other issues in [cstdint].
    
-
    View all issues with Open status.
    
-
    Discussion:
    
-
    
-I'm seeing a problem with such overloads: when, _Longlong == intmax_t ==
-long long we end up, essentially, with the same arguments and different
-return types (lldiv_t and imaxdiv_t, respectively). Similar issue with
-abs(_Longlong) and abs(intmax_t), of course.
-
    
-
    
-Comparing sections 8.25 and 8.11, I see an important difference,
-however: 8.25.3 and 8.25.4 carefully describe div and abs for _Longlong
-types (rightfully, because not moved over directly from C99), whereas
-there is no equivalent in 8.11: the abs and div overloads for intmax_t
-types appear only in the synopsis and are not described anywhere, in
-particular no mention in 8.11.2 (at variance with 8.25.2).
-
    
-
    
-I'm wondering whether we really, really, want div and abs for intmax_t...
-
    
-
-
-
-
    Proposed resolution:
    
-
-
-
-
    [
-Portland: no consensus.
-]
    
-
-
-
    Rationale:
    
-
    [
-Batavia, Bill: The <cstdint> synopsis in TR1 8.11.1 [tr.c99.cinttypes.syn] contains:
-]
    
-
-
    intmax_t imaxabs(intmax_t i);
-intmax_t abs(intmax_t i);
-
-imaxdiv_t imaxdiv(intmax_t numer, intmax_t denom);
-imaxdiv_t div(intmax_t numer, intmax_t denom);
-
    
-
-
    [
-and in TR1 8.11.2 [tr.c99.cinttypes.def]:
-]
    
-
-
-
    
-The header defines all functions, types, and macros the same as C99
-subclause 7.8.
-
    
-
-
    [
-This is as much definition as we give for most other C99 functions,
-so nothing need change. We might, however, choose to add the footnote:
-]
    
-
-
-
    
-[Note: These overloads for abs and div may well be equivalent to
-those that take long long arguments. If so, the implementation is
-responsible for avoiding conflicting declarations. -- end note]
-
    
-
-
-
-
-
-
-
    
-
    561. inserter overly generic
    
-
    Section: 24.4.2.6.5 [inserter] Status: Ready
- Submitter: Howard Hinnant Date: 2006-02-21
    
-
    View all issues with Ready status.
    
-
    Discussion:
    
-
    
-The declaration of std::inserter is:
-
    
-
-
    template <class Container, class Iterator>
-insert_iterator<Container>
-inserter(Container& x, Iterator i);
-
    
-
-
    
-The template parameter Iterator in this function is completely unrelated
-to the template parameter Container when it doesn't need to be.  This
-causes the code to be overly generic.  That is, any type at all can be deduced
-as Iterator, whether or not it makes sense.  Now the same is true of
-Container.  However, for every free (unconstrained) template parameter
-one has in a signature, the opportunity for a mistaken binding grows geometrically.
-
    
-
-
    
-It would be much better if inserter had the following signature instead:
-
    
-
-
    template <class Container>
-insert_iterator<Container>
-inserter(Container& x, typename Container::iterator i);
-
    
-
-
    
-Now there is only one free template parameter.  And the second argument to
-inserter must be implicitly convertible to the container's iterator,
-else the call will not be a viable overload (allowing other functions in the
-overload set to take precedence).  Furthermore, the first parameter must have a
-nested type named iterator, or again the binding to std::inserter
-is not viable.  Contrast this with the current situation
-where any type can bind to Container or Iterator and those
-types need not be anything closely related to containers or iterators.
-
    
-
-
    
-This can adversely impact well written code.  Consider:
-
    
-
-
    #include <iterator>
-#include <string>
-
-namespace my
-{
-
-template <class String>
-struct my_type {};
-
-struct my_container
-{
-template <class String>
-void push_back(const my_type<String>&);
-};
-
-template <class String>
-void inserter(const my_type<String>& m, my_container& c) {c.push_back(m);}
-
-}  // my
-
-int main()
-{
-    my::my_container c;
-    my::my_type<std::string> m;
-    inserter(m, c);
-}
-
    
-
-
    
-Today this code fails because the call to inserter binds to
-std::inserter instead of to my::inserter.  However with the
-proposed change std::inserter will no longer be a viable function which
-leaves only my::inserter in the overload resolution set.  Everything
-works as the client intends.
-
    
-
-
    
-To make matters a little more insidious, the above example works today if you
-simply change the first argument to an rvalue:
-
    
-
-
        inserter(my::my_type(), c);
-
    
-
-
    
-It will also work if instantiated with some string type other than
-std::string (or any other std type).  It will also work if
-<iterator> happens to not get included.
-
    
-
-
    
-And it will fail again for such inocuous reaons as my_type or
-my_container privately deriving from any std type.
-
    
-
-
    
-It seems unfortunate that such simple changes in the client's code can result
-in such radically differing behavior.
-
    
-
-
-
-
    Proposed resolution:
    
-
    
-Change 24.2:
-
    
-
-
    
-24.2 Header <iterator> synopsis
-
    
-
    ...
-template <class Container, class Iterator>
-   insert_iterator<Container> inserter(Container& x, Iterator typename Container::iterator i);
-...
-
    
-
    
-
-
    
-Change 24.4.2.5:
-
    
-
-
    
-24.4.2.5 Class template insert_iterator
    
-
    ...
-template <class Container, class Iterator>
-   insert_iterator<Container> inserter(Container& x, Iterator typename Container::iterator i);
-...
-
    
-
    
-
-
    
-Change 24.4.2.6.5:
-
    
-
-
    
-
    
-24.4.2.6.5 inserter
-
    
-
    template <class Container, class Inserter>
-   insert_iterator<Container> inserter(Container& x, Inserter typename Container::iterator i);
-
    
-
    
--1- Returns: insert_iterator<Container>(x,typename Container::iterator(i)).
-
    
-
    
-
-
-
-
    [
-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: Ready
- Submitter: Martin Sebor Date: 2006-02-23
    
-
    View all other issues in [string.streams].
    
-
    View all issues with Ready status.
    
-
    Discussion:
    
-        
    
-
-For  better efficiency,  the requirement  on the  stringbuf  ctor that
-takes  a  string  argument  should  be  loosened  up  to  let  it  set
-epptr()  beyond  just   one  past  the  last  initialized
-character  just like  overflow() has  been changed  to be
-allowed  to  do   (see  issue  432).  That  way   the  first  call  to
-sputc() on  an object won't  necessarily cause a  call to
-overflow. The corresponding change  should be made to the
-string overload of the str() member function.
-
-        
    
-
-
-
    Proposed resolution:
    
-        
    
-
-Change 27.7.1.1, p3 of the Working Draft, N1804, as follows:
-
-        
    
-
-
    explicit basic_stringbuf(const basic_string<charT,traits,Allocator>& str,
-               ios_base::openmode which = ios_base::in | ios_base::out);
-
    
-
-
    
--3- Effects:  Constructs an object of class basic_stringbuf,
-initializing the base class with basic_streambuf()
-(27.5.2.1), and initializing mode with which.
-Then calls str(s). copies the content of
-str into the basic_stringbuf underlying character
-sequence. If which & ios_base::out is true, initializes the
-output sequence such that pbase() points to the first underlying
-character, epptr() points one past the last underlying character, and
-pptr() is equal to epptr() if which & ios_base::ate
-is true, otherwise pptr() is equal to pbase(). If
-which & ios_base::in is true, initializes the input sequence such
-that eback() and gptr() point to the first underlying 
-character and egptr() points one past the last underlying character.
-
    
-
    
-
-        
    
-
-Change the Effects clause of the str() in 27.7.1.2, p2 to
-read:
-
-        
    
-
    
-
    
--2- Effects: Copies the contents of s into the
-basic_stringbuf underlying character sequence and
-initializes the input and output sequences according to mode.
-If
-mode & ios_base::out is true, initializes the output
-sequence such that pbase() points to the first underlying character, 
-epptr() points one past the last underlying character, and pptr()
-is equal to epptr() if mode & ios_base::in
-is true, otherwise pptr() is equal to pbase(). If
-mode & ios_base::in is true, initializes the input sequence 
-such that eback() and gptr() point to the first underlying
-character and egptr() points one past the last underlying character.
-
    
-
-        
    
-
--3- Postconditions:  If  mode  & ios_base::out  is  true,
-pbase()  points  to the  first  underlying character  and
-(epptr() >= pbase() + s.size()) holds; in addition, if
-mode & ios_base::in is true, (pptr() == pbase()
-+ s.data())  holds, otherwise (pptr()  == pbase())
-is   true.    If  mode   &   ios_base::in  is   true,
-eback()  points to  the first  underlying  character, and
-(gptr()  ==  eback())  and  (egptr() ==  eback()  +
-s.size()) hold.
-
-        
    
-
    
-
-
-
    [
-Kona (2007) Moved to Ready.
-]
    
-
-
-
-
-
-
    
-
    563. stringbuf seeking from end
    
-
    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 Ready status.
    
-
    Discussion:
    
-
    
-According to  Table 92  (unchanged by issue  432), when  (way ==
-end) the  newoff value in out mode  is computed as
-the difference between epptr() and pbase().
-
    
-        
    
-
-This value  isn't meaningful unless the  value of epptr()
-can be  precisely controlled by a  program.  That used  to be possible
-until  we accepted the  resolution of  issue 432,  but since  then the
-requirements on overflow() have  been relaxed to allow it
-to  make  more than  1  write  position  available (i.e.,  by  setting
-epptr()     to     some     unspecified    value     past
-pptr()).      So    after     the    first     call    to
-overflow()  positioning the  output sequence  relative to
-end will have unspecified results.
-
-        
    
-        
    
-
-In  addition,  in in|out  mode,  since (egptr()  ==
-epptr()) need not hold, there are two different possible values
-for   newoff:    epptr()   -   pbase()   and
-egptr() - eback().
-
-        
    
-
-
-
    Proposed resolution:
    
-        
    
-
-Change the newoff  column in the last row  of Table 94 to
-read:
-
-        
    
-
    
-
-the end high mark pointer minus the beginning 
-pointer (xend high_mark - xbeg).
-
-
    
-
-
-
    [
-Kona (2007) Moved to Ready.
-]
    
-
-
-
-
-
 
    
 
    564. stringbuf seekpos underspecified
    
 
    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 Open status.
    
 
    Discussion:
    
@@ -5658,74 +5908,6 @@ proposed wording doesn't accomplish that. Proposed Disposition: Open
 
 
 
-
    
-
    567. streambuf inserter and extractor should be unformatted
    
-
    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 Ready status.
    
-
    Discussion:
    
-        
    
-
-Issue  60 explicitly made  the extractor  and inserter  operators that
-take a  basic_streambuf* argument formatted  input and output
-functions,  respectively.  I  believe that's  wrong, certainly  in the
-case of  the extractor, since formatted functions  begin by extracting
-and  discarding  whitespace.  The  extractor  should  not discard  any
-characters.
-
-        
    
-
-
-
    Proposed resolution:
    
-        
    
-
-I propose to  change each operator to behave  as unformatted input and
-output function,  respectively. The changes below are  relative to the
-working draft document number N1804.
-
-        
    
-        
    
-
-Specifically, change 27.6.1.2.3, p14 as follows:
-
-        
    
-
-            
    
-        
    
-
-Effects:  Behaves as  an unformatted  input function
-(as   described   in   27.6.1.2.127.6.1.3,   paragraph
-1).
-
-        
    
-            
    
-        
    
-
-And change 27.6.2.5.3, p7 as follows:
-
-        
    
-
-            
    
-        
    
-
-Effects: Behaves  as an unformatted  output function
-(as   described   in   27.6.2.5.127.6.2.6,   paragraph
-1).
-
-        
    
-            
    
-
-
-
    [
-Kona (2007): Proposed Disposition: Ready
-]
    
-
-
-
-
-
 
    
 
    568. log2 overloads missing
    
 
    Section: TR1 8.16.4 [tr.c99.cmath.over] Status: New
@@ -5754,6 +5936,8 @@ Add log2 to the list of functions in TR1 8.16.4 [tr.c99.cmath.over] p1.
 
    570. Request adding additional explicit specializations of char_traits
    
 
    Section: 21.1 [char.traits] Status: Open
  Submitter: Jack Reeves Date: 2006-04-06
    
+
    View other active issues in [char.traits].
    
+
    View all other issues in [char.traits].
    
 
    View all issues with Open status.
    
 
    Discussion:
    
 
    
@@ -5780,6 +5964,27 @@ Toronto: issue has grown with addition of char16_t and char32_t
    
 
 
+
    [
+post Bellevue:
+]
    
+
+
+
    
+
    
+We suggest that Jack be asked about the status of his paper, and if it
+is not forthcoming, the work-item be assigned to someone else. If no one
+steps forward to do the paper before the next meeting, we propose to
+make this NAD without further discussion. We leave this Open for now,
+but our recommendation is NAD.
+
    
+
    
+Note: the issue statement should be updated, as the Toronto comment has
+already been resolved. E.g., char_traits specializations for char16_t
+and char32_t are now in the working paper.
+
    
+
    
+
+
 
 
    Proposed resolution:
    
 
@@ -5843,10 +6048,10 @@ these definitions are horrible. Proposed Disposition: Open
 
 
    
 
    574. DR 369 Contradicts Text
    
-
    Section: 27.3 [iostream.objects] Status: Review
+
    Section: 27.3 [iostream.objects] Status: Ready
  Submitter: Pete Becker Date: 2006-04-18
    
 
    View all other issues in [iostream.objects].
    
-
    View all issues with Review status.
    
+
    View all issues with Ready status.
    
 
    Discussion:
    
 
    
 lib.iostream.objects requires that the standard stream objects are never
@@ -5893,81 +6098,6 @@ Disposition: Review
 
 
 
-
    
-
    579. erase(iterator) for unordered containers should not return an iterator
    
-
    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 Open status.
    
-
    Discussion:
    
-
    
-See
-N2023
-for full discussion.
-
    
-
-
-
    Proposed resolution:
    
-
    
-Option 1:
-
    
-
-
    
-The problem can be eliminated by omitting the requirement that a.erase(q) return an 
-iterator. This is, however, in contrast with the equivalent requirements for other 
-standard containers.
-
    
-
-
    
-Option 2:
-
    
-
-
    
-a.erase(q) can be made to compute the next iterator only when explicitly requested: 
-the technique consists in returning a proxy object implicitly convertible to iterator, so 
-that
-
    
-
-
    iterator q1=a.erase(q);
-
    
-
-
    
-works as expected, while
-
    
-
-
    a.erase(q);
-
    
-
-
    
-does not ever invoke the conversion-to-iterator operator, thus avoiding the associated 
-computation. To allow this technique, some sections of TR1 along the line "return value 
-is an iterator..." should be changed to "return value is an unspecified object implicitly 
-convertible to an iterator..." Although this trick is expected to work transparently, it can 
-have some collateral effects when the expression a.erase(q) is used inside generic 
-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. 
-
    
-
-
-
-
-
 
    
 
    580. unused allocator members
    
 
    Section: 20.1.2 [allocator.requirements] Status: Open
@@ -6017,92 +6147,80 @@ pre-Oxford:  Martin provided wording.
     
 
     
    Proposed resolution:
    
-       
    
+       
    
 
 Specifically, I propose to change 23.1 [container.requirements],
 p9 as follows:
 
-       
    
-           
    
+       
    
+           
    
 
    
--9- Copy constructors  for all container types defined  in this clause
-that   are  parametrized  on   Allocator  copy
-anthe  allocator argument from  their respective
+-9- Copy constructors  for all container types defined  in this clause
+that   are  parametrized  on   Allocator  copy
+anthe  allocator argument from  their respective
 first parameters.
 
-All other  constructors for  these container types  take an
-const  Allocator&  argument  (20.1.6),  an
+All other  constructors for  these container types  take an
+const  Allocator&  argument  (20.1.6),  an
 allocator whose value_type is the same as the container's
 value_type.
 
-A copy of this  argument isshall be used for any
-memory  allocation  and  deallocation performed,
-by these  constructors and by all  member functions, during
-the  lifetime  of each  container  object.   Allocation shall  be
-performed  "as  if"  by  calling  the  allocate()  member
-function on  a copy  of the allocator  object of the  appropriate type
-New  Footnote),   and  deallocation  "as   if"  by  calling
-deallocate() on  a copy of  the same allocator  object of
+A copy of this  argument isshall be used for any
+memory  allocation  and  deallocation performed,
+by these  constructors and by all  member functions, during
+the  lifetime  of each  container  object.   Allocation shall  be
+performed  "as  if"  by  calling  the  allocate()  member
+function on  a copy  of the allocator  object of the  appropriate type
+New  Footnote),   and  deallocation  "as   if"  by  calling
+deallocate() on  a copy of  the same allocator  object of
 the corresponding type.
 
-A  copy of  this argument  shall also  be used  to  construct and
-destroy objects whose lifetime  is managed by the container, including
-but not  limited to those of  the container's value_type,
-and  to  obtain  their  address.   All  objects  residing  in  storage
-allocated by a  container's allocator shall be constructed  "as if" by
-calling the construct() member  function on a copy of the
-allocator object of  the appropriate type.  The same  objects shall be
-destroyed "as if"  by calling destroy() on a  copy of the
-same allocator object  of the same type.  The  address of such objects
+A  copy of  this argument  shall also  be used  to  construct and
+destroy objects whose lifetime  is managed by the container, including
+but not  limited to those of  the container's value_type,
+and  to  obtain  their  address.   All  objects  residing  in  storage
+allocated by a  container's allocator shall be constructed  "as if" by
+calling the construct() member  function on a copy of the
+allocator object of  the appropriate type.  The same  objects shall be
+destroyed "as if"  by calling destroy() on a  copy of the
+same allocator object  of the same type.  The  address of such objects
 shall be obtained "as if" by calling the address() member
-function  on  a  copy  of  the allocator  object  of  the  appropriate
+function  on  a  copy  of  the allocator  object  of  the  appropriate
 type.
 
-Finally, a copy  of this argument shall be  used by its container
-object to determine  the maximum number of objects  of the container's
-value_type the container may  store at the same time. The
-container  member function max_size()
-obtains  this number
-from      the
-     value
-     returned      by
-    a      call
-     to
+Finally, a copy  of this argument shall be  used by its container
+object to determine  the maximum number of objects  of the container's
+value_type the container may  store at the same time. The
+container  member function max_size() obtains  this number
+from      the      value      returned      by     a      call      to
 get_allocator().max_size().
 
-In   all  container   types  defined   in  this   clause that  are
-parametrized     on    Allocator,     the    member
-get_allocator()     returns
-    a     copy
-    of     the
-Allocator     object
-    used     to
-   construct     the
+In   all  container   types  defined   in  this   clause that  are
+parametrized     on    Allocator,     the    member
+get_allocator()     returns     a     copy     of     the
+Allocator     object     used     to    construct     the
 container.258)
 
    
 
    
-New Footnote: This type  may be different from Allocator:
-it     may    be
-    derived    from
-    Allocator    via
-Allocator::rebind<U>::other   for  the  appropriate
+New Footnote: This type  may be different from Allocator:
+it     may    be     derived    from     Allocator    via
+Allocator::rebind<U>::other   for  the  appropriate
 type U.
 
    
-           
    
-       
    
+           
    
+       
    
+
 The proposed wording seems cumbersome but I couldn't think of a better
-way   to  describe   the
-  requirement  that   containers  use
-  their
-Allocator  to manage  only objects  (regardless  of their
-type)  that  persist  over  their  lifetimes  and  not,  for  example,
-temporaries  created on the  stack. That  is, containers  shouldn't be
-required  to  call  Allocator::construct(Allocator::allocate(1),
-elem)  just to  construct a  temporary copy  of an  element, or
-Allocator::destroy(Allocator::address(temp),     1)    to
+way   to  describe   the   requirement  that   containers  use   their
+Allocator  to manage  only objects  (regardless  of their
+type)  that  persist  over  their  lifetimes  and  not,  for  example,
+temporaries  created on the  stack. That  is, containers  shouldn't be
+required  to  call  Allocator::construct(Allocator::allocate(1),
+elem)  just to  construct a  temporary copy  of an  element, or
+Allocator::destroy(Allocator::address(temp),     1)    to
 destroy temporaries.
 
-       
    
+       
    
 
 
 
    [
@@ -6119,75 +6237,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: Ready
- Submitter: Martin Sebor Date: 2006-06-14
    
-
    View all other issues in [ostream.unformatted].
    
-
    View all issues with Ready status.
    
-
    Discussion:
    
-        
    
-
-The resolution of issue 60 changed basic_ostream::flush()
-so as not  to require it to behave as  an unformatted output function.
-That has at least two in my opinion problematic consequences:
-
-        
    
-        
    
-
-First, flush()  now calls rdbuf()->pubsync()
-unconditionally, without  regard to the  state of the stream.  I can't
-think of any reason why flush() should behave differently
-from the vast majority of stream functions in this respect.
-
-        
    
-        
    
-
-Second, flush() is not  required to catch exceptions from
-pubsync() or set  badbit in response to such
-events. That doesn't seem right either, as most other stream functions
-do so.
-
-        
    
-    
-
-    
    Proposed resolution:
    
-        
    
-
-I  propose  to revert  the  resolution of  issue  60  with respect  to
-flush(). Specifically,  I propose to  change 27.6.2.6, p7
-as follows:
-
-        
    
-
-
    
-Effects: Behaves as an  unformatted output function (as described
-in 27.6.2.6, paragraph 1). If rdbuf() is not a null
-pointer,  constructs a  sentry  object.  If  this object  returns
-true when converted to a  value of type bool the function
-calls rdbuf()->pubsync().  If that function returns
--1    calls    setstate(badbit)    (which    may    throw
-ios_base::failure  (27.4.4.3)).   Otherwise, if  the
-sentry object returns false, does nothing.Does
-not  behave  as  an  unformatted  output  function  (as  described  in
-27.6.2.6, paragraph 1).
-
    
-
-    
-
-
    [
-Kona (2007): Proposed Disposition: Ready
-]
    
-
-
-
-
-
 
    
 
    582. specialized algorithms and volatile storage
    
-
    Section: 20.6.4.1 [uninitialized.copy] Status: Open
+
    Section: 20.6.10.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:
    
@@ -6587,6 +6640,8 @@ requirements? Alisdair will prepare a paper. Proposed Disposition: Open
 
    595. TR1/C++0x: fabs(complex<T>) redundant / wrongly specified
    
 
    Section: 26.3.7 [complex.value.ops] Status: Ready
  Submitter: Stefan Große Pawig Date: 2006-09-24
    
+
    View other active issues in [complex.value.ops].
    
+
    View all other issues in [complex.value.ops].
    
 
    View all issues with Ready status.
    
 
    Discussion:
    
 
    
@@ -6691,6 +6746,14 @@ or (for C++0X) removed from the standard, since the functionality
 is already provided by the corresponding overloads of abs().
 
    
 
+
    [
+Bellevue:
+]
    
+
+
+
    
+Bill believes that abs() is a suitable overload. We should remove fabs().
+
    
 
 
 
    Proposed resolution:
    
@@ -6699,19 +6762,19 @@ is already provided by the corresponding overloads of abs().
 Change the synopsis in 26.3.1 [complex.synopsis]:
 
    
 
-
    template<class T> complex<T> fabs(const complex<T>&);
+
    template<class T> complex<T> fabs(const complex<T>&);
 
    
 
 
    
-Change 26.3.7 [complex.value.ops], p7:
+Remove 26.3.7 [complex.value.ops], p7:
 
    
 
 
    
-
    template<class T> complex<T> fabs(const complex<T>& x);
+
    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.
+-7- Effects: Behaves the same as C99 function cabs, defined in subclause 7.3.8.1.
 
    
 
    
 
    
@@ -6729,11 +6792,11 @@ Proposed Disposition: Ready
 
 
    
 
    596. 27.8.1.3 Table 112 omits "a+" and "a+b" modes
    
-
    Section: 27.8.1.4 [filebuf.members] Status: Review
+
    Section: 27.8.1.4 [filebuf.members] Status: Ready
  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 Review status.
    
+
    View all issues with Ready status.
    
 
    Discussion:
    
 
    
 In testing 27.8.1.4 [filebuf.members], Table 112 (in the latest N2009 draft), we invoke  
@@ -6916,7 +6979,8 @@ better than the other.
 
    
 Robert comments:
 
    
-
    In general, a library of arithmetic types cannot exactly emulate the
+
    
+In general, a library of arithmetic types cannot exactly emulate the
 behavior of the intrinsic numeric types. There are several ways to tell
 whether an implementation of the decimal types uses compiler
 intrinisics or a library. For example:
@@ -7014,21 +7078,21 @@ Redmond: We prefer explicit conversions for narrowing and implicit for widening.
 
 
 
    
-
    612. numeric_limits::is_modulo insufficently defined
    
-
    Section: 18.2.1.2 [numeric.limits.members] Status: Open
+
    612. numeric_limits::is_modulo insufficiently defined
    
+
    Section: 18.2.1.2 [numeric.limits.members] Status: Ready
  Submitter: Chris Jefferson Date: 2006-11-10
    
 
    View all other issues in [numeric.limits.members].
    
-
    View all issues with Open status.
    
+
    View all issues with Ready status.
    
 
    Discussion:
    
 
    
 18.2.1.2 55 states that "A type is modulo if it is possible to add two
 positive numbers together and have a result that wraps around to a
 third number that is less".
-This seems insufficent for the following reasons:
+This seems insufficient for the following reasons:
 
    
 
 
      
-
    1. Doesn't define what that value recieved is.
      2. 
+
    2. Doesn't define what that value received is.
      3. 
 
    3. Doesn't state the result is repeatable
      4. 
 
    4.  Doesn't require that doing addition, subtraction and other
 operations on all values is defined behaviour.
      5. 
@@ -7041,10 +7105,17 @@ Pete: is there an ISO definition of modulo?  Underflow on signed behavior is und
 ]
      
 
 
+
      [
+Bellevue:  accept resolution, move to ready status.
+Does this mandate that is_modulo be true on platforms for which int
+happens to b modulo? A: the standard already seems to require that.
+]
      
+
+
 
 
      Proposed resolution:
      
 
      
-Suggest 18.2.1.2 [numeric.limits.members[numeric.limits.members], paragraph 57 is ammeded to:
+Suggest 18.2.1.2 [numeric.limits.members[numeric.limits.members], paragraph 57 is amended to:
 
      
 
 
      
@@ -7118,6 +7189,12 @@ all member functions, during the lifetime of each container object.
 ]
      
 
 
+
      [
+post Bellevue: We re-confirm that the issue is real. Pablo will provide wording.
+]
      
+
+
+
 
 
      Proposed resolution:
      
 
      
@@ -7129,11 +7206,11 @@ all member functions, during the lifetime of each container object.
 
 
      
 
      617. std::array is a sequence that doesn't satisfy the sequence requirements?
      
-
      Section: 23.2.1 [array] Status: New
+
      Section: 23.2.1 [array] Status: Open
  Submitter: Bo Persson Date: 2006-12-30
      
 
      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 <array> header is given under 23.2 [sequences].
@@ -7164,9 +7241,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: Review
+
      Section: 26.5.2.7 [valarray.members] Status: Ready
  Submitter: Gabriel Dos Reis Date: 2007-01-10
      
-
      View all issues with Review status.
      
+
      View all issues with Ready status.
      
 
      Discussion:
      
 
      
 I would respectfully request an issue be opened with the intention to
@@ -7219,689 +7296,12 @@ 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: 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 Ready status.
      
-
      Discussion:
      
-        
      
-
-The Effects  clause for the  default valarray ctor
-suggests  that  it  is possible  to  increase  the  size of  an  empty
-valarray  object   by  calling  other   non-const  member
-functions of the class besides resize(). However, such an
-interpretation would  be contradicted by  the requirement on  the copy
-assignment  operator  (and  apparently   also  that  on  the  computed
-assignments)  that the  assigned arrays  be  the same  size.  See  the
-reflector discussion starting with c++std-lib-17871.
-
-        
      
-        
      
-
-In  addition,  Footnote 280  uses  some questionable  normative
-language.
-
-        
      
-
-
-
      Proposed resolution:
      
-        
      
-
-Reword the Effects clause and Footnote 280 as follows (26.5.2.1 [valarray.cons]):
-
-        
      
-        
      
-            
      
-
-valarray();
-
-            
      
-            
      
-
-Effects:      Constructs      an      object      of      class
-valarray<T>,279)    which    has    zero
-length until it is passed into a library function as a modifiable
-lvalue or through a non-constant this pointer.280)
-
-            
      
-            
      
-
-Postcondition: size() == 0.
-
-            
      
-            
      
-
-Footnote  280:  This default  constructor  is essential,  since
-arrays  of  valarray  are  likely to  prove  useful.
-There  shall also  be  a way  to change  the  size of  an array  after
-initialization;  this  is  supplied  by the  semantics  may be
-useful.   The  length  of  an  empty  array  can  be  increased  after
-initialization  by  means  of the  resize()  member
-function.
-
-            
      
-        
      
-
-
-
-
-
-
      
-
      621. non-const copy assignment operators of helper arrays
      
-
      Section: 26.5 [numarray] Status: Ready
- Submitter: Martin Sebor Date: 2007-01-20
      
-
      View all other issues in [numarray].
      
-
      View all issues with Ready status.
      
-
      Discussion:
      
-        
      
-
-The computed and  "fill" assignment operators of valarray
-helper     array     class    templates     (slice_array,
-gslice_array,         mask_array,        and
-indirect_array) are const  member functions of each class
-template     (the     latter    by     the     resolution    of  123
-since  they have reference  semantics and thus do  not affect
-the state of  the object on which they are  called.  However, the copy
-assignment  operators  of  these  class  templates,  which  also  have
-reference semantics,  are non-const.   The absence of  constness opens
-the door to speculation about whether they really are intended to have
-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:
      
-        
      
-
-Declare  the  copy  assignment  operators  of all  four  helper  array
-class templates const.
-
-        
      
-        
      
-
-Specifically,  make the following edits:
-
-        
      
-        
      
-
-Change     the    signature     in     26.5.5 [template.slice.array]    and
-26.5.5.1 [slice.arr.assign] as follows:
-
-        
      
-        
      -const slice_array& operator= (const slice_array&) const;
-
-        
      
-        
      
-
-Change     the     signature     in    26.5.7 [template.gslice.array]     and
-26.5.7.1 [gslice.array.assign] as follows:
-
-        
      
-        
      -const gslice_array& operator= (const gslice_array&) const;
-
-        
      
-        
      
-
-Change the  signature in 26.5.8 [template.mask.array]  and 26.5.8.1 [mask.array.assign] as
-follows:
-
-        
      
-        
      -const mask_array& operator= (const mask_array&) const;
-
-        
      
-        
      
-
-Change     the     signature     in    26.5.9 [template.indirect.array] and
-26.5.9.1 [indirect.array.assign] as follows:
-
-        
      
-        
      -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: Ready
- Submitter: Martin Sebor Date: 2007-01-20
      
-
      View all issues with Ready status.
      
-
      Discussion:
      
-        
      
-
-basic_filebuf  dtor is  specified to  have  the following
-straightforward effects:
-
-        
      
-        
      
-
-Effects:       Destroys      an      object       of      class
-basic_filebuf. Calls close().
-
-        
      
-        
      
-
-close() does a lot of potentially complicated processing,
-including calling overflow() to write out the termination
-sequence  (to   bring  the  output  sequence  to   its  initial  shift
-state). Since  any of the  functions called during the  processing can
-throw an exception, what should the  effects of an exception be on the
-dtor? Should the  dtor catch and swallow it or  should it propagate it
-to the caller?  The text doesn't  seem to provide any guidance in this
-regard  other  than  the  general  restriction on  throwing  (but  not
-propagating)  exceptions  from   destructors  of  library  classes  in
-17.4.4.8 [res.on.exception.handling].
-
-        
      
-        
      
-
-Further,  the last thing  close() is  specified to  do is
-call fclose() to close the FILE pointer. The
-last sentence of the Effects clause reads:
-
-        
      
-        
      
-
-...   If    any   of    the   calls   to    overflow   or
-std::fclose fails then close fails.
-
-        
      
-        
      
-
-This  suggests that  close()  might be  required to  call
-fclose()   if  and  only   if  none   of  the   calls  to
-overflow() fails, and avoid closing the FILE
-otherwise. This  way, if  overflow() failed to  flush out
-the data, the caller  would have  the opportunity to  try to  flush it
-again (perhaps  after trying  to deal with  whatever problem  may have
-caused the failure), rather than losing it outright.
-
-        
      
-        
      
-
-On the other hand,  the function's Postcondition specifies that
-is_open() ==  false, which  suggests that it  should call
-fclose()       unconditionally.       However,      since
-Postcondition clauses  are specified for many  functions in the
-standard,  including constructors  where they  obviously  cannot apply
-after an  exception, it's not clear  whether this Postcondition
-clause is intended to apply even after an exception.
-
-        
      
-        
      
-
-It  might  be worth  noting  that  the  traditional behavior  (Classic
-Iostreams  fstream::close() and  C fclose())
-is  to  close  the  FILE unconditionally,  regardless  of
-errors.
-
-        
      
-
-
      [
-See 397 and 418 for related issues.
-]
      
-
-
-
-
-
      Proposed resolution:
      
-        
      
-
-After discussing this  on the reflector (see the  thread starting with
-c++std-lib-17650) we propose that close() be clarified to
-match the traditional behavior, that is to close the FILE
-unconditionally,  even after  errors or  exceptions.  In  addition, we
-propose the dtor description be amended so as to explicitly require it
-to catch and swallow any exceptions thrown by close().
-
-        
      
-        
      
-
-Specifically,   we   propose   to   make  the   following   edits   in
-27.8.1.4 [filebuf.members]:
-
-        
      
-        
      
-            
      -basic_filebuf<charT,traits>* close();
-
-            
      
-            
      
-
-Effects:  If is_open()  == false,  returns  a null
-pointer.        If      a       put      area       exists,      calls
-overflow(traits::eof()) to flush  characters. If the last
-virtual   member  function   called  on   *this  (between
-underflow,  overflow,  seekoff,
-and   seekpos)  was   overflow   then  calls
-a_codecvt.unshift (possibly several times) to determine a
-termination   sequence,    inserts   those   characters    and   calls
-overflow(traits::eof())  again.  Finally, regardless
-of whether  any of the preceding  calls fails or  throws an exception,
-the  function it  closes   the  file   ("as   if"  by   calling
-std::fclose(file)).334)  If any  of  the calls
-made    by   the    functionto   overflow
-or,  including  std::fclose, 
-fails then close fails  by returning a null pointer.
-If one of these calls throws an exception, the exception is caught and
-rethrown after closing the file.
-
-            
      
-        
      
-        
      
-
-And to make the following edits in 27.8.1.2 [filebuf.cons].
-
-        
      
-        
      
-            
      -virtual ~basic_filebuf();
-
-            
      
-            
      
-
-Effects:       Destroys      an      object       of      class
-basic_filebuf<charT,traits>.                   Calls
-close().    If  an   exception  occurs   during  the
-destruction of the object, including the call to close(),
-the     exception    is     caught    but     not     rethrown    (see
-17.4.4.8 [res.on.exception.handling]).
-
-            
      
-        
      
-
-
-
-
-
-
      
-
      623. pubimbue forbidden to call imbue
      
-
      Section: 27.1.1 [iostream.limits.imbue] Status: Ready
- Submitter: Martin Sebor Date: 2007-01-20
      
-
      View all issues with Ready status.
      
-
      Discussion:
      
-        
      
-
-27.1.1 [iostream.limits.imbue]  specifies  that  "no  function  described  in
-clause 27 except  for ios_base::imbue causes any instance
-of                   basic_ios::imbue                  or
-basic_streambuf::imbue to be called."
-
-        
      
-        
      
-
-That      contradicts      the      Effects     clause      for
-basic_streambuf::pubimbue()  which requires  the function
-to do just that: call basic_streambuf::imbue().
-
-        
      
-
-
-
      Proposed resolution:
      
-        
      
-
-To    fix   this,    rephrase    the   sentence    above   to    allow
-pubimbue to do what  it was designed to do. Specifically.
-change 27.1.1 [iostream.limits.imbue], p1 to read:
-
-        
      
-        
      
-
-No     function    described     in    clause     27     except    for
-ios_base::imbue  and basic_filebuf::pubimbue
-causes    any    instance    of    basic_ios::imbue    or
-basic_streambuf::imbue to be called. ...
-
-        
      
-
-
-
-
-
-
      
-
      624. valarray assignment and arrays of unequal length
      
-
      Section: 26.5.2.2 [valarray.assign] Status: Ready
- Submitter: Martin Sebor Date: 2007-01-20
      
-
      View all issues with Ready status.
      
-
      Discussion:
      
-        
      
-
-The behavior of the  valarray copy assignment operator is
-defined only when both sides have  the same number of elements and the
-spec is explicit about assignments of arrays of unequal lengths having
-undefined behavior.
-
-        
      
-        
      
-
-However, the generalized  subscripting assignment operators overloaded
-on slice_array  et al (26.5.2.2 [valarray.assign])  don't have any
-such restriction, leading  the reader to believe that  the behavior of
-these  overloads is  well defined  regardless  of the  lengths of  the
-arguments.
-
-        
      
-        
      
-
-For example,  based on  the reading  of the spec  the behavior  of the
-snippet below can be expected to be well-defined:
-
-        
      
-        
          const std::slice from_0_to_3 (0, 3, 1);   // refers to elements 0, 1, 2
-    const std::valarray<int> a (1, 3);        // a = { 1, 1, 1 }
-    std::valarray<int>       b (2, 4);        // b = { 2, 2, 2, 2 }
-
-    b = a [from_0_to_3];
-        
      
-        
      
-
-In practice, b may end up being { 1, 1, 1 },
-{  1,  1, 1,  2  },  or  anything else,  indicating  that
-existing implementations vary.
-
-        
      
-
-
      
-Quoting from Section 3.4, Assignment operators, of Al Vermeulen's
-Proposal for Standard C++ Array Classes (see c++std-lib-704;
-N0308):
-
      
-
      
-  ...if the size of the array on the right hand side of the equal
-  sign differs from the size of the array on the left, a run time
-  error occurs. How this error is handled is implementation
-  dependent; for compilers which support it, throwing an exception
-  would be reasonable.
-
      
-
-
      
-And see more history in
-N0280.
-
      
-
-        
      
-
-It has  been argued in  discussions on the committee's  reflector that
-the semantics of all valarray assignment operators should
-be permitted to be undefined unless  the  length  of the arrays  being
-assigned is the same as the length of the one being assigned from. See
-the thread starting at c++std-lib-17786.
-
-        
      
-        
      
-
-In order  to reflect  such views, the  standard must specify  that the
-size of the  array referred to by the argument  of the assignment must
-match the size of the array  under assignment, for example by adding a
-Requires clause to 26.5.2.2 [valarray.assign] as follows:
-
-        
      
-        
      
-
-Requires: The length of the  array to which the argument refers
-equals size().
-
-        
      
-
-        
      
-
-Note that it's  far from clear that such leeway  is necessary in order
-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.
-
      
-
      
-
      
-
-
-
-
-
-
      
-
      625. mixed up Effects and Returns clauses
      
-
      Section: 17 [library] Status: Open
- Submitter: Martin Sebor Date: 2007-01-20
      
-
      View all other issues in [library].
      
-
      View all issues with Open status.
      
-
      Discussion:
      
-        
      
-
-Many  member functions  of  basic_string are  overloaded,
-with  some of  the  overloads taking  a string  argument,
-others  value_type*,  others size_type,  and
-others still iterators. Often, the requirements on one of
-the   overloads  are   expressed  in   the  form   of  Effects,
-Throws,      and     in      the     Working      Paper     
-(N2134)
-also Remark clauses,  while those on the rest  of the overloads
-via a reference to this overload and using a Returns clause.
-
-        
      
-        
      
-
-The  difference between  the two  forms of  specification is  that per
-17.3.1.3 [structure.specifications],  p3,  an  Effects clause  specifies
-"actions  performed  by the  functions,"  i.e., its  observable
-effects,  while a Returns  clause is  "a description  of the
-return  value(s)   of  a  function"  that  does   not  impose  any
-requirements on the function's observable effects.
-
-        
      
-        
      
-
-Since only  Notes are explicitly defined to  be informative and
-all  other paragraphs  are explicitly  defined to  be  normative, like
-Effects and Returns,  the new Remark clauses also
-impose normative requirements.
-
-        
      
-        
      
-
-So  by this  strict  reading of  the  standard there  are some  member
-functions of  basic_string that are required  to throw an
-exception under  some conditions or use specific  traits members while
-many other otherwise equivalent overloads, while obliged to return the
-same  values, aren't required  to follow  the exact  same requirements
-with regards to the observable effects.
-
-        
      
-        
      
-
-Here's an example of this  problem that was precipitated by the change
-from informative Notes to normative Remarks (presumably made to
-address 424):
-
-        
      
-        
      
-
-In the Working  Paper, find(string, size_type) contains a
-Remark  clause (which  is  just a  Note  in the  current
-standard) requiring it to use traits::eq().
-
-        
      
-        
      
-
-find(const  charT  *s,  size_type  pos) is  specified  to
-return  find(string(s), pos)  by a  Returns clause
-and so  it is not required to  use traits::eq(). However,
-the Working  Paper has  replaced the original  informative Note
-about   the  function   using  traits::length()   with  a
-normative  requirement  in  the   form  of  a  Remark.  Calling
-traits::length() may be  suboptimal, for example when the
-argument is a  very long array whose initial  substring doesn't appear
-anywhere in *this.
-
-        
      
-        
      
-
-Here's another  similar example,  one that existed  even prior  to the
-introduction of Remarks:
-
-        
      
-        
      
-
- insert(size_type  pos, string, size_type,  size_type) is
-required   to   throw   out_of_range   if   pos   >
-size().
-
-        
      
-        
      
-
-insert(size_type pos, string  str) is specified to return
-insert(pos, str, 0, npos)  by a Returns clause and
-so its  effects when pos  > size() are  strictly speaking
-unspecified.
-
-        
-        
      
-
-I  believe  a  careful   review  of  the  current  Effects  and
-Returns  clauses  is  needed  in  order to  identify  all  such
-problematic cases. In  addition, a review of the  Working Paper should
-be done to make sure that the newly introduced normative Remark
-clauses do not impose  any undesirable normative requirements in place
-of the original informative Notes.
-
-        
      
-
      [
-Batavia:  Alan and Pete to work.
-]
      
-
-
-
-
      Proposed resolution:
      
-
      
-
      
-
-
-
-
-
-
      
-
      626. new Remark clauses not documented
      
-
      Section: 17.3.1.3 [structure.specifications] Status: Open
- Submitter: Martin Sebor Date: 2007-01-20
      
-
      View all other issues in [structure.specifications].
      
-
      View all issues with Open status.
      
-
      Discussion:
      
-        
      
-
-The Remark clauses newly  introduced into the Working Paper 
-(N2134)
-are  not mentioned  in  17.3.1.3 [structure.specifications] where  we list  the
-meaning  of Effects, Requires,  and other  clauses (with
-the exception  of Notes which are documented  as informative in
-17.3.1.1 [structure.summary], p2, and which they replace in many cases).
-
-        
      
-        
      
-
-Propose add a bullet for Remarks along with a brief description.
-
-        
      
-
      [
-Batavia:  Alan and Pete to work.
-]
      
-
-
-
-
      Proposed resolution:
      
-
      
-
      
-
-
-
-
-
-
      
-
      627. Low memory and exceptions
      
-
      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 Open status.
      
-
      Discussion:
      
-
      
-I recognize the need for nothrow guarantees in the exception reporting
-mechanism, but I strongly believe that implementors also need an escape hatch
-when memory gets really low. (Like, there's not enough heap to construct and
-copy exception objects, or not enough stack to process the throw.) I'd like to
-think we can put this escape hatch in 18.5.1.1 [new.delete.single],
-operator new, but I'm not sure how to do it. We need more than a
-footnote, but the wording has to be a bit vague. The idea is that if
-new can't allocate something sufficiently small, it has the right to
-abort/call terminate/call unexpected.
-
      
-
-
-
      Proposed resolution:
      
-
      
-
      
-
-
-
-
-
 
      
 
      629. complex insertion and locale dependence
      
-
      Section: 26.3.6 [complex.ops] Status: Open
+
      Section: 26.3.6 [complex.ops] Status: Ready
  Submitter: Gabriel Dos Reis Date: 2007-01-28
      
 
      View all other issues in [complex.ops].
      
-
      View all issues with Open status.
      
+
      View all issues with Ready status.
      
 
      Discussion:
      
 
      
 is there an issue opened for (0,3) as complex number with
@@ -7927,12 +7327,39 @@ dedicated facet.  Then complex should use that solution.
 
      
 
      
 
+
      [
+Bellevue:
+]
      
+
+
+
      
+
      
+After much discussion, we agreed on the following: Add a footnote:
+
      
+
      
+[In a locale in which comma is being used as a decimal point character,
+inserting "showbase" into the output stream forces all outputs to show
+an explicit decimal point character; then all inserted complex sequences
+will extract unambiguously.]
+
      
+
      
+And move this to READY status.
+
      
+
      
 
 
 
      Proposed resolution:
      
 
      
+Add a footnote to 26.3.6 [complex.ops] p16:
 
      
 
+
      
+[In a locale in which comma is being used as a decimal point character,
+inserting "showbase" into the output stream forces all outputs to show
+an explicit decimal point character; then all inserted complex sequences
+will extract unambiguously.]
+
      
+
 
 
 
@@ -7941,7 +7368,6 @@ dedicated facet.  Then complex should use that solution.
 
      630. arrays of valarray
      
 
      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 Open status.
      
 
      Discussion:
      
@@ -8012,6 +7438,16 @@ assignment operator.
 
         
      
 
+
      [
+Bellevue:
+]
      
+
+
+
      
+If no proposed wording by June meeting, this issue should be closed NAD.
+
      
+
+
 
 
      Proposed resolution:
      
         
      
@@ -8216,6 +7652,7 @@ away.
 
      
 
 
+
 
      Proposed resolution:
      
 
      
 
      
@@ -8229,6 +7666,17 @@ O(1). Alan has volunteered to provide wording.
 ]
      
 
 
+
      [
+Bellevue:
+]
      
+
+
+
      
+Mandating O(1) size will not fly, too many implementations would be
+invalidated. Alan to provide wording that toughens wording, but that
+does not absolutely mandate O(1).
+
      
+
 
 
 
@@ -8317,9 +7765,9 @@ no resolution to this issue was recorded.  Moved to Open.
 
 
      
 
      638. deque end invalidation during erase
      
-
      Section: 23.2.2.3 [deque.modifiers] Status: Review
+
      Section: 23.2.2.3 [deque.modifiers] Status: Ready
  Submitter: Steve LoBasso Date: 2007-02-17
      
-
      View all issues with Review status.
      
+
      View all issues with Ready status.
      
 
      Discussion:
      
 
      
 The standard states at 23.2.2.3 [deque.modifiers]/4:
@@ -8353,6 +7801,17 @@ pop_front() with size() == 1
 
 
    
 
+
    [
+Post Kona, Steve LoBasso notes:
+]
    
+
+
+
    
+My only issue with the proposed resolution is that it might not be clear
+that pop_front() [where size() == 1] can invalidate past-the-end
+iterators.
+
    
+
 
 
 
    Proposed resolution:
    
@@ -8384,189 +7843,19 @@ Kona (2007): Proposed wording added and moved to Review.
 ]
    
 
 
-
-
-
-
    
-
    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:
    
-
    
-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:
-
    
-
-
    
-1) The members
-
    
-
-
    const_iterator rbegin() const;
-const_iterator rend() const;
-
    
-
-
    
-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.
-
    
-
    
-2) The new "convenience" members
-
    
-
    const_iterator cbegin() const;
-const_iterator cend() const;
-const_iterator crbegin() const;
-const_iterator crend() const;
-
    
-
    
-should be added according to tables 80/81.
-
    
-
-
-
    Proposed resolution:
    
-
    
-Add the following members to the match_results synopsis after end() in 28.10 [re.results]
-para 3:
-
    
-
-
    const_iterator cbegin() const; 
-const_iterator cend() const;
-
    
-
-
    
-In section 28.10.3 [re.results.acc] change:
-
    
-
-
    
-
    const_iterator begin() const;
-const_iterator cbegin() const;
-
    
-
    
-
    
--7- Returns: A starting iterator that enumerates over all the sub-expressions stored in *this.
-
    
-
    
-
-
    const_iterator end() const;
-const_iterator cend() const;
-
    
-
    
-
    
--8- Returns: A terminating iterator that enumerates over all the sub-expressions stored in *this.
-
    
-
    
-
    
-
-
-
 
    [
-Kona (2007): Voted to adopt proposed wording in
-N2409
-except removing the entry in the table container requirements.  Moved to Review.
+Bellevue:
 ]
    
 
 
-
-
-
-
    
-
    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:
    
-
    
-
    
 
    
-
    
-1.2 [intro.refs] Normative references
-
    
-
-
    
-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.
-
    
-
-
      
-
    • 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
      • 
-
    
+Note that there is existing code that relies on iterators not being
+invalidated, but there are also existing implementations that do
+invalidate iterators. Thus, such code is not portable in any case. There
+is a pop_front() note, which should possibly be a separate issue. Mike
+Spertus to evaluate and, if need be, file an issue.
 
    
 
-
    
-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!
-
    
-
    
-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.
-]
    
-
-
-
-
-
    Proposed resolution:
    
-
-
 
 
 
@@ -8581,26 +7870,26 @@ specific documents add their rules to this issue until the list is complete.
 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
+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> 
+
     #include <iostream> 
+ #include <fstream>
+ #include <streambuf> 
 
- typedef char C;
- int main ()
- {
-   std::ifstream s("filename", std::ios::in);
-   std::istreambuf_iterator<char> i(s);
+ 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!
- }
+   (*i).~C();  // This is well-formed...
+   i->~C();  // ... so this should be supported!
+ }
 
    
 
 
    
@@ -8608,9 +7897,9 @@ 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,
+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
+address.  Or by returning a proxy, like operator_arrow_proxy, from
 http://www.boost.org/boost/iterator/iterator_facade.hpp
 
    
 
    
@@ -8671,14 +7960,14 @@ may in fact be a proxy.
 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.
+definition.  I don't think Iter::pointer needs to be a raw pointer.
 
    
 
    
 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
+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
+(*i).m. Even for an explicit destructor call, i->~C().  The main issue
 is just: istreambuf_iterator should have an operator->()!
 
    
 
    
@@ -8686,248 +7975,6 @@ is just: istreambuf_iterator should have an operator->()!
 
 
 
-
    
-
    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:
    
-
    
-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. 
-
      
-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);
-
      
-
-
      
-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. 
-
    
-
-
-
    [
-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.
-]
    
-
-
-
-
-
-
    
-
    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:
    
-
    
-22.2.1.4.2 [locale.codecvt.virtuals], para 7 says (regarding do_unshift):
-
    
-
-
    
-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.
-
    
-
-
    
-The following objection has been raised:
-
    
-
-
    
-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.
-
    
-
-
    
-[Plum ref _222152Y50]
-
    
-
-
-
    Proposed resolution:
    
-
    
-Change 22.2.1.4.2 [locale.codecvt.virtuals], p7:
-
    
-
-
    
-
    
-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.
-
    
-
    
-
-
-
-
-
-
    
-
    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.
-
    
-
-
    
-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.
-
    
-
-
    
-[Plum ref _222152Y62]
-
    
-
-
-
    Proposed resolution:
    
-
    
-Change 22.2.1.4.2 [locale.codecvt.virtuals], p8:
-
    
-
-
    
-
    Returns: An enumeration value, as summarized in Table 76:
    
-
    ...
    
-
    
-codecvt<char,char,mbstate_t>, returns noconv.
-
    
-
    
-
-
-
-
-
-
-
    
-
    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:
    
-
    
-22.2.6.3.2 [locale.moneypunct.virtuals], para 4 footnote 257 says
-
    
-
-
    
-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:
-
    
-
-
    
-The international currency 
-symbol is whatever the underlying locale says it is, not necessarily 
-four characters long.
-
    
-
-
    
-[Plum ref _222632Y41]
-
    
-
-
-
    Proposed resolution:
    
-
    
-Change footnote 253 in 22.2.6.3.2 [locale.moneypunct.virtuals]:
-
    
-
-
    
-
    
-253) For international specializations (second template
-parameter true) this is always typically
-four characters long, usually three letters and a space.
-
    
-
    
-
-
-
-
-
 
    
 
    667. money_get's widened minus sign
    
 
    Section: 22.2.6.1.2 [locale.money.get.virtuals] Status: Open
@@ -8941,9 +7988,9 @@ four characters long, usually three letters and a space.
 
    
 
 
    
-The result is returned as an integral value 
-stored in units or as a sequence of digits possibly preceded by a 
-minus sign (as produced by ct.widen(c) where c is '-' or in the range 
+The result is returned as an integral value 
+stored in units or as a sequence of digits possibly preceded by a 
+minus sign (as produced by ct.widen(c) where c is '-' or in the range 
 from '0' through '9', inclusive) stored in digits.
 
    
 
@@ -8956,10 +8003,10 @@ 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
+'@' 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?
+implementation to "hard-wire" L'-' as the "widened" minus sign.  Are
+both interpretations permissible, or only  one?
 
    
 
 
    
@@ -8976,6 +8023,18 @@ Kona (2007): Bill and Dietmar to provide proposed wording.
 ]
    
 
 
+
    [
+post Bellevue: Bill adds:
+]
    
+
+
+
    
+The Standard is clear that the minus sign stored in digits is ct.widen('-').
+The subject string must contain characters c in the set [-0123456789]
+which are translated by ct.widen(c) calls before being stored in digits;
+the widened characters are not relevant to the parsing of the subject string.
+
    
+
 
 
    Proposed resolution:
    
 
    
@@ -8999,7 +8058,7 @@ Kona (2007): Bill and Dietmar to provide proposed wording.
 
 
    
 If pos or neg is empty, the sign component is
-optional, and if no sign is detected, the result is given the sign 
+optional, and if no sign is detected, the result is given the sign 
 that corresponds to the source of the empty string.
 
    
 
@@ -9009,8 +8068,8 @@ objection has been raised:
 
    
 
 
    
-A negative_sign of "" means "there is no 
-way to write a negative sign" not "any null sequence is a negative 
+A negative_sign of "" means "there is no 
+way to write a negative sign" not "any null sequence is a negative 
 sign, so it's always there when you look for it".
 
    
 
@@ -9046,14 +8105,14 @@ Kona (2007): Bill to provide proposed wording and interpretation of existing wor
 
    
 
 
    
-If the first character of pos is equal to the first character of neg, 
+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.
 
    
 
 
    
 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:
+is interpreted as positive.  The following objections has been raised:
 
    
 
 
    
@@ -9091,7 +8150,7 @@ Bill to provide proposed wording and interpretation of existing wording.
 
    
 
 
    
-The value space indicates that at least one space is required at 
+The value space indicates that at least one space is required at 
 that position.
 
    
 
@@ -9100,7 +8159,7 @@ The following objection has been raised:
 
    
 
 
    
-Whitespace is optional when matching space. (See 22.2.6.1.2 [locale.money.get.virtuals], para 2.)
+Whitespace is optional when matching space. (See 22.2.6.1.2 [locale.money.get.virtuals], para 2.)
 
    
 
 
    
@@ -9201,11 +8260,11 @@ Kona (2007): Robert volunteers to propose wording.
 
 
    
 
    672. Swappable requirements need updating
    
-
    Section: 20.1.1 [utility.arg.requirements] Status: Review
+
    Section: 20.1.1 [utility.arg.requirements] Status: Ready
  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.
    
+
    View all issues with Ready status.
    
 
    Discussion:
    
 
    
 The current Swappable is:
@@ -9361,16 +8420,18 @@ swap to be rvalues).
 
 
    
 
    673. unique_ptr update
    
-
    Section: 20.6.5 [unique.ptr] Status: Open
+
    Section: 20.6.11 [unique.ptr] Status: Ready
  Submitter: Howard Hinnant Date: 2007-05-04
    
-
    View all issues with Open status.
    
+
    View other active issues in [unique.ptr].
    
+
    View all other issues in [unique.ptr].
    
+
    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
+example implmenation
 for all of these changes.
 
    
 
@@ -9405,7 +8466,7 @@ 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
+type (example 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)
@@ -9482,7 +8543,7 @@ the proposed resolutions below.
 
  • 
 
 
    
-Change 20.6.5.2 [unique.ptr.single]:
+Change 20.6.11.2 [unique.ptr.single]:
 
    
 
 
    template <class T, class D = default_delete<T>> class unique_ptr {
@@ -9493,7 +8554,7 @@ Change 20.6.5.2 [unique.ptr.single]:
 
    
 
 
    
-Change 20.6.5.2.4 [unique.ptr.single.observers]:
+Change 20.6.11.2.4 [unique.ptr.single.observers]:
 
    
 
 
    T& typename add_lvalue_reference<T>::type operator*() const;
@@ -9503,7 +8564,7 @@ Change 20.6.5.2.4 [unique.ptr.single.observers]:
 
 
  • 
 
    
-Change 20.6.5.2 [unique.ptr.single]:
+Change 20.6.11.2 [unique.ptr.single]:
 
    
 
 
    template <class T, class D = default_delete<T>> class unique_ptr {
@@ -9529,13 +8590,13 @@ public:
 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
+The type unique_ptr<T, D>::pointer shall be CopyConstructible
 and CopyAssignable.
 
 
    
 
 
    
-Change 20.6.5.2.1 [unique.ptr.single.ctor]:
+Change 20.6.11.2.1 [unique.ptr.single.ctor]:
 
    
 
 
    unique_ptr(T* pointer p);
@@ -9557,10 +8618,10 @@ 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
+must shall be well formed and not throw an exception. If D is a
+reference type, then E must shall be the same type as D
 (diagnostic required). U* unique_ptr<U,E>::pointer
-must be implicitly convertible to T*
+must shall be implicitly convertible to T*
 pointer.
 
    
 
@@ -9575,20 +8636,20 @@ internally stored deleter which was constructed from
 
    
 
 
    
-Change 20.6.5.2.3 [unique.ptr.single.asgn]:
+Change 20.6.11.2.3 [unique.ptr.single.asgn]:
 
    
 
 
    
 
    
 -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
+D must shall not throw an exception. U*
+unique_ptr<U,E>::pointer must shall be implicitly
 convertible to T* pointer.
 
    
 
    
 
 
    
-Change 20.6.5.2.4 [unique.ptr.single.observers]:
+Change 20.6.11.2.4 [unique.ptr.single.observers]:
 
    
 
 
    
@@ -9598,7 +8659,7 @@ Change 20.6.5.2.4 [unique.ptr.single.observers]:
 
    
 
 
    
-Change 20.6.5.2.5 [unique.ptr.single.modifiers]:
+Change 20.6.11.2.5 [unique.ptr.single.modifiers]:
 
    
 
 
    
@@ -9608,7 +8669,7 @@ Change 20.6.5.2.5 [unique.ptr.single.modifiers]:
 
    
 
 
    
-Change 20.6.5.3 [unique.ptr.runtime]:
+Change 20.6.11.3 [unique.ptr.runtime]:
 
    
 
 
    template <class T, class D> class unique_ptr<T[], D> {
@@ -9628,7 +8689,7 @@ public:
 
    
 
 
    
-Change 20.6.5.3.1 [unique.ptr.runtime.ctor]:
+Change 20.6.11.3.1 [unique.ptr.runtime.ctor]:
 
    
 
 
    
@@ -9647,7 +8708,7 @@ these members. -- end note]
 
    
 
 
    
-Change 20.6.5.3.3 [unique.ptr.runtime.modifiers]:
+Change 20.6.11.3.3 [unique.ptr.runtime.modifiers]:
 
    
 
 
    
@@ -9662,89 +8723,53 @@ templated overload. -- end note]
 
    
 
    
 
-
    
-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());
-};
-
    
-
-
    
-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]
-
    
-
-
    
-
 
    • 
 
 
  • 
 
 
    
-Change 20.6.5.2.1 [unique.ptr.single.ctor]:
+Change 20.6.11.2.1 [unique.ptr.single.ctor]:
 
    
 
 
    
 
    unique_ptr();
    
 
    
 
    
-Requires: D must be default constructible, and that
-construction must not throw an exception. D must not be a
+Requires: D must shall be default constructible, and that
+construction must shall not throw an exception. D must shall not be a
 reference type or pointer type (diagnostic required).
 
    
 
    
 
    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
+Requires:  The expression D()(p) must shall be well formed.
+The default constructor of D must shall not throw an exception.
+D must shall not be a reference type or pointer type (diagnostic
 required).
 
    
 
    
 
    
 
 
    
-Change 20.6.5.2.1 [unique.ptr.single.ctor]:
+Change 20.6.11.2.1 [unique.ptr.single.ctor]:
 
    
 
 
    
 
    unique_ptr();
    
 
    
 
    
-Requires: D must be default constructible, and that
-construction must not throw an exception. D must not be a
+Requires: D must shall be default constructible, and that
+construction must shall not throw an exception. D must shall not be a
 reference type or pointer type (diagnostic required).
 
    
 
    
 
    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
+Requires:  The expression D()(p) must shall be well formed.
+The default constructor of D must shall not throw an exception.
+D must shall not be a reference type or pointer type (diagnostic
 required).
 
    
 
    
@@ -9759,110 +8784,13 @@ required).
 
 
 
-
    
-
    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:
    
-
    
-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.
-
    
-
-
-
    Proposed resolution:
    
-
-
    
-Change 20.6.6.2 [util.smartptr.shared] as follows:
-
    
-
-
    
-
    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);
    
-
    
-
-
    
-Change 20.6.6.2.1 [util.smartptr.shared.const] as follows:
-
    
-
-
    
-
    template<class Y> shared_ptr(auto_ptr<Y>&&& r);
    
-
    
-
-
    
-Add to 20.6.6.2.1 [util.smartptr.shared.const]:
-
    
-
-
    
-
    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.
-
    
-
    
-
-
    
-
-
    
-Change 20.6.6.2.3 [util.smartptr.shared.assign] as follows:
-
    
-
-
    
-
    template<class Y> shared_ptr& operator=(auto_ptr<Y>&&& r);
    
-
    
-
-
    
-Add to 20.6.6.2.3 [util.smartptr.shared.assign]:
-
    
-
-
    
-
    template<class Y, class D> shared_ptr& operator=(unique_ptr<Y,D>&& r);
    
-
-
    
-
    
--4- Effects: Equivalent to shared_ptr(std::move(r)).swap(*this).
-
    
-
    
--5- Returns: *this.
-
    
-
    
-
-
    
-
-
-
-
    [
-Kona (2007): We may need to open an issue (743) to deal with the question of
-whether shared_ptr needs an rvalue swap.
-]
    
-
-
-
-
-
 
    
 
    675. Move assignment of containers
    
-
    Section: 23.1 [container.requirements] Status: Ready
+
    Section: 23.1 [container.requirements] Status: Open
  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.
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
 James Hopkin pointed out to me that if vector<T> move assignment is O(1)
@@ -9928,16 +8856,30 @@ before this construction
 
 
 
+
    [
+post Bellevute Howard adds:
+]
    
+
+
+
    
+
    
+This issue was voted to WP in Bellevue, but accidently got stepped on by
+N2525
+which was voted to WP simulataneously.  Moving back to Open for the purpose of getting
+the wording right.  The intent of this issue and N2525 are not in conflict.
+
    
+
    
+
 
 
 
 
    
 
    676. Moving the unordered containers
    
-
    Section: 23.4 [unord] Status: Ready
+
    Section: 23.4 [unord] Status: Open
  Submitter: Howard Hinnant Date: 2007-05-05
    
 
    View other active issues in [unord].
    
 
    View all other issues in [unord].
    
-
    View all issues with Ready status.
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
 Move semantics are missing from the unordered containers.  The proposed
@@ -10535,311 +9477,45 @@ Add to 23.4.4.2 [unord.multiset.swap]:
 
 
 
-
-
-
-
    
-
    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:
+Voted to WP in Bellevue.
 ]
    
 
 
-
    
-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.
+post Bellevue, Pete notes:
 ]
    
 
 
-
-
    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.
+Please remind people who are reviewing issues to check that the text
+modifications match the current draft. Issue 676, for example, adds two
+overloads for unordered_map::insert taking a hint. One takes a
+const_iterator and returns a const_iterator, and the other takes an
+iterator and returns an iterator. This was correct at the time the issue
+was written, but was changed in Toronto so there is only one hint
+overload, taking a const_iterator and returning an iterator.
 
    
-
    
-
    
-
-
    
-
    template<class BidirectionalIterator, class Allocator> 
-  bool operator!=(const match_results<BidirectionalIterator, Allocator>& m1, 
-                  const match_results<BidirectionalIterator, Allocator>& m2);
-
    
-
    
 
    
-Returns: !(m1 == m2).
+This issue is not ready. In addition to the relatively minor signature
+problem I mentioned earlier, it puts requirements in the wrong places.
+Instead of duplicating requirements throughout the template
+specifications, it should put them in the front matter that talks about
+requirements for unordered containers in general. This presentation
+problem is editorial, but I'm not willing to do the extensive rewrite
+that it requires. Please put it back into Open status.
 
    
 
    
-
    
-
-
    
-
    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
+
    Section: 24.4.1.3.19 [reverse.iter.opdiff], 24.4.3.3.14 [move.iter.nonmember] Status: Ready
  Submitter: Bo Persson Date: 2007-06-10
    
-
    View all issues with Review status.
    
+
    View all issues with Ready status.
    
 
    Discussion:
    
 
    
 In C++03 the difference between two reverse_iterators
@@ -10855,8 +9531,8 @@ In the current draft, the operator is defined as 24.4.1.3.19 [reverse.iter.opdif
 
    
 
    template<class Iterator1, class Iterator2> 
 typename reverse_iterator<Iterator>::difference_type 
-   operator-(const reverse_iterator<Iterator1>& x, 
-                    const reverse_iterator<Iterator2>& y);
+   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 
@@ -10882,13 +9558,8 @@ 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));
+    const reverse_iterator<Iterator2>& y) -> decltype(y.current - x.current);
 
    
-
    
-
    
-Returns: y.current - x.current.
-
    
-
    
 
    
 
 
    
@@ -10899,7 +9570,7 @@ 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));
+    const reverse_iterator<Iterator2>& y) -> decltype(y.current - x.current);
 
    
 
    
 
    
@@ -10917,13 +9588,8 @@ 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));
+    const move_iterator<Iterator2>& y) -> decltype(x.base() - y.base());
 
    
-
    
-
    
-Returns: y.current - x.current.
-
    
-
    
 
    
 
 
    
@@ -10934,7 +9600,7 @@ 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));
+    const move_iterator<Iterator2>& y) -> decltype(x.base() - y.base());
 
    
 
    
 
    
@@ -10943,122 +9609,23 @@ Change 24.4.3.3.14 [move.iter.nonmember]:
 
    
 
    • 
 
-
-
-
-
-
    
-
    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.
+Pre Bellevue:  This issue needs to wait until the auto -> return language feature
+goes in.
 ]
    
 
 
 
 
 
-
    
-
    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
+
    Section: 20.5.5.1 [refwrap.const] Status: Open
  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.
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
 A reference_wrapper can be constructed from an rvalue, either by using
@@ -11076,60 +9643,13 @@ Also please see the thread starting at c++std-lib-17398 for some good discussion
 
 
    Proposed resolution:
    
 
    
-In 20.5.5 [refwrap], add:
+In 20.5 [function.objects], add the following two signatures to the synopsis:
 
    
 
-
    private:
-  explicit reference_wrapper(T&&);
+
    template <class T> void ref(const T&& t) = delete;
+template <class T> void cref(const T&& t) = delete;
 
    
 
-
    
-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.
-
    
-
    
-
    
-
 
 
 
    [
@@ -11138,35 +9658,20 @@ addresses the first part of the resolution but not the second.
 ]
    
 
 
+
    [
+Bellevue:  Doug noticed problems with the current wording.
+]
    
 
 
-
-
    
-
    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.
-
    
+
    [
+post Bellevue:  Howard and Peter provided revised wording.
+]
    
 
 
-
    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.
-
    
+
    [
+This resolution depends on a "favorable" resolution of CWG 606:  that is,
+the "special deduction rule" is disabled with the const T&& pattern.
+]
    
 
 
 
@@ -11260,9 +9765,10 @@ const_local_iterator cend(size_type n) const;
 
 
 
    
-
    692. get_money and put_money should be formatted I/O functions
    
+
    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 other active issues in [ext.manip].
    
 
    View all other issues in [ext.manip].
    
 
    View all issues with New status.
    
 
    Discussion:
    
@@ -11270,15 +9776,15 @@ const_local_iterator cend(size_type n) const;
 In a private email Bill Plauger notes:
 
    
 
    
-I  believe that  the function  that  implements get_money
+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
+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
+The words  don't say that  right now and  I'm far from  convinced that
 such a change is editorial.
 
    
 
    
@@ -11291,19 +9797,19 @@ formatted I/O functions do. The text in N2072 assumes so but the
 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
+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
+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)
+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]).
 
    
@@ -11312,253 +9818,25 @@ 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
+if in is  an object of type basic_istream<charT,
+traits>    then    the    expression   in >> get_money(mon, intl) behaves as a formatted input function
+that    calls    f(in, mon, intl)    were
 called. The function f can be defined as...
 
    
 
 
+
    [
+post Bellevue:
+]
    
 
 
-
-
    
-
    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().
+We recommend moving immediately to Review. We've looked at the issue and
+have a consensus that the proposed resolution is correct, but want an
+iostream expert to sign off. Alisdair has taken the action item to putt
+this up on the reflector for possible movement by Howard to Tenatively
+Ready.
 
    
-
    
-
-
    
-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;
-
    
-
    
-
 
 
 
@@ -11567,7 +9845,6 @@ 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:
    
@@ -11613,66 +9890,6 @@ prevent the facet from storing the value.
 
 
 
-
    
-
    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:
    
-
    
-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:
-
    
-
-
    #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
@@ -11705,50 +9922,6 @@ accepting a const char*.
 
 
 
-
    
-
    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
@@ -11761,11 +9934,11 @@ 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
+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
+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.
@@ -11773,7 +9946,7 @@ 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 
+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.
 
    
@@ -11794,7 +9967,7 @@ current ones to double.
 
    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
+One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should  be
 |x| <= 1, not x >= 0.
    
 
 
@@ -11806,32 +9979,6 @@ One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should&nb
 
 
 
-
    
-
    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
@@ -11970,6 +10117,11 @@ Kona (2007): Howard and Alan to update requirements table in issue with emplace
 ]
    
 
 
+
    [
+Bellevue: This should be handled as part of the concepts work.
+]
    
+
+
 
 
 
    Proposed resolution:
    
@@ -11979,144 +10131,6 @@ Kona (2007): Howard and Alan to update requirements table in issue with emplace
 
 
 
-
    
-
    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:
    
-
    
-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.
-
    
-
-
-
    Proposed resolution:
    
-
    
-In 20.2 [utility] change the synopsis for make_pair() to read
-
    
-
-
    template <class T1, class T2>
-  pair<typename decay<T1>::type V1, typename decay<T2>::type V2> make_pair(T1&&, T2&&);
-
    
-
-
    
-In 20.2.3 [pairs]/16 change the declaration to match the above synopsis.
-Then change the 20.2.3 [pairs]/17 to:
-
    
-
-
    
-
    
-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.
-
    
-
    
-
-
-
-
-
-
-
    
-
    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:
    
-
-
    
-From the Toronto Core wiki:
-
    
-
-
    
-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".
-
    
-
-
    
-Peter's response:
-
    
-
-
    
-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.
-
    
-
-
-
-
    Proposed resolution:
    
-
    
-
    
-
-
-
-
-
 
    
 
    708. Locales need to be per thread and updated for POSIX changes
    
 
    Section: 22 [localization] Status: Open
@@ -12167,60 +10181,13 @@ Kona (2007): Bill and Nick to provide wording.
 
 
 
-
    
-
    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:
    
-
    
-The changes made for constexpr in 21.1.3 [char.traits.specializations] have 
-not only changed the not_eof function from pass by const reference to 
-pass by value, it has also changed the parameter type from int_type to 
-char_type.
-
    
-
    
-This doesn't work for type char, and is inconsistent with the 
-requirements in Table 56, Traits requirements, 21.1.1 [char.traits.require].
-
    
-
-
    
-Pete adds:
-
    
-
-
    
-For what it's worth, that may not have been an intentional change. 
-N2349, which detailed the changes for adding constant expressions to 
-the library, has strikeout bars through the const and the & that 
-surround the char_type argument, but none through char_type itself. 
-So the intention may have been just to change to pass by value, with 
-text incorrectly copied from the standard.
-
    
-
-
-
-
    Proposed resolution:
    
-
    
-Change the signature in 21.1.3.1 [char.traits.specializations.char],
-21.1.3.2 [char.traits.specializations.char16_t], 21.1.3.3 [char.traits.specializations.char32_t],
-and 21.1.3.4 [char.traits.specializations.wchar.t] to
-
    
-
-
    static constexpr int_type not_eof(char_type int_type c);
-
    
-
-
-
-
-
-
 
    
 
    710. Missing postconditions
    
-
    Section: 20.6.6.2 [util.smartptr.shared] Status: New
+
    Section: 20.6.12.2 [util.smartptr.shared] Status: Ready
  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.
    
+
    View all issues with Ready status.
    
 
    Discussion:
    
 
    
 A discussion on
@@ -12230,10 +10197,27 @@ The shared_ptr move constructor and the cast functions are
 missing postconditions for the get() accessor.
 
    
 
+
    [
+Bellevue:
+]
    
+
+
+
    
+
    
+Move to "ready", adopting the first (Peter's) proposed resolution.
+
    
+
    
+Note to the project editor: there is an editorial issue here. The
+wording for the postconditions of the casts is slightly awkward, and the
+editor should consider rewording "If w is the return value...", e. g. as
+"For a return value w...".
+
    
+
    
+
 
 
    Proposed resolution:
    
 
    
-Add to 20.6.6.2.1 [util.smartptr.shared.const]:
+Add to 20.6.12.2.1 [util.smartptr.shared.const]:
 
    
 
 
    
@@ -12249,7 +10233,7 @@ shall be empty. r.get() == 0.
 
    
 
 
    
-Add to 20.6.6.2.10 [util.smartptr.shared.cast]:
+Add to 20.6.12.2.10 [util.smartptr.shared.cast]:
 
    
 
 
    
@@ -12292,7 +10276,7 @@ the aliasing constructor as follows:
 
    
 
 
    
-Change 20.6.6.2.10 [util.smartptr.shared.cast]:
+Change 20.6.12.2.10 [util.smartptr.shared.cast]:
 
    
 
 
    
@@ -12339,10 +10323,10 @@ in the aliasing constructor postcondition "by reference".
 
 
    
 
    711. Contradiction in empty shared_ptr
    
-
    Section: 20.6.6.2.5 [util.smartptr.shared.obs] Status: New
+
    Section: 20.6.12.2.5 [util.smartptr.shared.obs] Status: Review
  Submitter: Peter Dimov Date: 2007-08-24
    
 
    View all other issues in [util.smartptr.shared.obs].
    
-
    View all issues with New status.
    
+
    View all issues with Review status.
    
 
    Discussion:
    
 
    
 A discussion on
@@ -12371,7 +10355,7 @@ with a non-NULL stored pointer.
 
    
 
 
    
-This is contradicted by the second sentence in the Returns clause of 20.6.6.2.5 [util.smartptr.shared.obs]:
+This is contradicted by the second sentence in the Returns clause of 20.6.12.2.5 [util.smartptr.shared.obs]:
 
    
 
 
    
@@ -12382,11 +10366,34 @@ This is contradicted by the second sentence in the Returns clause of 20.6.6.2.5
 
    
 
    
 
+
    [
+Bellevue:
+]
    
+
+
+
    
+
    
+Adopt option 1 and move to review, not ready.
+
    
+
    
+There was a lot of confusion about what an empty shared_ptr is (the term
+isn't defined anywhere), and whether we have a good mental model for how
+one behaves. We think it might be possible to deduce what the definition
+should be, but the words just aren't there. We need to open an issue on
+the use of this undefined term. (The resolution of that issue might
+affect the resolution of issue 711.)
+
    
+
    
+The LWG is getting more uncomfortable with the aliasing proposal (N2351)
+now that we realize some of its implications, and we need to keep an eye
+on it, but there isn't support for removing this feature at this time.
+
    
+
    
 
 
 
    Proposed resolution:
    
 
    
-In keeping the N2351 spirit and obviously my preference, change 20.6.6.2.5 [util.smartptr.shared.obs]:
+In keeping the N2351 spirit and obviously my preference, change 20.6.12.2.5 [util.smartptr.shared.obs]:
 
    
 
 
    
@@ -12402,7 +10409,7 @@ Alternative proposed resolution: (I won't be happy if we do this, but it's possi
 
    
 
 
    
-Change 20.6.6.2.1 [util.smartptr.shared.const]:
+Change 20.6.12.2.1 [util.smartptr.shared.const]:
 
    
 
 
    
@@ -12517,10 +10524,11 @@ template<class ForwardIterator, class Size, class T,
 
 
    
 
    715. minmax_element complexity is too lax
    
-
    Section: 25.3.7 [alg.min.max] Status: New
+
    Section: 25.3.7 [alg.min.max] Status: Ready
  Submitter: Matt Austern Date: 2007-08-30
    
+
    View other active issues in [alg.min.max].
    
 
    View all other issues in [alg.min.max].
    
-
    View all issues with New status.
    
+
    View all issues with Ready status.
    
 
    Discussion:
    
 
    
 The complexity for minmax_element (25.3.7 [alg.min.max] par 16) says "At most max(2 *
@@ -12549,12 +10557,11 @@ template<class ForwardIterator, class Compare>
 
    
 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
+comp) the first iterator in [first,
+last) such that no iterator in the range refers to a smaller element, 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.
+in [first, last) such that no iterator in the range refers to a larger element.
 
    
 
    
 Complexity: At most max(2 * (last - first ) - 2, 0)
@@ -12615,73 +10622,13 @@ Remove this mention of the CharacterClass production.
 
 
 
-
    
-
    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:
    
-
    
-Change 26.5.2.3 [valarray.access]:
-
    
-
-
    
-
    
--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.
-
    
-
-
    
--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)
-
    
-
-
    
--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.
-
    
-
-
    
-
-
-
-
-
-
 
    
 
    718. basic_string is not a sequence
    
-
    Section: 21.3 [basic.string] Status: New
+
    Section: 21.3 [basic.string] Status: Open
  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.
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
 Paragraph 21.3 [basic.string]/3 states:
@@ -12701,6 +10648,33 @@ Secondly, after the resent changes to containers (emplace, push_bac
 even close to conform to the current requirements.
 
    
 
+
    [
+Bellevue:
+]
    
+
+
+
    
+
      
+
    • emplace, for example, may not make sense for strings. Is also likely suboptimal
      • 
+
    • with concepts do we need to maintain string as sequence container?
      • 
+
    • One approach might be to say something like: string is a sequence except it doesn't have these functions
      • 
+
    
+
      
+
    • basic_string already has push_back
      • 
+
    • const_iterator parameters to insert and erase should be added to basic_string
      • 
+
    • this leaves emplace to handle -- we have the following options:
+
        
+
      • option 1: add it to string even though it's optional
        • 
+
      • option 2: make emplace optional to sequences (move from table 89 to 90)
        • 
+
      • option 3: say string not sequence (the proposal),
        • 
+
      • option 4: add an exception to basic string wording.
        • 
+
      
+
      • 
+
    
+General consensus is to suggest option 2.
+
    
+
+
 
 
    Proposed resolution:
    
 
    
@@ -12715,10 +10689,10 @@ different, a string abstraction in its own right.
 
 
    
 
    719. std::is_literal type traits should be provided
    
-
    Section: 20.4 [meta] Status: New
+
    Section: 20.4 [meta] Status: Open
  Submitter: Daniel Krügler Date: 2007-08-25
    
 
    View all other issues in [meta].
    
-
    View all issues with New status.
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
 Since the inclusion of constexpr in the standard draft N2369 we have
@@ -12796,6 +10770,14 @@ reference type (instead of const T& we could decide to
 use T&&, but that is another issue).
 
    
 
+
    [
+Alisdair is considering preparing a paper listing a number of missing
+type traits, and feels that it might be useful to handle them all
+together rather than piecemeal. This would affect issue 719 and 750.
+These two issues should move to OPEN pending AM paper on type traits.
+]
    
+
+
 
 
 
    Proposed resolution:
    
@@ -12839,11 +10821,11 @@ array of unknown bound, or
 
 
    
 
    720. Omissions in constexpr usages
    
-
    Section: 23.2.1 [array], 23.3.5 [template.bitset] Status: New
+
    Section: 23.2.1 [array], 23.3.5 [template.bitset] Status: Open
  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.
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
      
 
    1. 
@@ -12936,11 +10918,11 @@ void main()
 
 
      
 
      722. Missing [c.math] functions nanf and nanl
      
-
      Section: 26.7 [c.math] Status: New
+
      Section: 26.7 [c.math] Status: Ready
  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.
      
+
      View all issues with Ready status.
      
 
      Discussion:
      
 
      
 In the listing of 26.7 [c.math], table 108: Header <cmath> synopsis I miss
@@ -13080,11 +11062,11 @@ to describe these additions.
 
 
      
 
      724. DefaultConstructible is not defined
      
-
      Section: 20.1.1 [utility.arg.requirements] Status: New
+
      Section: 20.1.1 [utility.arg.requirements] Status: Open
  Submitter: Pablo Halpern Date: 2007-09-12
      
 
      View other active issues in [utility.arg.requirements].
      
 
      View all other issues in [utility.arg.requirements].
      
-
      View all issues with New status.
      
+
      View all issues with Open status.
      
 
      Discussion:
      
 
      
 The DefaultConstructible requirement is referenced in
@@ -13093,6 +11075,43 @@ several places in the August 2007 working draft
 but is not defined anywhere.
 
      
 
+
      [
+Bellevue:
+]
      
+
+
+
      
+
      
+Walking into the default/value-initialization mess...
+
      
+
      
+Why two lines? Because we need both expressions to be valid.
+
      
+
      
+AJM not sure what the phrase "default constructed" means. This is
+unfortunate, as the phrase is already used 24 times in the library!
+
      
+
      
+Example: const int would not accept first line, but will accept the second.
+
      
+
      
+This is an issue that must be solved by concepts, but we might need to solve it independantly first.
+
      
+
      
+It seems that the requirements are the syntax in the proposed first
+column is valid, but not clear what semantics we need.
+
      
+
      
+A table where there is no post-condition seems odd, but appears to sum up our position best.
+
      
+
      
+At a minimum an object is declared and is destuctible.
+
      
+
      
+Move to open, as no-one happy to produce wording on the fly.
+
      
+
      
+
 
 
      Proposed resolution:
      
 
      
@@ -13133,42 +11152,6 @@ following table:
 
 
 
-
      
-
      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)
-
      
-
-
      
-Surely that's meant to be "operational semantics?"
-
      
-
-
-
-
      Proposed resolution:
      
-
      
-
-
-
-
-
-
      Table 90: Optional sequence container operations
      expression return type assertion/note
      pre/post-condition
       operational semantics      		 container
      
-
      
-
-
-
-
-
-
 
      
 
      726. Missing regex_replace() overloads
      
 
      Section: 28.11.4 [re.alg.replace] Status: New
@@ -13190,7 +11173,7 @@ Two overloads of regex_replace() are currently provided:
                 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, 
@@ -13202,7 +11185,7 @@ template <class traits, class charT>
 
 
        
 
      1. Overloads taking const charT * are provided for regex_match() and
-regex_search(), but not regex_replace().  This is inconsistent.
        2. 
+regex_search(), but not regex_replace().  This is inconsistent.
 
      2. 
 
        The absence of const charT * overloads prevents ordinary-looking code from compiling, such as:
        
 
@@ -13219,9 +11202,9 @@ char[1]'".
 
 
        
 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
+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
+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).
@@ -13229,10 +11212,10 @@ indicates, template argument deduction fails first).
 
 
        
 If a user figures out what the compiler error message means, workarounds
-are available - but they are all verbose.  Explicit template arguments
+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
+the first, so this would be extremely verbose.  Therefore, constructing
 a basic_string from each C string is the simplest workaround.
 
        
 
        3. 
@@ -13240,7 +11223,7 @@ a basic_string from each C string is the simplest workaround.
 
      3. 
 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. 
+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.)
@@ -13329,7 +11312,7 @@ charT* str and const charT* fmt).  28.11.4 [re.alg.replace]:
 
        Discussion:
        
 
        
 regex_match() and regex_search() take const basic_string<charT, ST,
-SA>&.  regex_replace() takes const basic_string<charT>&.  This prevents
+SA>&.  regex_replace() takes const basic_string<charT>&.  This prevents
 regex_replace() from accepting basic_strings with custom traits and
 allocators.
 
        
@@ -13339,7 +11322,7 @@ allocators.
 
        
 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
+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
@@ -13352,9 +11335,10 @@ arguments.
 
 
        
 
        728. Problem in [rand.eng.mers]/6
        
-
        Section: 26.4.3.2 [rand.eng.mers] Status: New
+
        Section: 26.4.3.2 [rand.eng.mers] Status: Review
  Submitter: Stephan Tolksdorf Date: 2007-09-21
        
-
        View all issues with New status.
        
+
        View all other issues in [rand.eng.mers].
        
+
        View all issues with Review status.
        
 
        Discussion:
        
 
        
 The mersenne_twister_engine is required to use a seeding method that is given 
@@ -13379,184 +11363,66 @@ order) and always employ the 32-bit algorithm for seeding
 
      
 
 
      
-See N2423
+See N2424
 for further discussion.
 
      
 
+
      [
+Bellevue:
+]
      
+
+
+
      
+
      
+Stephan Tolksdorf has additional comments on N2424. He comments: "there
+is a typo in the required behaviour for mt19937_64: It should be the
+10000th (not 100000th) invocation whose value is given, and the value
+should be 9981545732273789042 (not 14002232017267485025)." These values
+need checking.
+
      
+
      
+Take the proposed recommendation in N2424 and move to REVIEW.
+
      
+
      
+
+
 
 
 
      Proposed resolution:
      
 
 
      
-See N2423
+See N2424
 for the proposed resolution.
 
      
 
+
      [
+Stephan Tolksdorf adds pre-Bellevue:
+]
      
 
 
+
      
+I support the proposed resolution in
+N2424,
+but there is a typo in the
+required behaviour for mt19937_64: It should be the 10000th (not
+100000th) invocation whose value is given, and the value should be
+9981545732273789042 (not 14002232017267485025). The change to para. 8
+proposed by Charles Karney should also be included in the proposed
+wording.
+
      
 
 
 
-
      
-
      729. Problem in [rand.req.eng]/3
      
-
      Section: 26.4.1.3 [rand.req.eng] Status: New
- Submitter: Stephan Tolksdorf Date: 2007-09-21
      
-
      View all other issues in [rand.req.eng].
      
-
      View all issues with New status.
      
-
      Discussion:
      
-
      
-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.
-
      
-
-
      
-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."
-
      
-
-
      
-Additionally, the definition of s in 26.4.1.3 [rand.req.eng]/1 c) could be restricted to unsigned integer types.
-
      
-
-
      
-Similarly, the type of the seed in 26.4.1.4 [rand.req.adapt]/3 e) could be left unspecified.
-
      
-
-
      
-See N2423
-for further discussion.
-
      
-
-
-
-
      Proposed resolution:
      
-
      
-See N2423
-for further discussion.
-
      
-
-
-
-
-
-
-
      
-
      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:
      
-
      
-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.
-
      
-
-
      
-Posssible resolution: [As above]
-
      
-
-
      
-See N2423
-for further discussion.
-
      
-
-
-
-
      Proposed resolution:
      
-
      
-See N2423
-for the proposed resolution.
-
      
-
-
-
-
-
-
      
-
      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 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:
-
      
-
-
      
-Possible resolution:
-
      
-
-
        
-
      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:
      
-
      
-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
+
      Section: 26.4.8.5.3 [rand.dist.samp.genpdf] Status: Open
  Submitter: Stephan Tolksdorf Date: 2007-09-21
      
-
      View all issues with New status.
      
+
      View all other issues in [rand.dist.samp.genpdf].
      
+
      View all issues with Open status.
      
+
      Duplicate of: 795
      
 
      Discussion:
      
 
      
 26.4.8.5.3 [rand.dist.samp.genpdf] describes the interface for a distribution template that is 
@@ -13574,41 +11440,46 @@ nightmare.
 Possible resolution: For these reasons, I propose to delete section 26.4.8.5.3 [rand.dist.samp.genpdf].
 
      
 
+
      [
+Bellevue:
+]
      
 
-
      Proposed resolution:
      
+
+
      
 
      
-See N2423
-for the proposed resolution.
+Disagreement persists.
 
      
-
-
-
-
-
-
      
-
      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:
      
 
      
-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.]
+Objection to this issue is that this function takes a general functor.
+The general approach would be to normalize this function, integrate it,
+and take the inverse of the integral, which is not possible in general.
+An example function is sin(1+n*x) -- for any spatial frequency that the
+implementor chooses, there is a value of n that renders that choice
+arbitrarily erroneous.
 
      
-
 
      
-Proposed resolution: I propose to drop this requirement.
+Correction: The formula above should instead read 1+sin(n*x).
 
      
+
      
+Objector proposes the following possible compromise positions:
+
      
+
        
+
      • 
+rand.dist.samp.genpdf takes an number of points so that implementor need not guess.
+
        • 
+
      • replace rand.disk.samp.genpdf with an extension to either or both
+of the discrete functions to take arguments that take a functor and
+number of points in place of the list of probabilities. Reference
+issues 793 and 794.
+
        • 
+
      
+
      
+
 
 
 
      Proposed resolution:
      
 
      
-See N2423
+See N2424
 for the proposed resolution.
 
      
 
@@ -13618,9 +11489,9 @@ for the proposed resolution.
 
 
      
 
      734. Unnecessary restriction in [rand.dist.norm.chisq]
      
-
      Section: 26.4.8.4.3 [rand.dist.norm.chisq] Status: New
+
      Section: 26.4.8.4.3 [rand.dist.norm.chisq] Status: Open
  Submitter: Stephan Tolksdorf Date: 2007-09-21
      
-
      View all issues with New status.
      
+
      View all issues with Open status.
      
 
      Discussion:
      
 
      
 chi_squared_distribution, fisher_f_distribution and student_t_distribution
@@ -13647,197 +11518,107 @@ log-factorial function).
 to double.
 
      
 
-
-
      Proposed resolution:
      
-
      
-See N2423
-for the proposed resolution.
-
      
+
      [
+Bellevue:
+]
      
 
 
-
-
-
-
      
-
      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:
      
-
      
-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.
-
      
-
-
      
-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.
-
      
-
-
      
-Possible resolution: For these reasons, I propose to change the name of the respective parameters
-to n and r.
-
      
+
      
+In N2424. Not wildly enthusiastic, not really felt necessary. Less
+frequently used in practice. Not terribly bad either. Move to OPEN.
+
      
 
 
 
      Proposed resolution:
      
 
      
-See N2423
+See N2424
 for the proposed resolution.
 
      
 
+
      [
+Stephan Tolksdorf adds pre-Bellevue:
+]
      
 
 
-
-
-
      
-
      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. 
-
      
-
+
      
 
      
-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.
+In 26.4.8.4.3 [rand.dist.norm.chisq]:
 
      
 
-
-
      Proposed resolution:
      
+
      
 
      
-See N2423
-for the proposed resolution.
+Delete ", where n is a positive integer" in the first paragraph.
 
      
 
-
-
-
-
-
      
-
      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. 
 
        
-The design of the constructor
+Replace both occurrences of "explicit chi_squared_distribution(int n = 1);"
+with "explicit chi_squared_distribution(RealType n = 1);".
 
        
-
        template <class InputIteratorB, class InputIteratorW> 
-piecewise_constant_distribution( InputIteratorB firstB, InputIteratorB lastB, 
-                                 InputIteratorW firstW);
+
+
        
+Replace both occurrences of "int n() const;" with "RealType n() const;".
+
        
+
+
        
+
+
        
+In 26.4.8.4.5 [rand.dist.norm.f]:
+
        
+
        
+
        
+Delete ", where m and n are positive integers" in the first paragraph.
+
        
+
+
        
+Replace both occurrences of
+
        
+
        explicit fisher_f_distribution(int m = 1, int n = 1);
 
        
 
        
-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.
+with
 
        
-
        3. 
-
      
+
      explicit fisher_f_distribution(RealType m = 1, RealType n = 1);
+
      
 
 
      
-Possible resolution: I propose to add an InputIteratorW lastW argument to the interface.
-
      
-
-
-
      Proposed resolution:
      
-
      
-See N2423
-for the proposed resolution.
-
      
-
-
-
-
-
-
      
-
      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:
      
-
      
-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.
-
      
-
-
-
      Proposed resolution:
      
-
      
-See N2423
-for the proposed resolution.
-
      
-
-
-
-
-
-
      
-
      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:
      
-
      
-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)).
+Replace both occurrences of "int m() const;" with "RealType m() const;".
 
      
 
 
      
-See N2423
-for further discussion.
+Replace both occurrences of "int n() const;" with "RealType n() const;".
 
      
+
      
 
-
-
-
      Proposed resolution:
      
 
      
-See N2423
-for the proposed resolution.
+In 26.4.8.4.6 [rand.dist.norm.t]:
 
      
 
+
      
+
      
+Delete ", where n is a positive integer" in the first paragraph.
+
      
+
+
      
+Replace both occurrences of "explicit student_t_distribution(int n = 1);"
+with "explicit student_t_distribution(RealType n = 1);".
+
      
+
+
      
+Replace both occurrences of "int n() const;" with "RealType n() const;".
+
      
+
      
+
+
      
+
 
 
 
 
 
      
 
      740. Please remove *_ptr<T[N]>
      
-
      Section: 20.6.5.4 [unique.ptr.compiletime] Status: New
+
      Section: 20.6.11.4 [unique.ptr.compiletime] Status: Ready
  Submitter: Herb Sutter Date: 2007-10-04
      
-
      View all issues with New status.
      
+
      View all issues with Ready status.
      
 
      Discussion:
      
 
      
 Please don't provide *_ptr<T[N]>. It doesn't enable any useful
@@ -13874,10 +11655,34 @@ remove *_ptr<T[N]> which equally makes the smart pointer more lik
 std::array. :-)
 
      
 
+
      [
+Bellevue:
+]
      
+
+
+
      
+
      Suggestion that fixed-size array instantiations are going to fail at
+compile time anyway (if we remove specialization) due to pointer decay,
+at least that appears to be result from available compilers.
+
      
+
      
+So concerns about about requiring static_assert seem unfounded.
+
      
+
      After a little more experimentation with compiler, it appears that
+fixed size arrays would only work at all if we supply these explicit
+specialization. So removing them appears less breaking than originally
+thought.
+
      
+
      
+straw poll unanimous move to Ready.
+
      
+
      
+
+
 
 
      Proposed resolution:
      
 
      
-Change the synopsis under 20.6.5 [unique.ptr] p2:
+Change the synopsis under 20.6.11 [unique.ptr] p2:
 
      
 
 
      ...
@@ -13892,13 +11697,13 @@ template<class T, class D> class unique_ptr<T[], D>;
 
      
 
 
      
-Remove the entire section 20.6.5.1.3 [unique.ptr.dltr.dflt2] default_delete<T[N]>.
+Remove the entire section 20.6.11.1.3 [unique.ptr.dltr.dflt2] default_delete<T[N]>.
 
      
 
 
      
-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].
+Remove the entire section 20.6.11.4 [unique.ptr.compiletime] unique_ptr for array objects with a compile time length
+and its subsections: 20.6.11.4.1 [unique.ptr.compiletime.dtor], 20.6.11.4.2 [unique.ptr.compiletime.observers],
+20.6.11.4.3 [unique.ptr.compiletime.modifiers].
 
      
 
 
@@ -13906,109 +11711,13 @@ and its subsections: 20.6.5.4.1 [unique.ptr.compiletime.dtor], 20.6.5.4.2 [uniqu
 
 
 
-
      
-
      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:
      
-
      
-The following issue was raised by Alf P. Steinbach in c.l.c++.mod:
-
      
-
-
      
-According to the recent draft N2369, both the header memory synopsis
-of 20.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);
-
      
-
-
      
-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:
-
-
      
-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):
-
      
-
-
        
-
      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. 
-
      
-
-
      
-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&);
-
        
-
-
        
-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:
-
      
-
-
      
-
      
-My favorite option is "not a defect". A, B and C break useful code.
-
      
-
      
-
-
-
-
      Proposed resolution:
      
-
      
-
      
-
-
-
-
-
 
      
 
      742. Enabling swap for proxy iterators
      
-
      Section: 20.1.1 [utility.arg.requirements] Status: New
+
      Section: 20.1.1 [utility.arg.requirements] Status: Open
  Submitter: Howard Hinnant Date: 2007-10-10
      
 
      View other active issues in [utility.arg.requirements].
      
 
      View all other issues in [utility.arg.requirements].
      
-
      View all issues with New status.
      
+
      View all issues with Open status.
      
 
      Discussion:
      
 
      
 This issue was split from 672. 672 now just
@@ -14071,6 +11780,37 @@ That is, no standard library code needs to change.  We simply need to have a mor
 definition of Swappable.
 
      
 
+
      [
+Bellevue:
+]
      
+
+
+
      
+
      
+While we believe Concepts work will define a swappable concept, we
+should still resolve this issue if possible to give guidance to the
+Concepts work.
+
      
+
      
+Would an ambiguous swap function in two namespaces found by ADL break
+this wording? Suggest that the phrase "valid expression" means such a
+pair of types would still not be swappable.
+
      
+
      
+Motivation is proxy-iterators, but facility is considerably more
+general. Are we happy going so far?
+
      
+
      
+We think this wording is probably correct and probably an improvement on
+what's there in the WP. On the other hand, what's already there in the
+WP is awfully complicated. Why do we need the two bullet points? They're
+too implementation-centric. They don't add anything to the semantics of
+what swap() means, which is there in the post-condition. What's wrong
+with saying that types are swappable if you can call swap() and it
+satisfies the semantics of swapping?
+
      
+
      
+
 
 
 
      Proposed resolution:
      
@@ -14132,12 +11872,12 @@ semantics described in this table.
 
 
      
 
      743. rvalue swap for shared_ptr
      
-
      Section: 20.6.6.2.9 [util.smartptr.shared.spec] Status: New
+
      Section: 20.6.12.2.9 [util.smartptr.shared.spec] Status: Ready
  Submitter: Howard Hinnant Date: 2007-10-10
      
-
      View all issues with New status.
      
+
      View all issues with Ready status.
      
 
      Discussion:
      
 
      
-When the LWG looked at 674 in Kona the following note was made:
+When the LWG looked at 674 in Kona the following note was made:
 
      
 
 
      
@@ -14154,11 +11894,27 @@ I believe allowing rvalue shared_ptrs to swap is both
 appropriate, and consistent with how other library components are currently specified.
 
      
 
+
      [
+Bellevue:
+]
      
+
+
+
      
+
      
+Concern that the three signatures for swap is needlessly complicated,
+but this issue merely brings shared_ptr into equal complexity with the
+rest of the library. Will open a new issue for concern about triplicate
+signatures.
+
      
+
      
+Adopt issue as written.
+
      
+
      
 
 
 
      Proposed resolution:
      
 
      
-Change the synopsis in 20.6.6.2 [util.smartptr.shared]:
+Change the synopsis in 20.6.12.2 [util.smartptr.shared]:
 
      
 
 
      void swap(shared_ptr&& r);
@@ -14169,14 +11925,14 @@ template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>
 
      
 
 
      
-Change 20.6.6.2.4 [util.smartptr.shared.mod]:
+Change 20.6.12.2.4 [util.smartptr.shared.mod]:
 
      
 
 
      void swap(shared_ptr&& r);
 
      
 
 
      
-Change 20.6.6.2.9 [util.smartptr.shared.spec]:
+Change 20.6.12.2.9 [util.smartptr.shared.spec]:
 
      
 
 
      template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b);
@@ -14190,15 +11946,15 @@ template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>
 
 
      
 
      744. What is the lifetime of an exception pointed to by an exception_ptr?
      
-
      Section: 18.7.5 [propagation] Status: New
+
      Section: 18.7.5 [propagation] Status: Ready
  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.
      
+
      View all issues with Ready status.
      
 
      Discussion:
      
 
      
 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
+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.
@@ -14208,55 +11964,68 @@ API.
 explain?)
 
      
 
+
      [
+Bellevue:
+]
      
 
-
      Proposed resolution:
      
+
+
      
 
      
-
      
-
-
-
-
-
-
      
-
      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:
      
-
      
-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.
+Agree the issue is real.
 
      
 
      
-(Peter Dimov suggests NAD)
+Intent is lifetime is similar to a shared_ptr (and we might even want to
+consider explicitly saying that it is a shared_ptr< unspecified type >).
 
      
+
      
+We expect that most implementations will use shared_ptr, and the
+standard should be clear that the exception_ptr type is intended to be
+something whose semantics are smart-pointer-like so that the user does
+not need to worry about lifetime management. We still need someone to
+draught those words - suggest emailing Peter Dimov.
+
      
+
      
+Move to Open.
+
      
+
      
 
 
 
      Proposed resolution:
      
 
      
+Change 18.7.5 [propagation]/7:
 
      
 
+
      
+-7- Returns: An exception_ptr object that refers to the currently
+handled exception or a copy of the currently handled exception, or a
+null exception_ptr object if no exception is being handled.
+The referenced object remains valid at least as long as there is an
+exception_ptr that refers to it.
+If the function needs to allocate memory and the attempt
+fails, it returns an exception_ptr object that refers to an instance of
+bad_alloc. It is unspecified whether the return values of two successive
+calls to current_exception refer to the same exception object. [Note:
+that is, it is unspecified whether current_exception creates a new copy
+each time it is called. --end note]
+
      
+
 
 
 
 
 
      
 
      746. current_exception may fail with bad_alloc
      
-
      Section: 18.7.5 [propagation] Status: New
+
      Section: 18.7.5 [propagation] Status: Ready
  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.
      
+
      View all issues with Ready status.
      
 
      Discussion:
      
 
      
 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
+implementation-defined type derived from bad_alloc.  For instance, the Core
 language for a failed new expression is:
 
      
 
      
@@ -14274,29 +12043,60 @@ compatible-exception freedom paragraph in 17)
 I prefer the clause 17 approach myself, and maybe clean up any outstanding
 wording that could also rely on it.
 
      
+
      
+Although filed against a specific case, this issue is a problem throughout
+the library. 
+
      
+
+
      [
+Bellevue:
+]
      
+
+
+
      
+
      
+Is issue bigger than library?
+
      
+
      
+No - Core are already very clear about their wording, which is inspiration for the issue.
+
      
+
      
+While not sold on the original 18.7.5 use case, the generalised 17.4.4.8 wording is the real issue.
+
      
+
      
+Accept the broad view and move to ready
+
      
+
      
 
 
 
      Proposed resolution:
      
 
      
+Add the following exemption clause to 17.4.4.8 [res.on.exception.handling]:
 
      
 
+
      
+A function may throw a type not listed in its Throws clause so long as it is
+derived from a class named in the Throws clause, and would be caught by an
+exception handler for the base type.
+
      
+
 
 
 
 
 
      
 
      747. We have 3 separate type traits to identify classes supporting no-throw operations
      
-
      Section: 20.4.4.3 [meta.unary.prop] Status: New
+
      Section: 20.4.4.3 [meta.unary.prop] Status: Open
  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.
      
+
      View all issues with Open status.
      
 
      Discussion:
      
 
      
 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
+guarantees.  However, I'm not entirely clear on what the current wording
+requires of a conforming implementation.  To quote from
 has_nothrow_default_constructor:
 
      
 
      
@@ -14311,13 +12111,13 @@ E.g.
 
      
 
 
      struct test{
- int x;
- test() : x() {}
+ int x;
+ test() : x() {}
 };
 
      
 
      
 Should I expect a conforming compiler to 
- assert( has_nothrow_constructor<test>::value )
+ assert( has_nothrow_constructor<test>::value )
 
      
 
      
 Is this a QoI issue?
@@ -14339,72 +12139,15 @@ but right now I don't know what to suggest putting in the footnote.
 Open if QoI should be allowed to detect further)
 
      
 
-
-
      Proposed resolution:
      
-
      
-
      
+
      [
+Bellevue:
+]
      
 
 
-
-
-
-
      
-
      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:
      
-
      
-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:
      
-
      
-
      
-
-
-
-
-
-
      
-
      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:
      
-
      
-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.
-
      
-
      
-For instance:
-
      
 
      
-
      struct awkward {
- awkward( const awkward & ) throw() {}
- awkward( awkward & ) { throw "oops"; } };
-
      
+This looks like a QoI issue.
+In the case of trivial and nothrow it is known. Static analysis of the program is definitely into QoI.
+Move to OPEN. Need to talk to Core about this.
 
      
 
 
@@ -14416,18 +12159,101 @@ For instance:
 
 
 
+
      
+
      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: Ready
+ 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 Ready status.
      
+
      Discussion:
      
+
      
+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.
+
      
+
      
+For instance:
+
      
+
      
+
      struct awkward {
+ awkward( const awkward & ) throw() {}
+ awkward( awkward & ) { throw "oops"; } };
+
      
+
      
+
+
+
      Proposed resolution:
      
+
      
+Change 20.4.4.3 [meta.unary.prop]:
+
      
+
+
      
+
      has_trivial_copy_constructor
      
+
      
+T is a trivial type (3.9) or a reference type or a class type with a trivial copy constructor
+where all copy constructors are trivial (12.8).
+
      
+
      
+
+
      
+
      has_trivial_assign
      
+
      
+T is neither const nor a reference type, and T is a trivial type (3.9)
+or a class type with a trivial copy assignment operator where all copy assignment operators are trivial (12.8).
+
      
+
      
+
+
      
+
      has_nothrow_copy_constructor
      
+
      
+has_trivial_copy_constructor<T>::value is true or T is a class type with
+a where all copy constructors that is are 
+known not to throw any exceptions or T is an
+array of such a class type
+
      
+
      
+
+
      
+
      has_nothrow_assign
      
+
      
+T is neither const nor a reference type, and
+has_trivial_assign<T>::value is true or T is a class type with a
+where all copy
+assignment operators takeing an lvalue of type T that is known not to
+throw any exceptions or T is an array of such a class type.
+
      
+
      
+
+
+
+
+
+
 
      
 
      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
+
      Section: 20.4.5 [meta.rel] Status: Open
  Submitter: Alisdair Meredith Date: 2007-10-10
      
-
      View all issues with New status.
      
+
      View all issues with Open status.
      
 
      Discussion:
      
 
      
 With the pending arrival of explicit conversion functions though, I'm
 wondering if we want an additional trait, is_explictly_convertible?
 
      
 
+
      [
+Bellevue:
+]
      
+
+
+
      
+Alisdair is considering preparing a paper listing a number of missing
+type traits, and feels that it might be useful to handle them all
+together rather than piecemeal. This would affect issue 719 and 750.
+These two issues should move to OPEN pending AM paper on type traits.
+
      
+
 
 
      Proposed resolution:
      
 
      
@@ -14439,8 +12265,10 @@ wondering if we want an additional trait, is_explictly_convertible?
 
 
      
 
      751. change pass-by-reference members of vector<bool> to pass-by-value?
      
-
      Section: 23.2.6 [vector.bool] Status: New
+
      Section: 23.2.7 [vector.bool] Status: New
  Submitter: Alisdair Meredith Date: 2007-10-10
      
+
      View other active issues in [vector.bool].
      
+
      View all other issues in [vector.bool].
      
 
      View all issues with New status.
      
 
      Discussion:
      
 
      
@@ -14449,6 +12277,39 @@ 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?
 
      
 
+
      [
+post Bellevue:
+]
      
+
+
+
      
+
      
+As we understand it, the original requester (Martin Sebor) would like
+for implementations to be permitted to pass-by-value. Alisdair suggests
+that if this is to be resolved, it should be resolved more generally,
+e.g. in other containers as well.
+
      
+
      
+We note that this would break ABI. However, we also suspect that this
+might be covered under the "as-if" rule in section 1.9.
+
      
+
      
+Many in the group feel that for vector<bool>, this is a "don't care",
+and that at this point in the process it's not worth the bandwidth.
+
      
+
      
+Issue 679 -- which was in ready status pre-Bellevue and is
+now in the working paper -- is related to this, though not a duplicate.
+
      
+
      
+Moving to Open with a task for Alisdair to craft a informative note to
+be put whereever appropriate in the WP. This note would clarify places
+where pass-by-const-ref can be transformed to pass-by-value under the
+as-if rule.
+
      
+
      
+
+
 
 
      Proposed resolution:
      
 
      
@@ -14510,11 +12371,11 @@ requirements on allocator types.
 
 
      
 
      753. Move constructor in draft
      
-
      Section: 20.1.1 [utility.arg.requirements] Status: New
+
      Section: 20.1.1 [utility.arg.requirements] Status: Open
  Submitter: Yechezkel Mett Date: 2007-10-14
      
 
      View other active issues in [utility.arg.requirements].
      
 
      View all other issues in [utility.arg.requirements].
      
-
      View all issues with New status.
      
+
      View all issues with Open status.
      
 
      Discussion:
      
 
      
 The draft standard n2369 uses the term move constructor in a few
@@ -14553,7 +12414,7 @@ in filling the above requirement.
 
 
      
 For vector::reserve, vector::resize and the vector modifiers given in
-23.2.5.4 [vector.modifiers] we have
+23.2.6.4 [vector.modifiers] we have
 
      
 
 
      
@@ -14590,6 +12451,1053 @@ possibly more concise too.
 
      
 
 
+
      Proposed resolution:
      
+
      
+Add new defintions to 17.1 [definitions]:
+
      
+
+
      
+
      
+move constructor
+
      
+
      
+a constructor which accepts only rvalue arguments of that type, and modifies the rvalue as a
+side effect during the construction.
+
      
+
      
+move assignment operator
+
      
+
      
+an assignment operator which accepts only rvalue arguments of that type, and modifies the rvalue as a
+side effect during the assignment.
+
      
+
      
+move assignment
+
      
+
      
+use of the move assignment operator.
+
      
+
      
+
+
      [
+Howard adds post-Bellevue:
+]
      
+
+
+
      
+
      
+Unfortunately I believe the wording recommended by the LWG in Bellevue is incorrect.  reserve et. al. will use a move constructor
+if one is available, else it will use a copy constructor.  A type may have both.  If the move constructor is
+used, it must not throw.  If the copy constructor is used, it can throw.  The sentence in the proposed wording
+is correct without the recommended insertion.  The Bellevue LWG recommended moving this issue to Ready.  I am
+unfortunately pulling it back to Open.  But I'm drafting wording to atone for this egregious action. :-)
+
      
+
      
+
+
+
+
+
+
+
      
+
      755. std::vector and std:string lack explicit shrink-to-fit operations
      
+
      Section: 23.2.6.2 [vector.capacity], 21.3.4 [string.capacity] Status: Ready
+ Submitter: Beman Dawes Date: 2007-10-31
      
+
      View all other issues in [vector.capacity].
      
+
      View all issues with Ready status.
      
+
      Discussion:
      
+
      
+A std::vector can be shrunk-to-fit via the swap idiom:
+
      
+
+
      vector<int> v;
+...
+v.swap(vector<int>(v));  // shrink to fit
+
      
+
      
+or:
+
      
+
      vector<int>(v).swap(v);  // shrink to fit
+
      
+
      
+or:
+
      
+
      swap(v, vector<int>(v));  // shrink to fit
+
      
+
      
+
+
      
+A non-binding request for shrink-to-fit can be made to a std::string via:
+
      
+
+
      string s;
+...
+s.reserve(0);
+
      
+
+
      
+Neither of these is at all obvious to beginners, and even some
+experienced C++ programmers are not aware that shrink-to-fit is
+trivially available.
+
      
+
      
+Lack of explicit functions to perform these commonly requested
+operations makes vector and string less usable for non-experts. Because
+the idioms are somewhat obscure, code readability is impaired. It is
+also unfortunate that two similar vector-like containers use different
+syntax for the same operation.
+
      
+
      
+The proposed resolution addresses these concerns. The proposed function
+takes no arguments to keep the solution simple and focused.
+
      
+
+
+
      Proposed resolution:
      
+
      
+To Class template basic_string 21.3 [basic.string] synopsis,
+Class template vector 23.2.6 [vector] synopsis, and Class
+vector<bool> 23.2.7 [vector.bool] synopsis, add:
+
      
+
+
          
+void shrink_to_fit();
+
      
+
+
      
+To basic_string capacity 21.3.4 [string.capacity] and vector
+capacity 23.2.6.2 [vector.capacity], add:
+
      
+
+
      
+
      void shrink_to_fit();
+
      
+
      
+Remarks: shrink_to_fit is a non-binding request to reduce
+capacity() to size(). [Note: The request is non-binding to
+allow latitude for implementation-specific optimizations.
+-- end note]
+
      
+
      
+
+
+
+
+
+
      
+
      756. Container adaptors push
      
+
      Section: 23.2.5 [container.adaptors] Status: Open
+ Submitter: Paolo Carlini Date: 2007-10-31
      
+
      View all issues with Open status.
      
+
      Discussion:
      
+
      
+After n2369 we have a single push_back overload in the sequence containers,
+of the "emplace" type. At variance with that, still in n2461, we have
+two separate overloads, the C++03 one + one taking an rvalue reference
+in the container adaptors. Therefore, simply from a consistency point of
+view, I was wondering whether the container adaptors should be aligned
+with the specifications of the sequence container themselves: thus have
+a single push along the lines:
+
      
+
+
      template<typename... _Args>
+void
+push(_Args&&... __args)
+  { c.push_back(std::forward<_Args>(__args)...); }
+
      
+
+
      [
+Related to 767
+]
      
+
+
+
+
      Proposed resolution:
      
+
      
+Change 23.2.5.1.1 [queue.defn]:
+
      
+
+
      void push(const value_type& x) { c.push_back(x); }
+void push(value_type&& x) { c.push_back(std::move(x)); }
+template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }
+
      
+
+
      
+Change 23.2.5.2 [priority.queue]:
+
      
+
+
      void push(const value_type& x) { c.push_back(x); }
+void push(value_type&& x) { c.push_back(std::move(x)); }
+template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }
+
      
+
+
      
+Change 23.2.5.2.2 [priqueue.members]:
+
      
+
+
      
+
      void push(const value_type& x);
+
      
+
      
+
      
+Effects:
+
      
+
      c.push_back(x);
+push_heap(c.begin(), c.end(), comp);
+
      
+
      
+
+
      template<class... Args> void push(value_type Args&&... x args);
+
      
+
      
+
      
+Effects:
+
      
+
      c.push_back(std::moveforward<Args>(x args)...);
+push_heap(c.begin(), c.end(), comp);
+
      
+
      
+
      
+
+
      
+Change 23.2.5.3.1 [stack.defn]:
+
      
+
+
      void push(const value_type& x) { c.push_back(x); }
+void push(value_type&& x) { c.push_back(std::move(x)); }
+template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }
+
      
+
+
+
+
+
+
+
      
+
      758. shared_ptr and nullptr
      
+
      Section: 20.6.12.2 [util.smartptr.shared] Status: Ready
+ Submitter: Joe Gottman Date: 2007-10-31
      
+
      View other active issues in [util.smartptr.shared].
      
+
      View all other issues in [util.smartptr.shared].
      
+
      View all issues with Ready status.
      
+
      Discussion:
      
+
      
+Consider the following program:
+
      
+
+
      int main() {
+   shared_ptr<int> p(nullptr); 
+   return 0;
+}
+
      
+
+
      
+This program will fail to compile because shared_ptr uses the following 
+template constructor to construct itself from pointers:
+
      
+
+
      template <class Y> shared_ptr(Y *);
+
      
+
+
      
+According
+to N2431,
+the conversion from nullptr_t to Y * is not
+deducible, so the above constructor will not be found.  There are similar problems with the
+constructors that take a pointer and a deleter or a
+pointer, a deleter and an allocator, as well as the
+corresponding forms of reset(). Note that N2435
+will solve this problem for constructing from just nullptr, but not for constructors that use
+deleters or allocators or for reset().
+
      
+
+
      
+In the case of the functions that take deleters, there is the additional
+question of what argument should be passed to the deleter when it is
+eventually called.  There are two reasonable possibilities: nullptr or
+static_cast<T *>(0), where T is the template argument of the
+shared_ptr.  It is not immediately clear which of these is better.  If
+D::operator() is a template function similar to shared_ptr's
+constructor, then d(static_cast<T*>(0)) will compile and d(nullptr)
+will not.  On the other hand, if D::operator()() takes a parameter that
+is a pointer to some type other that T (for instance U* where U derives
+from T) then d(nullptr) will compile and d(static_cast<T *>(0)) may not.
+
      
+
+
      [
+Bellevue:
+]
      
+
+
+
      
+
      
+The general idea is right, we need to be able to pass a nullptr to a
+shared_ptr, but there are a few borderline editorial issues here. (For
+example, the single-argument nullptr_t constructor in the class synopsis
+isn't marked explicit, but it is marked explicit in the proposed wording
+for 20.6.6.2.1. There is a missing empty parenthesis in the form that
+takes a nullptr_t, a deleter, and an allocator.)
+
      
+
      
+More seriously: this issue says that a shared_ptr constructed from a
+nullptr is empty. Since "empty" is undefined, it's hard to know whether
+that's right. This issue is pending on handling that term better.
+
      
+
      
+Peter suggests definition of empty should be "does not own anything"
+
      
+
      
+Is there an editorial issue that post-conditions should refer to get() =
+nullptr, rather than get() = 0?
+
      
+
      
+No strong feeling towards accept or NAD, but prefer to make a decision than leave it open.
+
      
+
      
+Seems there are no technical merits between NAD and Ready, comes down to
+"Do we intentially want to allow/disallow null pointers with these
+functions". Staw Poll - support null pointers 5 - No null pointers 0
+
      
+
      
+Move to Ready, modulo editorial comments
+
      
+
      
+
+
      [
+post Bellevue Peter adds:
+]
      
+
+
+
      
+
      
+The following wording changes are less intrusive:
+
      
+
+
      
+In 20.6.12.2.1 [util.smartptr.shared.const], add:
+
      
+
+
      shared_ptr(nullptr_t);
+
      
+
+
      
+after:
+
      
+
+
      shared_ptr();
+
      
+
+
      
+(Absence of explicit intentional.)
+
      
+
+
      
+px.reset( nullptr ) seems a somewhat contrived way to write px.reset(), so
+I'm not convinced of its utility.
+
      
+
      
+It's similarly not clear to me whether the deleter constructors need to be
+extended to take nullptr, but if they need to:
+
      
+
      
+Add
+
      
+
+
      template<class D> shared_ptr(nullptr_t p, D d);
+template<class D, class A> shared_ptr(nullptr_t p, D d, A a);
+
      
+
+
      
+after
+
      
+
+
      template<class Y, class D> shared_ptr(Y* p, D d);
+template<class Y, class D, class A> shared_ptr(Y* p, D d, A a);
+
      
+
+
      
+Note that this changes the semantics of the new constructors such that they
+consistently call d(p) instead of d((T*)0) when p is nullptr.
+
      
+
      
+The ability to be able to pass 0/NULL to a function that takes a shared_ptr
+has repeatedly been requested by users, but the other additions that the
+proposed resolution makes are not supported by real world demand or
+motivating examples.
+
      
+
      
+It might be useful to split the obvious and non-controversial nullptr_t
+constructor into a separate issue. Waiting for "empty" to be clarified is
+unnecessary; this is effectively an alias for the default constructor.
+
      
+
      
+
+
+
+
      Proposed resolution:
      
+
      
+Add the following constructors to 20.6.12.2 [util.smartptr.shared]:
+
      
+
+
      shared_ptr(nullptr_t);
+template <class D> shared_ptr(nullptr_t, D d);
+template <class D, class A> shared_ptr(nullptr_t, D d, A a);
+
      
+
+
      
+Add the following methods to 20.6.12.2 [util.smartptr.shared]:
+
      
+
+
      void reset(nullptr_t);
+template <class D> void reset(nullptr_t, D d);
+template <class D, class A> void reset(nullptr_t, D d, A a);
+
      
+
+
      
+Add the following constructor definitions to 20.6.12.2.1 [util.smartptr.shared.const]:
+
      
+
+
      
+
       explicit shared_ptr(nullptr_t);
+
      
+
      
+
      
+Effects: Constructs an empty shared_ptr object.
+
      
+
      
+Postconditions: use_count() == 0 && get() == 0.
+
      
+
      
+Throws: nothing.
+
      
+
      
+
      
+
+
      
+
      template <class D> shared_ptr(nullptr_t, D d);
+template <class D, class A> shared_ptr<nullptr_t, D d, A a);
+
      
+
      
+
      
+Requires: D shall be CopyConstructible. The copy constructor and
+destructor of D shall not throw exceptions. The expression
+d(static_cast<T *>(0)) shall be well-formed, shall have well defined behavior,
+and shall not throw exceptions. A shall be an allocator (20.1.2 [allocator.requirements]).
+The copy constructor and destructor of A shall not throw
+exceptions.
+
      
+
      
+Effects: Constructs a shared_ptr object that owns a null pointer of type T *
+and  deleter d.  The
+second constructor shall use a copy of a to allocate memory for
+internal use.
+
      
+
      
+Postconditions: use_count() == 1 and get() == 0.
+
      
+
      
+Throws: bad_alloc, or an implementation-defined exception when a
+resource other than memory could not be obtained.
+
      
+
      
+Exception safety: If an exception is thrown, d(static_cast<Y *>(nullptr)) is called.
+
      
+
      
+
      
+
+
      
+Add the following method definitions to 20.6.12.2.4 [util.smartptr.shared.mod]:
+
      
+
+
      
+
      void reset(nullptr_t);
+
      
+
      
+
      
+Effects: Equivalent to shared_ptr(nullptr).swap(*this).
+
      
+
      
+
      
+
+
      
+
      template <class D> void reset(nullptr_t, const D d)
+
      
+
      
+
      
+Effects: Equivalent to shared_ptr(nullptr, d).swap(*this).
+
      
+
      
+
      
+
+
      
+
      template <class D, class A> void reset(nullptr_t, D d, A a);
+
      
+
      
+
      
+Effects: Equivalent to shared_ptr(nullptr, d, a).swap(*this).
+
      
+
      
+
      
+
+
+
+
+
+
+
      
+
      759. A reference is not an object
      
+
      Section: 23.1 [container.requirements] Status: Ready
+ Submitter: Jens Maurer Date: 2007-11-06
      
+
      View other active issues in [container.requirements].
      
+
      View all other issues in [container.requirements].
      
+
      View all issues with Ready status.
      
+
      Discussion:
      
+
      
+23.1 [container.requirements] says:
+
      
+
+
      
+-12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No 
+diagnostic required.
+
      
+
+
      
+A reference is not an object, but this sentence appears to claim so.
+
      
+
+
      
+What is probably meant here:
+
      
+
      
+An object bound to an rvalue
+reference parameter of a member function of a container shall not be
+an element of that container; no diagnostic required.
+
      
+
+
+
+
      Proposed resolution:
      
+
      
+Change 23.1 [container.requirements]:
+
      
+
+
      
+-12- Objects passed to member functions of a container as rvalue references shall not be elements
+An object bound to an rvalue
+reference parameter of a member function of a container shall not be
+an element
+of that container.; Nno 
+diagnostic required.
+
      
+
+
+
+
+
+
+
      
+
      760. The emplace issue
      
+
      Section: 23.1 [container.requirements] Status: Open
+ Submitter: Paolo Carlini Date: 2007-11-11
      
+
      View other active issues in [container.requirements].
      
+
      View all other issues in [container.requirements].
      
+
      View all issues with Open status.
      
+
      Discussion:
      
+
      
+In an emplace member function the function parameter pack may be bound
+to a priori unlimited number of objects: some or all of them can be
+elements of the container itself. Apparently, in order to conform to the
+blanket statement 23.1 [container.requirements]/11, the implementation must check all of them for
+that possibility. A possible solution can involve extending the
+exception in 23.1 [container.requirements]/12 also to the emplace member. As a side note, the
+push_back and push_front member functions are luckily not affected by
+this problem, can be efficiently implemented anyway
+
      
+
+
      [
+Related to 767
+]
      
+
+
+
      [
+Bellevue:
+]
      
+
+
+
      
+
      
+The proposed addition (13) is partially redundant with the existing
+paragraph 12. Why was the qualifier "rvalues" added to paragraph 12? Why
+does it not cover subelements and pointers?
+
      
+
      
+Resolution: Alan Talbot to rework language, then set state to Review.
+
      
+
      
+
+
+
+
      Proposed resolution:
      
+
      
+Add after 23.1 [container.requirements]/12:
+
      
+
+
      
+
      
+-12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No 
+diagnostic required.
+
      
+
      
+
+-13- Objects bound to the function parameter pack of the emplace member function shall not be elements or
+sub-objects of elements of the container. No diagnostic required.
+
+
      
+
+
      
+
+
+
+
+
+
+
      
+
      761. unordered_map needs an at() member function
      
+
      Section: 23.4.1.2 [unord.map.elem] Status: Ready
+ Submitter: Joe Gottman Date: 2007-11-15
      
+
      View all issues with Ready status.
      
+
      Discussion:
      
+
      
+The new member function at() was recently added to std::map().  It acts 
+like operator[](), except it throws an exception when the input key is 
+not found.  It is useful when the map is const, the value_type of the 
+key doesn't have  a default constructor, it is an error if the key is 
+not found, or the user wants to avoid accidentally adding an element to 
+the map.  For exactly these same reasons, at() would be equally useful 
+in std::unordered_map.
+
      
+
+
+
      Proposed resolution:
      
+
      
+Add the following functions to the definition of unordered_map under "lookup" (23.4.1 [unord.map]):
+
      
+
+
      mapped_type& at(const key_type& k);
+const mapped_type &at(const key_type &k) const;
+
      
+
+
      
+Add the following definitions to 23.4.1.2 [unord.map.elem]:
+
      
+
+
      
+
      mapped_type& at(const key_type& k);
+const mapped_type &at(const key_type &k) const;
+
      
+
      
+
      
+Returns: A reference to x.second, where x is the (unique) element 
+whose key is equivalent to k.
+
      
+
      
+Throws: An exception object of type out_of_range if no such element 
+is present.
+
      
+
      
+
      
+
+
      [
+Bellevue:  Editorial note: the "(unique)" differs from map.
+]
      
+
+
+
+
+
+
+
+
      
+
      762. std::unique_ptr requires complete type?
      
+
      Section: 20.6.11 [unique.ptr] Status: Open
+ Submitter: Daniel Krügler Date: 2007-11-30
      
+
      View other active issues in [unique.ptr].
      
+
      View all other issues in [unique.ptr].
      
+
      View all issues with Open status.
      
+
      Discussion:
      
+
      
+In contrast to the proposed std::shared_ptr, std::unique_ptr
+does currently not support incomplete types, because it
+gives no explicit grant - thus instantiating unique_ptr with
+an incomplete pointee type T automatically belongs to
+undefined behaviour according to 17.4.3.7 [res.on.functions]/2, last
+bullet. This is an unnecessary restriction and prevents
+many well-established patterns - like the bridge pattern -
+for std::unique_ptr.
+
      
+
+
      [
+Bellevue:
+]
      
+
+
+
      
+Move to open. The LWG is comfortable with the intent of allowing
+incomplete types and making unique_ptr more like shared_ptr, but we are
+not comfortable with the wording. The specification for unique_ptr
+should be more like that of shared_ptr. We need to know, for individual
+member functions, which ones require their types to be complete. The
+shared_ptr specification is careful to say that for each function, and
+we need the same level of care here. We also aren't comfortable with the
+"part of the operational semantic" language; it's not used elsewhere in
+the standard, and it's not clear what it means. We need a volunteer to
+produce new wording.
+
      
+
+
+
      Proposed resolution:
      
+
      
+The proposed changes in the following revision refers to the current state of
+N2521 including the assumption that 20.6.11.4 [unique.ptr.compiletime] will be removed
+according to the current state of 740.
+
      
+
      
+The specialization unique_ptr<T[]> has some more restrictive constraints on
+type-completeness on T than unique_ptr<T>. The following proposed wordings
+try to cope with that. If the committee sees less usefulness on relaxed
+constraints on unique_ptr<T[]>, the alternative would be to stop this relaxation
+e.g. by adding one further bullet to 20.6.11.3 [unique.ptr.runtime]/1:
+"T shall be a complete type, if used as template argument of
+unique_ptr<T[], D>
+
      
+
      
+This issue has some overlap with 673, but it seems not to cause any
+problems with this one,
+because 673 adds only optional requirements on D that do not conflict
+with the here discussed
+ones, provided that D::pointer's operations (including default
+construction, copy construction/assignment,
+and pointer conversion) are specified not to throw, otherwise this
+would have impact on the
+current specification of unique_ptr.
+
      
+
+
        
+
      1. 
+
        
+In 20.6.11 [unique.ptr]/2 add as the last sentence to the existing para:
+
        
+
+
        
+The unique_ptr provides a semantics of strict ownership. A
+unique_ptr owns the object it holds a pointer to. A
+unique_ptr is not CopyConstructible, nor
+CopyAssignable, however it is MoveConstructible and
+MoveAssignable. The template parameter T of
+unique_ptr may be an incomplete type. [ Note: The
+uses of unique_ptr include providing exception safety for
+dynamically allcoated memory, passing ownership of dynamically allocated
+memory to a function, and returning dynamically allocated memory from a
+function. -- end note ]
+
        
+
        2. 
+
+
      2. 
+
        
+20.6.11.2.1 [unique.ptr.single.ctor]/1: No changes necessary.
+
        
+
+
        
+
        [
+N.B.: We only need the requirement that D is DefaultConstructible.
+The current wording says just this.
+]
        
+
+
        
+
        3. 
+
+
      3. 
+
        
+In 20.6.11.2.1 [unique.ptr.single.ctor]/5 change the requires clause to say:
+
        
+
+
        
+
        
+Requires: The expression D()(p) shall be well formed. The default constructor
+of D shall not throw an exception.
+D must shall not be a reference type.
+
+D shall be default constructible, and that construction
+shall not throw an exception.
+
+
        
+
        [
+N.B.: There is no need that the expression D()(p) is well-formed at
+this point. I assume that the current wording is based on the
+corresponding shared_ptr wording. In case of shared_ptr this
+requirement is necessary, because the corresponding c'tor *can* fail
+and must invoke delete p/d(p) in this case. Unique_ptr is simpler in
+this regard. The *only* functions that must insist on well-formedness
+and well-definedness of the expression get_deleter()(get()) are (1)
+the destructor and (2) reset. The reasoning for the wording change to
+explicitly require DefaultConstructible of D is to guarantee that
+invocation of
+D's default c'tor is both well-formed and well-defined. Note also that
+we do *not* need the
+requirement that T must be complete, also in contrast to shared_ptr.
+Shared_ptr needs this, because it's c'tor is a template c'tor which
+potentially requires Convertible<Y*, X*>, which
+again requires Completeness of Y, if !SameType<X, Y>
+]
        
+
+
        
+
        4. 
+
+
      4. 
+
        
+Merge 20.6.11.2.1 [unique.ptr.single.ctor]/12+13 thereby removing the sentence
+of 12, but transferring the "requires" to 13:
+
        
+
+
        
+
        
+Requires: If D is not an lvalue-reference type then[..]
+
        
+
        [
+N.B.: For the same reasons as for (3), there is no need that d(p) is
+well-formed/well-defined at this point. The current wording guarantees
+all what we need, namely that the initialization of both the T*
+pointer and the D deleter are well-formed and well-defined.
+]
        
+
+
        
+
        5. 
+
+
      5. 
+20.6.11.2.1 [unique.ptr.single.ctor]/17: No changes necessary.
+
        6. 
+
      6. 
+
        20.6.11.2.1 [unique.ptr.single.ctor]/21: No changes necessary.
        
+
+
        [
+N.B.: The current wording of 21 already implicitly guarantees that U
+is completely defined, because it requires that Convertible<U*, T*> is
+true. If the committee wishes this explicit requirement can be added,
+e.g. "U shall be a complete type."
+]
        
+
+
        7. 
+
+
      7. 
+
        
+20.6.11.2.2 [unique.ptr.single.dtor]: Just before p1 add a new paragraph:
+
        
+
        
+
        
+Requires: The expression get_deleter()(get()) shall be well-formed,
+shall have well-defined behavior, and shall not throw exceptions.
+
        
+
        [
+N.B.: This requirement ensures that the whole responsibility on
+type-completeness of T is delegated to this expression.
+]
        
+
+
        
+
        8. 
+
+
      8. 
+
        
+20.6.11.2.3 [unique.ptr.single.asgn]/1: No changes necessary, except the
+current editorial issue, that "must shall" has to be changed to
+"shall", but this change is not a special part of this resolution.
+
        
+
+
        [
+N.B. The current wording is sufficient, because we can delegate all
+further requirements on the requirements of the effects clause
+]
        
+
+
        9. 
+
+
      9. 
+
        
+20.6.11.2.3 [unique.ptr.single.asgn]/6: No changes necessary.
+
        
+
        [
+N.B.: The current wording of p. 6 already implicitly guarantees that
+U is completely defined, because it requires that Convertible<U*, T*>
+is true, see (6)+(8).
+]
        
+
+
        10. 
+
+
      10. 
+
        
+20.6.11.2.3 [unique.ptr.single.asgn]/11: No changes necessary.
+
        
+
        [
+N.B.: Delegation to requirements of effects clause is sufficient.
+]
        
+
+
        11. 
+
+
      11. 
+20.6.11.2.4 [unique.ptr.single.observers]/1+4+7+9+11: No changes necessary.
+
        12. 
+
+
      12. 
+20.6.11.2.5 [unique.ptr.single.modifiers]/1: No changes necessary.
+
        13. 
+
+
      13. 
+
        
+20.6.11.2.5 [unique.ptr.single.modifiers]/4: Just before p. 4 add a new paragraph:
+
        
+
        
+Requires: The expression get_deleter()(get()) shall be well-formed,
+shall have well-defined behavior, and shall not throw exceptions.
+
        
+
        14. 
+
+
      14. 
+20.6.11.2.5 [unique.ptr.single.modifiers]/7: No changes necessary.
+
        15. 
+
+
      15. 
+
        
+20.6.11.3.1 [unique.ptr.runtime.ctor]: Add one additional paragraph just
+before the current one:
+
        
+
+
        
+
        
+Requires: T shall be a complete type.
+
        
+
        [
+N.B.: We need this requirement, because otherwise it is not
+guaranteed that the c'tors can fulfill their requirements to reject
+any type that is convertible to T*.
+]
        
+
+
        
+
        16. 
+
+
      16. 
+20.6.11.3.2 [unique.ptr.runtime.observers]/1: Change the clause to says:
+
        17. 
+
+
        
+Requires: i < the size of the array to which the stored pointer
+points. T shall be a complete type.
+
        
+
+
      17. 
+
        
+20.6.11.3.3 [unique.ptr.runtime.modifiers]/1: Change the first sentence of the
+paragraph to say:
+
        
+
        
+
        
+Requires: T shall be a complete type. Does not accept pointer types
+which are convertible to T* (diagnostic required). [ Note: ...]
+
        
+
        [
+N.B. Similar to (15) we need this requirement such that reset can
+reject types which are convertible to T*
+]
        
+
+
        
+
+
        18. 
+
      
+
+
      [
+post Bellevue: Daniel provided revised wording.
+]
      
+
+
+
+
+
+
+
+
      
+
      765. more on iterator validity
      
+
      Section: 24.1 [iterator.requirements] Status: New
+ Submitter: Martin Sebor Date: 2007-12-14
      
+
      View other active issues in [iterator.requirements].
      
+
      View all other issues in [iterator.requirements].
      
+
      View all issues with New status.
      
+
      Discussion:
      
+       
      
+
+Issue 278
+defines the meaning of the term "invalid iterator" as one that may be
+singular.
+
+       
      
+       
      
+
+Consider the following code:
+
+       
      
+       
         std::deque<int> x, y;
+   std::deque<int>::iterator i = x.end(), j = y.end();
+   x.swap(y);
+       
      
+       
      
+
+Given that swap() is required not to invalidate iterators
+and using the definition above, what should be the expected result of
+comparing i and j to x.end()
+and y.end(), respectively, after the swap()?
+
+       
      
+       
      
+
+I.e., is the expression below required to evaluate
+to true?
+
+       
      
+       
         i == y.end() && j == x.end()
+       
      
+       
      
+
+(There are at least two implementations where the expression
+returns false.)
+
+       
      
+       
      
+
+More generally, is the definition introduced in issue 278 meant to
+make any guarantees about whether iterators actually point to the same
+elements or be associated with the same containers after a
+non-invalidating operation as they did before?
+
+       
      
+       
      
+
+Here's a motivating example intended to demonstrate the importance of
+the question:
+
+       
      
+       
         Container x, y ({ 1, 2});   // pseudocode to initialize y with { 1, 2 }
+   Container::iterator i = y.begin() + 1;
+   Container::iterator j = y.end();
+   std::swap(x, y);
+   std::find(i, j, 3);
+       
      
+       
      
+
+swap() guarantees that i and j
+continue to be valid. Unless the spec says that even though they are
+valid they may no longer denote a valid range the code above must be
+well-defined. Expert opinions on this differ as does the behavior of
+popular implementations for some standard Containers.
+
+       
      
+
+
 
      Proposed resolution:
      
 
      
 
      
@@ -14599,92 +13507,1326 @@ possibly more concise too.
 
 
 
      
-
      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.
      
+
      766. Inconsistent exception guarantees between ordered and unordered associative containers
      
+
      Section: 23.1 [container.requirements], 23.1.3.1 [unord.req.except] Status: Ready
+ Submitter: Ion Gaztańaga Date: 2007-12-22
      
+
      View other active issues in [container.requirements].
      
+
      View all other issues in [container.requirements].
      
+
      View all issues with Ready status.
      
 
      Discussion:
      
 
      
-14882-2003, [lib.uninitialized.copy] is currently written as follows:
+23.1 [container.requirements]p10 states:
 
      
 
 
      
-
      template <class InputIterator, class ForwardIterator>
-  ForwardIterator uninitialized_copy(InputIterator first, InputIterator last,
-                                     ForwardIterator result);
-
      
+
      
+Unless otherwise specified (see 23.2.2.3 and 23.2.5.4) all container types defined in this clause meet the following
+additional requirements:
+
      
+
        
+
+
      • [...]
        • 
+
+
      • no erase(), pop_back() or pop_front() function throws an exception.
        • 
+
+
      
+
      
+
+
      
+23.2.2.3 [deque.modifiers] and 23.2.6.4 [vector.modifiers] offer
+additional guarantees for deque/vector insert() and
+erase() members. However, 23.1 [container.requirements]p10
+does not mention 23.1.3.1 [unord.req.except] that specifies exception
+safety guarantees
+for unordered containers. In addition, 23.1.3.1 [unord.req.except]p1
+offers the following guaratee for
+erase():
+
      
+
 
      
-
      
--1- Effects:
-
      
-
      for (; first != last; ++result, ++first)
-  new (static_cast<void*>(&*result))
-    typename iterator_traits<ForwardIterator>::value_type(*first);
-
      
-
      
--2- Returns: result
-
      
-
      
+No erase() function throws an exception unless that exception
+is thrown by the container's Hash or Pred object (if any).
 
      
 
 
      
-similarily for N2369, and its corresponding section
-20.6.4.1 [uninitialized.copy].
+Summary:
 
      
 
 
      
-It's not clear to me what the return clause is supposed to mean, I see
-two
-possible interpretations:
+According to 23.1 [container.requirements]p10 no
+erase() function should throw an exception unless otherwise
+specified. Although does not explicitly mention 23.1.3.1 [unord.req.except], this section offers additional guarantees
+for unordered containers, allowing erase() to throw if
+predicate or hash function throws.
 
      
 
-
        
+
        
+In contrast, associative containers have no exception safety guarantees
+section so no erase() function should throw, including
+erase(k) that needs to use the predicate function to
+perform its work. This means that the predicate of an associative
+container is not allowed to throw.
+
        
+
+
        
+So:
+
        
+
+
          
 
        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.
+erase(k) for associative containers is not allowed to throw. On
+the other hand, erase(k) for unordered associative containers
+is allowed to throw.
 
          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).
+erase(q) for associative containers is not allowed to throw. On
+the other hand, erase(q) for unordered associative containers
+is allowed to throw if it uses the hash or predicate.
+
          3. 
+
        3. 
+To fulfill 1), predicates of associative containers are not allowed to throw.
+Predicates of unordered associative containers are allowed to throw.
+
          4. 
+
        4. 
+2) breaks a widely used programming pattern (flyweight pattern) for
+unordered containers, where objects are registered in a global map in
+their constructors and unregistered in their destructors. If erase(q) is
+allowed to throw, the destructor of the object would need to rethrow the
+exception or swallow it, leaving the object registered.
 
          5. 
 
        
 
+
+
        Proposed resolution:
        
 
        
-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.
+Create a new sub-section of 23.1.2 [associative.reqmts] (perhaps [associative.req.except]) titled "Exception
+safety guarantees".
+
        
+
+
        
+
        
+1 For associative containers, no clear() function throws an exception.
+erase(k) does not throw an exception unless that exception is thrown by
+the container's Pred object (if any).
+
        
+
+
        
+2 For associative containers, if an exception is thrown by any operation
+from within an insert() function inserting a single element, the
+insert() function has no effect.
+
        
+
+
        
+3 For associative containers, no swap function throws an exception
+unless that exception is thrown by the copy constructor or copy
+assignment operator of the container's Pred object (if any).
+
        
+
        
+
+
        
+Change 23.1.3.1 [unord.req.except]p1:
+
        
+
+
        
+For unordered associative containers, no clear() function
+throws an exception. No erase(k)
+function does not throws an exception
+unless that exception is thrown by the container's Hash or Pred object
+(if any).
+
        
+
+
        
+Change 23.1 [container.requirements]p10 to add references to new sections:
+
        
+
+
        
+Unless otherwise specified (see [deque.modifiers],
+and [vector.modifiers], [associative.req.except],
+[unord.req.except]) all container types defined in this clause meet
+the following additional requirements:
+
        
+
+
        
+Change 23.1 [container.requirements]p10 referring to swap:
+
        
+
+
        
+
          
+
        • 
+no swap() function throws an exception unless that exception is thrown
+by the copy constructor or assignment operator of the container's
+Compare object (if any; see [associative.reqmts]).
+
          • 
+
        
+
        
+
+
+
+
+
+
+
        
+
        767. Forwarding and backward compatibility
        
+
        Section: 23 [containers] Status: Open
+ Submitter: Sylvain Pion Date: 2007-12-28
        
+
        View other active issues in [containers].
        
+
        View all other issues in [containers].
        
+
        View all issues with Open status.
        
+
        Discussion:
        
+
        
+Playing with g++'s C++0X mode, I noticed that the following
+code, which used to compile:
+
        
+
+
        #include <vector>
+
+int main()
+{
+    std::vector<char *> v;
+    v.push_back(0);
+}
+
        
+
+
        
+now fails with the following error message:
+
        
+
+
        .../include/c++/4.3.0/ext/new_allocator.h: In member
+function 'void __gnu_cxx::new_allocator<_Tp>::construct(_Tp*,
+_Args&& ...) [with _Args = int, _Tp = char*]':
+.../include/c++/4.3.0/bits/stl_vector.h:707: instantiated from 'void
+std::vector<_Tp, _Alloc>::push_back(_Args&& ...) [with
+_Args = int, _Tp = char*, _Alloc = std::allocator<char*>]'
+test.cpp:6: instantiated from here
+.../include/c++/4.3.0/ext/new_allocator.h:114: error: invalid
+conversion from 'int' to 'char*'
+
        
+
+
        
+As far as I know, g++ follows the current draft here.
+
        
+
        
+Does the committee really intend to break compatibility for such cases?
+
        
+
+
        [
+Sylvain adds: 
+]
        
+
+
+
        
+
        
+I just noticed that std::pair has the same issue.
+The following now fails with GCC's -std=c++0x mode:
+
        
+
+
        #include <utility>
+
+int main()
+{
+   std::pair<char *, char *> p (0,0);
+}
+
        
+
+
        
+I have not made any general audit for such problems elsewhere.
+
        
+
        
+
+
        [
+Related to 756
+]
        
+
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+
        
+Motivation is to handle the old-style int-zero-valued NULL pointers.
+Problem: this solution requires concepts in some cases, which some users
+will be slow to adopt. Some discussion of alternatives involving
+prohibiting variadic forms and additional library-implementation
+complexity.
+
        
+
        
+Discussion of "perfect world" solutions, the only such solution put
+forward being to retroactively prohibit use of the integer zero for a
+NULL pointer. This approach was deemed unacceptable given the large
+bodies of pre-existing code that do use integer zero for a NULL pointer.
+
        
+
        
+Another approach is to change the member names. Yet another approach is
+to forbid the extension in absence of concepts.
+
        
+
        
+Resolution: These issues (756, 767, 760, 763) will be subsumed into a
+paper to be produced by Alan Talbot in time for review at the 2008
+meeting in France. Once this paper is produced, these issues will be
+moved to NAD.
+
        
+
        
+
+
+
+
        Proposed resolution:
        
+
        
+Add the following rows to Table 90 "Optional sequence container operations", 23.1.1 [sequence.reqmts]:
+
        
+
+
        
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
        expression return type assertion/note
        pre-/post-condition        		 container
        
+a.push_front(t)
+
+void
+
+a.insert(a.begin(), t)
        
+Requires: T shall be CopyConstructible.
+        		
+list, deque
+
        
+a.push_front(rv)
+
+void
+
+a.insert(a.begin(), rv)
        
+Requires: T shall be MoveConstructible.
+        		
+list, deque
+
        
+a.push_back(t)
+
+void
+
+a.insert(a.end(), t)
        
+Requires: T shall be CopyConstructible.
+        		
+list, deque, vector, basic_string
+
        
+a.push_back(rv)
+
+void
+
+a.insert(a.end(), rv)
        
+Requires: T shall be MoveConstructible.
+        		
+list, deque, vector, basic_string
+
        
+
        
+
+
        
+Change the synopsis in 23.2.2 [deque]:
+
        
+
+
        void push_front(const T& x);
+void push_front(T&& x);
+void push_back(const T& x);
+void push_back(T&& x);
+template <class... Args> requires Constructible<T, Args&&...> void push_front(Args&&... args);
+template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
+
        
+
+
        
+Change 23.2.2.3 [deque.modifiers]:
+
        
+
+
        void push_front(const T& x);
+void push_front(T&& x);
+void push_back(const T& x);
+void push_back(T&& x);
+template <class... Args> requires Constructible<T, Args&&...> void push_front(Args&&... args);
+template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
+
        
+
+
        
+Change the synopsis in 23.2.4 [list]:
+
        
+
+
        void push_front(const T& x);
+void push_front(T&& x);
+void push_back(const T& x);
+void push_back(T&& x);
+template <class... Args> requires Constructible<T, Args&&...> void push_front(Args&&... args);
+template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
+
        
+
+
        
+Change 23.2.4.3 [list.modifiers]:
+
        
+
+
        void push_front(const T& x);
+void push_front(T&& x);
+void push_back(const T& x);
+void push_back(T&& x);
+template <class... Args> requires Constructible<T, Args&&...> void push_front(Args&&... args);
+template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
+
        
+
+
        
+Change the synopsis in 23.2.6 [vector]:
+
        
+
+
        void push_back(const T& x);
+void push_back(T&& x);
+template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
+
        
+
+
        
+Change 23.2.6.4 [vector.modifiers]:
+
        
+
+
        void push_back(const T& x);
+void push_back(T&& x);
+template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
+
        
+
+
+
+
+
+
+
+
        
+
        768. Typos in [atomics]?
        
+
        Section: 29.4.3 [atomics.types.generic] Status: Ready
+ Submitter: Alberto Ganesh Barbati Date: 2007-12-28
        
+
        View all issues with Ready status.
        
+
        Discussion:
        
+
        
+in the latest publicly available draft, paper
+N2641,
+in section 29.4.3 [atomics.types.generic], the following specialization of the template
+atomic<> is provided for pointers:
+
        
+
+
        template <class T> struct atomic<T*> : atomic_address { 
+  T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
+  T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
+
+  atomic() = default; 
+  constexpr explicit atomic(T); 
+  atomic(const atomic&) = delete; 
+  atomic& operator=(const atomic&) = delete; 
+
+  T* operator=(T*) volatile; 
+  T* operator++(int) volatile; 
+  T* operator--(int) volatile; 
+  T* operator++() volatile; 
+  T* operator--() volatile; 
+  T* operator+=(ptrdiff_t) volatile;
+  T* operator-=(ptrdiff_t) volatile; 
+};
+
        
+
+
        
+First of all, there is a typo in the non-default constructor which
+should take a T* rather than a T.
+
        
+
+
        
+As you can see, the specialization redefine and therefore hide a few
+methods from the base class atomic_address, namely fetch_add, fetch_sub,
+operator=, operator+= and operator-=. That's good, but... what happened
+to the other methods, in particular these ones:
+
        
+
+
        void store(T*, memory_order = memory_order_seq_cst) volatile;
+T* load( memory_order = memory_order_seq_cst ) volatile;
+T* swap( T*, memory_order = memory_order_seq_cst ) volatile;
+bool compare_swap( T*&, T*, memory_order, memory_order ) volatile;
+bool compare_swap( T*&, T*, memory_order = memory_order_seq_cst ) volatile;
+
        
+
+
        
+By reading paper
+N2427 "C++ Atomic Types and Operations",
+I see that the
+definition of the specialization atomic<T*> matches the one in the
+draft, but in the example implementation the methods load(), swap()
+and compare_swap() are indeed present.
+
        
+
+
        
+Strangely, the example implementation does not redefine the method
+store(). It's true that a T* is always convertible to void*, but not
+hiding the void* signature from the base class makes the class
+error-prone to say the least: it lets you assign pointers of any type to
+a T*, without any hint from the compiler.
+
        
+
+
        
+Is there a true intent to remove them from the specialization or are
+they just missing from the definition because of a mistake?
+
        
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+
        
+The proposed revisions are accepted.
+
        
+
        
+Further discussion: why is the ctor labeled "constexpr"? Lawrence said
+this permits the object to be statically initialized, and that's
+important because otherwise there would be a race condition on
+initialization.
+
        
+
        
+
+
+
        Proposed resolution:
        
+
        
+Change the synopsis in 29.4.3 [atomics.types.generic]:
+
        
+
+
        template <class T> struct atomic<T*> : atomic_address { 
+  void store(T*, memory_order = memory_order_seq_cst) volatile;
+  T* load( memory_order = memory_order_seq_cst ) volatile;
+  T* swap( T*, memory_order = memory_order_seq_cst ) volatile;
+  bool compare_swap( T*&, T*, memory_order, memory_order ) volatile;
+  bool compare_swap( T*&, T*, memory_order = memory_order_seq_cst ) volatile;
+
+  T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
+  T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
+
+  atomic() = default; 
+  constexpr explicit atomic(T*); 
+  atomic(const atomic&) = delete; 
+  atomic& operator=(const atomic&) = delete; 
+
+  T* operator=(T*) volatile; 
+  T* operator++(int) volatile; 
+  T* operator--(int) volatile; 
+  T* operator++() volatile; 
+  T* operator--() volatile; 
+  T* operator+=(ptrdiff_t) volatile;
+  T* operator-=(ptrdiff_t) volatile; 
+};
+
        
+
+
+
+
+
+
+
        
+
        769. std::function should use nullptr_t instead of "unspecified-null-pointer-type"
        
+
        Section: 20.5.15.2 [func.wrap.func] Status: New
+ Submitter: Daniel Krügler Date: 2008-01-10
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+N2461 already replaced in 20.5.15.2 [func.wrap.func] it's originally proposed
+(implicit) conversion operator to "unspecified-bool-type" by the new
+explicit bool conversion, but the inverse conversion should also
+use the new std::nullptr_t type instead of "unspecified-null-pointer-
+type".
+
        
+
+
+
        Proposed resolution:
        
+
+
        
+In 20.5 [function.objects], header <functional> synopsis replace:
+
        
+
+
        template<class R, class... ArgTypes>
+  bool operator==(const function<R(ArgTypes...)>&, unspecified-null-pointer-type nullptr_t);
+template<class R, class... ArgTypes>
+  bool operator==(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>&);
+template<class R, class... ArgTypes>
+  bool operator!=(const function<R(ArgTypes...)>&, unspecified-null-pointer-type nullptr_t);
+template<class R, class... ArgTypes>
+  bool operator!=(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>&);
+
        
+
+
        
+In the class function synopsis of 20.5.15.2 [func.wrap.func] replace
+
        
+
+
        function(unspecified-null-pointer-type nullptr_t);
+...
+function& operator=(unspecified-null-pointer-type nullptr_t);
+
        
+
+
        
+In 20.5.15.2 [func.wrap.func], "Null pointer comparisons" replace:
+
        
+
+
        template <class R, class... ArgTypes>
+  bool operator==(const function<R(ArgTypes...)>&, unspecified-null-pointer-type nullptr_t);
+template <class R, class... ArgTypes>
+  bool operator==(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>&);
+template <class R, class... ArgTypes>
+  bool operator!=(const function<R(ArgTypes...)>&, unspecified-null-pointer-type nullptr_t);
+template <class R, class... ArgTypes>
+  bool operator!=(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>&);
+
        
+
+
        
+In 20.5.15.2.1 [func.wrap.func.con], replace
+
        
+
+
        function(unspecified-null-pointer-type nullptr_t);
+...
+function& operator=(unspecified-null-pointer-type nullptr_t);
+
        
+
+
        
+In 20.5.15.2.6 [func.wrap.func.nullptr], replace
+
        
+
+
        template <class R, class... ArgTypes>
+  bool operator==(const function<R(ArgTypes...)>& f, unspecified-null-pointer-type nullptr_t);
+template <class R, class... ArgTypes>
+  bool operator==(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>& f);
+
        
+
+
        
+and replace
+
        
+
+
        template <class R, class... ArgTypes>
+  bool operator!=(const function<R(ArgTypes...)>& f, unspecified-null-pointer-type nullptr_t);
+template <class R, class... ArgTypes>
+  bool operator!=(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>& f);
+
        
+
+
+
+
+
+
+
        
+
        770. std::function should use rvalue swap
        
+
        Section: 20.5.15 [func.wrap] Status: Ready
+ Submitter: Daniel Krügler Date: 2008-01-10
        
+
        View all issues with Ready status.
        
+
        Discussion:
        
+
        
+It is expected that typical implementations of std::function will
+use dynamic memory allocations at least under given conditions,
+so it seems appropriate to change the current lvalue swappabilty of
+this class to rvalue swappability.
+
        
+
+
+
        Proposed resolution:
        
+
        
+In 20.5 [function.objects], header <functional> synopsis, just below of
+
        
+
+
        template<class R, class... ArgTypes>
+  void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&);
+template<class R, class... ArgTypes>
+  void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&);
+template<class R, class... ArgTypes>
+  void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&&);
+
        
+
+
        
+In 20.5.15.2 [func.wrap.func] class function definition, change
+
        
+
+
        void swap(function&&);
+
        
+
+
        
+In 20.5.15.2 [func.wrap.func], just below of
+
        
+
+
        template <class R, class... ArgTypes>
+  void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&);
+template <class R, class... ArgTypes>
+  void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&);
+template <class R, class... ArgTypes>
+  void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&&);
+
        
+
+
        
+In 20.5.15.2.2 [func.wrap.func.mod] change
+
        
+
+
        void swap(function&& other);
+
        
+
+
        
+In 20.5.15.2.7 [func.wrap.func.alg] add the two overloads
+
        
+
+
        template<class R, class... ArgTypes>
+  void swap(function<R(ArgTypes...)>&& f1, function<R(ArgTypes...)>& f2);
+template<class R, class... ArgTypes>
+  void swap(function<R(ArgTypes...)>& f1, function<R(ArgTypes...)>&& f2);
+
        
+
+
+
+
+
+
+
        
+
        771. Impossible throws clause in [string.conversions]
        
+
        Section: 21.4 [string.conversions] Status: Review
+ Submitter: Daniel Krügler Date: 2008-01-13
        
+
        View other active issues in [string.conversions].
        
+
        View all other issues in [string.conversions].
        
+
        View all issues with Review status.
        
+
        Discussion:
        
+
        
+The new to_string and to_wstring functions described in 21.4 [string.conversions]
+have throws clauses (paragraphs 8 and 16) which say:
+
        
+
+
        
+Throws: nothing
+
        
+
+
        
+Since all overloads return either a std::string or a std::wstring by value
+this throws clause is impossible to realize in general, since the basic_string
+constructors can fail due to out-of-memory conditions. Either these throws
+clauses should be removed or should be more detailled like:
+
        
+
+
        
+Throws: Nothing if the string construction throws nothing
+
        
+
+
        
+Further there is an editorial issue in p. 14: All three to_wstring
+overloads return a string, which should be wstring instead (The
+header <string> synopsis of 21.2 [string.classes] is correct in this
+regard).
 
        
 
 
 
 
        Proposed resolution:
        
 
        
-Change the wording of the return clause to say (20.6.4.1 [uninitialized.copy]):
+In 21.4 [string.conversions], remove the paragraphs 8 and 16.
 
        
 
 
        
+
        string to_string(long long val); 
+string to_string(unsigned long long val); 
+string to_string(long double val); 
+
        
+
        
+Throws: nothing
+
        
+
        
+
+
        
+
        wstring to_wstring(long long val); 
+wstring to_wstring(unsigned long long val); 
+wstring to_wstring(long double val); 
+
        
+
        
+Throws: nothing
+
        
+
        
+
+
+
+
+
+
+
        
+
        772.  Impossible return clause in [string.conversions]
        
+
        Section: 21.4 [string.conversions] Status: New
+ Submitter: Daniel Krügler Date: 2008-01-13
        
+
        View other active issues in [string.conversions].
        
+
        View all other issues in [string.conversions].
        
+
        View all issues with New status.
        
+
        Discussion:
        
 
        
--2- Returns: The value of result after effects have taken place.
+The return clause 21.4 [string.conversions]/paragraph 15 of the new to_wstring
+overloads says:
+
        
+
+
        
+Returns: each function returns a wstring object holding the character
+representation of the value of its argument that would be generated by
+calling wsprintf(buf, fmt, val) with a format specifier of L"%lld", L"%ulld",
+or L"%f", respectively.
+
        
+
+
        
+Problem is: There does not exist any wsprintf function in C99 (I checked
+the 2nd edition of ISO 9899, and the first and the second corrigenda from
+2001-09-01 and 2004-11-15). What probably meant here is the function
+swprintf from <wchar.h>/<cwchar>, but this has the non-equivalent
+declaration:
+
        
+
+
        int swprintf(wchar_t * restrict s, size_t n,
+const wchar_t * restrict format, ...);
+
        
+
+
        
+therefore the paragraph needs to mention the size_t parameter n.
+
        
+
+
+
+
        Proposed resolution:
        
+
        
+Change the current wording of 21.4 [string.conversions]/p. 15 to:
+
        
+
+
        
+Returns: eEach function returns a
+wstring object holding the character representation of the
+value of its argument that would be generated by calling
+wsswprintf(buf, bufsz, fmt,
+val) with a format specifier fmt of L"%lld",
+L"%ulld", or L"%f", respectively, where buf
+designates an internal character buffer of sufficient size bufsz.
+
        
+
+
        
+[Hint to the editor: The resolution also adds to mention the name of
+the format specifier "fmt"]
+
        
+
+
        
+I also would like to remark that the current wording of it's equivalent
+paragraph 7 should also mention the meaning of buf and fmt.
+
        
+
+
        
+Change the current wording of 21.4 [string.conversions]/p. 7 to:
+
        
+
+
        
+Returns: eEach function returns a string object holding the
+character representation of the value of its argument that would be
+generated by calling sprintf(buf, fmt, val) with a format specifier fmt of
+"%lld", "%ulld", or "%f", respectively, where buf designates an internal
+character buffer of sufficient size.
+
        
+
+
+
+
+
+
+
        
+
        774. Member swap undefined for most containers
        
+
        Section: 23 [containers] Status: Open
+ Submitter: Alisdair Meredith Date: 2008-01-14
        
+
        View other active issues in [containers].
        
+
        View all other issues in [containers].
        
+
        View all issues with Open status.
        
+
        Discussion:
        
+
        
+It appears most containers declare but do not define a member-swap
+function.
+
        
+
+
        
+This is unfortunate, as all overload the swap algorithm to call the
+member-swap function!
+(required for swappable guarantees [Table 37] and Container Requirements
+[Table 87])
+
        
+
+
        
+Note in particular that Table 87 gives semantics of a.swap(b) as swap(a,b),
+yet for all containers we define swap(a,b) to call a.swap(b) - a circular
+definition.
+
        
+
+
        
+A quick survey of clause 23 shows that the following containers provide a
+definition for member-swap:
+
        
+
+
        array
+queue
+stack
+vector
+
        
+
+
        
+Whereas the following declare it, but do not define the semantics:
+
        
+
+
        deque
+list
+map
+multimap
+multiset
+priority_queue
+set
+unordered_map
+unordered_multi_map
+unordered_multi_set
+unordered_set
+
        
+
+
        
+Suggested resolution:
+
        
+
        
+Provide a definition for each of the affected containers...
+
        
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+Move to Open and ask Alisdair to provide wording.
+
        
+
+
+
        Proposed resolution:
        
+
        
+Wording provided in
+N2590.
+
        
+
+
+
+
+
+
        
+
        775. Tuple indexing should be unsigned?
        
+
        Section: 20.3.1.4 [tuple.helper] Status: Ready
+ Submitter: Alisdair Meredith Date: 2008-01-16
        
+
        View all issues with Ready status.
        
+
        Discussion:
        
+
        
+The tuple element access API identifies the element in the sequence
+using signed integers, and then goes on to enforce the requirement that
+I be >= 0.  There is a much easier way to do this - declare I as
+unsigned.
+
        
+
        
+In fact the proposal is to use std::size_t, matching the type used in the tuple_size API.
+
        
+
        
+A second suggestion is that it is hard to imagine an API that deduces
+and index at compile time and returns a reference throwing an exception.
+Add a specific Throws: Nothing paragraph to each element
+access API.
+
        
+
        
+In addition to tuple, update the API applies to
+pair and array, and should be updated
+accordingly.
+
        
+
+
        
+A third observation is that the return type of the get
+functions for std::pair is pseudo-code, but it is not
+clearly marked as such.  There is actually no need for pseudo-code as
+the return type can be specified precisely with a call to
+tuple_element.  This is already done for
+std::tuple, and std::array does not have a
+problem as all elements are of type T.
+
        
+
+
+
        Proposed resolution:
        
+
        
+Update header <utility> synopsis in 20.2 [utility]
+
        
+
        // 20.2.3, tuple-like access to pair:
+template <class T> class tuple_size;
+template <intsize_t I, class T> class tuple_element;
+
+template <class T1, class T2> struct tuple_size<std::pair<T1, T2> >;
+template <class T1, class T2> struct tuple_element<0, std::pair<T1, T2> >;
+template <class T1, class T2> struct tuple_element<1, std::pair<T1, T2> >;
+
+template<intsize_t I, class T1, class T2>
+  Ptypename tuple_element<I, std::pair<T1, T2> >::type & get(std::pair<T1, T2>&);
+template<intsize_t I, class T1, class T2>
+  const Ptypename tuple_element<I, std::pair<T1, T2> >::type & get(const std::pair<T1, T2>&);
+
        
+
        
+Update 20.2.3 [pairs] Pairs
+
        
+
        template<intsize_t I, class T1, class T2>
+  Ptypename tuple_element<I, std::pair<T1, T2> >::type & get(pair<T1, T2>&);
+template<intsize_t I, class T1, class T2>
+  const Ptypename tuple_element<I, std::pair<T1, T2> >::type & get(const pair<T1, T2>&);
+
        
+
        
+24 Return type: If I == 0 then P is T1, if I == 1 then P is T2, and otherwise the program is ill-formed.
+
        
+
        
+25 Returns: If I == 0 returns p.first, otherwise if I == 1 returns p.second, and otherwise the program is ill-formed.
+
        
+
        
+Throws: Nothing.
+
        
+
+
+
        
+Update header <tuple> synopsis in 20.3 [tuple] with a APIs as below:
+
        
+
        template <intsize_t I, class T> class tuple_element; // undefined
+template <intsize_t I, class... Types> class tuple_element<I, tuple<Types...> >;
+
+// 20.3.1.4, element access:
+template <intsize_t I, class... Types>
+  typename tuple_element<I, tuple<Types...> >::type& get(tuple<Types...>&);
+template <intsize_t I, class ... types>
+  typename tuple_element<I, tuple<Types...> >::type const& get(const tuple<Types...>&);
+
        
+
+
        
+Update 20.3.1.4 [tuple.helper] Tuple helper classes
+
        
+
        template <intsize_t I, class... Types>
+class tuple_element<I, tuple<Types...> > {
+public:
+  typedef TI type;
+};
        
+
        
+1 Requires: 0 <= I and I < sizeof...(Types). The program is ill-formed if I is out of bounds.
+
        
+
        
+2 Type: TI is the type of the Ith element of Types, where indexing is zero-based.
+
        
+
        
+Update 20.3.1.5 [tuple.elem] Element access
+
        
+
        template <intsize_t I, class... types >
+typename tuple_element<I, tuple<Types...> >::type& get(tuple<Types...>& t);
+
        
+1 Requires: 0 <= I and I < sizeof...(Types). The program is ill-formed if I is out of bounds.
+
        
+2 Returns: A reference to the Ith element of t, where indexing is zero-based.
+
        
+Throws: Nothing.
+
        template <intsize_t I, class... types>
+typename tuple_element<I, tuple<Types...> >::type const& get(const tuple<Types...>& t);
+
        
+
        
+3 Requires: 0 <= I and I < sizeof...(Types). The program is ill-formed if I is out of bounds.
+
        
+
        
+4 Returns: A const reference to the Ith element of t, where indexing is zero-based.
+
        
+
        
+Throws: Nothing.
+
        
+
+
+
        
+Update header <array> synopsis in 20.2 [utility]
+
        
+
        template <class T> class tuple_size; // forward declaration
+template <intsize_t I, class T> class tuple_element; // forward declaration
+template <class T, size_t N>
+  struct tuple_size<array<T, N> >;
+template <intsize_t I, class T, size_t N>
+  struct tuple_element<I, array<T, N> >;
+template <intsize_t I, class T, size_t N>
+  T& get(array<T, N>&);
+template <intsize_t I, class T, size_t N>
+  const T& get(const array<T, N>&);
+
        
+
+
        
+Update 23.2.1.6 [array.tuple] Tuple interface to class template array
+
        
+
        tuple_element<size_t I, array<T, N> >::type
+
        
+
        
+3 Requires: 0 <= I < N. The program is ill-formed if I is out of bounds.
+
        
+
        
+4 Value: The type T.
+
        
+
        template <intsize_t I, class T, size_t N> T& get(array<T, N>& a);
+
        
+
        
+5 Requires: 0 <= I < N. The program is ill-formed if I is out of bounds.
+
        
+
        
+Returns: A reference to the Ith element of a, where indexing is zero-based.
+
        
+
        
+Throws: Nothing.
+
        
+
        template <intsize_t I, class T, size_t N> const T& get(const array<T, N>& a);
+
        
+
        
+6 Requires: 0 <= I < N. The program is ill-formed if I is out of bounds.
+
        
+
        
+7 Returns: A const reference to the Ith element of a, where indexing is zero-based.
+
        
+
        
+Throws: Nothing.
+
        
+
+
+
        [
+Bellevue: Note also that the phrase "The program is ill-formed if I is
+out of bounds" in the requires clauses are probably unnecessary, and
+could be removed at the editor's discretion. Also std:: qualification
+for pair is also unnecessary.
+]
        
+
+
+
+
+
        
+
        776. Undescribed assign function of std::array
        
+
        Section: 23.2.1 [array] Status: Review
+ Submitter: Daniel Krügler Date: 2008-01-20
        
+
        View other active issues in [array].
        
+
        View all other issues in [array].
        
+
        View all issues with Review status.
        
+
        Discussion:
        
+
        
+The class template array synopsis in 23.2.1 [array]/3 declares a member
+function
+
        
+
+
        void assign(const T& u);
+
        
+
+
        
+which's semantic is no-where described. Since this signature is
+not part of the container requirements, such a semantic cannot
+be derived by those.
+
        
+
+
        
+I found only one reference to this function in the issue list,
+588 where the question is raised:
+
        
+
+
        
+what's the effect of calling assign(T&) on a zero-sized array?
+
        
+
+
        
+which does not answer the basic question of this issue.
+
        
+
+
        
+If this function shall be part of the std::array, it's probable
+semantic should correspond to that of boost::array, but of
+course such wording must be added.
+
        
+
+
+
        Proposed resolution:
        
+
        
+Just after the section 23.2.1.4 [array.data] add the following new section:
+
        
+
+
        
+23.2.1.5 array::fill [array.fill]
+
        
+
+
        
+
        void fill(const T& u);
+
        
+
+
        
+1: Effects: fill_n(begin(), N, u)
+
        
+
        
+
+
        
+[N.B: I wonder, why class array does not have a "modifiers"
+section. If it had, then assign would naturally belong to it]
+
        
+
+
        
+Change the synopsis in 23.2.1 [array]/3:
+
        
+
+
        template <class T, size_t N>
+struct array { 
+  ...
+  void assign fill(const T& u);
+  ...
+
        
+
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+
        
+Suggest substituting "fill" instead of "assign".
+
        
+
        
+Set state to Review given substitution of "fill" for "assign".
+
        
+
        
+
+
+
+
+
        
+
        777. Atomics Library Issue
        
+
        Section: 29.4.4 [atomics.types.operations] Status: Ready
+ Submitter: Lawrence Crowl Date: 2008-01-21
        
+
        View all issues with Ready status.
        
+
        Discussion:
        
+
        
+The load functions are defined as
+
        
+
+
        C atomic_load(volatile A* object);
+C atomic_load_explicit(volatile A* object, memory_order);
+C A::load(memory_order order = memory_order_seq_cst) volatile;
+
        
+
+
        
+which prevents their use in const contexts.
+
        
+
+
        [
+post Bellevue Peter adds:
+]
        
+
+
+
        
+
        
+Issue 777 suggests making atomic_load operate on const objects. There is a
+subtle point here. Atomic loads do not generally write to the object, except
+potentially for the memory_order_seq_cst constraint. Depending on the
+architecture, a dummy write with the same value may be required to be issued
+by the atomic load to maintain sequential consistency. This, in turn, may
+make the following code:
+
        
+
+
        const atomic_int x{};
+
+int main()
+{
+  x.load();
+}
+
        
+
+
        
+dump core under a straightforward implementation that puts const objects in
+a read-only section.
+
        
+
        
+There are ways to sidestep the problem, but it needs to be considered.
+
        
+
        
+The tradeoff is between making the data member of the atomic types
+mutable and requiring the user to explicitly mark atomic members as
+mutable, as is already the case with mutexes.
+
        
+
        
+
+
+
+
        Proposed resolution:
        
+
        
+Add the const qualifier to *object and *this.
+
        
+
+
        C atomic_load(const volatile A* object);
+C atomic_load_explicit(const volatile A* object, memory_order);
+C A::load(memory_order order = memory_order_seq_cst) const volatile;
+
        
+
+
+
+
+
+
+
        
+
        778. std::bitset does not have any constructor taking a string literal
        
+
        Section: 23.3.5.1 [bitset.cons] Status: Ready
+ Submitter: Thorsten Ottosen Date: 2008-01-24
        
+
        View other active issues in [bitset.cons].
        
+
        View all other issues in [bitset.cons].
        
+
        View all issues with Ready status.
        
+
        Duplicate of: 116
        
+
        Discussion:
        
+
        
+A small issue with std::bitset: it does not have any constructor
+taking a string literal, which is clumsy and looks like an oversigt when
+we tried to enable uniform use of string and const char* in the library.
+
        
+
+
        
+Suggestion: Add
+
        
+
+
        explicit bitset( const char* str );
+
        
+
+
        
+to std::bitset.
+
        
+
+
+
        Proposed resolution:
        
+
        
+Add to synopsis in 23.3.5 [template.bitset]
+
        
+
+
        explicit bitset( const char* str );
+
        
+
+
        
+Add to synopsis in 23.3.5.1 [bitset.cons]
+
        
+
+
        explicit bitset( const char* str );
+
        
+
        
+Effects: Constructs a bitset as if bitset(string(str)).
 
        
 
        
 
@@ -14693,4 +14835,4382 @@ Change the wording of the return clause to say (20.6.4.1 [uninitialized.copy]):
 
 
 
+
        
+
        779. Resolution of #283 incomplete
        
+
        Section: 25.2.8 [alg.remove] Status: New
+ Submitter: Daniel Krügler Date: 2008-01-25
        
+
        View all other issues in [alg.remove].
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+The resolution of 283 did not resolve similar necessary changes for algorithm
+remove_copy[_if],
+which seems to be an oversight.
+
        
+
+
+
        Proposed resolution:
        
+
        
+In 25.2.8 [alg.remove]/p.6, replace the N2461 requires clause with one of:
+
        
+
+
        
+Requires: Type T is EqualityComparable (31). The ranges [first,last)
+and [result,result + (last - first)) shall not overlap. The expression *result = *first shall be
+valid.
+
        
+
+
        
+or
+
        
+
+
        
+Requires: Type T is EqualityComparable (31). The ranges [first,last)
+and [result,result + (last - first)) shall not overlap.
+The result of the expression *first shall
+be writable to the output iterator.
+
        
+
+
+
+
+
+
+
        
+
        780. std::merge() specification incorrect/insufficient
        
+
        Section: 25.3.4 [alg.merge] Status: New
+ Submitter: Daniel Krügler Date: 2008-01-25
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+Though issue 283 has fixed many open issues, it seems that some are still open:
+
        
+
+
        
+Both 25.3.4 [lib.alg.merge] in 14882:2003 and 25.3.4 [alg.merge] in N2461
+have no Requires element and the Effects element contains some requirements,
+which is probably editorial. Worse is that:
+
        
+
+
          
+
        • 
+no assignment requirements are specified (neither implicit nor explicit).
+
          • 
+
+
        • 
+the effects clause just speaks of "merges", which is badly worded
+near to a circular definition.
+
          • 
+
+
        • 
+p. 2 mentions a range [first, last), which is not defined by the
+function arguments or otherwise.
+
          • 
+
+
        • 
+p. 2 says "according to the ordering defined by comp" which is both
+incomplete (because
+this excludes the first variant with <) and redundant (because the
+following subordinate
+clause mentions comp again)
+
          • 
+
        
+
+
+
+
        Proposed resolution:
        
+
        
+In 25.3.4 [alg.merge] replace p.1+ 2:
+
        
+
+
        
+
        
+Effects: Merges Copies all the elements of the two sorted ranges [first1,last1) and
+[first2,last2) into the range
+[result,result + (last1 - first1) + (last2 - first2))
+[result, last) (where last is equal to result + (last1
+- first1) + (last2 - first2)), such that resulting range will be
+sorted in non-decreasing order; that is, for every iterator i in
+[result,last) other than result, the condition *i < *(i - 1) or,
+respectively, comp(*i, *(i - 1)) will be false.
+
        
+
+
        
+Requires: The resulting range shall not overlap with either of the original ranges. The list will be sorted in non-decreasing 
+order according to the ordering defined by comp; that is, for every iterator i in
+[first,last) other than first, the condition *i < *(i - 1) or
+comp(*i, *(i - 1)) will be false. The results of the expressions *first1 and *first2
+shall be writable to the output iterator.
+
        
+
        
+
+
        
+[N.B.: I attempted to reuse the wording style of inplace_merge,
+therefore proposing to
+insert ", respectively," between both predicate tests. This is no
+strictly necessary as
+other parts of <algorithm> show, just a matter of consistency]
+
        
+
+
+
+
+
+
+
        
+
        781. std::complex should add missing C99 functions
        
+
        Section: 26.3.7 [complex.value.ops] Status: Ready
+ Submitter: Daniel Krügler Date: 2008-01-26
        
+
        View other active issues in [complex.value.ops].
        
+
        View all other issues in [complex.value.ops].
        
+
        View all issues with Ready status.
        
+
        Discussion:
        
+
        
+A comparision of the N2461 header <complex> synopsis ([complex.synopsis])
+with the C99 standard (ISO 9899, 2nd edition and the two corrigenda) show
+some complex functions that are missing in C++. These are:
+
        
+
+
          
+
        1. 
+7.3.9.4: (required elements of the C99 library)
          
+The cproj functions
+
          2. 
+
        2. 
+7.26.1: (optional elements of the C99 library)
          
+
          cerf    cerfc    cexp2
+cexpm1  clog10   clog1p
+clog2   clgamma  ctgamma
+
          
+
          3. 
+
        
+
+
        
+I propose that at least the required cproj overloads are provided as equivalent
+C++ functions. This addition is easy to do in one sentence (delegation to C99
+function).
+
        
+
+
        
+Please note also that the current entry polar
+in 26.3.9 [cmplx.over]/1
+should be removed from the mentioned overload list. It does not make sense to require that a
+function already expecting scalar arguments
+should cast these arguments into corresponding
+complex<T> arguments, which are not accepted by
+this function.
+
        
+
+
+
        Proposed resolution:
        
+
        
+In 26.3.1 [complex.synopsis] add just between the declaration of conj and fabs:
+
        
+
+
        template<class T> complex<T> conj(const complex<T>&);
+template<class T> complex<T> proj(const complex<T>&);
+template<class T> complex<T> fabs(const complex<T>&);
+
        
+
+
        
+In 26.3.7 [complex.value.ops] just after p.6 (return clause of conj) add:
+
        
+
+
        
+
        template<class T> complex<T> proj(const complex<T>& x);
+
        
+
        
+
+Effects: Behaves the same as C99 function cproj, defined in
+subclause 7.3.9.4."
+
        
+
        
+
+
        
+In 26.3.9 [cmplx.over]/1, add one further entry proj to
+the overload list.
+
        
+
+
        
+
        
+The following function templates shall have additional overloads:
+
        
+
        arg           norm 
+conj          polar proj
+imag          real
+
        
+
        
+
+
+
+
+
+
+
        
+
        782. Extended seed_seq constructor is useless
        
+
        Section: 26.4.7.1 [rand.util.seedseq] Status: Ready
+ Submitter: Daniel Krügler Date: 2008-01-27
        
+
        View other active issues in [rand.util.seedseq].
        
+
        View all other issues in [rand.util.seedseq].
        
+
        View all issues with Ready status.
        
+
        Discussion:
        
+
        
+Part of the resolution of n2423, issue 8 was the proposal to
+extend the seed_seq constructor accepting an input range
+as follows (which is now part of N2461):
+
        
+
+
        template<class InputIterator,
+size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>
+seed_seq(InputIterator begin, InputIterator end);
+
        
+
+
        
+First, the expression iterator_traits<InputIterator>::value_type
+is invalid due to missing typename keyword, which is easy to
+fix.
+
        
+
+
        
+Second (and worse), while the language now supports default
+template arguments of function templates, this customization
+point via the second size_t template parameter is of no advantage,
+because u can never be deduced, and worse - because it is a
+constructor function template - it can also never be explicitly
+provided (14.8.1 [temp.arg.explicit]/7).
+
        
+
+
        
+The question arises, which advantages result from a compile-time
+knowledge of u versus a run time knowledge? If run time knowledge
+suffices, this parameter should be provided as normal function
+default argument [Resolution marked (A)], if compile-time knowledge
+is important, this could be done via a tagging template or more
+user-friendly via a standardized helper generator function
+(make_seed_seq), which allows this [Resolution marked (B)].
+
        
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+
        
+Fermilab does not have a strong opinion. Would prefer to go with
+solution A. Bill agrees that solution A is a lot simpler and does the
+job.
+
        
+
        
+Proposed Resolution: Accept Solution A.
+
        
+
        
+
+
        
+Issue 803 claims to make this issue moot.
+
        
+
+
+
+
        Proposed resolution:
        
+
          
+
        1. 
+
          
+In 26.4.7.1 [rand.util.seedseq]/2, class seed_seq synopsis replace:
+
          
+
+
          class seed_seq 
+{ 
+public:
+   ...
+   template<class InputIterator,
+      size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>
+          seed_seq(InputIterator begin, InputIterator end,
+          size_t u = numeric_limits<typename iterator_traits<InputIterator>::value_type>::digits);
+   ...
+};
+
          
+
+
          
+and do a similar replacement in the member description between
+p.3 and p.4.
+
          
+
          2. 
+
+
        2. 
+
          
+In 26.4.7.1 [rand.util.seedseq]/2, class seed_seq synopsis and in the
+member description between p.3 and p.4 replace:
+
          
+
+
          template<class InputIterator,
+  size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>
+	  seed_seq(InputIterator begin, InputIterator end);
+template<class InputIterator, size_t u>
+seed_seq(InputIterator begin, InputIterator end, implementation-defined s);
+
          
+
+
          
+In 26.4.2 [rand.synopsis], header <random> synopsis, immediately after the
+class seed_seq declaration and in 26.4.7.1 [rand.util.seedseq]/2, immediately
+after the class seed_seq definition add:
+
          
+
+
          template<size_t u, class InputIterator>
+  seed_seq make_seed_seq(InputIterator begin, InputIterator end);
+
          
+
+
          
+In 26.4.7.1 [rand.util.seedseq], just before p.5 insert two paragraphs:
+
          
+
+
          
+
          
+The first constructor behaves as if it would provide an
+integral constant expression u of type size_t of value
+numeric_limits<typename iterator_traits<InputIterator>::value_type>::digits.
+
          
+
          
+The second constructor uses an implementation-defined mechanism
+to provide an integral constant expression u of type size_t and
+is called by the function make_seed_seq.
+
          
+
          
+
+
          
+In 26.4.7.1 [rand.util.seedseq], just after the last paragraph add:
+
          
+
+
          
+
          template<size_t u, class InputIterator>
+   seed_seq make_seed_seq(InputIterator begin, InputIterator end);
+
          
+
          
+
          
+where u is used to construct an object s of implementation-defined type.
+
          
+
          
+Returns: seed_seq(begin, end, s);
+
          
+
          
+
          
+
+
          3. 
+
        
+
+
+
+
+
+
+
        
+
        783. thread::id reuse
        
+
        Section: 30.2.1.1 [thread.thread.id] Status: Ready
+ Submitter: Hans Boehm Date: 2008-02-01
        
+
        View all issues with Ready status.
        
+
        Discussion:
        
+
        
+The current working paper 
+(N2497,
+integrated just before Bellevue) is
+not completely clear whether a given thread::id value may be reused once
+a thread has exited and has been joined or detached.  Posix allows
+thread ids (pthread_t values) to be reused in this case.  Although it is
+not completely clear whether this originally was the right decision, it
+is clearly the established practice, and we believe it was always the
+intent of the C++ threads API to follow Posix and allow this.  Howard
+Hinnant's example implementation implicitly relies on allowing reuse
+of ids, since it uses Posix thread ids directly.
+
        
+
+
        
+It is important to be clear on this point, since it the reuse of thread
+ids often requires extra care in client code, which would not be
+necessary if thread ids were unique across all time.  For example, a
+hash table indexed by thread id may have to be careful not to associate
+data values from an old thread with a new one that happens to reuse the
+id.  Simply removing the old entry after joining a thread may not be
+sufficient, if it creates a visible window between the join and removal
+during which a new thread with the same id could have been created and
+added to the table.
+
        
+
+
        [
+post Bellevue Peter adds:
+]
        
+
+
+
        
+
        
+There is a real issue with thread::id reuse, but I urge the LWG to
+reconsider fixing this by disallowing reuse, rather than explicitly allowing
+it. Dealing with thread id reuse is an incredibly painful exercise that
+would just force the world to reimplement a non-conflicting thread::id over
+and over.
+
        
+
        
+In addition, it would be nice if a thread::id could be manipulated
+atomically in a lock-free manner, as motivated by the recursive lock
+example:
+
        
+
+
        
+http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html
+
        
+
        
+
+
+
+
        Proposed resolution:
        
+
        
+Add a sentence to 30.2.1.1 [thread.thread.id]/p1:
+
        
+
+
        
+
        
+An object of type thread::id provides
+a unique identifier for each thread of execution
+and a single distinct value for all thread objects
+that do not represent a thread of execution ([thread.threads.class]).
+Each thread of execution has a thread::id
+that is not equal to the thread::id
+of other threads of execution
+and that is not equal to
+the thread::id of std::thread objects
+that do not represent threads of execution.
+The library may reuse the value of a thread::id of a
+terminated thread that can no longer be joined.
+
        
+
        
+
+
+
+
+
+
        
+
        785. Random Number Requirements in TR1
        
+
        Section: TR1 5.1.4.5 [tr.rand.eng.disc], TR1 5.1.4.6 [tr.rand.eng.xor] Status: New
+ Submitter: John Maddock Date: 2008-01-15
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+Table 16 of TR1 requires that all Pseudo Random Number generators have a
+
        
+
+
        seed(integer-type s)
+
        
+
+
        
+member function that is equivalent to:
+
        
+
+
        mygen = Generator(s)
+
        
+
+
        
+But the generators xor_combine and discard_block have no such seed member, only the
+
        
+
+
        template <class Gen>
+seed(Gen&);
+
        
+
+
        
+member, which will not accept an integer literal as an argument: something that appears to violate the intent of Table 16.
+
        
+
+
        
+So... is this a bug in TR1?
+
        
+
+
        This is a real issue BTW, since the Boost implementation does adhere
+to the requirements of Table 16, while at least one commercial
+implementation does not and follows a strict adherence to sections
+5.1.4.5 and 5.1.4.6 instead.
+
        
+
+
        [
+Jens adds:
+]
        
+
+
+
        
+Both engines do have the necessary
+constructor, therefore the omission of the seed() member
+functions appears to be an oversight.
+
        
+
+
+
+
        Proposed resolution:
        
+
        
+
        
+
+
+
+
+
+
        
+
        786. Thread library timed waits, UTC and monotonic clocks
        
+
        Section: X [datetime.system] Status: New
+ Submitter: Christopher Kohlhoff, Jeff Garland Date: 2008-02-03
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+The draft C++0x thread library requires that the time points of type
+system_time and returned by get_system_time() represent Coordinated
+Universal Time (UTC) (section X [datetime.system]). This can lead to
+surprising behavior when a library user performs a duration-based wait,
+such as condition_variable::timed_wait(). A complete explanation of the
+problem may be found in the
+Rationale for the Monotonic Clock
+section in POSIX, but in summary:
+
        
+
+
          
+
        • 
+Operations such as condition_variable::timed_wait() (and its POSIX
+equivalent, pthread_cond_timedwait()) are specified using absolute times
+to address the problem of spurious wakeups.
+
          • 
+
+
        • 
+The typical use of the timed wait operations is to perform a relative
+wait. This may be achieved by first calculating an absolute time as the
+sum of the current time and the desired duration. In fact, the C++0x
+thread library includes duration-based overloads of
+condition_variable::timed_wait() that behave as if by calling the
+corresponding absolute time overload with a time point value of
+get_system_time() + rel_time.
+
          • 
+
+
        • 
+A UTC clock may be affected by changes to the system time, such as
+synchronization with an external source, leap seconds, or manual changes
+to the clock.
+
          • 
+
+
        • 
+Should the clock change during a timed wait operation, the actual
+duration of the wait will not be the expected length. For example, a
+user may intend a timed wait of one second duration but, due to an
+adjustment of the system clock backwards by a minute, the wait instead
+takes 61 seconds.
+
          • 
+
        
+
+
        
+POSIX solves the problem by introducing a new monotonic clock, which is
+unaffected by changes to the system time. When a condition variable is
+initialized, the user may specify whether the monotonic clock is to be
+used. (It is worth noting that on POSIX systems it is not possible to
+use condition_variable::native_handle() to access this facility, since
+the desired clock type must be specified during construction of the
+condition variable object.)
+
        
+
+
        
+In the context of the C++0x thread library, there are added dimensions
+to the problem due to the need to support platforms other than POSIX:
+
        
+
+
          
+
        • 
+Some environments (such as embedded systems) do not have a UTC clock, but do have a monotonic clock.
+
          • 
+
+
        • 
+Some environments do not have a monotonic clock, but do have a UTC clock.
+
          • 
+
+
        • 
+The Microsoft Windows API's synchronization functions use relative
+timeouts based on an implied monotonic clock. A program that switches
+from the Windows API to the C++0x thread library will now find itself
+susceptible to clock changes.
+
          • 
+
        
+
+
        
+One possible minimal solution:
+
        
+
+
          
+
        • 
+Strike normative references to UTC and an epoch based on 1970-01-01.
+
          • 
+
+
        • 
+Make the semantics of system_time and get_system_time()
+implementation-defined (i.e standard library implementors may choose the
+appropriate underlying clock based on the capabilities of the target
+platform).
+
          • 
+
+
        • 
+Add a non-normative note encouraging use of a monotonic clock.
+
          • 
+
+
        • 
+Remove system_time::seconds_since_epoch().
+
          • 
+
+
        • 
+Change the constructor explicit system_time(time_t secs, nanoseconds ns
+= 0) to explicit system_time(nanoseconds ns).
+
          • 
+
        
+
+
+
+
        Proposed resolution:
        
+
        
+
        
+
+
+
+
+
+
        
+
        787. complexity of binary_search
        
+
        Section: 25.3.3.4 [binary.search] Status: New
+ Submitter: Daniel Krügler Date: 2007-09-08
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+In 25.3.3.4 [binary.search]/3 the complexity of binary_search is described as
+
        
+
+
        
+At most log(last - first) + 2 comparisons.
+
        
+
+
        
+This should be precised and brought in line with the nomenclature used for
+lower_bound, upper_bound, and equal_range.
+
        
+
+
        
+All existing libraries I'm aware of, delegate to
+lower_bound (+ one further comparison). Since
+issue 384
+has now WP status, the resolution of #787 should
+be brought in-line with 384 by changing the + 2
+to + O(1).
+
        
+
+
+
        Proposed resolution:
        
+
        
+Change 25.3.3.4 [binary.search]/3
+
        
+
+
        
+Complexity: At most log2(last - first) + 2 O(1) comparisons.
+
        
+
+
+
+
+
+
        
+
        788. ambiguity in [istream.iterator]
        
+
        Section: 24.5.1 [istream.iterator] Status: New
+ Submitter: Martin Sebor Date: 2008-02-06
        
+
        View other active issues in [istream.iterator].
        
+
        View all other issues in [istream.iterator].
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+The description of how an istream_iterator object becomes an
+end-of-stream iterator is a) ambiguous and b) out of date WRT
+issue 468:
+
        
+
+
        
+istream_iterator reads (using operator>>) successive elements from the
+input stream for which it was constructed. After it is constructed, and
+every time ++ is used, the iterator reads and stores a value of T. If
+the end of stream is reached (operator void*() on the stream returns
+false), the iterator becomes equal to the end-of-stream iterator value.
+The constructor with no arguments istream_iterator() always constructs
+an end of stream input iterator object, which is the only legitimate
+iterator to be used for the end condition. The result of operator* on an
+end of stream is not defined. For any other iterator value a const T& is
+returned. The result of operator-> on an end of stream is not defined.
+For any other iterator value a const T* is returned. It is impossible to
+store things into istream iterators. The main peculiarity of the istream
+iterators is the fact that ++ operators are not equality preserving,
+that is, i == j does not guarantee at all that ++i == ++j. Every time ++
+is used a new value is read.
+
        
+
+
        
+istream::operator void*() returns null if istream::fail() is true,
+otherwise non-null. istream::fail() returns true if failbit or
+badbit is set in rdstate(). Reaching the end of stream doesn't
+necessarily imply that failbit or badbit is set (e.g., after
+extracting an int from stringstream("123") the stream object will
+have reached the end of stream but fail() is false and operator
+void*() will return a non-null value).
+
        
+
+
        
+Also I would prefer to be explicit about calling fail() here
+(there is no operator void*() anymore.)
+
        
+
+
+
        Proposed resolution:
        
+
        
+Change 24.5.1 [istream.iterator]/1:
+
        
+
+
        
+istream_iterator reads (using operator>>) successive elements from the
+input stream for which it was constructed. After it is constructed, and
+every time ++ is used, the iterator reads and stores a value of T. If
+the end of stream is reached the iterator fails to read and store a value of T
+(operator void*() fail() on the stream returns
+false true), the iterator becomes equal to the end-of-stream iterator value.
+The constructor with no arguments istream_iterator() always constructs
+an end of stream input iterator object, which is the only legitimate
+iterator to be used for the end condition. The result of operator* on an
+end of stream is not defined. For any other iterator value a const T& is
+returned. The result of operator-> on an end of stream is not defined.
+For any other iterator value a const T* is returned. It is impossible to
+store things into istream iterators. The main peculiarity of the istream
+iterators is the fact that ++ operators are not equality preserving,
+that is, i == j does not guarantee at all that ++i == ++j. Every time ++
+is used a new value is read.
+
        
+
+
+
+
+
+
        
+
        789. xor_combine_engine(result_type) should be explicit
        
+
        Section: 26.4.4.4 [rand.adapt.xor] Status: Ready
+ Submitter: P.J. Plauger Date: 2008-02-09
        
+
        View all other issues in [rand.adapt.xor].
        
+
        View all issues with Ready status.
        
+
        Discussion:
        
+
        
+xor_combine_engine(result_type) should be explicit. (Obvious oversight.)
+
        
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+Non-controversial. Bill is right, but Fermilab believes that this is
+easy to use badly and hard to use right, and so it should be removed
+entirely. Got into TR1 by well defined route, do we have permission to
+remove stuff? Should probably check with Jens, as it is believed he is
+the originator. Broad consensus that this is not a robust engine
+adapter.
+
        
+
+
+
        Proposed resolution:
        
+
        
+Remove xor_combine_engine from synopsis of 26.4.2 [rand.synopsis].
+
        
+
        
+Remove 26.4.4.4 [rand.adapt.xor] xor_combine_engine.
+
        
+
+
+
+
+
+
        
+
        792. piecewise_constant_distribution is undefined for a range with just one endpoint
        
+
        Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: Ready
+ Submitter: P.J. Plauger Date: 2008-02-09
        
+
        View other active issues in [rand.dist.samp.pconst].
        
+
        View all other issues in [rand.dist.samp.pconst].
        
+
        View all issues with Ready status.
        
+
        Discussion:
        
+
        
+piecewise_constant_distribution is undefined for a range with just one
+endpoint. (Probably should be the same as an empty range.)
+
        
+
+
+
        Proposed resolution:
        
+
        
+Change 26.4.8.5.2 [rand.dist.samp.pconst] paragraph 3b:
+
        
+
+
        
+b) If firstB == lastB or the sequence w has the length zero,
+
        
+
+
+
+
+
+
        
+
        793. discrete_distribution missing constructor
        
+
        Section: 26.4.8.5.1 [rand.dist.samp.discrete] Status: Open
+ Submitter: P.J. Plauger Date: 2008-02-09
        
+
        View all other issues in [rand.dist.samp.discrete].
        
+
        View all issues with Open status.
        
+
        Discussion:
        
+
        
+discrete_distribution should have a constructor like:
+
        
+
+
        template<class _Fn>
+  discrete_distribution(result_type _Count, double _Low, double _High,
+                        _Fn& _Func);
+
        
+
+
        
+(Makes it easier to fill a histogram with function vaues over a range.)
+
        
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+How do you specify the function so that it does not return negative
+values? If you do it is a bad construction. This requirement is already
+there. Where in each bin does one evaluate the function? In the middle.
+Need to revisit tomorrow.
+
        
+
+
+
        Proposed resolution:
        
+
+
+
+
+
+
        
+
        794. piecewise_constant_distribution missing constructor
        
+
        Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: New
+ Submitter: P.J. Plauger Date: 2008-02-09
        
+
        View other active issues in [rand.dist.samp.pconst].
        
+
        View all other issues in [rand.dist.samp.pconst].
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+piecewise_constant_distribution should have a constructor like:
+
        
+
+
        template<class _Fn>
+   piecewise_constant_distribution(size_t _Count,
+            _Ty _Low, _Ty _High, _Fn& _Func);
+
        
+
+
        
+(Makes it easier to fill a histogram with function vaues over a range.
+The two (reference 793) make a sensible replacement for
+general_pdf_distribution.)
+
        
+
+
+
        Proposed resolution:
        
+
+
+
+
+
+
        
+
        798. Refactoring of binders lead to interface breakage
        
+
        Section: D.8 [depr.lib.binders] Status: Ready
+ Submitter: Daniel Krügler Date: 2008-02-14
        
+
        View all other issues in [depr.lib.binders].
        
+
        View all issues with Ready status.
        
+
        Discussion:
        
+
        
+N2521
+and its earlier predecessors have moved the old binders from
+[lib.binders] to D.8 [depr.lib.binders] thereby introducing some renaming
+of the template parameter names (Operation -> Fn). During this
+renaming process the protected data member op was also renamed to
+fn, which seems as an unnecessary interface breakage to me - even if
+this user access point is probably rarely used.
+
        
+
+
+
        Proposed resolution:
        
+
        
+Change D.8.1 [depr.lib.binder.1st]:
+
        
+
+
        
+
        template <class Fn> 
+class binder1st 
+  : public unary_function<typename Fn::second_argument_type, 
+                          typename Fn::result_type> { 
+protected: 
+  Fn fn op; 
+  typename Fn::first_argument_type value; 
+public: 
+  binder1st(const Fn& x, 
+            const typename Fn::first_argument_type& y); 
+  typename Fn::result_type 
+    operator()(const typename Fn::second_argument_type& x) const; 
+  typename Fn::result_type 
+    operator()(typename Fn::second_argument_type& x) const; 
+};
+
        
+
+
        
+
        
+-1- The constructor initializes fn op with x and value with y.
+
        
+
        
+-2- operator() returns fnop(value,x).
+
        
+
        
+
        
+
+
        
+Change D.8.3 [depr.lib.binder.2nd]:
+
        
+
+
        
+
        template <class Fn> 
+class binder2nd
+  : public unary_function<typename Fn::first_argument_type, 
+                          typename Fn::result_type> { 
+protected: 
+  Fn fn op; 
+  typename Fn::second_argument_type value; 
+public: 
+  binder2nd(const Fn& x, 
+            const typename Fn::second_argument_type& y); 
+  typename Fn::result_type 
+    operator()(const typename Fn::first_argument_type& x) const; 
+  typename Fn::result_type 
+    operator()(typename Fn::first_argument_type& x) const; 
+};
+
        
+
+
        
+
        
+-1- The constructor initializes fn op with x and value with y.
+
        
+
        
+-2- operator() returns fnop(value,x).
+
        
+
        
+
        
+
+
+
+
+
+
+
        
+
        800. Issues in 26.4.7.1 [rand.util.seedseq](6)
        
+
        Section: 26.4.7.1 [rand.util.seedseq] Status: Open
+ Submitter: Stephan Tolksdorf Date: 2008-02-18
        
+
        View other active issues in [rand.util.seedseq].
        
+
        View all other issues in [rand.util.seedseq].
        
+
        View all issues with Open status.
        
+
        Discussion:
        
+
        
+The for-loop in the algorithm specification has n iterations, where n is
+defined to be end - begin, i.e. the number of supplied w-bit quantities.
+Previous versions of this algorithm and the general logic behind it
+suggest that this is an oversight and that in the context of the
+for-loop n should be the number of full 32-bit quantities in b (rounded
+upwards). If w is 64, the current algorithm throws away half of all bits
+in b. If w is 16, the current algorithm sets half of all elements in v
+to 0.
+
        
+
+
        
+There are two more minor issues:
+
        
+
+
          
+
        • 
+Strictly speaking end - begin is not defined since
+InputIterator is not required to be a random access iterator.
+
          • 
+
        • 
+Currently all integral types are allowed as input to the seed_seq
+constructor, including bool. IMHO allowing bools unnecessarily
+complicates the implementation without any real benefit to the user.
+I'd suggest to exclude bools as input.
+
          • 
+
        
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+Move to OPEN Bill will try to propose a resolution by the next meeting.
+
        
+
+
        [
+post Bellevue:  Bill provided wording.
+]
        
+
+
+
        
+This issue is made moot if 803 is accepted.
+
        
+
+
+
+
        Proposed resolution:
        
+
        
+Replace 26.4.7.1 [rand.util.seedseq] paragraph 6 with:
+
        
+
+
        
+
        
+Effects: Constructs a seed_seq object by effectively concatenating the
+low-order u bits of each of the elements of the supplied sequence [begin,
+end)
+in ascending order of significance to make a (possibly very large) unsigned
+binary number b having a total of n bits, and then carrying out the
+following
+algorithm:
+
        
+
+
        for( v.clear(); n > 0; n -= 32 )
+   v.push_back(b mod 232), b /= 232;
+
        
+
        
+
+
+
+
+
+
        
+
        801. tuple and pair trivial members
        
+
        Section: 20.3 [tuple] Status: Open
+ Submitter: Lawrence Crowl Date: 2008-02-18
        
+
        View other active issues in [tuple].
        
+
        View all other issues in [tuple].
        
+
        View all issues with Open status.
        
+
        Discussion:
        
+
        
+Classes with trivial special member functions are inherently more
+efficient than classes without such functions.  This efficiency is
+particularly pronounced on modern ABIs that can pass small classes
+in registers.  Examples include value classes such as complex numbers
+and floating-point intervals.  Perhaps more important, though, are
+classes that are simple collections, like pair and tuple.  When the
+parameter types of these classes are trivial, the pairs and tuples
+themselves can be trivial, leading to substantial performance wins.
+
        
+
        
+The current working draft make specification of trivial functions
+(where possible) much easer through defaulted and deleted functions.
+As long as the semantics of defaulted and deleted functions match
+the intended semantics, specification of defaulted and deleted
+functions will yield more efficient programs.
+
        
+
        
+There are at least two cases where specification of an explicitly
+defaulted function may be desirable.
+
        
+
        
+First, the std::pair template has a non-trivial default constructor,
+which prevents static initialization of the pair even when the
+types are statically initializable.  Changing the definition to
+
        
+
+
        pair() = default;
+
        
+
+
        
+would enable such initialization.  Unfortunately, the change is
+not semantically neutral in that the current definition effectively
+forces value initialization whereas the change would not value
+initialize in some contexts.
+
        
+
+
        
+** Does the committee confirm that forced value initialization
+was the intent?  If not, does the committee wish to change the
+behavior of std::pair in C++0x?
+
        
+
        
+Second, the same default constructor issue applies to std::tuple.
+Furthermore, the tuple copy constructor is current non-trivial,
+which effectively prevents passing it in registers.  To enable
+passing tuples in registers, the copy constructor should be
+make explicitly defaulted.  The new declarations are:
+
        
+
+
        tuple() = default;
+tuple(const tuple&) = default;
+
        
+
+
        
+This changes is not implementation neutral.  In particular, it
+prevents implementations based on pointers to the parameter
+types.  It does however, permit implementations using the
+parameter types as bases.
+
        
+
        
+** How does the committee wish to trade implementation
+efficiency versus implementation flexibility?
+
        
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+
        
+General agreement; the first half of the issue is NAD.
+
        
+
        
+Before voting on the second half, it was agreed that a "Strongly Favor"
+vote meant support for trivial tuples (assuming usual requirements met),
+even at the expense of other desired qualities. A "Weakly Favor" vote
+meant support only if not at the expense of other desired qualities.
+
        
+
        
+Concensus: Go forward, but not at expense of other desired qualities.
+
        
+
        
+It was agreed to Alisdair should fold this work in with his other
+pair/tuple action items, above, and that issue 801 should be "open", but
+tabled until Alisdair's proposals are disposed of.
+
        
+
        
+
+
+
        Proposed resolution:
        
+
        
+
        
+
+
+
+
+
+
        
+
        803. Simplification of seed_seq::seq_seq
        
+
        Section: 26.4.7.1 [rand.util.seedseq] Status: Open
+ Submitter: Charles Karney Date: 2008-02-22
        
+
        View other active issues in [rand.util.seedseq].
        
+
        View all other issues in [rand.util.seedseq].
        
+
        View all issues with Open status.
        
+
        Discussion:
        
+
        
+seed_seq(InputIterator begin, InputIterator end); constructs a seed_seq
+object repacking the bits of supplied sequence [begin, end) into a
+32-bit vector.
+
        
+
        
+This repacking triggers several problems:
+
        
+
          
+
        1. 
+Distinctness of the output of seed_seq::generate required the
+introduction of the initial "if (w < 32) v.push_back(n);"  (Otherwise
+the unsigned short vectors [1, 0] and [1] generate the same sequence.)
+
          2. 
+
        2. 
+Portability demanded the introduction of the template parameter u.
+(Otherwise some sequences could not be obtained on computers where no
+integer types are exactly 32-bits wide.)
+
          3. 
+
        3. 
+The description and algorithm have become unduly complicated.
+
          4. 
+
        
+
        
+I propose simplifying this seed_seq constructor to be "32-bit only".
+Despite it's being simpler, there is NO loss of functionality (see
+below).
+
        
+
        
+Here's how the description would read
+
        
+
        
+
        
+26.4.7.1 [rand.util.seedseq] Class seed_seq
+
        
+
+
        
+
        template<class InputIterator>
+  seed_seq(InputIterator begin, InputIterator end);
+
        
+
        
+
        
+5 Requires: NO CHANGE
+
        
+
        
+6 Effects: Constructs a seed_seq object by
+
        
+
        
+
        for (InputIterator s = begin; s != end; ++s)
+   v.push_back((*s) mod 2^32);
+
        
+
        
+
        
+
        
+
        
+
+
        
+Discussion:
+
        
+
        
+The chief virtues here are simplicity, portability, and generality.
+
        
+
          
+
        • 
+Simplicity -- compare the above specification with the
+n2461 proposal.
+
          • 
+
        • 
+Portability -- with iterator_traits<InputIterator>::value_type =
+uint_least32_t the user is guaranteed to get the same behavior across
+platforms.
+
          • 
+
        • 
+Generality -- any behavior that the
+n2461
+proposal can achieve can be
+obtained with this simpler proposal (albeit with a shuffling of bits
+in the input sequence).
+
          • 
+
        
+
        
+Arguments (and counter-arguments) against making this change (and
+retaining the
+n2461
+behavior) are:
+
        
+
          
+
        • 
+
          
+The user can pass an array of unsigned char and seed_seq will nicely
+ repack it.
+
          
+
          
+ Response: So what?  Consider the seed string "ABC".  The
+ n2461
+ proposal results in
+
          
+
          v = { 0x3, 0x434241 };
+
          
+
          
+while the simplified proposal yields
+
          
+
          v = { 0x41, 0x42, 0x43 };
+
          
+
          
+The results produced by seed_seq::generate with the two inputs are
+different but nevertheless equivalently "mixed up" and this remains
+true even if the seed string is long.
+
          
+
          • 
+
        • 
+
          
+With long strings (e.g., with bit-length comparable to the number of
+ bits in the state), v is longer (by a factor of 4) with the simplified
+ proposal and seed_seq::generate will be slower.
+
          
+
          
+Response: It's unlikely that the efficiency of seed_seq::generate will
+ be a big issue.  If it is, the user is free to repack the seed vector
+ before constructing seed_seq.
+
          
+
          • 
+
        • 
+
          
+A user can pass an array of 64-bit integers and all the bits will be
+ used.
+
          
+
          
+ Response: Indeed.  However, there are many instances in the 
+ n2461
+ where integers are silently coerced to a narrower width and this
+ should just be a case of the user needing to read the documentation.
+ The user can of course get equivalent behavior by repacking his seed
+ into 32-bit pieces.  Furthermore, the unportability of the 
+ n2461
+ proposal with
+
          
+
          unsigned long s[] = {1, 2, 3, 4};
+seed_seq q(s, s+4);
+
          
+
          
+ which typically results in v = {1, 2, 3, 4} on 32-bit machines and in
+v = {1, 0, 2, 0, 3, 0, 4, 0} on 64-bit machines is a major pitfall for
+ unsuspecting users.
+
          
+
          • 
+
        
+
+
        
+Note: this proposal renders moot issues 782 and 800.
+
        
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+Walter needs to ask Fermilab for guidance. Defer till tomorrow. Bill likes the proposed resolution.
+
        
+
+
+
        Proposed resolution:
        
+
        
+Change 26.4.7.1 [rand.util.seedseq]:
+
        
+
+
        
+
        template<class InputIterator, 
+  size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>
+  seed_seq(InputIterator begin, InputIterator end);
+
        
+
        
+
        
+-5- Requires: InputIterator shall satisfy the requirements of an input iterator (24.1.1)
+such that iterator_traits<InputIterator>::value_type shall denote an integral type.
+
        
+
        
+-6- Constructs a seed_seq object by rearranging some or all of the bits of the supplied sequence
+[begin,end) of w-bit quantities into 32-bit units, as if by the following: 
+
        
+
        
+First extract the rightmost u bits from each of the n = end
+- begin elements of the supplied sequence and concatenate all the
+extracted bits to initialize a single (possibly very large) unsigned
+binary number, b = ∑n-1i=0 (begin[i] 
+mod 2u) ˇ 2wˇi (in which the bits of each begin[i]
+are treated as denoting an unsigned quantity). Then carry out 
+the following algorithm:
+
        
+
        
+v.clear(); 
+if ($w$ < 32) 
+  v.push_back($n$); 
+for( ; $n$ > 0; --$n$) 
+  v.push_back(b mod 232), b /= 232;
+
        
+
        
+
        
+for (InputIterator s = begin; s != end; ++s)
+   v.push_back((*s) mod 232);
+
        
+
        
+
        
+
        
+
+
+
+
+
+
        
+
        804. Some problems with classes error_code/error_condition
        
+
        Section: 19.4 [syserr] Status: New
+ Submitter: Daniel Krügler Date: 2008-02-24
        
+
        View other active issues in [syserr].
        
+
        View all other issues in [syserr].
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
          
+
        1. 
+
          
+19.4.2.1 [syserr.errcode.overview]/1, class error_code and
+19.4.3.1 [syserr.errcondition.overview]/, class error_condition synopses
+declare an expository data member cat_:
+
          
+
          const error_category& cat_; // exposition only
+
          
+
          
+which is used to define the semantics of several members. The decision
+to use a member of reference type lead to several problems:
+
          
+
            
+
          1. 
+The classes are not (Copy)Assignable, which is probably not the intent.
+
            2. 
+
          2. 
+The post conditions of all modifiers from
+19.4.2.3 [syserr.errcode.modifiers] and 19.4.3.3 [syserr.errcondition.modifiers], resp.,
+cannot be fulfilled.
+
            3. 
+
          
+
          
+The simple fix would be to replace the reference by a pointer member.
+
          
+
          2. 
+
+
        2. 
+I would like to give the editorial remark that in both classes the
+constrained operator=
+overload (template with ErrorCodeEnum argument) makes in invalid
+usage of std::enable_if: By using the default value for the second enable_if
+parameter the return type would be defined to be void& even in otherwise
+valid circumstances - this return type must be explicitly provided (In
+error_condition the first declaration uses an explicit value, but of wrong
+type).
+
          3. 
+
+
        3. 
+The member function message throws clauses (
+19.4.1.2 [syserr.errcat.virtuals]/10, 19.4.2.4 [syserr.errcode.observers]/8, and
+19.4.3.4 [syserr.errcondition.observers]/6) guarantee "throws nothing",
+although
+they return a std::string by value, which might throw in out-of-memory
+conditions (see related issue 771).
+
          4. 
+
        
+
+
+
        Proposed resolution:
        
+
        
+In 19.4.1.2 [syserr.errcat.virtuals], remove the throws clause p. 10.
+
        
+
+
        
+
        virtual string message(int ev) const = 0;
+
        
+
+
        
+
        
+Returns: A string that describes the error condition denoted by ev.
+
        
+
        
+Throws: Nothing.
+
        
+
        
+
        
+
+
        
+In 19.4.2.1 [syserr.errcode.overview]/1, class error_code synopsis, modifiers section,
+replace the current operator= overload by the following:
+
        
+
+
        
+
        template <class ErrorCodeEnum> 
+  typename enable_if<is_error_code_enum<ErrorCodeEnum>::value, error_code>::type& 
+    operator=(ErrorCodeEnum e);
+
        
+
        
+
+
        
+In the private section of the same class replace the current
+data member cat_ definition by:
+
        
+
+
        
+const error_category&* cat_; // exposition only
+
        
+
+
        
+In 19.4.2.2 [syserr.errcode.constructors], change p. 2 to read:
+
        
+
+
        
+
        error_code();
+
        
+
        
+
        
+
        ...
        
+
+
        
+Postconditions: val_ == 0 and cat_ == &system_category.
+
        
+
        
+
        
+
+
        
+Change 19.4.2.2 [syserr.errcode.constructors] p. 5 to read:
+
        
+
+
        
+
        error_code(int val, const error_category& cat);
+
        
+
        
+
        ...
        
+
        
+Postconditions: val_ == val and cat_ == &cat.
+
        
+
        
+
        
+
+
        
+In 19.4.2.3 [syserr.errcode.modifiers], change p. 1 to read:
+
        
+
+
        
+
        void assign(int val, const error_category& cat);
+
        
+
        
+
        
+
        ...
        
+
+
        
+Postconditions: val_ == val and cat_ == &cat.
+
        
+
        
+
        
+
+
        
+In 19.4.2.3 [syserr.errcode.modifiers], change the operator= signature to read:
+
        
+
+
        
+
        template <class ErrorCodeEnum> 
+  typename enable_if<is_error_code_enum<ErrorCodeEnum>::value, error_code>::type& 
+    operator=(ErrorCodeEnum e);
+
        
+
        
+
+
        
+In 19.4.2.4 [syserr.errcode.observers], change p. 3 to read:
+
        
+
+
        
+
        const error_category& category() const;
+
        
+
        
+
        
+
        ...
        
+
+
        
+Returns: *cat_.
+
        
+
        
+
        
+
+
        
+In 19.4.2.4 [syserr.errcode.observers], remove the throws clause p. 8.
+
        
+
+
        
+
        string message() const;
+
        
+
        
+
        
+
        ...
        
+
+
        
+Throws: Nothing.
+
        
+
        
+
        
+
+
        
+In 19.4.3.1 [syserr.errcondition.overview]/1, class error_condition
+synopsis, constructors section, replace the template constructor
+overload declaration by one with an added "::value"
+
        
+
+
        
+
        template <class ErrorConditionEnum>
+  error_condition(ErrorConditionEnum e,
+    typename enable_if<is_error_condition_enum<ErrorConditionEnum>::value>::type* = 0);
+
        
+
        
+
+
        
+In 19.4.3.1 [syserr.errcondition.overview]/1, class error_condition synopsis,
+modifiers section,
+replace the operator= overload declaration by:
+
        
+
+
        
+
        template<typename ErrorConditionEnum> 
+  typename enable_if<is_error_condition_enum<ErrorConditionEnum>::value, error_code error_condition>::type & 
+     operator=( ErrorConditionEnum e );
+
        
+
        
+
+
        
+In the private section of the same class replace the current
+data member cat_ definition by:
+
        
+
+
        const error_category&* cat_; // exposition only
+
        
+
+
        
+In 19.4.3.2 [syserr.errcondition.constructors], change p. 2 to read:
+
        
+
+
        
+
        error_condition();
+
        
+
        
+
        
+
        ...
        
+
+
        
+Postconditions: val_ == 0 and cat_ == &posix_category.
+
        
+
        
+
        
+
+
        
+In the same section, change p. 5 to read:
+
        
+
+
        
+
        error_condition(int val, const error_category& cat);
+
        
+
        
+
        
+
        ...
        
+
+
        
+Postconditions: val_ == val and cat_ == &cat.
+
        
+
        
+
        
+
+
        
+In 19.4.3.3 [syserr.errcondition.modifiers], change p. 1 to read:
+
        
+
+
        
+
        void assign(int val, const error_category& cat);
+
        
+
        
+
        
+Postconditions: val_ == val and cat_ == &cat.
+
        
+
        
+
        
+
+
        
+In the same section replace the current operator= overload declaration by:
+
        
+
+
        
+
        template <class ErrorConditionEnum> 
+  typename enable_if<is_error_condition_enum<ErrorConditionEnum>::value, error_condition>::type&
+    operator=(ErrorConditionEnum e);
+
        
+
+
        
+In 19.4.3.4 [syserr.errcondition.observers], change p. 3 to read:
+
        
+
+
        
+
        const error_category& category() const;
+
        
+
        
+
        
+Returns: *cat_.
+
        
+
        
+
        
+
+
        
+In 19.4.3.4 [syserr.errcondition.observers], remove the throws clause p. 6.
+
        
+
+
        
+
        string message() const;
+
        
+
        
+
        
+
        ...
        
+
+
        
+Throws: Nothing.
+
        
+
        
+
        
+
+
+
+
+
+
+
+
        
+
        805. posix_error::posix_errno concerns
        
+
        Section: 19.4 [syserr] Status: New
+ Submitter: Jens Maurer Date: 2008-02-24
        
+
        View other active issues in [syserr].
        
+
        View all other issues in [syserr].
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+19.4 [syserr]
+
        
+
+
        namespace posix_error {
+  enum posix_errno {
+    address_family_not_supported, // EAFNOSUPPORT
+    ...
+
        
+
+
        
+should rather use the new scoped-enum  facility (7.2 [dcl.enum]),
+which would avoid the necessity for a new posix_error
+namespace, if I understand correctly.
+
        
+
+
        [
+Further discussion:
+]
        
+
+
+
        
+
        
+See N2347,
+Strongly Typed Enums, since renamed Scoped Enums.
+
        
+
        
+Alberto Ganesh Barbati also raised this issue in private email, and also proposed the scoped-enum solution.
+
        
+
        
+Nick Stoughton asked in Bellevue that posix_error and posix_errno not be used as names. The LWG agreed.
+
        
+
        
+The wording for the Proposed resolution was provided by Beman Dawes.
+
        
+
        
+
+
+
        Proposed resolution:
        
+
        
+Change System error support 19.4 [syserr] as indicated:
+
        
+
+
        namespace posix_error {
+  enum posix_errno class errc {
+    address_family_not_supported, // EAFNOSUPPORT
+    ...
+    wrong_protocol_type, // EPROTOTYPE
+  };
+} // namespace posix_error
+
+template <> struct is_error_condition_enum<posix_error::posix_errno errc>
+  : public true_type {}
+
+namespace posix_error {
+  error_code make_error_code(posix_errno errc e);
+  error_condition make_error_condition(posix_errno errc e);
+} // namespace posix_error
+
        
+
+
        
+Change System error support 19.4 [syserr] :
+
        
+
+
        
+The is_error_code_enum and is_error_condition_enum templates may be
+specialized for user-defined types to indicate that such a type is
+eligible for class error_code and class error_condition automatic
+conversions, respectively.
+
        
+
+
        
+Change System error support 19.4 [syserr] and its subsections:
+
        
+
+
        
+
          
+
        • 
+remove all occurrences of posix_error::
+
          • 
+
        • 
+change all instances of posix_errno to errc
+
          • 
+
        • 
+change all instances of posix_category to generic_category
+
          • 
+
        • 
+change all instances of get_posix_category to get_generic_category
+
          • 
+
        
+
        
+
+
        
+Change Error category objects 19.4.1.5 [syserr.errcat.objects], paragraph 2:
+
        
+
+
        
+Remarks: The object's default_error_condition and equivalent virtual
+functions shall behave as specified for the class error_category. The
+object's name virtual function shall return a pointer to the string
+"POSIX" "GENERIC".
+
        
+
+
        
+Change 19.4.2.5 [syserr.errcode.nonmembers] Class error_code non-member functions as indicated:
+
        
+
+
        
+
        error_code make_error_code(posix_errno errc e);
+
        
+
+
        
+Returns: error_code(static_cast<int>(e), posixgeneric_category).
+
        
+
        
+
+
        
+Change 19.4.3.5 [syserr.errcondition.nonmembers] Class error_condition non-member functions as indicated:
+
        
+
+
        
+
        error_condition make_error_condition(posix_errno errc e);
+
        
+
+
        
+Returns: error_condition(static_cast<int>(e), posixgeneric_category).
+
        
+
        
+
+
+
+
        Rationale:
        
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
        Names Considered
        portable
+Too non-specific. Did not wish to reserve such a common word in
+namespace std. Not quite the right meaning, either.
+
        portable_error
+Too long. Explicit qualification is always required for scoped enums, so
+a short name is desirable. Not quite the right meaning, either. May be
+misleading because *_error in the std lib is usually an exception class
+name.
+
        std_error
+Fairly short, yet explicit. But in fully qualified names like
+std::std_error::not_enough_memory, the std_ would be unfortunate. Not
+quite the right meaning, either. May be misleading because *_error in
+the std lib is usually an exception class name.
+
        generic
+Short enough. The category could be generic_category. Fully qualified
+names like std::generic::not_enough_memory read well. Reserving in
+namespace std seems dicey.
+
        generic_error
+Longish. The category could be generic_category. Fully qualified names
+like std::generic_error::not_enough_memory read well. Misleading because
+*_error in the std lib is usually an exception class name.
+
        generic_err
+A bit less longish. The category could be generic_category. Fully
+qualified names like std::generic_err::not_enough_memory read well.
+
        gen_err
+Shorter still. The category could be generic_category. Fully qualified
+names like std::gen_err::not_enough_memory read well.
+
        generr
+Shorter still. The category could be generic_category. Fully qualified
+names like std::generr::not_enough_memory read well.
+
        error
+Shorter still. The category could be generic_category. Fully qualified
+names like std::error::not_enough_memory read well. Do we want to use
+this general a name?
+
        err
+Shorter still. The category could be generic_category. Fully qualified
+names like std::err::not_enough_memory read well. Although alone it
+looks odd as a name, given the existing errno and namespace std names,
+it seems fairly intuitive.
+Problem: err is used throughout the standard library as an argument name
+and in examples as a variable name; it seems too confusing to add yet
+another use of the name.
+
        errc
+Short enough. The "c" stands for "constant". The category could be
+generic_category. Fully qualified names like
+std::errc::not_enough_memory read well. Although alone it looks odd as a
+name, given the existing errno and namespace std names, it seems fairly
+intuitive. There are no uses of errc in the current C++ standard.
+
        
+
+
+
+
+
+
        
+
        806. unique_ptr::reset effects incorrect, too permissive
        
+
        Section: 20.6.11.2.5 [unique.ptr.single.modifiers] Status: New
+ Submitter: Peter Dimov Date: 2008-03-13
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+void unique_ptr::reset(T* p = 0) is currently specified as:
+
        
+
+
        
+Effects: If p == get() there are no effects. Otherwise get_deleter()(get()).
+
        
+
+
        
+There are two problems with this. One, if get() == 0 and p != 0, the
+deleter is called with a NULL pointer, and this is probably not what's
+intended (the destructor avoids calling the deleter with 0.)
+
        
+
+
        
+Two, the special check for get() == p is generally not needed and such a
+situation usually indicates an error in the client code, which is being
+masked. As a data point, boost::shared_ptr was changed to assert on such
+self-resets in 2001 and there were no complaints.
+
        
+
+
        
+One might think that self-resets are necessary for operator= to work; it's specified to perform
+
        
+
+
        reset( u.release() );
+
        
+
+
        
+and the self-assignment
+
        
+
+
        p = move(p);
+
        
+
+
        
+might appear to result in a self-reset. But it doesn't; the release() is
+performed first, zeroing the stored pointer. In other words, p.reset(
+q.release() ) works even when p and q are the same unique_ptr, and there
+is no need to special-case p.reset( q.get() ) to work in a similar
+scenario, as it definitely doesn't when p and q are separate.
+
        
+
+
+
+
        Proposed resolution:
        
+
+
        
+Change 20.6.11.2.5 [unique.ptr.single.modifiers]:
+
        
+
+
        
+
        void reset(T* p = 0);
+
        
+
        
+-4- Effects: If p == get() == 0 there are no effects. Otherwise get_deleter()(get()).
+
        
+
        
+
+
        
+Change 20.6.11.3.3 [unique.ptr.runtime.modifiers]:
+
        
+
+
        
+
        void reset(T* p = 0);
+
        
+
        
+
        ...
        
+
        
+-2- Effects: If p == get() == 0 there are no effects. Otherwise get_deleter()(get()).
+
        
+
        
+
        
+
+
+
+
+
+
+
        
+
        807. tuple construction should not fail unless its element's construction fails
        
+
        Section: 20.3.1.2 [tuple.cnstr] Status: New
+ Submitter: Howard Hinnant Date: 2008-03-13
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+527 Added a throws clause to bind constructors.  I believe the same throws clause
+should be added to tuple except it ought to take into account move constructors as well.
+
        
+
+
+
        Proposed resolution:
        
+
        
+Add to 20.3.1.2 [tuple.cnstr]:
+
        
+
+
        
+
        
+For each tuple constructor and assignment operator, an exception is thrown only if the construction
+or assignment of one of the types in Types throws an exception.
+
        
+
        
+
+
+
+
+
+
        
+
        808. [forward] incorrect redundant specification
        
+
        Section: 20.2.2 [forward] Status: New
+ Submitter: Jens Maurer Date: 2008-03-13
        
+
        View other active issues in [forward].
        
+
        View all other issues in [forward].
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+p4 (forward) says:
+
        
+
        
+Return type: If T is an lvalue-reference type, an lvalue; otherwise, an rvalue.
+
        
+
+
        
+First of all, lvalue-ness and rvalue-ness are properties of an expression,
+not of a type (see 3.10 [basic.lval]).  Thus, the phrasing "Return type" is wrong.
+Second, the phrase says exactly what the core language wording says for
+folding references in 14.3.1 [temp.arg.type]/p4  and for function return values
+in 5.2.2 [expr.call]/p10.  (If we feel the wording should be retained, it should
+at most be a note with cross-references to those sections.)
+
        
+
        
+The prose after the example talks about "forwarding as an int& (an lvalue)" etc.
+In my opinion, this is a category error:  "int&" is a type, "lvalue" is a
+property of an expression, orthogonal to its type.  (Btw, expressions cannot
+have reference type, ever.)
+
        
+
        
+Similar with move:
+
        
+
        
+Return type: an rvalue.
+
        
+
        
+is just wrong and also redundant.
+
        
+
+
+
        Proposed resolution:
        
+
        
+Change 20.2.2 [forward] as indicated:
+
        
+
+
        
+
        template <class T> T&& forward(typename identity<T>::type&& t);
+
        
+
+
        
+
        ...
        
+
        
+Return type: If T is an lvalue-reference type, an lvalue; otherwise, an rvalue.
+
        
+
        ...
        
+
        
+-7- In the first call to factory, A1 is deduced as int, so 2 is forwarded to A's constructor
+as an int&& (an rvalue). In the second call to factory, A1 is deduced
+as int&, so i is forwarded to A's constructor as an int& (an lvalue).
+In both cases, A2 is deduced as double, so 1.414 is forwarded to A's constructor as
+double&& (an rvalue).
+
        
+
        
+
+
        template <class T> typename remove_reference<T>::type&& move(T&& t);
+
        
+
+
        
+
        ...
        
+
        
+Return type:  an rvalue.
+
        
+
        
+
+
        
+
+
+
+
+
+
+
        
+
        809. std::swap should be overloaded for array types
        
+
        Section: 25.2.3 [alg.swap] Status: New
+ Submitter: Niels Dekker Date: 2008-02-28
        
+
        View all other issues in [alg.swap].
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+For the sake of generic programming, the header <algorithm> should provide an
+overload of std::swap for array types:
+
        template<class T, size_t N> void swap(T (&a)[N], T (&b)[N]);
+
        
+
+
+
        
+It became apparent to me that this overload is missing, when I considered how to write a swap
+function for a generic wrapper class template.
+(Actually I was thinking of Boost's value_initialized.)
+Please look at the following template, W, and suppose that is intended to be a very
+generic wrapper:
+
        template<class T> class W {
+public:
+   T data;
+};
+
        
+Clearly W<T> is CopyConstructible and CopyAssignable, and therefore
+Swappable, whenever T is CopyConstructible and CopyAssignable.
+Moreover, W<T> is also Swappable when T is an array type
+whose element type is CopyConstructible and CopyAssignable.
+Still it is recommended to add a custom swap function template to such a class template,
+for the sake of efficiency and exception safety.
+(E.g., Scott Meyers, Effective C++, Third Edition, item 25: Consider support for a non-throwing
+swap.)
+This function template is typically written as follows:
+
        template<class T> void swap(W<T>& x, W<T>& y) {
+  using std::swap;
+  swap(x.data, y.data);
+}
+
        
+Unfortunately, this will introduce an undesirable inconsistency, when T is an array.
+For instance, W<std::string[8]> is Swappable, but the current Standard does not
+allow calling the custom swap function that was especially written for W!
+
        W<std::string[8]> w1, w2;  // Two objects of a Swappable type.
+std::swap(w1, w2);  // Well-defined, but inefficient.
+using std::swap;
+swap(w1, w2);  // Ill-formed, just because ADL finds W's swap function!!!
+
        
+
+W's swap function would try to call std::swap for an array,
+std::string[8], which is not supported by the Standard Library.
+This issue is easily solved by providing an overload of std::swap for array types.
+This swap function should be implemented in terms of swapping the elements of the arrays, so that
+it would be non-throwing for arrays whose element types have a non-throwing swap.
+
+
+
        
+Note that such an overload of std::swap should also support multi-dimensional
+arrays. Fortunately that isn't really an issue, because it would do so automatically, by
+means of recursion.
+
        
+
+
        
+For your information, there was a discussion on this issue at comp.lang.c++.moderated: [Standard
+Library] Shouldn't std::swap be overloaded for C-style arrays?
+
        
+
+
+
        Proposed resolution:
        
+
        
+Add an extra condition to the definition of Swappable requirements [swappable] in 20.1.1 [utility.arg.requirements]:
+
        
+
        
+- T is Swappable if T is an array type whose element type is Swappable.
+
        
+
        
+Add the following to 25.2.3 [alg.swap]:
+
        
+
        
+
        template<class T, size_t N> void swap(T (&a)[N], T (&b)[N]);
+
        
+
        
+Requires: Type T shall be Swappable.
+
        
+
        
+Effects: swap_ranges(a, a + N, b);
+
        
+
        
+
+
+
+
+
+
        
+
        810. Missing traits dependencies in operational semantics of extended manipulators
        
+
        Section: 27.6.4 [ext.manip] Status: New
+ Submitter: Daniel Krügler Date: 2008-03-01
        
+
        View other active issues in [ext.manip].
        
+
        View all other issues in [ext.manip].
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+The recent draft (as well as the original proposal n2072) uses an
+operational semantic
+for get_money ([ext.manip]/3) and put_money ([ext.manip]/5), which uses
+
        
+
+
        istreambuf_iterator<charT>
+
        
+
+
        
+and
+
        
+
+
        ostreambuf_iterator<charT>
+
        
+
+
        
+resp, instead of the iterator instances, with explicitly provided
+traits argument (The operational semantic defined by f is also traits
+dependent). This is an obvious oversight because both *stream_buf
+c'tors expect a basic_streambuf<charT,traits> as argument.
+
        
+
        
+The same problem occurs within the get_time and put_time semantic (p.
+7 and p. 9)
+of n2071 incorporated in N2521, where additional to the problem we
+have an editorial issue in get_time (streambuf_iterator instead of
+istreambuf_iterator).
+
        
+
+
+
        Proposed resolution:
        
+
        
+In 27.6.4 [ext.manip]/3 within function f replace the first line
+
        
+
+
        template <class charT, class traits, class moneyT> 
+void f(basic_ios<charT, traits>& str, moneyT& mon, bool intl) { 
+   typedef istreambuf_iterator<charT, traits> Iter;
+   ...
+
        
+
+
        
+In 27.6.4 [ext.manip]/4 remove the first template charT parameter:
+
        
+
+
        template <class charT, class moneyT> unspecified put_money(const moneyT& mon, bool intl = false);
+
        
+
+
        
+In 27.6.4 [ext.manip]/5 within function f replace the first line
+
        
+
+
        template <class charT, class traits, class moneyT> 
+void f(basic_ios<charT, traits>& str, const moneyT& mon, bool intl) { 
+  typedef ostreambuf_iterator<charT, traits> Iter;
+  ...
+
        
+
+
        
+In 27.6.4 [ext.manip]/7 within function f replace the first line
+
        
+
+
        template <class charT, class traits> 
+void f(basic_ios<charT, traits>& str, struct tm *tmb, const charT *fmt) { 
+  typedef istreambuf_iterator<charT, traits> Iter;
+  ...
+
        
+
+
        
+In 27.6.4 [ext.manip]/8 add const:
+
        
+
+
        template <class charT> unspecified put_time(const struct tm *tmb, const charT *fmt);
+
        
+
+
        
+In 27.6.4 [ext.manip]/9 within function f replace the first line
+
        
+
+
        template <class charT, class traits> 
+void f(basic_ios<charT, traits>& str, const struct tm *tmb, const charT *fmt) { 
+  typedef ostreambuf_iterator<charT, traits> Iter;
+  ...
+
        
+
+
        
+Add to the <iomanip> synopsis in 27.6 [iostream.format]
+
        
+
+
        template <class moneyT> unspecified get_money(moneyT& mon, bool intl = false);
+template <class moneyT> unspecified put_money(const moneyT& mon, bool intl = false);
+template <class charT> unspecified get_time(struct tm *tmb, const charT *fmt);
+template <class charT> unspecified put_time(const struct tm *tmb, const charT *fmt);
+
        
+
+
+
+
+
+
+
        
+
        811. pair of pointers no longer works with literal 0
        
+
        Section: 20.2.3 [pairs] Status: New
+ Submitter: Doug Gregor Date: 2008-03-14
        
+
        View all other issues in [pairs].
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        #include <utility>
+
+int main()
+{
+   std::pair<char *, char *> p (0,0);
+}
+
        
+
+
        
+I just got a bug report about that, because it's valid C++03, but not
+C++0x. The important realization, for me, is that the emplace
+proposal---which made push_back variadic, causing the push_back(0)
+issue---didn't cause this break in backward compatibility. The break
+actually happened when we added this pair constructor as part of adding
+rvalue references into the language, long before variadic templates or
+emplace came along:
+
        
+
+
        template<class U, class V> pair(U&& x, V&& y);
+
        
+
+
        
+Now, concepts will address this issue by constraining that pair
+constructor to only U's and V's that can properly construct "first" and
+"second", e.g. (from
+N2322):
+
        
+
+
        template<class U , class V >
+requires Constructible<T1, U&&> && Constructible<T2, V&&>
+pair(U&& x , V&& y );
+
        
+
+
+
+
        Proposed resolution:
        
+
        
+
        
+
+
+
+
+
+
        
+
        812. unsolicited multithreading considered harmful?
        
+
        Section: 25.3.1 [alg.sort] Status: New
+ Submitter: Paul McKenney Date: 2008-02-27
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+Multi-threading is a good thing, but unsolicited multi-threading can
+potentially be harmful.  For example, sort() performance might be
+greatly increased via a multithreaded implementation.  However, such
+a multithreaded implementation could result in concurrent invocations
+of the user-supplied comparator.  This would in turn result in problems
+given a caching comparator that might be written for complex sort keys.
+Please note that this is not a theoretical issue, as multithreaded
+implementations of sort() already exist.
+
        
+
        
+Having a multithreaded sort() available is good, but it should not
+be the default for programs that are not explicitly multithreaded.
+Users should not be forced to deal with concurrency unless they have
+asked for it.
+
        
+
+
        [
+This may be covered by
+N2410
+Thread-Safety in the Standard Library (Rev 1).
+]
        
+
+
+
+
        Proposed resolution:
        
+
        
+
        
+
+
+
+
+
+
        
+
        813. "empty" undefined for shared_ptr
        
+
        Section: 20.6.12.2 [util.smartptr.shared] Status: New
+ Submitter: Matt Austern Date: 2008-02-26
        
+
        View other active issues in [util.smartptr.shared].
        
+
        View all other issues in [util.smartptr.shared].
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+Several places in 20.6.12.2 [util.smartptr.shared] refer to an "empty" shared_ptr.
+However, that term is nowhere defined. The closest thing we have to a
+definition is that the default constructor creates an empty shared_ptr
+and that a copy of a default-constructed shared_ptr is empty. Are any
+other shared_ptrs empty? For example, is shared_ptr((T*) 0) empty? What
+are the properties of an empty shared_ptr? We should either clarify this
+term or stop using it.
+
        
+
        
+One reason it's not good enough to leave this term up to the reader's
+intuition is that, in light of
+N2351
+and issue 711, most readers'
+intuitive understanding is likely to be wrong. Intuitively one might
+expect that an empty shared_ptr is one that doesn't store a pointer,
+but, whatever the definition is, that isn't it.
+
+
+
        [
+Peter adds:
+]
        
+
+
+
        
+
        
+Or, what is an "empty" shared_ptr?
+
        
+
+
          
+
        • 
+
          
+Are any other shared_ptrs empty?
+
          
+
          
+Yes. Whether a given shared_ptr instance is empty or not is (*)
+completely specified by the last mutating operation on that instance.
+Give me an example and I'll tell you whether the shared_ptr is empty or
+not.
+
          
+
          
+(*) If it isn't, this is a legitimate defect.
+
          
+
          • 
+
+
        • 
+
          
+For example, is shared_ptr((T*) 0) empty?
+
          
+
          
+No. If it were empty, it would have a use_count() of 0, whereas it is
+specified to have an use_count() of 1.
+
          
+
          • 
+
+
        • 
+
          
+What are the properties of an empty shared_ptr?
+
          
+
          
+The properties of an empty shared_ptr can be derived from the
+specification. One example is that its destructor is a no-op. Another is
+that its use_count() returns 0. I can enumerate the full list if you
+really like.
+
          
+
          • 
+
+
        • 
+
          
+We should either clarify this term or stop using it.
+
          
+
          
+I don't agree with the imperative tone
+
          
+
          
+A clarification would be either a no-op - if it doesn't contradict the
+existing wording - or a big mistake if it does.
+
          
+
          
+I agree that a clarification that is formally a no-op may add value.
+
          
+
          • 
+
+
        • 
+
          
+However, that term is nowhere defined.
+
          
+
          
+Terms can be useful without a definition. Consider the following
+simplistic example. We have a type X with the following operations
+defined:
+
          
+
          X x;
+X x2(x);
+X f(X x);
+X g(X x1, X x2);
+
          
+
          
+A default-constructed value is green.
          
+A copy has the same color as the original.
          
+f(x) returns a red value if the argument is green, a green value otherwise.
          
+g(x1,x2) returns a green value if the arguments are of the same color, a red value otherwise.
+
          
+
+
          
+Given these definitions, you can determine the color of every instance
+of type X, even if you have absolutely no idea what green and red mean.
+
          
+
+
          
+Green and red are "nowhere defined" and completely defined at the same time.
+
          
+
          • 
+
        
+
+
        
+Alisdair's wording is fine.
+
        
+
        
+
+
+
        Proposed resolution:
        
+
        
+Append the following sentance to 20.6.12.2 [util.smartptr.shared]
+
        
+
        
+The shared_ptr class template stores a pointer, usually obtained
+via new. shared_ptr implements semantics of
+shared ownership; the last remaining owner of the pointer is responsible for
+destroying the object, or otherwise releasing  the resources associated with
+the stored pointer. A shared_ptr object that does not own
+a pointer is said to be empty.
+
        
+
+
+
+
+
+
        
+
        814. vector<bool>::swap(reference, reference) not defined
        
+
        Section: 23.2.7 [vector.bool] Status: New
+ Submitter: Alisdair Meredith Date: 2008-03-17
        
+
        View other active issues in [vector.bool].
        
+
        View all other issues in [vector.bool].
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+vector<bool>::swap(reference, reference) has no definition.
+
        
+
+
+
        Proposed resolution:
        
+
        
+
        
+
+
+
+
+
+
        
+
        815. std::function and reference_closure do not use perfect forwarding
        
+
        Section: 20.5.15.2.4 [func.wrap.func.inv] Status: New
+ Submitter: Alisdair Meredith Date: 2008-03-16
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+std::function and reference_closure should use "perfect forwarding" as
+described in the rvalue core proposal.
+
        
+
+
+
        Proposed resolution:
        
+
        
+
        
+
+
+
+
+
+
        
+
        816. Should bind()'s returned functor have a nofail copy ctor when bind() is nofail?
        
+
        Section: 20.5.11.1.3 [func.bind.bind] Status: New
+ Submitter: Stephan T. Lavavej Date: 2008-02-08
        
+
        View other active issues in [func.bind.bind].
        
+
        View all other issues in [func.bind.bind].
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+Library Issue 527 notes that bind(f, t1, ..., tN)
+should be nofail when f, t1, ..., tN have nofail copy ctors.
+
        
+
        
+However, no guarantees are provided for the copy ctor of the functor
+returned by bind().  (It's guaranteed to have a copy ctor, which can
+throw implementation-defined exceptions: bind() returns a forwarding
+call wrapper, TR1 3.6.3/2.  A forwarding call wrapper is a call wrapper,
+TR1 3.3/4.  Every call wrapper shall be CopyConstructible, TR1 3.3/4. 
+Everything without an exception-specification may throw
+implementation-defined exceptions unless otherwise specified, C++03
+17.4.4.8/3.)
+
        
+
        
+Should the nofail guarantee requested by Library Issue 527 be extended
+to cover both calling bind() and copying the returned functor?
+
        
+
+
        [
+Howard adds:
+]
        
+
+
+
        
+tuple construction should probably have a similar guarantee.
+
        
+
+
+
+
        Proposed resolution:
        
+
        
+
        
+
+
+
+
+
+
        
+
        817. bind needs to be moved
        
+
        Section: 20.5.11.1.3 [func.bind.bind] Status: New
+ Submitter: Howard Hinnant Date: 2008-03-17
        
+
        View other active issues in [func.bind.bind].
        
+
        View all other issues in [func.bind.bind].
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+The functor retureed by bind() should have a move constructor that
+requires only move construction of its contained functor and bound arguments.
+That way move-only functors can be passed to objects such as thread.
+
        
+
        
+This issue is related to issue 816.
+
        
+
+
+
        Proposed resolution:
        
+
        
+
        
+
+
+
+
+
+
        
+
        818. wording for memory ordering
        
+
        Section: 29.1 [atomics.order] Status: New
+ Submitter: Jens Maurer Date: 2008-03-22
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+29.1 [atomics.order] p1 says in the table that
+
        
+
+
        
+
+
+
+
+
+
+
+
+
        ElementMeaning
        memory_order_acq_relthe operation has both acquire and release semantics
        
+
        
+
+
        
+To my naked eye, that seems to imply that even an atomic read has both
+acquire and release semantics.
+
        
+
+
        
+Then, p1 says in the table:
+
        
+
+
        
+
+
+
+
+
+
+
+
+
        ElementMeaning
        memory_order_seq_cstthe operation has both acquire and release semantics,
+    and, in addition, has sequentially-consistent operation ordering
        
+
        
+
+
        
+So that seems to be "the same thing" as memory_order_acq_rel, with additional
+constraints.
+
        
+
+
        
+I'm then reading p2, where it says:
+
        
+
+
        
+The memory_order_seq_cst operations that load a value are acquire operations
+on the affected locations. The memory_order_seq_cst operations that store a value
+are release operations on the affected locations.
+
        
+
+
        
+That seems to imply that atomic reads only have acquire semantics.  If that
+is intended, does this also apply to memory_order_acq_rel and the individual
+load/store operations as well?
+
        
+
+
        
+Also, the table in p1 contains phrases with "thus" that seem to indicate
+consequences of normative wording in 1.10 [intro.multithread].  That shouldn't be in
+normative text, for the fear of redundant or inconsistent specification with
+the other normative text.
+
        
+
+
        
+Double-check 29.4.4 [atomics.types.operations] that each
+operation clearly says whether it's a load or a store operation, or
+both.  (It could be clearer, IMO.  Solution not in current proposed resolution.)
+
        
+
+
        
+29.1 [atomics.order] p2:  What's a "consistent execution"?  It's not defined in
+1.10 [intro.multithread], it's just used in notes there.
+
        
+
+
        
+And why does 29.4.4 [atomics.types.operations] p9 for "load" say:
+
        
+
+
+
        
+Requires: The order argument shall not be memory_order_acquire
+nor memory_order_acq_rel.
+
        
+
+
        
+(Since this is exactly the same restriction as for "store", it seems to be a typo.)
+
        
+
+
        
+And then: 29.4.4 [atomics.types.operations] p12:
+
        
+
+
        
+These operations are read-modify-write operations in the sense of the
+"synchronizes with" definition (1.10 [intro.multithread]), so both such an operation and the
+evaluation that produced the input value synchronize with any evaluation
+that reads the updated value.
+
        
+
+
        
+This is redundant with 1.10 [intro.multithread], see above for the reasoning.
+
        
+
+
+
        Proposed resolution:
        
+
        
+Replace the cross-reference in p1 to refer to 1.1 [intro.scope] instead of
+1.7 [intro.memory].
+Rephrase the table in as follows (maybe don't use a table):
+
        
+
+
        
+
        
+For memory_order_relaxed, no operation orders memory.
+
        
+
+
        
+For memory_order_release, memory_order_acq_rel, and memory_order_seq_cst,
+a store operation performs a release operation on the affected memory location.
+
        
+
+
        
+For memory_order_acquire, memory_order_acq_rel, and memory_order_seq_cst,
+a load operation performs an acquire operation on the affected memory location.
+
        
+
        
+
+
        
+Rephrase 29.1 [atomics.order] p2:
+
        
+
+
        
+The memory_order_seq_cst operations that load a value are
+acquire operations on the affected locations. The
+memory_order_seq_cst operations that store a value are release
+operations on the affected locations.
+In addition, in a consistent
+execution, tThere must be is a single
+total order S on all
+memory_order_seq_cst operations, consistent with the happens before
+order and modification orders for all affected locations, such that each
+memory_order_seq_cst operation observes either the last preceding
+modification according to this order S, or the result of an operation
+that is not memory_order_seq_cst. [Note: Although it is not explicitly
+required that S include locks, it can always be extended to an order
+that does include lock and unlock operations, since the ordering between
+those is already included in the happens before ordering. -- end note]
+
        
+
+
        
+Rephrase 29.4.4 [atomics.types.operations] p12 as:
+
        
+
+
        
+Effects: Atomically replaces the value pointed to by object or by
+this with desired. Memory is affected according to the value of order.
+These operations are read-modify-write operations in the sense of the
+"synchronizes with" definition (1.10 [intro.multithread]), so both such an operation and the
+evaluation that produced the input value synchronize with any evaluation
+that reads the updated value.
+
        
+
+
        
+Same in p15, p20, p22.
+
        
+
+
+
+
+
+
+
        
+
        819. rethrow_if_nested
        
+
        Section: 18.7.6 [except.nested] Status: New
+ Submitter: Alisdair Meredith Date: 2008-03-25
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+Looking at the wording I submitted for rethrow_if_nested, I don't think I
+got it quite right.
+
        
+
+
        
+The current wording says:
+
        
+
+
        
+
        template <class E> void rethrow_if_nested(const E& e);
+
        
+
        
+
        
+Effects: Calls e.rethrow_nested() only if e
+is publicly derived from nested_exception.
+
        
+
        
+
        
+
+
        
+This is trying to be a bit subtle, by requiring e (not E) to be publicly
+derived from nested_exception the idea is that a dynamic_cast would be
+required to be sure.  Unfortunately, if e is dynamically but not statically
+derived from nested_exception, e.rethrow_nested() is ill-formed.
+
        
+
+
+
        Proposed resolution:
        
+
+
+
+
+
+
        
+
        820. current_exception()'s interaction with throwing copy ctors
        
+
        Section: 18.7.5 [propagation] Status: New
+ Submitter: Stephan T. Lavavej Date: 2008-03-26
        
+
        View other active issues in [propagation].
        
+
        View all other issues in [propagation].
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+As of N2521, the Working Paper appears to be silent about what
+current_exception() should do if it tries to copy the currently handled
+exception and its copy constructor throws.  18.7.5 [propagation]/7 says "If the
+function needs to allocate memory and the attempt fails, it returns an
+exception_ptr object that refers to an instance of bad_alloc.", but
+doesn't say anything about what should happen if memory allocation
+succeeds but the actual copying fails.
+
        
+
+
        
+I see three alternatives: (1) return an exception_ptr object that refers
+to an instance of some fixed exception type, (2) return an exception_ptr
+object that refers to an instance of the copy ctor's thrown exception
+(but if that has a throwing copy ctor, an infinite loop can occur), or
+(3) call terminate().
+
        
+
+
        
+I believe that terminate() is the most reasonable course of action, but
+before we go implement that, I wanted to raise this issue.
+
        
+
+
        [
+Peter's summary:
+]
        
+
+
+
        
+
        
+The current practice is to not have throwing copy constructors in
+exception classes, because this can lead to terminate() as described in
+15.5.1 [except.terminate]. Thus calling terminate() in this situation seems
+consistent and does not introduce any new problems.
+
        
+
+
        
+However, the resolution of core issue 475 may relax this requirement:
+
        
+
+
        
+The CWG agreed with the position that std::uncaught_exception() should
+return false during the copy to the exception object and that std::terminate()
+should not be called if that constructor exits with an exception.
+
        
+
+
        
+Since throwing copy constructors will no longer call terminate(), option
+(3) doesn't seem reasonable as it is deemed too drastic a response in a
+recoverable situation.
+
        
+
+
        
+Option (2) cannot be adopted by itself, because a potential infinite
+recursion will need to be terminated by one of the other options.
+
        
+
+
        
+
+
+
        Proposed resolution:
        
+
        
+Add the following paragraph after 18.7.5 [propagation]/7:
+
        
+
+
        
+
        
+Returns (continued): If the attempt to copy the current exception
+object throws an exception, the function returns an exception_ptr that
+refers to the thrown exception or, if this is not possible, to an
+instance of bad_exception.
+
        
+
        
+[Note: The copy constructor of the thrown exception may also fail, so
+the implementation is allowed to substitute a bad_exception to avoid
+infinite recursion. -- end note.]
+
        
+
        
+
+
+
+
+
+
+
        
+
        821. Minor cleanup : unique_ptr
        
+
        Section: 20.6.11.3.3 [unique.ptr.runtime.modifiers] Status: New
+ Submitter: Alisdair Meredith Date: 2008-03-30
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+Reading resolution of LWG issue 673 I noticed the following:
+
        
+
+
        
+
        void reset(T* pointer p = 0 pointer());
+
        
+
+
        
+-1- Requires: Does not accept pointer types which are convertible
+to T* pointer (diagnostic
+required). [Note: One implementation technique is to create a private
+templated overload. -- end note]
+
        
+
        
+
+
        
+This could be cleaned up by mandating the overload as a public deleted
+function.  In addition, we should probably overload reset on nullptr_t
+to be a stronger match than the deleted overload. Words...
+
        
+
+
+
        Proposed resolution:
        
+
        
+Add to class template definition in 20.6.11.3 [unique.ptr.runtime]
+
        
+
+
        
+
        // modifiers 
+T* release(); 
+void reset(T* p = 0); 
+void reset( nullptr_t );
+template< typename T > void reset( T ) = delete;
+void swap(unique_ptr&& u);
+
        
+
        
+
+
        
+Update 20.6.11.3.3 [unique.ptr.runtime.modifiers]
+
        
+
+
        
+
        void reset(pointer p = pointer());
+void reset(nullptr_t);
+
        
+
+
        
+-1- Requires: Does not accept pointer types which are convertible
+to pointer (diagnostic
+required). [Note: One implementation technique is to create a private
+templated overload. -- end note]
+
        
+
        
+Effects: If get() == nullptr there are no effects. Otherwise get_deleter()(get()). 
+
        
+
        ...
        
+
        
+
+
        [
+Note this wording incorporates resolutions for 806 (New) and 673 (Ready).
+]
        
+
+
+
+
+
+
+
        
+
        822. Object with explicit copy constructor no longer CopyConstructible
        
+
        Section: 20.1.1 [utility.arg.requirements] Status: New
+ Submitter: James Kanze Date: 2008-04-01
        
+
        View other active issues in [utility.arg.requirements].
        
+
        View all other issues in [utility.arg.requirements].
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+I just noticed that the following program is legal in C++03, but
+is forbidden in the current draft:
+
        
+
+
        #include <vector>
+#include <iostream>
+
+class Toto
+{
+public:
+    Toto() {}
+    explicit Toto( Toto const& ) {}
+} ;
+
+int
+main()
+{
+    std::vector< Toto > v( 10 ) ;
+    return 0 ;
+}
+
        
+
+
        
+Is this change intentional?  (And if so, what is the
+justification?  I wouldn't call such code good, but I don't see
+any reason to break it unless we get something else in return.)
+
        
+
+
+
+
        Proposed resolution:
        
+
        
+In 20.1.1 [utility.arg.requirements] change Table 33: MoveConstructible requirements [moveconstructible]:
+
        
+
+
        
+
+
+
+
+
+
+
+
+
+
+
        expressionpost-condition
        T t(rv) = rvt is equivalent to the value of rv before the construction
        ...
        
+
        
+
+
        
+In 20.1.1 [utility.arg.requirements] change Table 34: CopyConstructible requirements [copyconstructible]:
+
        
+
+
        
+
+
+
+
+
+
+
+
+
+
+
        expressionpost-condition
        T t(u) = uthe value of u is unchanged and is equivalent to t
        ...
        
+
        
+
+
+
+
+
+
        
+
        823. identity<void> seems broken
        
+
        Section: 20.2.2 [forward] Status: New
+ Submitter: Walter Brown Date: 2008-04-09
        
+
        View other active issues in [forward].
        
+
        View all other issues in [forward].
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+N2588 seems to have added an operator() member function to the
+identity<> helper in 20.2.2 [forward].  I believe this change makes it no
+longer possible to instantiate identity<void>, as it would require
+forming a reference-to-void type as this operator()'s parameter type.
+
        
+
+
        
+Suggested resolution:  Specialize identity<void> so as not to require
+the member function's presence.
+
        
+
+
+
        Proposed resolution:
        
+
        
+
        
+
+
+
+
+
+
        
+
        824. rvalue ref issue with basic_string inserter
        
+
        Section: 21.3.8.9 [string.io] Status: New
+ Submitter: Alisdair Meredith Date: 2008-04-10
        
+
        View all other issues in [string.io].
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+In the current working paper, the <string> header synopsis at the end of
+21.2 [string.classes] lists a single operator<< overload
+for basic_string.
+
        
+
+
        template<class charT, class traits, class Allocator>
+ basic_ostream<charT, traits>&
+   operator<<(basic_ostream<charT, traits>&& os,
+              const basic_string<charT,traits,Allocator>& str);
+
        
+
+
        
+The definition in 21.3.8.9 [string.io] lists two:
+
        
+
+
        template<class charT, class traits, class Allocator>
+ basic_ostream<charT, traits>&
+   operator<<(basic_ostream<charT, traits>& os,
+              const basic_string<charT,traits,Allocator>& str);
+
+template<class charT, class traits, class Allocator>
+ basic_ostream<charT, traits>&
+   operator<<(basic_ostream<charT, traits>&& os,
+              const basic_string<charT,traits,Allocator>& str);
+
        
+
+
        
+I believe the synopsis in 21.2 [string.classes] is correct, and the first of the two
+signatures in 21.3.8.9 [string.io] should be deleted.
+
        
+
+
+
        Proposed resolution:
        
+
        
+
        
+
+
+
+
+
+
        
+
        825. Missing rvalues reference stream insert/extract operators?
        
+
        Section: 19.4.2.1 [syserr.errcode.overview], 20.6.12.2.8
+[util.smartptr.shared.io], 22.2.8 [facets.examples], 23.3.5.3
+[bitset.operators], 26.3.6 [complex.ops], 27.5 [stream.buffers], 28.9
+[re.submatch] Status: New
+ Submitter: Alisdair Meredith Date: 2008-04-10
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+Should the following use rvalues references to stream in insert/extract
+operators?
+
        
+
+
          
+
        • 19.4.2.1 [syserr.errcode.overview]
          • 
+
        • 20.6.12.2.8 [util.smartptr.shared.io]
          • 
+
        • 22.2.8 [facets.examples]
          • 
+
        • 23.3.5.3 [bitset.operators]
          • 
+
        • 26.3.6 [complex.ops]
          • 
+
        • Doubled signatures in 27.5 [stream.buffers] for character inserters
+(ref 27.6.2.6.4 [ostream.inserters.character])
++ definition 27.6.2.6.4 [ostream.inserters.character]
          • 
+
        • 28.9 [re.submatch]
          • 
+
        
+
+
+
        Proposed resolution:
        
+
        
+
        
+
+
+
+
+
+
        
+
        826. Equivalent of %'d, or rather, lack thereof?
        
+
        Section: 22.2.2.2 [locale.nm.put] Status: New
+ Submitter: Peter Dimov Date: 2008-04-07
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+In the spirit of printf vs iostream...
+
        
+
+
        
+POSIX printf says that %'d should insert grouping characters (and the
+implication is that in the absence of ' no grouping characters are
+inserted). The num_put facet, on the other hand, seems to always insert
+grouping characters. Can this be considered a defect worth fixing for
+C++0x? Maybe ios_base needs an additional flag?
+
        
+
+
        [
+Pablo Halpern:
+]
        
+
+
+
        
+I'm not sure it constitutes a defect, but I would be in favor of adding
+another flag (and corresponding manipulator).
+
        
+
+
        [
+Martin Sebor:
+]
        
+
+
+
        
+I don't know if it qualifies as a defect but I agree that there
+should be an easy way to control whether the thousands separator
+should or shouldn't be inserted. A new flag would be in line with
+the current design of iostreams (like boolalpha, showpos, or
+showbase).
+
        
+
+
+
        Proposed resolution:
        
+
        
+
        
+
+
+
+
+
+
        
+
        827. constexpr shared_ptr::shared_ptr()?
        
+
        Section: 20.6.12.2.1 [util.smartptr.shared.const] Status: New
+ Submitter: Peter Dimov Date: 2008-04-11
        
+
        View all other issues in [util.smartptr.shared.const].
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+Would anyone object to making the default constructor of shared_ptr (and
+weak_ptr and enable_shared_from_this) constexpr? This would enable
+static initialization for shared_ptr variables, eliminating another
+unfair advantage of raw pointers.
+
        
+
+
+
        Proposed resolution:
        
+
        
+
        
+
+
+
+
+
+
        
+
        828. Static initialization for std::mutex?
        
+
        Section: 30.3.1.1 [thread.mutex.class] Status: New
+ Submitter: Peter Dimov Date: 2008-04-18
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+[Note: I'm assuming here that 3.6.2 [basic.start.init]/1 will be fixed.]
+
        
+
        
+Currently std::mutex doesn't support static initialization. This is a
+regression with respect to pthread_mutex_t, which does. I believe that
+we should strive to eliminate such regressions in expressive power where
+possible, both to ease migration and to not provide incentives to (or
+force) people to forego the C++ primitives in favor of pthreads.
+
        
+
+
+
        Proposed resolution:
        
+
        
+
        
+
+
+
+
+
+
        
+
        829. current_exception wording unclear about exception type
        
+
        Section: 18.7.5 [propagation] Status: New
+ Submitter: Beman Dawes Date: 2008-04-20
        
+
        View other active issues in [propagation].
        
+
        View all other issues in [propagation].
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        Consider this code:
        
+
+
        
+
        exception_ptr xp;
        
+
        try {do_something(); }
+
+catch (const runtime_error& ) {xp = current_exception();}
+
+...
+
+rethrow_exception(xp);
        
+
        
+
+
        
+Say do_something() throws an exception object of type 
+range_error. What is the type of the exception object thrown by 
+rethrow_exception(xp) above? It must have a type of range_error; 
+if it were of type runtime_error it still isn't possible to 
+propagate an exception and the exception_ptr/current_exception/rethrow_exception 
+machinery serves no useful purpose.
+
        
+
+
        
+Unfortunately, the current wording does not explicitly say that. Different 
+people read the current wording and come to different conclusions. While it may 
+be possible to deduce the correct type from the current wording, it would be 
+much clearer to come right out and explicitly say what the type of the referred 
+to exception is.
+
        
+
+
        [
+Peter adds:
+]
        
+
+
+
        
+
        
+I don't like the proposed resolution of 829. The normative text is
+unambiguous that the exception_ptr refers to the currently handled
+exception. This term has a standard meaning, see 15.3 [except.handle]/8; this is the
+exception that throw; would rethrow, see 15.1 [except.throw]/7.
+
        
+
        
+A better way to address this is to simply add the non-normative example
+in question as a clarification. The term currently handled exception
+should be italicized and cross-referenced. A [Note: the currently
+handled exception is the exception that a throw expression without an
+operand (15.1 [except.throw]/7) would rethrow. --end note] is also an option.
+
        
+
        
+
+
+
+
        Proposed resolution:
        
+
+
        
+After 18.7.5 [propagation] , paragraph 7, add the indicated text:
+
        
+
+
        
+
        exception_ptr current_exception();
        
+
+
        
+
        
+Returns: exception_ptr object that refers 
+to the currently handled exception or a copy of the currently handled 
+exception, or a null exception_ptr object if no exception is being handled. If 
+the function needs to allocate memory and the attempt fails, it returns an
+exception_ptr object that refers to an instance of bad_alloc. 
+It is unspecified whether the return values of two successive calls to
+current_exception refer to the same exception object. 
+[Note: that is, it 
+is unspecified whether current_exception
+creates a new copy each time it is called.
+-- end note]
+
        
+
+
        
+Remarks: The type of the exception object 
+referred to by the returned exception_ptr is the most-derived 
+type of the currently handled exception.
+
        
+
+
        
+Throws: nothing.
+
        
+
+
        
+
        
+
+
+
+
+
+
+
        
+
        830. Incomplete list of char_traits specializations
        
+
        Section: 21.1 [char.traits] Status: New
+ Submitter: Dietmar Kühl Date: 2008-04-23
        
+
        View other active issues in [char.traits].
        
+
        View all other issues in [char.traits].
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+  Paragraph 4 of 21.1 [char.traits] mentions that this
+  section specifies two specializations (char_traits<char>
+  and (char_traits<wchar_t>). However, there are actually
+  four specializations provided, i.e. in addition to the two above also
+  char_traits<char16_t> and char_traits<char32_t>).
+  I guess this was just an oversight and there is nothing wrong with just
+  fixing this.
+
        
+
+
        [
+Alisdair adds:
+]
        
+
+
        
+char_traits< char16/32_t >
+should also be added to <ios_fwd> in 27.2 [iostream.forward], and all the specializations
+taking a char_traits parameter in that header.
+
        
+
+
+
        Proposed resolution:
        
+
        
+  Replace paragraph 4 of 21.1 [char.traits] by:
+
        
+
        
+
        
+  This subclause specifies a struct template, char_traits<charT>,
+  and four explicit specializations of it, char_traits<char>,
+  char_traits<char16_t>, char_traits<char32_t>, and
+  char_traits<wchar_t>, all of which appear in the header
+  <string> and satisfy the requirements below.
+
        
+
        
+
+
+
+
+
+
        
+
        831. wrong type for not_eof()
        
+
        Section: 21.1.3 [char.traits.specializations] Status: New
+ Submitter: Dietmar Kühl Date: 2008-04-23
        
+
        View all other issues in [char.traits.specializations].
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+  In Table 56 (Traits requirements) the not_eof() member function
+  is using an argument of type e which denotes an object of
+  type X::int_type. However, the specializations in
+  21.1.3 [char.traits.specializations] all use char_type.
+  This would effectively mean that the argument type actually can't
+  represent EOF in the first place. I'm pretty sure that the type used
+  to be int_type which is quite obviously the only sensible
+  argument.
+
        
+
        
+  This issue is close to being editorial. I suspect that the proposal
+  changing this section to include the specializations for char16_t
+  and char32_t accidentally used the wrong type.
+
        
+
+
+
        Proposed resolution:
        
+
        
+  In 21.1.3.1 [char.traits.specializations.char],
+  21.1.3.2 [char.traits.specializations.char16_t],
+  21.1.3.3 [char.traits.specializations.char32_t], and
+   [char.traits.specializations.wchar_t] correct the
+  argument type from char_type to int_type.
+
        
+
+
+
+
+
+
        
+
        832. Applying constexpr to System error support
        
+
        Section: 19.4 [syserr] Status: New
+ Submitter: Beman Dawes Date: 2008-05-14
        
+
        View other active issues in [syserr].
        
+
        View all other issues in [syserr].
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+Initialization of objects of class error_code
+(19.4.2 [syserr.errcode]) and class
+error_condition (19.4.3 [syserr.errcondition]) can be made simpler and more reliable by use of
+the new constexpr feature 
+[N2349]
+of C++0x. Less code will need to be
+generated for both library implementations and user programs when
+manipulating constant objects of these types. 
+
        
+
+
        
+This was not proposed originally because the constant expressions
+proposal was moving into the standard at about the same time as the
+Diagnostics Enhancements proposal 
+[N2241],
+and it wasn't desirable to
+make the later depend on the former. There were also technical concerns
+as to how constexpr would apply to references. Those concerns are now
+resolved; constexpr can't be used for references, and that fact is
+reflected in the proposed resolution.
+
        
+
+
        
+Thanks to Jens Maurer, Gabriel Dos Reis, and Bjarne Stroustrup for clarification of constexpr requirements.
+
        
+
+
        
+LWG issue 804 is related in that it raises the question of whether the
+exposition only member cat_ of class error_code (19.4.2 [syserr.errcode]) and class
+error_condition (19.4.3 [syserr.errcondition]) should be presented as a reference or pointer.
+While in the context of 804 that is arguably an editorial question,
+presenting it as a pointer becomes more or less required with this
+proposal, given constexpr does not play well with references. The
+proposed resolution thus changes the private member to a pointer, which
+also brings it in sync with real implementations.
+
        
+
+
+
        Proposed resolution:
        
+
        
+The proposed wording assumes the LWG 805 proposed wording has been
+applied to the WP, resulting in the former posix_category being renamed
+generic_category. If 805 has not been applied, the names in this
+proposal must be adjusted accordingly.
+
        
+
+
        
+Change 19.4.1.1 [syserr.errcat.overview] Class
+error_category overview error_category synopsis  as
+indicated:
+
        
+
+
        const error_category& get_generic_category();
+const error_category& get_system_category();
+
+static extern const error_category&* const generic_category = get_generic_category();
+static extern const error_category&* const native_category system_category = get_system_category();
+
        
+
+
        
+Change 19.4.1.5 [syserr.errcat.objects] Error category objects as indicated:
+
        
+
+
        
+
        extern const error_category&* const get_generic_category();
+
        
+
        
+Returns: A reference generic_category shall point
+to an a statically initialized object of a type derived from
+class error_category.
+
        
+
+
        
+Remarks: The object's default_error_condition and equivalent virtual
+functions shall behave as specified for the class error_category. The
+object's name virtual function shall return a pointer to the string
+"GENERIC".
+
        
+
+
        extern const error_category&* const get_system_category();
+
        
+
+
        
+Returns: A reference system_category shall point
+to an a statically
+initialized object of a type derived from class error_category.
+
        
+
+
        
+Remarks:  The object's equivalent virtual functions shall behave as
+specified for class error_category. The object's name virtual function
+shall return a pointer to the string "system". The object's
+default_error_condition virtual function shall behave as follows:
+
        
+
+
        
+If the argument ev corresponds to a POSIX errno value posv, the function
+shall return error_condition(posv, generic_category). Otherwise, the
+function shall return error_condition(ev, system_category). What
+constitutes correspondence for any given operating system is
+unspecified. [Note: The number of potential system error codes is large
+and unbounded, and some may not correspond to any POSIX errno value.
+Thus implementations are given latitude in determining correspondence.
+-- end note]
+
        
+
        
+
+
        
+Change 19.4.2.1 [syserr.errcode.overview] Class error_code overview as indicated:
+
        
+
+
        class error_code {
+public:
+  ...;
+  constexpr error_code(int val, const error_category&* cat);
+  ...
+  void assign(int val, const error_category&* cat);
+  ...
+  const error_category&* category() const;
+  ...
+private:
+  int val_;                    // exposition only
+  const error_category&* cat_; // exposition only
+
        
+
+
        
+Change 19.4.2.2 [syserr.errcode.constructors] Class error_code constructors as indicated:
+
        
+
+
        
+
        constexpr error_code(int val, const error_category&* cat);
+
        
+
        
+Effects: Constructs an object of type error_code.
+
        
+
        
+Postconditions: val_ == val and cat_ == cat.
+
        
+
        
+Throws: Nothing.
+
        
+
        
+
+
        
+Change 19.4.2.3 [syserr.errcode.modifiers] Class error_code modifiers  as indicated:
+
        
+
+
        
+
        void assign(int val, const error_category&* cat);
+
        
+
        
+Postconditions: val_ == val and cat_ == cat.
+
        
+
        
+Throws: Nothing.
+
        
+
        
+
+
        
+Change 19.4.2.4 [syserr.errcode.observers] Class error_code observers  as indicated:
+
        
+
+
        
+
        const error_category&* category() const;
+
        
+
+
        
+Returns: cat_.
+
        
+
        
+Throws: Nothing.
+
        
+
        
+
+
        
+Change 19.4.3.1 [syserr.errcondition.overview] Class error_condition overview   as indicated:
+
        
+
+
        
+
        class error_condition {
+public:
+  ...;
+  constexpr error_condition(int val, const error_category&* cat);
+  ...
+  void assign(int val, const error_category&* cat);
+  ...
+  const error_category&* category() const;
+  ...
+private:
+  int val_;                    // exposition only
+  const error_category&* cat_; // exposition only
+
        
+
        
+
+
        
+Change 19.4.3.2 [syserr.errcondition.constructors] Class error_condition constructors as indicated:
+
        
+
+
        
+
        constexpr error_condition(int val, const error_category&* cat);
+
        
+
        
+Effects: Constructs an object of type error_condition.
+
        
+
        
+Postconditions: val_ == val and cat_ == cat.
+
        
+
        
+Throws: Nothing.
+
        
+
        
+
+
        
+Change 19.4.3.3 [syserr.errcondition.modifiers] Class error_condition modifiers as indicated:
+
        
+
+
        
+
        void assign(int val, const error_category&* cat);
+
        
+
        
+Postconditions: val_ == val and cat_ == cat.
+
        
+
        
+Throws: Nothing.
+
        
+
        
+
+
        
+Change 19.4.3.4 [syserr.errcondition.observers] Class error_condition observers as indicated:
+
        
+
+
        
+
        const error_category&* category() const;
+
        
+
        
+Returns: cat_.
+
        
+
        
+Throws: Nothing.
+
        
+
        
+
+
        
+Throughout 19.4 [syserr] System error support, change "category()."  to "category()->".
+Appears approximately six times.
+
        
+
+
        
+[Partially Editorial] In 19.4.4 [syserr.compare] Comparison operators,
+paragraphs 2 and 4, change "category.equivalent("  to
+"category()->equivalent(".
+
        
+
+
+
+
+
+
        
+
        833. Freestanding implementations header list needs review for C++0x
        
+
        Section: 17.4.1.3 [compliance] Status: New
+ Submitter: Beman Dawes Date: 2008-05-14
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+Once the C++0x standard library is feature complete, the LWG needs to
+review 17.4.1.3 [compliance] Freestanding implementations header list to
+ensure it reflects LWG consensus.
+
        
+
+
+
        Proposed resolution:
        
+
+
+
+
+
+
        
+
        834. Unique_ptr::pointer requirements underspecified
        
+
        Section: 20.6.11.2 [unique.ptr.single] Status: New
+ Submitter: Daniel Krügler Date: 2008-05-14
        
+
        View all issues with New status.
        
+
        Discussion:
        
+
        
+Issue 673 (including recent updates by 821) proposes a useful
+extension point for unique_ptr by granting support for an optional
+deleter_type::pointer to act as pointer-like replacement for element_type*
+(In the following: pointer).
+
        
+
        
+Unfortunately no requirements are specified for the type pointer which has
+impact on at least two key features of unique_ptr:
+
        
+
+
          
+
        1. Operational fail-safety.
          2. 
+
        2. (Well-)Definedness of expressions.
          3. 
+
        
+
+
        
+Unique_ptr specification makes great efforts to require that essentially *all*
+operations cannot throw and therefore adds proper wording to the affected
+operations of the deleter as well. If user-provided pointer-emulating types
+("smart pointers") will be allowed, either *all* throw-nothing clauses have to
+be replaced by weaker "An exception is thrown only if pointer's {op} throws
+an exception"-clauses or it has to be said explicitly that all used
+operations of
+pointer are required *not* to throw. I understand the main focus of unique_ptr
+to be as near as possible to the advantages of native pointers which cannot
+fail and thus strongly favor the second choice. Also, the alternative position
+would make it much harder to write safe and simple template code for
+unique_ptr. Additionally, I assume that a general statement need to be given
+that all of the expressions of pointer used to define semantics are required to
+be well-formed and well-defined (also as back-end for 762).
+
        
+
+
+
        Proposed resolution:
        
+
        
+Add the following sentence just at the end of the newly proposed
+20.6.11.2 [unique.ptr.single]/p. 3:
+
        
+
+
        
+unique_ptr<T, D>::pointer's operations shall be well-formed, shall have well
+defined behavior, and shall not throw exceptions.
+
        
+
+
+
+
+
+
        
+
        835. tying two streams together (correction to DR 581)
        
+
        Section: 27.4.4.2 [basic.ios.members] Status: New
+ Submitter: Martin Sebor Date: 2008-05-17
        
+
        View other active issues in [basic.ios.members].
        
+
        View all other issues in [basic.ios.members].
        
+
        View all issues with New status.
        
+
        Discussion:
        
+       
        
+
+The fix for
+issue 581,
+now integrated into the working paper, overlooks a couple of minor
+problems.
+
+       
        
+       
        
+
+First, being an unformatted function once again, flush()
+is required to create a sentry object whose constructor must, among
+other things, flush the tied stream. When two streams are tied
+together, either directly or through another intermediate stream
+object, flushing one will also cause a call to flush() on
+the other tied stream(s) and vice versa, ad infinitum. The program
+below demonstrates the problem.
+
+       
        
+       
        
+
+Second, as Bo Persson notes in his
+comp.lang.c++.moderated post,
+for streams with the unitbuf flag set such
+as std::stderr, the destructor of the sentry object will
+again call flush(). This seems to create an infinite
+recursion for std::cerr << std::flush;
+
+       
        
+       
        
+           
        #include <iostream>
+
+int main ()
+{
+   std::cout.tie (&std::cerr);
+   std::cerr.tie (&std::cout);
+   std::cout << "cout\n";
+   std::cerr << "cerr\n";
+} 
+           
        
+       
        
+   
+   
        Proposed resolution:
        
+       
        
+
+I think an easy way to plug the first hole is to add a requires clause
+to ostream::tie(ostream *tiestr) requiring the this
+pointer not be equal to any pointer on the list starting
+with tiestr->tie()
+through tiestr()->tie()->tie() and so on. I am not
+proposing that we require implementations to traverse this list,
+although I think we could since the list is unlikely to be very long.
+
+       
        
+       
        
+
+Add a Requires clause to 27.4.4.2 [basic.ios.members] withethe following
+text:
+
+       
        
+       
        
+
+Requires: If (tiestr != 0) is
+true, tiestr must not be reachable by traversing the
+linked list of tied stream objects starting
+from tiestr->tie().
+
+       
        
+       
        
+
+In addition, to prevent the infinite recursion that Bo writes about in
+his comp.lang.c++.moderated post, I propose to change
+27.6.2.4 [ostream::sentry], p2 like so:
+
+       
        
+       
        
+
+If ((os.flags() & ios_base::unitbuf) &&
+!uncaught_exception()) is true,
+calls os.flush() os.rdbuf()->pubsync().
+
+       
        
+   
+
+
+
+
        
+
        836. 
+       effects of money_base::space and
+       money_base::none on money_get
+   
        
+
        Section: 22.2.6.1.2 [locale.money.get.virtuals] Status: New
+ Submitter: Martin Sebor Date: 2008-05-17
        
+
        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:
        
+       
        
+
+In paragraph 2, 22.2.6.1.2 [locale.money.get.virtuals] specifies the following:
+
+       
        
+       
        
+
+Where space or none appears in the format
+pattern, except at the end, optional white space (as recognized
+by ct.is) is consumed after any required space.
+
+       
        
+       
        
+
+This requirement can be (and has been) interpreted two mutually
+exclusive ways by different readers. One possible interpretation
+is that:
+
+       
        
+       
        
+           
          
+               
        1. 
+
+where money_base::space appears in the format, at least
+one space is required, and
+
+               
          2. 
+               
        2. 
+
+where money_base::none appears in the format, space is
+allowed but not required.
+
+               
          3. 
+           
        
+       
        
+       
        
+
+The other is that:
+
+       
        
+       
        
+
+where either money_base::space or money_base::none appears in the format, white space is optional.
+
+       
        
+   
+
+   
        Proposed resolution:
        
+       
        
+
+I propose to change the text to make it clear that the first
+interpretation is intended, that is, to make following change to
+22.2.6.1.2 [locale.money.get.virtuals], p2:
+
+       
        
+
+       
        
+
+When money_base::space
+or money_base::none appears as the last
+element in the format pattern, except at the end, optional
+white space (as recognized by ct.is) is consumed after
+any required space. no white space is consumed. Otherwise,
+where money_base::space appears in any of the initial
+elements of the format pattern, at least one white space character is
+required. Where money_base::none appears in any of the
+initial elements of the format pattern, white space is allowed but not
+required. In either case, any required followed by all optional white
+space (as recognized by ct.is()) is consumed.
+If (str.flags() & str.showbase) is false, ...
+
+       
        
+   
+
+
+
+
        
+
        837. 
+   basic_ios::copyfmt() overly loosely specified
+ 
        
+
        Section: 27.4.4.2 [basic.ios.members] Status: New
+ Submitter: Martin Sebor Date: 2008-05-17
        
+
        View other active issues in [basic.ios.members].
        
+
        View all other issues in [basic.ios.members].
        
+
        View all issues with New status.
        
+
        Discussion:
        
+   
        
+
+The basic_ios::copyfmt() member function is specified in 27.4.4.2 [basic.ios.members] to have the following effects:
+
+   
        
+   
        
+
+Effects: If (this == &rhs) does
+nothing. Otherwise assigns to the member objects of *this
+the corresponding member objects of rhs, except that
+
+     
          
+       
        • 
+
+rdstate() and rdbuf() are left unchanged;
+
+       
          • 
+       
        • 
+
+exceptions() is altered last by
+calling exceptions(rhs.except)
+
+       
          • 
+       
        • 
+
+the contents of arrays pointed at by pword
+and iword are copied not the pointers themselves
+
+       
          • 
+     
        
+   
        
+   
        
+
+Since the rest of the text doesn't specify what the member objects
+of basic_ios are this seems a little too loose.
+
+   
        
+ 
+
+ 
        Proposed resolution:
        
+   
        
+
+I propose to tighten things up by adding a Postcondition clause
+to the function like so:
+
+   
        
+   
        
+     Postconditions:
+
+     
+       
+         
+           
+         
+         
+           
+           
+         
+       
+       
+         
+           
+           
+         
+          
+           
+           
+         
+          
+           
+           
+         
+          
+           
+           
+         
+          
+           
+           
+         
+          
+           
+           
+         
+          
+           
+           
+         
+          
+           
+           
+         
+          
+           
+           
+         
+       
+     
        copyfmt() postconditions
        ElementValue
        rdbuf()unchanged
        tie()rhs.tie()
        rdstate()unchanged
        exceptions()rhs.exceptions()
        flags()rhs.flags()
        width()rhs.width()
        precision()rhs.precision()
        fill()rhs.fill()
        getloc()rhs.getloc()
        
+   
        
+   
        
+
+The format of the table follows Table 117 (as
+of N2588): basic_ios::init()
+effects.
+
+   
        
+   
        
+
+The intent of the new table is not to impose any new requirements or
+change existing ones, just to be more explicit about what I believe is
+already there.
+
+   
        
+ 
+
+
+
+
        
+
        838. 
+   can an end-of-stream iterator become a non-end-of-stream one?
+ 
        
+
        Section: 24.5.1 [istream.iterator] Status: New
+ Submitter: Martin Sebor Date: 2008-05-17
        
+
        View other active issues in [istream.iterator].
        
+
        View all other issues in [istream.iterator].
        
+
        View all issues with New status.
        
+
        Discussion:
        
+   
        
+
+From message c++std-lib-20003...
+
+   
        
+   
        
+
+The description of istream_iterator in
+24.5.1 [istream.iterator], p1 specifies that objects of the
+class become the end-of-stream (EOS) iterators under the
+following condition (see also issue 836 another problem
+with this paragraph):
+
+   
        
+   
        
+
+If the end of stream is reached (operator void*() on the
+stream returns false), the iterator becomes equal to
+the end-of-stream iterator value.
+
+   
        
+   
        
+
+One possible implementation approach that has been used in practice is
+for the iterator to set its in_stream pointer to 0 when
+it reaches the end of the stream, just like the default ctor does on
+initialization. The problem with this approach is that
+the Effects clause for operator++() says the
+iterator unconditionally extracts the next value from the stream by
+evaluating *in_stream >> value, without checking
+for (in_stream == 0).
+
+   
        
+   
        
+
+Conformance to the requirement outlined in the Effects clause
+can easily be verified in programs by setting eofbit
+or failbit in exceptions() of the associated
+stream and attempting to iterate past the end of the stream: each
+past-the-end access should trigger an exception. This suggests that
+some other, more elaborate technique might be intended.
+
+   
        
+   
        
+
+Another approach, one that allows operator++() to attempt
+to extract the value even for EOS iterators (just as long
+as in_stream is non-0) is for the iterator to maintain a
+flag indicating whether it has reached the end of the stream. This
+technique would satisfy the presumed requirement implied by
+the Effects clause mentioned above, but it isn't supported by
+the exposition-only members of the class (no such flag is shown). This
+approach is also found in existing practice.
+
+   
        
+   
        
+
+The inconsistency between existing implementations raises the question
+of whether the intent of the specification is that a non-EOS iterator
+that has reached the EOS become a non-EOS one again after the
+stream's eofbit flag has been cleared? That is, are the
+assertions in the program below expected to pass?
+
+   
        
+   
        
+     
           sstream strm ("1 ");
+   istream_iterator eos;
+   istream_iterator it (strm);
+   int i;
+   i = *it++
+   assert (it == eos);
+   strm.clear ();
+   strm << "2 3 ";
+   assert (it != eos);
+   i = *++it;
+   assert (3 == i);
+     
        
+   
        
+   
        
+
+Or is it intended that once an iterator becomes EOS it stays EOS until
+the end of its lifetime?
+
+   
        
+ 
+
+ 
        Proposed resolution:
        
+   
        
+
+The discussion of this issue on the reflector suggests that the intent
+of the standard is for an istreambuf_iterator that has
+reached the EOS to remain in the EOS state until the end of its
+lifetime. Implementations that permit EOS iterators to return to a
+non-EOS state may only do so as an extension, and only as a result of
+calling istream_iterator member functions on EOS
+iterators whose behavior is in this case undefined.
+
+   
        
+   
        
+
+To this end we propose to change 24.5.1 [istream.iterator], p1,
+as follows:
+
+   
        
+   
        
+
+The result of operator-> on an end-of-stream
+is not defined. For any other iterator value a const T*
+is returned. Invoking operator++() on
+an end-of-stream iterator is undefined. It is impossible
+to store things into istream iterators...
+
+   
        
+   
        
+
+Add pre/postconditions to the member function descriptions of istream_iterator like so:
+
+   
        
+   
        
+
+
        istream_iterator();
        
+
+Effects: Constructs the end-of-stream iterator.
        
+Postcondition: in_stream == 0.
+
+
        istream_iterator(istream_type &s);
        
+
+Effects: Initializes in_stream with &s. value
+may be initialized during construction or the first time it is
+referenced.
        
+Postcondition: in_stream == &s.
+
+
        istream_iterator(const istream_iterator &x);
        
+
+Effects: Constructs a copy of x.
        
+Postcondition: in_stream == x.in_stream.
+
+
        istream_iterator& operator++();
        
+
+Requires: in_stream != 0.
        
+Effects: *in_stream >> value.
+
+
        istream_iterator& operator++(int);
        
+
+Requires: in_stream != 0.
        
+Effects:
+   
        istream_iterator tmp (*this);
+*in_stream >> value;
+return tmp;
+     
        
+     
        
+   
        
+ 
+
+
+
+
 
\ No newline at end of file
diff --git a/libstdc++-v3/doc/html/ext/lwg-closed.html b/libstdc++-v3/doc/html/ext/lwg-closed.html
index 52184fb805e..68bca503aa2 100644
--- a/libstdc++-v3/doc/html/ext/lwg-closed.html
+++ b/libstdc++-v3/doc/html/ext/lwg-closed.html
@@ -12,11 +12,11 @@ del {background-color:#FFA0A0}
 
-
+
-
+
@@ -27,7 +27,7 @@ del {background-color:#FFA0A0}
 
        
 
        
 Doc. no.N2458=07-0328N2614=08-0124
 
        
 
        
 Date:2007-10-202008-05-18
 
        
 
        
 Project:Howard Hinnant <howard.hinnant@gmail.com>
 
        
 
        
-
        C++ Standard Library Closed Issues List (Revision R52)
        
+
        C++ Standard Library Closed Issues List (Revision R56)
        
 
   
        Reference ISO/IEC IS 14882:1998(E)
        
   
        Also see:
        
@@ -49,6 +49,89 @@ del {background-color:#FFA0A0}
 
 
        Revision History
        
 
 
@@ -96,13 +179,13 @@ del {background-color:#FFA0A0}
 
      1. 708 issues total, up by 12.
        2. 
 
 
      2. Details:
          
-
        • Added the following New issues: 697, 698, 699, 700, 701, 702, 703, 704, 705, 706, 707, 708.
          • 
+
        • Added the following New issues: 697, 698, 699, 700, 701, 702, 703, 704, 705, 706, 707, 708.
          • 
 
        • Changed the following issues from New to NAD: 583, 584, 662.
          • 
 
        • Changed the following issues from Open to NAD: 528.
          • 
 
        • Changed the following issues from New to NAD Editorial: 637, 647, 658, 690.
          • 
 
        • Changed the following issues from Open to NAD Editorial: 525.
          • 
 
        • Changed the following issues from Pending NAD Editorial to NAD Editorial: 553, 571, 591, 633, 636, 641, 642, 648, 649, 656.
          • 
-
        • Changed the following issues from New to Open: 579, 631, 680.
          • 
+
        • Changed the following issues from New to Open: 579, 631, 680.
          • 
 
        • Changed the following issues from Pending WP to Open: 258.
          • 
 
        • Changed the following issues from Ready to Pending WP: 644.
          • 
 
        • Changed the following issues from New to Ready: 577, 660.
          • 
@@ -123,7 +206,7 @@ del {background-color:#FFA0A0}
 
        • 696 issues total, up by 20.
          • 
 
        3. 
 
      3. Details:
        4. 
 
      4. Details:
        5. 
 
      5. Details:
        6. 
 
@@ -201,7 +284,7 @@ del {background-color:#FFA0A0}
 
      6. Moved issues 520, 521, 530, 535, 537, 538, 540, 541 to WP.
        7. 
 
      7. Moved issues 504, 512, 516, 544, 549, 554, 555, 558 to NAD.
        8. 
 
      8. Moved issue 569 to Dup.
        9. 
-
      9. Moved issues 518, 523, 524, 542, 556, 557, 559, 597, 606 to Open.
        10. 
+
      10. Moved issues 518, 523, 524, 542, 556, 557, 559, 597, 606 to Open.
        11. 
 
      11. Moved issues 543, 545, 549, 549, 598 - 603, 605 to Ready.
        12. 
 
      12. Moved issues 531, 551, 604 to Review.
        13. 
 
      13. Added new issues 593-609.
        14. 
@@ -245,9 +328,9 @@ del {background-color:#FFA0A0}
 
      14. 574 issues total, up by 8.
        15. 
 
 
      15. Details:
        16. 
 
      16. Details:
        17. 
 
 
@@ -323,12 +406,12 @@ new issues 463-478.
+new issues 463-478.
 
 
      17. R30: 
 Post-Sydney mailing: reflects decisions made at the Sydney meeting.
 Voted all "Ready" issues from R29 into the working paper.
-Added new issues 460-462.
+Added new issues 460-462.
 
        18. 
 
      18. R29: 
 Pre-Sydney mailing.  Added new issues 441-457.
@@ -473,7 +556,7 @@ of issue 83,
 86, 91, 92,
-109. Added issues 190 to
+109. Added issues 190 to
 195. (99-0033/D1209, 14 Oct 99)
 
        19. 
 
      19. R9: 
@@ -492,7 +575,7 @@ pre-Dublin updated: Added issues 138, 139 (31 Mar 99)
 
        20. 
 
      20. R6: 
-pre-Dublin mailing. Added issues 127, 128,
+pre-Dublin mailing. Added issues 127, 128,
 and 129.  (99-0007/N1194, 22 Feb 99)
 
        21. 
 
      21. R5: 
@@ -1214,6 +1297,7 @@ illegal.  See 17.4.4.4 [member.functions] paragraph 2.
        
 
        97. Insert inconsistent definition
        
 
        Section: 23 [containers] Status: NAD
  Submitter: AFNOR Date: 1998-10-07
        
+
        View other active issues in [containers].
        
 
        View all other issues in [containers].
        
 
        View all issues with NAD status.
        
 
        Discussion:
        
@@ -1275,7 +1359,7 @@ incorrect code to work, rather than the other way around.
        
 
 
        
 
        101. No way to free storage for vector and deque
        
-
        Section: 23.2.5 [vector], 23.2.1 [array] Status: NAD
+
        Section: 23.2.6 [vector], 23.2.1 [array] Status: NAD
  Submitter: AFNOR Date: 1998-10-07
        
 
        View all other issues in [vector].
        
 
        View all issues with NAD status.
        
@@ -1348,10 +1432,13 @@ the Standard.
        
 
 
        
 
        105. fstream ctors argument types desired
        
-
        Section: 27.8 [file.streams] Status: NAD Future
+
        Section: 27.8 [file.streams] Status: Dup
  Submitter: AFNOR Date: 1998-10-07
        
-
        View all issues with NAD Future status.
        
+
        View all issues with Dup status.
        
+
        Duplicate of: 454
        
 
        Discussion:
        
+
+
 
        fstream ctors take a const char* instead of string.
        
 fstream ctors can't take wchar_t
        
 
@@ -1488,12 +1575,15 @@ desired functionality.
        
 
 
        
 
        116. bitset cannot be constructed with a const char*
        
-
        Section: 23.3.5 [template.bitset] Status: NAD Future
+
        Section: 23.3.5 [template.bitset] Status: Dup
  Submitter: Judy Ward Date: 1998-11-06
        
-
        View other active issues in [template.bitset].
        
 
        View all other issues in [template.bitset].
        
-
        View all issues with NAD Future status.
        
+
        View all issues with Dup status.
        
+
        Duplicate of: 778
        
 
        Discussion:
        
+
+
+
 
        The following code does not compile with the EDG compiler:
        
 
 
        
@@ -1590,61 +1680,9 @@ ctype<wchar_t> specialization. 
        
 
 
 
-
        
-
        128. Need open_mode() function for file stream, string streams, file buffers, and string  buffers
        
-
        Section: 27.7 [string.streams], 27.8 [file.streams] Status: NAD Future
- Submitter: Angelika Langer Date: 1999-02-22
        
-
        View all other issues in [string.streams].
        
-
        View all issues with NAD Future status.
        
-
        Discussion:
        
-
        The following question came from Thorsten Herlemann:
        
-
-
        
-  
        You can set a mode when constructing or opening a file-stream or
-  filebuf, e.g.  ios::in, ios::out, ios::binary, ... But how can I get
-  that mode later on, e.g. in my own operator << or operator
-  >> or when I want to check whether a file-stream or
-  file-buffer object passed as parameter is opened for input or output
-  or binary? Is there no possibility? Is this a design-error in the
-  standard C++ library? 
        
-
        
-
-
        It is indeed impossible to find out what a stream's or stream
-buffer's open mode is, and without that knowledge you don't know
-how certain operations behave. Just think of the append mode. 
        
-
-
        Both streams and stream buffers should have a mode() function that returns the
-current open mode setting. 
        
-
-
-
        Proposed resolution:
        
-
        For stream buffers, add a function to the base class as a non-virtual function
-qualified as const to 27.5.2 [streambuf]:
        
-
-
            openmode mode() const;
        
-
-
            Returns the current open mode.
        
-
-
        With streams, I'm not sure what to suggest. In principle, the mode
-could already be returned by ios_base, but the mode is only
-initialized for file and string stream objects, unless I'm overlooking
-anything. For this reason it should be added to the most derived
-stream classes. Alternatively, it could be added to basic_ios
-and would be default initialized in basic_ios<>::init().
        
-
-
-
        Rationale:
        
-
        This might be an interesting extension for some future, but it is
-not a defect in the current standard. The Proposed Resolution is
-retained for future reference.
        
-
-
-
-
-
 
        
 
        131. list::splice throws nothing
        
-
        Section: 23.2.3.4 [list.ops] Status: NAD
+
        Section: 23.2.4.4 [list.ops] Status: NAD
  Submitter: Howard Hinnant Date: 1999-03-06
        
 
        View all other issues in [list.ops].
        
 
        View all issues with NAD status.
        
@@ -1731,10 +1769,10 @@ not in the specialization. See issue 140. map<Key, T>::value_type does not satisfy the assignable requirement
-
        Section: 23.3.1 [map] Status: NAD Future
+
        Section: 23.3.1 [map] Status: NAD Editorial
  Submitter: Mark Mitchell Date: 1999-04-14
        
 
        View all other issues in [map].
        
-
        View all issues with NAD Future status.
        
+
        View all issues with NAD Editorial status.
        
 
        Discussion:
        
 
        
   
        23.1 [container.requirements]
        
@@ -2191,65 +2229,11 @@ ios_base::init to basic_ios::init().)
        
 
 
 
-
        
-
        180. Container member iterator arguments constness has unintended consequences
        
-
        Section: 23 [containers] Status: NAD Future
- Submitter: Dave Abrahams Date: 1999-07-01
        
-
        View all other issues in [containers].
        
-
        View all issues with NAD Future status.
        
-
        Discussion:
        
-
        It is the constness of the container which should control whether
-it can be modified through a member function such as erase(), not the
-constness of the iterators. The iterators only serve to give
-positioning information.
        
-
-
        Here's a simple and typical example problem which is currently very
-difficult or impossible to solve without the change proposed
-below.
        
-
-
        Wrap a standard container C in a class W which allows clients to
-find and read (but not modify) a subrange of (C.begin(), C.end()]. The
-only modification clients are allowed to make to elements in this
-subrange is to erase them from C through the use of a member function
-of W.
        
-
-
-
        Proposed resolution:
        
-
        Change all non-const iterator parameters of standard library
-container member functions to accept const_iterator parameters.
-Note that this change applies to all library clauses, including
-strings.
        
-
-
        For example, in   21.3.5.5  change:
        
-
        
-       iterator erase(iterator p);
        
-
        
-to:
        
-       iterator erase(const_iterator p);
-
        
-
-
-
        Rationale:
        
-
        The issue was discussed at length. It was generally agreed that 1)
-There is no major technical argument against the change (although
-there is a minor argument that some obscure programs may break), and
-2) Such a change would not break const correctness. The concerns about
-making the change were 1) it is user detectable (although only in
-boundary cases), 2) it changes a large number of signatures, and 3) it
-seems more of a design issue that an out-and-out defect.
        
-
-
        The LWG believes that this issue should be considered as part of a
-general review of const issues for the next revision of the
-standard. Also see issue 200.
        
-
-
-
-
 
        
 
        188. valarray helpers missing augmented assignment operators
        
-
        Section: 26.5.2.6 [valarray.cassign] Status: NAD Future
+
        Section: 26.5.2.6 [valarray.cassign] Status: NAD
  Submitter: Gabriel Dos Reis Date: 1999-08-15
        
-
        View all issues with NAD Future status.
        
+
        View all issues with NAD status.
        
 
        Discussion:
        
 
        26.5.2.6 defines augmented assignment operators
 valarray<T>::op=(const T&), but fails to provide
@@ -2282,30 +2266,6 @@ operators.
        
 
 
 
-
        
-
        190. min() and max() functions should be std::binary_functions
        
-
        Section: 25.3.7 [alg.min.max] Status: NAD Future
- Submitter: Mark Rintoul Date: 1999-08-26
        
-
        View all other issues in [alg.min.max].
        
-
        View all issues with NAD Future status.
        
-
        Discussion:
        
-
        Both std::min and std::max are defined as template functions.  This
-is very different than the definition of std::plus (and similar
-structs) which are defined as function objects which inherit
-std::binary_function.
        
-
        
-        This lack of inheritance leaves std::min and std::max somewhat useless in standard library algorithms which require
-a function object that inherits std::binary_function.
        
-
-
-
        Rationale:
        
-
        Although perhaps an unfortunate design decision, the omission is not a defect
-in the current standard.  A future standard may wish to consider additional
-function objects.
        
-
-
-
-
 
        
 
        191. Unclear complexity for algorithms such as binary search
        
 
        Section: 25.3.3 [alg.binary.search] Status: NAD
@@ -3011,6 +2971,8 @@ might reasonably pass an argument that is not Copy Constructible.
        
 
        245. Which operations on istream_iterator trigger input operations?
        
 
        Section: 24.5.1 [istream.iterator] Status: NAD
  Submitter: Andrew Koenig Date: 2000-05-02
        
+
        View other active issues in [istream.iterator].
        
+
        View all other issues in [istream.iterator].
        
 
        View all issues with NAD status.
        
 
        Discussion:
        
 
        I do not think the standard specifies what operation(s) on istream
@@ -3977,11 +3939,11 @@ about when terminate() is called; it merely specifies which
 
 
        
 
        323. abs() overloads in different headers
        
-
        Section: 26.7 [c.math] Status: NAD Future
+
        Section: 26.7 [c.math] Status: NAD
  Submitter: Dave Abrahams Date: 2001-06-04
        
 
        View other active issues in [c.math].
        
 
        View all other issues in [c.math].
        
-
        View all issues with NAD Future status.
        
+
        View all issues with NAD status.
        
 
        Discussion:
        
 
        Currently the standard mandates the following overloads of
 abs():
        
@@ -4019,6 +3981,16 @@ and int_max_abs.
        
 
 
        Related issue: 343.
        
 
+
        [
+Bellevue:
+]
        
+
+
+
        
+The situation is not sufficiently severe to warrant a change.
+
        
+
+
 
 
 
        Rationale:
        
@@ -4208,11 +4180,14 @@ consensus in the LWG for action.
 
 
        
 
        348. Minor issue with std::pair operator<
        
-
        Section: 20.2.3 [pairs] Status: NAD Future
+
        Section: 20.2.3 [pairs] Status: Dup
  Submitter: Andy Sawyer Date: 2001-10-23
        
 
        View all other issues in [pairs].
        
-
        View all issues with NAD Future status.
        
+
        View all issues with Dup status.
        
+
        Duplicate of: 532
        
 
        Discussion:
        
+
+
 
        
 The current wording of 20.2.2 [lib.pairs] p6 precludes the use of
 operator< on any pair type which contains a pointer.
@@ -4253,7 +4228,7 @@ 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: Dup
+
        Section: 20.6.5.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 Dup status.
        
@@ -4371,10 +4346,10 @@ might wish to make the change as editorial.]
        
 
 
        
 
        353. std::pair missing template assignment
        
-
        Section: 20.2.3 [pairs] Status: NAD Future
+
        Section: 20.2.3 [pairs] Status: NAD Editorial
  Submitter: Martin Sebor Date: 2001-12-02
        
 
        View all other issues in [pairs].
        
-
        View all issues with NAD Future status.
        
+
        View all issues with NAD Editorial status.
        
 
        Discussion:
        
 
        
 The class template std::pair defines a template ctor (20.2.2, p4) but
@@ -4413,6 +4388,13 @@ a design decision, and thus NAD.  May be appropriate for a future
 standard.]
        
 
 
+
        [
+Pre Bellevue:  It was recognized that this was taken care of by
+N1856,
+and thus moved from NAD Future to NAD Editorial.
+]
        
+
+
 
 
 
@@ -5109,10 +5091,10 @@ 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
+
        Section: 26.3 [complex.numbers] Status: NAD
  Submitter: Gabriel Dos Reis Date: 2002-11-08
        
 
        View all other issues in [complex.numbers].
        
-
        View all issues with NAD Future status.
        
+
        View all issues with NAD status.
        
 
        Discussion:
        
 
        
 Practice with std::complex<> and the associative containers
@@ -5138,6 +5120,27 @@ containers as an ordering useful to meet complexity requirements.
 
 
        Related issue: 348.
        
 
+
        [
+Pre Bellevue: Reopened at the request of Alisdair.
+]
        
+
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+This is a request for a design change, and not a defect in the standard.
+It is in scope to consider, but the group feels that it is not a change
+that we need to do. Is there a total ordering for floating point values,
+including NaN? There is not a clear enough solution or big enough
+problem for us to solve. Solving this problem would require solving the
+problem for floating point, which is equally unclear. The LWG noted that
+users who want to put objects into an associative container for which
+operator< isn't defined can simply provide their own comparison function
+object. NAD
+
        
 
 
 
        Proposed resolution:
        
@@ -5160,11 +5163,11 @@ provide their own comparison function object.
        
 
 
        
 
        390. CopyConstructible requirements too strict
        
-
        Section: 20.1.1 [utility.arg.requirements] Status: NAD Future
+
        Section: 20.1.1 [utility.arg.requirements] Status: NAD Editorial
  Submitter: Doug Gregor Date: 2002-10-24
        
 
        View other active issues in [utility.arg.requirements].
        
 
        View all other issues in [utility.arg.requirements].
        
-
        View all issues with NAD Future status.
        
+
        View all issues with NAD Editorial status.
        
 
        Discussion:
        
 
        
 The CopyConstructible requirements in Table 30 state that for an
@@ -5295,7 +5298,6 @@ 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:
        
@@ -5401,6 +5403,95 @@ can use alternative signatures that don't call widen.
 
 
 
+
        
+
        424. normative notes
        
+
        Section: 17.3.1.1 [structure.summary] Status: Pending NAD Editorial
+ Submitter: Martin Sebor Date: 2003-09-18
        
+
        View all issues with Pending NAD Editorial status.
        
+
        Discussion:
        
+
+
        
+The text in 17.3.1.1, p1 says:
+
        
+
+"Paragraphs labelled "Note(s):" or "Example(s):" are informative, other
+paragraphs are normative."
+
        
+
+The library section makes heavy use of paragraphs labeled "Notes(s),"
+some of which are clearly intended to be normative (see list 1), while
+some others are not (see list 2). There are also those where the intent
+is not so clear (see list 3).
+

        
+
+List 1 -- Examples of (presumably) normative Notes:
+
        
+
+20.6.5.1 [allocator.members], p3,
        
+20.6.5.1 [allocator.members], p10,
        
+21.3.2 [string.cons], p11,
        
+22.1.1.2 [locale.cons], p11,
        
+23.2.2.3 [deque.modifiers], p2,
        
+25.3.7 [alg.min.max], p3,
        
+26.3.6 [complex.ops], p15,
        
+27.5.2.4.3 [streambuf.virt.get], p7.
        
+
        
+
+List 2 -- Examples of (presumably) informative Notes:
+
        
+
+18.5.1.3 [new.delete.placement], p3,
        
+21.3.6.6 [string::replace], p14,
        
+22.2.1.4.2 [locale.codecvt.virtuals], p3,
        
+25.1.1 [alg.foreach], p4,
        
+26.3.5 [complex.member.ops], p1,
        
+27.4.2.5 [ios.base.storage], p6.
        
+
        
+
+List 3 -- Examples of Notes that are not clearly either normative
+or informative:
+
        
+
+22.1.1.2 [locale.cons], p8,
        
+22.1.1.5 [locale.statics], p6,
        
+27.5.2.4.5 [streambuf.virt.put], p4.
        
+
        
+
+None of these lists is meant to be exhaustive.
+
        
+
+
        [Definitely a real problem.  The big problem is there's material
+  that doesn't quite fit any of the named paragraph categories
+  (e.g. Effects).  Either we need a new kind of named
+  paragraph, or we need to put more material in unnamed paragraphs
+  jsut after the signature.  We need to talk to the Project Editor
+  about how to do this.
+]
        
+
+
+
        [
+Bellevue: Specifics of list 3: First 2 items correct in std (22.1.1.2,
+22.1.1.5) Third item should be non-normative (27.5.2.4.5), which Pete
+will handle editorially.
+]
        
+
+
+
+
        Proposed resolution:
        
+
        [Pete: I changed the paragraphs marked "Note" and "Notes" to use "Remark" and "Remarks".
+Fixed as editorial.  This change has been in the WD since the post-Redmond mailing, in 2004.
+Recommend NAD.]
        
+
+
        [
+Batavia:  We feel that the references in List 2 above should be changed from Remarks
+to Notes.  We also feel that those items in List 3 need to be double checked for
+the same change.  Alan and Pete to review.
+]
        
+
+
+
+
+
 
        
 
        429. typo in basic_ios::clear(iostate)
        
 
        Section: 27.4.4.3 [iostate.flags] Status: Dup
@@ -5770,274 +5861,153 @@ standard facets.
 
 
 
        
-
        463. auto_ptr usability issues
        
-
        Section: D.9.1 [auto.ptr] Status: NAD
- Submitter: Rani Sharoni Date: 2003-12-07
        
-
        View all other issues in [auto.ptr].
        
+
        462. Destroying objects with static storage duration
        
+
        Section: 3.6.3 [basic.start.term], 18.3 [cstdint] Status: NAD
+ Submitter: Bill Plauger Date: 2004-03-23
        
 
        View all issues with NAD status.
        
 
        Discussion:
        
-
 
        
-TC1 CWG DR #84 effectively made the template<class Y> operator auto_ptr<Y>()
-member of auto_ptr (20.4.5.3/4) obsolete.
+3.6.3 Termination spells out in detail the interleaving of static
+destructor calls and calls to functions registered with atexit. To
+match this behavior requires intimate cooperation between the code
+that calls destructors and the exit/atexit machinery. The former
+is tied tightly to the compiler; the latter is a primitive mechanism
+inherited from C that traditionally has nothing to do with static
+construction and destruction. The benefits of intermixing destructor
+calls with atexit handler calls is questionable at best, and very
+difficult to get right, particularly when mixing third-party C++
+libraries with different third-party C++ compilers and C libraries
+supplied by still other parties.
 
        
 
 
        
-The sole purpose of this obsolete conversion member is to enable copy
-initialization base from r-value derived (or any convertible types like
-cv-types) case:
-
        
-
        #include <memory>
-using std::auto_ptr;
-
-struct B {};
-struct D : B {};
-
-auto_ptr<D> source();
-int sink(auto_ptr<B>);
-int x1 = sink( source() ); // #1 EDG - no suitable copy constructor
-
        
-
-
        
-The excellent analysis of conversion operations that was given in the final
-auto_ptr proposal
-(http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf)
-explicitly specifies this case analysis (case 4). DR #84 makes the analysis
-wrong and actually comes to forbid the loophole that was exploited by the
-auto_ptr designers.
+I believe the right thing to do is defer all static destruction
+until after all atexit handlers are called. This is a change in
+behavior, but one that is likely visible only to perverse test
+suites. At the very least, we should permit deferred destruction
+even if we don't require it.
 
        
 
-
        
-I didn't encounter any compliant compiler (e.g. EDG, GCC, BCC and VC) that
-ever allowed this case. This is probably because it requires 3 user defined
-conversions and in fact current compilers conform to DR #84.
-
        
+
        [If this is to be changed, it should probably be changed by CWG.
+  At this point, however, the LWG is leaning toward NAD.  Implementing
+  what the standard says is hard work, but it's not impossible and
+  most vendors went through that pain years ago.  Changing this
+  behavior would be a user-visible change, and would break at least
+  one real application.]
        
 
-
        
-I was surprised to discover that the obsolete conversion member actually has
-negative impact of the copy initialization base from l-value derived
-case:
        
-
        auto_ptr<D> dp;
-int x2 = sink(dp); // #2 EDG - more than one user-defined conversion applies
-
        
 
-
        
-I'm sure that the original intention was allowing this initialization using
-the template<class Y> auto_ptr(auto_ptr<Y>& a) constructor (20.4.5.1/4) but
-since in this copy initialization it's merely user defined conversion (UDC)
-and the obsolete conversion member is UDC with the same rank (for the early
-overloading stage) there is an ambiguity between them.
-
        
+
        [
+Batavia:  Send to core with our recommendation that we should permit deferred
+destruction but not require it.
+]
        
 
-
        
-Removing the obsolete member will have impact on code that explicitly
-invokes it:
-
        
-
        int y = sink(source().operator auto_ptr<B>());
-
        
 
-
        
-IMHO no one ever wrote such awkward code and the reasonable workaround for
-#1 is:
-
        
-
        int y = sink( auto_ptr<B>(source()) );
-
        
+
        [
+Howard:  The course of action recommended in Batavia would undo LWG
+issue 3 and break current code implementing the "phoenix
+singleton". Search the net for "phoenix singleton atexit" to get a feel
+for the size of the adverse impact this change would have.  Below is
+sample code which implements the phoenix singleton and would break if
+atexit is changed in this way:
+]
        
 
-
        
-I was even more surprised to find out that after removing the obsolete
-conversion member the initialization was still ill-formed:
-int x3 = sink(dp); // #3 EDG - no suitable copy constructor
-
        
 
-
        
-This copy initialization semantically requires copy constructor which means
-that both template conversion constructor and the auto_ptr_ref conversion
-member (20.4.5.3/3) are required which is what was explicitly forbidden in
-DR #84. This is a bit amusing case in which removing ambiguity results with
-no candidates.
-
        
+
        #include <cstdlib>
+#include <iostream>
+#include <type_traits>
+#include <new>
 
-
        
-I also found exception safety issue with auto_ptr related to auto_ptr_ref:
-
        
-
        int f(auto_ptr<B>, std::string);
-auto_ptr<B> source2();
-
-// string constructor throws while auto_ptr_ref
-// "holds" the pointer
-int x4 = f(source2(), "xyz"); // #4
-
        
-
-
        
-The theoretic execution sequence that will cause a leak:
-
        
-
          
-
        1. call auto_ptr<B>::operator auto_ptr_ref<B>()
          2. 
-
        2. call string::string(char const*) and throw
          3. 
-
        
-
-
        
-According to 20.4.5.3/3 and 20.4.5/2 the auto_ptr_ref conversion member
-returns auto_ptr_ref<Y> that holds *this and this is another defect since
-the type of *this is auto_ptr<X> where X might be different from Y. Several
-library vendors (e.g. SGI) implement auto_ptr_ref<Y> with Y* as member which
-is much more reasonable. Other vendor implemented auto_ptr_ref as
-defectively required and it results with awkward and catastrophic code:
-int oops = sink(auto_ptr<B>(source())); // warning recursive on all control
-paths
-
        
-
-
        
-Dave Abrahams noticed that there is no specification saying that
-auto_ptr_ref copy constructor can't throw.
-
        
-
-
        
-My proposal comes to solve all the above issues and significantly simplify
-auto_ptr implementation. One of the fundamental requirements from auto_ptr
-is that it can be constructed in an intuitive manner (i.e. like ordinary
-pointers) but with strict ownership semantics which yield that source
-auto_ptr in initialization must be non-const. My idea is to add additional
-constructor template with sole propose to generate ill-formed, diagnostic
-required, instance for const auto_ptr arguments during instantiation of
-declaration. This special constructor will not be instantiated for other
-types which is achievable using 14.8.2/2 (SFINAE). Having this constructor
-in hand makes the constructor template<class Y> auto_ptr(auto_ptr<Y> const&)
-legitimate since the actual argument can't be const yet non const r-value
-are acceptable.
-
        
-
-
        
-This implementation technique makes the "private auxiliary class"
-auto_ptr_ref obsolete and I found out that modern C++ compilers (e.g. EDG,
-GCC and VC) consume the new implementation as expected and allow all
-intuitive initialization and assignment cases while rejecting illegal cases
-that involve const auto_ptr arguments.
-
        
-
-
        The proposed auto_ptr interface:
        
-
-
        namespace std {
-    template<class X> class auto_ptr {
-    public:
-        typedef X element_type;
-
-        // 20.4.5.1 construct/copy/destroy:
-        explicit auto_ptr(X* p=0) throw();
-        auto_ptr(auto_ptr&) throw();
-        template<class Y> auto_ptr(auto_ptr<Y> const&) throw();
-        auto_ptr& operator=(auto_ptr&) throw();
-        template<class Y> auto_ptr& operator=(auto_ptr<Y>) throw();
-        ~auto_ptr() throw();
-
-        // 20.4.5.2 members:
-        X& operator*() const throw();
-        X* operator->() const throw();
-        X* get() const throw();
-        X* release() throw();
-        void reset(X* p=0) throw();
-
-    private:
-        template<class U>
-        auto_ptr(U& rhs, typename
-unspecified_error_on_const_auto_ptr<U>::type = 0);
-    };
-}
-
        
-
-
        
-One compliant technique to implement the unspecified_error_on_const_auto_ptr
-helper class is using additional private auto_ptr member class template like
-the following:
-
        
-
        template<typename T> struct unspecified_error_on_const_auto_ptr;
-
-template<typename T>
-struct unspecified_error_on_const_auto_ptr<auto_ptr<T> const>
-{ typedef typename auto_ptr<T>::const_auto_ptr_is_not_allowed type; };
-
        
-
-
        
-There are other techniques to implement this helper class that might work
-better for different compliers (i.e. better diagnostics) and therefore I
-suggest defining its semantic behavior without mandating any specific
-implementation. IMO, and I didn't found any compiler that thinks otherwise,
-14.7.1/5 doesn't theoretically defeat the suggested technique but I suggest
-verifying this with core language experts.
-
        
-
-
        Further changes in standard text:
        
-
        Remove section 20.4.5.3
        
-
-
        Change 20.4.5/2 to read something like:
-Initializing auto_ptr<X> from const auto_ptr<Y> will result with unspecified
-ill-formed declaration that will require unspecified diagnostic.
        
-
-
        Change 20.4.5.1/4,5,6 to read:
        
-
-
        template<class Y> auto_ptr(auto_ptr<Y> const& a) throw();
        
-
         4 Requires: Y* can be implicitly converted to X*.
        
-
         5 Effects: Calls const_cast<auto_ptr<Y>&>(a).release().
        
-
         6 Postconditions: *this holds the pointer returned from a.release().
        
-
-
        Change 20.4.5.1/10
        
-
        template<class Y> auto_ptr& operator=(auto_ptr<Y> a) throw();
-
        
-
        
-10 Requires: Y* can be implicitly converted to X*. The expression delete
-get() is well formed.
-
        
-
-
        LWG TC DR #127 is obsolete.
        
-
-
        
-Notice that the copy constructor and copy assignment operator should remain
-as before and accept non-const auto_ptr& since they have effect on the form
-of the implicitly declared copy constructor and copy assignment operator of
-class that contains auto_ptr as member per 12.8/5,10:
-
        
-
        struct X {
-    // implicit X(X&)
-    // implicit X& operator=(X&)
-    auto_ptr<D> aptr_;
+class A
+{
+    bool alive_;
+    A(const A&);
+    A& operator=(const A&);
+public:
+    A() : alive_(true) {std::cout << "A()\n";}
+    ~A() {alive_ = false; std::cout << "~A()\n";}
+    void use()
+    {
+        if (alive_)
+            std::cout << "A is alive\n";
+        else
+            std::cout << "A is dead\n";
+    }
 };
-
        
+
+void deallocate_resource();
+
+// This is the phoenix singleton pattern
+A& get_resource(bool create = true)
+{
+    static std::aligned_storage<sizeof(A), std::alignment_of<A>::value>::type buf;
+    static A* a;
+    if (create)
+    {
+        if (a != (A*)&buf)
+        {
+            a = ::new (&buf) A;
+            std::atexit(deallocate_resource);
+        }
+    }
+    else
+    {
+        a->~A();
+        a = (A*)&buf + 1;
+    }
+    return *a;
+}
+
+void deallocate_resource()
+{
+    get_resource(false);
+}
+
+void use_A(const char* message)
+{
+    A& a = get_resource();
+    std::cout << "Using A " << message << "\n";
+    a.use();
+}
+
+struct B
+{
+    ~B() {use_A("from ~B()");}
+};
+
+B b;
+
+int main()
+{
+    use_A("from main()");
+}
+
        
 
 
        
-In most cases this indicates about sloppy programming but preserves the
-current auto_ptr behavior.
+The correct output is:
 
        
 
-
        
-Dave Abrahams encouraged me to suggest fallback implementation in case that
-my suggestion that involves removing of auto_ptr_ref will not be accepted.
-In this case removing the obsolete conversion member to auto_ptr<Y> and
-20.4.5.3/4,5 is still required in order to eliminate ambiguity in legal
-cases. The two constructors that I suggested will co exist with the current
-members but will make auto_ptr_ref obsolete in initialization contexts.
-auto_ptr_ref will be effective in assignment contexts as suggested in DR
-#127 and I can't see any serious exception safety issues in those cases
-(although it's possible to synthesize such). auto_ptr_ref<X> semantics will
-have to be revised to say that it strictly holds pointer of type X and not
-reference to an auto_ptr for the favor of cases in which auto_ptr_ref<Y> is
-constructed from auto_ptr<X> in which X is different from Y (i.e. assignment
-from r-value derived to base).
-
        
+
        A()
+Using A from main()
+A is alive
+~A()
+A()
+Using A from ~B()
+A is alive
+~A()
+
        
+
+
        [
+Bellevue: Confirmed no interaction with quick_exit.
+Strong feeling against mandating the change. Leaning towards NAD rather than permitting the change,
+as this would make common implementations of pheonix-singleton pattern implementation defined, as noted by Howard.
+Bill agrees issue is no longer serious, and accepts NAD.
+]
        
+
 
 
 
 
        Proposed resolution:
        
-
        [Redmond: punt for the moment. We haven't decided yet whether we
-  want to fix auto_ptr for C++-0x, or remove it and replace it with
-  move_ptr and unique_ptr.]
        
-
-
-
-
        Rationale:
        
 
        
-Recommend NAD.  We're just going to deprecate it.  It still works for simple use cases
-and people know how to deal with it.  Going forward unique_ptr is the recommended
-tool.
 
        
 
 
@@ -6096,6 +6066,7 @@ Recommend NAD.  Relegate this functionality to debugging implementations.
 
        470. accessing containers from their elements' special functions
        
 
        Section: 23 [containers] Status: NAD
  Submitter: Martin Sebor Date: 2004-06-28
        
+
        View other active issues in [containers].
        
 
        View all other issues in [containers].
        
 
        View all issues with NAD status.
        
 
        Discussion:
        
@@ -6564,6 +6535,7 @@ operator that takes a T, or a T may be convertible to the type of *i.
 
        486. min/max CopyConstructible requirement is too strict
        
 
        Section: 25.3.7 [alg.min.max] Status: Dup
  Submitter: Dave Abrahams Date: 2004-10-13
        
+
        View other active issues in [alg.min.max].
        
 
        View all other issues in [alg.min.max].
        
 
        View all issues with Dup status.
        
 
        Duplicate of: 281
        
@@ -7080,12 +7052,12 @@ change, so there is no real-world harm here.
        
 
 
        
 
        491. std::list<>::unique incorrectly specified
        
-
        Section: 23.2.3.4 [list.ops] Status: NAD
+
        Section: 23.2.4.4 [list.ops] Status: NAD
  Submitter: Thomas Mang Date: 2004-12-12
        
 
        View all other issues in [list.ops].
        
 
        View all issues with NAD status.
        
 
        Discussion:
        
-
        In Section 23.2.3.4 [list.ops], paragraphs 19 to 21 describe the
+
        In Section 23.2.4.4 [list.ops], paragraphs 19 to 21 describe the
 behavior of the std::list<T, Allocator>::unique operation. However, the
 current wording is defective for various reasons.
        
 
@@ -7095,7 +7067,7 @@ current wording is defective for various reasons.
        
 1) Analysis of current wording:
 
        
 
-
        23.2.3.4 [list.ops], paragraph 19:
        
+
        23.2.4.4 [list.ops], paragraph 19:
        
 
 
        
 Current wording says:
@@ -7109,7 +7081,7 @@ predicate argument) holds."
        
 This sentences makes use of the undefined term "Eliminates". Although it
 is, to a certain degree, reasonable to consider the term "eliminate"
 synonymous with "erase", using "Erase" in the first place, as the
-wording of 23.2.3.4 [list.ops], paragraph 15 does, would be clearer.
        
+wording of 23.2.4.4 [list.ops], paragraph 15 does, would be clearer.
        
 
 
        
 The range of the elements referred to by iterator i is "[first + 1,
@@ -7126,7 +7098,7 @@ The same problems as pointed out in DR 202 (equivalence relation / order
 of arguments for pred()) apply to this paragraph.
        
 
 
        
-23.2.3.4 [list.ops], paragraph 20:
+23.2.4.4 [list.ops], paragraph 20:
 
        
 
 
        
@@ -7143,7 +7115,7 @@ expressions ( "*i == *(i - 1)", "pred(*i, *(i -1))" ).
 
        
 
 
        
-23.2.3.4 [list.ops], paragraph 21:
        
+23.2.4.4 [list.ops], paragraph 21:
        
 
 
        
 Current wording says:
@@ -7182,7 +7154,7 @@ of DR 202, no impact on current code is expected.
        
 3) Proposed fixes:
        
 
 
        
-Change 23.2.3.4 [list.ops], paragraph 19 to:
        
+Change 23.2.4.4 [list.ops], paragraph 19 to:
        
 
 
        
 "Effect: Erases all but the first element from every consecutive group
@@ -7201,7 +7173,7 @@ wording need also additional review.
 b) "Erases" refers in the author's opinion unambiguously to the member
 function "erase". In case there is doubt this might not be unamgibuous,
 a direct reference to the member function "erase" is suggested [Note:
-This would also imply a change of 23.2.3.4 [list.ops], paragraph
+This would also imply a change of 23.2.4.4 [list.ops], paragraph
 15.].
 c) The expression "(i - 1)" was left, but is expected that DR submitted
 by Thomas Mang regarding invalid iterator arithmetic expressions will
@@ -7221,7 +7193,7 @@ elements consists of only a single element, this element is also
 considered the first element."
        
 
 
        
-Change 23.2.3.4 [list.ops], paragraph 20 to:
        
+Change 23.2.4.4 [list.ops], paragraph 20 to:
        
 
 
        
 "Throws: Nothing unless an exception is thrown by *(i-1) == *i or
@@ -7232,7 +7204,7 @@ Comments to the new wording:
        
 
 
        
 a) The wording regarding the conditions is identical to proposed
-23.2.3.4 [list.ops], paragraph 19. If 23.2.3.4 [list.ops],
+23.2.4.4 [list.ops], paragraph 19. If 23.2.4.4 [list.ops],
 paragraph 19 is resolved in another way, the proposed wording need also
 additional review.
 b) The expression "(i - 1)" was left, but is expected that DR submitted
@@ -7241,7 +7213,7 @@ take this into account.
 c) Typos fixed.
        
 
 
        
-Change 23.2.3.4 [list.ops], paragraph 21 to:
        
+Change 23.2.4.4 [list.ops], paragraph 21 to:
        
 
 
        
 "Complexity: If empty() == false, exactly size() - 1 applications of the
@@ -7659,6 +7631,7 @@ Marc supports having min and max to satisfy generic programming interface.
 
        509. Uniform_int template parameters
        
 
        Section: 26.4.8.1 [rand.dist.uni], TR1 5.1.7.1 [tr.rand.dist.iunif] Status: NAD
  Submitter: Walter Brown Date: 2005-07-03
        
+
        View all other issues in [rand.dist.uni].
        
 
        View all issues with NAD status.
        
 
        Discussion:
        
 
        
@@ -8416,11 +8389,106 @@ chapter 17 wording.
 
 
 
+
        
+
        529. The standard encourages redundant and confusing preconditions
        
+
        Section: 17.4.3.9 [res.on.required] Status: NAD Editorial
+ Submitter: David Abrahams Date: 2005-10-25
        
+
        View all issues with NAD Editorial status.
        
+
        Discussion:
        
+
        
+17.4.3.8/1 says:
+
        
+
+
        
+Violation of the preconditions specified in a function's 
+Required behavior: paragraph results in undefined behavior unless the 
+function's Throws: paragraph specifies throwing an exception when the 
+precondition is violated.
+
        
+
+
        
+This implies that a precondition violation can lead to defined
+behavior.  That conflicts with the only reasonable definition of
+precondition: that a violation leads to undefined behavior.  Any other
+definition muddies the waters when it comes to analyzing program
+correctness, because precondition violations may be routinely done in
+correct code (e.g. you can use std::vector::at with the full
+expectation that you'll get an exception when your index is out of
+range, catch the exception, and continue).  Not only is it a bad
+example to set, but it encourages needless complication and redundancy
+in the standard.  For example:
+
        
+
+
          21 Strings library 
+  21.3.3 basic_string capacity
+
+  void resize(size_type n, charT c);
+
+  5 Requires: n <= max_size()
+  6 Throws: length_error if n > max_size().
+  7 Effects: Alters the length of the string designated by *this as follows:
+
        
+
+
        
+The Requires clause is entirely redundant and can be dropped.  We
+could make that simplifying change (and many others like it) even
+without changing 17.4.3.8/1; the wording there just seems to encourage
+the redundant and error-prone Requires: clause.
+
        
+
+
        [
+Batavia:  Alan and Pete to work.
+]
        
+
+
+
        [
+Bellevue:  NAD Editorial, this group likes 
+N2121,
+Pete agrees, accepting it is Pete's business.
+General agreement that precondition violations are synonymous with UB.
+]
        
+
+
+
+
        Proposed resolution:
        
+
        
+1. Change 17.4.3.8/1 to read:
+
        
+
+
        
+Violation of the preconditions specified in a function's
+Required behavior: paragraph results in undefined behavior
+unless the function's Throws: paragraph specifies throwing
+an exception when the precondition is violated.
+
        
+
+
        
+2. Go through and remove redundant Requires: clauses.  Specifics to be
+   provided by Dave A.
+
        
+
+
        [
+Berlin: The LWG requests a detailed survey of part 2 of the proposed resolution.
+]
        
+
+
+
        [
+Alan provided the survey
+N2121.
+]
        
+
+
+
+
+
+
+
 
        
 
        532. Tuple comparison
        
-
        Section: 20.3.1.5 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] Status: Pending NAD Editorial
+
        Section: 20.3.1.6 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] Status: Pending NAD Editorial
  Submitter: David Abrahams Date: 2005-11-29
        
 
        View all issues with Pending NAD Editorial status.
        
+
        Duplicate of: 348
        
 
        Discussion:
        
 
        
 Where possible, tuple comparison operators <,<=,=>, and > ought to be
@@ -8844,6 +8912,97 @@ Redmond:  Editorial.
 
 
 
+
        
+
        557. TR1: div(_Longlong, _Longlong) vs div(intmax_t, intmax_t)
        
+
        Section: 18.3 [cstdint], TR1 8.22 [tr.c99.cstdint] Status: Pending NAD Editorial
+ Submitter: Paolo Carlini Date: 2006-02-06
        
+
        View all other issues in [cstdint].
        
+
        View all issues with Pending NAD Editorial status.
        
+
        Discussion:
        
+
        
+I'm seeing a problem with such overloads: when, _Longlong == intmax_t ==
+long long we end up, essentially, with the same arguments and different
+return types (lldiv_t and imaxdiv_t, respectively). Similar issue with
+abs(_Longlong) and abs(intmax_t), of course.
+
        
+
        
+Comparing sections 8.25 and 8.11, I see an important difference,
+however: 8.25.3 and 8.25.4 carefully describe div and abs for _Longlong
+types (rightfully, because not moved over directly from C99), whereas
+there is no equivalent in 8.11: the abs and div overloads for intmax_t
+types appear only in the synopsis and are not described anywhere, in
+particular no mention in 8.11.2 (at variance with 8.25.2).
+
        
+
        
+I'm wondering whether we really, really, want div and abs for intmax_t...
+
        
+
+
+
+
        Proposed resolution:
        
+
+
+
+
        [
+Portland: no consensus.
+]
        
+
+
+
        Rationale:
        
+
        [
+Batavia, Bill: The <cstdint> synopsis in TR1 8.11.1 [tr.c99.cinttypes.syn] contains:
+]
        
+
+
        intmax_t imaxabs(intmax_t i);
+intmax_t abs(intmax_t i);
+
+imaxdiv_t imaxdiv(intmax_t numer, intmax_t denom);
+imaxdiv_t div(intmax_t numer, intmax_t denom);
+
        
+
+
        [
+and in TR1 8.11.2 [tr.c99.cinttypes.def]:
+]
        
+
+
+
        
+The header defines all functions, types, and macros the same as C99
+subclause 7.8.
+
        
+
+
        [
+This is as much definition as we give for most other C99 functions,
+so nothing need change. We might, however, choose to add the footnote:
+]
        
+
+
+
        
+[Note: These overloads for abs and div may well be equivalent to
+those that take long long arguments. If so, the implementation is
+responsible for avoiding conflicting declarations. -- end note]
+
        
+
+
        [
+Bellevue: NAD Editorial. Pete must add a footnote, as described below.
+]
        
+
+
+
        
+
        [
+Looks like a real problem. Dietmar suggests div() return a template
+type. Matt: looks like imaxdiv_t is loosly defined. Can it be a typedef
+for lldiv_t when _Longlong == intmax_t? PJP seems to agree. We would
+need a non-normative note declaring that the types lldiv_t and imaxdiv_t
+may not be unique if intmax_t==_longlong.
+]
        
+
+
        
+
+
+
+
+
+
 
        
 
        558. lib.input.iterators Defect
        
 
        Section: 24.1.1 [input.iterators] Status: NAD Editorial
@@ -9142,6 +9301,93 @@ is adopted.
 
 
 
+
        
+
        579. erase(iterator) for unordered containers should not return an iterator
        
+
        Section: 23.1.3 [unord.req] Status: NAD
+ Submitter: Joaquín M López Muńoz Date: 2006-06-13
        
+
        View all other issues in [unord.req].
        
+
        View all issues with NAD status.
        
+
        Discussion:
        
+
        
+See
+N2023
+for full discussion.
+
        
+
+
+
        Proposed resolution:
        
+
        
+Option 1:
+
        
+
+
        
+The problem can be eliminated by omitting the requirement that a.erase(q) return an 
+iterator. This is, however, in contrast with the equivalent requirements for other 
+standard containers.
+
        
+
+
        
+Option 2:
+
        
+
+
        
+a.erase(q) can be made to compute the next iterator only when explicitly requested: 
+the technique consists in returning a proxy object implicitly convertible to iterator, so 
+that
+
        
+
+
        iterator q1=a.erase(q);
+
        
+
+
        
+works as expected, while
+
        
+
+
        a.erase(q);
+
        
+
+
        
+does not ever invoke the conversion-to-iterator operator, thus avoiding the associated 
+computation. To allow this technique, some sections of TR1 along the line "return value 
+is an iterator..." should be changed to "return value is an unspecified object implicitly 
+convertible to an iterator..." Although this trick is expected to work transparently, it can 
+have some collateral effects when the expression a.erase(q) is used inside generic 
+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. 
+
        
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+The Bellevue review of this issue reached consensus with the Portland
+consensus, in contravention of the Toronto non-consensus. Common
+implementations have the iterator readily available, and most common
+uses depend on the iterator being returned.
+
        
+
+
+
+
+
+
 
        
 
        583. div() for unsigned integral types
        
 
        Section: 26.7 [c.math] Status: NAD
@@ -9597,6 +9843,207 @@ Recommend NAD, editorial.  Send to Pete.
 
 
 
+
        
+
        625. mixed up Effects and Returns clauses
        
+
        Section: 17 [library] Status: Pending NAD Editorial
+ Submitter: Martin Sebor Date: 2007-01-20
        
+
        View all other issues in [library].
        
+
        View all issues with Pending NAD Editorial status.
        
+
        Discussion:
        
+        
        
+
+Many  member functions  of  basic_string are  overloaded,
+with  some of  the  overloads taking  a string  argument,
+others  value_type*,  others size_type,  and
+others still iterators. Often, the requirements on one of
+the   overloads  are   expressed  in   the  form   of  Effects,
+Throws,      and     in      the     Working      Paper     
+(N2134)
+also Remark clauses,  while those on the rest  of the overloads
+via a reference to this overload and using a Returns clause.
+
+        
        
+        
        
+
+The  difference between  the two  forms of  specification is  that per
+17.3.1.3 [structure.specifications],  p3,  an  Effects clause  specifies
+"actions  performed  by the  functions,"  i.e., its  observable
+effects,  while a Returns  clause is  "a description  of the
+return  value(s)   of  a  function"  that  does   not  impose  any
+requirements on the function's observable effects.
+
+        
        
+        
        
+
+Since only  Notes are explicitly defined to  be informative and
+all  other paragraphs  are explicitly  defined to  be  normative, like
+Effects and Returns,  the new Remark clauses also
+impose normative requirements.
+
+        
        
+        
        
+
+So  by this  strict  reading of  the  standard there  are some  member
+functions of  basic_string that are required  to throw an
+exception under  some conditions or use specific  traits members while
+many other otherwise equivalent overloads, while obliged to return the
+same  values, aren't required  to follow  the exact  same requirements
+with regards to the observable effects.
+
+        
        
+        
        
+
+Here's an example of this  problem that was precipitated by the change
+from informative Notes to normative Remarks (presumably made to
+address 424):
+
+        
        
+        
        
+
+In the Working  Paper, find(string, size_type) contains a
+Remark  clause (which  is  just a  Note  in the  current
+standard) requiring it to use traits::eq().
+
+        
        
+        
        
+
+find(const  charT  *s,  size_type  pos) is  specified  to
+return  find(string(s), pos)  by a  Returns clause
+and so  it is not required to  use traits::eq(). However,
+the Working  Paper has  replaced the original  informative Note
+about   the  function   using  traits::length()   with  a
+normative  requirement  in  the   form  of  a  Remark.  Calling
+traits::length() may be  suboptimal, for example when the
+argument is a  very long array whose initial  substring doesn't appear
+anywhere in *this.
+
+        
        
+        
        
+
+Here's another  similar example,  one that existed  even prior  to the
+introduction of Remarks:
+
+        
        
+        
        
+
+ insert(size_type  pos, string, size_type,  size_type) is
+required   to   throw   out_of_range   if   pos   >
+size().
+
+        
        
+        
        
+
+insert(size_type pos, string  str) is specified to return
+insert(pos, str, 0, npos)  by a Returns clause and
+so its  effects when pos  > size() are  strictly speaking
+unspecified.
+
+        
+        
        
+
+I  believe  a  careful   review  of  the  current  Effects  and
+Returns  clauses  is  needed  in  order to  identify  all  such
+problematic cases. In  addition, a review of the  Working Paper should
+be done to make sure that the newly introduced normative Remark
+clauses do not impose  any undesirable normative requirements in place
+of the original informative Notes.
+
+        
        
+
        [
+Batavia:  Alan and Pete to work.
+]
        
+
+
+
        [
+Bellevue:  Marked as NAD Editorial.
+]
        
+
+
+
+
+
        Proposed resolution:
        
+
        
+
        
+
+
+
+
+
+
        
+
        626. new Remark clauses not documented
        
+
        Section: 17.3.1.3 [structure.specifications] Status: NAD Editorial
+ Submitter: Martin Sebor Date: 2007-01-20
        
+
        View all other issues in [structure.specifications].
        
+
        View all issues with NAD Editorial status.
        
+
        Discussion:
        
+        
        
+
+The Remark clauses newly  introduced into the Working Paper 
+(N2134)
+are  not mentioned  in  17.3.1.3 [structure.specifications] where  we list  the
+meaning  of Effects, Requires,  and other  clauses (with
+the exception  of Notes which are documented  as informative in
+17.3.1.1 [structure.summary], p2, and which they replace in many cases).
+
+        
        
+        
        
+
+Propose add a bullet for Remarks along with a brief description.
+
+        
        
+
        [
+Batavia:  Alan and Pete to work.
+]
        
+
+
+
        [
+Bellevue: Already resolved in current working paper.
+]
        
+
+
+
+
        Proposed resolution:
        
+
        
+
        
+
+
+
+
+
+
        
+
        627. Low memory and exceptions
        
+
        Section: 18.5.1.1 [new.delete.single] Status: NAD
+ Submitter: P.J. Plauger Date: 2007-01-23
        
+
        View all other issues in [new.delete.single].
        
+
        View all issues with NAD status.
        
+
        Discussion:
        
+
        
+I recognize the need for nothrow guarantees in the exception reporting
+mechanism, but I strongly believe that implementors also need an escape hatch
+when memory gets really low. (Like, there's not enough heap to construct and
+copy exception objects, or not enough stack to process the throw.) I'd like to
+think we can put this escape hatch in 18.5.1.1 [new.delete.single],
+operator new, but I'm not sure how to do it. We need more than a
+footnote, but the wording has to be a bit vague. The idea is that if
+new can't allocate something sufficiently small, it has the right to
+abort/call terminate/call unexpected.
+
        
+
+
        [
+Bellevue: NAD.  1.4p2 specifies a program must behave correctly "within
+its resource limits", so no further escape hatch is necessary.
+]
        
+
+
+
+
        Proposed resolution:
        
+
        
+
        
+
+
+
+
+
 
        
 
        633. Return clause mentions undefined "type()"
        
 
        Section: 20.5.15.2.5 [func.wrap.func.targ] Status: NAD Editorial
@@ -9862,6 +10309,7 @@ input functions because that applies to the case in which badbit is set.
 
        641. Editorial fix for 27.6.4 (N2134)
        
 
        Section: 27.6.4 [ext.manip] Status: NAD Editorial
  Submitter: Daniel Krügler Date: 2007-02-18
        
+
        View other active issues in [ext.manip].
        
 
        View all other issues in [ext.manip].
        
 
        View all issues with NAD Editorial status.
        
 
        Discussion:
        
@@ -9962,6 +10410,113 @@ In 27.8.1.13 [ofstream.members], remove footnote:
 
 
 
+
        
+
        645. Missing members in match_results
        
+
        Section: 28.10 [re.results] Status: NAD Editorial
+ Submitter: Daniel Krügler Date: 2007-02-26
        
+
        View all other issues in [re.results].
        
+
        View all issues with NAD Editorial status.
        
+
        Discussion:
        
+
        
+According to the description given in 28.10 [re.results]/2 the class template
+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:
+
        
+
+
        
+1) The members
+
        
+
+
        const_iterator rbegin() const;
+const_iterator rend() const;
+
        
+
+
        
+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.
+
        
+
        
+2) The new "convenience" members
+
        
+
        const_iterator cbegin() const;
+const_iterator cend() const;
+const_iterator crbegin() const;
+const_iterator crend() const;
+
        
+
        
+should be added according to tables 80/81.
+
        
+
+
+
        Proposed resolution:
        
+
        
+Add the following members to the match_results synopsis after end() in 28.10 [re.results]
+para 3:
+
        
+
+
        const_iterator cbegin() const; 
+const_iterator cend() const;
+
        
+
+
        
+In section 28.10.3 [re.results.acc] change:
+
        
+
+
        
+
        const_iterator begin() const;
+const_iterator cbegin() const;
+
        
+
        
+
        
+-7- Returns: A starting iterator that enumerates over all the sub-expressions stored in *this.
+
        
+
        
+
+
        const_iterator end() const;
+const_iterator cend() const;
+
        
+
        
+
        
+-8- Returns: A terminating iterator that enumerates over all the sub-expressions stored in *this.
+
        
+
        
+
        
+
+
+
+
        [
+Kona (2007): Voted to adopt proposed wording in
+N2409
+except removing the entry in the table container requirements.  Moved to Review.
+]
        
+
+
+
        [
+Bellevue:  Proposed wording now in the WP.
+]
        
+
+
+
+
+
 
        
 
        647. Inconsistent regex_search params
        
 
        Section: 28.11.3 [re.alg.search] Status: NAD Editorial
@@ -10178,6 +10733,92 @@ constructor sets *this to an end-of-sequence iterator.
 
 
 
+
        
+
        653. Library reserved names
        
+
        Section: 1.2 [intro.refs] Status: NAD
+ Submitter: Alisdair Meredith Date: 2007-03-08
        
+
        View all other issues in [intro.refs].
        
+
        View all issues with NAD status.
        
+
        Discussion:
        
+
        
+
        
+
        
+
        
+1.2 [intro.refs] Normative references
+
        
+
+
        
+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.
+
        
+
+
          
+
        • 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
          • 
+
        
+
        
+
+
        
+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!
+
        
+
        
+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.
+]
        
+
+
+
        [
+Bellevue: Wording is aleady present in various standards, and no-one has come forward with wording.
+Suggest a formal paper rather than a defect report is the correct way to proceed.
+]
        
+
+
+
+
+
        Proposed resolution:
        
+
+
+
+
+
 
        
 
        656. Typo in subtract_with_carry_engine declaration
        
 
        Section: 26.4.2 [rand.synopsis] Status: NAD Editorial
@@ -10584,6 +11225,159 @@ Yep, looks like a typo/administrative fix to me.
 
 
 
+
        
+
        684. Unclear which members of match_results should be used in comparison
        
+
        Section: 28.10 [re.results] Status: NAD Editorial
+ Submitter: Nozomu Katoo Date: 2007-05-27
        
+
        View all other issues in [re.results].
        
+
        View all issues with NAD Editorial status.
        
+
        Discussion:
        
+
        
+In 28.4 [re.syn] of N2284, two template functions 
+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).
+
        
+
        
+
        
+
+
+
        [
+Bellevue:  Proposed wording now in WP.
+]
        
+
+
+
+
+
+
        
+
        686. Unique_ptr and shared_ptr fail to specify non-convertibility to int for unspecified-bool-type
        
+
        Section: 20.6.11.2.4 [unique.ptr.single.observers], 20.6.12.2.5 [util.smartptr.shared.obs] Status: NAD
+ Submitter: Beman Dawes Date: 2007-06-14
        
+
        View all issues with NAD status.
        
+
        Discussion:
        
+
        
+The standard library uses the operator unspecified-bool-type() const idiom in
+five places. In three of those places (20.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.
+
        
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+Close as NAD. Accepting paper
+N2435
+makes it irrelevant.
+
        
+
+
+
+
        Proposed resolution:
        
+
        
+To the Returns paragraph for operator unspecified-bool-type()
+const
+of 20.6.11.2.4 [unique.ptr.single.observers] paragraph 11 and
+20.6.12.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.
+]
        
+
+
+
+
+
 
        
 
        690. abs(long long) should return long long
        
 
        Section: 26.7 [c.math] Status: NAD Editorial
@@ -10624,4 +11418,1893 @@ Had already been fixed in the WP by the time the LWG reviewed this.
 
 
 
+
        
+
        697. New <system_error> header leads to name clashes
        
+
        Section: 19.4 [syserr] Status: NAD Editorial
+ Submitter: Daniel Krügler Date: 2007-06-24
        
+
        View other active issues in [syserr].
        
+
        View all other issues in [syserr].
        
+
        View all issues with NAD Editorial status.
        
+
        Discussion:
        
+
        
+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:
+
        
+
+
        #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:
        
+
        
+Fixed by issue 7 of N2422.
+
        
+
+
+
+
+
+
+
        
+
        707. null pointer constant for exception_ptr
        
+
        Section: 18.7.5 [propagation] Status: NAD
+ Submitter: Jens Maurer Date: 2007-07-20
        
+
        View other active issues in [propagation].
        
+
        View all other issues in [propagation].
        
+
        View all issues with NAD status.
        
+
        Discussion:
        
+
+
        
+From the Toronto Core wiki:
+
        
+
+
        
+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".
+
        
+
+
        
+Peter's response:
+
        
+
+
        
+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.
+
        
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+
        
+Original implementation was possible using the "unspecified-null-pointer" idiom, similar to unspecified-bool.
+
        
+
        
+Even simpler now with nullptr_t.
+
        
+
        
+NAD Rationale : null pointer constant is a perfectly defined term, and
+while API is clearly implementable there is no need to spell out
+implementation details.
+
        
+
        
+
+
+
+
        Proposed resolution:
        
+
        
+
        
+
+
+
+
+
+
        
+
        709. char_traits::not_eof has wrong signature
        
+
        Section: 21.1.3 [char.traits.specializations] Status: Pending NAD Editorial
+ Submitter: Bo Persson Date: 2007-08-13
        
+
        View all other issues in [char.traits.specializations].
        
+
        View all issues with Pending NAD Editorial status.
        
+
        Discussion:
        
+
        
+The changes made for constexpr in 21.1.3 [char.traits.specializations] have 
+not only changed the not_eof function from pass by const reference to 
+pass by value, it has also changed the parameter type from int_type to 
+char_type.
+
        
+
        
+This doesn't work for type char, and is inconsistent with the 
+requirements in Table 56, Traits requirements, 21.1.1 [char.traits.require].
+
        
+
+
        
+Pete adds:
+
        
+
+
        
+For what it's worth, that may not have been an intentional change. 
+N2349, which detailed the changes for adding constant expressions to 
+the library, has strikeout bars through the const and the & that 
+surround the char_type argument, but none through char_type itself. 
+So the intention may have been just to change to pass by value, with 
+text incorrectly copied from the standard.
+
        
+
+
+
+
        Proposed resolution:
        
+
        
+Change the signature in 21.1.3.1 [char.traits.specializations.char],
+21.1.3.2 [char.traits.specializations.char16_t], 21.1.3.3 [char.traits.specializations.char32_t],
+and 21.1.3.4 [char.traits.specializations.wchar.t] to
+
        
+
+
        static constexpr int_type not_eof(char_type int_type c);
+
        
+
+
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+Resolution: NAD editorial - up to Pete's judgment
+
        
+
+
+
+
+
        
+
        717. Incomplete valarray::operator[] specification in [valarray.access]
        
+
        Section: 26.5.2.3 [valarray.access] Status: Pending NAD Editorial
+ Submitter: Daniel Krügler Date: 2007-08-27
        
+
        View all other issues in [valarray.access].
        
+
        View all issues with Pending NAD Editorial status.
        
+
        Discussion:
        
+
        
+Since the return type of valarray's operator[] const overload has been
+changed to const T& as described in 389 several paragraphs of
+the section 26.5.2.3 [valarray.access] are now
+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:
        
+
        
+Change 26.5.2.3 [valarray.access]:
+
        
+
+
        
+
        
+-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.
+
        
+
+
        
+-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)
+
        
+
+
        
+-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.
+
        
+
+
        
+
+
+
+
+
+
+
        
+
        725. Optional sequence container requirements column label
        
+
        Section: 23.1.1 [sequence.reqmts] Status: Pending NAD Editorial
+ Submitter: David Abrahams Date: 2007-09-16
        
+
        View all other issues in [sequence.reqmts].
        
+
        View all issues with Pending NAD Editorial status.
        
+
        Discussion:
        
+
        
+Table 90: (Optional sequence container operations) states the
+"assertion note pre/post-condition" of operator[] to be
+
        
+
+
        *(a.begin() + n)
+
        
+
+
        
+Surely that's meant to be "operational semantics?"
+
        
+
+
+
+
        Proposed resolution:
        
+
        
+
+
+
+
+
+
        Table 90: Optional sequence container operations
        expression return type assertion/note
        pre/post-condition
         operational semantics        		 container
        
+
        
+
+
+
+
+
+
+
        
+
        729. Problem in [rand.req.eng]/3
        
+
        Section: 26.4.1.3 [rand.req.eng] Status: NAD
+ Submitter: Stephan Tolksdorf Date: 2007-09-21
        
+
        View all other issues in [rand.req.eng].
        
+
        View all issues with NAD status.
        
+
        Discussion:
        
+
        
+The 3rd table row in 26.4.1.3 [rand.req.eng]/3 requires random number engines to accept any 
+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.
+
        
+
+
        
+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."
+
        
+
+
        
+Additionally, the definition of s in 26.4.1.3 [rand.req.eng]/1 c) could be restricted to unsigned integer types.
+
        
+
+
        
+Similarly, the type of the seed in 26.4.1.4 [rand.req.adapt]/3 e) could be left unspecified.
+
        
+
+
        
+See N2424
+for further discussion.
+
        
+
+
        [
+Stephan Tolksdorf adds pre-Bellevue:
+]
        
+
+
+
        
+
        
+In reply to the discussion in
+N2424
+regarding this issue:
+
        
+
        
+The descriptions of all engines and engine adaptors given in sections
+26.4.3 [rand.eng] and 26.4.4 [rand.adapt] already specify the concrete
+types of the integer arguments for seeding. Hence, relaxing the general
+requirement in 26.4.1.3 [rand.req.eng] would not affect portability and
+reproducibility of the standard library. Furthermore, it is not clear to
+me what exactly the guarantee "with initial state determined by
+static_cast<X::result_type>(s)" is useful for. On the other hand,
+relaxing the requirement would allow developers to implement  other
+random number engines that do not have to cast all arithmetic seed
+arguments to their result_types.
+
        
+
        
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+Propose close NAD for the reasons given in N2424.
+
        
+
+
+
+
+
        Proposed resolution:
        
+
        
+See N2424
+for further discussion.
+
        
+
+
        [
+Stephan Tolksdorf adds pre-Bellevue:
+]
        
+
+
+
        
+
        
+Change row 3 of table 105 "Random number engine requirements" in 26.4.1.3 [rand.req.eng]/3
+
        
+
+
        
+Creates an engine with initial state determined by
+static_cast<X::result_type>(s)
+
        
+
+
        
+Similarly, change 26.4.1.4 [rand.req.adapt]/3 e)
+
        
+
+
        
+When X::X is invoked with an X::result_type value s
+of arithmetic type (3.9.1), ...
+
        
+
+
        
+
+
+
+
+
+
+
        
+
        730. Comment on [rand.req.adapt]/3 e)
        
+
        Section: 26.4.1.4 [rand.req.adapt] Status: NAD
+ Submitter: Stephan Tolksdorf Date: 2007-09-21
        
+
        View all issues with NAD status.
        
+
        Discussion:
        
+
        
+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.
+
        
+
+
        
+Posssible resolution: [As above]
+
        
+
+
        
+See N2424
+for further discussion.
+
        
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+Close NAD for the reasons given in N2424.
+
        
+
+
+
+
        Proposed resolution:
        
+
        
+See N2424
+for the proposed resolution.
+
        
+
+
+
+
+
+
        
+
        731. proposal for a customizable seed_seq
        
+
        Section: 26.4.7.1 [rand.util.seedseq] Status: NAD
+ Submitter: Stephan Tolksdorf Date: 2007-09-21
        
+
        View other active issues in [rand.util.seedseq].
        
+
        View all other issues in [rand.util.seedseq].
        
+
        View all issues with NAD status.
        
+
        Discussion:
        
+
        
+The proper way to seed random number engines seems to be the most frequently 
+discussed issue of the 26.4 [rand] proposal. While the new seed_seq approach is already rather 
+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:
+
        
+
+
        
+Possible resolution:
+
        
+
+
          
+
        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. 
+
        
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+See N2424. Close NAD but note that "conceptizing" the library may cause
+this problem to be solved by that route.
+
        
+
+
+
        Proposed resolution:
        
+
        
+See N2424
+for the proposed resolution.
+
        
+
+
+
+
+
+
        
+
        733. Comment on [rand.req.dist]/9
        
+
        Section: 26.4.1.5 [rand.req.dist] Status: NAD
+ Submitter: Stephan Tolksdorf Date: 2007-09-21
        
+
        View all issues with NAD status.
        
+
        Discussion:
        
+
        
+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.]
+
        
+
+
        
+Proposed resolution: I propose to drop this requirement.
+
        
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+Close NAD for the reasons given in N2424. In practice it is not inconvenient to meet these requirements.
+
        
+
+
+
+
        Proposed resolution:
        
+
        
+See N2424
+for the proposed resolution.
+
        
+
+
+
+
+
+
        
+
        735. Unfortunate naming
        
+
        Section: 26.4.8.2.2 [rand.dist.bern.bin], 26.4.8.2.4 [rand.dist.bern.negbin] Status: NAD
+ Submitter: Stephan Tolksdorf Date: 2007-09-21
        
+
        View all issues with NAD status.
        
+
        Discussion:
        
+
        
+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.
+
        
+
+
        
+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.
+
        
+
+
        
+Possible resolution: For these reasons, I propose to change the name of the respective parameters
+to n and r.
+
        
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+In N2424. NAD It has been around for a while. It is hardly universal,
+there is prior art, and this would confuse people.
+
        
+
+
+
        Proposed resolution:
        
+
        
+See N2424
+for the proposed resolution.
+
        
+
+
+
+
+
+
        
+
        736. Comment on [rand.dist.samp.discrete]
        
+
        Section: 26.4.8.5.1 [rand.dist.samp.discrete] Status: NAD
+ Submitter: Stephan Tolksdorf Date: 2007-09-21
        
+
        View all other issues in [rand.dist.samp.discrete].
        
+
        View all issues with NAD 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. 
+
        
+
+
        
+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.
+
        
+
+
        [
+Stephan Tolksdorf adds pre-Bellevue:
+]
        
+
+
+
        
+
        
+In reply to the discussion in 
+N2424
+of this issue:
+
        
+
        
+Rescaled floating-point parameter vectors can not be expected to compare
+equal because of the limited precision of floating-point numbers.
+My proposal would at least guarantee that a parameter
+vector (of type double) passed into the distribution would compare equal
+with the one returned by the probabilities() method. Furthermore, I do
+not understand why "the changed requirement would lead to a significant
+increase in the amount of state in the distribution object". A typical
+implementation's state would increase by exactly one number: the sum of
+all probabilities. The textual representation for serialization would
+not need to grow at all. Finally, the proposed replacement "0 < n <=
+numeric_limits<IntType>::max() + 1" makes the implementation
+unnecessarily complicated, "0 < n <= numeric_limits<IntType>::max()"
+would be better.
+
        
+
        
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+
        
+In N2424. We agree with the observation and the proposed resolution to
+part b). We recommend the wording n > 0 be replaced with 0 < n
+numeric_limits::max() + 1. However, we disagree with part a), as it
+would interfere with the definition of parameters' equality. Further,
+the changed requirement would lead to a significant increase in the
+amount of state of the distribution object.
+
        
+
+
        
+As it stands now, it is convenient, and the changes proposed make it
+much less so.
+
        
+
+
        
+NAD. Part a the current behavior is desirable. Part b, any constructor
+can fail, but the rules under which it can fail do not need to be listed
+here.
+
        
+
        
+
+
+
        Proposed resolution:
        
+
        
+See N2424
+for the proposed resolution.
+
        
+
+
        [
+Stephan Tolksdorf adds pre-Bellevue:
+]
        
+
+
+
        
+
        
+In 26.4.8.5.1 [rand.dist.samp.discrete]:
+
        
+
+
        
+Proposed wording a):
+
        
+
+
        
+
        
+Changae in para. 2
+
        
+
+
        
+Constructs a discrete_distribution object with n=1 and p0 = w0 = 1
+
        
+
+
        
+and change in para. 5
+
        
+
+
        
+Returns: A vector<double> whose size member returns n and whose
+operator[] member returns pk
+the weight wk as a double value
+when invoked with argument k for k = 0,
+..., n-1
+
        
+
+
        
+
+
        
+Proposed wording b):
+
        
+
+
        
+
        
+Change in para. 3:
+
        
+
+
        
+If firstW == lastW, let the sequence w have length n = 1 and consist
+of the single value w0 = 1. Otherwise, [firstW,lastW) shall form a
+sequence w of length n > 0 
+such that 0 < n <= numeric_limits<IntType>::max(),
+and *firstW shall yield a value w0
+convertible to double. [Note: The values wk are commonly known
+as the weights . -- end note]
+
        
+
+
        
+
+
        
+
+
+
+
+
+
        
+
        737. Comment on [rand.dist.samp.pconst]
        
+
        Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: NAD
+ Submitter: Stephan Tolksdorf Date: 2007-09-21
        
+
        View other active issues in [rand.dist.samp.pconst].
        
+
        View all other issues in [rand.dist.samp.pconst].
        
+
        View all issues with NAD status.
        
+
        Discussion:
        
+
          
+
        1. 
+The discussion in point T11 above regarding probabilities() similarly applies 
+to the method densities() of piecewise_constant_distribution.
+
          2. 
+
        2. 
+
          
+The design of the constructor
+
          
+
          template <class InputIteratorB, class InputIteratorW> 
+piecewise_constant_distribution( InputIteratorB firstB, InputIteratorB lastB, 
+                                 InputIteratorW firstW);
+
          
+
          
+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. 
+
        
+
+
        
+Possible resolution: I propose to add an InputIteratorW lastW argument to the interface.
+
        
+
+
        [
+Stephan Tolksdorf adds pre-Bellevue:
+]
        
+
+
        
+In reply to the discussion in
+N2424
+I'd like to make the same comments as for 736.
+
        
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+In N2424. There is already precedent elsewhere in the library. Follows existing convention. NAD.
+
        
+
+
+
        Proposed resolution:
        
+
        
+See N2424
+for the proposed resolution.
+
        
+
+
        [
+Stephan Tolksdorf adds pre-Bellevue:
+]
        
+
+
+
        
+
        
+In 26.4.8.5.2 [rand.dist.samp.pconst]:
+
        
+
+
        
+Proposed wording a)
+
        
+
+
        
+
        
+Change in para. 2
+
        
+
        
+Constructs a piecewise_constant_distribution object with n = 1, p0 = w0 = 1,
+b0 = 0, and b1 = 1
+
        
+
+
        
+and change in para. 5
+
        
+
+
        
+A vector<result_type> whose size member returns n and whose operator[]
+member returns pk
+the weight wk as a double value
+when invoked with argument k for k = 0, ..., n-1
+
        
+
+
        
+
+
        
+Proposed wording b)
+
        
+
+
        
+
        
+Change both occurrences of
+
        
+
+
        
+"piecewise_constant_distribution(InputIteratorB firstB, InputIteratorB lastB,
+                                 InputIteratorW firstW, InputIteratorW lastW)
+
        
+
+
        
+and change in para. 3
+
        
+
+
        
+the length of the sequence w starting from firstW shall be at least n,
+*firstW shall return a value w0 that is convertible to double, and any
+wk for k >= n shall be ignored by the distribution
+[firstW, lastW) shall form a sequence w of length n whose leading element
+w0 shall be convertible to double
+
        
+
+
        
+
+
+
        
+
+
+
+
+
+
+
        
+
        738. Editorial issue in [rand.adapt.disc]/3
        
+
        Section: 26.4.4.1 [rand.adapt.disc] Status: Pending NAD Editorial
+ Submitter: Stephan Tolksdorf Date: 2007-09-21
        
+
        View all issues with Pending NAD Editorial status.
        
+
        Discussion:
        
+
        
+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.
+
        
+
+
+
        Proposed resolution:
        
+
        
+See N2424
+for the proposed resolution.
+
        
+
+
+
+
+
+
        
+
        739. Defect in [rand.util.canonical]/3
        
+
        Section: 26.4.7.2 [rand.util.canonical] Status: NAD
+ Submitter: Stephan Tolksdorf Date: 2007-09-21
        
+
        View all other issues in [rand.util.canonical].
        
+
        View all issues with NAD status.
        
+
        Discussion:
        
+
        
+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)).
+
        
+
+
        
+See N2424
+for further discussion.
+
        
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+In N2424. Close NAD as described there.
+
        
+
+
+
+
        Proposed resolution:
        
+
        
+See N2424
+for the proposed resolution.
+
        
+
+
+
+
+
+
        
+
        741. Const-incorrect get_deleter function for shared_ptr
        
+
        Section: 20.6.12.2.11 [util.smartptr.getdeleter] Status: NAD
+ Submitter: Daniel Krügler Date: 2007-09-27
        
+
        View all other issues in [util.smartptr.getdeleter].
        
+
        View all issues with NAD status.
        
+
        Discussion:
        
+
        
+The following issue was raised by Alf P. Steinbach in c.l.c++.mod:
+
        
+
+
        
+According to the recent draft N2369, both the header memory synopsis
+of 20.6 [memory] and 20.6.12.2.11 [util.smartptr.getdeleter] declare:
+
        
+
+
        template<class D, class T> D* get_deleter(shared_ptr<T> const& p);
+
        
+
+
        
+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:
+
+
        
+Replace the declarations of get_deleter in the header <memory>
+synopsis of 20.6 [memory] and in 20.6.12.2.11 [util.smartptr.getdeleter] by one of the
+following alternatives (A) or (B):
+
        
+
+
          
+
        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. 
+
        
+
+
        
+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&);
+
          
+
+
          
+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:
+
        
+
+
        
+
        
+My favorite option is "not a defect". A, B and C break useful code.
+
        
+
        
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+Concern this is similar to confusing "pointer to const" with "a constant pointer".
+
        
+
+
+
        Proposed resolution:
        
+
        
+
        
+
+
+
+
+
+
        
+
        745. copy_exception API slices.
        
+
        Section: 18.7.5 [propagation] Status: NAD
+ Submitter: Alisdair Meredith Date: 2007-10-10
        
+
        View other active issues in [propagation].
        
+
        View all other issues in [propagation].
        
+
        View all issues with NAD status.
        
+
        Discussion:
        
+
        
+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.
+
        
+
        
+(Peter Dimov suggests NAD)
+
        
+
+
        [
+Bellevue: 
+]
        
+
+
+
        
+
        
+How could this be implemented in a way that the dynamic type is cloned?
+
        
+
        
+The feature is designed to create an exception_ptr from an object whose
+static type is identical to the dynamic type and thus there is no
+slicing involved.
+
        
+
        
+
+
+
        Proposed resolution:
        
+
        
+
        
+
+
+
+
+
+
        
+
        748. The is_abstract type trait is defined by reference to 10.4.
        
+
        Section: 20.4.4.3 [meta.unary.prop] Status: NAD
+ 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 NAD status.
        
+
        Discussion:
        
+
        
+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:
        
+
        
+Core has clarified that the definition abstract is adequate. Issue withdrawn by submitter. NAD.
+
        
+
+
+
+
+
+
        
+
        754. Ambiguous return clause for std::uninitialized_copy
        
+
        Section: 20.6.10.1 [uninitialized.copy] Status: Pending NAD Editorial
+ Submitter: Daniel Krügler Date: 2007-10-15
        
+
        View all other issues in [uninitialized.copy].
        
+
        View all issues with Pending NAD Editorial status.
        
+
        Discussion:
        
+
        
+14882-2003, [lib.uninitialized.copy] is currently written as follows:
+
        
+
+
        
+
        template <class InputIterator, class ForwardIterator>
+  ForwardIterator uninitialized_copy(InputIterator first, InputIterator last,
+                                     ForwardIterator result);
+
        
+
        
+
        
+-1- Effects:
+
        
+
        for (; first != last; ++result, ++first)
+  new (static_cast<void*>(&*result))
+    typename iterator_traits<ForwardIterator>::value_type(*first);
+
        
+
        
+-2- Returns: result
+
        
+
        
+
        
+
+
        
+similarily for N2369, and its corresponding section
+20.6.10.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.10.1 [uninitialized.copy]):
+
        
+
+
        
+
        
+-2- Returns: The value of result after effects have taken place.
+
        
+
        
+
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+Resolution: NAD editorial -- project editor to decide if change is
+worthwhile. Concern is that there are many other places this might
+occur.
+
        
+
+
+
+
+
        
+
        757. Typo in the synopsis of vector
        
+
        Section: 23.2.6 [vector] Status: Pending NAD Editorial
+ Submitter: Paolo Carlini Date: 2007-11-04
        
+
        View all other issues in [vector].
        
+
        View all issues with Pending NAD Editorial status.
        
+
        Discussion:
        
+
        
+In the synopsis 23.2.6 [vector], there is the signature:
+
        
+
+
        void insert(const_iterator position, size_type n, T&& x);
+
        
+
+
        
+instead of:
+
        
+
+
        iterator insert(const_iterator position, T&& x);
+
        
+
+
        
+23.2.6.4 [vector.modifiers] is fine.
+
        
+
+
+
+
        Proposed resolution:
        
+
        
+Change the synopsis in 23.2.6 [vector]:
+
        
+
+
        iterator insert(const_iterator position, const T& x); 
+iterator insert(const_iterator position, T&& x);
+void     insert(const_iterator position, size_type n, const T& x); 
+void     insert(const_iterator position, size_type n, T&& x);
+
        
+
+
+
+
+
+
        
+
        763. Renaming emplace() overloads
        
+
        Section: 23.1.2 [associative.reqmts] Status: NAD
+ Submitter: Sylvain Pion Date: 2007-12-04
        
+
        View all other issues in [associative.reqmts].
        
+
        View all issues with NAD status.
        
+
        Discussion:
        
+
        
+The associative containers provide 2 overloads of emplace():
+
        
+
+
        template <class... Args> pair<iterator, bool> emplace(Args&&... args);
+template <class... Args> iterator emplace(const_iterator position, Args&&... args);
+
        
+
+
        
+This is a problem if you mean the first overload while passing
+a const_iterator as first argument.
+
        
+
+
        [
+Related to 767
+]
        
+
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+
        
+
        
+This can be disambiguated by passing "begin" as the first argument in
+the case when the non-default choice is desired. We believe that desire
+will be rare.
+
        
+
        
+Resolution: Change state to NAD.
+
        
+
+
+
        Proposed resolution:
        
+
        
+Rename one of the two overloads.
+For example to emplace_here, hint_emplace...
+
        
+
+
+
+
+
+
        
+
        764. equal_range on unordered containers should return a pair of local_iterators
        
+
        Section: 23.1.3 [unord.req] Status: NAD
+ Submitter: Joe Gottman Date: 2007-11-29
        
+
        View all other issues in [unord.req].
        
+
        View all issues with NAD status.
        
+
        Discussion:
        
+
        
+    A major attribute of the unordered containers is that iterating 
+though them inside a bucket is very fast while iterating between buckets 
+can be much slower.  If an unordered container has a low load factor, 
+iterating between the last iterator in one bucket and the next iterator, 
+which is in another bucket, is O(bucket_count()) which may be much 
+larger than O(size()).
+
        
+
        
+    If b is an non-const unordered container of type B and k is an 
+object of it's key_type, then b.equal_range(k) currently returns 
+pair<B::iterator, B::iterator>. Consider the following code:
+
        
+
+
        B::iterator lb, ub;
+tie(lb, ub) = b.equal_range(k);
+for (B::iterator it = lb; it != ub; ++it) {
+        // Do something with *it
+}
+
        
+
+
        
+If b.equal_range(k) returns a non-empty range (i.e. b contains at least 
+on element whose key is equivalent to k), then every iterator in the 
+half-open range [lb, ub) will be in the same bucket, but ub will likely 
+either be in a different bucket or be equal to b.end().  In either case, 
+iterating between ub - 1 and ub could take a much longer time than 
+iterating through the rest of the range.
+
        
+
        
+If instead of returning pair<iterator, iterator>, equal_range were to 
+return pair<local_iterator, local_iterator>, then ub (which, like lb, 
+would now be a local_iterator) could be guaranteed to always be in the 
+same bucket as lb. In the cases where currently ub is equal to b.end()
+or is in a different bucket, ub would be equal to b.end(b.bucket(key)). 
+  This would make iterating between lb and ub much faster, as every 
+iteration would be constant time.
+
        
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+The proposed resolution breaks consistency with other container types
+for dubious benefit, and iterators are already constant time.
+
        
+
+
+
+
        Proposed resolution:
        
+
        
+Change the entry for equal_range in Table 93 (23.1.3 [unord.req]) as follows:
+
        
+
+
+
+
+
+
+
+
+
+
+
+
        expression return type assertion/note pre/post-condition complexity
        b.equal_range(k)pair<local_iterator,local_iterator>; pair<const_local_iterator,const_local_iterator> for const b.Returns a range containing all elements with keys equivalent to k. Returns make_pair(b.end(b.bucket(key)),b.end(b.bucket(key))) if no such elements exist.Average case Θ(b.count(k)). Worst case Θ(b.size()). 
        
+
+
+
+
+
+
        
+
        773. issues with random
        
+
        Section: 26.4.8.1 [rand.dist.uni] Status: NAD
+ Submitter: P.J. Plauger Date: 2008-01-14
        
+
        View all other issues in [rand.dist.uni].
        
+
        View all issues with NAD status.
        
+
        Discussion:
        
+
          
+
        1. 
+26.4.8.1.1 [rand.dist.uni.int] uniform_int constructor has changed the default
+max constructor parameter from 9 (in TR1) to max(). The value
+is arbitrary at best and shouldn't be lightly changed because
+it breaks backward compatibility.
+
          2. 
+
+
        2. 
+26.4.8.1.1 [rand.dist.uni.int] uniform_int has a parameter param that you can
+provide on construction or operator(), set, and get. But there
+is not even a hint of what this might be for.
+
          3. 
+
+
        3. 
+26.4.8.1.2 [rand.dist.uni.real] uniform_real. Same issue as #2.
+
          4. 
+
        
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+NAD. Withdrawn.
+
        
+
+
+
        Proposed resolution:
        
+
        
+
        
+
+
+
+
+
+
        
+
        784. unique_lock::release
        
+
        Section: 30.3.3.2.3 [thread.lock.unique.mod] Status: NAD
+ Submitter: Constantine Sapuntzakis Date: 2008-02-02
        
+
        View all issues with NAD status.
        
+
        Discussion:
        
+
        
+unique_lock::release will probably lead to many mistakes where people
+call release instead of unlock. I just coded such a mistake using the
+boost pre-1.35 threads library last week.
+
        
+
+
        
+In many threading libraries, a call with release in it unlocks the
+lock (e.g. ReleaseMutex in Win32, java.util.concurrent.Semaphore).
+
        
+
+
        
+I don't call unique_lock::lock much at all, so I don't get to see the
+symmetry between ::lock and ::unlock. I usually use the constructor to
+lock the mutex. So I'm left to remember whether to call release or
+unlock during the few times I need to release the mutex before the scope
+ends. If I get it wrong, the compiler doesn't warn me.
+
        
+
+
        
+An alternative name for release may be disown.
+
        
+
+
        
+This might be a rare case where usability is hurt by consistency with
+the rest of the C++ standard (e.g. std::auto_ptr::release).
+
        
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+Change a name from release to disown. However prior art uses the release
+name. Compatibility with prior art is more important that any possible
+benefit such a change might make. We do not see the benefit for
+changing. NAD
+
        
+
+
+
        Proposed resolution:
        
+
        
+Change the synopsis in 30.3.3.2 [thread.lock.unique]:
+
        
+
+
        template <class Mutex> 
+class unique_lock 
+{ 
+public:
+   ...
+   mutex_type* release disown();
+   ...
+};
+
        
+
+
        
+Change 30.3.3.2.3 [thread.lock.unique.mod]:
+
        
+
+
        mutex_type *release disown();
+
        
+
+
+
+
+
+
        
+
        790. xor_combine::seed not specified
        
+
        Section: 26.4.4.4 [rand.adapt.xor] Status: NAD
+ Submitter: P.J. Plauger Date: 2008-02-09
        
+
        View all other issues in [rand.adapt.xor].
        
+
        View all issues with NAD status.
        
+
        Discussion:
        
+
        
+xor_combine::seed(result_type) and seed(seed_seq&) don't say what
+happens to each of the sub-engine seeds. (Should probably do the same
+to both, unlike TR1.)
+
        
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+Overcome by the previous proposal. NAD mooted by resolution of 789.
+
        
+
+
+
+
        Proposed resolution:
        
+
+
+
+
+
+
        
+
        791. piecewise_constant_distribution::densities has wrong name
        
+
        Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: NAD
+ Submitter: P.J. Plauger Date: 2008-02-09
        
+
        View other active issues in [rand.dist.samp.pconst].
        
+
        View all other issues in [rand.dist.samp.pconst].
        
+
        View all issues with NAD status.
        
+
        Discussion:
        
+
        
+piecewise_constant_distribution::densities() should be probabilities(),
+just like discrete_distribution. (There's no real use for weights divided
+by areas.)
+
        
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+
        
+Fermilab does not agree with this summary. As defined in the equation in
+26.4.8.5.2/4, the quantities are indeed probability densities not
+probabilities. Because we view this distribution as a parameterization
+of a *probability density function*, we prefer to work in terms of
+probability densities.
+
        
+
+
        
+We don't think this should be changed.
+
        
+
+
        
+If there is a technical argument about why the implementation dealing
+with these values can't be as efficient as one dealing with
+probabilities, we might reconsider. We don't care about this one member
+function being somewhat more or less efficient; we care about the size
+of the distribution object and the speed of the calls to generate
+variates.
+
        
+
        
+
+
+
+
        Proposed resolution:
        
+
+
        
+Change synopsis in 26.4.8.5.2 [rand.dist.samp.pconst]:
+
        
+
+
        template <class RealType = double> 
+class piecewise_constant_distribution 
+{ 
+public:
+    ...
+    vector<double> densities probabilities() const;
+    ...
+};
+
        
+
+
        
+Change 26.4.8.5.2 [rand.dist.samp.pconst]/6:
+
        
+
+
        vector<double> densities probabilities() const;
+
        
+
+
+
+
+
+
+
        
+
        795. general_pdf_distribution should be dropped
        
+
        Section: 26.4.8.5.3 [rand.dist.samp.genpdf] Status: Dup
+ Submitter: P.J. Plauger Date: 2008-02-09
        
+
        View all other issues in [rand.dist.samp.genpdf].
        
+
        View all issues with Dup status.
        
+
        Duplicate of: 732
        
+
        Discussion:
        
+
        
+general_pdf_distribution should be dropped. (It's a research topic in
+adaptive numerical integration.)
+
        
+
+
        [
+Stephan Tolksdorf notes:
+]
        
+
+
+
        
+This appears to be a duplicate of 732.
+
        
+
+
+
        Proposed resolution:
        
+
+
+
+
+
+
+
        
+
        796. ranlux48_base returns wrong value
        
+
        Section: 26.4.5 [rand.predef] Status: NAD
+ Submitter: P.J. Plauger Date: 2008-02-09
        
+
        View all other issues in [rand.predef].
        
+
        View all issues with NAD status.
        
+
        Discussion:
        
+
        
+The 10,000th value returned by ranlux48_base is supposed to be
+61839128582725. We get 192113843633948. (Note that the underlying
+generator was changed in Kona.)
+
        
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+Submitter withdraws defect.
+
        
+
+
+
+
        Proposed resolution:
        
+
        
+Change 26.4.5 [rand.predef]/p5:
+
        
+
+
        
+
        typedef subtract_with_carry_engine<uint_fast64_t, 48, 5, 12> 
+        ranlux48_base; 
+
        
+
        
+Required behavior: The 10000th consecutive invocation of a default-constructed
+object of type ranlux48_base shall produce the value
+61839128582725 192113843633948.
+
        
+
        
+
+
+
+
+
+
        
+
        797. ranlux48 returns wrong value
        
+
        Section: 26.4.5 [rand.predef] Status: NAD
+ Submitter: P.J. Plauger Date: 2008-02-09
        
+
        View all other issues in [rand.predef].
        
+
        View all issues with NAD status.
        
+
        Discussion:
        
+
        
+The 10,000th value returned by ranlux48 is supposed to be
+249142670248501. We get 88229545517833. (Note that this depends
+on ranlux48_base.)
+
        
+
        [
+Bellevue:
+]
        
+
+
+
        
+Submitter withdraws defect.
+
        
+
+
+
+
        Proposed resolution:
        
+
        
+Change 26.4.5 [rand.predef]/p6:
+
        
+
+
        
+
        typedef discard_block_engine<ranlux48_base, 389, 11> 
+        ranlux48
+
        
+
        
+Required behavior: The 10000th consecutive invocation of a default-constructed
+object of type ranlux48 shall produce the value
+249142670248501 88229545517833.
+
        
+
        
+
+
+
+
+
+
        
+
        799. [tr.rand.eng.mers] and [rand.eng.mers]
        
+
        Section: 26.4.3.2 [rand.eng.mers], TR1 5.1.4.2 [tr.rand.eng.mers] Status: NAD
+ Submitter: Stephan Tolksdorf Date: 2008-02-18
        
+
        View all other issues in [rand.eng.mers].
        
+
        View all issues with NAD status.
        
+
        Discussion:
        
+
        
+TR1 5.1.4.2 [tr.rand.eng.mers](10) requires that operator== for the mersenne_twister
+returns true if and only if the states of two mersenne_twisters,
+consisting each of n integers between 0 and 2w - 1, are completely
+equal. This is a contradiction with TR1 5.1.1 [tr.rand.req](3) because the given
+definition of the state also includes the lower r bits of x(i-n), which
+will never be used to generate a random number. If two mersenne_twisters
+only differ in the lower bits of x(i-n) they will not compare equal,
+although they will produce an identical sequence of random numbers.
+
        
+
+
        
+26.4.3.2 [rand.eng.mers] in the latest C++ draft does not specify the behaviour
+of operator== but uses a similar definition of the state and, just like
+TR1 5.1.4.2 [tr.rand.eng.mers], requires the textual representation of a
+mersenne_twister_engine to consist of Xi-n to Xi-1, including the
+lower bits of Xi-n. This leads to two problems: First, the
+unsuspecting implementer is likely to erroneously compare the lower r
+bits of Xi-n in operator==. Second, if only the lower r bits differ,
+two mersenne_twister_engines will compare equal (if correctly
+implemented) but have different textual representations, which
+conceptually is a bit ugly.
+
        
+
+
        
+I propose that a paragraph or footnote is added to 26.4.3.2 [rand.eng.mers] which
+clarifies that the lower r bits of Xi-n are not to be compared in
+operator== and operator!=. It would only be consequent if furthermore
+the specification for the textual respresentation was changed to
+Xi-n bitand ((2w - 1) - (2r - 1)), Xi-(n-1), ...,  Xi-1 or
+something similar.
+
        
+
+
        
+These changes would likely have no practical effect, but would allow an
+implementation that does the right thing to be standard-conformant.
+
        
+
+
        [
+Bellevue:
+]
        
+
+
+
        
+
        
+Fermi Lab has no objection to the proposed change. However it feels that
+more time is needed to check the details, which would suggest a change
+to REVIEW.
+
        
+
        
+Bill feels that this is NAD, not enough practical importance to abandon
+the simple definition of equality, and someone would have to do a lot
+more study to ensure that all cases are covered for a very small
+payback. The submitter admits that "These changes would likely have no
+practical effect,", and according to Plum's razor this means that it is
+not worth the effort!
+
        
+
        
+Revisted: Agree that the fact that there is no practical difference means that no change can be justified.
+
        
+
        
+
+
+
        Proposed resolution:
        
+
        
+In 26.4.3.2 [rand.eng.mers]:
+
        
+
+
        
+
        
+Insert at the end of para 2.:
+
        
+
+
        
+[Note: The lower r bits of Xi-n do not influence
+the state transition and hence should not be compared when comparing two
+mersenne_twister_engine objects. -- end note]
+
        
+
+
        
+In para 5. change:
+
        
+
+
        
+The textual representation of xi consists of the values of
+Xi-n bitand ((2w - 1) - (2r - 1)),  Xi-(n-1),
+..., Xi-1, in that order.
+
        
+
        
+
+
+
+
+
+
        
+
        802. knuth_b returns wrong value
        
+
        Section: 26.4.5 [rand.predef] Status: NAD
+ Submitter: P.J. Plauger Date: 2008-02-20
        
+
        View all other issues in [rand.predef].
        
+
        View all issues with NAD status.
        
+
        Discussion:
        
+
        
+The 10,000th value returned by knuth_b is supposed to be
+1112339016. We get 2126698284.
+
        
+
+
+
        Proposed resolution:
        
+
        
+Change 26.4.5 [rand.predef]/p8:
+
        
+
+
        
+
        typedef shuffle_order_engine<minstd_rand0, 256> 
+        knuth_b; 
+
        
+
        
+Required behavior: The 10000th consecutive invocation of a default-constructed
+object of type knuth_b shall produce the value
+1112339016 2126698284.
+
        
+
        
+
+
+
        [
+Bellevue: Submitter withdraws defect. "We got the wrong value for entirely the right reasons". NAD.
+]
        
+
+
+
+
+
+
 
\ No newline at end of file
diff --git a/libstdc++-v3/doc/html/ext/lwg-defects.html b/libstdc++-v3/doc/html/ext/lwg-defects.html
index cefbee652e6..01335032884 100644
--- a/libstdc++-v3/doc/html/ext/lwg-defects.html
+++ b/libstdc++-v3/doc/html/ext/lwg-defects.html
@@ -12,11 +12,11 @@ del {background-color:#FFA0A0}
 
-
+
-
+
@@ -27,7 +27,7 @@ del {background-color:#FFA0A0}
 
        
 
        
 Doc. no.N2457=07-0327N2613=08-0123
 
        
 
        
 Date:2007-10-202008-05-18
 
        
 
        
 Project:Howard Hinnant <howard.hinnant@gmail.com>
 
        
 
        
-
        C++ Standard Library Defect Report List (Revision R52)
        
+
        C++ Standard Library Defect Report List (Revision R56)
        
 
   
        Reference ISO/IEC IS 14882:1998(E)
        
   
        Also see:
        
@@ -49,6 +49,89 @@ del {background-color:#FFA0A0}
 
 
        Revision History
        
 
 
        22. 
@@ -96,13 +179,13 @@ del {background-color:#FFA0A0}
 
      22. 708 issues total, up by 12.
        23. 
 
 
      23. Details:
          
-
        • Added the following New issues: 697, 698, 699, 700, 701, 702, 703, 704, 705, 706, 707, 708.
          • 
+
        • Added the following New issues: 697, 698, 699, 700, 701, 702, 703, 704, 705, 706, 707, 708.
          • 
 
        • Changed the following issues from New to NAD: 583, 584, 662.
          • 
 
        • Changed the following issues from Open to NAD: 528.
          • 
 
        • Changed the following issues from New to NAD Editorial: 637, 647, 658, 690.
          • 
 
        • Changed the following issues from Open to NAD Editorial: 525.
          • 
 
        • Changed the following issues from Pending NAD Editorial to NAD Editorial: 553, 571, 591, 633, 636, 641, 642, 648, 649, 656.
          • 
-
        • Changed the following issues from New to Open: 579, 631, 680.
          • 
+
        • Changed the following issues from New to Open: 579, 631, 680.
          • 
 
        • Changed the following issues from Pending WP to Open: 258.
          • 
 
        • Changed the following issues from Ready to Pending WP: 644.
          • 
 
        • Changed the following issues from New to Ready: 577, 660.
          • 
@@ -123,7 +206,7 @@ del {background-color:#FFA0A0}
 
        • 696 issues total, up by 20.
          • 
 
        24. 
 
      24. Details:
        25. 
 
      25. Details:
        26. 
 
      26. Details:
        27. 
 
@@ -201,7 +284,7 @@ del {background-color:#FFA0A0}
 
      27. Moved issues 520, 521, 530, 535, 537, 538, 540, 541 to WP.
        28. 
 
      28. Moved issues 504, 512, 516, 544, 549, 554, 555, 558 to NAD.
        29. 
 
      29. Moved issue 569 to Dup.
        30. 
-
      30. Moved issues 518, 523, 524, 542, 556, 557, 559, 597, 606 to Open.
        31. 
+
      31. Moved issues 518, 523, 524, 542, 556, 557, 559, 597, 606 to Open.
        32. 
 
      32. Moved issues 543, 545, 549, 549, 598 - 603, 605 to Ready.
        33. 
 
      33. Moved issues 531, 551, 604 to Review.
        34. 
 
      34. Added new issues 593-609.
        35. 
@@ -245,9 +328,9 @@ del {background-color:#FFA0A0}
 
      35. 574 issues total, up by 8.
        36. 
 
 
      36. Details:
        37. 
 
      37. Details:
        38. 
 
 
@@ -323,12 +406,12 @@ new issues 463-478.
+new issues 463-478.
 
 
      38. R30: 
 Post-Sydney mailing: reflects decisions made at the Sydney meeting.
 Voted all "Ready" issues from R29 into the working paper.
-Added new issues 460-462.
+Added new issues 460-462.
 
        39. 
 
      39. R29: 
 Pre-Sydney mailing.  Added new issues 441-457.
@@ -473,7 +556,7 @@ of issue 83,
 86, 91, 92,
-109. Added issues 190 to
+109. Added issues 190 to
 195. (99-0033/D1209, 14 Oct 99)
 
        40. 
 
      40. R9: 
@@ -492,7 +575,7 @@ pre-Dublin updated: Added issues 138, 139 (31 Mar 99)
 
        41. 
 
      41. R6: 
-pre-Dublin mailing. Added issues 127, 128,
+pre-Dublin mailing. Added issues 127, 128,
 and 129.  (99-0007/N1194, 22 Feb 99)
 
        42. 
 
      42. R5: 
@@ -962,7 +1045,6 @@ supporting to the proposed resolution.
        
 
        11. Bitset minor problems
        
 
        Section: 23.3.5 [template.bitset] Status: TC
  Submitter: Matt Austern Date: 1998-01-22
        
-
        View other active issues in [template.bitset].
        
 
        View all other issues in [template.bitset].
        
 
        View all issues with TC status.
        
 
        Discussion:
        
@@ -3314,7 +3396,7 @@ item from:
        
 
 
        
 
        69. Must elements of a vector be contiguous?
        
-
        Section: 23.2.5 [vector] Status: TC
+
        Section: 23.2.6 [vector] Status: TC
  Submitter: Andrew Koenig Date: 1998-07-29
        
 
        View all other issues in [vector].
        
 
        View all issues with TC status.
        
@@ -3328,7 +3410,7 @@ debugging implementations)
        
 
 
 
        Proposed resolution:
        
-
        Add the following text to the end of 23.2.5 [vector],
+
        Add the following text to the end of 23.2.6 [vector],
 paragraph 1. 
        
 
 
        
@@ -4567,7 +4649,6 @@ example, printing short(-1) in hex format should yield 0xffff.)
        
 
        118. basic_istream uses nonexistent num_get member functions
        
 
        Section: 27.6.1.2.2 [istream.formatted.arithmetic] Status: WP
  Submitter: Matt Austern Date: 1998-11-20
        
-
        View other active issues in [istream.formatted.arithmetic].
        
 
        View all other issues in [istream.formatted.arithmetic].
        
 
        View all issues with WP status.
        
 
        Discussion:
        
@@ -4681,7 +4762,7 @@ exception-specification for a non-virtual function". 
        
 
 
        
 
        120. Can an implementor add specializations?
        
-
        Section: 17.4.3.1 [reserved.names] Status: WP
+
        Section: 17.4.3.2 [reserved.names] Status: WP
  Submitter: Judy Ward Date: 1998-12-15
        
 
        View all other issues in [reserved.names].
        
 
        View all issues with WP status.
        
@@ -4732,7 +4813,7 @@ different explicit instantiations might be harmless.
        
 
 
 
        Proposed resolution:
        
-  
        Append to 17.4.3.1 [reserved.names] paragraph 1: 
        
+  
        Append to 17.4.3.2 [reserved.names] paragraph 1: 
        
   
        
     A program may explicitly instantiate any templates in the standard
     library only if the declaration depends on the name of a user-defined
@@ -4751,7 +4832,7 @@ different explicit instantiations might be harmless.
        
 
        
   
        In light of the resolution to core issue 259, no normative changes
   in the library clauses are necessary.  Add the following non-normative
-  note to the end of 17.4.3.1 [reserved.names] paragraph 1:
        
+  note to the end of 17.4.3.2 [reserved.names] paragraph 1:
        
   
        
     [Note: A program may explicitly instantiate standard library
     templates, even when an explicit instantiation does not depend on
@@ -5226,7 +5307,7 @@ Redmond:  formally voted into WP.
 
 
        
 
        132. list::resize description uses random access iterators
        
-
        Section: 23.2.3.2 [list.capacity] Status: TC
+
        Section: 23.2.4.2 [list.capacity] Status: TC
  Submitter: Howard Hinnant Date: 1999-03-06
        
 
        View all issues with TC status.
        
 
        Discussion:
        
@@ -5245,7 +5326,7 @@ Redmond:  formally voted into WP.
 
 
 
        Proposed resolution:
        
-
        Change 23.2.3.2 [list.capacity] paragraph 1 to:
        
+
        Change 23.2.4.2 [list.capacity] paragraph 1 to:
        
 
 
        Effects:
        
 
@@ -5286,7 +5367,7 @@ after operator= in the map declaration:
        
 
 
        
 
        134. vector constructors over specified
        
-
        Section: 23.2.5.1 [vector.cons] Status: TC
+
        Section: 23.2.6.1 [vector.cons] Status: TC
  Submitter: Howard Hinnant Date: 1999-03-06
        
 
        View all issues with TC status.
        
 
        Discussion:
        
@@ -5298,7 +5379,7 @@ tradeoff for the implementor.
        
 
 
 
        Proposed resolution:
        
-
        Change 23.2.5.1 [vector.cons], paragraph 1 to:
        
+
        Change 23.2.6.1 [vector.cons], paragraph 1 to:
        
 
 
        -1- Complexity: The constructor template <class
 InputIterator> vector(InputIterator first, InputIterator last)
@@ -6085,7 +6166,6 @@ is the correct spelling.]
        
 
        161. Typo: istream_iterator vs. istreambuf_iterator
        
 
        Section: 27.6.1.2.2 [istream.formatted.arithmetic] Status: TC
  Submitter: Dietmar Kühl Date: 1999-07-20
        
-
        View other active issues in [istream.formatted.arithmetic].
        
 
        View all other issues in [istream.formatted.arithmetic].
        
 
        View all issues with TC status.
        
 
        Discussion:
        
@@ -6311,7 +6391,6 @@ sentences, change the word "formatted" to
 
        169. Bad efficiency of overflow() mandated
        
 
        Section: 27.7.1.4 [stringbuf.virtuals] Status: TC
  Submitter: Dietmar Kühl Date: 1999-07-20
        
-
        View other active issues in [stringbuf.virtuals].
        
 
        View all other issues in [stringbuf.virtuals].
        
 
        View all issues with TC status.
        
 
        Discussion:
        
@@ -6758,7 +6837,7 @@ proposed resolution passed their test suites.
        
 
        Discussion:
        
 
        Many references to  size_t throughout the document
 omit the  std:: namespace qualification.
         
        For
-example, 17.4.3.4 [replacement.functions] paragraph 2:
        
+example, 17.4.3.5 [replacement.functions] paragraph 2:
        
 
        
 
         operator new(size_t)
  operator new(size_t, const std::nothrow_t&)
@@ -6768,7 +6847,7 @@ example, 17.4.3.4 [replacement.functions] paragraph 2:
        
 
 
 
        Proposed resolution:
        
-
           In 17.4.3.4 [replacement.functions] paragraph 2: replace:
        
+
           In 17.4.3.5 [replacement.functions] paragraph 2: replace:
        
 
        
 
             - operator new(size_t)
        
      - operator new(size_t, const std::nothrow_t&)
        
@@ -6845,7 +6924,7 @@ declaration of template <class charT> class ctype.
        
 
        The LWG believes correcting names like size_t and
 ptrdiff_t to std::size_t and std::ptrdiff_t
 to be essentially editorial.  There there can't be another size_t or
-ptrdiff_t meant anyway because, according to 17.4.3.1.4 [extern.types],
        
+ptrdiff_t meant anyway because, according to 17.4.3.2.4 [extern.types],
        
 
 
        
 For each type T from the Standard C library, the types ::T and std::T
@@ -7700,7 +7779,7 @@ otherwise const U&".
 
        [Tokyo: The LWG believes this is the tip of a larger iceberg;
 there are multiple const problems with the STL portion of the library
 and that these should be addressed as a single package.  Note
-that issue 180 has already been declared NAD Future for
+that issue 180 has already been declared NAD Future for
 that very reason.]
        
 
 
@@ -8382,6 +8461,7 @@ is.setstate(ios::failbit) which may throw ios_base::failure
 
        212. Empty range behavior unclear for several algorithms
        
 
        Section: 25.3.7 [alg.min.max] Status: TC
  Submitter: Nico Josuttis Date: 2000-02-26
        
+
        View other active issues in [alg.min.max].
        
 
        View all other issues in [alg.min.max].
        
 
        View all issues with TC status.
        
 
        Discussion:
        
@@ -8839,7 +8919,7 @@ resolution for this issue is in accordance with Howard's paper.]
        
 
 
        
 
        226. User supplied specializations or overloads of namespace std function templates
        
-
        Section: 17.4.3.1 [reserved.names] Status: WP
+
        Section: 17.4.3.2 [reserved.names] Status: WP
  Submitter: Dave Abrahams Date: 2000-04-01
        
 
        View all other issues in [reserved.names].
        
 
        View all issues with WP status.
        
@@ -9452,7 +9532,7 @@ where precision is 0 and mode is %g.]
        
 
 
        
 
        232. "depends" poorly defined in 17.4.3.1
        
-
        Section: 17.4.3.1 [reserved.names] Status: WP
+
        Section: 17.4.3.2 [reserved.names] Status: WP
  Submitter: Peter Dimov Date: 2000-04-18
        
 
        View all other issues in [reserved.names].
        
 
        View all issues with WP status.
        
@@ -9557,10 +9637,10 @@ adjacent to the insertion point.]
        
 
 
        [Copenhagen: the LWG agreed to the original proposed resolution,
 in which an insertion hint would be used even when it is far from the
-insertion point.  This was contingent on seeing a reference
+insertion point.  This was contingent on seeing a example
 implementation showing that it is possible to implement this
 requirement without loss of efficiency.  John Potter provided such a
-reference implementation.]
        
+example implementation.]
        
 
 
 
        [Redmond: The LWG was reluctant to adopt the proposal that
@@ -9656,7 +9736,7 @@ logarithmic in general, but amortized constant if t is inserted right <
 
 
        
 
        234. Typos in allocator definition
        
-
        Section: 20.6.1.1 [allocator.members] Status: WP
+
        Section: 20.6.5.1 [allocator.members] Status: WP
  Submitter: Dietmar Kühl Date: 2000-04-24
        
 
        View all other issues in [allocator.members].
        
 
        View all issues with WP status.
        
@@ -10184,12 +10264,12 @@ Jerry Schwarz's message c++std-lib-7618.
        
 
 
        
 
        247. vector, deque::insert complexity
        
-
        Section: 23.2.5.4 [vector.modifiers] Status: WP
+
        Section: 23.2.6.4 [vector.modifiers] Status: WP
  Submitter: Lisa Lippincott Date: 2000-06-06
        
 
        View all other issues in [vector.modifiers].
        
 
        View all issues with WP status.
        
 
        Discussion:
        
-
        Paragraph 2 of 23.2.5.4 [vector.modifiers] describes the complexity
+
        Paragraph 2 of 23.2.6.4 [vector.modifiers] describes the complexity
 of vector::insert:
        
 
    
        
@@ -10226,7 +10306,7 @@ paragraph 3):
        
 
 
        Proposed resolution:
        
 
-
        Change Paragraph 2 of 23.2.5.4 [vector.modifiers] to
        
+
        Change Paragraph 2 of 23.2.6.4 [vector.modifiers] to
        
    
        
    Complexity: The complexity is linear in the number of elements 
    inserted plus the distance to the end of the vector.
@@ -10292,13 +10372,13 @@ input facets.
        
 
 
        
 
        250. splicing invalidates iterators
        
-
        Section: 23.2.3.4 [list.ops] Status: WP
+
        Section: 23.2.4.4 [list.ops] Status: WP
  Submitter: Brian Parker  Date: 2000-07-14
        
 
        View all other issues in [list.ops].
        
 
        View all issues with WP status.
        
 
        Discussion:
        
 
        
-Section 23.2.3.4 [list.ops] states that
+Section 23.2.4.4 [list.ops] states that
 
        
 
          void splice(iterator position, list<T, Allocator>& x);
 
        
@@ -10315,14 +10395,14 @@ after splice.
 
 
        Proposed resolution:
        
 
-
        Add a footnote to 23.2.3.4 [list.ops], paragraph 1:
        
+
        Add a footnote to 23.2.4.4 [list.ops], paragraph 1:
        
 
        
 [Footnote: As specified in  [default.con.req], paragraphs
 4-5, the semantics described in this clause applies only to the case
 where allocators compare equal.  --end footnote]
 
        
 
-
        In 23.2.3.4 [list.ops], replace paragraph 4 with:
        
+
        In 23.2.4.4 [list.ops], replace paragraph 4 with:
        
 
        
 Effects: Inserts the contents of x before position and x becomes 
 empty.  Pointers and references to the moved elements of x now refer to 
@@ -10331,7 +10411,7 @@ moved elements will continue to refer to their elements, but they now
 behave as iterators into *this, not into x.
 
        
 
-
        In 23.2.3.4 [list.ops], replace paragraph 7 with:
        
+
        In 23.2.4.4 [list.ops], replace paragraph 7 with:
        
 
        
 Effects: Inserts an element pointed to by i from list x before 
 position and removes the element from x. The result is unchanged if 
@@ -10341,7 +10421,7 @@ to refer to this same element but as a member of *this.  Iterators to *i
 behave as iterators into *this, not into x.
 
        
 
-
        In 23.2.3.4 [list.ops], replace paragraph 12 with:
        
+
        In 23.2.4.4 [list.ops], replace paragraph 12 with:
        
 
        
 Requires: [first, last) is a valid range in x. The result is 
 undefined if position is an iterator in the range [first, last).  
@@ -10439,7 +10519,6 @@ issue is stylistic rather than a matter of correctness.
        
 
        253. valarray helper functions are almost entirely useless
        
 
        Section: 26.5.2.1 [valarray.cons], 26.5.2.2 [valarray.assign] Status: WP
  Submitter: Robert Klarer Date: 2000-07-31
        
-
        View other active issues in [valarray.cons].
        
 
        View all other issues in [valarray.cons].
        
 
        View all issues with WP status.
        
 
        Discussion:
        
@@ -11043,6 +11122,7 @@ the need to explicit include or construct a std::string.
 
        256. typo in 27.4.4.2, p17: copy_event does not exist
        
 
        Section: 27.4.4.2 [basic.ios.members] Status: WP
  Submitter: Martin Sebor Date: 2000-08-21
        
+
        View other active issues in [basic.ios.members].
        
 
        View all other issues in [basic.ios.members].
        
 
        View all issues with WP status.
        
 
        Discussion:
        
@@ -12193,13 +12273,13 @@ implement vector::push_back in terms of
 
 
        
 
        278. What does iterator validity mean?
        
-
        Section: 23.2.3.4 [list.ops] Status: WP
+
        Section: 23.2.4.4 [list.ops] Status: WP
  Submitter: P.J. Plauger Date: 2000-11-27
        
 
        View all other issues in [list.ops].
        
 
        View all issues with WP status.
        
 
        Discussion:
        
 
        
-Section 23.2.3.4 [list.ops] states that
+Section 23.2.4.4 [list.ops] states that
 
        
 
          void splice(iterator position, list<T, Allocator>& x);
 
        
@@ -12345,6 +12425,7 @@ this solution is safe and correct.
 
        281. std::min() and max() requirements overly restrictive
        
 
        Section: 25.3.7 [alg.min.max] Status: WP
  Submitter: Martin Sebor Date: 2000-12-02
        
+
        View other active issues in [alg.min.max].
        
 
        View all other issues in [alg.min.max].
        
 
        View all issues with WP status.
        
 
        Duplicate of: 486
        
@@ -12855,6 +12936,7 @@ m         of these elements from [first2, last2) if m < n.
 
        292. effects of a.copyfmt (a)
        
 
        Section: 27.4.4.2 [basic.ios.members] Status: WP
  Submitter: Martin Sebor Date: 2001-01-05
        
+
        View other active issues in [basic.ios.members].
        
 
        View all other issues in [basic.ios.members].
        
 
        View all issues with WP status.
        
 
        Discussion:
        
@@ -12892,11 +12974,11 @@ objects of rhs, except that...
 
 
        
 
        294. User defined macros and standard headers
        
-
        Section: 17.4.3.1.1 [macro.names] Status: WP
+
        Section: 17.4.3.2.1 [macro.names] Status: WP
  Submitter: James Kanze Date: 2001-01-11
        
 
        View all issues with WP status.
        
 
        Discussion:
        
-
        Paragraph 2 of 17.4.3.1.1 [macro.names] reads: "A
+
        Paragraph 2 of 17.4.3.2.1 [macro.names] reads: "A
 translation unit that includes a header shall not contain any macros
 that define names declared in that header." As I read this, it
 would mean that the following program is legal:
        
@@ -12917,7 +12999,7 @@ it isn't stringent enough.
        
 
 
 
        Proposed resolution:
        
-
        For 17.4.3.1.1 [macro.names], replace the current wording, which reads:
        
+
        For 17.4.3.2.1 [macro.names], replace the current wording, which reads:
        
 
        
      
        Each name defined as a macro in a header is reserved to the
      implementation for any use if the translation unit includes
@@ -13101,7 +13183,7 @@ For a null value of ptr , does nothing.
 Any other value of ptr shall be a value returned
 earlier by a call to the default operator new[](std::size_t).
 [Footnote: The value must not have been invalidated by an intervening
-call to operator delete[](void*) (17.4.3.7 [res.on.arguments]).
+call to operator delete[](void*) (17.4.3.8 [res.on.arguments]).
 --- end footnote]
 For such a non-null value of ptr , reclaims storage
 allocated by the earlier call to the default operator new[].
@@ -13123,13 +13205,13 @@ or operator delete(ptr, std::nothrow) respectively.
 
 
        
 
        300. list::merge() specification incomplete
        
-
        Section: 23.2.3.4 [list.ops] Status: WP
+
        Section: 23.2.4.4 [list.ops] Status: WP
  Submitter: John Pedretti Date: 2001-01-23
        
 
        View all other issues in [list.ops].
        
 
        View all issues with WP status.
        
 
        Discussion:
        
 
        
-The "Effects" clause for list::merge() (23.2.3.4 [list.ops], p23)
+The "Effects" clause for list::merge() (23.2.4.4 [list.ops], p23)
 appears to be incomplete: it doesn't cover the case where the argument
 list is identical to *this (i.e., this == &x). The requirement in the
 note in p24 (below) is that x be empty after the merge which is surely
@@ -13138,7 +13220,7 @@ unintended in this case.
 
 
 
        Proposed resolution:
        
-
        In 23.2.3.4 [list.ops], replace paragraps 23-25 with:
        
+
        In 23.2.4.4 [list.ops], replace paragraps 23-25 with:
        
 
        
 
        
 23 Effects: if (&x == this) does nothing; otherwise, merges the two
@@ -13167,7 +13249,7 @@ effects.
 
        
 
 
        [Copenhagen: The original proposed resolution did not fix all of
-the problems in 23.2.3.4 [list.ops], p22-25.  Three different
+the problems in 23.2.4.4 [list.ops], p22-25.  Three different
 paragraphs (23, 24, 25) describe the effects of merge.
 Changing p23, without changing the other two, appears to introduce
 contradictions.  Additionally, "merges the argument list into the
@@ -13507,7 +13589,7 @@ possible.]
        
 
 
        
 
        307. Lack of reference typedefs in container adaptors
        
-
        Section: 23.2.3 [list] Status: WP
+
        Section: 23.2.4 [list] Status: WP
  Submitter: Howard Hinnant Date: 2001-03-13
        
 
        View all issues with WP status.
        
 
        Discussion:
        
@@ -13515,8 +13597,8 @@ possible.]
        
 
        From reflector message c++std-lib-8330.  See also lib-8317.
        
 
 
        
-The standard is currently inconsistent in 23.2.3.2 [list.capacity]
-paragraph 1 and 23.2.3.3 [list.modifiers] paragraph 1.
+The standard is currently inconsistent in 23.2.4.2 [list.capacity]
+paragraph 1 and 23.2.4.3 [list.modifiers] paragraph 1.
 23.2.3.3/1, for example, says:
 
        
 
@@ -13975,13 +14057,13 @@ as <memory>.
        
 
 
        
 
        315. Bad "range" in list::unique complexity
        
-
        Section: 23.2.3.4 [list.ops] Status: WP
+
        Section: 23.2.4.4 [list.ops] Status: WP
  Submitter: Andy Sawyer Date: 2001-05-01
        
 
        View all other issues in [list.ops].
        
 
        View all issues with WP status.
        
 
        Discussion:
        
 
        
-23.2.3.4 [list.ops], Para 21 describes the complexity of
+23.2.4.4 [list.ops], Para 21 describes the complexity of
 list::unique as: "If the range (last - first) is not empty, exactly
 (last - first) -1 applications of the corresponding predicate,
 otherwise no applications of the predicate)".
@@ -14176,13 +14258,13 @@ should be specified as "Requires".
        
 
 
        
 
        320. list::assign overspecified
        
-
        Section: 23.2.3.1 [list.cons] Status: WP
+
        Section: 23.2.4.1 [list.cons] Status: WP
  Submitter: Howard Hinnant Date: 2001-05-17
        
 
        View all other issues in [list.cons].
        
 
        View all issues with WP status.
        
 
        Discussion:
        
 
        
-Section 23.2.3.1 [list.cons], paragraphs 6-8 specify that list assign (both forms) have
+Section 23.2.4.1 [list.cons], paragraphs 6-8 specify that list assign (both forms) have
 the "effects" of a call to erase followed by a call to insert.
 
        
 
@@ -14208,7 +14290,7 @@ Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't.
 
 
 
        Proposed resolution:
        
-
        Change 23.2.3.1 [list.cons]/7 from:
        
+
        Change 23.2.4.1 [list.cons]/7 from:
        
 
 
        
 
        Effects:
        
@@ -14235,7 +14317,7 @@ add two new rows:
        
                                   of t.
 
        
 
-
        Change 23.2.3.1 [list.cons]/8 from:
        
+
        Change 23.2.4.1 [list.cons]/8 from:
        
 
 
        
 
        Effects:
        
@@ -14608,18 +14690,18 @@ modifier.
        
 
 
        
 
        329. vector capacity, reserve and reallocation
        
-
        Section: 23.2.5.2 [vector.capacity], 23.2.5.4 [vector.modifiers] Status: WP
+
        Section: 23.2.6.2 [vector.capacity], 23.2.6.4 [vector.modifiers] Status: WP
  Submitter: Anthony Williams Date: 2001-07-13
        
 
        View all other issues in [vector.capacity].
        
 
        View all issues with WP status.
        
 
        Discussion:
        
 
        
 There is an apparent contradiction about which circumstances can cause
-a reallocation of a vector in Section 23.2.5.2 [vector.capacity] and
-section 23.2.5.4 [vector.modifiers].
+a reallocation of a vector in Section 23.2.6.2 [vector.capacity] and
+section 23.2.6.4 [vector.modifiers].
 
        
 
-
        23.2.5.2 [vector.capacity],p5 says:
        
+
        23.2.6.2 [vector.capacity],p5 says:
        
 
        
 Notes: Reallocation invalidates all the references, pointers, and iterators
 referring to the elements in the sequence. It is guaranteed that no
@@ -14639,7 +14721,7 @@ greater than the size specified in the most recent call to reserve().
 
        then the implementation may reallocate the vector for the insert,
 as the size specified in the previous call to reserve was zero.
        
 
-
        However, the previous paragraphs (23.2.5.2 [vector.capacity], p1-2) state:
        
+
        However, the previous paragraphs (23.2.6.2 [vector.capacity], p1-2) state:
        
 
        
 
        
 (capacity) Returns: The total number of elements the vector
@@ -14655,7 +14737,7 @@ of capacity() otherwise...
 
        
 This implies that vec.capacity() is still 23, and so the insert()
 should not require a reallocation, as vec.size() is 0. This is backed
-up by 23.2.5.4 [vector.modifiers], p1:
+up by 23.2.6.4 [vector.modifiers], p1:
 
        
 
        
 (insert) Notes: Causes reallocation if the new size is greater than the old
@@ -14670,7 +14752,7 @@ than the old capacity, I think the intent is clear.
 
 
 
        Proposed resolution:
        
-
        Change the wording of 23.2.5.2 [vector.capacity] paragraph 5 to:
        
+
        Change the wording of 23.2.6.2 [vector.capacity] paragraph 5 to:
        
 
 
        
 Notes: Reallocation invalidates all the references, pointers, and
@@ -15009,7 +15091,7 @@ library (though a deprecated one).
        
 
      43. 17.3.2.3 [objects.within.classes] Private members/1/(2 places)
        44. 
 
      44. 17.4 [requirements] Library-wide requirements/1
        45. 
 
      45. 17.4.1.2 [headers] Headers/4
        46. 
-
      46. 17.4.3.4 [replacement.functions] Replacement functions/1
        47. 
+
      47. 17.4.3.5 [replacement.functions] Replacement functions/1
        48. 
 
      48. 17.4.4.3 [global.functions] Global or non-member functions/2
        49. 
 
      49. 17.4.4.6 [protection.within.classes] Protection within classes/1
        50. 
 
@@ -15268,7 +15350,7 @@ complete list of the ones we need.
        
 
 
        
 
        341. Vector reallocation and swap
        
-
        Section: 23.2.5.2 [vector.capacity] Status: WP
+
        Section: 23.2.6.2 [vector.capacity] Status: WP
  Submitter: Anthony Williams Date: 2001-09-27
        
 
        View all other issues in [vector.capacity].
        
 
        View all issues with WP status.
        
@@ -15281,7 +15363,7 @@ an empty one:
        
   // vec is now empty, with minimal capacity
 
      
 
-
      However, the wording of 23.2.5.2 [vector.capacity]paragraph 5 prevents
+
      However, the wording of 23.2.6.2 [vector.capacity]paragraph 5 prevents
 the capacity of a vector being reduced, following a call to
 reserve(). This invalidates the idiom, as swap() is thus prevented
 from reducing the capacity. The proposed wording for issue 329 does not affect this.  Consequently, the example above
@@ -15314,7 +15396,7 @@ referred to one vector now refer to the other, and vice-versa.
      2. 
 
 
 
      Proposed resolution:
      
-
      Add a new paragraph after 23.2.5.2 [vector.capacity] paragraph 5:
      
+
      Add a new paragraph after 23.2.6.2 [vector.capacity] paragraph 5:
      
 
      
 
        void swap(vector<T,Allocator>& x);
 
      
@@ -16435,7 +16517,6 @@ In 27.6.1.2.1 [istream.formatted.reqmts] and 27.6.2.6.1 [ostream.formatted.reqmt
 
      375. basic_ios should be ios_base in 27.7.1.3
      
 
      Section: 27.7.1.4 [stringbuf.virtuals] Status: WP
  Submitter: Ray Lischner Date: 2002-08-14
      
-
      View other active issues in [stringbuf.virtuals].
      
 
      View all other issues in [stringbuf.virtuals].
      
 
      View all issues with WP status.
      
 
      Discussion:
      
@@ -16462,7 +16543,6 @@ paragraph 14 to "ios_base".
 
      376. basic_streambuf semantics
      
 
      Section: 27.7.1.4 [stringbuf.virtuals] Status: WP
  Submitter: Ray Lischner Date: 2002-08-14
      
-
      View other active issues in [stringbuf.virtuals].
      
 
      View all other issues in [stringbuf.virtuals].
      
 
      View all issues with WP status.
      
 
      Discussion:
      
@@ -17025,13 +17105,13 @@ implementation is permitted to use rand.]
 
 
      
 
      400. redundant type cast in lib.allocator.members
      
-
      Section: 20.6.1.1 [allocator.members] Status: WP
+
      Section: 20.6.5.1 [allocator.members] Status: WP
  Submitter: Markus Mauhart Date: 2003-02-27
      
 
      View all other issues in [allocator.members].
      
 
      View all issues with WP status.
      
 
      Discussion:
      
 
      
-20.6.1.1 [allocator.members] allocator members, contains
+20.6.5.1 [allocator.members] allocator members, contains
 the following 3 lines:
 
      
 
@@ -17143,7 +17223,7 @@ 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
+
      Section: 20.1.2 [allocator.requirements], 20.6.5.1 [allocator.members] Status: WP
  Submitter: Markus Mauhart Date: 2003-02-27
      
 
      View other active issues in [allocator.requirements].
      
 
      View all other issues in [allocator.requirements].
      
@@ -17151,13 +17231,13 @@ issue to Ready status to be voted into the WP at Kona.
 
      Discussion:
      
 
      
 This applies to the new expression that is contained in both par12 of
-20.6.1.1 [allocator.members] and in par2 (table 32) of  [default.con.req].
+20.6.5.1 [allocator.members] and in par2 (table 32) of  [default.con.req].
 I think this new expression is wrong, involving unintended side
 effects.
 
      
 
 
-
      20.6.1.1 [allocator.members]  contains the following 3 lines:
      
+
      20.6.5.1 [allocator.members]  contains the following 3 lines:
      
 
 
        11 Returns: the largest value N for which the call allocate(N,0) might succeed.
      void construct(pointer p, const_reference val);
@@ -17278,7 +17358,7 @@ Throws: Shall not throw exceptions.
 
 
      
 
      404. May a replacement allocation function be declared inline?
      
-
      Section: 17.4.3.4 [replacement.functions], 18.5.1 [new.delete] Status: WP
+
      Section: 17.4.3.5 [replacement.functions], 18.5.1 [new.delete] Status: WP
  Submitter: Matt Austern Date: 2003-04-24
      
 
      View all issues with WP status.
      
 
      Discussion:
      
@@ -17292,7 +17372,7 @@ in preference to the implementation's definition.
 
 
      
 Three different parts of the standard mention requirements on
-replacement functions: 17.4.3.4 [replacement.functions], 18.5.1.1 [new.delete.single]
+replacement functions: 17.4.3.5 [replacement.functions], 18.5.1.1 [new.delete.single]
 and 18.5.1.2 [new.delete.array], and 3.7.2 [basic.stc.auto].
 
      
 
@@ -17310,7 +17390,7 @@ and 18.5.1.2 [new.delete.array], and 3.7.2 [basic.stc.auto].
 
 
      Proposed resolution:
      
 
      
-Add a new sentence to the end of 17.4.3.4 [replacement.functions] paragraph 3:
+Add a new sentence to the end of 17.4.3.5 [replacement.functions] paragraph 3:
 "The program's definitions shall not be specified as inline.
 No diagnostic is required."
 
      
@@ -17367,7 +17447,7 @@ type."
 
 
      
 
      406. vector::insert(s) exception safety
      
-
      Section: 23.2.5.4 [vector.modifiers] Status: DR
+
      Section: 23.2.6.4 [vector.modifiers] Status: DR
  Submitter: Dave Abrahams Date: 2003-04-27
      
 
      View all other issues in [vector.modifiers].
      
 
      View all issues with DR status.
      
@@ -17384,7 +17464,7 @@ existing implementation.
 
 
 
      Proposed resolution:
      
-
      Replace 23.2.5.4 [vector.modifiers] paragraph 1 with:
      
+
      Replace 23.2.6.4 [vector.modifiers] paragraph 1 with:
      
 
      
   1- Notes: Causes reallocation if the new size is greater than the
   old capacity. If no reallocation happens, all the iterators and
@@ -17522,22 +17602,22 @@ flags.]
      
 
 
      
 
      410. Missing semantics for stack and queue comparison operators
      
-
      Section: 23.2.3.1 [list.cons], 23.2.3.3 [list.modifiers] Status: WP
+
      Section: 23.2.4.1 [list.cons], 23.2.4.3 [list.modifiers] Status: WP
  Submitter: Hans Bos Date: 2003-06-07
      
 
      View all other issues in [list.cons].
      
 
      View all issues with WP status.
      
 
      Discussion:
      
 
      
-Sections 23.2.3.1 [list.cons] and 23.2.3.3 [list.modifiers] list
+Sections 23.2.4.1 [list.cons] and 23.2.4.3 [list.modifiers] list
 comparison operators (==, !=, <, <=, >, =>) for queue and
-stack.  Only the semantics for queue::operator== (23.2.3.1 [list.cons] par2) and queue::operator< (23.2.3.1 [list.cons]
+stack.  Only the semantics for queue::operator== (23.2.4.1 [list.cons] par2) and queue::operator< (23.2.4.1 [list.cons]
 par3) are defined.
 
      
 
 
 
      Proposed resolution:
      
 
-
      Add the following new paragraphs after 23.2.3.1 [list.cons]
+
      Add the following new paragraphs after 23.2.4.1 [list.cons]
   paragraph 3:
      
 
 
      
@@ -17560,7 +17640,7 @@ par3) are defined.
 
 
      
 
-
      Add the following paragraphs at the end of 23.2.3.3 [list.modifiers]:
      
+
      Add the following paragraphs at the end of 23.2.4.3 [list.modifiers]:
      
 
 
      
 
@@ -17728,7 +17808,7 @@ then the caught exception is rethrown.
 
 
      
 
      414. Which iterators are invalidated by v.erase()?
      
-
      Section: 23.2.5.4 [vector.modifiers] Status: WP
+
      Section: 23.2.6.4 [vector.modifiers] Status: WP
  Submitter: Matt Austern Date: 2003-08-19
      
 
      View all other issues in [vector.modifiers].
      
 
      View all issues with WP status.
      
@@ -17783,7 +17863,7 @@ techniques.)
 
 
      Proposed resolution:
      
 
      
-In 23.2.5.4 [vector.modifiers] paragraph 3, change "Invalidates all the
+In 23.2.6.4 [vector.modifiers] paragraph 3, change "Invalidates all the
 iterators and references after the point of the erase" to
 "Invalidates iterators and references at or after the point of the
 erase". 
@@ -17946,7 +18026,7 @@ allowed to just declare it without providing a full definition?
 
 
      
 
      422. explicit specializations of member functions of class templates
      
-
      Section: 17.4.3.1 [reserved.names] Status: WP
+
      Section: 17.4.3.2 [reserved.names] Status: WP
  Submitter: Martin Sebor Date: 2003-09-18
      
 
      View all other issues in [reserved.names].
      
 
      View all issues with WP status.
      
@@ -17966,7 +18046,7 @@ the program) by relying on the "as if" rule.
 
      Proposed resolution:
      
 
 
      
-  Add the following sentence to 17.4.3.1 [reserved.names], p1:
+  Add the following sentence to 17.4.3.2 [reserved.names], p1:
 
      
 
 
      
@@ -18014,7 +18094,7 @@ use the right wording.]
      
 
 
      
 
      425. return value of std::get_temporary_buffer
      
-
      Section: 20.6.3 [temporary.buffer] Status: WP
+
      Section: 20.6.8 [temporary.buffer] Status: WP
  Submitter: Martin Sebor Date: 2003-09-18
      
 
      View all issues with WP status.
      
 
      Discussion:
      
@@ -18160,7 +18240,6 @@ which is most likely not the intent.
 
      432. stringbuf::overflow() makes only one write position available
      
 
      Section: 27.7.1.4 [stringbuf.virtuals] Status: WP
  Submitter: Christian W Brock Date: 2003-09-24
      
-
      View other active issues in [stringbuf.virtuals].
      
 
      View all other issues in [stringbuf.virtuals].
      
 
      View all issues with WP status.
      
 
      Discussion:
      
@@ -19303,7 +19382,6 @@ undefined."
 
      453. basic_stringbuf::seekoff need not always fail for an empty stream
      
 
      Section: 27.7.1.4 [stringbuf.virtuals] Status: WP
  Submitter: Bill Plauger Date: 2004-01-30
      
-
      View other active issues in [stringbuf.virtuals].
      
 
      View all other issues in [stringbuf.virtuals].
      
 
      View all issues with WP status.
      
 
      Discussion:
      
@@ -19529,6 +19607,7 @@ names within the namespace std. -- end example]
 
      457. bitset constructor: incorrect number of initialized bits
      
 
      Section: 23.3.5.1 [bitset.cons] Status: DR
  Submitter: Dag Henriksson Date: 2004-01-30
      
+
      View other active issues in [bitset.cons].
      
 
      View all other issues in [bitset.cons].
      
 
      View all issues with DR status.
      
 
      Discussion:
      
@@ -19703,7 +19782,7 @@ An implementation may also accept additional implementation-defined formats.
 
 
      
 
      464. Suggestion for new member functions in standard containers
      
-
      Section: 23.2.5 [vector], 23.3.1 [map] Status: WP
+
      Section: 23.2.6 [vector], 23.3.1 [map] Status: WP
  Submitter: Thorsten Ottosen Date: 2004-05-12
      
 
      View all other issues in [vector].
      
 
      View all issues with WP status.
      
@@ -19733,14 +19812,14 @@ at() (which will then throw if the vector is empty). 
 
 
 
      Proposed resolution:
      
-
      In 23.2.5 [vector], add the following to the vector
+
      In 23.2.6 [vector], add the following to the vector
   synopsis after "element access" and before "modifiers":
      
 
        // [lib.vector.data] data access
   pointer       data();
   const_pointer data() const;
 
      
 
-
      Add a new subsection of 23.2.5 [vector]:
      
+
      Add a new subsection of 23.2.6 [vector]:
      
 
      
 
      23.2.4.x vector data access
      
 
         pointer       data();
@@ -19954,7 +20033,7 @@ the value need not be valid.
 
 
      
 
      469. vector<bool> ill-formed relational operators
      
-
      Section: 23.2.5 [vector] Status: DR
+
      Section: 23.2.6 [vector] Status: DR
  Submitter: Martin Sebor Date: 2004-06-28
      
 
      View all other issues in [vector].
      
 
      View all issues with DR status.
      
@@ -20321,13 +20400,13 @@ requirements of charT (described in 21 [strings]).
 
 
      
 
      496. Illegal use of "T" in vector<bool>
      
-
      Section: 23.2.5 [vector] Status: WP
+
      Section: 23.2.6 [vector] Status: WP
  Submitter: richard@ex-parrot.com Date: 2005-02-10
      
 
      View all other issues in [vector].
      
 
      View all issues with WP status.
      
 
      Discussion:
      
 
      
-In the synopsis of the std::vector<bool> specialisation in 23.2.5 [vector],
+In the synopsis of the std::vector<bool> specialisation in 23.2.6 [vector],
 the non-template assign() function has the signature
      
 
 
        void assign( size_type n, const T& t );
@@ -20493,6 +20572,7 @@ Precondition:  distribution().operator()(e,value) is well-formed.
 
      508. Bad parameters for ranlux64_base_01
      
 
      Section: 26.4.5 [rand.predef], TR1 5.1.5 [tr.rand.predef] Status: WP
  Submitter: Walter Brown Date: 2005-07-03
      
+
      View all other issues in [rand.predef].
      
 
      View all issues with WP status.
      
 
      Discussion:
      
 
      
@@ -20799,6 +20879,98 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
 
+
      
+
      527. tr1::bind has lost its Throws clause
      
+
      Section: 20.5.11.1.3 [func.bind.bind], TR1 3.6.3 [tr.func.bind.bind] Status: WP
+ Submitter: Peter Dimov Date: 2005-10-01
      
+
      View other active issues in [func.bind.bind].
      
+
      View all other issues in [func.bind.bind].
      
+
      View all issues with WP 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.
+]
      
+
+
+
      [
+Toronto:  We agree but aren't quite happy with the wording.  The "t"'s no
+longer refer to anything.  Alan to provide improved wording.
+]
      
+
+
+
+
      [
+Pre-Bellevue:  Alisdair provided wording.
+]
      
+
+
+
      
+TR1 proposed resolution:
+
      
+
+
      
+
      
+In TR1 3.6.3 [tr.func.bind.bind], add a new paragraph after p2:
+
      
+
      
+Throws: Nothing unless one of the copy constructors of f, t1, t2, ..., tN
+throws an exception.
+
      
+
+
      
+Add a new paragraph after p4:
+
      
+
      
+Throws: nothing unless one of the copy constructors of f, t1, t2, ..., tN
+throws an exception.
+
      
+
+
      
+
+
+
+
      Proposed resolution:
      
+
      
+In 20.5.11.1.3 [func.bind.bind], add a new paragraph after p2:
+
      
+
+
      
+Throws: Nothing unless the copy constructor of F or of one of the types
+in the BoundArgs... pack expansion throws an exception. 
+
      
+
+
      
+In 20.5.11.1.3 [func.bind.bind], add a new paragraph after p4:
+
      
+
+
      
+Throws: Nothing unless the copy constructor of F or of one of the types
+in the BoundArgs... pack expansion throws an exception. 
+
      
+
+
+
+
+
+
 
      
 
      530. Must elements of a string be contiguous?
      
 
      Section: 21.3 [basic.string] Status: WP
@@ -20931,7 +21103,7 @@ 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.11 [util.smartptr.getdeleter], TR1 2.2.3.10 [tr.util.smartptr.getdeleter] Status: DR
+
      Section: 20.6.12.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.
      
@@ -21256,7 +21428,7 @@ Otherwise CopyConstructible is not required.
 
 
      
 
      540. shared_ptr<void>::operator*()
      
-
      Section: 20.6.6.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] Status: WP
+
      Section: 20.6.12.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] Status: WP
  Submitter: Martin Sebor Date: 2005-10-15
      
 
      View all other issues in [util.smartptr.shared.obs].
      
 
      View all issues with WP status.
      
@@ -21314,7 +21486,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
+
      Section: 20.6.12.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].
      
@@ -21395,7 +21567,7 @@ public:
 
 
      
 
      542. shared_ptr observers
      
-
      Section: 20.6.6.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] Status: WP
+
      Section: 20.6.12.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] Status: WP
  Submitter: Martin Sebor Date: 2005-10-18
      
 
      View all other issues in [util.smartptr.shared.obs].
      
 
      View all issues with WP status.
      
@@ -21435,7 +21607,7 @@ capture the intent.
 
 
      Proposed resolution:
      
 
      
-Change 20.6.6.2.5 [util.smartptr.shared.obs] p12:
+Change 20.6.12.2.5 [util.smartptr.shared.obs] p12:
 
      
 
      
 [Note: use_count() is not necessarily efficient. Use only for
@@ -21443,7 +21615,7 @@ debugging and testing purposes, not for production code. --end note
 
      
 
 
      
-Change 20.6.6.3.5 [util.smartptr.weak.obs] p3:
+Change 20.6.12.3.5 [util.smartptr.weak.obs] p3:
 
      
 
      
 [Note: use_count() is not necessarily efficient. Use only for
@@ -21532,7 +21704,7 @@ lengths, and strides, as explained in the previous section.
 
 
      
 
      545. When is a deleter deleted?
      
-
      Section: 20.6.6.2.11 [util.smartptr.getdeleter], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] Status: WP
+
      Section: 20.6.12.2.11 [util.smartptr.getdeleter], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] Status: WP
  Submitter: Matt Austern Date: 2006-01-10
      
 
      View all other issues in [util.smartptr.getdeleter].
      
 
      View all issues with WP status.
      
@@ -21550,7 +21722,7 @@ instances). We should say which it is.
 
 
      Proposed resolution:
      
 
      
-Add after the first sentence of 20.6.6.2.11 [util.smartptr.getdeleter]/1:
+Add after the first sentence of 20.6.12.2.11 [util.smartptr.getdeleter]/1:
 
      
 
      
 
      
@@ -21745,6 +21917,325 @@ automatically.
 
 
 
+
      
+
      561. inserter overly generic
      
+
      Section: 24.4.2.6.5 [inserter] Status: WP
+ Submitter: Howard Hinnant Date: 2006-02-21
      
+
      View all issues with WP status.
      
+
      Discussion:
      
+
      
+The declaration of std::inserter is:
+
      
+
+
      template <class Container, class Iterator>
+insert_iterator<Container>
+inserter(Container& x, Iterator i);
+
      
+
+
      
+The template parameter Iterator in this function is completely unrelated
+to the template parameter Container when it doesn't need to be.  This
+causes the code to be overly generic.  That is, any type at all can be deduced
+as Iterator, whether or not it makes sense.  Now the same is true of
+Container.  However, for every free (unconstrained) template parameter
+one has in a signature, the opportunity for a mistaken binding grows geometrically.
+
      
+
+
      
+It would be much better if inserter had the following signature instead:
+
      
+
+
      template <class Container>
+insert_iterator<Container>
+inserter(Container& x, typename Container::iterator i);
+
      
+
+
      
+Now there is only one free template parameter.  And the second argument to
+inserter must be implicitly convertible to the container's iterator,
+else the call will not be a viable overload (allowing other functions in the
+overload set to take precedence).  Furthermore, the first parameter must have a
+nested type named iterator, or again the binding to std::inserter
+is not viable.  Contrast this with the current situation
+where any type can bind to Container or Iterator and those
+types need not be anything closely related to containers or iterators.
+
      
+
+
      
+This can adversely impact well written code.  Consider:
+
      
+
+
      #include <iterator>
+#include <string>
+
+namespace my
+{
+
+template <class String>
+struct my_type {};
+
+struct my_container
+{
+template <class String>
+void push_back(const my_type<String>&);
+};
+
+template <class String>
+void inserter(const my_type<String>& m, my_container& c) {c.push_back(m);}
+
+}  // my
+
+int main()
+{
+    my::my_container c;
+    my::my_type<std::string> m;
+    inserter(m, c);
+}
+
      
+
+
      
+Today this code fails because the call to inserter binds to
+std::inserter instead of to my::inserter.  However with the
+proposed change std::inserter will no longer be a viable function which
+leaves only my::inserter in the overload resolution set.  Everything
+works as the client intends.
+
      
+
+
      
+To make matters a little more insidious, the above example works today if you
+simply change the first argument to an rvalue:
+
      
+
+
          inserter(my::my_type(), c);
+
      
+
+
      
+It will also work if instantiated with some string type other than
+std::string (or any other std type).  It will also work if
+<iterator> happens to not get included.
+
      
+
+
      
+And it will fail again for such inocuous reaons as my_type or
+my_container privately deriving from any std type.
+
      
+
+
      
+It seems unfortunate that such simple changes in the client's code can result
+in such radically differing behavior.
+
      
+
+
+
+
      Proposed resolution:
      
+
      
+Change 24.2:
+
      
+
+
      
+24.2 Header <iterator> synopsis
+
      
+
      ...
+template <class Container, class Iterator>
+   insert_iterator<Container> inserter(Container& x, Iterator typename Container::iterator i);
+...
+
      
+
      
+
+
      
+Change 24.4.2.5:
+
      
+
+
      
+24.4.2.5 Class template insert_iterator
      
+
      ...
+template <class Container, class Iterator>
+   insert_iterator<Container> inserter(Container& x, Iterator typename Container::iterator i);
+...
+
      
+
      
+
+
      
+Change 24.4.2.6.5:
+
      
+
+
      
+
      
+24.4.2.6.5 inserter
+
      
+
      template <class Container, class Inserter>
+   insert_iterator<Container> inserter(Container& x, Inserter typename Container::iterator i);
+
      
+
      
+-1- Returns: insert_iterator<Container>(x,typename Container::iterator(i)).
+
      
+
      
+
+
+
+
      [
+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: WP
+ Submitter: Martin Sebor Date: 2006-02-23
      
+
      View all other issues in [string.streams].
      
+
      View all issues with WP status.
      
+
      Discussion:
      
+        
      
+
+For  better efficiency,  the requirement  on the  stringbuf  ctor that
+takes  a  string  argument  should  be  loosened  up  to  let  it  set
+epptr()  beyond  just   one  past  the  last  initialized
+character  just like  overflow() has  been changed  to be
+allowed  to  do   (see  issue  432).  That  way   the  first  call  to
+sputc() on  an object won't  necessarily cause a  call to
+overflow. The corresponding change  should be made to the
+string overload of the str() member function.
+
+        
      
+
+
+
      Proposed resolution:
      
+        
      
+
+Change 27.7.1.1, p3 of the Working Draft, N1804, as follows:
+
+        
      
+
+
      explicit basic_stringbuf(const basic_string<charT,traits,Allocator>& str,
+               ios_base::openmode which = ios_base::in | ios_base::out);
+
      
+
+
      
+-3- Effects:  Constructs an object of class basic_stringbuf,
+initializing the base class with basic_streambuf()
+(27.5.2.1), and initializing mode with which.
+Then calls str(s). copies the content of
+str into the basic_stringbuf underlying character
+sequence. If which & ios_base::out is true, initializes the
+output sequence such that pbase() points to the first underlying
+character, epptr() points one past the last underlying character, and
+pptr() is equal to epptr() if which & ios_base::ate
+is true, otherwise pptr() is equal to pbase(). If
+which & ios_base::in is true, initializes the input sequence such
+that eback() and gptr() point to the first underlying 
+character and egptr() points one past the last underlying character.
+
      
+
      
+
+        
      
+
+Change the Effects clause of the str() in 27.7.1.2, p2 to
+read:
+
+        
      
+
      
+
      
+-2- Effects: Copies the contents of s into the
+basic_stringbuf underlying character sequence and
+initializes the input and output sequences according to mode.
+If
+mode & ios_base::out is true, initializes the output
+sequence such that pbase() points to the first underlying character, 
+epptr() points one past the last underlying character, and pptr()
+is equal to epptr() if mode & ios_base::in
+is true, otherwise pptr() is equal to pbase(). If
+mode & ios_base::in is true, initializes the input sequence 
+such that eback() and gptr() point to the first underlying
+character and egptr() points one past the last underlying character.
+
      
+
+        
      
+
+-3- Postconditions:  If  mode  & ios_base::out  is  true,
+pbase()  points  to the  first  underlying character  and
+(epptr() >= pbase() + s.size()) holds; in addition, if
+mode & ios_base::in is true, (pptr() == pbase()
++ s.data())  holds, otherwise (pptr()  == pbase())
+is   true.    If  mode   &   ios_base::in  is   true,
+eback()  points to  the first  underlying  character, and
+(gptr()  ==  eback())  and  (egptr() ==  eback()  +
+s.size()) hold.
+
+        
      
+
      
+
+
+
      [
+Kona (2007) Moved to Ready.
+]
      
+
+
+
+
+
+
      
+
      563. stringbuf seeking from end
      
+
      Section: 27.7.1.4 [stringbuf.virtuals] Status: WP
+ Submitter: Martin Sebor Date: 2006-02-23
      
+
      View all other issues in [stringbuf.virtuals].
      
+
      View all issues with WP status.
      
+
      Discussion:
      
+
      
+According to  Table 92  (unchanged by issue  432), when  (way ==
+end) the  newoff value in out mode  is computed as
+the difference between epptr() and pbase().
+
      
+        
      
+
+This value  isn't meaningful unless the  value of epptr()
+can be  precisely controlled by a  program.  That used  to be possible
+until  we accepted the  resolution of  issue 432,  but since  then the
+requirements on overflow() have  been relaxed to allow it
+to  make  more than  1  write  position  available (i.e.,  by  setting
+epptr()     to     some     unspecified    value     past
+pptr()).      So    after     the    first     call    to
+overflow()  positioning the  output sequence  relative to
+end will have unspecified results.
+
+        
      
+        
      
+
+In  addition,  in in|out  mode,  since (egptr()  ==
+epptr()) need not hold, there are two different possible values
+for   newoff:    epptr()   -   pbase()   and
+egptr() - eback().
+
+        
      
+
+
+
      Proposed resolution:
      
+        
      
+
+Change the newoff  column in the last row  of Table 94 to
+read:
+
+        
      
+
      
+
+the end high mark pointer minus the beginning 
+pointer (xend high_mark - xbeg).
+
+
      
+
+
+
      [
+Kona (2007) Moved to Ready.
+]
      
+
+
+
+
+
 
      
 
      566. array forms of unformatted input function undefined for zero-element arrays
      
 
      Section: 27.6.1.3 [istream.unformatted] Status: WP
@@ -21817,9 +22308,76 @@ location of the array.
 
 
 
+
      
+
      567. streambuf inserter and extractor should be unformatted
      
+
      Section: 27.6 [iostream.format] Status: WP
+ Submitter: Martin Sebor Date: 2006-02-25
      
+
      View all other issues in [iostream.format].
      
+
      View all issues with WP status.
      
+
      Discussion:
      
+        
      
+
+Issue  60 explicitly made  the extractor  and inserter  operators that
+take a  basic_streambuf* argument formatted  input and output
+functions,  respectively.  I  believe that's  wrong, certainly  in the
+case of  the extractor, since formatted functions  begin by extracting
+and  discarding  whitespace.  The  extractor  should  not discard  any
+characters.
+
+        
      
+
+
+
      Proposed resolution:
      
+        
      
+
+I propose to  change each operator to behave  as unformatted input and
+output function,  respectively. The changes below are  relative to the
+working draft document number N1804.
+
+        
      
+        
      
+
+Specifically, change 27.6.1.2.3, p14 as follows:
+
+        
      
+
+            
      
+        
      
+
+Effects:  Behaves as  an unformatted  input function
+(as   described   in   27.6.1.2.127.6.1.3,   paragraph
+1).
+
+        
      
+            
      
+        
      
+
+And change 27.6.2.5.3, p7 as follows:
+
+        
      
+
+            
      
+        
      
+
+Effects: Behaves  as an unformatted  output function
+(as   described   in   27.6.2.5.127.6.2.6,   paragraph
+1).
+
+        
      
+            
      
+
+
+
      [
+Kona (2007): Proposed Disposition: Ready
+]
      
+
+
+
+
+
 
      
 
      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
+
      Section: 20.6.12.2.2 [util.smartptr.shared.dest], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] Status: WP
  Submitter: Peter Dimov Date: 2006-04-23
      
 
      View all issues with WP status.
      
 
      Discussion:
      
@@ -22000,7 +22558,7 @@ conditions hold: !(value < *j) or comp(value, *j)
 
 
      
 
      578. purpose of hint to allocator::allocate()
      
-
      Section: 20.6.1.1 [allocator.members] Status: WP
+
      Section: 20.6.5.1 [allocator.members] Status: WP
  Submitter: Martin Sebor Date: 2006-05-17
      
 
      View all other issues in [allocator.members].
      
 
      View all issues with WP status.
      
@@ -22057,6 +22615,70 @@ adjacent element is often a good choice to pass for this argument.
 
 
 
+
      
+
      581. flush() not unformatted function
      
+
      Section: 27.6.2.7 [ostream.unformatted] Status: WP
+ Submitter: Martin Sebor Date: 2006-06-14
      
+
      View all other issues in [ostream.unformatted].
      
+
      View all issues with WP status.
      
+
      Discussion:
      
+        
      
+
+The resolution of issue 60 changed basic_ostream::flush()
+so as not  to require it to behave as  an unformatted output function.
+That has at least two in my opinion problematic consequences:
+
+        
      
+        
      
+
+First, flush()  now calls rdbuf()->pubsync()
+unconditionally, without  regard to the  state of the stream.  I can't
+think of any reason why flush() should behave differently
+from the vast majority of stream functions in this respect.
+
+        
      
+        
      
+
+Second, flush() is not  required to catch exceptions from
+pubsync() or set  badbit in response to such
+events. That doesn't seem right either, as most other stream functions
+do so.
+
+        
      
+    
+
+    
      Proposed resolution:
      
+        
      
+
+I  propose  to revert  the  resolution of  issue  60  with respect  to
+flush(). Specifically,  I propose to  change 27.6.2.6, p7
+as follows:
+
+        
      
+
+
      
+Effects: Behaves as an  unformatted output function (as described
+in 27.6.2.6, paragraph 1). If rdbuf() is not a null
+pointer,  constructs a  sentry  object.  If  this object  returns
+true when converted to a  value of type bool the function
+calls rdbuf()->pubsync().  If that function returns
+-1    calls    setstate(badbit)    (which    may    throw
+ios_base::failure  (27.4.4.3)).   Otherwise, if  the
+sentry object returns false, does nothing.Does
+not  behave  as  an  unformatted  output  function  (as  described  in
+27.6.2.6, paragraph 1).
+
      
+
+    
+
+
      [
+Kona (2007): Proposed Disposition: Ready
+]
      
+
+
+
+
+
 
      
 
      586. string inserter not a formatted function
      
 
      Section: 21.3.8.9 [string.io] Status: WP
@@ -22784,10 +23406,11 @@ floating-point types decimal32, decimal64, and d
 
 
      
 
      607. Concern about short seed vectors
      
-
      Section: 26.4.7.1 [rand.util.seedseq] Status: Pending WP
+
      Section: 26.4.7.1 [rand.util.seedseq] Status: WP
  Submitter: Charles Karney Date: 2006-10-26
      
+
      View other active issues in [rand.util.seedseq].
      
 
      View all other issues in [rand.util.seedseq].
      
-
      View all issues with Pending WP status.
      
+
      View all issues with WP status.
      
 
      Discussion:
      
 
      
 Short seed vectors of 32-bit quantities all result in different states. However
@@ -22835,10 +23458,11 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
      
 
      608. Unclear seed_seq construction details
      
-
      Section: 26.4.7.1 [rand.util.seedseq] Status: Pending WP
+
      Section: 26.4.7.1 [rand.util.seedseq] Status: WP
  Submitter: Charles Karney Date: 2006-10-26
      
+
      View other active issues in [rand.util.seedseq].
      
 
      View all other issues in [rand.util.seedseq].
      
-
      View all issues with Pending WP status.
      
+
      View all issues with WP status.
      
 
      Discussion:
      
 
      
 In 26.4.7.1 [rand.util.seedseq] /6, the order of packing the inputs into b and the
@@ -22977,7 +23601,7 @@ function pointer (a "bound member function").
 
 
      
 
      611. Standard library templates and incomplete types
      
-
      Section: 17.4.3.6 [res.on.functions] Status: WP
+
      Section: 17.4.3.7 [res.on.functions] Status: WP
  Submitter: Nicola Musatti Date: 2006-11-13
      
 
      View all issues with WP status.
      
 
      Discussion:
      
@@ -23224,6 +23848,498 @@ undefined behavior if replacing the setjmp and longjmp by
 
 
 
+
      
+
      620. valid uses of empty valarrays
      
+
      Section: 26.5.2.1 [valarray.cons] Status: WP
+ Submitter: Martin Sebor Date: 2007-01-20
      
+
      View all other issues in [valarray.cons].
      
+
      View all issues with WP status.
      
+
      Discussion:
      
+        
      
+
+The Effects  clause for the  default valarray ctor
+suggests  that  it  is possible  to  increase  the  size of  an  empty
+valarray  object   by  calling  other   non-const  member
+functions of the class besides resize(). However, such an
+interpretation would  be contradicted by  the requirement on  the copy
+assignment  operator  (and  apparently   also  that  on  the  computed
+assignments)  that the  assigned arrays  be  the same  size.  See  the
+reflector discussion starting with c++std-lib-17871.
+
+        
      
+        
      
+
+In  addition,  Footnote 280  uses  some questionable  normative
+language.
+
+        
      
+
+
+
      Proposed resolution:
      
+        
      
+
+Reword the Effects clause and Footnote 280 as follows (26.5.2.1 [valarray.cons]):
+
+        
      
+        
      
+            
      
+
+valarray();
+
+            
      
+            
      
+
+Effects:      Constructs      an      object      of      class
+valarray<T>,279)    which    has    zero
+length until it is passed into a library function as a modifiable
+lvalue or through a non-constant this pointer.280)
+
+            
      
+            
      
+
+Postcondition: size() == 0.
+
+            
      
+            
      
+
+Footnote  280:  This default  constructor  is essential,  since
+arrays  of  valarray  are  likely to  prove  useful.
+There  shall also  be  a way  to change  the  size of  an array  after
+initialization;  this  is  supplied  by the  semantics  may be
+useful.   The  length  of  an  empty  array  can  be  increased  after
+initialization  by  means  of the  resize()  member
+function.
+
+            
      
+        
      
+
+
+
+
+
+
      
+
      621. non-const copy assignment operators of helper arrays
      
+
      Section: 26.5 [numarray] Status: WP
+ Submitter: Martin Sebor Date: 2007-01-20
      
+
      View all other issues in [numarray].
      
+
      View all issues with WP status.
      
+
      Discussion:
      
+        
      
+
+The computed and  "fill" assignment operators of valarray
+helper     array     class    templates     (slice_array,
+gslice_array,         mask_array,        and
+indirect_array) are const  member functions of each class
+template     (the     latter    by     the     resolution    of  123
+since  they have reference  semantics and thus do  not affect
+the state of  the object on which they are  called.  However, the copy
+assignment  operators  of  these  class  templates,  which  also  have
+reference semantics,  are non-const.   The absence of  constness opens
+the door to speculation about whether they really are intended to have
+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:
      
+        
      
+
+Declare  the  copy  assignment  operators  of all  four  helper  array
+class templates const.
+
+        
      
+        
      
+
+Specifically,  make the following edits:
+
+        
      
+        
      
+
+Change     the    signature     in     26.5.5 [template.slice.array]    and
+26.5.5.1 [slice.arr.assign] as follows:
+
+        
      
+        
      +const slice_array& operator= (const slice_array&) const;
+
+        
      
+        
      
+
+Change     the     signature     in    26.5.7 [template.gslice.array]     and
+26.5.7.1 [gslice.array.assign] as follows:
+
+        
      
+        
      +const gslice_array& operator= (const gslice_array&) const;
+
+        
      
+        
      
+
+Change the  signature in 26.5.8 [template.mask.array]  and 26.5.8.1 [mask.array.assign] as
+follows:
+
+        
      
+        
      +const mask_array& operator= (const mask_array&) const;
+
+        
      
+        
      
+
+Change     the     signature     in    26.5.9 [template.indirect.array] and
+26.5.9.1 [indirect.array.assign] as follows:
+
+        
      
+        
      +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: WP
+ Submitter: Martin Sebor Date: 2007-01-20
      
+
      View all issues with WP status.
      
+
      Discussion:
      
+        
      
+
+basic_filebuf  dtor is  specified to  have  the following
+straightforward effects:
+
+        
      
+        
      
+
+Effects:       Destroys      an      object       of      class
+basic_filebuf. Calls close().
+
+        
      
+        
      
+
+close() does a lot of potentially complicated processing,
+including calling overflow() to write out the termination
+sequence  (to   bring  the  output  sequence  to   its  initial  shift
+state). Since  any of the  functions called during the  processing can
+throw an exception, what should the  effects of an exception be on the
+dtor? Should the  dtor catch and swallow it or  should it propagate it
+to the caller?  The text doesn't  seem to provide any guidance in this
+regard  other  than  the  general  restriction on  throwing  (but  not
+propagating)  exceptions  from   destructors  of  library  classes  in
+17.4.4.8 [res.on.exception.handling].
+
+        
      
+        
      
+
+Further,  the last thing  close() is  specified to  do is
+call fclose() to close the FILE pointer. The
+last sentence of the Effects clause reads:
+
+        
      
+        
      
+
+...   If    any   of    the   calls   to    overflow   or
+std::fclose fails then close fails.
+
+        
      
+        
      
+
+This  suggests that  close()  might be  required to  call
+fclose()   if  and  only   if  none   of  the   calls  to
+overflow() fails, and avoid closing the FILE
+otherwise. This  way, if  overflow() failed to  flush out
+the data, the caller  would have  the opportunity to  try to  flush it
+again (perhaps  after trying  to deal with  whatever problem  may have
+caused the failure), rather than losing it outright.
+
+        
      
+        
      
+
+On the other hand,  the function's Postcondition specifies that
+is_open() ==  false, which  suggests that it  should call
+fclose()       unconditionally.       However,      since
+Postcondition clauses  are specified for many  functions in the
+standard,  including constructors  where they  obviously  cannot apply
+after an  exception, it's not clear  whether this Postcondition
+clause is intended to apply even after an exception.
+
+        
      
+        
      
+
+It  might  be worth  noting  that  the  traditional behavior  (Classic
+Iostreams  fstream::close() and  C fclose())
+is  to  close  the  FILE unconditionally,  regardless  of
+errors.
+
+        
      
+
+
      [
+See 397 and 418 for related issues.
+]
      
+
+
+
+
+
      Proposed resolution:
      
+        
      
+
+After discussing this  on the reflector (see the  thread starting with
+c++std-lib-17650) we propose that close() be clarified to
+match the traditional behavior, that is to close the FILE
+unconditionally,  even after  errors or  exceptions.  In  addition, we
+propose the dtor description be amended so as to explicitly require it
+to catch and swallow any exceptions thrown by close().
+
+        
      
+        
      
+
+Specifically,   we   propose   to   make  the   following   edits   in
+27.8.1.4 [filebuf.members]:
+
+        
      
+        
      
+            
      +basic_filebuf<charT,traits>* close();
+
+            
      
+            
      
+
+Effects:  If is_open()  == false,  returns  a null
+pointer.        If      a       put      area       exists,      calls
+overflow(traits::eof()) to flush  characters. If the last
+virtual   member  function   called  on   *this  (between
+underflow,  overflow,  seekoff,
+and   seekpos)  was   overflow   then  calls
+a_codecvt.unshift (possibly several times) to determine a
+termination   sequence,    inserts   those   characters    and   calls
+overflow(traits::eof())  again.  Finally, regardless
+of whether  any of the preceding  calls fails or  throws an exception,
+the  function it  closes   the  file   ("as   if"  by   calling
+std::fclose(file)).334)  If any  of  the calls
+made    by   the    functionto   overflow
+or,  including  std::fclose, 
+fails then close fails  by returning a null pointer.
+If one of these calls throws an exception, the exception is caught and
+rethrown after closing the file.
+
+            
      
+        
      
+        
      
+
+And to make the following edits in 27.8.1.2 [filebuf.cons].
+
+        
      
+        
      
+            
      +virtual ~basic_filebuf();
+
+            
      
+            
      
+
+Effects:       Destroys      an      object       of      class
+basic_filebuf<charT,traits>.                   Calls
+close().    If  an   exception  occurs   during  the
+destruction of the object, including the call to close(),
+the     exception    is     caught    but     not     rethrown    (see
+17.4.4.8 [res.on.exception.handling]).
+
+            
      
+        
      
+
+
+
+
+
+
      
+
      623. pubimbue forbidden to call imbue
      
+
      Section: 27.1.1 [iostream.limits.imbue] Status: WP
+ Submitter: Martin Sebor Date: 2007-01-20
      
+
      View all issues with WP status.
      
+
      Discussion:
      
+        
      
+
+27.1.1 [iostream.limits.imbue]  specifies  that  "no  function  described  in
+clause 27 except  for ios_base::imbue causes any instance
+of                   basic_ios::imbue                  or
+basic_streambuf::imbue to be called."
+
+        
      
+        
      
+
+That      contradicts      the      Effects     clause      for
+basic_streambuf::pubimbue()  which requires  the function
+to do just that: call basic_streambuf::imbue().
+
+        
      
+
+
+
      Proposed resolution:
      
+        
      
+
+To    fix   this,    rephrase    the   sentence    above   to    allow
+pubimbue to do what  it was designed to do. Specifically.
+change 27.1.1 [iostream.limits.imbue], p1 to read:
+
+        
      
+        
      
+
+No     function    described     in    clause     27     except    for
+ios_base::imbue  and basic_filebuf::pubimbue
+causes    any    instance    of    basic_ios::imbue    or
+basic_streambuf::imbue to be called. ...
+
+        
      
+
+
+
+
+
+
      
+
      624. valarray assignment and arrays of unequal length
      
+
      Section: 26.5.2.2 [valarray.assign] Status: WP
+ Submitter: Martin Sebor Date: 2007-01-20
      
+
      View all issues with WP status.
      
+
      Discussion:
      
+        
      
+
+The behavior of the  valarray copy assignment operator is
+defined only when both sides have  the same number of elements and the
+spec is explicit about assignments of arrays of unequal lengths having
+undefined behavior.
+
+        
      
+        
      
+
+However, the generalized  subscripting assignment operators overloaded
+on slice_array  et al (26.5.2.2 [valarray.assign])  don't have any
+such restriction, leading  the reader to believe that  the behavior of
+these  overloads is  well defined  regardless  of the  lengths of  the
+arguments.
+
+        
      
+        
      
+
+For example,  based on  the reading  of the spec  the behavior  of the
+snippet below can be expected to be well-defined:
+
+        
      
+        
          const std::slice from_0_to_3 (0, 3, 1);   // refers to elements 0, 1, 2
+    const std::valarray<int> a (1, 3);        // a = { 1, 1, 1 }
+    std::valarray<int>       b (2, 4);        // b = { 2, 2, 2, 2 }
+
+    b = a [from_0_to_3];
+        
      
+        
      
+
+In practice, b may end up being { 1, 1, 1 },
+{  1,  1, 1,  2  },  or  anything else,  indicating  that
+existing implementations vary.
+
+        
      
+
+
      
+Quoting from Section 3.4, Assignment operators, of Al Vermeulen's
+Proposal for Standard C++ Array Classes (see c++std-lib-704;
+N0308):
+
      
+
      
+  ...if the size of the array on the right hand side of the equal
+  sign differs from the size of the array on the left, a run time
+  error occurs. How this error is handled is implementation
+  dependent; for compilers which support it, throwing an exception
+  would be reasonable.
+
      
+
+
      
+And see more history in
+N0280.
+
      
+
+        
      
+
+It has  been argued in  discussions on the committee's  reflector that
+the semantics of all valarray assignment operators should
+be permitted to be undefined unless  the  length  of the arrays  being
+assigned is the same as the length of the one being assigned from. See
+the thread starting at c++std-lib-17786.
+
+        
      
+        
      
+
+In order  to reflect  such views, the  standard must specify  that the
+size of the  array referred to by the argument  of the assignment must
+match the size of the array  under assignment, for example by adding a
+Requires clause to 26.5.2.2 [valarray.assign] as follows:
+
+        
      
+        
      
+
+Requires: The length of the  array to which the argument refers
+equals size().
+
+        
      
+
+        
      
+
+Note that it's  far from clear that such leeway  is necessary in order
+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.
+
      
+
      
+
      
+
+
+
+
+
 
      
 
      628. Inconsistent definition of basic_regex constructor
      
 
      Section: 28.8 [re.regex] Status: WP
@@ -23263,7 +24379,7 @@ Change 28.8.2 [re.regex.construct]:
 
 
      
 
      634. allocator.address() doesn't work for types overloading operator&
      
-
      Section: 20.6.1.1 [allocator.members] Status: WP
+
      Section: 20.6.5.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.
      
@@ -23271,7 +24387,7 @@ Change 28.8.2 [re.regex.construct]:
 
      Discussion:
      
 
 
      
-20.6.1.1 [allocator.members] says:
+20.6.5.1 [allocator.members] says:
 
      
 
      
 
      pointer address(reference x) const;
      
@@ -23283,7 +24399,7 @@ Change 28.8.2 [re.regex.construct]:
 
      
 
 
      
-20.6.1.1 [allocator.members] defines CopyConstructible which currently not
+20.6.5.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
@@ -23314,7 +24430,7 @@ is expected to make use of allocator::address mandatory for containers.
 
 
      Proposed resolution:
      
 
      
-Change 20.6.1.1 [allocator.members]:
+Change 20.6.5.1 [allocator.members]:
 
      
 
 
      
@@ -23473,7 +24589,6 @@ A local variable punct is initialized via
 
      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]
@@ -23691,10 +24806,10 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
      
 
      654. Missing IO roundtrip for random number engines
      
-
      Section: 26.4.1.3 [rand.req.eng] Status: Pending WP
+
      Section: 26.4.1.3 [rand.req.eng] Status: WP
  Submitter: Daniel Krügler Date: 2007-03-08
      
 
      View all other issues in [rand.req.eng].
      
-
      View all issues with Pending WP status.
      
+
      View all issues with WP status.
      
 
      Discussion:
      
 
      
 Table 98 and para 5 in 26.4.1.3 [rand.req.eng] specify
@@ -23821,10 +24936,10 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
      
 
      655. Signature of generate_canonical not useful
      
-
      Section: 26.4.7.2 [rand.util.canonical] Status: Pending WP
+
      Section: 26.4.7.2 [rand.util.canonical] Status: WP
  Submitter: Daniel Krügler Date: 2007-03-08
      
 
      View all other issues in [rand.util.canonical].
      
-
      View all issues with Pending WP status.
      
+
      View all issues with WP status.
      
 
      Discussion:
      
 
      
 In 26.4.2 [rand.synopsis] we have the declaration
@@ -23929,12 +25044,349 @@ template <class T> struct bit_xor;
      
 
 
 
+
      
+
      661. New 27.6.1.2.2 changes make special extractions useless
      
+
      Section: 27.6.1.2.2 [istream.formatted.arithmetic] Status: WP
+ Submitter: Daniel Krügler Date: 2007-04-01
      
+
      View all other issues in [istream.formatted.arithmetic].
      
+
      View all issues with WP 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.
+
      
+
+
        
+
      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. 
+
        
+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);
+
        
+
+
        
+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. 
+
      
+
+
+
      [
+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.
+]
      
+
+
+
+
+
+
      
+
      664. do_unshift for codecvt<char, char, mbstate_t>
      
+
      Section: 22.2.1.4.2 [locale.codecvt.virtuals] Status: WP
+ Submitter: Thomas Plum Date: 2007-04-16
      
+
      View all other issues in [locale.codecvt.virtuals].
      
+
      View all issues with WP status.
      
+
      Discussion:
      
+
      
+22.2.1.4.2 [locale.codecvt.virtuals], para 7 says (regarding do_unshift):
+
      
+
+
      
+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.
+
      
+
+
      
+The following objection has been raised:
+
      
+
+
      
+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.
+
      
+
+
      
+[Plum ref _222152Y50]
+
      
+
+
+
      Proposed resolution:
      
+
      
+Change 22.2.1.4.2 [locale.codecvt.virtuals], p7:
+
      
+
+
      
+
      
+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.
+
      
+
      
+
+
+
+
+
+
      
+
      665. do_unshift return value
      
+
      Section: 22.2.1.4.2 [locale.codecvt.virtuals] Status: WP
+ Submitter: Thomas Plum Date: 2007-04-16
      
+
      View all other issues in [locale.codecvt.virtuals].
      
+
      View all issues with WP status.
      
+
      Discussion:
      
+
      
+22.2.1.4.2 [locale.codecvt.virtuals], para 8 says:
+
      
+
+
      
+codecvt<char,char,mbstate_t>, returns noconv.
+
      
+
+
      
+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.
+
      
+
+
      
+[Plum ref _222152Y62]
+
      
+
+
+
      Proposed resolution:
      
+
      
+Change 22.2.1.4.2 [locale.codecvt.virtuals], p8:
+
      
+
+
      
+
      Returns: An enumeration value, as summarized in Table 76:
      
+
      ...
      
+
      
+codecvt<char,char,mbstate_t>, returns noconv.
+
      
+
      
+
+
+
+
+
+
+
      
+
      666. moneypunct::do_curr_symbol()
      
+
      Section: 22.2.6.3.2 [locale.moneypunct.virtuals] Status: WP
+ Submitter: Thomas Plum Date: 2007-04-16
      
+
      View all other issues in [locale.moneypunct.virtuals].
      
+
      View all issues with WP status.
      
+
      Discussion:
      
+
      
+22.2.6.3.2 [locale.moneypunct.virtuals], para 4 footnote 257 says
+
      
+
+
      
+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:
+
      
+
+
      
+The international currency 
+symbol is whatever the underlying locale says it is, not necessarily 
+four characters long.
+
      
+
+
      
+[Plum ref _222632Y41]
+
      
+
+
+
      Proposed resolution:
      
+
      
+Change footnote 253 in 22.2.6.3.2 [locale.moneypunct.virtuals]:
+
      
+
+
      
+
      
+253) For international specializations (second template
+parameter true) this is always typically
+four characters long, usually three letters and a space.
+
      
+
      
+
+
+
+
+
+
      
+
      674. shared_ptr interface changes for consistency with N1856
      
+
      Section: 20.6.12.2 [util.smartptr.shared] Status: WP
+ 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 WP 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.
+
      
+
+
+
      Proposed resolution:
      
+
+
      
+Change 20.6.12.2 [util.smartptr.shared] as follows:
+
      
+
+
      
+
      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);
      
+
      
+
+
      
+Change 20.6.12.2.1 [util.smartptr.shared.const] as follows:
+
      
+
+
      
+
      template<class Y> shared_ptr(auto_ptr<Y>&&& r);
      
+
      
+
+
      
+Add to 20.6.12.2.1 [util.smartptr.shared.const]:
+
      
+
+
      
+
      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.
+
      
+
      
+
+
      
+
+
      
+Change 20.6.12.2.3 [util.smartptr.shared.assign] as follows:
+
      
+
+
      
+
      template<class Y> shared_ptr& operator=(auto_ptr<Y>&&& r);
      
+
      
+
+
      
+Add to 20.6.12.2.3 [util.smartptr.shared.assign]:
+
      
+
+
      
+
      template<class Y, class D> shared_ptr& operator=(unique_ptr<Y,D>&& r);
      
+
+
      
+
      
+-4- Effects: Equivalent to shared_ptr(std::move(r)).swap(*this).
+
      
+
      
+-5- Returns: *this.
+
      
+
      
+
+
      
+
+
+
+
      [
+Kona (2007): We may need to open an issue (743) to deal with the question of
+whether shared_ptr needs an rvalue swap.
+]
      
+
+
+
+
+
 
      
 
      677. Weaknesses in seed_seq::randomize [rand.util.seedseq]
      
-
      Section: 26.4.7.1 [rand.util.seedseq] Status: Pending WP
+
      Section: 26.4.7.1 [rand.util.seedseq] Status: WP
  Submitter: Charles Karney Date: 2007-05-15
      
+
      View other active issues in [rand.util.seedseq].
      
 
      View all other issues in [rand.util.seedseq].
      
-
      View all issues with Pending WP status.
      
+
      View all issues with WP status.
      
 
      Discussion:
      
 
      
 seed_seq::randomize provides a mechanism for initializing random number
@@ -24088,6 +25540,206 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
 
+
      
+
      679. resize parameter by value
      
+
      Section: 23.2 [sequences] Status: WP
+ Submitter: Howard Hinnant Date: 2007-06-11
      
+
      View all issues with WP status.
      
+
      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.4 [list], p2:
+
      
+
+
      class list {
+   ...
+   void resize(size_type sz, const T& c);
+
      
+
+
      
+Change 23.2.4.2 [list.capacity], p3:
+
      
+
+
      void resize(size_type sz, const T& c);
+
      
+
+
      
+Change 23.2.6 [vector], p2:
+
      
+
+
      class vector {
+   ...
+   void resize(size_type sz, const T& c);
+
      
+
+
      
+Change 23.2.6.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: WP
+ Submitter: Howard Hinnant Date: 2007-06-11
      
+
      View all issues with WP 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;
+
      
+
+
+
+
+
+
 
      
 
      681. Operator functions impossible to compare are defined in [re.submatch.op]
      
 
      Section: 28.9.2 [re.submatch.op] Status: WP
@@ -24100,8 +25752,7 @@ operator functions numbered 31-42 seem impossible to compare.  E.g.:
 
      
 
 
      
-
      -template <class BiIter>
+
      template <class BiIter>
     bool operator==(typename iterator_traits<BiIter>::value_type const& lhs,
                     const sub_match<BiIter>& rhs);
 
      
@@ -24139,9 +25790,9 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
      
 
      682. basic_regex ctor takes InputIterator or ForwardIterator?
      
-
      Section: 28.8.2 [re.regex.construct] Status: Pending WP
+
      Section: 28.8.2 [re.regex.construct] Status: WP
  Submitter: Eric Niebler Date: 2007-06-03
      
-
      View all issues with Pending WP status.
      
+
      View all issues with WP status.
      
 
      Discussion:
      
 
      
 Looking at N2284, 28.8 [re.regex], p3 basic_regex class template synopsis shows this 
@@ -24198,6 +25849,341 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
 
+
      
+
      687. shared_ptr conversion constructor not constrained
      
+
      Section: 20.6.12.2.1 [util.smartptr.shared.const], 20.6.12.3.1 [util.smartptr.weak.const] Status: WP
+ Submitter: Peter Dimov Date: 2007-05-10
      
+
      View all other issues in [util.smartptr.shared.const].
      
+
      View all issues with WP 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.12.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.12.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*.
+
      
+
      
+
+
+
+
+
+
+
      
+
      689. reference_wrapper constructor overly constrained
      
+
      Section: 20.5.5.1 [refwrap.const] Status: WP
+ Submitter: Peter Dimov Date: 2007-05-10
      
+
      View all other issues in [refwrap.const].
      
+
      View all issues with WP 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.
+
      
+
+
+
+
+
+
      
+
      693. std::bitset::all() missing
      
+
      Section: 23.3.5 [template.bitset] Status: WP
+ Submitter: Martin Sebor Date: 2007-06-22
      
+
      View all other issues in [template.bitset].
      
+
      View all issues with WP 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: WP
+ Submitter: Martin Sebor Date: 2007-06-22
      
+
      View all other issues in [template.bitset].
      
+
      View all issues with WP 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: WP
+ Submitter: Martin Sebor Date: 2007-06-22
      
+
      View all issues with WP 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;
+
      
+
      
+
+
+
+
+
 
      
 
      699. N2111 changes min/max
      
 
      Section: 26.4 [rand] Status: WP
@@ -24237,10 +26223,182 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
 
+
      
+
      700. N1856 defines struct identity
      
+
      Section: 20.2.2 [forward] Status: WP
+ Submitter: P.J. Plauger Date: 2007-07-01
      
+
      View other active issues in [forward].
      
+
      View all other issues in [forward].
      
+
      View all issues with WP 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.
+
      
+
      
+
      
+
+
      
+
+
+
+
+
+
+
      
+
      703. map::at() need a complexity specification
      
+
      Section: 23.3.1.2 [map.access] Status: WP
+ Submitter: Joe Gottman Date: 2007-07-03
      
+
      View all other issues in [map.access].
      
+
      View all issues with WP 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.
+
      
+
      
+
+
+
+
+
+
      
+
      705. type-trait decay incompletely specified
      
+
      Section: 20.4.7 [meta.trans.other] Status: WP
+ Submitter: Thorsten Ottosen Date: 2007-07-08
      
+
      View all issues with WP 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.3 [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: WP
+ Submitter: Thorsten Ottosen Date: 2007-07-08
      
+
      View all other issues in [pairs].
      
+
      View all issues with WP status.
      
+
      Discussion:
      
+
      
+The current draft has make_pair() in 20.2.3 [pairs]/16
+and make_tuple() in 20.3.1.3 [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.
+
      
+
+
+
      Proposed resolution:
      
+
      
+In 20.2 [utility] change the synopsis for make_pair() to read
+
      
+
+
      template <class T1, class T2>
+  pair<typename decay<T1>::type V1, typename decay<T2>::type V2> make_pair(T1&&, T2&&);
+
      
+
+
      
+In 20.2.3 [pairs]/16 change the declaration to match the above synopsis.
+Then change the 20.2.3 [pairs]/17 to:
+
      
+
+
      
+
      
+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.
+
      
+
      
+
+
+
+
+
+
 
      
 
      712. seed_seq::size no longer useful
      
 
      Section: 26.4.7.1 [rand.util.seedseq] Status: WP
  Submitter: Marc Paterno Date: 2007-08-25
      
+
      View other active issues in [rand.util.seedseq].
      
 
      View all other issues in [rand.util.seedseq].
      
 
      View all issues with WP status.
      
 
      Discussion:
      
@@ -24280,5 +26438,4 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
 
-
 
\ No newline at end of file