From: Paolo Carlini Date: Wed, 21 May 2008 20:13:47 +0000 (+0000) Subject: lwg-active.html: Update to Revision R56. X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=301a9fb249131bad2b88ddea549cfee9b577c9e0;p=gcc.git 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 --- 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,65 +3383,212 @@ object (e.g., slice (2, 1, 1) for a valarray of size 1).
   need wording to express this decision.]
    
 
 
+
    [
+Bellevue:
+]
    
+
 
-
    Proposed resolution:
    
+
    
+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.
+]
    
 
 
 
-
    
-
    431. Swapping containers with unequal allocators
    
-
    Section: 20.1.2 [allocator.requirements], 25 [algorithms] Status: Open
- Submitter: Matt Austern Date: 2003-09-20
    
-
    View other active issues in [allocator.requirements].
    
-
    View all other issues in [allocator.requirements].
    
-
    View all issues with Open status.
    
-
    Discussion:
    
-
    Clause 20.1.2 [allocator.requirements] paragraph 4 says that implementations
-  are permitted to supply containers that are unable to cope with
-  allocator instances and that container implementations may assume
-  that all instances of an allocator type compare equal.  We gave
-  implementers this latitude as a temporary hack, and eventually we
-  want to get rid of it.  What happens when we're dealing with
-  allocators that don't compare equal?
+
    Proposed resolution:
    
+
    
+Insert after 26.5.2.4 [valarray.sub], paragraph 1:
 
    
 
-
    In particular: suppose that v1 and v2 are both
-  objects of type vector<int, my_alloc> and that
-  v1.get_allocator() != v2.get_allocator().  What happens if
-  we write v1.swap(v2)?  Informally, three possibilities:
    
+
    
+
    
+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:
+
    
 
-
    1. This operation is illegal.  Perhaps we could say that an
-  implementation is required to check and to throw an exception, or
-  perhaps we could say it's undefined behavior.
    
-
    2. The operation performs a slow swap (i.e. using three
-  invocations of operator=, leaving each allocator with its
-  original container.  This would be an O(N) operation.
    
-
    3. The operation swaps both the vectors' contents and their
-  allocators.  This would be an O(1) operation. That is:
    
-  
    
-  
        my_alloc a1(...);
-    my_alloc a2(...);
-    assert(a1 != a2);
+
    valarray<char> v0("abcdefghijklmnop", 16);
+v0[3] = 'A';
+// v0 == valarray<char>("abcAefghijklmnop", 16)
+
    
 
-    vector<int, my_alloc> v1(a1);
-    vector<int, my_alloc> v2(a2);
-    assert(a1 == v1.get_allocator());
-    assert(a2 == v2.get_allocator());
+
    
+The second member operator selects those elements of the controlled sequence
+designated by slicearr. For example:
+
    
 
-    v1.swap(v2);
-    assert(a1 == v2.get_allocator());
-    assert(a2 == v1.get_allocator());
-  
    
-  
    
+
    valarray<char> v0("abcdefghijklmnop", 16);
+valarray<char> v1("ABCDE", 5);
+v0[slice(2, 5, 3)] = v1;
+// v0 == valarray<char>("abAdeBghCjkDmnEp", 16)
+
    
 
-
    [Kona: This is part of a general problem.  We need a paper
-  saying how to deal with unequal allocators in general.]
    
+
    
+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)
+
    
 
-
    [pre-Sydney: Howard argues for option 3 in
-N1599.
-]
    
+
    
+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)
+
    
+
+
    
+
+
+
+
+
+
    
+
    431. Swapping containers with unequal allocators
    
+
    Section: 20.1.2 [allocator.requirements], 25 [algorithms] Status: Open
+ Submitter: Matt Austern Date: 2003-09-20
    
+
    View other active issues in [allocator.requirements].
    
+
    View all other issues in [allocator.requirements].
    
+
    View all issues with Open status.
    
+
    Discussion:
    
+
    Clause 20.1.2 [allocator.requirements] paragraph 4 says that implementations
+  are permitted to supply containers that are unable to cope with
+  allocator instances and that container implementations may assume
+  that all instances of an allocator type compare equal.  We gave
+  implementers this latitude as a temporary hack, and eventually we
+  want to get rid of it.  What happens when we're dealing with
+  allocators that don't compare equal?
+
    
+
+
    In particular: suppose that v1 and v2 are both
+  objects of type vector<int, my_alloc> and that
+  v1.get_allocator() != v2.get_allocator().  What happens if
+  we write v1.swap(v2)?  Informally, three possibilities:
    
+
+
    1. This operation is illegal.  Perhaps we could say that an
+  implementation is required to check and to throw an exception, or
+  perhaps we could say it's undefined behavior.
    
+
    2. The operation performs a slow swap (i.e. using three
+  invocations of operator=, leaving each allocator with its
+  original container.  This would be an O(N) operation.
    
+
    3. The operation swaps both the vectors' contents and their
+  allocators.  This would be an O(1) operation. That is:
    
+  
    
+  
        my_alloc a1(...);
+    my_alloc a2(...);
+    assert(a1 != a2);
+
+    vector<int, my_alloc> v1(a1);
+    vector<int, my_alloc> v2(a2);
+    assert(a1 == v1.get_allocator());
+    assert(a2 == v2.get_allocator());
+
+    v1.swap(v2);
+    assert(a1 == v2.get_allocator());
+    assert(a2 == v1.get_allocator());
+  
    
+  
    
+
+
    [Kona: This is part of a general problem.  We need a paper
+  saying how to deal with unequal allocators in general.]
    
+
+
+
    [pre-Sydney: Howard argues for option 3 in
+N1599.
+]
    
 
 
 
    [
@@ -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,236 +3937,523 @@ 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;
 
-
    [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.]
    
+struct B {};
+struct D : B {};
 
+auto_ptr<D> source();
+int sink(auto_ptr<B>);
+int x1 = sink( source() ); // #1 EDG - no suitable copy constructor
+
    
 
-
    [
-Batavia:  Send to core with our recommendation that we should permit deferred
-destruction but not require it.
-]
    
+
    
+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 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.
+
    
 
-
    [
-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 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.
+
    
 
-
    #include <cstdlib>
-#include <iostream>
-#include <type_traits>
-#include <new>
+
    
+Removing the obsolete member will have impact on code that explicitly
+invokes it:
+
    
+
    int y = sink(source().operator auto_ptr<B>());
+
    
 
-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";
-    }
-};
+
    
+IMHO no one ever wrote such awkward code and the reasonable workaround for
+#1 is:
+
    
+
    int y = sink( auto_ptr<B>(source()) );
+
    
 
-void deallocate_resource();
+
    
+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 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;
-}
+
    
+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.
+
    
 
-void deallocate_resource()
-{
-    get_resource(false);
-}
+
    
+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();
 
-void use_A(const char* message)
-{
-    A& a = get_resource();
-    std::cout << "Using A " << message << "\n";
-    a.use();
-}
+// string constructor throws while auto_ptr_ref
+// "holds" the pointer
+int x4 = f(source2(), "xyz"); // #4
+
    
 
-struct B
-{
-    ~B() {use_A("from ~B()");}
-};
+
    
+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. 
+
    
 
-B b;
+
    
+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
+
    
 
-int main()
-{
-    use_A("from main()");
-}
-
    
+
    
+Dave Abrahams noticed that there is no specification saying that
+auto_ptr_ref copy constructor can't throw.
+
    
 
 
    
-The correct output is:
+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.
 
    
 
-
    A()
-Using A from main()
-A is alive
-~A()
-A()
-Using A from ~B()
-A is alive
-~A()
-
    
+
    
+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);
+    };
+}
+
    
 
-
    Proposed resolution:
    
 
    
+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.
    
 
-
    
-
    471. result of what() implementation-defined
    
-
    Section: 18.6.1 [type.info] Status: Open
- Submitter: Martin Sebor Date: 2004-06-28
    
-
    View all other issues in [type.info].
    
-
    View all issues with Open status.
    
-
    Discussion:
    
+
    Change 20.4.5.1/4,5,6 to read:
    
 
-
    [lib.exception] specifies the following:
    
-
        exception (const exception&) throw();
-    exception& operator= (const exception&) throw();
+
    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().
    
 
-    -4- Effects: Copies an exception object.
-    -5- Notes: The effects of calling what() after assignment
-        are implementation-defined.
+
    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.
    
 
 
    
-First, does the Note only apply to the assignment operator? If so,
-what are the effects of calling what() on a copy of an object? Is
-the returned pointer supposed to point to an identical copy of
-the NTBS returned by what() called on the original object or not?
+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_;
+};
+
    
 
 
    
-Second, is this Note intended to extend to all the derived classes
-in section 19? I.e., does the standard provide any guarantee for
-the effects of what() called on a copy of any of the derived class
-described in section 19?
+In most cases this indicates about sloppy programming but preserves the
+current auto_ptr behavior.
 
    
 
 
    
-Finally, if the answer to the first question is no, I believe it
-constitutes a defect since throwing an exception object typically
-implies invoking the copy ctor on the object. If the answer is yes,
-then I believe the standard ought to be clarified to spell out
-exactly what the effects are on the copy (i.e., after the copy
-ctor was called).
+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: Yes, this is fuzzy.  The issue of derived classes is
-  fuzzy too.]
    
+
    [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: Howard provided wording.
+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.
+]
    
+
+
+
    [
+2007-11-09: Reopened at the request of David Abrahams, Alisdair Meredith and Gabriel Dos Reis.
 ]
    
 
 
 
 
 
    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; 
+  }; 
+
+}
+
    
 
 
    
-Change 18.7.1 [exception] to:
+Remove D.9.1.3 [auto.ptr.conv].
+
    
+
+
    
+Change D.9.1 [auto.ptr], p3:
 
    
 
 
    
-
    exception(const exception& e) throw();
-exception& operator=(const exception& e) throw();
    
-
    
+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]
+
    
+
 
    
--4- Effects: Copies an exception object.
+Change D.9.1.1 [auto.ptr.cons], p5:
 
    
+
+
    
+
    template<class Y> auto_ptr(auto_ptr<Y> const& a) throw();
+
    
+
    
 
    
- -5- Remarks: The effects of calling what() after assignment are implementation-defined.
+Requires: Y* can be implicitly converted to X*.
 
    
 
    
--5- Throws: Nothing.  This also applies
-to all standard library-defined classes that derive from exception.
+Effects: Calls const_cast<auto_ptr<Y>&>(a).release().
 
    
 
    
--7- Postcondition: strcmp(what(), e.what()) == 0.  This also applies
-to all standard library-defined classes that derive from exception.
+Postconditions: *this holds the pointer returned from a.release().
 
    
-
 
    
 
    
 
+
    
+Change D.9.1.1 [auto.ptr.cons], p10:
+
    
 
-
-
-
    
-
    473. underspecified ctype calls
    
-
    Section: 22.2.1.1 [locale.ctype] Status: Open
+
    
+
    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: Ready
+ Submitter: Martin Sebor Date: 2004-06-28
    
+
    View all other issues in [type.info].
    
+
    View all issues with Ready status.
    
+
    Discussion:
    
+
+
    [lib.exception] specifies the following:
    
+
        exception (const exception&) throw();
+    exception& operator= (const exception&) throw();
+
+    -4- Effects: Copies an exception object.
+    -5- Notes: The effects of calling what() after assignment
+        are implementation-defined.
+
    
+
+
    
+First, does the Note only apply to the assignment operator? If so,
+what are the effects of calling what() on a copy of an object? Is
+the returned pointer supposed to point to an identical copy of
+the NTBS returned by what() called on the original object or not?
+
    
+
+
    
+Second, is this Note intended to extend to all the derived classes
+in section 19? I.e., does the standard provide any guarantee for
+the effects of what() called on a copy of any of the derived class
+described in section 19?
+
    
+
+
    
+Finally, if the answer to the first question is no, I believe it
+constitutes a defect since throwing an exception object typically
+implies invoking the copy ctor on the object. If the answer is yes,
+then I believe the standard ought to be clarified to spell out
+exactly what the effects are on the copy (i.e., after the copy
+ctor was called).
+
    
+
+
    [Redmond: Yes, this is fuzzy.  The issue of derived classes is
+  fuzzy too.]
    
+
+
+
    [
+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:
    
+
+
    
+Change 18.7.1 [exception] to:
+
    
+
+
    
+
    exception(const exception& e) throw();
+exception& operator=(const exception& e) throw();
    
+
    
+
    
+-4- Effects: Copies an exception object.
+
    
+
    
+ -5- Remarks: The effects of calling what() after assignment are implementation-defined.
+
    
+
    
+-5- Throws: Nothing.  This also applies
+to all standard library-defined classes that derive from exception.
+
    
+
    
+-7- Postcondition: strcmp(what(), e.what()) == 0.  This also applies
+to all standard library-defined classes that derive from exception.
+
    
+
+
    
+
    
+
+
+
+
+
    
+
    473. underspecified ctype calls
    
+
    Section: 22.2.1.1 [locale.ctype] Status: Open
  Submitter: Martin Sebor Date: 2004-07-01
    
 
    View all issues with Open status.
    
 
    Discussion:
    
@@ -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)
+
    
+
    
+
    
+
+
 
 
 
@@ -4619,236 +5362,92 @@ 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.
    
+
    539. partial_sum and adjacent_difference should mention requirements
    
+
    Section: 26.6.3 [partial.sum] Status: Review
+ Submitter: Marc Schoolderman Date: 2006-02-06
    
+
    View all issues with Review 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.
+There are some problems in the definition of partial_sum and
+adjacent_difference in 26.4 [lib.numeric.ops]
 
    
 
 
    
-This guarantee is not present in the final version of TR1.
+Unlike accumulate and inner_product, these functions are not
+parametrized on a "type T", instead, 26.4.3 [lib.partial.sum] simply
+specifies the effects clause as;
 
    
 
-
    
-I'm pretty certain that we never removed it on purpose. Editorial omission? :-)
+
    
+Assigns to every element referred to by iterator i in the range
+[result,result + (last - first)) a value correspondingly equal to
 
    
+
    ((...(* first + *( first + 1)) + ...) + *( first + ( i - result )))
+
    
+
    
 
-
    [
-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.
-]
    
+
    
+And similarly for BinaryOperation. Using just this definition, it seems
+logical to expect that:
+
    
 
 
+
    char i_array[4] = { 100, 100, 100, 100 };
+int  o_array[4];
 
+std::partial_sum(i_array, i_array+4, o_array);
+
    
 
-
    Proposed resolution:
    
 
    
-In 20.5.10.1.3 [lib.func.bind.bind] ([tr.func.bind.bind]), add a new paragraph after p2:
+Is equivalent to
 
    
-
    
-Throws: Nothing unless one of the copy constructors of f, t1, t2, ..., tN
-throws an exception.
-
    
+
+
    int o_array[4] = { 100, 100+100, 100+100+100, 100+100+100+100 };
+
    
 
 
    
-Add a new paragraph after p4:
+i.e. 100, 200, 300, 400, with addition happening in the result type,
+int.
 
    
-
    
-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:
+Yet all implementations I have tested produce 100, -56, 44, -112,
+because they are using an accumulator of the InputIterator's
+value_type, which in this case is char, not int.
 
    
 
-
    
-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:
+The issue becomes more noticeable when the result of the expression *i +
+*(i+1) or binary_op(*i, *i-1) can't be converted to the
+value_type. In a contrived 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:
+
    enum not_int { x = 1, y = 2 };
+...
+not_int e_array[4] = { x, x, y, y };
+std::partial_sum(e_array, e_array+4, o_array);
 
    
 
 
    
-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.
+Is it the intent that the operations happen in the input type, or in
+the result type?
 
    
 
-
    [
-Batavia:  Alan and Pete to work.
-]
    
-
-
-
-
    Proposed resolution:
    
 
    
-1. Change 17.4.3.8/1 to read:
+If the intent is that operations happen in the result type, something
+like this should be added to the "Requires" clause of 26.4.3/4
+[lib.partial.sum]:
 
    
 
 
    
-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.
+The type of *i + *(i+1) or binary_op(*i, *(i+1)) shall meet the
+requirements of CopyConstructible (20.1.3) and Assignable
+(23.1) types.
 
    
 
 
    
-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
- Submitter: Marc Schoolderman Date: 2006-02-06
    
-
    View all issues with Open status.
    
-
    Discussion:
    
-
    
-There are some problems in the definition of partial_sum and
-adjacent_difference in 26.4 [lib.numeric.ops]
-
    
-
-
    
-Unlike accumulate and inner_product, these functions are not
-parametrized on a "type T", instead, 26.4.3 [lib.partial.sum] simply
-specifies the effects clause as;
-
    
-
-
    
-Assigns to every element referred to by iterator i in the range
-[result,result + (last - first)) a value correspondingly equal to
-
    
-
    ((...(* first + *( first + 1)) + ...) + *( first + ( i - result )))
-
    
-
    
-
-
    
-And similarly for BinaryOperation. Using just this definition, it seems
-logical to expect that:
-
    
-
-
-
    char i_array[4] = { 100, 100, 100, 100 };
-int  o_array[4];
-
-std::partial_sum(i_array, i_array+4, o_array);
-
    
-
-
    
-Is equivalent to
-
    
-
-
    int o_array[4] = { 100, 100+100, 100+100+100, 100+100+100+100 };
-
    
-
-
    
-i.e. 100, 200, 300, 400, with addition happening in the result type,
-int.
-
    
-
-
    
-Yet all implementations I have tested produce 100, -56, 44, -112,
-because they are using an accumulator of the InputIterator's
-value_type, which in this case is char, not int.
-
    
-
-
    
-The issue becomes more noticeable when the result of the expression *i +
-*(i+1) or binary_op(*i, *i-1) can't be converted to the
-value_type. In a contrived example:
-
    
-
-
    enum not_int { x = 1, y = 2 };
-...
-not_int e_array[4] = { x, x, y, y };
-std::partial_sum(e_array, e_array+4, o_array);
-
    
-
-
    
-Is it the intent that the operations happen in the input type, or in
-the result type?
-
    
-
-
    
-If the intent is that operations happen in the result type, something
-like this should be added to the "Requires" clause of 26.4.3/4
-[lib.partial.sum]:
-
    
-
-
    
-The type of *i + *(i+1) or binary_op(*i, *(i+1)) shall meet the
-requirements of CopyConstructible (20.1.3) and Assignable
-(23.1) types.
-
    
-
-
    
-(As also required for T in 26.4.1 [lib.accumulate] and 26.4.2
-[lib.inner.product].)
+(As also required for T in 26.4.1 [lib.accumulate] and 26.4.2
+[lib.inner.product].)
 
    
 
 
    
@@ -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);
 
    
+
    
 
 
 
@@ -5129,335 +5775,323 @@ 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].
    
+
    564. stringbuf seekpos underspecified
    
+
    Section: 27.7.1.4 [stringbuf.virtuals] Status: Open
+ Submitter: Martin Sebor Date: 2006-02-23
    
+
    View all other issues in [stringbuf.virtuals].
    
 
    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...
+The   effects  of  the   seekpos()  member   function  of
+basic_stringbuf  simply say  that the  function positions
+the  input and/or  output  sequences  but fail  to  spell out  exactly
+how. This is in contrast  to the detail in which seekoff()
+is described.
 
    
 
 
-
 
    Proposed resolution:
    
+        
    
+
+Change 27.7.1.3, p13 to read:
 
+        
    
+
    
+
    
+-13- Effects: Same as seekoff(off_type(sp), ios_base::beg,
+which). Alters the stream position within the controlled sequences,
+if possible, to correspond to the stream position stored in sp
+(as described below).
+
    
+
      
+
    • If (which & ios_base::in) != 0, positions the input sequence.
      • 
+
    • If (which & ios_base::out) != 0, positions the output sequence.
      • 
+
    • If sp is an invalid stream position, or if the function
+positions neither sequence, the positioning operation fails. If sp
+has not been obtained by a previous successful call to one of the positioning
+functions (seekoff, seekpos, tellg, tellp)
+the effect is undefined.
      • 
+
    
+
    
 
 
 
    [
-Portland: no consensus.
+Kona (2007): A pos_type is a position in a stream by
+definition, so there is no ambiguity as to what it means. Proposed
+Disposition: NAD
 ]
    
 
 
-
    Rationale:
    
 
    [
-Batavia, Bill: The <cstdint> synopsis in TR1 8.11.1 [tr.c99.cinttypes.syn] contains:
+Post-Kona Martin adds:
+I'm afraid I disagree
+with the Kona '07 rationale for marking it NAD. The only text
+that describes precisely what it means to position the input
+or output sequence is in seekoff(). The seekpos() Effects
+clause is inadequate in comparison and the proposed resolution
+plugs the hole by specifying seekpos() in terms of seekoff().
 ]
    
 
-
    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:
-]
    
+
    
+
    565. xsputn inefficient
    
+
    Section: 27.5.2.4.5 [streambuf.virt.put] Status: Open
+ Submitter: Martin Sebor Date: 2006-02-23
    
+
    View all issues with Open status.
    
+
    Discussion:
    
+        
    
 
+streambuf::xsputn()  is  specified  to  have  the  effect  of
+"writing up to  n characters to the output  sequence as if by
+repeated calls to sputc(c)."
 
-
    
-[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]
-
    
+        
    
+        
    
 
+Since  sputc() is required  to call  overflow() when
+(pptr()    ==   epptr())    is   true,    strictly   speaking
+xsputn()  should do  the same.   However, doing  so  would be
+suboptimal in  some interesting cases,  such as in unbuffered  mode or
+when the buffer is basic_stringbuf.
 
+        
    
+        
    
 
+Assuming  calling overflow()  is  not really  intended to  be
+required  and the  wording is  simply  meant to  describe the  general
+effect of appending to the end  of the sequence it would be worthwhile
+to  mention in  xsputn() that  the function  is  not actually
+required to cause a call to overflow().
 
+        
    
 
 
-
    
-
    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:
-
    
+
    Proposed resolution:
    
+        
    
 
-
    template <class Container, class Iterator>
-insert_iterator<Container>
-inserter(Container& x, Iterator i);
-
    
+Add the following sentence  to the xsputn() Effects clause in
+27.5.2.4.5, p1 (N1804):
 
-
    
-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.
-
    
+        
    
+        
        
+            
    
+-1- Effects: Writes up to n characters to the output
+sequence as if by repeated calls to sputc(c). The characters 
+written are obtained from successive elements of the array whose first element
+is designated by s. Writing stops when either n
+characters have been written or a call to sputc(c) would return
+traits::eof(). It is  uspecified whether the function  calls
+overflow() when (pptr() ==  epptr()) becomes true or whether
+it achieves the same effects by other means.
+            
    
+        
        
+        
    
 
-
    
-It would be much better if inserter had the following signature instead:
-
    
+In addition,  I suggest to  add a footnote  to this function  with the
+same text as Footnote 292 to  make it extra clear that derived classes
+are permitted to override xsputn() for efficiency.
 
-
    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 {};
+
    [
+Kona (2007): We want to permit a streambuf that streams output directly
+to a device without making calls to sputc or overflow. We believe that
+has always been the intention of the committee. We believe that the
+proposed wording doesn't accomplish that. Proposed Disposition: Open
+]
    
 
-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);
-}
-
    
 
+
    
+
    568. log2 overloads missing
    
+
    Section: TR1 8.16.4 [tr.c99.cmath.over] Status: New
+ Submitter: Paolo Carlini Date: 2006-03-07
    
+
    View all issues with New status.
    
+
    Discussion:
    
 
    
-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.
+log2 is missing from the list of "additional overloads" in TR1 8.16.4 [tr.c99.cmath.over] p1.
 
    
 
 
    
-To make matters a little more insidious, the above example works today if you
-simply change the first argument to an rvalue:
+Hinnant:  This is a TR1 issue only.  It is fixed in the current (N2135) WD.
 
    
 
-
        inserter(my::my_type(), c);
-
    
 
+
    Proposed resolution:
    
 
    
-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.
+Add log2 to the list of functions in TR1 8.16.4 [tr.c99.cmath.over] p1.
 
    
 
-
    
-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:
    
+
    
+
    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:
    
 
    
-Change 24.2:
-
    
-
-
    
-24.2 Header <iterator> synopsis
+Currently, the Standard Library specifies only a declaration for template class
+char_traits<> and requires the implementation provide two explicit
+specializations: char_traits<char> and char_traits<wchar_t>. I feel the Standard
+should require explicit specializations for all built-in character types, i.e.
+char, wchar_t, unsigned char, and signed char.
 
    
-
    ...
-template <class Container, class Iterator>
-   insert_iterator<Container> inserter(Container& x, Iterator typename Container::iterator i);
-...
-
    
-
    
-
 
    
-Change 24.4.2.5:
+I have put together a paper
+(N1985)
+that describes this in more detail and
+includes all the necessary wording.
 
    
+
    [
+Portland: Jack will rewrite
+N1985
+to propose a primary template that will work with other integral types.
+]
    
 
-
    
-24.4.2.5 Class template insert_iterator
    
-
    ...
-template <class Container, class Iterator>
-   insert_iterator<Container> inserter(Container& x, Iterator typename Container::iterator i);
-...
-
    
-
    
+
    [
+Toronto: issue has grown with addition of char16_t and char32_t.
+]
    
+
+
+
    [
+post Bellevue:
+]
    
 
-
    
-Change 24.4.2.6.5:
-
    
 
 
    
 
    
-24.4.2.6.5 inserter
+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.
 
    
-
    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
-]
    
+
    Proposed resolution:
    
 
 
 
 
 
 
    
-
    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.
    
+
    573. C++0x file positioning should handle modern file sizes
    
+
    Section: 27.4.3 [fpos] Status: Open
+ Submitter: Beman Dawes Date: 2006-04-12
    
+
    View all other issues in [fpos].
    
+
    View all issues with Open status.
    
 
    Discussion:
    
-        
    
+
    
+There are two deficiencies related to file sizes:
+
    
+
      
+
    1. It doesn't appear that the Standard Library is specified in
+      a way that handles modern file sizes, which are often too
+      large to be represented by an unsigned long.
      2. 
 
-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.
+
    2. The std::fpos class does not currently have the ability to
+      set/get file positions.
      3. 
+
    
+
    
+The Dinkumware implementation of the Standard Library as shipped with the Microsoft compiler copes with these issues by:
+
    
+
      
+
    1. Defining fpos_t be long long, which is large enough to
+      represent any file position likely in the foreseeable future.
      2. 
+
+
    2. Adding member functions to class fpos. For example,
+
      fpos_t seekpos() const;
+
      
+
      3. 
+
    
+
    
+Because there are so many types relating to file positions and offsets (fpos_t,
+fpos, pos_type, off_type, streamoff, streamsize, streampos, wstreampos, and
+perhaps more), it is difficult to know if the Dinkumware extensions are
+sufficient. But they seem a useful starting place for discussions, and they do
+represent existing practice.
+
    
+
+
    [
+Kona (2007): We need a paper. It would be nice if someone proposed
+clarifications to the definitions of pos_type and off_type. Currently
+these definitions are horrible. Proposed Disposition: Open
+]
    
 
-        
    
 
 
 
    Proposed resolution:
    
-        
    
+
    
+
    
+
 
-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);
-
    
 
+
    
+
    574. DR 369 Contradicts Text
    
+
    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 Ready status.
    
+
    Discussion:
    
 
    
--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.
+lib.iostream.objects requires that the standard stream objects are never
+destroyed, and it requires that they be destroyed.
+
    
+
    
+DR 369 adds words to say that we really mean for ios_base::Init objects to force
+construction of standard stream objects. It ends, though, with the phrase "these
+stream objects shall be destroyed after the destruction of dynamically ...".
+However, the rule for destruction is stated in the standard: "The objects are
+not destroyed during program execution."
 
    
-
    
 
-        
    
 
-Change the Effects clause of the str() in 27.7.1.2, p2 to
-read:
+
    Proposed resolution:
    
+
    
+Change 27.3 [iostream.objects]/1:
+
    
 
-        
    
 
    
 
    
--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.
+-2- The objects are constructed and the associations are established at
+some time prior to or during the first time an object of class
+ios_base::Init is constructed, and in any case before the body of main
+begins execution.290) The objects are not destroyed during program
+execution.291) If a translation unit includes <iostream&t; or explicitly
+constructs an ios_base::Init object, these stream objects shall be
+constructed before dynamic initialization of non-local objects defined
+later in that translation unit, and these stream objects shall be
+destroyed after the destruction of dynamically initialized non-local
+objects defined later in that translation unit.
 
    
-
-        
    
-
--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.
+Kona (2007): From 27.3 [iostream.objects]/2, strike the words "...and these stream objects
+shall be destroyed after the destruction of dynamically initialized
+non-local objects defined later in that translation unit." Proposed
+Disposition: Review
 ]
    
 
 
@@ -5465,121 +6099,138 @@ 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.
    
+
    580. unused allocator members
    
+
    Section: 20.1.2 [allocator.requirements] Status: Open
+ Submitter: Martin Sebor Date: 2006-06-14
    
+
    View other active issues in [allocator.requirements].
    
+
    View all other issues in [allocator.requirements].
    
+
    View all issues with Open status.
    
+
    Duplicate of: 479
    
 
    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.
+C++ Standard Library  templates that take an allocator  as an argument
+are    required    to    call    the    allocate()    and
+deallocate()  members of the  allocator object  to obtain
+storage.  However, they do not appear to be required to call any other
+allocator      members      such     as      construct(),
+destroy(),           address(),          and
+max_size().  This makes these allocator members less than
+useful in portable programs.
 
         
    
         
    
 
-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().
+It's unclear to me whether the absence of the requirement to use these
+allocator  members  is  an  unintentional  omission  or  a  deliberate
+choice. However,  since the functions exist in  the standard allocator
+and  since  they are  required  to  be  provided by  any  user-defined
+allocator I  believe the standard  ought to be clarified  to explictly
+specify  whether programs  should or  should not  be able  to  rely on
+standard containers calling the functions.
 
         
    
-
-
-
    Proposed resolution:
    
         
    
 
-Change the newoff  column in the last row  of Table 94 to
-read:
+I  propose  that all  containers  be required  to  make  use of  these
+functions.
 
         
    
-
    
+
    [
+Batavia:  We support this resolution.  Martin to provide wording.
+]
    
 
-the end high mark pointer minus the beginning 
-pointer (xend high_mark - xbeg).
+
    [
+pre-Oxford:  Martin provided wording.
+]
    
 
-
    
+    
 
+    
    Proposed resolution:
    
+       
    
 
-
    [
-Kona (2007) Moved to Ready.
-]
    
+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
+first parameters.
 
+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
+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
+shall be obtained "as if" by calling the address() member
+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
+get_allocator().max_size().
 
-
    
-
    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:
    
+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)
+
    
 
    
-The   effects  of  the   seekpos()  member   function  of
-basic_stringbuf  simply say  that the  function positions
-the  input and/or  output  sequences  but fail  to  spell out  exactly
-how. This is in contrast  to the detail in which seekoff()
-is described.
+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
+destroy temporaries.
 
-
    Proposed resolution:
    
-        
    
-
-Change 27.7.1.3, p13 to read:
-
-        
    
-
    
-
    
--13- Effects: Same as seekoff(off_type(sp), ios_base::beg,
-which). Alters the stream position within the controlled sequences,
-if possible, to correspond to the stream position stored in sp
-(as described below).
-
    
-
      
-
    • If (which & ios_base::in) != 0, positions the input sequence.
      • 
-
    • If (which & ios_base::out) != 0, positions the output sequence.
      • 
-
    • If sp is an invalid stream position, or if the function
-positions neither sequence, the positioning operation fails. If sp
-has not been obtained by a previous successful call to one of the positioning
-functions (seekoff, seekpos, tellg, tellp)
-the effect is undefined.
      • 
-
    
-
    
+       
    
 
 
 
    [
-Kona (2007): A pos_type is a position in a stream by
-definition, so there is no ambiguity as to what it means. Proposed
-Disposition: NAD
+Howard: This same paragraph will need some work to accommodate 431.
 ]
    
 
 
 
    [
-Post-Kona Martin adds:
-I'm afraid I disagree
-with the Kona '07 rationale for marking it NAD. The only text
-that describes precisely what it means to position the input
-or output sequence is in seekoff(). The seekpos() Effects
-clause is inadequate in comparison and the proposed resolution
-plugs the hole by specifying seekpos() in terms of seekoff().
+post Oxford:  This would be rendered NAD Editorial by acceptance of
+N2257.
 ]
    
 
 
@@ -5587,596 +6238,552 @@ plugs the hole by specifying seekpos() in terms of seekoff().
 
 
 
    
-
    565. xsputn inefficient
    
-
    Section: 27.5.2.4.5 [streambuf.virt.put] Status: Open
- Submitter: Martin Sebor Date: 2006-02-23
    
+
    582. specialized algorithms and volatile storage
    
+
    Section: 20.6.10.1 [uninitialized.copy] Status: Open
+ Submitter: Martin Sebor Date: 2006-06-14
    
+
    View all other issues in [uninitialized.copy].
    
 
    View all issues with Open status.
    
 
    Discussion:
    
         
    
 
-streambuf::xsputn()  is  specified  to  have  the  effect  of
-"writing up to  n characters to the output  sequence as if by
-repeated calls to sputc(c)."
+The specialized  algorithms [lib.specialized.algorithms] are specified
+as having the general effect of invoking the following expression:
 
         
    
+            
    +new (static_cast<void*>(&*i))
+    typename iterator_traits<ForwardIterator>::value_type (x)
+
+            
    
         
    
 
-Since  sputc() is required  to call  overflow() when
-(pptr()    ==   epptr())    is   true,    strictly   speaking
-xsputn()  should do  the same.   However, doing  so  would be
-suboptimal in  some interesting cases,  such as in unbuffered  mode or
-when the buffer is basic_stringbuf.
+This  expression is  ill-formed  when the  type  of the  subexpression
+&*i is some volatile-qualified T.
 
         
    
+
+
    [
+Batavia:  Lack of support for proposed resolution but agree there is a
+defect.  Howard to look at wording.  Concern that move semantics
+properly expressed if iterator returns rvalue.
+]
    
+
+
+    
+
+    
    Proposed resolution:
    
         
    
 
-Assuming  calling overflow()  is  not really  intended to  be
-required  and the  wording is  simply  meant to  describe the  general
-effect of appending to the end  of the sequence it would be worthwhile
-to  mention in  xsputn() that  the function  is  not actually
-required to cause a call to overflow().
+In order  to allow these algorithms  to operate on  volatile storage I
+propose to change the expression so as to make it well-formed even for
+pointers  to volatile  types.  Specifically,  I propose  the following
+changes to clauses 20 and 24. Change 20.6.4.1, p1 to read:
 
         
    
+            
    +Effects:
 
+typedef typename iterator_traits<ForwardIterator>::pointer    pointer;
+typedef typename iterator_traits<ForwardIterator>::value_type value_type;
 
-
    Proposed resolution:
    
+for (; first != last; ++result, ++first)
+    new (static_cast<void*>(const_cast<pointer>(&*result))
+        value_type (*first);
+
+            
    
         
    
 
-Add the following sentence  to the xsputn() Effects clause in
-27.5.2.4.5, p1 (N1804):
+change 20.6.4.2, p1 to read
 
         
    
-        
        
-            
    
--1- Effects: Writes up to n characters to the output
-sequence as if by repeated calls to sputc(c). The characters 
-written are obtained from successive elements of the array whose first element
-is designated by s. Writing stops when either n
-characters have been written or a call to sputc(c) would return
-traits::eof(). It is  uspecified whether the function  calls
-overflow() when (pptr() ==  epptr()) becomes true or whether
-it achieves the same effects by other means.
-            
    
-        
        
+            
    +Effects:
+
+typedef typename iterator_traits<ForwardIterator>::pointer    pointer;
+typedef typename iterator_traits<ForwardIterator>::value_type value_type;
+
+for (; first != last; ++result, ++first)
+    new (static_cast<void*>(const_cast<pointer>(&*first))
+        value_type (*x);
+
+            
    
         
    
 
-In addition,  I suggest to  add a footnote  to this function  with the
-same text as Footnote 292 to  make it extra clear that derived classes
-are permitted to override xsputn() for efficiency.
+and change 20.6.4.3, p1 to read
 
         
    
+            
    +Effects:
 
+typedef typename iterator_traits<ForwardIterator>::pointer    pointer;
+typedef typename iterator_traits<ForwardIterator>::value_type value_type;
 
-
    [
-Kona (2007): We want to permit a streambuf that streams output directly
-to a device without making calls to sputc or overflow. We believe that
-has always been the intention of the committee. We believe that the
-proposed wording doesn't accomplish that. Proposed Disposition: Open
-]
    
+for (; n--; ++first)
+    new (static_cast<void*>(const_cast<pointer>(&*first))
+        value_type (*x);
+
+            
    
+        
    
 
+In   addition,  since   there   is  no   partial  specialization   for
+iterator_traits<volatile T*>  I propose to  add one
+to parallel such specialization  for <const T*>. Specifically, I
+propose to add the following text to the end of 24.3.1, p3:
 
+        
    
+        
    
 
+and for pointers to volatile as 
 
+        
    
+            
    +namespace std {
+template<class T> struct iterator_traits<volatile T*> {
+typedef ptrdiff_t difference_type;
+typedef T value_type;
+typedef volatile T* pointer;
+typedef volatile T& reference;
+typedef random_access_iterator_tag iterator_category;
+};
+}
 
-
    
-
    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.
+Note that  the change to  iterator_traits isn't necessary
+in order to implement the  specialized algorithms in a way that allows
+them to operate on volatile  strorage. It is only necesassary in order
+to specify  their effects in terms  of iterator_traits as
+is  done here.   Implementations can  (and some  do) achieve  the same
+effect by means of function template overloading.
 
         
    
+    
 
 
-
    Proposed resolution:
    
+
+
    
+
    585. facet error reporting
    
+
    Section: 22.2 [locale.categories] Status: Open
+ Submitter: Martin Sebor, Paolo Carlini Date: 2006-06-22
    
+
    View other active issues in [locale.categories].
    
+
    View all other issues in [locale.categories].
    
+
    View all issues with Open status.
    
+
    Discussion:
    
         
    
 
-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.
+Section  22.2, paragraph 2  requires facet  get() members
+that    take    an    ios_base::iostate&    argument,
+err,  to   ignore  the  (initial)   value  of  the
+argument, but to set it to ios_base::failbit in case of a
+parse error.
 
         
    
         
    
 
-Specifically, change 27.6.1.2.3, p14 as follows:
+We  believe  there  are  a   few  minor  problems  with  this  blanket
+requirement  in   conjunction  with   the  wording  specific   to  each
+get() member function.
 
         
    
-
-            
    
         
    
 
-Effects:  Behaves as  an unformatted  input function
-(as   described   in   27.6.1.2.127.6.1.3,   paragraph
-1).
+First,  besides get()  there are  other  member functions
+with     a      slightly     different     name      (for     example,
+get_date()). It's not completely clear that the intent of
+the  paragraph  is  to  include  those  as  well,  and  at  least  one
+implementation has interpreted the requirement literally.
 
         
    
-            
    
         
    
 
-And change 27.6.2.5.3, p7 as follows:
+Second,    the     requirement    to    "set     the    argument    to
+ios_base::failbit  suggests that  the  functions are  not
+permitted    to   set    it   to    any   other    value    (such   as
+ios_base::eofbit,   or   even  ios_base::eofbit   |
+ios_base::failbit).
 
         
    
-
-            
    
         
    
 
-Effects: Behaves  as an unformatted  output function
-(as   described   in   27.6.2.5.127.6.2.6,   paragraph
-1).
+However, 22.2.2.1.2, p5 (Stage  3 of num_get parsing) and
+p6 (bool parsing)  specifies that the do_get
+functions  perform err |=  ios_base::eofbit, which
+contradicts  the earlier  requirement to  ignore  err's initial
+value.
 
         
    
-            
    
+        
    
 
+22.2.6.1.2,  p1  (the  Effects  clause of  the  money_get
+facet's  do_get  member  functions) also  specifies  that
+err's initial  value be used to  compute the final
+value  by  ORing  it  with  either  ios_base::failbit  or
+withios_base::eofbit | ios_base::failbit.
 
-
    [
-Kona (2007): Proposed Disposition: Ready
-]
    
+        
    
+    
 
+    
    Proposed resolution:
    
+        
    
 
+We believe the  intent is for all facet member  functions that take an
+ios_base::iostate& argument to:
 
+        
    
+            
      
+                
    • 
 
+ignore the initial value of the err argument,
 
-
      
-
      568. log2 overloads missing
      
-
      Section: TR1 8.16.4 [tr.c99.cmath.over] Status: New
- Submitter: Paolo Carlini Date: 2006-03-07
      
-
      View all issues with New status.
      
-
      Discussion:
      
-
      
-log2 is missing from the list of "additional overloads" in TR1 8.16.4 [tr.c99.cmath.over] p1.
-
      
+                
      • 
+                
    • 
 
-
      
-Hinnant:  This is a TR1 issue only.  It is fixed in the current (N2135) WD.
-
      
+reset err  to ios_base::goodbit prior
+to any further processing,
 
+                
      • 
+                
    • 
 
-
      Proposed resolution:
      
-
      
-Add log2 to the list of functions in TR1 8.16.4 [tr.c99.cmath.over] p1.
-
      
+and       set      either       ios_base::eofbit,      or
+ios_base::failbit, or both in err, as
+appropriate,  in response  to  reaching the  end-of-file  or on  parse
+error, or both.
 
+                
      • 
+            
    
+        
    
 
+To that effect we propose to change 22.2, p2 as follows:
 
+        
    
+        
    
 
+The  put()  members  make  no  provision  for  error
+reporting.   (Any  failures of  the  OutputIterator  argument must  be
+extracted   from  the   returned  iterator.)    Unless  otherwise
+specified, the get()  members  that
+take an  ios_base::iostate& argument whose value
+they  ignore,  but  set  to  ios_base::failbit  in  case  of  a  parse
+error.,   err,   start  by   evaluating
+err  =   ios_base::goodbit,  and  may   subsequently  set
+err     to     either     ios_base::eofbit,     or
+ios_base::failbit,     or     ios_base::eofbit    |
+ios_base::failbit in response to reaching the end-of-file or in
+case of a parse error, or both, respectively.
 
-
    
-
    570. Request adding additional explicit specializations of char_traits
    
-
    Section: 21.1 [char.traits] Status: Open
- Submitter: Jack Reeves Date: 2006-04-06
    
-
    View all issues with Open status.
    
-
    Discussion:
    
-
    
-Currently, the Standard Library specifies only a declaration for template class
-char_traits<> and requires the implementation provide two explicit
-specializations: char_traits<char> and char_traits<wchar_t>. I feel the Standard
-should require explicit specializations for all built-in character types, i.e.
-char, wchar_t, unsigned char, and signed char.
-
    
-
    
-I have put together a paper
-(N1985)
-that describes this in more detail and
-includes all the necessary wording.
-
    
-
    [
-Portland: Jack will rewrite
-N1985
-to propose a primary template that will work with other integral types.
-]
    
-
+        
    
+    
+    
 
    [
-Toronto: issue has grown with addition of char16_t and char32_t.
+Kona (2007): We need to change the proposed wording to clarify that the
+phrase "the get members" actually denotes get(), get_date(), etc.
+Proposed Disposition: Open
 ]
    
 
 
 
-
    Proposed resolution:
    
-
-
-
-
 
 
    
-
    573. C++0x file positioning should handle modern file sizes
    
-
    Section: 27.4.3 [fpos] Status: Open
- Submitter: Beman Dawes Date: 2006-04-12
    
-
    View all other issues in [fpos].
    
+
    588. requirements on zero sized tr1::arrays and other details
    
+
    Section: 23.2.1 [array] Status: Open
+ Submitter: Gennaro Prota Date: 2006-07-18
    
+
    View other active issues in [array].
    
+
    View all other issues in [array].
    
 
    View all issues with Open status.
    
 
    Discussion:
    
 
    
-There are two deficiencies related to file sizes:
+The wording used for section 23.2.1 [lib.array] seems to be subtly
+ambiguous about zero sized arrays (N==0). Specifically:
 
    
-
      
-
    1. It doesn't appear that the Standard Library is specified in
-      a way that handles modern file sizes, which are often too
-      large to be represented by an unsigned long.
      2. 
-
-
    2. The std::fpos class does not currently have the ability to
-      set/get file positions.
      3. 
-
    
 
    
-The Dinkumware implementation of the Standard Library as shipped with the Microsoft compiler copes with these issues by:
+* "An instance of array<T, N> stores N elements of type T, so that
+[...]"
 
    
-
      
-
    1. Defining fpos_t be long long, which is large enough to
-      represent any file position likely in the foreseeable future.
      2. 
-
-
    2. Adding member functions to class fpos. For example,
-
      fpos_t seekpos() const;
-
      
-
      3. 
-
    
 
    
-Because there are so many types relating to file positions and offsets (fpos_t,
-fpos, pos_type, off_type, streamoff, streamsize, streampos, wstreampos, and
-perhaps more), it is difficult to know if the Dinkumware extensions are
-sufficient. But they seem a useful starting place for discussions, and they do
-represent existing practice.
+Does this imply that a zero sized array object stores 0 elements, i.e.
+that it cannot store any element of type T? The next point clarifies
+the rationale behind this question, basically how to implement begin()
+and end():
 
    
-
-
    [
-Kona (2007): We need a paper. It would be nice if someone proposed
-clarifications to the definitions of pos_type and off_type. Currently
-these definitions are horrible. Proposed Disposition: Open
-]
    
-
-
-
-
    Proposed resolution:
    
 
    
+* 23.2.1.5 [lib.array.zero], p2: "In the case that N == 0, begin() ==
+end() == unique value."
 
    
+
    
+What does "unique" mean in this context? Let's consider the following
+possible implementations, all relying on a partial specialization:
+
    
+
    a)
+    template< typename T >
+    class array< T, 0 > {
+    
+        ....
 
+        iterator begin()
+        { return iterator( reinterpret_cast< T * >( this ) ); }
+        ....
 
+    };
+
    
+
    
+This has been used in boost, probably intending that the return value
+had to be unique to the specific array object and that array couldn't
+store any T. Note that, besides relying on a reinterpret_cast, has
+(more than potential) alignment problems.
+
    
+
    b)
+    template< typename T >
+    class array< T, 0 > {
+    
+        T t;
 
+        iterator begin()
+        { return iterator( &t ); }
+        ....
 
-
-
    
-
    574. DR 369 Contradicts Text
    
-
    Section: 27.3 [iostream.objects] Status: Review
- Submitter: Pete Becker Date: 2006-04-18
    
-
    View all other issues in [iostream.objects].
    
-
    View all issues with Review status.
    
-
    Discussion:
    
+    };
+
    
 
    
-lib.iostream.objects requires that the standard stream objects are never
-destroyed, and it requires that they be destroyed.
+This provides a value which is unique to the object and to the type of
+the array, but requires storing a T. Also, it would allow the user to
+mistakenly provide an initializer list with one element.
 
    
 
    
-DR 369 adds words to say that we really mean for ios_base::Init objects to force
-construction of standard stream objects. It ends, though, with the phrase "these
-stream objects shall be destroyed after the destruction of dynamically ...".
-However, the rule for destruction is stated in the standard: "The objects are
-not destroyed during program execution."
+A slight variant could be returning *the* null pointer of type T
 
    
-
-
-
    Proposed resolution:
    
+
        return static_cast<T*>(0);
+
    
 
    
-Change 27.3 [iostream.objects]/1:
+In this case the value would be unique to the type array<T, 0> but not
+to the objects (all objects of type array<T, 0> with the same value
+for T would yield the same pointer value).
 
    
-
-
    
 
    
--2- The objects are constructed and the associations are established at
-some time prior to or during the first time an object of class
-ios_base::Init is constructed, and in any case before the body of main
-begins execution.290) The objects are not destroyed during program
-execution.291) If a translation unit includes <iostream&t; or explicitly
-constructs an ios_base::Init object, these stream objects shall be
-constructed before dynamic initialization of non-local objects defined
-later in that translation unit, and these stream objects shall be
-destroyed after the destruction of dynamically initialized non-local
-objects defined later in that translation unit.
+Furthermore this is inconsistent with what the standard requires from
+allocation functions (see library issue 9).
 
    
-
    
-
-
-
    [
-Kona (2007): From 27.3 [iostream.objects]/2, strike the words "...and these stream objects
-shall be destroyed after the destruction of dynamically initialized
-non-local objects defined later in that translation unit." Proposed
-Disposition: Review
-]
    
-
-
-
-
-
-
    
-
    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.
+c) same as above but with t being a static data member; again, the
+value would be unique to the type, not to the object.
 
    
-
-
-
    Proposed resolution:
    
 
    
-Option 1:
+d) to avoid storing a T *directly* while disallowing the possibility
+to use a one-element initializer list a non-aggregate nested class
+could be defined
 
    
-
+
        struct holder { holder() {} T t; } h;
+
    
 
    
-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.
+and then begin be defined as
+
    
+
     iterator begin() { return &h.t; }
+
    
+
    
+But then, it's arguable whether the array stores a T or not.
+Indirectly it does.
 
    
-
 
    
-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
+Now, on different issues:
 
    
-
-
    iterator q1=a.erase(q);
-
    
-
 
    
-works as expected, while
+* what's the effect of calling assign(T&) on a zero-sized array? There
+seems to be only mention of front() and back(), in 23.2.1 [lib.array]
+p4 (I would also suggest to move that bullet to section 23.2.1.5
+[lib.array.zero], for locality of reference)
 
    
-
-
    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.
+* (minor) the opening paragraph of 23.2.1 [lib.array] wording is a bit
+inconsistent with that of other sequences: that's not a problem in
+itself, but compare it for instance with "A vector is a kind of
+sequence that supports random access iterators"; though the intent is
+obvious one might argue that the wording used for arrays doesn't tell
+what an array is, and relies on the reader to infer that it is what
+the <array> header defines.
+
    
+
    
+* it would be desiderable to have a static const data member of type
+std::size_t, with value N, for usage as integral constant expression
 
    
-
-
-
-
    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.
+* section 23.1 [lib.container.requirements] seem not to consider
+fixed-size containers at all, as it says: "[containers] control
+allocation and deallocation of these objects [the contained objects]
+through constructors, destructors, *insert and erase* operations"
+
    
+
    
+* max_size() isn't specified: the result is obvious but, technically,
+it relies on table 80: "size() of the largest possible container"
+which, again, doesn't seem to consider fixed size containers
 
    
 
+
+
    Proposed resolution:
    
 
    
-Post Toronto:  There does not at this time appear to be consensus with the Portland consensus. 
 
    
 
 
+
    [
+Kona (2007): requirements on zero sized tr1::arrays and other details
+Issue 617: std::array is a sequence that doesn't satisfy the sequence
+requirements? Alisdair will prepare a paper. Proposed Disposition: Open
+]
    
+
+
 
 
 
 
    
-
    580. unused allocator members
    
-
    Section: 20.1.2 [allocator.requirements] Status: Open
- Submitter: Martin Sebor Date: 2006-06-14
    
-
    View other active issues in [allocator.requirements].
    
-
    View all other issues in [allocator.requirements].
    
-
    View all issues with Open status.
    
-
    Duplicate of: 479
    
+
    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:
    
-        
    
-
-C++ Standard Library  templates that take an allocator  as an argument
-are    required    to    call    the    allocate()    and
-deallocate()  members of the  allocator object  to obtain
-storage.  However, they do not appear to be required to call any other
-allocator      members      such     as      construct(),
-destroy(),           address(),          and
-max_size().  This makes these allocator members less than
-useful in portable programs.
-
-        
    
-        
    
-
-It's unclear to me whether the absence of the requirement to use these
-allocator  members  is  an  unintentional  omission  or  a  deliberate
-choice. However,  since the functions exist in  the standard allocator
-and  since  they are  required  to  be  provided by  any  user-defined
-allocator I  believe the standard  ought to be clarified  to explictly
-specify  whether programs  should or  should not  be able  to  rely on
-standard containers calling the functions.
+
    
+TR1 introduced, in the C compatibility chapter, the function
+fabs(complex<T>):
+
    
+
    ----- SNIP -----
+8.1.1 Synopsis                                [tr.c99.cmplx.syn]
 
-        
    
-        
    
+  namespace std {
+  namespace tr1 {
+[...]
+  template<class T> complex<T> fabs(const complex<T>& x);
+  } // namespace tr1
+  } // namespace std
 
-I  propose  that all  containers  be required  to  make  use of  these
-functions.
+[...]
 
-        
    
-
    [
-Batavia:  We support this resolution.  Martin to provide wording.
-]
    
+8.1.8 Function fabs                          [tr.c99.cmplx.fabs]
 
-
    [
-pre-Oxford:  Martin provided wording.
-]
    
+1 Effects: Behaves the same as C99 function cabs, defined in
+  subclause 7.3.8.1.
+----- SNIP -----
+
    
 
-    
+
    
+The current C++0X draft document (n2009.pdf) adopted this
+definition in chapter 26.3.1 (under the comment // 26.3.7 values)
+and 26.3.7/7.
+
    
+
    
+But in C99 (ISO/IEC 9899:1999 as well as the 9899:TC2 draft document
+n1124), the referenced subclause reads
+
    
 
-    
    Proposed resolution:
    
-       
    
+
    ----- SNIP -----
+7.3.8.1 The cabs functions
 
-Specifically, I propose to change 23.1 [container.requirements],
-p9 as follows:
+  Synopsis
 
-       
    
-           
    
-
    
--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.
+1 #include <complex.h>
+  double cabs(double complex z);
+  float cabsf(float complex z);
+  long double cabsl(long double z);
 
-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.
+  Description
 
-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.
+2 The cabs functions compute the complex absolute value (also called
+  norm, modulus, or magnitude) of z.
 
-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
-type.
+  Returns
 
-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().
+3 The cabs functions return the complex absolute value.
+----- SNIP -----
+
    
 
-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)
+
    
+Note that the return type of the cabs*() functions is not a complex
+type.  Thus, they are equivalent to the already well established
+  template<class T> T abs(const complex<T>& x);
+(26.2.7/2 in ISO/IEC 14882:1998, 26.3.7/2 in the current draft
+document n2009.pdf).
 
    
 
    
-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.
+So either the return value of fabs() is specified wrongly, or fabs()
+does not behave the same as C99's cabs*().
 
    
-           
    
-       
    
-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
-destroy temporaries.
-
-       
    
-
 
-
    [
-Howard: This same paragraph will need some work to accommodate 431.
-]
    
+Possible Resolutions
 
+
    
+This depends on the intention behind the introduction of fabs().
+
    
+
    
+If the intention was to provide a /complex/ valued function that
+calculates the magnitude of its argument, this should be
+explicitly specified.  In TR1, the categorization under "C
+compatibility" is definitely wrong, since C99 does not provide
+such a complex valued function.
+
    
+
    
+Also, it remains questionable if such a complex valued function
+is really needed, since complex<T> supports construction and
+assignment from real valued arguments.  There is no difference
+in observable behaviour between
+
    
+
      complex<double> x, y;
+  y = fabs(x);
+  complex<double> z(fabs(x));
+
    
+
    
+and
+
    
+
      complex<double> x, y;
+  y = abs(x);
+  complex<double> z(abs(x));
+
    
+
    
+If on the other hand the intention was to provide the intended
+functionality of C99, fabs() should be either declared deprecated
+or (for C++0X) removed from the standard, since the functionality
+is already provided by the corresponding overloads of abs().
+
    
 
 
    [
-post Oxford:  This would be rendered NAD Editorial by acceptance of
-N2257.
+Bellevue:
 ]
    
 
 
+
    
+Bill believes that abs() is a suitable overload. We should remove fabs().
+
    
 
 
+
    Proposed resolution:
    
 
-
    
-
    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:
    
-        
    
+
    
+Change the synopsis in 26.3.1 [complex.synopsis]:
+
    
 
-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:
+
    template<class T> complex<T> fabs(const complex<T>&);
+
    
 
-        
    
+
    
+Remove 26.3.7 [complex.value.ops], p7:
+
    
 
+
    
+
    template<class T> complex<T> fabs(const complex<T>& x);
+
    
+
    
 
    
-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).
+-7- Effects: Behaves the same as C99 function cabs, defined in subclause 7.3.8.1.
 
    
+
    
+
    
+
 
-    
 
 
    [
-Kona (2007): Proposed Disposition: Ready
+Kona (2007): Change the return type of fabs(complex) to T. 
+Proposed Disposition: Ready
 ]
    
 
 
@@ -6184,387 +6791,3164 @@ Kona (2007): Proposed Disposition: Ready
 
 
 
    
-
    582. specialized algorithms and volatile storage
    
-
    Section: 20.6.4.1 [uninitialized.copy] Status: Open
- Submitter: Martin Sebor Date: 2006-06-14
    
-
    View other active issues in [uninitialized.copy].
    
-
    View all other issues in [uninitialized.copy].
    
-
    View all issues with Open status.
    
+
    596. 27.8.1.3 Table 112 omits "a+" and "a+b" modes
    
+
    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 Ready status.
    
 
    Discussion:
    
-        
    
-
-The specialized  algorithms [lib.specialized.algorithms] are specified
-as having the general effect of invoking the following expression:
-
-        
    
-            
    -new (static_cast<void*>(&*i))
-    typename iterator_traits<ForwardIterator>::value_type (x)
-
-            
    
-        
    
-
-This  expression is  ill-formed  when the  type  of the  subexpression
-&*i is some volatile-qualified T.
-
-        
    
+
    
+In testing 27.8.1.4 [filebuf.members], Table 112 (in the latest N2009 draft), we invoke  
+
    
+
       ostr.open("somename", ios_base::out | ios_base::in | ios_base::app)
+
    
+
    
+and we expect the open to fail, because out|in|app is not listed in
+Table 92, and just before the table we see very specific words:
+
    
+
    
+  If mode is not some combination of flags shown in the table 
+  then the open fails.
+
    
+
    
+But the corresponding table in the C standard, 7.19.5.3, provides two
+modes "a+" and "a+b", to which the C++ modes out|in|app and
+out|in|app|binary would presumably apply.
+
    
+
    
+We would like to argue that the intent of Table 112 was to match the
+semantics of 7.19.5.3 and that the omission of "a+" and "a+b" was
+unintentional.  (Otherwise there would be valid and useful behaviors
+available in C file I/O which are unavailable using C++, for no
+valid functional reason.)
+
    
+
    
+We further request that the missing modes be explicitly restored to
+the WP, for inclusion in C++0x.
+
    
 
 
    [
-Batavia:  Lack of support for proposed resolution but agree there is a
-defect.  Howard to look at wording.  Concern that move semantics
-properly expressed if iterator returns rvalue.
+Martin adds:
 ]
    
 
 
-    
+
    
+...besides "a+" and "a+b" the C++ table is also missing a row
+for a lone app bit which in at least two current implementation
+as well as in Classic Iostreams corresponds to the C stdio "a"
+mode and has been traditionally documented as implying ios::out.
+Which means the table should also have a row for in|app meaning
+the same thing as "a+" already proposed in the issue.
+
    
 
-    
    Proposed resolution:
    
-        
    
 
-In order  to allow these algorithms  to operate on  volatile storage I
-propose to change the expression so as to make it well-formed even for
-pointers  to volatile  types.  Specifically,  I propose  the following
-changes to clauses 20 and 24. Change 20.6.4.1, p1 to read:
+
    Proposed resolution:
    
+
    
+Add to the table "File open modes" in 27.8.1.4 [filebuf.members]:
+
    
 
-        
    
-            
    -Effects:
+
    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
     File open modes
    ios_base Flag combinationstdio equivalent
    binaryinouttruncapp 
        +     "w"
        +   + "a"
            + "a"
        + +   "w"
      +       "r"
      + +     "r+"
      + + +   "w+"
      + +   + "a+"
      +     + "a+"
    +   +     "wb"
    +   +   + "ab"
    +       + "ab"
    +   + +   "wb"
    + +       "rb"
    + + +     "r+b"
    + + + +   "w+b"
    + + +   + "a+b"
    + +     + "a+b"
    
+
    
+
+
+
+
    [
+Kona (2007) Added proposed wording and moved to Review.
+]
    
+
+
+
+
+
+
    
+
    597. Decimal: The notion of 'promotion' cannot be emulated by user-defined types.
    
+
    Section: TRDecimal 3.2 [trdec.types.types] Status: Open
+ Submitter: Daveed Vandevoorde Date: 2006-04-05
    
+
    View other active issues in [trdec.types.types].
    
+
    View all other issues in [trdec.types.types].
    
+
    View all issues with Open status.
    
+
    Discussion:
    
+
    
+In a private email, Daveed writes:
+
    
+
    
+
    
+I am not familiar with the C TR, but my guess is that the
+class type approach still won't match a built-in type
+approach because the notion of "promotion" cannot be
+emulated by user-defined types.
+
    
+
    
+Here is an example:
+
    
+
    
+
    +		 struct S {
+		   S(_Decimal32 const&);  // Converting constructor
+		 };
+		 void f(S);
+
+		 void f(_Decimal64);
+
+		 void g(_Decimal32 d) {
+		   f(d);
+		 }
+
    
+
+
    
+
    
+If _Decimal32 is a built-in type, the call f(d) will likely
+resolve to f(_Decimal64) because that requires only a
+promotion, whereas f(S) requires a user-defined conversion.
+
    
+
    
+If _Decimal32 is a class type, I think the call f(d) will be
+ambiguous because both the conversion to _Decimal64 and the
+conversion to S will be user-defined conversions with neither
+better than the other.
+
    
+
    
+
    
+Robert comments:
+
    
+
    
+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:
+
    
+
                     _Decimal32 d1;
+                 d1.operator+=(5);  // If d1 is a builtin type, this won't compile.
+
    
+
    
+In preparing the decimal TR, we have three options:
+
    
+
      
+
    1. require that the decimal types be class types
      2. 
+
    2. require that the decimal types be builtin types, like float and double
      3. 
+
    3. specify a library of class types, but allow enough implementor
+latitude that a conforming implementation could instead provide builtin
+types
      4. 
+
    
+
    
+We decided as a group to pursue option #3, but that approach implies
+that implementations may not agree on the semantics of certain use
+cases (first example, above), or on whether certain other cases are
+well-formed (second example). Another potentially important problem is
+that, under the present definition of POD, the decimal classes are not
+POD types, but builtins will be.
+
    
+
    Note that neither example above implies any problems with respect to
+C-to-C++ compatibility, since neither example can be expressed in C.
+
    
+
+
+
    Proposed resolution:
    
+
+
+
+
+
+
    
+
    606. Decimal: allow narrowing conversions
    
+
    Section: TRDecimal 3.2 [trdec.types.types] Status: Open
+ Submitter: Martin Sebor Date: 2006-06-15
    
+
    View other active issues in [trdec.types.types].
    
+
    View all other issues in [trdec.types.types].
    
+
    View all issues with Open status.
    
+
    Discussion:
    
+
    
+In c++std-lib-17205, Martin writes:
+
    
+
    ...was it a deliberate design choice to make narrowing
+assignments ill-formed while permitting narrowing compound assignments?
+For instance:
+
    
+
          decimal32 d32;
+      decimal64 d64;
+
+      d32 = 64;     // error
+      d32 += 64;    // okay
+
    
+
    
+In c++std-lib-17229, Robert responds:
+
    
+
    It is a vestige of an old idea that I forgot to remove
+from the paper. Narrowing assignments should be permitted. The bug is
+that the converting constructors that cause narrowing should not be
+explicit. Thanks for pointing this out.
+
    
+
+
    Proposed resolution:
    
+
    
+1.  In "3.2.2 Class decimal32" synopsis, remove the explicit specifier from the narrowing conversions:
+
    
+
                    // 3.2.2.2 conversion from floating-point type:
+                explicit decimal32(decimal64 d64);
+                explicit decimal32(decimal128 d128);
+
    
+
    
+2.  Do the same thing in "3.2.2.2. Conversion from floating-point type."
+
    
+
    
+3.  In "3.2.3 Class decimal64" synopsis, remove the explicit specifier from the narrowing conversion:
+
    
+
                    // 3.2.3.2 conversion from floating-point type:
+                explicit decimal64(decimal128 d128);
+
    
+
    
+4.  Do the same thing in "3.2.3.2. Conversion from floating-point type."
+
    
+
+
    [
+Redmond: We prefer explicit conversions for narrowing and implicit for widening.
+]
    
+
+
+
+
+
+
+
    
+
    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 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 insufficient for the following reasons:
+
    
+
+
      
+
    1. Doesn't define what that value received is.
      2. 
+
    2. Doesn't state the result is repeatable
      3. 
+
    3.  Doesn't require that doing addition, subtraction and other
+operations on all values is defined behaviour.
      4. 
+
    
+
+
    [
+Batavia: Related to
+N2144.
+Pete: is there an ISO definition of modulo?  Underflow on signed behavior is undefined.
+]
    
+
+
+
    [
+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 amended to:
+
    
+
+
    
+A type is modulo if, it is possible to add two positive numbers
+and have a result that wraps around to a third number that is less.
+given any operation involving +,- or * on values of that type whose value
+would fall outside the range [min(), max()], then the value returned
+differs from the true value by an integer multiple of (max() - min() +
+1).
+
    
+
+
+
+
+
+
+
    
+
    614. std::string allocator requirements still inconsistent
    
+
    Section: 21.3 [basic.string] Status: Open
+ Submitter: Bo Persson Date: 2006-12-05
    
+
    View other active issues in [basic.string].
    
+
    View all other issues in [basic.string].
    
+
    View all issues with Open status.
    
+
    Discussion:
    
+
    
+This is based on N2134, where 21.3.1/2 states:
+"... The Allocator object used shall be a copy of the Allocator object 
+passed to the basic_string object's constructor or, if the constructor does 
+not take an Allocator argument, a copy of a default-constructed Allocator 
+object."
+
    
+
    
+Section 21.3.2/1 lists two constructors:
+
    
+
    basic_string(const basic_string<charT,traits,Allocator>& str );
+
+basic_string(const basic_string<charT,traits,Allocator>& str ,
+             size_type pos , size_type n = npos,
+             const Allocator& a = Allocator());
+
    
+
    
+and then says "In the first form, the Allocator value used is copied from 
+str.get_allocator().", which isn't an option according to 21.3.1.
+
    
+
    [
+Batavia:  We need blanket statement to the effect of:
+]
    
+
+
+
      
+
    1. If an allocator is passed in, use it, or,
      2. 
+
    2. If a string is passed in, use its allocator.
      3. 
+
    
+
    [
+Review constructors and functions that return a string; make sure we follow these
+rules (substr, operator+, etc.).  Howard to supply wording.
+]
    
+
+
+
    [
+Bo adds:  The new container constructor which takes only a size_type is not
+consistent with 23.1 [container.requirements], p9 which says in part:
+
+
    
+All other constructors for these container types take an
+Allocator& argument (20.1.2), an allocator whose value type
+is the same as the container's value type. A copy of this argument is
+used for any memory allocation performed, by these constructors and by
+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:
    
+
    
+
    
+
+
+
+
+
+
    
+
    617. std::array is a sequence that doesn't satisfy the sequence requirements?
    
+
    Section: 23.2.1 [array] Status: Open
+ Submitter: Bo Persson Date: 2006-12-30
    
+
    View other active issues in [array].
    
+
    View all other issues in [array].
    
+
    View all issues with Open status.
    
+
    Discussion:
    
+
    
+The <array> header is given under 23.2 [sequences].
+23.2.1 [array]/paragraph 3 says:
+
    
+
    
+"Unless otherwise specified, all array operations are as described in
+23.1 [container.requirements]".
+
    
+
    
+However, array isn't mentioned at all in section 23.1 [container.requirements].
+In particular, Table 82 "Sequence requirements" lists several operations (insert, erase, clear) 
+that std::array does not have in 23.2.1 [array].
+
    
+
    
+Also, Table 83 "Optional sequence operations" lists several operations that 
+std::array does have, but array isn't mentioned.
+
    
+
+
+
    Proposed resolution:
    
+
    
+
    
+
+
+
+
+
+
    
+
    618. valarray::cshift() effects on empty array
    
+
    Section: 26.5.2.7 [valarray.members] Status: Ready
+ Submitter: Gabriel Dos Reis Date: 2007-01-10
    
+
    View all issues with Ready status.
    
+
    Discussion:
    
+
    
+I would respectfully request an issue be opened with the intention to
+clarify the wording for size() == 0 for cshift.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Change 26.5.2.7 [valarray.members], paragraph 10:
+
    
+
+
    
+
+
    valarray<T> cshift(int n) const;
+
    
+
+
    
+
    
+This function returns an object of class valarray<T>, of
+length size(), each of whose elements I is
+(*this)[(I + n ) % size()]. Thus, if element zero is taken as
+the leftmost element, a positive value of n shifts the elements
+circularly left n places. that is a circular shift of *this. If
+element zero is taken as the leftmost element, a non-negative value of
+n shifts the elements circularly left n places and a
+negative value of n shifts the elements circularly right
+-n places.
+
    
+
    
+
    
+
+
+
+
    Rationale:
    
+
    
+We do not believe that there is any real ambiguity about what happens
+when size() == 0, but we do believe that spelling this out as a C++
+expression causes more trouble that it solves. The expression is
+certainly wrong when n < 0, since the sign of % with negative arguments
+is implementation defined.
+
    
+
+
+
    [
+Kona (2007) Changed proposed wording, added rationale and set to Review.
+]
    
+
+
+
+
+
+
    
+
    629. complex insertion and locale dependence
    
+
    Section: 26.3.6 [complex.ops] Status: Ready
+ Submitter: Gabriel Dos Reis Date: 2007-01-28
    
+
    View all other issues in [complex.ops].
    
+
    View all issues with Ready status.
    
+
    Discussion:
    
+
    
+is there an issue opened for (0,3) as complex number with
+the French local?  With the English local, the above parses as an
+imaginery complex number.  With the French locale it parses as a
+real complex number.
+
    
+
+
    
+Further notes/ideas from the lib-reflector, messages 17982-17984:
+
    
+
+
    
+
    
+Add additional entries in num_punct to cover the complex separator (French would be ';').
+
    
+
    
+Insert a space before the comma, which should eliminate the ambiguity.
+
    
+
    
+Solve the problem for ordered sequences in general, perhaps with a
+dedicated facet.  Then complex should use that solution.
+
    
+
    
+
+
    [
+Bellevue:
+]
    
+
+
+
    
+
    
+After much discussion, we agreed on the following: Add a footnote:
+
    
+
    
+[In a locale in which comma is being used as a decimal point character,
+inserting "showbase" into the output stream forces all outputs to show
+an explicit decimal point character; then all inserted complex sequences
+will extract unambiguously.]
+
    
+
    
+And move this to READY status.
+
    
+
    
+
+
+
    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.]
+
    
+
+
+
+
+
+
    
+
    630. arrays of valarray
    
+
    Section: 26.5.2.1 [valarray.cons] Status: Open
+ Submitter: Martin Sebor Date: 2007-01-28
    
+
    View all other issues in [valarray.cons].
    
+
    View all issues with Open status.
    
+
    Discussion:
    
+        
    
+
+Section 26.1 [numeric.requirements], p1     suggests     that     a
+valarray  specialization on  a  type T  that
+satisfies  the requirements enumerated  in the  paragraph is  itself a
+valid  type   on  which  valarray   may  be  instantiated
+(Footnote       269        makes       this       clear).        I.e.,
+valarray<valarray<T>  > is  valid as  long as
+T   is   valid.    However,  since   implementations   of
+valarray are permitted to initialize storage allocated by
+the class by  invoking the default ctor of  T followed by
+the    copy    assignment    operator,   such    implementations    of
+valarray   wouldn't  work  with   (perhaps  user-defined)
+specializations of valarray whose assignment operator had
+undefined behavior when the size of its argument didn't match the size
+of *this.  By "wouldn't work" I mean that it would
+be  impossible  to resize  such  an array  of  arrays  by calling  the
+resize() member  function on it if the  function used the
+copy  assignment operator  after constructing  all elements  using the
+default  ctor (e.g.,  by invoking  new  value_type[N]) to
+obtain default-initialized storage) as it's permitted to do.
+
+        
    
+        
    
+
+Stated      more     generally,      the      problem     is      that
+valarray<valarray<T>  >::resize(size_t) isn't
+required or  guaranteed to have well-defined semantics  for every type
+T     that      satisfies     all     requirements     in
+26.1 [numeric.requirements].
+
+        
    
+        
    
+
+I  believe  this  problem  was  introduced  by  the  adoption  of  the
+resolution                outlined                in                N0857,
+Assignment  of  valarrays,  from  1996.   The  copy  assignment
+operator  of  the original  numerical  array  classes  proposed in  N0280,
+as      well       as      the      one       proposed      in      N0308
+(both  from 1993), had  well-defined semantics  for arrays  of unequal
+size (the  latter explicitly  only when *this  was empty;
+assignment of non empty arrays of unequal size was a runtime error).
+
+        
    
+        
    
+
+The  justification for  the  change given  in  N0857 was the "loss  of
+performance [deemed]  only significant  for very simple  operations on
+small arrays or for architectures with very few registers."
+
+        
    
+        
    
+
+Since tiny  arrays on a  limited subset of hardware  architectures are
+likely  to  be  an   exceedingly  rare  case  (despite  the  continued
+popularity of  x86) I  propose to revert  the resolution and  make the
+behavior    of   all   valarray    assignment   operators
+well-defined even  for non-conformal  arrays (i.e., arrays  of unequal
+size).   I have implemented  this change  and measured  no significant
+degradation  in performance in  the common  case (non-empty  arrays of
+equal size).  I  have measured a 50% (and in  some cases even greater)
+speedup  in the  case of  assignments to  empty arrays  versus calling
+resize()  first followed  by  an invocation  of the  copy
+assignment operator.
+
+        
    
+
+
    [
+Bellevue:
+]
    
+
+
+
    
+If no proposed wording by June meeting, this issue should be closed NAD.
+
    
+
+
+
+
    Proposed resolution:
    
+        
    
+
+Change 26.5.2.2 [valarray.assign], p1 as follows:
+
+        
    
+        
    
+            
    
+                
+
+valarray<T>& operator=(const valarray<T>& x);
+
+                
+            
    
+            
    
+
+-1- Each element of the *this array is assigned the value
+of  the  corresponding  element   of  the  argument  array.   The
+resulting behavior is undefined if When the length of
+the  argument  array  is  not   equal  to  the  length  of  the  *this
+array.  resizes  *this  to make  the  two
+arrays     the      same     length,     as      if     by     calling
+resize(x.size()), before performing the assignment.
+
+            
    
+        
    
+        
    
+
+And  add a new  paragraph just  below paragraph  1 with  the following
+text:
+
+        
    
+        
    
+            
    
+
+-2- Postcondition: size() == x.size().
+
+            
    
+        
    
+        
    
+
+Also add the following paragraph to 26.5.2.2 [valarray.assign], immediately after p4:
+
+        
    
+        
    
+            
    
+
+-?- When the length,  N of the array referred
+to by the  argument is not equal to  the length of *this,
+the  operator resizes *this  to make  the two  arrays the
+same  length, as if  by calling  resize(N), before
+performing the assignment.
+
+            
    
+        
    
+
+
+
    [
+Kona (2007): Gaby to propose wording for an alternative resolution in
+which you can assign to a valarray of size 0, but not to any other
+valarray whose size is unequal to the right hand side of the assignment.
+]
    
+
+
+
+
+
+
    
+
    631. conflicting requirements for BinaryPredicate
    
+
    Section: 25 [algorithms] Status: Open
+ Submitter: James Kanze Date: 2007-01-31
    
+
    View all other issues in [algorithms].
    
+
    View all issues with Open status.
    
+
    Discussion:
    
+
    
+The general requirements for BinaryPredicate (in 25 [algorithms]/8) contradict the implied specific requirements for
+some functions. In particular, it says that:
+
    
+
+
    
+[...] if an algorithm takes BinaryPredicate binary_pred
+as its argument and first1 and first2 as its
+iterator arguments, it should work correctly in the construct if
+(binary_pred (*first1 , *first2 )){...}.
+BinaryPredicate always takes the first iterator type as its
+first argument, that is, in those cases when T value is
+part of the signature, it should work correctly in the context of if
+(binary_pred (*first1 , value)){...}.
+
    
+
+
    
+In the description of upper_bound (25.3.3.2 [upper.bound]/2), however, the use is described as
+"!comp(value, e)", where e is an
+element of the sequence (a result of dereferencing
+*first).
+
    
+
+
    
+In the description of lexicographical_compare, we have both
+"*first1 < *first2" and "*first2
+< *first1" (which presumably implies "comp(
+*first1, *first2 )" and "comp( *first2,
+*first1 )".
+
    
+
+
    [
+Toronto:  Moved to Open.  ConceptGCC seems to get lower_bound
+and upper_bound to work withoutt these changes.
+]
    
+
+
+
+
+
    Proposed resolution:
    
+
    
+Logically, the BinaryPredicate is used as an ordering
+relationship, with the semantics of "less than".  Depending on the
+function, it may be used to determine equality, or any of the inequality
+relationships; doing this requires being able to use it with either
+parameter first.  I would thus suggest that the requirement be:
+
    
+
+
    
+[...] BinaryPredicate always takes the first iterator
+value_type as one of its arguments, it is unspecified which. If
+an algorithm takes BinaryPredicate binary_pred as its
+argument and first1 and first2 as its
+iterator arguments, it should work correctly both in the construct
+if (binary_pred (*first1 , *first2 )){...} and
+if (binary_pred (*first2, *first1)){...}.  In
+those cases when T value is part of the signature, it
+should work correctly in the context of if (binary_pred
+(*first1 , value)){...} and of if (binary_pred
+(value, *first1)){...}. [Note: if the two
+types are not identical, and neither is convertable to the other, this
+may require that the BinaryPredicate be a functional object
+with two overloaded operator()() functions. --end note]
+
    
+
+
    
+Alternatively, one could specify an order for each function. IMHO, this
+would be more work for the committee, more work for the implementors,
+and of no real advantage for the user: some functions, such as
+lexicographical_compare or equal_range, will still require both
+functions, and it seems like a much easier rule to teach that both
+functions are always required, rather than to have a complicated list of
+when you only need one, and which one.
+
    
+
+
+
+
+
+
    
+
    632. Time complexity of size() for std::set
    
+
    Section: 23.1 [container.requirements] Status: Open
+ Submitter: Lionel B Date: 2007-02-01
    
+
    View other active issues in [container.requirements].
    
+
    View all other issues in [container.requirements].
    
+
    View all issues with Open status.
    
+
    Discussion:
    
+
    
+A recent news group discussion:
+
    
+
    
+
    
+Anyone know if the Standard has anything to say about the time complexity
+of size() for std::set?   I need to access a set's size (/not/ to know if it is empty!) heavily
+during an algorithm and was thus wondering whether I'd be better off
+tracking the size "manually" or whether that'd be pointless.
+
    
+
    
+That would be pointless. size() is O(1).
+
    
+
    
+Nit: the standard says "should" have constant time. Implementations may take
+license to do worse. I know that some do this for std::list<> as a part of
+some trade-off with other operation.
+
    
+
+
    
+I was aware of that, hence my reluctance to use size() for std::set.
+
    
+
    
+However, this reason would not apply to std::set<> as far as I can see.
+
    
+
    
+Ok, I guess the only option is to try it and see...
+
    
+
    
+
+
    
+If I have any recommendation to the C++ Standards Committee it is that
+implementations must (not "should"!) document clearly[1], where known, the
+time complexity of *all* container access operations.
+
    
+
    
+[1] In my case (gcc 4.1.1) I can't swear that the time complexity of size()
+for std::set is not documented... but if it is it's certainly well hidden
+away.
+
    
+
+
+
+
    Proposed resolution:
    
+
    
+
    
+
+
+
    [
+Kona (2007): This issue affects all the containers. We'd love to see a
+paper dealing with the broad issue. We think that the complexity of the
+size() member of every container -- except possibly list -- should be
+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).
+
    
+
+
+
+
+
    
+
    635. domain of allocator::address
    
+
    Section: 20.1.2 [allocator.requirements] Status: Open
+ Submitter: Howard Hinnant Date: 2007-02-08
    
+
    View other active issues in [allocator.requirements].
    
+
    View all other issues in [allocator.requirements].
    
+
    View all issues with Open status.
    
+
    Discussion:
    
+
    
+The table of allocator requirements in 20.1.2 [allocator.requirements] describes
+allocator::address as:
+
    
+
    a.address(r)
+a.address(s)
+
    
+
    
+where r and s are described as:
+
    
+
    
+a value of type X::reference obtained by the expression *p. 
+
    
+
+
    
+and p is 
+
    
+
+
    
+a value of type X::pointer, obtained by calling a1.allocate, 
+where a1 == a
+
    
+
+
    
+This all implies that to get the address of some value of type T that
+value must have been allocated by this allocator or a copy of it.
+
    
+
+
    
+However sometimes container code needs to compare the address of an external value of
+type T with an internal value.  For example list::remove(const T& t)
+may want to compare the address of the external value t with that of a value
+stored within the list.  Similarly vector or deque insert may
+want to make similar comparisons (to check for self-referencing calls).
+
    
+
+
    
+Mandating that allocator::address can only be called for values which the
+allocator allocated seems overly restrictive.
+
    
+
+
+
+
    Proposed resolution:
    
+
    
+Change 20.1.2 [allocator.requirements]:
+
    
+
+
    
+
    
+r : a value of type X::reference obtained by the expression *p.
+
    
+
    
+s : a value of type X::const_reference obtained by the 
+expression *q or by conversion from a value r.
+
    
+
    
+
+
    [
+post Oxford:  This would be rendered NAD Editorial by acceptance of
+N2257.
+]
    
+
+
+
    [
+Kona (2007):  This issue is section 8 of N2387.  There was some discussion of it but
+no resolution to this issue was recorded.  Moved to Open.
+]
    
+
+
+
+
+
+
+
+
    
+
    638. deque end invalidation during erase
    
+
    Section: 23.2.2.3 [deque.modifiers] Status: Ready
+ Submitter: Steve LoBasso Date: 2007-02-17
    
+
    View all issues with Ready status.
    
+
    Discussion:
    
+
    
+The standard states at 23.2.2.3 [deque.modifiers]/4:
+
    
+
    deque erase(...)
+
    
+ 
    
+Effects: ... An erase at either end of the deque invalidates only
+the iterators and the references to the erased elements.
+
    
+
    
+
    
+This does not state that iterators to end will be invalidated.
+It needs to be amended in such a way as to account for end invalidation.
+
    
+
    
+Something like:
+
    
+
    
+Any time the last element is erased, iterators to end are invalidated.
+
    
+
+
    
+This would handle situations like:
+
    
+
    erase(begin(), end())
+erase(end() - 1)
+pop_back()
+resize(n, ...) where n < size()
+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:
    
+
    
+Change 23.2.2.3 [deque.modifiers], p4:
+
    
+
+
    
+
    iterator erase(const_iterator position); 
+iterator erase(const_iterator first, const_iterator last);
+
    
+
+
    
+
    
+-4- Effects: An erase in the middle of the deque
+invalidates all the iterators and references to elements of the
+deque and the past-the-end iterator. An erase at
+either end of the deque invalidates only the iterators and the
+references to the erased elements, except that erasing at the end
+also invalidates the past-the-end iterator.
+
    
+
    
+
    
+
+
+
+
    [
+Kona (2007): Proposed wording added and moved to Review.
+]
    
+
+
+
    [
+Bellevue:
+]
    
+
+
+
    
+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.
+
    
+
+
+
+
+
    
+
    659. istreambuf_iterator should have an operator->()
    
+
    Section: 24.5.3 [istreambuf.iterator] Status: Open
+ Submitter: Niels Dekker Date: 2007-03-25
    
+
    View all other issues in [istreambuf.iterator].
    
+
    View all issues with Open status.
    
+
    Discussion:
    
+
    
+Greg Herlihy has clearly demonstrated that a user defined input
+iterator should have an operator->(), even if its
+value type is a built-in type (comp.std.c++, "Re: Should any iterator
+have an operator->() in C++0x?", March 2007).  And as Howard
+Hinnant remarked in the same thread that the input iterator
+istreambuf_iterator doesn't have one, this must be a
+defect!
+
    
+
    
+Based on Greg's example, the following code demonstrates the issue:
+
     #include <iostream> 
+ #include <fstream>
+ #include <streambuf> 
+
+ typedef char C;
+ int main ()
+ {
+   std::ifstream s("filename", std::ios::in);
+   std::istreambuf_iterator<char> i(s);
+
+   (*i).~C();  // This is well-formed...
+   i->~C();  // ... so this should be supported!
+ }
+
    
+
+
    
+Of course, operator-> is also needed when the value_type of
+istreambuf_iterator is a class.
+
    
+
    
+The operator-> could be implemented in various ways.  For instance,
+by storing the current value inside the iterator, and returning its
+address.  Or by returning a proxy, like operator_arrow_proxy, from
+http://www.boost.org/boost/iterator/iterator_facade.hpp
+
    
+
    
+I hope that the resolution of this issue will contribute to getting a
+clear and consistent definition of iterator concepts.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Add to the synopsis in 24.5.3 [istreambuf.iterator]:
+
    
+
+
    charT operator*() const;
+pointer operator->() const;
+istreambuf_iterator<charT,traits>& operator++();
+
    
+
+
    
+Change 24.5.3 [istreambuf.iterator], p1:
+
    
+
+
    
+The class template istreambuf_iterator reads successive
+characters from the streambuf for which it was constructed.
+operator* provides access to the current input character, if
+any. operator-> may return a proxy. Each time
+operator++ is evaluated, the iterator advances to the next
+input character. If the end of stream is reached
+(streambuf_type::sgetc() returns traits::eof()), the
+iterator becomes equal to the end of stream iterator value. The default
+constructor istreambuf_iterator() and the constructor
+istreambuf_iterator(0) both construct an end of stream iterator
+object suitable for use as an end-of-range.
+
    
+
+
+
+
    [
+Kona (2007): The proposed resolution is inconsistent because the return
+type of istreambuf_iterator::operator->() is specified to be pointer,
+but the proposed text also states that "operator-> may return a proxy."
+]
    
+
+
+
    [
+Niels Dekker (mailed to Howard Hinnant):
+]
    
+
+
    
+
    
+The proposed resolution does
+not seem inconsistent to me. istreambuf_iterator::operator->() should
+have istreambuf_iterator::pointer as return type, and this return type
+may in fact be a proxy.
+
    
+
    
+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.
+
    
+
    
+Still I wouldn't mind if the text "operator-> may return a proxy" would
+be removed from the resolution. I think it's up to the library
+implementation, how to implement istreambuf_iterator::operator->().  As
+longs as it behaves as expected: i->m should have the same effect as
+(*i).m. Even for an explicit destructor call, i->~C().  The main issue
+is just: istreambuf_iterator should have an operator->()!
+
    
+
    
+
+
+
+
+
    
+
    667. money_get's widened minus sign
    
+
    Section: 22.2.6.1.2 [locale.money.get.virtuals] Status: Open
+ Submitter: Thomas Plum Date: 2007-04-16
    
+
    View other active issues in [locale.money.get.virtuals].
    
+
    View all other issues in [locale.money.get.virtuals].
    
+
    View all issues with Open status.
    
+
    Discussion:
    
+
    
+22.2.6.1.2 [locale.money.get.virtuals], para 1 says:
+
    
+
+
    
+The result is returned as an integral value 
+stored in units or as a sequence of digits possibly preceded by a 
+minus sign (as produced by ct.widen(c) where c is '-' or in the range 
+from '0' through '9', inclusive) stored in digits.
+
    
+
+
    
+The following
+objection has been raised:
+
    
+
+
    
+Some implementations interpret this to mean that a facet derived from
+ctype<wchar_t> can provide its own member do_widen(char)
+which produces e.g. L'@' for the "widened" minus sign, and that the
+'@' symbol will appear in the resulting sequence of digits.  Other
+implementations have assumed that one or more places in the standard permit the
+implementation to "hard-wire" L'-' as the "widened" minus sign.  Are
+both interpretations permissible, or only  one?
+
    
+
+
    
+[Plum ref _222612Y14]
+
    
+
+
    
+Furthermore: if ct.widen('9') produces L'X' (a non-digit), does a
+parse fail if a '9' appears in the subject string? [Plum ref _22263Y33]
+
    
+
+
    [
+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:
    
+
    
+
    
+
+
+
+
+
+
    
+
    668. money_get's empty minus sign
    
+
    Section: 22.2.6.1.2 [locale.money.get.virtuals] Status: Open
+ Submitter: Thomas Plum Date: 2007-04-16
    
+
    View other active issues in [locale.money.get.virtuals].
    
+
    View all other issues in [locale.money.get.virtuals].
    
+
    View all issues with Open status.
    
+
    Discussion:
    
+
    
+22.2.6.1.2 [locale.money.get.virtuals], para 3 says:
+
    
+
+
    
+If pos or neg is empty, the sign component is
+optional, and if no sign is detected, the result is given the sign 
+that corresponds to the source of the empty string.
+
    
+
+
    
+The following
+objection has been raised:
+
    
+
+
    
+A negative_sign of "" means "there is no 
+way to write a negative sign" not "any null sequence is a negative 
+sign, so it's always there when you look for it".
+
    
+
+
    
+[Plum ref _222612Y32]
+
    
+
+
    [
+Kona (2007): Bill to provide proposed wording and interpretation of existing wording.
+]
    
+
+
+
+
+
    Proposed resolution:
    
+
    
+
    
+
+
+
+
+
+
    
+
    669. Equivalent postive and negative signs in money_get
    
+
    Section: 22.2.6.1.2 [locale.money.get.virtuals] Status: Open
+ Submitter: Thomas Plum Date: 2007-04-16
    
+
    View other active issues in [locale.money.get.virtuals].
    
+
    View all other issues in [locale.money.get.virtuals].
    
+
    View all issues with Open status.
    
+
    Discussion:
    
+
    
+22.2.6.1.2 [locale.money.get.virtuals], para 3 sentence 4 says:
+
    
+
+
    
+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:
+
    
+
+
    
+The input can successfully match only a positive sign, so the negative
+pattern is an unsuccessful match.
+
    
+
+
    
+[Plum ref _222612Y34, 222612Y51b]
+
    
+
+
    [
+Bill to provide proposed wording and interpretation of existing wording.
+]
    
+
+
+
+
+
    Proposed resolution:
    
+
    
+
    
+
+
+
+
+
+
    
+
    670. money_base::pattern and space
    
+
    Section: 22.2.6.3 [locale.moneypunct] Status: Open
+ Submitter: Thomas Plum Date: 2007-04-16
    
+
    View all issues with Open status.
    
+
    Discussion:
    
+
    
+22.2.6.3 [locale.moneypunct], para 2 says:
+
    
+
+
    
+The value space indicates that at least one space is required at 
+that position.
+
    
+
+
    
+The following objection has been raised:
+
    
+
+
    
+Whitespace is optional when matching space. (See 22.2.6.1.2 [locale.money.get.virtuals], para 2.)
+
    
+
+
    
+[Plum ref _22263Y22]
+
    
+
+
    [
+Kona (2007): Bill to provide proposed wording. We agree that C++03 is
+ambiguous, and that we want C++0X to say "space" means 0 or more
+whitespace characters on input.
+]
    
+
+
+
+
+
    Proposed resolution:
    
+
    
+
    
+
+
+
+
+
+
    
+
    671. precision of hexfloat
    
+
    Section: 22.2.2.2.2 [facet.num.put.virtuals] Status: Open
+ Submitter: John Salmon Date: 2007-04-20
    
+
    View all other issues in [facet.num.put.virtuals].
    
+
    View all issues with Open status.
    
+
    Discussion:
    
+
    
+I am trying to understand how TR1 supports hex float (%a) output.
+
    
+
    
+As far as I can tell, it does so via the following:
+
    
+
    
+8.15 Additions to header <locale> [tr.c99.locale]
+
    
+
    
+In subclause 22.2.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after
+the line:
+floatfield == ios_base::scientific %E
+
    
+
    
+add the two lines:
+
    
+
    floatfield == ios_base::fixed | ios_base::scientific && !uppercase %a
+floatfield == ios_base::fixed | ios_base::scientific %A 2
+
    
+
    
+[Note: The additional requirements on print and scan functions, later
+in this clause, ensure that the print functions generate hexadecimal
+floating-point fields with a %a or %A conversion specifier, and that
+the scan functions match hexadecimal floating-point fields with a %g
+conversion specifier.  end note]
+
    
+
    
+Following the thread, in 22.2.2.2.2 [facet.num.put.virtuals], we find:
+
    
+
    
+For conversion from a floating-point type, if (flags & fixed) != 0 or
+if str.precision() > 0, then str.precision() is specified in the
+conversion specification.
+
    
+
    
+This would seem to imply that when floatfield == fixed|scientific, the
+precision of the conversion specifier is to be taken from
+str.precision().  Is this really what's intended?  I sincerely hope
+that I'm either missing something or this is an oversight.  Please
+tell me that the committee did not intend to mandate that hex floats
+(and doubles) should by default be printed as if by %.6a.
+
    
+
+
    [
+Howard: I think the fundamental issue we overlooked was that with %f,
+%e, %g, the default precision was always 6.  With %a the default
+precision is not 6, it is infinity.  So for the first time, we need to
+distinguish between the default value of precision, and the precision
+value 6.
+]
    
+
+
+
+
+
    Proposed resolution:
    
+
    
+
    
+
+
+
    [
+Kona (2007): Robert volunteers to propose wording.
+]
    
+
+
+
+
+
+
    
+
    672. Swappable requirements need updating
    
+
    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 Ready status.
    
+
    Discussion:
    
+
    
+The current Swappable is:
+
    
+
+
    
+
+
+
+
+
+
    Table 37: Swappable requirements [swappable]
    expressionreturn typepost-condition
    swap(s,t)voidt has the value originally held by u, and u has the value originally 
+held by t
    
+
    
+The Swappable requirement is met by satisfying one or more of the following conditions:
+
    
+
      
+
    • 
+T is Swappable if T satisfies the CopyConstructible requirements (Table 34) 
+and the CopyAssignable requirements (Table 36);
+
      • 
+
    • 
+T is Swappable if a namespace scope function named swap exists in the same 
+namespace as the definition of T, such that the expression swap(t,u) is valid 
+and has the semantics described in this table.
+
      • 
+
    
+
    
+
    
+
+
    
+With the passage of rvalue reference into the language, Swappable needs to be updated to
+require only MoveConstructible and MoveAssignable.  This is a minimum.
+
    
+
+
    
+Additionally we may want to support proxy references such that the following code is acceptable:
+
    
+
+
    namespace Mine {
+
+template <class T>
+struct proxy {...};
+
+template <class T>
+struct proxied_iterator
+{
+   typedef T value_type;
+   typedef proxy<T> reference;
+   reference operator*() const;
+   ...
+};
+
+struct A
+{
+   // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
+   void swap(A&);
+   ...
+};
+
+void swap(A&, A&);
+void swap(proxy<A>, A&);
+void swap(A&, proxy<A>);
+void swap(proxy<A>, proxy<A>);
+
+}  // Mine
+
+...
+
+Mine::proxied_iterator<Mine::A> i(...)
+Mine::A a;
+swap(*i1, a);
+
    
+
+
    
+I.e. here is a call to swap which the user enables swapping between a proxy to a class and the class
+itself.  We do not need to anything in terms of implementation except not block their way with overly
+constrained concepts.  That is, the Swappable concept should be expanded to allow swapping
+between two different types for the case that one is binding to a user-defined swap.
+
    
+
+
+
+
    Proposed resolution:
    
+
+
    
+Change 20.1.1 [utility.arg.requirements]:
+
    
+
+
    
+
+
    
+-1- The template definitions in the C++ Standard Library refer to various
+named requirements whose details are set out in tables 31-38. In these
+tables, T is a type to be supplied by a C++ program
+instantiating a template; a, b, and c are
+values of type const T; s and t are modifiable
+lvalues of type T; u is a value of type (possibly
+const) T; and rv is a non-const
+rvalue of type T.
+
    
+
+
+
+
+
+
+
+
    Table 37: Swappable requirements [swappable]
    expressionreturn typepost-condition
    swap(s,t)voidt has the value originally
+held by u, and
+u has the value originally held
+by t
    
+
    
+The Swappable requirement is met by satisfying one or more of the following conditions:
+
    
+
      
+
    • 
+T is Swappable if T satisfies the
+CopyConstructible MoveConstructible
+requirements (Table 34 33) and the CopyAssignable MoveAssignable
+requirements (Table 36 35);
+
      • 
+
    • 
+T is Swappable if a namespace scope function named
+swap exists in the same namespace as the definition of
+T, such that the expression
+swap(t,u) is valid and has the
+semantics described in this table.
+
      • 
+
    
+
    
+
    
+
+
+
+
    [
+Kona (2007): We like the change to the Swappable requirements to use
+move semantics. The issue relating to the support of proxies is
+separable from the one relating to move semantics, and it's bigger than
+just swap. We'd like to address only the move semantics changes under
+this issue, and open a separated issue (742) to handle proxies. Also, there
+may be a third issue, in that the current definition of Swappable does
+not permit rvalues to be operands to a swap operation, and Howard's
+proposed resolution would allow the right-most operand to be an rvalue,
+but it would not allow the left-most operand to be an rvalue (some swap
+functions in the library have been overloaded to permit left operands to
+swap to be rvalues).
+]
    
+
+
+
+
+
+
    
+
    673. unique_ptr update
    
+
    Section: 20.6.11 [unique.ptr] Status: Ready
+ Submitter: Howard Hinnant Date: 2007-05-04
    
+
    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
+example implmenation
+for all of these changes.
+
    
+
+
      
+
+
    • 
+
      
+Even though unique_ptr<void> is not a valid use case (unlike for shared_ptr<void>),
+unexpected cases to crop up which require the instantiation of the interface of unique_ptr<void>
+even if it is never used.  For example see
+LWG 541 for how this accidently
+happened to auto_ptr.  I believe the most robust way to protect unique_ptr against this
+type of failure is to augment the return type of unique_ptr<T>:operator*() with
+add_lvalue_reference<T>::type.  This means that given an instantiated unique_ptr<void>
+the act of dereferencing it will simply return void instead of causing a compile time failure.
+This is simpler than creating a unique_ptr<void> specialization which isn't robust in the
+face of cv-qualified void types.
+
      
+
+
      
+This resolution also supports instantiations such as unique_ptr<void, free_deleter>
+which could be very useful to the client.
+
      
+
+
      • 
+
+
    • 
+
      
+Efforts have been made to better support containers and smart pointers in shared
+memory contexts.  One of the key hurdles in such support is not assuming that a
+pointer type is actually a T*.  This can easily be accomplished
+for unique_ptr by having the deleter define the pointer type:
+D::pointer.  Furthermore this type can easily be defaulted to
+T* should the deleter D choose not to define a pointer
+type (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)
+authors of custom deleter types to define a smart pointer for the
+storage type of unique_ptr if they find such functionality
+useful.  std::default_delete is an example of a deleter which
+defaults pointer to T* by simply ignoring this issue
+and not including a pointer typedef.
+
      
+
      • 
+
+
    • 
+
      
+When the deleter type is a function pointer then it is unsafe to construct
+a unique_ptr without specifying the function pointer in the constructor.
+This case is easy to check for with a static_assert assuring that the
+deleter is not a pointer type in those constructors which do not accept deleters.
+
      
+
+
      unique_ptr<A, void(*)(void*)> p(new A);  // error, no function given to delete the pointer!
+
      
+
+
      • 
+
+
    
+
+
    [
+Kona (2007): We don't like the solution given to the first bullet in
+light of concepts. The second bullet solves the problem of supporting
+fancy pointers for one library component only. The full LWG needs to
+decide whether to solve the problem of supporting fancy pointers
+piecemeal, or whether a paper addressing the whole library is needed. We
+think that the third bullet is correct.
+]
    
+
+
+
    [
+Post Kona: Howard adds example user code related to the first bullet:
+]
    
+
+
+
    
+
    void legacy_code(void*, std::size_t);
+
+void foo(std::size_t N)
+{
+    std::unique_ptr<void, void(*)(void*)> ptr(std::malloc(N), std::free);
+    legacy_code(ptr.get(), N);
+}   // unique_ptr used for exception safety purposes
+
    
+
    
+
+
    
+I.e. unique_ptr<void> is a useful tool that we don't want
+to disable with concepts.  The only part of unique_ptr<void> we
+want to disable (with concepts or by other means) are the two member functions:
+
    
+
+
    T& operator*() const;
+T* operator->() const;
+
    
+
+
+
+
    Proposed resolution:
    
+
+
    [
+I am grateful for the generous aid of Peter Dimov and Ion Gaztañaga in helping formulate and review
+the proposed resolutions below.
+]
    
+
+
+
      
+
    • 
+
+
      
+Change 20.6.11.2 [unique.ptr.single]:
+
      
+
+
      template <class T, class D = default_delete<T>> class unique_ptr {
+   ...
+   T& typename add_lvalue_reference<T>::type operator*() const;
+   ...
+};
+
      
+
+
      
+Change 20.6.11.2.4 [unique.ptr.single.observers]:
+
      
+
+
      T& typename add_lvalue_reference<T>::type operator*() const;
+
      
+
+
      • 
+
+
    • 
+
      
+Change 20.6.11.2 [unique.ptr.single]:
+
      
+
+
      template <class T, class D = default_delete<T>> class unique_ptr {
+public:
+  typedef implementation (see description below) pointer;
+   ...
+   explicit unique_ptr(T* pointer p);
+   ...
+   unique_ptr(T* pointer p, implementation defined (see description below) d);
+   unique_ptr(T* pointer p, implementation defined (see description below) d);
+   ...
+   T* pointer operator->() const;
+   T* pointer get() const;
+   ...
+   T* pointer release();
+   void reset(T* pointer p = 0 pointer());
+};
+
      
+
+
      
+
+-3- If the type remove_reference<D>::type::pointer
+exists, then unique_ptr<T, D>::pointer is a typedef to
+remove_reference<D>::type::pointer.  Otherwise
+unique_ptr<T, D>::pointer is a typedef to T*.
+The type unique_ptr<T, D>::pointer shall be CopyConstructible
+and CopyAssignable.
+
+
      
+
+
      
+Change 20.6.11.2.1 [unique.ptr.single.ctor]:
+
      
+
+
      unique_ptr(T* pointer p);
+...
+unique_ptr(T* pointer p, implementation defined d); 
+unique_ptr(T* pointer p, implementation defined d); 
+...
+unique_ptr(T* pointer p, const A& d);
+unique_ptr(T* pointer p, A&& d);
+...
+unique_ptr(T* pointer p, A& d); 
+unique_ptr(T* pointer p, A&& d);
+...
+unique_ptr(T* pointer p, const A& d); 
+unique_ptr(T* pointer p, const A&& d);
+...
+
      
+
+
      
+-23- Requires: If D is not a reference type,
+construction of the deleter D from an rvalue of type E
+must 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 shall be implicitly convertible to T*
+pointer.
+
      
+
+
      
+-25- Postconditions: get() == value u.get() had before
+the construction, modulo any required offset adjustments resulting from
+the cast from U*
+unique_ptr<U,E>::pointer to T*
+pointer. get_deleter() returns a reference to the
+internally stored deleter which was constructed from
+u.get_deleter().
+
      
+
+
      
+Change 20.6.11.2.3 [unique.ptr.single.asgn]:
+
      
+
+
      
+
      
+-8- Requires: Assignment of the deleter D from an rvalue
+D must shall not throw an exception. U*
+unique_ptr<U,E>::pointer must shall be implicitly
+convertible to T* pointer.
+
      
+
      
+
+
      
+Change 20.6.11.2.4 [unique.ptr.single.observers]:
+
      
+
+
      
+
      T* pointer operator->() const;
      
+...
+
      T* pointer get() const;
      
+
      
+
+
      
+Change 20.6.11.2.5 [unique.ptr.single.modifiers]:
+
      
+
+
      
+
      T* pointer release();
      
+...
+
      void reset(T* pointer p = 0 pointer());
      
+
      
+
+
      
+Change 20.6.11.3 [unique.ptr.runtime]:
+
      
+
+
      template <class T, class D> class unique_ptr<T[], D> {
+public:
+  typedef implementation pointer;
+   ...
+   explicit unique_ptr(T* pointer p);
+   ...
+   unique_ptr(T* pointer p, implementation defined d);
+   unique_ptr(T* pointer p, implementation defined d);
+   ...
+   T* pointer get() const;
+   ...
+   T* pointer release();
+   void reset(T* pointer p = 0 pointer());
+};
+
      
+
+
      
+Change 20.6.11.3.1 [unique.ptr.runtime.ctor]:
+
      
+
+
      
+
      unique_ptr(T* pointer p);
+unique_ptr(T* pointer p, implementation defined d);
+unique_ptr(T* pointer p, implementation defined d);
+
      
+
+
      
+These constructors behave the same as in the primary template except
+that they do not accept pointer types which are convertible to
+T* pointer. [Note: One
+implementation technique is to create private templated overloads of
+these members. -- end note]
+
      
+
      
+
+
      
+Change 20.6.11.3.3 [unique.ptr.runtime.modifiers]:
+
      
+
+
      
+
      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]
+
      
+
      
+
+
      • 
+
+
    • 
+
+
      
+Change 20.6.11.2.1 [unique.ptr.single.ctor]:
+
      
+
+
      
+
      unique_ptr();
      
+
      
+
      
+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 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.11.2.1 [unique.ptr.single.ctor]:
+
      
+
+
      
+
      unique_ptr();
      
+
      
+
      
+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 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).
+
      
+
      
+
      
+
+
      • 
+
+
    
+
+
+
+
+
+
+
    
+
    675. Move assignment of containers
    
+
    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 Open status.
    
+
    Discussion:
    
+
    
+James Hopkin pointed out to me that if vector<T> move assignment is O(1)
+(just a swap) then containers such as vector<shared_ptr<ostream>> might have
+the wrong semantics under move assignment when the source is not truly an rvalue, but a
+moved-from lvalue (destructors could run late).
+
    
+
+
    vector<shared_ptr<ostream>> v1;
+vector<shared_ptr<ostream>> v2;
+...
+v1 = v2;               // #1
+v1 = std::move(v2);    // #2
+
    
+
+
    
+Move semantics means not caring what happens to the source (v2 in this example).
+It doesn't mean not caring what happens to the target (v1).  In the above example
+both assignments should have the same effect on v1.  Any non-shared ostream's
+v1 owns before the assignment should be closed, whether v1 is undergoing
+copy assignment or move assignment.
+
    
+
+
    
+This implies that the semantics of move assignment of a generic container should be
+clear, swap instead of just swap.  An alternative which could achieve the same
+effect would be to move assign each element.  In either case, the complexity of move
+assignment needs to be relaxed to O(v1.size()).
+
    
+
+
    
+The performance hit of this change is not nearly as drastic as it sounds. 
+In practice, the target of a move assignment has always just been move constructed
+or move assigned from.  Therefore under clear, swap semantics (in
+this common use case) we are still achieving O(1) complexity.
+
    
+
+
+
+
    Proposed resolution:
    
+
    
+Change 23.1 [container.requirements]:
+
    
+
+
    
+
+
+
+
+
+
+
+
+
+
+
+
+
    Table 86: Container requirements
    expressionreturn typeoperational semanticsassertion/note pre/post-conditioncomplexity
    a = rv;X&All existing elements of a are either move assigned or destructeda shall be equal to the 
+value that rv had 
+before this construction
+constant linear in a.size()
    
+
    
+
+
+
+
    [
+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: Open
+ Submitter: Howard Hinnant Date: 2007-05-05
    
+
    View other active issues in [unord].
    
+
    View all other issues in [unord].
    
+
    View all issues with Open status.
    
+
    Discussion:
    
+
    
+Move semantics are missing from the unordered containers.  The proposed
+resolution below adds move-support consistent with
+N1858
+and the current working draft.
+
    
+
+
    
+The current proposed resolution simply lists the requirements for each function.
+These might better be hoisted into the requirements table for unordered associative containers.
+Futhermore a mild reorganization of the container requirements could well be in order.
+This defect report is purposefully ignoring these larger issues and just focusing
+on getting the unordered containers "moved".
+
    
+
+
+
+
    Proposed resolution:
    
+
+
    
+Add to 23.4 [unord]:
+
    
+
+
    template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_map<Key, T, Hash, Pred, Alloc>& y); 
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_map<Key, T, Hash, Pred, Alloc>&& y);
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x, 
+            unordered_map<Key, T, Hash, Pred, Alloc>& y);
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x, 
+            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
+
+...
+
+template <class Value, class Hash, class Pred, class Alloc> 
+  void swap(unordered_set<Value, Hash, Pred, Alloc>& x, 
+            unordered_set<Value, Hash, Pred, Alloc>& y); 
+
+template <class Value, class Hash, class Pred, class Alloc> 
+  void swap(unordered_set<Value, Hash, Pred, Alloc>& x, 
+            unordered_set<Value, Hash, Pred, Alloc>&& y);
+
+template <class Value, class Hash, class Pred, class Alloc> 
+  void swap(unordered_set<Value, Hash, Pred, Alloc>&& x, 
+            unordered_set<Value, Hash, Pred, Alloc>& y);
+
+template <class Value, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multiset<Value, Hash, Pred, Alloc>& x, 
+            unordered_multiset<Value, Hash, Pred, Alloc>& y);
+
+template <class Value, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multiset<Value, Hash, Pred, Alloc>& x, 
+            unordered_multiset<Value, Hash, Pred, Alloc>&& y);
+
+template <class Value, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multiset<Value, Hash, Pred, Alloc>&& x, 
+            unordered_multiset<Value, Hash, Pred, Alloc>& y);
+
    
+
+
    unordered_map
    
+
+
    
+Change 23.4.1 [unord.map]:
+
    
+
+
    class unordered_map
+{
+    ...
+    unordered_map(const unordered_map&);
+    unordered_map(unordered_map&&);
+    ~unordered_map();
+    unordered_map& operator=(const unordered_map&);
+    unordered_map& operator=(unordered_map&&);
+    ...
+    // modifiers 
+    std::pair<iterator, bool> insert(const value_type& obj); 
+    template <class P> pair<iterator, bool> insert(P&& obj);
+    iterator       insert(iterator hint, const value_type& obj);
+    template <class P> iterator       insert(iterator hint, P&& obj);
+    const_iterator insert(const_iterator hint, const value_type& obj);
+    template <class P> const_iterator insert(const_iterator hint, P&& obj);
+    ...
+    void swap(unordered_map&&);
+    ...
+    mapped_type& operator[](const key_type& k);
+    mapped_type& operator[](key_type&& k);
+    ...
+};
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_map<Key, T, Hash, Pred, Alloc>& y);
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_map<Key, T, Hash, Pred, Alloc>&& y);
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x, 
+            unordered_map<Key, T, Hash, Pred, Alloc>& y);
+
    
+
+
    
+Add to 23.4.1.1 [unord.map.cnstr]:
+
    
+
+
    
+
    template <class InputIterator>
+  unordered_map(InputIterator f, InputIterator l, 
+                size_type n = implementation-defined, 
+                const hasher& hf = hasher(), 
+                const key_equal& eql = key_equal(), 
+                const allocator_type& a = allocator_type());
+
    
+
+
    
+
+Requires: If the iterator's dereference operator returns an
+lvalue or a const rvalue pair<key_type, mapped_type>,
+then both key_type and mapped_type shall be
+CopyConstructible.
+
+
    
+
    
+
+
    
+Add to 23.4.1.2 [unord.map.elem]:
+
    
+
+
    
+
+
    mapped_type& operator[](const key_type& k);
    
+
+
    
+
    ...
    
+
    
+Requires: key_type shall be CopyConstructible
+and mapped_type shall be DefaultConstructible.
+
    
+
    
+
+
    mapped_type& operator[](key_type&& k);
    
+
+
    
+
    
+Effects: If the unordered_map does not already contain an
+element whose key is equivalent to k , inserts the value
+std::pair<const key_type, mapped_type>(std::move(k), mapped_type()).
+
    
+
+
    
+Requires: mapped_type shall be DefaultConstructible.
+
    
+
+
    
+Returns: A reference to x.second, where x is the
+(unique) element whose key is equivalent to k.
+
    
+
+
    
+
+
    
+
+
    
+Add new section [unord.map.modifiers]:
+
    
+
+
    
+
    pair<iterator, bool> insert(const value_type& x);
+template <class P> pair<iterator, bool> insert(P&& x);
+iterator       insert(iterator hint, const value_type& x);
+template <class P> iterator       insert(iterator hint, P&& x);
+const_iterator insert(const_iterator hint, const value_type& x);
+template <class P> const_iterator insert(const_iterator hint, P&& x);
+template <class InputIterator>
+  void insert(InputIterator first, InputIterator last);
+
    
+
+
    
+
    
+Requires: Those signatures taking a const value_type& parameter
+requires both the key_type and the mapped_type to be
+CopyConstructible.
+
    
+
+
    
+P shall be convertible to value_type.
+ If P is instantiated as a reference
+type, then the argument x is copied from. Otherwise x
+is considered to be an rvalue as it is converted to value_type
+and inserted into the unordered_map. Specifically, in such
+cases CopyConstructible is not required of key_type or
+mapped_type unless the conversion from P specifically
+requires it (e.g. if P is a tuple<const key_type,
+mapped_type>, then key_type must be
+CopyConstructible).
+
    
+
+
    
+The signature taking InputIterator
+parameters requires CopyConstructible of both
+key_type and mapped_type if the dereferenced
+InputIterator returns an lvalue or const rvalue
+value_type.
+
    
+
+
    
+
+
    
+
+
    
+Add to 23.4.1.3 [unord.map.swap]:
+
    
+
+
    
+
    template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_map<Key, T, Hash, Pred, Alloc>& y);
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_map<Key, T, Hash, Pred, Alloc>&& y);
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x, 
+            unordered_map<Key, T, Hash, Pred, Alloc>& y);
+
    
+
    
+
+
    unordered_multimap
    
+
+
    
+Change 23.4.2 [unord.multimap]:
+
    
+
+
    class unordered_multimap
+{
+    ...
+    unordered_multimap(const unordered_multimap&);
+    unordered_multimap(unordered_multimap&&);
+    ~unordered_multimap();
+    unordered_multimap& operator=(const unordered_multimap&);
+    unordered_multimap& operator=(unordered_multimap&&);
+    ...
+    // modifiers 
+    iterator insert(const value_type& obj); 
+    template <class P> iterator insert(P&& obj);
+    iterator       insert(iterator hint, const value_type& obj);
+    template <class P> iterator       insert(iterator hint, P&& obj);
+    const_iterator insert(const_iterator hint, const value_type& obj);
+    template <class P> const_iterator insert(const_iterator hint, P&& obj);
+    ...
+    void swap(unordered_multimap&&);
+    ...
+};
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x, 
+            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
+
    
+
+
    
+Add to 23.4.2.1 [unord.multimap.cnstr]:
+
    
+
+
    
+
    template <class InputIterator>
+  unordered_multimap(InputIterator f, InputIterator l, 
+                size_type n = implementation-defined, 
+                const hasher& hf = hasher(), 
+                const key_equal& eql = key_equal(), 
+                const allocator_type& a = allocator_type());
+
    
+
+
    
+
+Requires: If the iterator's dereference operator returns an
+lvalue or a const rvalue pair<key_type, mapped_type>,
+then both key_type and mapped_type shall be
+CopyConstructible.
+
+
    
+
    
+
+
    
+Add new section [unord.multimap.modifiers]:
+
    
+
+
    
+
    iterator insert(const value_type& x);
+template <class P> iterator       insert(P&& x);
+iterator       insert(iterator hint, const value_type& x);
+template <class P> iterator       insert(iterator hint, P&& x);
+const_iterator insert(const_iterator hint, const value_type& x);
+template <class P> const_iterator insert(const_iterator hint, P&& x);
+template <class InputIterator>
+  void insert(InputIterator first, InputIterator last);
+
    
+
+
    
+
    
+Requires: Those signatures taking a const value_type& parameter
+requires both the key_type and the mapped_type to be
+CopyConstructible.
+
    
+
+
    
+P shall be convertible to value_type.
+ If P is instantiated as a reference
+type, then the argument x is copied from. Otherwise x
+is considered to be an rvalue as it is converted to value_type
+and inserted into the unordered_multimap. Specifically, in such
+cases CopyConstructible is not required of key_type or
+mapped_type unless the conversion from P specifically
+requires it (e.g. if P is a tuple<const key_type,
+mapped_type>, then key_type must be
+CopyConstructible).
+
    
+
+
    
+The signature taking InputIterator
+parameters requires CopyConstructible of both
+key_type and mapped_type if the dereferenced
+InputIterator returns an lvalue or const rvalue
+value_type.
+
    
+
    
+
+
    
+
+
    
+Add to 23.4.2.2 [unord.multimap.swap]:
+
    
+
+
    
+
    template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x, 
+            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
+
    
+
    
+
+
    unordered_set
    
+
+
    
+Change 23.4.3 [unord.set]:
+
    
+
+
    class unordered_set
+{
+    ...
+    unordered_set(const unordered_set&);
+    unordered_set(unordered_set&&);
+    ~unordered_set();
+    unordered_set& operator=(const unordered_set&);
+    unordered_set& operator=(unordered_set&&);
+    ...
+    // modifiers 
+    std::pair<iterator, bool> insert(const value_type& obj); 
+    pair<iterator, bool> insert(value_type&& obj);
+    iterator       insert(iterator hint, const value_type& obj);
+    iterator       insert(iterator hint, value_type&& obj);
+    const_iterator insert(const_iterator hint, const value_type& obj);
+    const_iterator insert(const_iterator hint, value_type&& obj);
+    ...
+    void swap(unordered_set&&);
+    ...
+};
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_set<Key, T, Hash, Pred, Alloc>& y);
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_set<Key, T, Hash, Pred, Alloc>&& y);
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_set<Key, T, Hash, Pred, Alloc>&& x, 
+            unordered_set<Key, T, Hash, Pred, Alloc>& y);
+
    
+
+
    
+Add to 23.4.3.1 [unord.set.cnstr]:
+
    
+
+
    
+
    template <class InputIterator>
+  unordered_set(InputIterator f, InputIterator l, 
+                size_type n = implementation-defined, 
+                const hasher& hf = hasher(), 
+                const key_equal& eql = key_equal(), 
+                const allocator_type& a = allocator_type());
+
    
+
+
    
+
+Requires: If the iterator's dereference operator returns an
+lvalue or a const rvalue value_type, then the
+value_type shall be CopyConstructible.
+
+
    
+
    
+
+
    
+Add new section [unord.set.modifiers]:
+
    
+
+
    
+
    pair<iterator, bool> insert(const value_type& x);
+pair<iterator, bool> insert(value_type&& x);
+iterator       insert(iterator hint, const value_type& x);
+iterator       insert(iterator hint, value_type&& x);
+const_iterator insert(const_iterator hint, const value_type& x);
+const_iterator insert(const_iterator hint, value_type&& x);
+template <class InputIterator>
+  void insert(InputIterator first, InputIterator last);
+
    
+
+
    
+
+
    
+Requires: Those signatures taking a const
+value_type& parameter requires the value_type to
+be CopyConstructible.
+
    
+
+
    
+The signature taking InputIterator parameters requires
+CopyConstructible of value_type if the dereferenced
+InputIterator returns an lvalue or const rvalue
+value_type.
+
    
+
+
    
+
+
    
+
+
    
+Add to 23.4.3.2 [unord.set.swap]:
+
    
+
+
    
+
    template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_set<Key, T, Hash, Pred, Alloc>& y);
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_set<Key, T, Hash, Pred, Alloc>&& y);
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_set<Key, T, Hash, Pred, Alloc>&& x, 
+            unordered_set<Key, T, Hash, Pred, Alloc>& y);
+
    
+
    
+
+
    unordered_multiset
    
+
+
    
+Change 23.4.4 [unord.multiset]:
+
    
+
+
    class unordered_multiset
+{
+    ...
+    unordered_multiset(const unordered_multiset&);
+    unordered_multiset(unordered_multiset&&);
+    ~unordered_multiset();
+    unordered_multiset& operator=(const unordered_multiset&);
+    unordered_multiset& operator=(unordered_multiset&&);
+    ...
+    // modifiers 
+    iterator insert(const value_type& obj); 
+    iterator insert(value_type&& obj);
+    iterator       insert(iterator hint, const value_type& obj);
+    iterator       insert(iterator hint, value_type&& obj);
+    const_iterator insert(const_iterator hint, const value_type& obj);
+    const_iterator insert(const_iterator hint, value_type&& obj);
+    ...
+    void swap(unordered_multiset&&);
+    ...
+};
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_multiset<Key, T, Hash, Pred, Alloc>&& y);
+
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>&& x, 
+            unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
+
    
+
+
    
+Add to 23.4.4.1 [unord.multiset.cnstr]:
+
    
+
+
    
+
    template <class InputIterator>
+  unordered_multiset(InputIterator f, InputIterator l, 
+                size_type n = implementation-defined, 
+                const hasher& hf = hasher(), 
+                const key_equal& eql = key_equal(), 
+                const allocator_type& a = allocator_type());
+
    
+
+
    
+
+Requires: If the iterator's dereference operator returns an
+lvalue or a const rvalue value_type, then the
+value_type shall be CopyConstructible.
+
+
    
+
    
+
+
    
+Add new section [unord.multiset.modifiers]:
+
    
+
+
    
+
    iterator insert(const value_type& x);
+iterator insert(value_type&& x);
+iterator       insert(iterator hint, const value_type& x);
+iterator       insert(iterator hint, value_type&& x);
+const_iterator insert(const_iterator hint, const value_type& x);
+const_iterator insert(const_iterator hint, value_type&& x);
+template <class InputIterator>
+  void insert(InputIterator first, InputIterator last);
+
    
 
-typedef typename iterator_traits<ForwardIterator>::pointer    pointer;
-typedef typename iterator_traits<ForwardIterator>::value_type value_type;
+
    
 
-for (; first != last; ++result, ++first)
-    new (static_cast<void*>(const_cast<pointer>(&*result))
-        value_type (*first);
+
    
+Requires: Those signatures taking a const
+value_type& parameter requires the value_type to
+be CopyConstructible.
+
    
 
-            
    
-        
    
+
    
+The signature taking InputIterator parameters requires
+CopyConstructible of value_type if the dereferenced
+InputIterator returns an lvalue or const rvalue
+value_type.
+
    
 
-change 20.6.4.2, p1 to read
+
    
 
-        
    
-            
    -Effects:
+
    
 
-typedef typename iterator_traits<ForwardIterator>::pointer    pointer;
-typedef typename iterator_traits<ForwardIterator>::value_type value_type;
+
    
+Add to 23.4.4.2 [unord.multiset.swap]:
+
    
 
-for (; first != last; ++result, ++first)
-    new (static_cast<void*>(const_cast<pointer>(&*first))
-        value_type (*x);
+
    
+
    template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x, 
+            unordered_multiset<Key, T, Hash, Pred, Alloc>&& y);
+template <class Key, class T, class Hash, class Pred, class Alloc> 
+  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>&& x, 
+            unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
+
    
+
    
 
-            
    
-        
    
 
-and change 20.6.4.3, p1 to read
 
-        
    
-            
    -Effects:
+
    [
+Voted to WP in Bellevue.
+]
    
 
-typedef typename iterator_traits<ForwardIterator>::pointer    pointer;
-typedef typename iterator_traits<ForwardIterator>::value_type value_type;
 
-for (; n--; ++first)
-    new (static_cast<void*>(const_cast<pointer>(&*first))
-        value_type (*x);
+
    [
+post Bellevue, Pete notes:
+]
    
 
-            
    
-        
    
 
-In   addition,  since   there   is  no   partial  specialization   for
-iterator_traits<volatile T*>  I propose to  add one
-to parallel such specialization  for <const T*>. Specifically, I
-propose to add the following text to the end of 24.3.1, p3:
+
    
+
    
+Please remind people who are reviewing issues to check that the text
+modifications match the current draft. Issue 676, for example, adds two
+overloads for unordered_map::insert taking a hint. One takes a
+const_iterator and returns a const_iterator, and the other takes an
+iterator and returns an iterator. This was correct at the time the issue
+was written, but was changed in Toronto so there is only one hint
+overload, taking a const_iterator and returning an iterator.
+
    
+
    
+This issue is not ready. In addition to the relatively minor signature
+problem I mentioned earlier, it puts requirements in the wrong places.
+Instead of duplicating requirements throughout the template
+specifications, it should put them in the front matter that talks about
+requirements for unordered containers in general. This presentation
+problem is editorial, but I'm not willing to do the extensive rewrite
+that it requires. Please put it back into Open status.
+
    
+
    
 
-        
    
-        
    
 
-and for pointers to volatile as 
 
-        
    
-            
    -namespace std {
-template<class T> struct iterator_traits<volatile T*> {
-typedef ptrdiff_t difference_type;
-typedef T value_type;
-typedef volatile T* pointer;
-typedef volatile T& reference;
-typedef random_access_iterator_tag iterator_category;
-};
-}
 
-            
    
-        
    
+
    
+
    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: Ready
+ Submitter: Bo Persson Date: 2007-06-10
    
+
    View all issues with Ready status.
    
+
    Discussion:
    
+
    
+In C++03 the difference between two reverse_iterators
+
    
+
    ri1 - ri2
+
    
+
    
+is possible to compute only if both iterators have the same base 
+iterator. The result type is the difference_type of the base iterator. 
+
    
+
    
+In the current draft, the operator is defined as 24.4.1.3.19 [reverse.iter.opdiff] 
+
    
+
    template<class Iterator1, class Iterator2> 
+typename reverse_iterator<Iterator>::difference_type 
+   operator-(const reverse_iterator<Iterator1>& x, 
+                    const reverse_iterator<Iterator2>& y);
+
    
+
    
+The return type is the same as the C++03 one, based on the no longer 
+present Iterator template parameter. 
+
    
+
    
+Besides being slightly invalid, should this operator work only when 
+Iterator1 and Iterator2 has the same difference_type? Or should the 
+implementation choose one of them? Which one? 
+
    
+
    
+The same problem now also appears in operator-() for move_iterator
+24.4.3.3.14 [move.iter.nonmember]. 
+
    
 
-Note that  the change to  iterator_traits isn't necessary
-in order to implement the  specialized algorithms in a way that allows
-them to operate on volatile  strorage. It is only necesassary in order
-to specify  their effects in terms  of iterator_traits as
-is  done here.   Implementations can  (and some  do) achieve  the same
-effect by means of function template overloading.
 
-        
    
-    
+
    Proposed resolution:
    
+
    
+Change the synopsis in 24.4.1.1 [reverse.iterator]:
+
    
 
+
    
+
    template <class Iterator1, class Iterator2> 
+  typename reverse_iterator<Iterator>::difference_type auto operator-( 
+    const reverse_iterator<Iterator1>& x, 
+    const reverse_iterator<Iterator2>& y) -> decltype(y.current - x.current);
+
    
+
    
 
+
    
+Change 24.4.1.3.19 [reverse.iter.opdiff]:
+
    
 
-
    
-
    585. facet error reporting
    
-
    Section: 22.2 [locale.categories] Status: Open
- Submitter: Martin Sebor, Paolo Carlini Date: 2006-06-22
    
-
    View other active issues in [locale.categories].
    
-
    View all other issues in [locale.categories].
    
-
    View all issues with Open status.
    
-
    Discussion:
    
-        
    
+
    
+
    template <class Iterator1, class Iterator2> 
+  typename reverse_iterator<Iterator>::difference_type auto operator-( 
+    const reverse_iterator<Iterator1>& x, 
+    const reverse_iterator<Iterator2>& y) -> decltype(y.current - x.current);
+
    
+
    
+
    
+Returns: y.current - x.current.
+
    
+
    
+
    
 
-Section  22.2, paragraph 2  requires facet  get() members
-that    take    an    ios_base::iostate&    argument,
-err,  to   ignore  the  (initial)   value  of  the
-argument, but to set it to ios_base::failbit in case of a
-parse error.
 
-        
    
-        
    
+
    
+Change the synopsis in 24.4.3.1 [move.iterator]:
+
    
 
-We  believe  there  are  a   few  minor  problems  with  this  blanket
-requirement  in   conjunction  with   the  wording  specific   to  each
-get() member function.
+
    
+
    template <class Iterator1, class Iterator2> 
+  typename move_iterator<Iterator>::difference_type auto operator-( 
+    const move_iterator<Iterator1>& x, 
+    const move_iterator<Iterator2>& y) -> decltype(x.base() - y.base());
+
    
+
    
 
-        
    
-        
    
+
    
+Change 24.4.3.3.14 [move.iter.nonmember]:
+
    
 
-First,  besides get()  there are  other  member functions
-with     a      slightly     different     name      (for     example,
-get_date()). It's not completely clear that the intent of
-the  paragraph  is  to  include  those  as  well,  and  at  least  one
-implementation has interpreted the requirement literally.
+
    
+
    template <class Iterator1, class Iterator2> 
+  typename move_iterator<Iterator>::difference_type auto operator-( 
+    const move_iterator<Iterator1>& x, 
+    const move_iterator<Iterator2>& y) -> decltype(x.base() - y.base());
+
    
+
    
+
    
+Returns: x.base() - y.base().
+
    
+
    
+
    
 
-        
    
-        
    
+
    [
+Pre Bellevue:  This issue needs to wait until the auto -> return language feature
+goes in.
+]
    
 
-Second,    the     requirement    to    "set     the    argument    to
-ios_base::failbit  suggests that  the  functions are  not
-permitted    to   set    it   to    any   other    value    (such   as
-ios_base::eofbit,   or   even  ios_base::eofbit   |
-ios_base::failbit).
 
-        
    
-        
    
 
-However, 22.2.2.1.2, p5 (Stage  3 of num_get parsing) and
-p6 (bool parsing)  specifies that the do_get
-functions  perform err |=  ios_base::eofbit, which
-contradicts  the earlier  requirement to  ignore  err's initial
-value.
 
-        
    
-        
    
 
-22.2.6.1.2,  p1  (the  Effects  clause of  the  money_get
-facet's  do_get  member  functions) also  specifies  that
-err's initial  value be used to  compute the final
-value  by  ORing  it  with  either  ios_base::failbit  or
-withios_base::eofbit | ios_base::failbit.
 
-        
    
-    
 
-    
    Proposed resolution:
    
-        
    
+
    
+
    688. reference_wrapper, cref unsafe, allow binding to rvalues
    
+
    Section: 20.5.5.1 [refwrap.const] Status: Open
+ Submitter: Peter Dimov Date: 2007-05-10
    
+
    View all other issues in [refwrap.const].
    
+
    View all issues with Open status.
    
+
    Discussion:
    
+
    
+A reference_wrapper can be constructed from an rvalue, either by using
+the constructor, or via cref (and ref in some corner cases). This leads
+to a dangling reference being stored into the reference_wrapper object.
+Now that we have a mechanism to detect an rvalue, we can fix them to
+disallow this source of undefined behavior.
+
    
 
-We believe the  intent is for all facet member  functions that take an
-ios_base::iostate& argument to:
+
    
+Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
+
    
 
-        
    
-            
      
-                
    • 
 
-ignore the initial value of the err argument,
 
-                
      • 
-                
    • 
+
      Proposed resolution:
      
+
      
+In 20.5 [function.objects], add the following two signatures to the synopsis:
+
      
+
+
      template <class T> void ref(const T&& t) = delete;
+template <class T> void cref(const T&& t) = delete;
+
      
+
 
-reset err  to ios_base::goodbit prior
-to any further processing,
 
-                
      • 
-                
    • 
+
      [
+N2292
+addresses the first part of the resolution but not the second.
+]
      
 
-and       set      either       ios_base::eofbit,      or
-ios_base::failbit, or both in err, as
-appropriate,  in response  to  reaching the  end-of-file  or on  parse
-error, or both.
 
-                
      • 
-            
    
-        
    
+
    [
+Bellevue:  Doug noticed problems with the current wording.
+]
    
 
-To that effect we propose to change 22.2, p2 as follows:
 
-        
    
-        
    
+
    [
+post Bellevue:  Howard and Peter provided revised wording.
+]
    
 
-The  put()  members  make  no  provision  for  error
-reporting.   (Any  failures of  the  OutputIterator  argument must  be
-extracted   from  the   returned  iterator.)    Unless  otherwise
-specified, the get()  members  that
-take an  ios_base::iostate& argument whose value
-they  ignore,  but  set  to  ios_base::failbit  in  case  of  a  parse
-error.,   err,   start  by   evaluating
-err  =   ios_base::goodbit,  and  may   subsequently  set
-err     to     either     ios_base::eofbit,     or
-ios_base::failbit,     or     ios_base::eofbit    |
-ios_base::failbit in response to reaching the end-of-file or in
-case of a parse error, or both, respectively.
 
-        
    
-    
-    
 
    [
-Kona (2007): We need to change the proposed wording to clarify that the
-phrase "the get members" actually denotes get(), get_date(), etc.
-Proposed Disposition: Open
+This resolution depends on a "favorable" resolution of CWG 606:  that is,
+the "special deduction rule" is disabled with the const T&& pattern.
 ]
    
 
 
 
 
+
 
    
-
    588. requirements on zero sized tr1::arrays and other details
    
-
    Section: 23.2.1 [array] Status: Open
- Submitter: Gennaro Prota Date: 2006-07-18
    
-
    View other active issues in [array].
    
-
    View all other issues in [array].
    
-
    View all issues with Open status.
    
+
    691. const_local_iterator cbegin, cend missing from TR1
    
+
    Section: 23.4 [unord], TR1 6.3 [tr.hash] Status: Review
+ Submitter: Joaquín M López Muñoz Date: 2007-06-14
    
+
    View other active issues in [unord].
    
+
    View all other issues in [unord].
    
+
    View all issues with Review status.
    
 
    Discussion:
    
 
    
-The wording used for section 23.2.1 [lib.array] seems to be subtly
-ambiguous about zero sized arrays (N==0). Specifically:
+The last version of TR1 does not include the following member
+functions
+for unordered containers:
 
    
+
+
    const_local_iterator cbegin(size_type n) const;
+const_local_iterator cend(size_type n) const;
+
    
+
 
    
-* "An instance of array<T, N> stores N elements of type T, so that
-[...]"
+which looks like an oversight to me. I've checked th TR1 issues lists
+and the latest working draft of the C++0x std (N2284) and haven't
+found any mention to these menfuns or to their absence.
 
    
 
    
-Does this imply that a zero sized array object stores 0 elements, i.e.
-that it cannot store any element of type T? The next point clarifies
-the rationale behind this question, basically how to implement begin()
-and end():
+Is this really an oversight, or am I missing something?
 
    
+
+
+
+
    Proposed resolution:
    
 
    
-* 23.2.1.5 [lib.array.zero], p2: "In the case that N == 0, begin() ==
-end() == unique value."
+Add the following two rows to table 93 (unordered associative container
+requirements) in section 23.1.3 [unord.req]:
 
    
+
+
    
+
+
+
+
+
+
+ 
+
+
+ 
+
+
    Unordered associative container requirements (in addition to container)
    expression return type assertion/note pre/post-condition complexity
    b.cbegin(n) const_local_iterator n shall be in the range [0, bucket_count()). Note: [b.cbegin(n), b.cend(n)) is a valid range containing all of the elements in the nth bucket. Constant
    b.cend(n) const_local_iterator n shall be in the range [0, bucket_count()). Constant
    
+
    
+
 
    
-What does "unique" mean in this context? Let's consider the following
-possible implementations, all relying on a partial specialization:
+Add to the synopsis in 23.4.1 [unord.map]:
 
    
-
    a)
-    template< typename T >
-    class array< T, 0 > {
-    
-        ....
-
-        iterator begin()
-        { return iterator( reinterpret_cast< T * >( this ) ); }
-        ....
 
-    };
+
    const_local_iterator cbegin(size_type n) const;
+const_local_iterator cend(size_type n) const;
 
    
+
 
    
-This has been used in boost, probably intending that the return value
-had to be unique to the specific array object and that array couldn't
-store any T. Note that, besides relying on a reinterpret_cast, has
-(more than potential) alignment problems.
+Add to the synopsis in 23.4.2 [unord.multimap]:
 
    
-
    b)
-    template< typename T >
-    class array< T, 0 > {
-    
-        T t;
 
-        iterator begin()
-        { return iterator( &t ); }
-        ....
-
-    };
+
    const_local_iterator cbegin(size_type n) const;
+const_local_iterator cend(size_type n) const;
 
    
+
 
    
-This provides a value which is unique to the object and to the type of
-the array, but requires storing a T. Also, it would allow the user to
-mistakenly provide an initializer list with one element.
+Add to the synopsis in 23.4.3 [unord.set]:
 
    
+
+
    const_local_iterator cbegin(size_type n) const;
+const_local_iterator cend(size_type n) const;
+
    
+
 
    
-A slight variant could be returning *the* null pointer of type T
+Add to the synopsis in 23.4.4 [unord.multiset]:
 
    
-
        return static_cast<T*>(0);
+
+
    const_local_iterator cbegin(size_type n) const;
+const_local_iterator cend(size_type n) const;
 
    
+
+
+
+
+
+
+
    
+
    692. get_money and put_money should be formatted I/O functions
    
+
    Section: 27.6.4 [ext.manip] Status: New
+ Submitter: Martin Sebor Date: 2007-06-22
    
+
    View other active issues in [ext.manip].
    
+
    View all other issues in [ext.manip].
    
+
    View all issues with New status.
    
+
    Discussion:
    
 
    
-In this case the value would be unique to the type array<T, 0> but not
-to the objects (all objects of type array<T, 0> with the same value
-for T would yield the same pointer value).
+In a private email Bill Plauger notes:
+
    
+
    
+I  believe that  the function  that  implements get_money
+[from N2072]
+should behave  as a  formatted input function,  and the  function that
+implements put_money should  behave as a formatted output
+function. This  has implications regarding the  skipping of whitespace
+and the handling of errors, among other things.
 
    
 
    
-Furthermore this is inconsistent with what the standard requires from
-allocation functions (see library issue 9).
+The words  don't say that  right now and  I'm far from  convinced that
+such a change is editorial.
+
    
+
    
+Martin's response:
+
    
+
    
+I agree that the manipulators should handle exceptions the same way as
+formatted I/O functions do. The text in N2072 assumes so but the
+Returns clause explicitly omits exception handling for the sake
+of brevity. The spec should be clarified to that effect.
 
    
 
    
-c) same as above but with t being a static data member; again, the
-value would be unique to the type, not to the object.
+As for dealing  with whitespace, I also agree it  would make sense for
+the extractors  and inserters involving the new  manipulators to treat
+it the same way as formatted I/O.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Add  a new  paragraph immediately  above  p4 of 27.6.4 [ext.manip] with  the
+following text:
 
    
+
    
+Effects:  The   expression  in >> get_money(mon, intl)
+described below behaves as a formatted input function (as
+described in 27.6.1.2.1 [istream.formatted.reqmts]).
+
    
 
    
-d) to avoid storing a T *directly* while disallowing the possibility
-to use a one-element initializer list a non-aggregate nested class
-could be defined
+Also change p4 of 27.6.4 [ext.manip] as follows:
 
    
-
        struct holder { holder() {} T t; } h;
-
    
+
    
+Returns: An object s of unspecified type such that
+if in is  an object of type basic_istream<charT,
+traits>    then    the    expression   in >> get_money(mon, intl) behaves as a formatted input function
+that    calls    f(in, mon, intl)    were
+called. The function f can be defined as...
+
    
+
+
+
    [
+post Bellevue:
+]
    
+
+
+
    
+We recommend moving immediately to Review. We've looked at the issue and
+have a consensus that the proposed resolution is correct, but want an
+iostream expert to sign off. Alisdair has taken the action item to putt
+this up on the reflector for possible movement by Howard to Tenatively
+Ready.
+
    
+
+
+
+
+
    
+
    696. istream::operator>>(int&) broken
    
+
    Section: 27.6.1.2.2 [istream.formatted.arithmetic] Status: New
+ Submitter: Martin Sebor Date: 2007-06-23
    
+
    View all other issues in [istream.formatted.arithmetic].
    
+
    View all issues with New status.
    
+
    Discussion:
    
 
    
-and then begin be defined as
+From message c++std-lib-17897:
 
    
-
     iterator begin() { return &h.t; }
-
    
 
    
-But then, it's arguable whether the array stores a T or not.
-Indirectly it does.
+The  code  shown  in  27.6.1.2.2 [istream.formatted.arithmetic] as  the  "as  if"
+implementation  of the  two arithmetic  extractors that  don't  have a
+corresponding     num_get     interface    (i.e.,     the
+short and int  overloads) is subtly buggy in
+how  it  deals  with  EOF, overflow,  and  other  similar
+conditions (in addition to containing a few typos).
 
    
 
    
------------------------------------------------------
+One  problem is  that if  num_get::get() reaches  the EOF
+after reading in  an otherwise valid value that  exceeds the limits of
+the    narrower    type     (but    not    LONG_MIN    or
+LONG_MAX),   it  will   set   err  to
+eofbit.   Because   of  the  if   condition  testing  for
+(err == 0),    the   extractor    won't   set
+failbit  (and presumably,  return  a bogus  value to  the
+caller).
+
    
+
    
+Another  problem with  the code  is that  it never  actually  sets the
+argument to  the extracted  value. It can't  happen after the  call to
+setstate() since  the function may  throw, so we  need to
+show when  and how it's done (we  can't just punt as  say: "it happens
+afterwards"). However, it  turns out that showing how  it's done isn't
+quite so  easy since  the argument is  normally left unchanged  by the
+facet on error  except when the error is due  to a misplaced thousands
+separator,  which causes  failbit to  be set  but doesn't
+prevent the facet from storing the value.
 
    
+
+
+
    Proposed resolution:
    
 
    
-Now, on different issues:
 
    
+
+
+
+
+
+
    
+
    698. Some system_error issues
    
+
    Section: 19.4.5.1 [syserr.syserr.overview] Status: New
+ Submitter: Daniel Krügler Date: 2007-06-24
    
+
    View all issues with New status.
    
+
    Discussion:
    
 
    
-* what's the effect of calling assign(T&) on a zero-sized array? There
-seems to be only mention of front() and back(), in 23.2.1 [lib.array]
-p4 (I would also suggest to move that bullet to section 23.2.1.5
-[lib.array.zero], for locality of reference)
+In 19.4.5.1 [syserr.syserr.overview] we have the class definition of
+std::system_error. In contrast to all exception classes, which
+are constructible with a what_arg string (see 19.1 [std.exceptions],
+or ios_base::failure in 27.4.2.1.1 [ios::failure]), only overloads with with
+const string& are possible. For consistency with the re-designed
+remaining exception classes this class should also provide
+c'tors which accept a const char* what_arg string.
 
    
 
    
-* (minor) the opening paragraph of 23.2.1 [lib.array] wording is a bit
-inconsistent with that of other sequences: that's not a problem in
-itself, but compare it for instance with "A vector is a kind of
-sequence that supports random access iterators"; though the intent is
-obvious one might argue that the wording used for arrays doesn't tell
-what an array is, and relies on the reader to infer that it is what
-the <array> header defines.
+Please note that this proposed addition makes sense even
+considering the given implementation hint for what(), because
+what_arg is required to be set as what_arg of the base class
+runtime_error, which now has the additional c'tor overload
+accepting a const char*.
 
    
+
+
+
    Proposed resolution:
    
 
    
-* it would be desiderable to have a static const data member of type
-std::size_t, with value N, for usage as integral constant expression
 
    
+
+
+
+
+
+
    
+
    701. assoc laguerre poly's
    
+
    Section: TR1 5.2.1.1 [tr.num.sf.Lnm] Status: New
+ Submitter: Christopher Crawford Date: 2007-06-30
    
+
    View all issues with New status.
    
+
    Discussion:
    
 
    
-* section 23.1 [lib.container.requirements] seem not to consider
-fixed-size containers at all, as it says: "[containers] control
-allocation and deallocation of these objects [the contained objects]
-through constructors, destructors, *insert and erase* operations"
+I see that the definition the associated Laguerre
+polynomials TR1 5.2.1.1 [tr.num.sf.Lnm] has been corrected since
+N1687.
+However, the draft standard only specifies ranks of integer value m,
+while the associated Laguerre polynomials are actually valid for real
+values of m > -1.  In the case of non-integer values of m, the
+definition  Ln(m) = (1/n!)exx-m (d/dx)n (e-xxm+n)
+must be used, which also holds for integer values of m.  See
+Abramowitz & Stegun, 22.11.6 for the general case, and 22.5.16-17 for
+the integer case.  In fact fractional values are most commonly used in
+physics, for example to m = +/- 1/2 to describe the harmonic
+oscillator in 1 dimension, and 1/2, 3/2, 5/2, ... in 3
+dimensions.
 
    
 
    
-* max_size() isn't specified: the result is obvious but, technically,
-it relies on table 80: "size() of the largest possible container"
-which, again, doesn't seem to consider fixed size containers
+If I am correct, the calculation of the more general case is no
+more difficult, and is in fact the function implemented in the GNU
+Scientific Library.  I would urge you to consider upgrading the 
+standard, either adding extra functions for real m or switching the
+current ones to double.
 
    
 
 
@@ -6573,440 +9957,619 @@ which, again, doesn't seem to consider fixed size containers
 
    
 
 
-
    [
-Kona (2007): requirements on zero sized tr1::arrays and other details
-Issue 617: std::array is a sequence that doesn't satisfy the sequence
-requirements? Alisdair will prepare a paper. Proposed Disposition: Open
-]
    
+
+
+
+
    
+
    702. Restriction in associated Legendre functions
    
+
    Section: TR1 5.2.1.2 [tr.num.sf.Plm] Status: New
+ Submitter: Christopher Crawford Date: 2007-06-30
    
+
    View all issues with New status.
    
+
    Discussion:
    
+
    
+One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should  be
+|x| <= 1, not x >= 0.
    
+
+
+
    Proposed resolution:
    
+
    
+
    
 
 
 
 
 
 
    
-
    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 all issues with Ready status.
    
+
    704. MoveAssignable requirement for container value type overly strict
    
+
    Section: 23.1 [container.requirements] Status: Open
+ Submitter: Howard Hinnant Date: 2007-05-20
    
+
    View other active issues in [container.requirements].
    
+
    View all other issues in [container.requirements].
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
-TR1 introduced, in the C compatibility chapter, the function
-fabs(complex<T>):
+The move-related changes inadvertently overwrote the intent of 276.
+Issue 276 removed the requirement of CopyAssignable from
+most of the member functions of node-based containers.  But the move-related changes
+unnecessarily introduced the MoveAssignable requirement for those members which used to
+require CopyAssignable.
 
    
-
    ----- SNIP -----
-8.1.1 Synopsis                                [tr.c99.cmplx.syn]
 
-  namespace std {
-  namespace tr1 {
-[...]
-  template<class T> complex<T> fabs(const complex<T>& x);
-  } // namespace tr1
-  } // namespace std
+
    
+We also discussed (c++std-lib-18722) the possibility of dropping MoveAssignable
+from some of the sequence requirements.  Additionally the in-place construction
+work may further reduce requirements.  For purposes of an easy reference, here are the
+minimum sequence requirements as I currently understand them.  Those items in requirements
+table in the working draft which do not appear below have been purposefully omitted for
+brevity as they do not have any requirements of this nature.  Some items which do not
+have any requirements of this nature are included below just to confirm that they were
+not omitted by mistake.
+
    
 
-[...]
+
+
+
+
+
+
+
+
    Container Requirements
    X u(a)value_type must be CopyConstructible
    X u(rv)array requires value_type to be MoveConstructible
    a = uSequences require value_type to be CopyConstructible and CopyAssignable.
+                               Associative containers require value_type to be CopyConstructible.
    a = rvarray requires value_type to be MoveAssignable.
+                                Sequences with non-Swappable allocators require value_type to be MoveConstructible and MoveAssignable.
+                                Associative containers with non-Swappable allocators require value_type to be MoveConstructible.
    swap(a,u)array requires value_type to be Swappable.
+                                Sequences with non-Swappable allocators require value_type to be Swappable, MoveConstructible and MoveAssignable.
+                                Associative containers with non-Swappable allocators require value_type to be MoveConstructible.
    
 
-8.1.8 Function fabs                          [tr.c99.cmplx.fabs]
+
    
+
    
 
-1 Effects: Behaves the same as C99 function cabs, defined in
-  subclause 7.3.8.1.
------ SNIP -----
-
    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    Sequence Requirements
    X(n)value_type must be DefaultConstructible
    X(n, t)value_type must be CopyConstructible
    X(i, j)If the iterators return an lvalue the value_type must be CopyConstructible.
+                                 If the iterators return an rvalue the value_type must be MoveConstructible.
    a.insert(p, t)The value_type must be CopyConstructible.
+                                        The sequences vector and deque also require the value_type to be CopyAssignable.
    a.insert(p, rv)The value_type must be MoveConstructible.
+                                        The sequences vector and deque also require the value_type to be MoveAssignable.
    a.insert(p, n, t)The value_type must be CopyConstructible.
+                                        The sequences vector and deque also require the value_type to be CopyAssignable.
    a.insert(p, i, j)If the iterators return an lvalue the value_type must be CopyConstructible.
+                                        The sequences vector and deque also require the value_type to be CopyAssignable when the iterators return an lvalue.
+                                        If the iterators return an rvalue the value_type must be MoveConstructible.
+                                        The sequences vector and deque also require the value_type to be MoveAssignable when the iterators return an rvalue.
    a.erase(p)The sequences vector and deque require the value_type to be MoveAssignable.
    a.erase(q1, q2)The sequences vector and deque require the value_type to be MoveAssignable.
    a.clear()
    a.assign(i, j)If the iterators return an lvalue the value_type must be CopyConstructible and CopyAssignable.
+                                        If the iterators return an rvalue the value_type must be MoveConstructible and MoveAssignable.
    a.assign(n, t)The value_type must be CopyConstructible and CopyAssignable.
    a.resize(n)The value_type must be DefaultConstructible.
+                                     The sequences vector and deque also require the value_type to be MoveConstructible.
    a.resize(n, t)The value_type must be CopyConstructible.
    
+
+
    
+
    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    Optional Sequence Requirements
    a.front()
    a.back()
    a.push_front(t)The value_type must be CopyConstructible.
    a.push_front(rv)The value_type must be MoveConstructible.
    a.push_back(t)The value_type must be CopyConstructible.
    a.push_back(rv)The value_type must be MoveConstructible.
    a.pop_front()
    a.pop_back()
    a[n]
    a.at[n]
    
 
 
    
-The current C++0X draft document (n2009.pdf) adopted this
-definition in chapter 26.3.1 (under the comment // 26.3.7 values)
-and 26.3.7/7.
 
    
+
+
+
+
+
+
+
+
+
+
+
+
    Associative Container Requirements
    X(i, j)If the iterators return an lvalue the value_type must be CopyConstructible.
+                                 If the iterators return an rvalue the value_type must be MoveConstructible.
    a_uniq.insert(t)The value_type must be CopyConstructible.
    a_uniq.insert(rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
    a_eq.insert(t)The value_type must be CopyConstructible.
    a_eq.insert(rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
    a.insert(p, t)The value_type must be CopyConstructible.
    a.insert(p, rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
    a.insert(i, j)If the iterators return an lvalue the value_type must be CopyConstructible.
+                                        If the iterators return an rvalue the key_type and the mapped_type (if it exists) must be MoveConstructible..
    
+
 
    
-But in C99 (ISO/IEC 9899:1999 as well as the 9899:TC2 draft document
-n1124), the referenced subclause reads
 
    
 
-
    ----- SNIP -----
-7.3.8.1 The cabs functions
+
+
+
+
+
+
+
+
+
+
+
    Unordered Associative Container Requirements
    X(i, j, n, hf, eq)If the iterators return an lvalue the value_type must be CopyConstructible.
+                                 If the iterators return an rvalue the value_type must be MoveConstructible.
    a_uniq.insert(t)The value_type must be CopyConstructible.
    a_uniq.insert(rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
    a_eq.insert(t)The value_type must be CopyConstructible.
    a_eq.insert(rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
    a.insert(p, t)The value_type must be CopyConstructible.
    a.insert(p, rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
    a.insert(i, j)If the iterators return an lvalue the value_type must be CopyConstructible.
+                                        If the iterators return an rvalue the key_type and the mapped_type (if it exists) must be MoveConstructible..
    
 
-  Synopsis
+
    
+
    
 
-1 #include <complex.h>
-  double cabs(double complex z);
-  float cabsf(float complex z);
-  long double cabsl(long double z);
+
+
+
+
+
    Miscellaneous Requirements
    map[lvalue-key]The key_type must be CopyConstructible.
+                                         The mapped_type must be DefaultConstructible and MoveConstructible.
    map[rvalue-key]The key_type must be MoveConstructible.
+                                         The mapped_type must be DefaultConstructible and MoveConstructible.
    
 
-  Description
+
    [
+Kona (2007): Howard and Alan to update requirements table in issue with emplace signatures.
+]
    
+
+
+
    [
+Bellevue: This should be handled as part of the concepts work.
+]
    
+
+
+
+
+
    Proposed resolution:
    
 
-2 The cabs functions compute the complex absolute value (also called
-  norm, modulus, or magnitude) of z.
 
-  Returns
 
-3 The cabs functions return the complex absolute value.
------ SNIP -----
-
    
 
-
    
-Note that the return type of the cabs*() functions is not a complex
-type.  Thus, they are equivalent to the already well established
-  template<class T> T abs(const complex<T>& x);
-(26.2.7/2 in ISO/IEC 14882:1998, 26.3.7/2 in the current draft
-document n2009.pdf).
-
    
-
    
-So either the return value of fabs() is specified wrongly, or fabs()
-does not behave the same as C99's cabs*().
-
    
 
-Possible Resolutions
 
+
    
+
    708. Locales need to be per thread and updated for POSIX changes
    
+
    Section: 22 [localization] Status: Open
+ Submitter: Peter Dimov Date: 2007-07-28
    
+
    View all other issues in [localization].
    
+
    View all issues with Open status.
    
+
    Discussion:
    
 
    
-This depends on the intention behind the introduction of fabs().
+The POSIX "Extended API Set Part 4,"
 
    
+
    
+http://www.opengroup.org/sib/details.tpl?id=C065
+
    
 
    
-If the intention was to provide a /complex/ valued function that
-calculates the magnitude of its argument, this should be
-explicitly specified.  In TR1, the categorization under "C
-compatibility" is definitely wrong, since C99 does not provide
-such a complex valued function.
+introduces extensions to the C locale mechanism that
+allow multiple concurrent locales to be used in the same application
+by introducing a type locale_t that is very similar to
+std::locale, and a number of _l functions that make use of it.
 
    
 
    
-Also, it remains questionable if such a complex valued function
-is really needed, since complex<T> supports construction and
-assignment from real valued arguments.  There is no difference
-in observable behaviour between
+The global locale (set by setlocale) is now specified to be per-
+process. If a thread does not call uselocale, the global locale is
+in effect for that thread. It can install a per-thread locale by
+using uselocale.
 
    
-
      complex<double> x, y;
-  y = fabs(x);
-  complex<double> z(fabs(x));
-
    
 
    
-and
+There is also a nice querylocale mechanism by which one can obtain
+the name (such as "de_DE") for a specific facet, even for combined
+locales, with no std::locale equivalent.
 
    
-
      complex<double> x, y;
-  y = abs(x);
-  complex<double> z(abs(x));
-
    
 
    
-If on the other hand the intention was to provide the intended
-functionality of C99, fabs() should be either declared deprecated
-or (for C++0X) removed from the standard, since the functionality
-is already provided by the corresponding overloads of abs().
+std::locale should be harmonized with the new POSIX locale_t
+mechanism and provide equivalents for uselocale and querylocale.
 
    
 
+
    [
+Kona (2007): Bill and Nick to provide wording.
+]
    
+
 
 
-
    Proposed resolution:
    
 
+
    Proposed resolution:
    
 
    
-Change the synopsis in 26.3.1 [complex.synopsis]:
 
    
 
-
    template<class T> complex<T> fabs(const complex<T>&);
-
    
 
-
    
-Change 26.3.7 [complex.value.ops], p7:
-
    
 
-
    
-
    template<class T> complex<T> fabs(const complex<T>& x);
-
    
-
    
-
    
--7- Effects: Behaves the same as C99 function cabs, defined in subclause 7.3.8.1.
-
    
-
    
-
    
 
 
+
    
+
    710. Missing postconditions
    
+
    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 Ready status.
    
+
    Discussion:
    
+
    
+A discussion on
+comp.std.c++
+has identified a contradiction in the shared_ptr specification.
+The shared_ptr move constructor and the cast functions are
+missing postconditions for the get() accessor.
+
    
 
 
    [
-Kona (2007): Change the return type of fabs(complex) to T. 
-Proposed Disposition: Ready
+Bellevue:
 ]
    
 
 
-
-
-
-
    
-
    596. 27.8.1.3 Table 112 omits "a+" and "a+b" modes
    
-
    Section: 27.8.1.4 [filebuf.members] Status: Review
- Submitter: Thomas Plum Date: 2006-09-26
    
-
    View other active issues in [filebuf.members].
    
-
    View all other issues in [filebuf.members].
    
-
    View all issues with Review status.
    
-
    Discussion:
    
+
    
 
    
-In testing 27.8.1.4 [filebuf.members], Table 112 (in the latest N2009 draft), we invoke  
+Move to "ready", adopting the first (Peter's) proposed resolution.
 
    
-
       ostr.open("somename", ios_base::out | ios_base::in | ios_base::app)
-
    
 
    
-and we expect the open to fail, because out|in|app is not listed in
-Table 92, and just before the table we see very specific words:
+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...".
 
    
-
    
-  If mode is not some combination of flags shown in the table 
-  then the open fails.
-
    
+
    
+
+
+
    Proposed resolution:
    
 
    
-But the corresponding table in the C standard, 7.19.5.3, provides two
-modes "a+" and "a+b", to which the C++ modes out|in|app and
-out|in|app|binary would presumably apply.
+Add to 20.6.12.2.1 [util.smartptr.shared.const]:
 
    
+
+
    
+
    shared_ptr(shared_ptr&& r);
+template<class Y> shared_ptr(shared_ptr<Y>&& r);
+
    
+
    
 
    
-We would like to argue that the intent of Table 112 was to match the
-semantics of 7.19.5.3 and that the omission of "a+" and "a+b" was
-unintentional.  (Otherwise there would be valid and useful behaviors
-available in C file I/O which are unavailable using C++, for no
-valid functional reason.)
+Postconditions:  *this shall contain the old value of r. r
+shall be empty. r.get() == 0.
 
    
+
    
+
    
+
 
    
-We further request that the missing modes be explicitly restored to
-the WP, for inclusion in C++0x.
+Add to 20.6.12.2.10 [util.smartptr.shared.cast]:
 
    
 
-
    [
-Martin adds:
-]
    
-
-
+
    
+
    template<class T, class U> shared_ptr<T> static_pointer_cast(shared_ptr<U> const& r);
+
    
+
    
 
    
-...besides "a+" and "a+b" the C++ table is also missing a row
-for a lone app bit which in at least two current implementation
-as well as in Classic Iostreams corresponds to the C stdio "a"
-mode and has been traditionally documented as implying ios::out.
-Which means the table should also have a row for in|app meaning
-the same thing as "a+" already proposed in the issue.
+Postconditions: If w is the return value,
+w.get() == static_cast<T*>(r.get()) && w.use_count() == r.use_count().
 
    
+
    
+
    
 
-
-
    Proposed resolution:
    
+
    
+
    template<class T, class U> shared_ptr<T> dynamic_pointer_cast(shared_ptr<U> const& r);
+
    
+
    
 
    
-Add to the table "File open modes" in 27.8.1.4 [filebuf.members]:
+Postconditions: If w is the return value, w.get() == dynamic_cast<T*>(r.get()).
 
    
+
    
+
    
 
 
    
-
-
-
-
-
-
-
-
-
+
    template<class T, class U> shared_ptr<T> const_pointer_cast(shared_ptr<U> const& r);
+
    
+
    
+
    
+Postconditions: If w is the return value,
+w.get() == const_cast<T*>(r.get()) && w.use_count() == r.use_count().
+
    
+
    
+
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
    
+Alberto Ganesh Barbati has written an
+alternative proposal
+where he suggests (among other things) that the casts be respecified in terms of
+the aliasing constructor as follows:
+
    
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
    
+Change 20.6.12.2.10 [util.smartptr.shared.cast]:
+
    
 
+
    
+
    
+-2- Returns: If r is empty, an empty
+shared_ptr<T>; otherwise, a shared_ptr<T>
+object that stores static_cast<T*>(r.get()) and shares ownership with
+r. shared_ptr<T>(r, static_cast<T*>(r.get()).
+
    
+
    
 
-
     File open modes
    ios_base Flag combinationstdio equivalent
    binaryinouttruncapp 
        +     "w"
        +   + "a"
            + "a"
        + +   "w"
      +       "r"
      + +     "r+"
      + + +   "w+"
      + +   + "a+"
      +     + "a+"
    +   +     "wb"
    +   +   + "ab"
    +       + "ab"
    +   + +   "wb"
    + +       "rb"
    + + +     "r+b"
    + + + +   "w+b"
    + + +   + "a+b"
    + +     + "a+b"
    
+
    
+
    
+-6- Returns:
+
    
+
      
+
    • When dynamic_cast<T*>(r.get()) returns a nonzero value,
+a shared_ptr<T> object that stores a copy 
+of it and shares ownership with r;
      • 
+
    • Otherwise, an empty shared_ptr<T> object.
      • 
+
    • If p = dynamic_cast<T*>(r.get()) is a non-null pointer, shared_ptr<T>(r, p);
      • 
+
    • Otherwise, shared_ptr<T>().
      • 
+
    
 
    
 
+
    
+
    
+-10- Returns: If r is empty, an empty
+shared_ptr<T>; otherwise, a shared_ptr<T>
+object that stores const_cast<T*>(r.get()) and shares ownership with
+r. shared_ptr<T>(r, const_cast<T*>(r.get()).
+
    
+
    
 
+
    
+This takes care of the missing postconditions for the casts by bringing
+in the aliasing constructor postcondition "by reference".
+
    
 
-
    [
-Kona (2007) Added proposed wording and moved to Review.
-]
    
 
 
 
 
 
 
    
-
    597. Decimal: The notion of 'promotion' cannot be emulated by user-defined types.
    
-
    Section: TRDecimal 3.2 [trdec.types.types] Status: Open
- Submitter: Daveed Vandevoorde Date: 2006-04-05
    
-
    View other active issues in [trdec.types.types].
    
-
    View all other issues in [trdec.types.types].
    
-
    View all issues with Open status.
    
+
    711. Contradiction in empty shared_ptr
    
+
    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 Review status.
    
 
    Discussion:
    
 
    
-In a private email, Daveed writes:
+A discussion on
+comp.std.c++
+has identified a contradiction in the shared_ptr specification.
+The note:
 
    
-
    
+
+
    
+[ Note: this constructor allows creation of an empty shared_ptr instance with a non-NULL stored pointer.
+-end note ]
+
    
+
 
    
-I am not familiar with the C TR, but my guess is that the
-class type approach still won't match a built-in type
-approach because the notion of "promotion" cannot be
-emulated by user-defined types.
+after the aliasing constructor
 
    
+
+
    template<class Y> shared_ptr(shared_ptr<Y> const& r, T *p);
+
    
+
 
    
-Here is an example:
+reflects the intent of
+N2351
+to, well, allow the creation of an empty shared_ptr
+with a non-NULL stored pointer.
 
    
-
    
-
    -		 struct S {
-		   S(_Decimal32 const&);  // Converting constructor
-		 };
-		 void f(S);
 
-		 void f(_Decimal64);
+
    
+This is contradicted by the second sentence in the Returns clause of 20.6.12.2.5 [util.smartptr.shared.obs]:
+
    
 
-		 void g(_Decimal32 d) {
-		   f(d);
-		 }
+
    
+
    T* get() const;
 
    
+
    
+Returns: the stored pointer. Returns a null pointer if *this is empty.
+
    
+
    
+
+
    [
+Bellevue:
+]
    
+
 
 
    
 
    
-If _Decimal32 is a built-in type, the call f(d) will likely
-resolve to f(_Decimal64) because that requires only a
-promotion, whereas f(S) requires a user-defined conversion.
+Adopt option 1 and move to review, not ready.
 
    
 
    
-If _Decimal32 is a class type, I think the call f(d) will be
-ambiguous because both the conversion to _Decimal64 and the
-conversion to S will be user-defined conversions with neither
-better than the other.
+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:
    
 
    
-Robert comments:
+In keeping the N2351 spirit and obviously my preference, change 20.6.12.2.5 [util.smartptr.shared.obs]:
 
    
-
    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:
+
+
    
+
    T* get() const;
+
    
+
    
+Returns: the stored pointer. Returns a null pointer if *this is empty.
+
    
+
    
+
+
    
+Alternative proposed resolution: (I won't be happy if we do this, but it's possible):
 
    
-
                     _Decimal32 d1;
-                 d1.operator+=(5);  // If d1 is a builtin type, this won't compile.
+
+
    
+Change 20.6.12.2.1 [util.smartptr.shared.const]:
+
    
+
+
    
+
    template<class Y> shared_ptr(shared_ptr<Y> const& r, T *p);
 
    
+
    
 
    
-In preparing the decimal TR, we have three options:
+Requires: If r is empty, p shall be 0.
 
    
-
      
-
    1. require that the decimal types be class types
      2. 
-
    2. require that the decimal types be builtin types, like float and double
      3. 
-
    3. specify a library of class types, but allow enough implementor
-latitude that a conforming implementation could instead provide builtin
-types
      4. 
-
    
 
    
-We decided as a group to pursue option #3, but that approach implies
-that implementations may not agree on the semantics of certain use
-cases (first example, above), or on whether certain other cases are
-well-formed (second example). Another potentially important problem is
-that, under the present definition of POD, the decimal classes are not
-POD types, but builtins will be.
+[ Note: this constructor allows creation of an empty shared_ptr
+instance with a non-NULL stored pointer. 
+-- end note ]
 
    
-
    Note that neither example above implies any problems with respect to
-C-to-C++ compatibility, since neither example can be expressed in C.
+
    
+
    
+
+
+
+
+
+
+
    
+
    713. sort() complexity is too lax
    
+
    Section: 25.3.1.1 [sort] Status: New
+ Submitter: Matt Austern Date: 2007-08-30
    
+
    View all issues with New status.
    
+
    Discussion:
    
+
    
+The complexity of sort() is specified as "Approximately N
+log(N) (where N == last - first ) comparisons on the
+average", with no worst case complicity specified. The intention was to
+allow a median-of-three quicksort implementation, which is usually O(N
+log N) but can be quadratic for pathological inputs. However, there is
+no longer any reason to allow implementers the freedom to have a
+worst-cast-quadratic sort algorithm. Implementers who want to use
+quicksort can use a variant like David Musser's "Introsort" (Software
+Practice and Experience 27:983-993, 1997), which is guaranteed to be O(N
+log N) in the worst case without incurring additional overhead in the
+average case. Most C++ library implementers already do this, and there
+is no reason not to guarantee it in the standard.
 
    
 
 
 
    Proposed resolution:
    
+
    
+In 25.3.1.1 [sort], change the complexity to "O(N log N)", and remove footnote 266:
+
    
+
+
    
+
    
+Complexity: Approximately O(N log(N)) (where N == last - first )
+comparisons on the average.266)
+
    
+
    
+266)
+If the worst case behavior is important stable_sort() (25.3.1.2) or partial_sort()
+(25.3.1.3) should be used.
+
    
+
    
+
 
 
 
 
 
 
    
-
    606. Decimal: allow narrowing conversions
    
-
    Section: TRDecimal 3.2 [trdec.types.types] Status: Open
- Submitter: Martin Sebor Date: 2006-06-15
    
-
    View other active issues in [trdec.types.types].
    
-
    View all other issues in [trdec.types.types].
    
-
    View all issues with Open status.
    
+
    714. search_n complexity is too lax
    
+
    Section: 25.1.9 [alg.search] Status: New
+ Submitter: Matt Austern Date: 2007-08-30
    
+
    View all other issues in [alg.search].
    
+
    View all issues with New status.
    
 
    Discussion:
    
 
    
-In c++std-lib-17205, Martin writes:
+The complexity for search_n (25.1.9 [alg.search] par 7) is specified as "At most
+(last - first ) * count applications of the corresponding predicate if
+count is positive, or 0 otherwise." This is unnecessarily pessimistic.
+Regardless of the value of count, there is no reason to examine any
+element in the range more than once.
 
    
-
    ...was it a deliberate design choice to make narrowing
-assignments ill-formed while permitting narrowing compound assignments?
-For instance:
-
    
-
          decimal32 d32;
-      decimal64 d64;
 
-      d32 = 64;     // error
-      d32 += 64;    // okay
+
+
    Proposed resolution:
    
+
    
+Change the complexity to "At most (last - first) applications of the corresponding predicate".
+
    
+
+
    
+
    template<class ForwardIterator, class Size, class T> 
+  ForwardIterator 
+    search_n(ForwardIterator first , ForwardIterator last , Size count , 
+             const T& value ); 
+
+template<class ForwardIterator, class Size, class T, 
+         class BinaryPredicate> 
+  ForwardIterator 
+    search_n(ForwardIterator first , ForwardIterator last , Size count , 
+             const T& value , BinaryPredicate pred );
 
    
+
    
 
    
-In c++std-lib-17229, Robert responds:
+Complexity: At most (last - first ) * count applications of the corresponding predicate
+if count is positive, or 0 otherwise.
+
    
+
    
+
    
+
+
+
+
+
+
+
    
+
    715. minmax_element complexity is too lax
    
+
    Section: 25.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 Ready status.
    
+
    Discussion:
    
+
    
+The complexity for minmax_element (25.3.7 [alg.min.max] par 16) says "At most max(2 *
+(last - first ) - 2, 0) applications of the corresponding comparisons",
+i.e. the worst case complexity is no better than calling min_element and
+max_element separately. This is gratuitously inefficient. There is a
+well known technique that does better: see section 9.1 of CLRS
+(Introduction to Algorithms, by Cormen, Leiserson, Rivest, and Stein).
 
    
-
    It is a vestige of an old idea that I forgot to remove
-from the paper. Narrowing assignments should be permitted. The bug is
-that the converting constructors that cause narrowing should not be
-explicit. Thanks for pointing this out.
-
    
+
 
 
    Proposed resolution:
    
 
    
-1.  In "3.2.2 Class decimal32" synopsis, remove the explicit specifier from the narrowing conversions:
+Change 25.3.7 [alg.min.max] to:
 
    
-
                    // 3.2.2.2 conversion from floating-point type:
-                explicit decimal32(decimal64 d64);
-                explicit decimal32(decimal128 d128);
+
+
    
+
    template<class ForwardIterator> 
+  pair<ForwardIterator, ForwardIterator> 
+    minmax_element(ForwardIterator first , ForwardIterator last); 
+template<class ForwardIterator, class Compare> 
+  pair<ForwardIterator, ForwardIterator> 
+    minmax_element(ForwardIterator first , ForwardIterator last , Compare comp);
 
    
+
    
 
    
-2.  Do the same thing in "3.2.2.2. Conversion from floating-point type."
-
    
-
    
-3.  In "3.2.3 Class decimal64" synopsis, remove the explicit specifier from the narrowing conversion:
+Returns: make_pair(m, M), where m is
+min_element(first, last) or min_element(first, last,
+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
+in [first, last) such that no iterator in the range refers to a larger element.
 
    
-
                    // 3.2.3.2 conversion from floating-point type:
-                explicit decimal64(decimal128 d128);
-
    
 
    
-4.  Do the same thing in "3.2.3.2. Conversion from floating-point type."
+Complexity: At most max(2 * (last - first ) - 2, 0)
+max(⌊(3/2) (N-1)⌋, 0) applications of the
+corresponding comparisons predicate, where N is distance(first, last).
 
    
-
-
    [
-Redmond: We prefer explicit conversions for narrowing and implicit for widening.
-]
    
+
    
+
    
 
 
 
@@ -7014,47 +10577,45 @@ 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
- Submitter: Chris Jefferson Date: 2006-11-10
    
-
    View all other issues in [numeric.limits.members].
    
-
    View all issues with Open status.
    
+
    716. Production in [re.grammar] not actually modified
    
+
    Section: 28.13 [re.grammar] Status: New
+ Submitter: Stephan T. Lavavej Date: 2007-08-31
    
+
    View all issues with New status.
    
 
    Discussion:
    
 
    
-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:
+TR1 7.13 [tr.re.grammar]/3 and C++0x WP 28.13 [re.grammar]/3 say:
 
    
 
-
      
-
    1. Doesn't define what that value recieved is.
      2. 
-
    2. Doesn't state the result is repeatable
      3. 
-
    3.  Doesn't require that doing addition, subtraction and other
-operations on all values is defined behaviour.
      4. 
-
    
+
    
+
    
+The following productions within the ECMAScript grammar are modified as follows:
+
    
 
-
    [
-Batavia: Related to
-N2144.
-Pete: is there an ISO definition of modulo?  Underflow on signed behavior is undefined.
-]
    
+
    CharacterClass ::
+[ [lookahead ∉ {^}] ClassRanges ]
+[ ^ ClassRanges ]
+
    
+
+
    
+
+
    
+This definition for CharacterClass appears to be exactly identical to that in ECMA-262.
+
    
 
+
    
+Was an actual modification intended here and accidentally omitted, or was this production accidentally included?
+
    
 
 
 
    Proposed resolution:
    
 
    
-Suggest 18.2.1.2 [numeric.limits.members[numeric.limits.members], paragraph 57 is ammeded to:
+Remove this mention of the CharacterClass production.
 
    
 
-
    
-A type is modulo if, it is possible to add two positive numbers
-and have a result that wraps around to a third number that is less.
-given any operation involving +,- or * on values of that type whose value
-would fall outside the range [min(), max()], then the value returned
-differs from the true value by an integer multiple of (max() - min() +
-1).
-
    
+
    CharacterClass ::
+[ [lookahead ∉ {^}] ClassRanges ]
+[ ^ ClassRanges ]
+
    
 
 
 
@@ -7062,65 +10623,64 @@ differs from the true value by an integer multiple of (max() - min() +
 
 
 
    
-
    614. std::string allocator requirements still inconsistent
    
+
    718. basic_string is not a sequence
    
 
    Section: 21.3 [basic.string] Status: Open
- Submitter: Bo Persson Date: 2006-12-05
    
+ 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 Open status.
    
 
    Discussion:
    
 
    
-This is based on N2134, where 21.3.1/2 states:
-"... The Allocator object used shall be a copy of the Allocator object 
-passed to the basic_string object's constructor or, if the constructor does 
-not take an Allocator argument, a copy of a default-constructed Allocator 
-object."
+Paragraph 21.3 [basic.string]/3 states:
 
    
+
+
    
 
    
-Section 21.3.2/1 lists two constructors:
+The class template basic_string conforms to the requirements for a 
+Sequence (23.1.1) and for a Reversible Container (23.1).
 
    
-
    basic_string(const basic_string<charT,traits,Allocator>& str );
+
    
 
-basic_string(const basic_string<charT,traits,Allocator>& str ,
-             size_type pos , size_type n = npos,
-             const Allocator& a = Allocator());
-
    
 
    
-and then says "In the first form, the Allocator value used is copied from 
-str.get_allocator().", which isn't an option according to 21.3.1.
+First of all, 23.1.1 [sequence.reqmts] is no longer "Sequence" but "Sequence container". 
+Secondly, after the resent changes to containers (emplace, push_back, 
+const_iterator parameters to insert and erase), basic_string is not 
+even close to conform to the current requirements.
 
    
-
    [
-Batavia:  We need blanket statement to the effect of:
-]
    
-
 
-
      
-
    1. If an allocator is passed in, use it, or,
      2. 
-
    2. If a string is passed in, use its allocator.
      3. 
-
    
 
    [
-Review constructors and functions that return a string; make sure we follow these
-rules (substr, operator+, etc.).  Howard to supply wording.
+Bellevue:
 ]
    
 
 
-
    [
-Bo adds:  The new container constructor which takes only a size_type is not
-consistent with 23.1 [container.requirements], p9 which says in part:
-
 
    
-All other constructors for these container types take an
-Allocator& argument (20.1.2), an allocator whose value type
-is the same as the container's value type. A copy of this argument is
-used for any memory allocation performed, by these constructors and by
-all member functions, during the lifetime of each container object.
+
      
+
    • 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:
    
 
    
+Remove this sentence, in recognition of the fact that basic_string is 
+not just a vector-light for literal types, but something quite 
+different, a string abstraction in its own right.
 
    
 
 
@@ -7128,802 +10688,993 @@ 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
- 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.
    
+
    719. std::is_literal type traits should be provided
    
+
    Section: 20.4 [meta] Status: Open
+ Submitter: Daniel Krügler Date: 2007-08-25
    
+
    View all other issues in [meta].
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
-The <array> header is given under 23.2 [sequences].
-23.2.1 [array]/paragraph 3 says:
-
    
-
    
-"Unless otherwise specified, all array operations are as described in
-23.1 [container.requirements]".
-
    
-
    
-However, array isn't mentioned at all in section 23.1 [container.requirements].
-In particular, Table 82 "Sequence requirements" lists several operations (insert, erase, clear) 
-that std::array does not have in 23.2.1 [array].
-
    
-
    
-Also, Table 83 "Optional sequence operations" lists several operations that 
-std::array does have, but array isn't mentioned.
+Since the inclusion of constexpr in the standard draft N2369 we have
+a new type category "literal", which is defined in 3.9 [basic.types]/p.11:
 
    
 
-
-
    Proposed resolution:
    
+
    
 
    
+-11- A type is a literal type if it is:
 
    
+
      
+
    • a scalar type; or
      • 
+
    • a class type (clause 9) with
      
+
        
+
      • a trivial copy constructor,
        • 
+
      • a trivial destructor,
        • 
+
      • at least one constexpr constructor other than the copy constructor,
        • 
+
      • no virtual base classes, and
        • 
+
      • all non-static data members and base classes of literal types; or
        • 
+
      
+
      • 
+
    • an array of literal type.
      • 
+
    
+
    
 
-
-
-
-
-
    
-
    618. valarray::cshift() effects on empty array
    
-
    Section: 26.5.2.7 [valarray.members] Status: Review
- Submitter: Gabriel Dos Reis Date: 2007-01-10
    
-
    View all issues with Review status.
    
-
    Discussion:
    
 
    
-I would respectfully request an issue be opened with the intention to
-clarify the wording for size() == 0 for cshift.
+I strongly suggest that the standard provides a type traits for
+literal types in 20.4.4.3 [meta.unary.prop] for several reasons:
 
    
 
+
      
+
    1. To keep the traits in sync with existing types.
      2. 
+
    2. I see many reasons for programmers to use this trait in template
+   code to provide optimized template definitions for these types,
+   see below.
      3. 
+
    3. A user-provided definition of this trait is practically impossible
+to write portably.
      4. 
+
    
 
-
    Proposed resolution:
    
 
    
-Change 26.5.2.7 [valarray.members], paragraph 10:
+The special problem of reason (c) is that I don't see currently a
+way to portably test the condition for literal class types:
 
    
 
 
    
+
      
+
    • at least one constexpr constructor other than the copy constructor,
      • 
+
    
+
    
 
-
    valarray<T> cshift(int n) const;
-
    
-
-
    
 
    
-This function returns an object of class valarray<T>, of
-length size(), each of whose elements I is
-(*this)[(I + n ) % size()]. Thus, if element zero is taken as
-the leftmost element, a positive value of n shifts the elements
-circularly left n places. that is a circular shift of *this. If
-element zero is taken as the leftmost element, a non-negative value of
-n shifts the elements circularly left n places and a
-negative value of n shifts the elements circularly right
--n places.
+Here follows a simply example to demonstrate it's usefulness:
 
    
-
    
-
    
 
+
    template <typename T>
+constexpr typename std::enable_if<std::is_literal<T>::value, T>::type
+abs(T x) {
+  return x < T() ? -x : x;
+}
 
+template <typename T>
+typename std::enable_if<!std::is_literal<T>::value, T>::type
+abs(const T& x) {
+  return x < T() ? -x : x;
+}
+
    
 
-
    Rationale:
    
 
    
-We do not believe that there is any real ambiguity about what happens
-when size() == 0, but we do believe that spelling this out as a C++
-expression causes more trouble that it solves. The expression is
-certainly wrong when n < 0, since the sign of % with negative arguments
-is implementation defined.
+Here we have the possibility to provide a general abs function
+template that can be used in ICE's if it's argument is a literal
+type which's value is a constant expression, otherwise we
+have an optimized version for arguments which are expensive
+to copy and therefore need the usage of arguments of
+reference type (instead of const T& we could decide to
+use T&&, but that is another issue).
 
    
 
-
 
    [
-Kona (2007) Changed proposed wording, added rationale and set to Review.
+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:
    
+
    
+In 20.4.2 [meta.type.synop] in the group "type properties",
+just below the line
+
    
 
-
    
-
    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:
    
-        
    
+
    template <class T> struct is_pod;
+
    
 
-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.
+
    
+add a new one:
+
    
 
-        
    
-        
    
+
    template <class T> struct is_literal;
+
    
 
-In  addition,  Footnote 280  uses  some questionable  normative
-language.
+
    
+In 20.4.4.3 [meta.unary.prop], table Type Property Predicates, just
+below the line for the is_pod property add a new line:
+
    
 
-        
    
+
+
+
+
+
+
+
+
+
+
    TemplateConditionPreconditions
    template <class T> struct is_literal;T is a literal type (3.9)T shall be a complete type, an
+array of unknown bound, or
+(possibly cv-qualified) void.
    
 
 
-
    Proposed resolution:
    
-        
    
 
-Reword the Effects clause and Footnote 280 as follows (26.5.2.1 [valarray.cons]):
 
-        
    
-        
    
-            
    
 
-valarray();
 
-            
    
-            
    
+
    
+
    720. Omissions in constexpr usages
    
+
    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 Open status.
    
+
    Discussion:
    
+
      
+
    1. 
+The member function bool array<T,N>::empty() const should be a
+constexpr because this is easily to proof and to implement following it's operational
+semantics defined by Table 87 (Container requirements) which says: a.size() == 0.
+
      2. 
+
    2. 
+The member function bool bitset<N>::test() const must be a
+constexpr (otherwise it would violate the specification of constexpr
+bitset<N>::operator[](size_t) const, because it's return clause delegates to test()).
+
      3. 
+
    3. 
+I wonder how the constructor bitset<N>::bitset(unsigned long) can
+be declared as a constexpr. Current implementations usually have no such bitset
+c'tor which would fulfill the requirements of a constexpr c'tor because they have a
+non-empty c'tor body that typically contains for-loops or memcpy to compute the
+initialisation. What have I overlooked here?
+
      4. 
+
    
 
-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)
 
-            
    
-            
    
+
    Proposed resolution:
    
+
      
+
    1. 
+
      In the class template definition of 23.2.1 [array]/p. 3 change
      
+
      constexpr bool empty() const;
+
      
+
      2. 
 
-Postcondition: size() == 0.
+
    2. 
+
      In the class template definition of 23.3.5 [template.bitset]/p. 1 change
      
+
      constexpr bool test(size_t pos ) const;
+
      
 
-            
      
-            
      
+
      
+and in 23.3.5.2 [bitset.members] change
+
      
 
-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.
+
      constexpr bool test(size_t pos ) const;
+
      
 
-            
      
-        
    
+
    • +
    -

    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.

    +

    721. wstring_convert inconsistensies

    +

    Section: 22.1.3.2.2 [conversions.string] Status: New + Submitter: Bo Persson Date: 2007-08-27

    +

    View all issues with New status.

    Discussion:

    -

    - -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: +Paragraph 3 says that the Codecvt template parameter shall meet the +requirements of std::codecvt, even though std::codecvt itself cannot +be used (because of a protected destructor).

    -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: +How are we going to explain this code to beginning programmers?

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

    template<class I, class E, class S>
+struct codecvt : std::codecvt<I, E, S>
+{
+    ~codecvt()
+    { }
+};
 
-        
    
-        
    -const slice_array& operator= (const slice_array&) const;
+void main()
+{
+    std::wstring_convert<codecvt<wchar_t, char, std::mbstate_t> > compiles_ok;
+    
+    std::wstring_convert<std::codecvt<wchar_t, char, std::mbstate_t> >   not_ok;
+}
+
    
 
-
    -

    -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;
+
    Proposed resolution:
    
+
    
+
    
 
-
    -

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

    +

    722. Missing [c.math] functions nanf and nanl

    +

    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 Ready status.

    +

    Discussion:

    +

    +In the listing of 26.7 [c.math], table 108: Header <cmath> synopsis I miss +the following C99 functions (from 7.12.11.2): +

    -

    - 
    -const indirect_array& operator= (const indirect_array&) const;
+
    float nanf(const char *tagp);
+long double nanl(const char *tagp);
+
    
 
-
    +

    +(Note: These functions cannot be overloaded and they are also not +listed anywhere else) +

    -

    [ -Kona (2007) Added const qualification to the return types and set to Ready. -]

    +

    Proposed resolution:

    +

    +In 26.7 [c.math], table 108, section "Functions", add nanf and nanl +just after the existing entry nan. +

    -

    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.

    +

    723. basic_regex should be moveable

    +

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

    +

    View all other issues in [re.regex].

    +

    View all issues with New status.

    Discussion:

    -

    +

    +According to the current state of the standard draft, the class +template basic_regex, as described in 28.8 [re.regex]/3, is +neither MoveConstructible nor MoveAssignable. +IMO it should be, because typical regex state machines tend +to have a rather large data quantum and I have seen several +use cases, where a factory function returns regex values, +which would take advantage of moveabilities. +

    -basic_filebuf dtor is specified to have the following -straightforward effects: -

    -

    +

    Proposed resolution:

    +
      +
    1. +

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

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

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

      +
      2. -Effects: Destroys an object of class -basic_filebuf. Calls close(). +
    2. +

      Just after the copy c'tor:

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

    -

    +

  • +

    Just after the copy-assignment op.:

    +
    basic_regex& operator=(basic_regex&&);
+
    +
    • -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]. +
  • +

    Just after the first assign overload insert:

    +
    basic_regex& assign(basic_regex&& that);
+
    +
    • -

    -

    +

  • +

    Change the current swap function to read:

    +
    void swap(basic_regex&&);
+
    +
    • + +
  • +

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

    +
    basic_regex(basic_regex&&);
+
    +
    • -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: +
  • +

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

    +
    basic_regex& operator=(basic_regex&&);
+
    +
    • + +
  • +

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

    +
    basic_regex& assign(basic_regex&& that);
+
    +
    • -

    -

    +

  • +

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

    +
    void swap(basic_regex&& e);
+
    +
    • -... If any of the calls to overflow or -std::fclose fails then close fails. +
  • +

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

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

    -

    +

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

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

    +
    +

    724. DefaultConstructible is not defined

    +

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

    +

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

    +

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

    +

    View all issues with Open status.

    +

    Discussion:

    +

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

    [ -See 397 and 418 for related issues. +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:

    -

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

    +In section 20.1.1 [utility.arg.requirements], before table 33, add the +following table: +

    -

    -

    +

    Table 33: DefaultConstructible requirements

    -Specifically, we propose to make the following edits in -27.8.1.4 [filebuf.members]: +
    -

    -
    - 
    -basic_filebuf<charT,traits>* close();
+
+ 
+  
+  
+ 
+ 
+  
+  
+ 
+
    
+  
    expression
    
+      		
+  
    post-condition
    
+  
    
+  
    T
+  t;
    
+  T()
    
+      		
+  
    T
+  is default constructed.
    
+  
    
 
-
    -

    +

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

    +

    726. Missing regex_replace() overloads

    +

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

    +

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

    +

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

    +

    View all issues with New status.

    +

    Discussion:

    +

    +Two overloads of regex_replace() are currently provided: +

    -

    -
    +
    template <class OutputIterator, class BidirectionalIterator, 
+    class traits, class charT> 
+  OutputIterator 
+  regex_replace(OutputIterator out, 
+                BidirectionalIterator first, BidirectionalIterator last, 
+                const basic_regex<charT, traits>& e, 
+                const basic_string<charT>& fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);
+ 
+template <class traits, class charT> 
+  basic_string<charT> 
+  regex_replace(const basic_string<charT>& s, 
+                const basic_regex<charT, traits>& e, 
+                const basic_string<charT>& fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);
+
    +
      +
    1. Overloads taking const charT * are provided for regex_match() and +regex_search(), but not regex_replace(). This is inconsistent.
      2. +
    2. +

      The absence of const charT * overloads prevents ordinary-looking code from compiling, such as:

      +
      const string s("kitten");
+const regex r("en");
+cout << regex_replace(s, r, "y") << endl;
+
      +

      +The compiler error message will be something like "could not deduce +template argument for 'const std::basic_string<_Elem> &' from 'const +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 +std::string (or std::wstring), they can pass a const char * (or const +wchar_t *), thanks to basic_string's implicit constructor. Because the +regex algorithms are templated on charT, they can't rely on +basic_string's implicit constructor (as the compiler error message +indicates, template argument deduction fails first). +

      -
      -

      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:

      -

      +

      +If a user figures out what the compiler error message means, workarounds +are available - but they are all verbose. Explicit template arguments +could be given to regex_replace(), allowing basic_string's implicit +constructor to be invoked - but charT is the last template argument, not +the first, so this would be extremely verbose. Therefore, constructing +a basic_string from each C string is the simplest workaround. +

      +
      3. -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." +
    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. +(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.) +
      4. +
    -

    -

    -That contradicts the Effects clause for -basic_streambuf::pubimbue() which requires the function -to do just that: call basic_streambuf::imbue(). -

    +

    Proposed resolution:

    +

    +Provide additional overloads for regex_replace(): one additional +overload of the iterator-based form (taking const charT* fmt), and three +additional overloads of the convenience form (one taking const charT* +str, another taking const charT* fmt, and the third taking both const +charT* str and const charT* fmt). 28.11.4 [re.alg.replace]: +

    +
    +
    template <class OutputIterator, class BidirectionalIterator, 
+    class traits, class charT> 
+  OutputIterator 
+  regex_replace(OutputIterator out, 
+                BidirectionalIterator first, BidirectionalIterator last, 
+                const basic_regex<charT, traits>& e, 
+                const basic_string<charT>& fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);
 
-
    Proposed resolution:
    
-        
    
+template <class OutputIterator, class BidirectionalIterator, 
+    class traits, class charT> 
+  OutputIterator 
+  regex_replace(OutputIterator out, 
+                BidirectionalIterator first, BidirectionalIterator last, 
+                const basic_regex<charT, traits>& e, 
+                const charT* fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);
+
    +

    ...

    +
    template <class traits, class charT> 
+  basic_string<charT> 
+  regex_replace(const basic_string<charT>& s, 
+                const basic_regex<charT, traits>& e, 
+                const basic_string<charT>& fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);
 
-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:
+template <class traits, class charT> 
+  basic_string<charT> 
+  regex_replace(const basic_string<charT>& s, 
+                const basic_regex<charT, traits>& e, 
+                const charT* fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);
 
-        
    
-        
    
+template <class traits, class charT> 
+  basic_string<charT> 
+  regex_replace(const charT* s, 
+                const basic_regex<charT, traits>& e, 
+                const basic_string<charT>& fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);
 
-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. ...
+template <class traits, class charT> 
+  basic_string<charT> 
+  regex_replace(const charT* s, 
+                const basic_regex<charT, traits>& e, 
+                const charT* fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);
+
    +
    -

    -

    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.

    +

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

    +

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

    +

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

    +

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

    +

    View all issues with New status.

    Discussion:

    -

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

    +regex_match() and regex_search() take const basic_string<charT, ST, +SA>&. regex_replace() takes const basic_string<charT>&. This prevents +regex_replace() from accepting basic_strings with custom traits and +allocators. +

    -

    -

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

    Proposed resolution:

    +

    +Overloads of regex_replace() taking basic_string should be additionally +templated on class ST, class SA and take const basic_string<charT, ST, +SA>&. Consistency with regex_match() and regex_search() would place +class ST, class SA as the first template arguments; compatibility with +existing code using TR1 and giving explicit template arguments to +regex_replace() would place class ST, class SA as the last template arguments. +

    -

    -

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

    +
    +

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

    +

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

    +

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

    +

    View all issues with Review status.

    +

    Discussion:

    -Quoting from Section 3.4, Assignment operators, of Al Vermeulen's -Proposal for Standard C++ Array Classes (see c++std-lib-704; -N0308): +The mersenne_twister_engine is required to use a seeding method that is given +as an algorithm parameterized over the number of bits W. I doubt whether the given generalization +of an algorithm that was originally developed only for unsigned 32-bit integers is appropriate +for other bit widths. For instance, W could be theoretically 16 and UIntType a 16-bit integer, in +which case the given multiplier would not fit into the UIntType. Moreover, T. Nishimura and M. +Matsumoto have chosen a dif ferent multiplier for their 64 bit Mersenne Twister +[reference].

    -

    - ...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. +I see two possible resolutions:

    -

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

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

    -

    +

    +See N2424 +for further discussion. +

    -Requires: The length of the array to which the argument refers -equals size(). +

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

    +
    -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]: +See N2424 +for the proposed resolution.

    +

    [ +Stephan Tolksdorf adds pre-Bellevue: +]

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

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

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

    +

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

    +

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

    +

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

    View all issues with Open status.

    +

    Duplicate of: 795

    Discussion:

    -

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

    -

    +

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

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

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

    -

    -

    +

    [ +Bellevue: +]

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

    -

    +
    +

    +Disagreement persists. +

    +

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

    +

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

    +

    +Objector proposes the following possible compromise positions: +

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

    Proposed resolution:

    +

    +See N2424 +for the proposed resolution. +

    -

    -

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

    -

    +
    +

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

    +

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

    +

    View all issues with Open status.

    +

    Discussion:

    +

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

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

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

    -

    -

    +

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

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

    [ +Bellevue: +]

    -

    -

    -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. +
    +In N2424. Not wildly enthusiastic, not really felt necessary. Less +frequently used in practice. Not terribly bad either. Move to OPEN. +
    - -

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

    Proposed resolution:

    +

    +See N2424 +for the proposed resolution. +

    -

    [ -Batavia: Alan and Pete to work. +Stephan Tolksdorf adds pre-Bellevue: ]

    - -

    Proposed resolution:

    +

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

    +
    +

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

    +

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

    +

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

    +
    -
    -

    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:

    -

    +

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

    +
    +

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

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

    +Replace both occurrences of +

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

    +with +

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

    -

    +

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

    -Propose add a bullet for Remarks along with a brief description. +

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

    +
    -

    -

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

    +

    +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);". +

    -

    Proposed resolution:

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

    +
    + +
    -

    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.

    +

    740. Please remove *_ptr<T[N]>

    +

    Section: 20.6.11.4 [unique.ptr.compiletime] Status: Ready + Submitter: Herb Sutter Date: 2007-10-04

    +

    View all issues with Ready 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. +Please don't provide *_ptr<T[N]>. It doesn't enable any useful +bounds-checking (e.g., you could imagine that doing op++ on a +shared_ptr<T[N]> yields a shared_ptr<T[N-1]>, but that promising path +immediately falters on op-- which can't reliably dereference because we +don't know the lower bound). Also, most buffers you'd want to point to +don't have a compile-time known size.

    - -

    Proposed resolution:

    +To enable any bounds-checking would require run-time information, with +the usual triplet: base (lower bound), current offset, and max offset +(upper bound). And I can sympathize with the point of view that you +wouldn't want to require this on *_ptr itself. But please let's not +follow the <T[N]> path, especially not with additional functions to +query the bounds etc., because this sets wrong user expectations by +embarking on a path that doesn't go all the way to bounds checking as it +seems to imply.

    +

    +If bounds checking is desired, consider a checked_*_ptr instead (e.g., +checked_shared_ptr). And make the interfaces otherwise identical so that +user code could easily #define/typedef between prepending checked_ on +debug builds and not doing so on release builds (for example). +

    - - - -
    -

    629. complex insertion and locale dependence

    -

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

    -

    View all other issues in [complex.ops].

    -

    View all issues with Open status.

    -

    Discussion:

    -is there an issue opened for (0,3) as complex number with -the French local? With the English local, the above parses as an -imaginery complex number. With the French locale it parses as a -real complex number. +Note that some may object that checked_*_ptr may seem to make the smart +pointer more like vector, and we don't want two ways to spell vector. I +don't agree, but if that were true that would be another reason to +remove *_ptr<T[N]> which equally makes the smart pointer more like +std::array. :-)

    -

    -Further notes/ideas from the lib-reflector, messages 17982-17984: -

    +

    [ +Bellevue: +]

    +
    -

    -Add additional entries in num_punct to cover the complex separator (French would be ';'). +

    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.

    -Insert a space before the comma, which should eliminate the ambiguity. +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.

    -Solve the problem for ordered sequences in general, perhaps with a -dedicated facet. Then complex should use that solution. +straw poll unanimous move to Ready.

    @@ -7931,946 +11682,815 @@ dedicated facet. Then complex should use that solution.

    Proposed resolution:

    +Change the synopsis under 20.6.11 [unique.ptr] p2:

    +
    ...
+template<class T> struct default_delete; 
+template<class T> struct default_delete<T[]>; 
+template<class T, size_t N> struct default_delete<T[N]>;
 
+template<class T, class D = default_delete<T>> class unique_ptr; 
+template<class T, class D> class unique_ptr<T[], D>; 
+template<class T, class D, size_t N> class unique_ptr<T[N], D>;
+...
+
    +

    +Remove the entire section 20.6.11.1.3 [unique.ptr.dltr.dflt2] default_delete<T[N]>. +

    +

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

    -
    -

    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:

    -

    - -Section 26.1 [numeric.requirements], p1 suggests that a -valarray specialization on a type T that -satisfies the requirements enumerated in the paragraph is itself a -valid type on which valarray may be instantiated -(Footnote 269 makes this clear). I.e., -valarray<valarray<T> > is valid as long as -T is valid. However, since implementations of -valarray are permitted to initialize storage allocated by -the class by invoking the default ctor of T followed by -the copy assignment operator, such implementations of -valarray wouldn't work with (perhaps user-defined) -specializations of valarray whose assignment operator had -undefined behavior when the size of its argument didn't match the size -of *this. By "wouldn't work" I mean that it would -be impossible to resize such an array of arrays by calling the -resize() member function on it if the function used the -copy assignment operator after constructing all elements using the -default ctor (e.g., by invoking new value_type[N]) to -obtain default-initialized storage) as it's permitted to do. - -

    -

    - -Stated more generally, the problem is that -valarray<valarray<T> >::resize(size_t) isn't -required or guaranteed to have well-defined semantics for every type -T that satisfies all requirements in -26.1 [numeric.requirements]. -

    -

    -I believe this problem was introduced by the adoption of the -resolution outlined in N0857, -Assignment of valarrays, from 1996. The copy assignment -operator of the original numerical array classes proposed in N0280, -as well as the one proposed in N0308 -(both from 1993), had well-defined semantics for arrays of unequal -size (the latter explicitly only when *this was empty; -assignment of non empty arrays of unequal size was a runtime error). -

    -

    -The justification for the change given in N0857 was the "loss of -performance [deemed] only significant for very simple operations on -small arrays or for architectures with very few registers." -

    -

    +

    +

    742. Enabling swap for proxy iterators

    +

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

    +

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

    +

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

    +

    View all issues with Open status.

    +

    Discussion:

    +

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

    -Since tiny arrays on a limited subset of hardware architectures are -likely to be an exceedingly rare case (despite the continued -popularity of x86) I propose to revert the resolution and make the -behavior of all valarray assignment operators -well-defined even for non-conformal arrays (i.e., arrays of unequal -size). I have implemented this change and measured no significant -degradation in performance in the common case (non-empty arrays of -equal size). I have measured a 50% (and in some cases even greater) -speedup in the case of assignments to empty arrays versus calling -resize() first followed by an invocation of the copy -assignment operator. +

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

    -

    +
    namespace Mine {
 
+template <class T>
+struct proxy {...};
 
-
    Proposed resolution:
    
-        
    
+template <class T>
+struct proxied_iterator
+{
+   typedef T value_type;
+   typedef proxy<T> reference;
+   reference operator*() const;
+   ...
+};
 
-Change 26.5.2.2 [valarray.assign], p1 as follows:
+struct A
+{
+   // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
+   void swap(A&);
+   ...
+};
 
-        
    
-        
    
-            
    
-                
+void swap(A&, A&);
+void swap(proxy<A>, A&);
+void swap(A&, proxy<A>);
+void swap(proxy<A>, proxy<A>);
 
-valarray<T>& operator=(const valarray<T>& x);
+}  // Mine
 
-                
-            
    
-            
    
+...
 
--1- Each element of the *this array is assigned the value
-of  the  corresponding  element   of  the  argument  array.   The
-resulting behavior is undefined if When the length of
-the  argument  array  is  not   equal  to  the  length  of  the  *this
-array.  resizes  *this  to make  the  two
-arrays     the      same     length,     as      if     by     calling
-resize(x.size()), before performing the assignment.
+Mine::proxied_iterator<Mine::A> i(...)
+Mine::A a;
+swap(*i1, a);
+
    -

    - -

    +

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

    -And add a new paragraph just below paragraph 1 with the following -text: +

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

    -

    -
    -

    +

    [ +Bellevue: +]

    --2- Postcondition: size() == x.size(). -

    -
    -

    +

    +

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

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

    -
    -

    --?- When the length, N of the array referred -to by the argument is not equal to the length of *this, -the operator resizes *this to make the two arrays the -same length, as if by calling resize(N), before -performing the assignment. +

    Proposed resolution:

    +

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

    -

    -
    +
    +

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

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

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

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

    [ -Kona (2007): Gaby to propose wording for an alternative resolution in -which you can assign to a valarray of size 0, but not to any other -valarray whose size is unequal to the right hand side of the assignment. -]

    -

    631. conflicting requirements for BinaryPredicate

    -

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

    -

    View all other issues in [algorithms].

    -

    View all issues with Open status.

    +

    743. rvalue swap for shared_ptr

    +

    Section: 20.6.12.2.9 [util.smartptr.shared.spec] Status: Ready + Submitter: Howard Hinnant Date: 2007-10-10

    +

    View all issues with Ready status.

    Discussion:

    -The general requirements for BinaryPredicate (in 25 [algorithms]/8) contradict the implied specific requirements for -some functions. In particular, it says that: +When the LWG looked at 674 in Kona the following note was made:

    -[...] if an algorithm takes BinaryPredicate binary_pred -as its argument and first1 and first2 as its -iterator arguments, it should work correctly in the construct if -(binary_pred (*first1 , *first2 )){...}. -BinaryPredicate always takes the first iterator type as its -first argument, that is, in those cases when T value is -part of the signature, it should work correctly in the context of if -(binary_pred (*first1 , value)){...}. +We may need to open an issue to deal with the question of +whether shared_ptr needs an rvalue swap.

    -In the description of upper_bound (25.3.3.2 [upper.bound]/2), however, the use is described as -"!comp(value, e)", where e is an -element of the sequence (a result of dereferencing -*first). +This issue was opened in response to that note.

    -In the description of lexicographical_compare, we have both -"*first1 < *first2" and "*first2 -< *first1" (which presumably implies "comp( -*first1, *first2 )" and "comp( *first2, -*first1 )". +I believe allowing rvalue shared_ptrs to swap is both +appropriate, and consistent with how other library components are currently specified.

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

    - - -

    Proposed resolution:

    +

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

    - -

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

    -

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

    +
    - - - -
    -

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

    -

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

    -

    View other active issues in [container.requirements].

    -

    View all other issues in [container.requirements].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -A recent news group discussion: -

    -
    -

    -Anyone know if the Standard has anything to say about the time complexity -of size() for std::set? I need to access a set's size (/not/ to know if it is empty!) heavily -during an algorithm and was thus wondering whether I'd be better off -tracking the size "manually" or whether that'd be pointless. -

    -

    -That would be pointless. size() is O(1). -

    +

    Proposed resolution:

    -Nit: the standard says "should" have constant time. Implementations may take -license to do worse. I know that some do this for std::list<> as a part of -some trade-off with other operation. +Change the synopsis in 20.6.12.2 [util.smartptr.shared]:

    -

    -I was aware of that, hence my reluctance to use size() for std::set. -

    -

    -However, this reason would not apply to std::set<> as far as I can see. -

    -

    -Ok, I guess the only option is to try it and see... -

    -
    +
    void swap(shared_ptr&& r);
+...
+template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b);
+template<class T> void swap(shared_ptr<T>&& a, shared_ptr<T>& b);
+template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>&& b);
+

    -If I have any recommendation to the C++ Standards Committee it is that -implementations must (not "should"!) document clearly[1], where known, the -time complexity of *all* container access operations. -

    -

    -[1] In my case (gcc 4.1.1) I can't swear that the time complexity of size() -for std::set is not documented... but if it is it's certainly well hidden -away. +Change 20.6.12.2.4 [util.smartptr.shared.mod]:

    +
    void swap(shared_ptr&& r);
+
    -

    Proposed resolution:

    +Change 20.6.12.2.9 [util.smartptr.shared.spec]:

    - -

    [ -Kona (2007): This issue affects all the containers. We'd love to see a -paper dealing with the broad issue. We think that the complexity of the -size() member of every container -- except possibly list -- should be -O(1). Alan has volunteered to provide wording. -]

    +
    template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b);
+template<class T> void swap(shared_ptr<T>&& a, shared_ptr<T>& b);
+template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>&& b);
+
    -

    635. domain of allocator::address

    -

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

    -

    View other active issues in [allocator.requirements].

    -

    View all other issues in [allocator.requirements].

    -

    View all issues with Open status.

    +

    744. What is the lifetime of an exception pointed to by an exception_ptr?

    +

    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 Ready status.

    Discussion:

    -The table of allocator requirements in 20.1.2 [allocator.requirements] describes -allocator::address as: +Without some lifetime guarantee, it is hard to know how this type can be +used. Very specifically, I don't see how the current wording would +guarantee and exception_ptr caught at the end of one thread could be safely +stored and rethrown in another thread - the original motivation for this +API.

    -
    a.address(r)
-a.address(s)
-

    -where r and s are described as: +(Peter Dimov agreed it should be clearer, maybe a non-normative note to +explain?)

    -

    -a value of type X::reference obtained by the expression *p. -

    -

    -and p is -

    +

    [ +Bellevue: +]

    -

    -a value of type X::pointer, obtained by calling a1.allocate, -where a1 == a -

    +

    -This all implies that to get the address of some value of type T that -value must have been allocated by this allocator or a copy of it. +Agree the issue is real.

    -

    -However sometimes container code needs to compare the address of an external value of -type T with an internal value. For example list::remove(const T& t) -may want to compare the address of the external value t with that of a value -stored within the list. Similarly vector or deque insert may -want to make similar comparisons (to check for self-referencing calls). +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 >).

    -

    -Mandating that allocator::address can only be called for values which the -allocator allocated seems overly restrictive. +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 20.1.2 [allocator.requirements]: +Change 18.7.5 [propagation]/7:

    -

    -r : a value of type X::reference obtained by the expression *p. -

    -

    -s : a value of type X::const_reference obtained by the -expression *q or by conversion from a value r. -

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

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

    - - -

    [ -Kona (2007): This issue is section 8 of N2387. There was some discussion of it but -no resolution to this issue was recorded. Moved to Open. -]

    - - -
    -

    638. deque end invalidation during erase

    -

    Section: 23.2.2.3 [deque.modifiers] Status: Review - Submitter: Steve LoBasso Date: 2007-02-17

    -

    View all issues with Review status.

    +

    746. current_exception may fail with bad_alloc

    +

    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 Ready status.

    Discussion:

    -The standard states at 23.2.2.3 [deque.modifiers]/4: -

    -
    deque erase(...)
-
    -

    -Effects: ... An erase at either end of the deque invalidates only -the iterators and the references to the erased elements. -

    -
    -

    -This does not state that iterators to end will be invalidated. -It needs to be amended in such a way as to account for end invalidation. +I understand that the attempt to copy an exception may run out of memory, +but I believe this is the only part of the standard that mandates failure +with specifically bad_alloc, as opposed to allowing an +implementation-defined type derived from bad_alloc. For instance, the Core +language for a failed new expression is:

    +

    -Something like: +Any other allocation function that fails to allocate storage shall indicate +failure only by throwing an exception of a type that would match a handler +(15.3) of type std::bad_alloc (18.5.2.1).

    -

    -Any time the last element is erased, iterators to end are invalidated. -

    - +

    -This would handle situations like: +I think we should allow similar freedom here (or add a blanket +compatible-exception freedom paragraph in 17)

    -
    erase(begin(), end())
-erase(end() - 1)
-pop_back()
-resize(n, ...) where n < size()
-pop_front() with size() == 1
-
-
    - - - -

    Proposed resolution:

    -Change 23.2.2.3 [deque.modifiers], p4: +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.

    -
    -
    iterator erase(const_iterator position); 
-iterator erase(const_iterator first, const_iterator last);
-
    +

    [ +Bellevue: +]

    +

    --4- Effects: An erase in the middle of the deque -invalidates all the iterators and references to elements of the -deque and the past-the-end iterator. An erase at -either end of the deque invalidates only the iterators and the -references to the erased elements, except that erasing at the end -also invalidates the past-the-end iterator. +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]: +

    -

    [ -Kona (2007): Proposed wording added and moved to Review. -]

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

    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.

    +

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

    +

    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 Open status.

    Discussion:

    -According to the description given in 28.10 [re.results]/2 the class template -match_results "shall satisfy the requirements of a Sequence, [..], -except that only operations defined for const-qualified Sequences -are supported". -Comparing the provided operations from 28.10 [re.results]/3 with the -sequence/container tables 80 and 81 one recognizes the following -missing operations: +We have 3 separate type traits to identify classes supporting no-throw +operations, which are very useful when trying to provide exception safety +guarantees. However, I'm not entirely clear on what the current wording +requires of a conforming implementation. To quote from +has_nothrow_default_constructor: +

    +

    +or T is a class type with a default constructor that is known not to throw +any exceptions +

    +

    +What level of magic do we expect to deduce if this is known?

    -

    -1) The members +E.g.

    -
    const_iterator rbegin() const;
-const_iterator rend() const;
+
    struct test{
+ int x;
+ test() : x() {}
+};
 
    
-
 
    
-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:
+Should I expect a conforming compiler to 
+ assert( has_nothrow_constructor<test>::value )
 
    
 
    
-(a) Several typedefs delegate to
-iterator_traits<BidirectionalIterator>.
+Is this a QoI issue?
 
    
 
    
-(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.
+Should I expect to 'know' only if-and-only-if there is an inline definition
+available?
 
    
 
    
-2) The new "convenience" members
+Should I never expect that to be true, and insist that the user supplies an
+empty throw spec if they want to assert the no-throw guarantee?
 
    
-
    const_iterator cbegin() const;
-const_iterator cend() const;
-const_iterator crbegin() const;
-const_iterator crend() const;
-
    
 
    
-should be added according to tables 80/81.
+It would be helpful to maybe have a footnote explaining what is required,
+but right now I don't know what to suggest putting in the footnote.
 
    
-
-
-
    Proposed resolution:
    
 
    
-Add the following members to the match_results synopsis after end() in 28.10 [re.results]
-para 3:
+(agreement since is that trivial ops and explicit no-throws are required.
+Open if QoI should be allowed to detect further)
 
    
 
-
    const_iterator cbegin() const; 
-const_iterator cend() const;
-
    
+
    [
+Bellevue:
+]
    
 
-
    
-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.
-
    
+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.
 
    
 
-
    const_iterator end() const;
-const_iterator cend() const;
-
    
-
    
+
+
    Proposed resolution:
    
 
    
--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.
-]
    
 
 
 
 
 
 
    
-
    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.
    
+
    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.
 
    
-
    
-
    
-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.
+For instance:
 
    
-
-
      
-
    • 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
      • 
-
    
+
    
+
    struct awkward {
+ awkward( const awkward & ) throw() {}
+ awkward( awkward & ) { throw "oops"; } };
+
    
 
    
 
+
+
    Proposed resolution:
    
 
    
-I'm not sure how many of those reserve naming patterns that might affect
-us, but I am equally sure I don't own a copy of any of these to check!
-
    
-
    
-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)
+Change 20.4.4.3 [meta.unary.prop]:
 
    
 
-
    [
-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.
-]
    
+
    
+
    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.
+
    
+
    
 
-
    Proposed resolution:
    
 
 
 
 
 
 
    
-
    659. istreambuf_iterator should have an operator->()
    
-
    Section: 24.5.3 [istreambuf.iterator] Status: Open
- Submitter: Niels Dekker Date: 2007-03-25
    
-
    View all other issues in [istreambuf.iterator].
    
+
    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: Open
+ Submitter: Alisdair Meredith Date: 2007-10-10
    
 
    View all issues with Open status.
    
 
    Discussion:
    
 
    
-Greg Herlihy has clearly demonstrated that a user defined input
-iterator should have an operator->(), even if its
-value type is a built-in type (comp.std.c++, "Re: Should any iterator
-have an operator->() in C++0x?", March 2007).  And as Howard
-Hinnant remarked in the same thread that the input iterator
-istreambuf_iterator doesn't have one, this must be a
-defect!
+With the pending arrival of explicit conversion functions though, I'm
+wondering if we want an additional trait, is_explictly_convertible?
 
    
-
    
-Based on Greg's example, the following code demonstrates the issue:
-
     #include <iostream> 
- #include <fstream>
- #include <streambuf> 
 
- typedef char C;
- int main ()
- {
-   std::ifstream s("filename", std::ios::in);
-   std::istreambuf_iterator<char> i(s);
+
    [
+Bellevue:
+]
    
 
-   (*i).~C();  // This is well-formed...
-   i->~C();  // ... so this should be supported!
- }
-
    
 
-
    
-Of course, operator-> is also needed when the value_type of
-istreambuf_iterator is a class.
-
    
-
    
-The operator-> could be implemented in various ways.  For instance,
-by storing the current value inside the iterator, and returning its
-address.  Or by returning a proxy, like operator_arrow_proxy, from
-http://www.boost.org/boost/iterator/iterator_facade.hpp
-
    
-
    
-I hope that the resolution of this issue will contribute to getting a
-clear and consistent definition of iterator concepts.
-
    
+
    
+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:
    
 
    
-Add to the synopsis in 24.5.3 [istreambuf.iterator]:
 
    
 
-
    charT operator*() const;
-pointer operator->() const;
-istreambuf_iterator<charT,traits>& operator++();
-
    
 
-
    
-Change 24.5.3 [istreambuf.iterator], p1:
-
    
 
-
    
-The class template istreambuf_iterator reads successive
-characters from the streambuf for which it was constructed.
-operator* provides access to the current input character, if
-any. operator-> may return a proxy. Each time
-operator++ is evaluated, the iterator advances to the next
-input character. If the end of stream is reached
-(streambuf_type::sgetc() returns traits::eof()), the
-iterator becomes equal to the end of stream iterator value. The default
-constructor istreambuf_iterator() and the constructor
-istreambuf_iterator(0) both construct an end of stream iterator
-object suitable for use as an end-of-range.
-
    
 
 
+
    
+
    751. change pass-by-reference members of vector<bool> to pass-by-value?
    
+
    Section: 23.2.7 [vector.bool] Status: New
+ Submitter: Alisdair Meredith Date: 2007-10-10
    
+
    View other active issues in [vector.bool].
    
+
    View all other issues in [vector.bool].
    
+
    View all issues with New status.
    
+
    Discussion:
    
+
    
+A number of vector<bool> members take const bool& as arguments.
+Is there any chance we could change them to pass-by-value or would I 
+be wasting everyone's time if wrote up an issue?
+
    
 
 
    [
-Kona (2007): The proposed resolution is inconsistent because the return
-type of istreambuf_iterator::operator->() is specified to be pointer,
-but the proposed text also states that "operator-> may return a proxy."
+post Bellevue:
 ]
    
 
 
-
    [
-Niels Dekker (mailed to Howard Hinnant):
-]
    
-
 
    
 
    
-The proposed resolution does
-not seem inconsistent to me. istreambuf_iterator::operator->() should
-have istreambuf_iterator::pointer as return type, and this return type
-may in fact be a proxy.
+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.
 
    
 
    
-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.
+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.
 
    
 
    
-Still I wouldn't mind if the text "operator-> may return a proxy" would
-be removed from the resolution. I think it's up to the library
-implementation, how to implement istreambuf_iterator::operator->().  As
-longs as it behaves as expected: i->m should have the same effect as
-(*i).m. Even for an explicit destructor call, i->~C().  The main issue
-is just: istreambuf_iterator should have an operator->()!
+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:
    
+
    
+
    
+
+
+
+
 
 
    
-
    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.
    
+
    752. Allocator complexity requirement
    
+
    Section: 20.1.2 [allocator.requirements] Status: New
+ Submitter: Hans Boehm Date: 2007-10-11
    
+
    View other active issues in [allocator.requirements].
    
+
    View all other issues in [allocator.requirements].
    
+
    View all issues with New status.
    
 
    Discussion:
    
 
    
-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.
+Did LWG recently discuss 20.1.2 [allocator.requirements]-2, which states that "All the operations
+on the allocators are expected to be amortized constant time."?
+
    
+
    
+As I think I pointed out earlier, this is currently fiction for
+allocate() if it has to obtain memory from the OS, and it's unclear to
+me how to interpret this for construct() and destroy() if they deal with
+large objects.  Would it be controversial to officially let these take
+time linear in the size of the object, as they already do in real life?
+
    
+
    
+Allocate() more blatantly takes time proportional to the size of the
+object if you mix in GC.  But it's not really a new problem, and I think
+we'd be confusing things by leaving the bogus requirements there.  The
+current requirement on allocate() is generally not important anyway,
+since it takes O(size) to construct objects in the resulting space.
+There are real performance issues here, but they're all concerned with
+the constants, not the asymptotic complexity.
 
    
 
-
      
-
    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
+Change 20.1.2 [allocator.requirements]/2:
 
      
-
      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
+-2- Table 39 describes the requirements on types manipulated through
+allocators. All the operations on the allocators are expected to be
+amortized constant time, except that allocate and
+construct may require time proportional to the size of the
+object allocated or constructed. Table 40 describes the
+requirements on allocator types.
 
      
-
-
      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.
    
+
    753. Move constructor in draft
    
+
    Section: 20.1.1 [utility.arg.requirements] Status: Open
+ Submitter: Yechezkel Mett Date: 2007-10-14
    
+
    View other active issues in [utility.arg.requirements].
    
+
    View all other issues in [utility.arg.requirements].
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
-22.2.1.4.2 [locale.codecvt.virtuals], para 7 says (regarding do_unshift):
+The draft standard n2369 uses the term move constructor in a few
+places, but doesn't seem to define it.
 
    
 
-
    
-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:
+MoveConstructible requirements are defined in Table 33 in 20.1.1 [utility.arg.requirements] as
+follows:
 
    
 
-
    
-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.
-
    
+
    
+
+
+
+
+
+
+
+
+
+
+
+
    MoveConstructible requirements
    expression post-condition
    T t = rv t is equivalent to the value of rv before the construction
    [Note: There is no requirement on the value of rv after the 
+construction. -- end note]
    
+
    
 
 
    
-[Plum ref _222152Y50]
+(where rv is a non-const rvalue of type T).
 
    
 
-
-
    Proposed resolution:
    
 
    
-Change 22.2.1.4.2 [locale.codecvt.virtuals], p7:
+So I assume the move constructor is the constructor that would be used
+in filling the above requirement.
 
    
 
-
    
 
    
-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.
+For vector::reserve, vector::resize and the vector modifiers given in
+23.2.6.4 [vector.modifiers] we have
 
    
-
    
-
-
-
 
+
    
+Requires: If value_type has a move constructor, that constructor shall
+not throw any exceptions.
+
    
 
-
    
-
    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:
+Firstly "If value_type has a move constructor" is superfluous; every
+type which can be put into a vector has a move constructor (a copy
+constructor is also a move constructor). Secondly it means that for
+any value_type which has a throwing copy constructor and no other move
+constructor these functions cannot be used -- which I think will come
+as a shock to people who have been using such types in vector until
+now!
 
    
 
-
    
-codecvt<char,char,mbstate_t>, returns noconv.
-
    
-
 
    
-The following objection has been raised:
+I can see two ways to correct this. The simpler, which is presumably
+what was intended, is to say "If value_type has a move constructor and
+no copy constructor, the move constructor shall not throw any
+exceptions" or "If value_type has a move constructor which changes the
+value of its parameter,".
 
    
 
-
    
-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]
+The other alternative is add to MoveConstructible the requirement that
+the expression does not throw. This would mean that not every type
+that satisfies the CopyConstructible requirements also satisfies the
+MoveConstructible requirements. It would mean changing requirements in
+various places in the draft to allow either MoveConstructible or
+CopyConstructible, but I think the result would be clearer and
+possibly more concise too.
 
    
 
 
 
    Proposed resolution:
    
 
    
-Change 22.2.1.4.2 [locale.codecvt.virtuals], p8:
+Add new defintions to 17.1 [definitions]:
 
    
 
 
    
-
    Returns: An enumeration value, as summarized in Table 76:
    
-
    ...
    
 
    
-codecvt<char,char,mbstate_t>, returns noconv.
+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. :-)
 
    
 
    
 
@@ -8880,48 +12500,84 @@ Change 22.2.1.4.2 [locale.codecvt.virtuals], p8:
 
 
 
    
-
    666. moneypunct::do_curr_symbol()
    
-
    Section: 22.2.6.3.2 [locale.moneypunct.virtuals] Status: Ready
- Submitter: Thomas Plum Date: 2007-04-16
    
-
    View all other issues in [locale.moneypunct.virtuals].
    
+
    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:
    
 
    
-22.2.6.3.2 [locale.moneypunct.virtuals], para 4 footnote 257 says
+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
+
    
 
    
-257) For international 
-specializations (second template parameter true) this is always four 
-characters long, usually three letters and a space.
+or:
 
    
+
    swap(v, vector<int>(v));  // shrink to fit
+
    
+
    
 
 
    
-The following objection has been raised:
+A non-binding request for shrink-to-fit can be made to a std::string via:
 
    
 
-
    
-The international currency 
-symbol is whatever the underlying locale says it is, not necessarily 
-four characters long.
-
    
+
    string s;
+...
+s.reserve(0);
+
    
 
 
    
-[Plum ref _222632Y41]
+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:
    
 
    
-Change footnote 253 in 22.2.6.3.2 [locale.moneypunct.virtuals]:
+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();
+
    
+
 
    
-253) For international specializations (second template
-parameter true) this is always typically
-four characters long, usually three letters and a space.
+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]
+
    
 
    
 
 
@@ -8929,830 +12585,1080 @@ 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
- Submitter: Thomas Plum Date: 2007-04-16
    
-
    View other active issues in [locale.money.get.virtuals].
    
-
    View all other issues in [locale.money.get.virtuals].
    
+
    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:
    
 
    
-22.2.6.1.2 [locale.money.get.virtuals], para 1 says:
+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:
 
    
 
-
    
-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.
-
    
+
    template<typename... _Args>
+void
+push(_Args&&... __args)
+  { c.push_back(std::forward<_Args>(__args)...); }
+
    
+
+
    [
+Related to 767
+]
    
+
+
 
+
    Proposed resolution:
    
 
    
-The following
-objection has been raised:
+Change 23.2.5.1.1 [queue.defn]:
 
    
 
-
    
-Some implementations interpret this to mean that a facet derived from
-ctype<wchar_t> can provide its own member do_widen(char)
-which produces e.g. L'@' for the "widened" minus sign, and that the
-'@' symbol will appear in the resulting sequence of digits.  Other
-implementations have assumed that one or more places in the standard permit the
-implementation to "hard-wire" L'-' as the "widened" minus sign.  Are
-both interpretations permissible, or only  one?
-
    
+
    void 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)...); }
+
    
 
 
    
-[Plum ref _222612Y14]
+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)...); }
+
    
+
 
    
-Furthermore: if ct.widen('9') produces L'X' (a non-digit), does a
-parse fail if a '9' appears in the subject string? [Plum ref _22263Y33]
+Change 23.2.5.2.2 [priqueue.members]:
 
    
 
-
    [
-Kona (2007): Bill and Dietmar to provide proposed wording.
-]
    
-
+
    
+
    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);
+
    
+
    
+
    
 
-
    Proposed resolution:
    
 
    
+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)...); }
+
    
+
+
 
 
 
 
 
    
-
    668. money_get's empty minus sign
    
-
    Section: 22.2.6.1.2 [locale.money.get.virtuals] Status: Open
- Submitter: Thomas Plum Date: 2007-04-16
    
-
    View other active issues in [locale.money.get.virtuals].
    
-
    View all other issues in [locale.money.get.virtuals].
    
-
    View all issues with Open status.
    
+
    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:
    
 
    
-22.2.6.1.2 [locale.money.get.virtuals], para 3 says:
+Consider the following program:
 
    
 
-
    
-If pos or neg is empty, the sign component is
-optional, and if no sign is detected, the result is given the sign 
-that corresponds to the source of the empty string.
-
    
+
    int main() {
+   shared_ptr<int> p(nullptr); 
+   return 0;
+}
+
    
 
 
    
-The following
-objection has been raised:
+This program will fail to compile because shared_ptr uses the following 
+template constructor to construct itself from pointers:
 
    
 
-
    
-A negative_sign of "" means "there is no 
-way to write a negative sign" not "any null sequence is a negative 
-sign, so it's always there when you look for it".
-
    
+
    template <class Y> shared_ptr(Y *);
+
    
 
 
    
-[Plum ref _222612Y32]
+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.
 
    
 
 
    [
-Kona (2007): Bill to provide proposed wording and interpretation of existing wording.
+Bellevue:
 ]
    
 
 
-
-
-
    Proposed resolution:
    
+
    
 
    
+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.)
 
    
-
-
-
-
-
-
    
-
    669. Equivalent postive and negative signs in money_get
    
-
    Section: 22.2.6.1.2 [locale.money.get.virtuals] Status: Open
- Submitter: Thomas Plum Date: 2007-04-16
    
-
    View other active issues in [locale.money.get.virtuals].
    
-
    View all other issues in [locale.money.get.virtuals].
    
-
    View all issues with Open status.
    
-
    Discussion:
    
 
    
-22.2.6.1.2 [locale.money.get.virtuals], para 3 sentence 4 says:
+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.
 
    
-
-
    
-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:
+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
 
    
-
-
    
-The input can successfully match only a positive sign, so the negative
-pattern is an unsuccessful match.
-
    
-
 
    
-[Plum ref _222612Y34, 222612Y51b]
+Move to Ready, modulo editorial comments
 
    
+
    
 
 
    [
-Bill to provide proposed wording and interpretation of existing wording.
+post Bellevue Peter adds:
 ]
    
 
 
-
-
-
    Proposed resolution:
    
+
    
 
    
+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();
+
    
 
-
    
-
    670. money_base::pattern and space
    
-
    Section: 22.2.6.3 [locale.moneypunct] Status: Open
- Submitter: Thomas Plum Date: 2007-04-16
    
-
    View all issues with Open status.
    
-
    Discussion:
    
 
    
-22.2.6.3 [locale.moneypunct], para 2 says:
+(Absence of explicit intentional.)
 
    
 
-
    
-The value space indicates that at least one space is required at 
-that position.
-
    
-
 
    
-The following objection has been raised:
+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
 
    
 
-
    
-Whitespace is optional when matching space. (See 22.2.6.1.2 [locale.money.get.virtuals], para 2.)
-
    
+
    template<class D> shared_ptr(nullptr_t p, D d);
+template<class D, class A> shared_ptr(nullptr_t p, D d, A a);
+
    
 
 
    
-[Plum ref _22263Y22]
+after
 
    
 
-
    [
-Kona (2007): Bill to provide proposed wording. We agree that C++03 is
-ambiguous, and that we want C++0X to say "space" means 0 or more
-whitespace characters on input.
-]
    
+
    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]:
+
    
 
-
    
-
    671. precision of hexfloat
    
-
    Section: 22.2.2.2.2 [facet.num.put.virtuals] Status: Open
- Submitter: John Salmon Date: 2007-04-20
    
-
    View all other issues in [facet.num.put.virtuals].
    
-
    View all issues with Open status.
    
-
    Discussion:
    
+
    
+
     explicit shared_ptr(nullptr_t);
+
    
+
    
 
    
-I am trying to understand how TR1 supports hex float (%a) output.
+Effects: Constructs an empty shared_ptr object.
 
    
 
    
-As far as I can tell, it does so via the following:
+Postconditions: use_count() == 0 && get() == 0.
 
    
 
    
-8.15 Additions to header <locale> [tr.c99.locale]
+Throws: nothing.
 
    
+
    
+
    
+
+
    
+
    template <class D> shared_ptr(nullptr_t, D d);
+template <class D, class A> shared_ptr<nullptr_t, D d, A a);
+
    
+
    
 
    
-In subclause 22.2.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after
-the line:
-floatfield == ios_base::scientific %E
+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.
 
    
 
    
-add the two lines:
+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.
 
    
-
    floatfield == ios_base::fixed | ios_base::scientific && !uppercase %a
-floatfield == ios_base::fixed | ios_base::scientific %A 2
-
    
 
    
-[Note: The additional requirements on print and scan functions, later
-in this clause, ensure that the print functions generate hexadecimal
-floating-point fields with a %a or %A conversion specifier, and that
-the scan functions match hexadecimal floating-point fields with a %g
-conversion specifier.  end note]
+Postconditions: use_count() == 1 and get() == 0.
 
    
 
    
-Following the thread, in 22.2.2.2.2 [facet.num.put.virtuals], we find:
+Throws: bad_alloc, or an implementation-defined exception when a
+resource other than memory could not be obtained.
 
    
 
    
-For conversion from a floating-point type, if (flags & fixed) != 0 or
-if str.precision() > 0, then str.precision() is specified in the
-conversion specification.
+Exception safety: If an exception is thrown, d(static_cast<Y *>(nullptr)) is called.
 
    
+
    
+
    
+
 
    
-This would seem to imply that when floatfield == fixed|scientific, the
-precision of the conversion specifier is to be taken from
-str.precision().  Is this really what's intended?  I sincerely hope
-that I'm either missing something or this is an oversight.  Please
-tell me that the committee did not intend to mandate that hex floats
-(and doubles) should by default be printed as if by %.6a.
+Add the following method definitions to 20.6.12.2.4 [util.smartptr.shared.mod]:
 
    
 
-
    [
-Howard: I think the fundamental issue we overlooked was that with %f,
-%e, %g, the default precision was always 6.  With %a the default
-precision is not 6, it is infinity.  So for the first time, we need to
-distinguish between the default value of precision, and the precision
-value 6.
-]
    
+
    
+
    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.
+
    
 
-
    [
-Kona (2007): Robert volunteers to propose wording.
-]
    
 
 
 
 
 
 
    
-
    672. Swappable requirements need updating
    
-
    Section: 20.1.1 [utility.arg.requirements] Status: Review
- Submitter: Howard Hinnant Date: 2007-05-04
    
-
    View other active issues in [utility.arg.requirements].
    
-
    View all other issues in [utility.arg.requirements].
    
-
    View all issues with Review status.
    
+
    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:
    
 
    
-The current Swappable is:
+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:
+]
    
+
+
 
    
-
-
-
-
-
-
    Table 37: Swappable requirements [swappable]
    expressionreturn typepost-condition
    swap(s,t)voidt has the value originally held by u, and u has the value originally 
-held by t
    
 
    
-The Swappable requirement is met by satisfying one or more of the following conditions:
+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.
 
    
-
      
-
    • 
-T is Swappable if T satisfies the CopyConstructible requirements (Table 34) 
-and the CopyAssignable requirements (Table 36);
-
      • 
-
    • 
-T is Swappable if a namespace scope function named swap exists in the same 
-namespace as the definition of T, such that the expression swap(t,u) is valid 
-and has the semantics described in this table.
-
      • 
-
    
-
    
 
    
 
+
+
+
    Proposed resolution:
    
 
    
-With the passage of rvalue reference into the language, Swappable needs to be updated to
-require only MoveConstructible and MoveAssignable.  This is a minimum.
+Add after 23.1 [container.requirements]/12:
 
    
 
+
    
 
    
-Additionally we may want to support proxy references such that the following code is acceptable:
+-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.
+
 
    
 
-
    namespace Mine {
-
-template <class T>
-struct proxy {...};
-
-template <class T>
-struct proxied_iterator
-{
-   typedef T value_type;
-   typedef proxy<T> reference;
-   reference operator*() const;
-   ...
-};
+
    
 
-struct A
-{
-   // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
-   void swap(A&);
-   ...
-};
 
-void swap(A&, A&);
-void swap(proxy<A>, A&);
-void swap(A&, proxy<A>);
-void swap(proxy<A>, proxy<A>);
 
-}  // Mine
 
-...
 
-Mine::proxied_iterator<Mine::A> i(...)
-Mine::A a;
-swap(*i1, a);
-
    +
    +

    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:

    -I.e. here is a call to swap which the user enables swapping between a proxy to a class and the class -itself. We do not need to anything in terms of implementation except not block their way with overly -constrained concepts. That is, the Swappable concept should be expanded to allow swapping -between two different types for the case that one is binding to a user-defined swap. +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]): +

    -

    Proposed resolution:

    +
    mapped_type& at(const key_type& k);
+const mapped_type &at(const key_type &k) const;
+

    -Change 20.1.1 [utility.arg.requirements]: +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;
+
    +

    --1- The template definitions in the C++ Standard Library refer to various -named requirements whose details are set out in tables 31-38. In these -tables, T is a type to be supplied by a C++ program -instantiating a template; a, b, and c are -values of type const T; s and t are modifiable -lvalues of type T; u is a value of type (possibly -const) T; and rv is a non-const -rvalue of type T. +Returns: A reference to x.second, where x is the (unique) element +whose key is equivalent to k.

    - - - - - - - -
    Table 37: Swappable requirements [swappable]
    expressionreturn typepost-condition
    swap(s,t)voidt has the value originally -held by u, and -u has the value originally held -by t

    -The Swappable requirement is met by satisfying one or more of the following conditions: +Throws: An exception object of type out_of_range if no such element +is present.

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

    [ -Kona (2007): We like the change to the Swappable requirements to use -move semantics. The issue relating to the support of proxies is -separable from the one relating to move semantics, and it's bigger than -just swap. We'd like to address only the move semantics changes under -this issue, and open a separated issue (742) to handle proxies. Also, there -may be a third issue, in that the current definition of Swappable does -not permit rvalues to be operands to a swap operation, and Howard's -proposed resolution would allow the right-most operand to be an rvalue, -but it would not allow the left-most operand to be an rvalue (some swap -functions in the library have been overloaded to permit left operands to -swap to be rvalues). +Bellevue: Editorial note: the "(unique)" differs from map. ]

    + +
    -

    673. unique_ptr update

    -

    Section: 20.6.5 [unique.ptr] Status: Open - Submitter: Howard Hinnant Date: 2007-05-04

    +

    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:

    -Since the publication of -N1856 -there have been a few small but significant advances which should be included into -unique_ptr. There exists a -reference implmenation -for all of these changes. +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:

      -Even though unique_ptr<void> is not a valid use case (unlike for shared_ptr<void>), -unexpected cases to crop up which require the instantiation of the interface of unique_ptr<void> -even if it is never used. For example see -LWG 541 for how this accidently -happened to auto_ptr. I believe the most robust way to protect unique_ptr against this -type of failure is to augment the return type of unique_ptr<T>:operator*() with -add_lvalue_reference<T>::type. This means that given an instantiated unique_ptr<void> -the act of dereferencing it will simply return void instead of causing a compile time failure. -This is simpler than creating a unique_ptr<void> specialization which isn't robust in the -face of cv-qualified void types. +The 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.

      -

      -This resolution also supports instantiations such as unique_ptr<void, free_deleter> -which could be very useful to the client. +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>

      - -
      • - -

    • -Efforts have been made to better support containers and smart pointers in shared -memory contexts. One of the key hurdles in such support is not assuming that a -pointer type is actually a T*. This can easily be accomplished -for unique_ptr by having the deleter define the pointer type: -D::pointer. Furthermore this type can easily be defaulted to -T* should the deleter D choose not to define a pointer -type (reference implementation -here). -This change has no run time overhead. It has no interface overhead on -authors of custom delter types. It simply allows (but not requires) -authors of custom deleter types to define a smart pointer for the -storage type of unique_ptr if they find such functionality -useful. std::default_delete is an example of a deleter which -defaults pointer to T* by simply ignoring this issue -and not including a pointer typedef. +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. -When the deleter type is a function pointer then it is unsafe to construct -a unique_ptr without specifying the function pointer in the constructor. -This case is easy to check for with a static_assert assuring that the -deleter is not a pointer type in those constructors which do not accept deleters. +In 20.6.11 [unique.ptr]/2 add as the last sentence to the existing para:

        -
        unique_ptr<A, void(*)(void*)> p(new A);  // error, no function given to delete the pointer!
-
        - +
        +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. -
    +
  • +

    +20.6.11.2.1 [unique.ptr.single.ctor]/1: No changes necessary. +

    +

    [ -Kona (2007): We don't like the solution given to the first bullet in -light of concepts. The second bullet solves the problem of supporting -fancy pointers for one library component only. The full LWG needs to -decide whether to solve the problem of supporting fancy pointers -piecemeal, or whether a paper addressing the whole library is needed. We -think that the third bullet is correct. +N.B.: We only need the requirement that D is DefaultConstructible. +The current wording says just this. ]

    +
    +
    • -

    [ -Post Kona: Howard adds example user code related to the first bullet: -]

    - +
  • +

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

    -
    void legacy_code(void*, std::size_t);
+
    
+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>
+]
    
 
-void foo(std::size_t N)
-{
-    std::unique_ptr<void, void(*)(void*)> ptr(std::malloc(N), std::free);
-    legacy_code(ptr.get(), N);
-}   // unique_ptr used for exception safety purposes
-
    +
    • +

  • -I.e. unique_ptr<void> is a useful tool that we don't want -to disable with concepts. The only part of unique_ptr<void> we -want to disable (with concepts or by other means) are the two member functions: +Merge 20.6.11.2.1 [unique.ptr.single.ctor]/12+13 thereby removing the sentence +of 12, but transferring the "requires" to 13:

    -
    T& operator*() const;
-T* operator->() const;
-
    - +
    +

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

    +
    +
    • -

    Proposed resolution:

    +
  • +20.6.11.2.1 [unique.ptr.single.ctor]/17: No changes necessary. +
    • +
  • +

    20.6.11.2.1 [unique.ptr.single.ctor]/21: No changes necessary.

    [ -I am grateful for the generous aid of Peter Dimov and Ion Gaztañaga in helping formulate and review -the proposed resolutions below. +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." ]

    +
    • -
    • -

      -Change 20.6.5.2 [unique.ptr.single]: +20.6.11.2.2 [unique.ptr.single.dtor]: Just before p1 add a new paragraph:

      - -
      template <class T, class D = default_delete<T>> class unique_ptr {
-   ...
-   T& typename add_lvalue_reference<T>::type operator*() const;
-   ...
-};
-
      - +

      -Change 20.6.5.2.4 [unique.ptr.single.observers]: +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. +]

      -
      T& typename add_lvalue_reference<T>::type operator*() const;
-
      - +

    • -Change 20.6.5.2 [unique.ptr.single]: +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.

      -
      template <class T, class D = default_delete<T>> class unique_ptr {
-public:
-  typedef implementation (see description below) pointer;
-   ...
-   explicit unique_ptr(T* pointer p);
-   ...
-   unique_ptr(T* pointer p, implementation defined (see description below) d);
-   unique_ptr(T* pointer p, implementation defined (see description below) d);
-   ...
-   T* pointer operator->() const;
-   T* pointer get() const;
-   ...
-   T* pointer release();
-   void reset(T* pointer p = 0 pointer());
-};
-
      +

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

      -

      - --3- If the type remove_reference<D>::type::pointer -exists, then unique_ptr<T, D>::pointer is a typedef to -remove_reference<D>::type::pointer. Otherwise -unique_ptr<T, D>::pointer is a typedef to T*. -The type unique_ptr<T, D>::pointer must be CopyConstructible -and CopyAssignable. - -

      +
      • +

    • -Change 20.6.5.2.1 [unique.ptr.single.ctor]: +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). +]

      -
      unique_ptr(T* pointer p);
-...
-unique_ptr(T* pointer p, implementation defined d); 
-unique_ptr(T* pointer p, implementation defined d); 
-...
-unique_ptr(T* pointer p, const A& d);
-unique_ptr(T* pointer p, A&& d);
-...
-unique_ptr(T* pointer p, A& d); 
-unique_ptr(T* pointer p, A&& d);
-...
-unique_ptr(T* pointer p, const A& d); 
-unique_ptr(T* pointer p, const A&& d);
-...
-
      +
      • +

    • --23- Requires: If D is not a reference type, -construction of the deleter D from an rvalue of type E -must be well formed and not throw an exception. If D is a -reference type, then E must be the same type as D -(diagnostic required). U* unique_ptr<U,E>::pointer -must be implicitly convertible to T* -pointer. +20.6.11.2.3 [unique.ptr.single.asgn]/11: No changes necessary.

      +

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

      -

      --25- Postconditions: get() == value u.get() had before -the construction, modulo any required offset adjustments resulting from -the cast from U* -unique_ptr<U,E>::pointer to T* -pointer. get_deleter() returns a reference to the -internally stored deleter which was constructed from -u.get_deleter(). +

      • + +
    • +20.6.11.2.4 [unique.ptr.single.observers]/1+4+7+9+11: No changes necessary. +
      • + +
    • +20.6.11.2.5 [unique.ptr.single.modifiers]/1: No changes necessary. +
      • + +
    • +

      +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. +
      +
      • + +
    • +20.6.11.2.5 [unique.ptr.single.modifiers]/7: No changes necessary. +
      • +

    • -Change 20.6.5.2.3 [unique.ptr.single.asgn]: +20.6.11.3.1 [unique.ptr.runtime.ctor]: Add one additional paragraph just +before the current one:

      --8- Requires: Assignment of the deleter D from an rvalue -D must not throw an exception. U* -unique_ptr<U,E>::pointer must be implicitly -convertible to T* pointer. +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*. +]

      +
      +
      • -

      -Change 20.6.5.2.4 [unique.ptr.single.observers]: -

      +
    • +20.6.11.3.2 [unique.ptr.runtime.observers]/1: Change the clause to says: +
      • -
      T* pointer operator->() const;
      -... -
      T* pointer get() const;
      +Requires: i < the size of the array to which the stored pointer +points. T shall be a complete type.
      +

    • -Change 20.6.5.2.5 [unique.ptr.single.modifiers]: +20.6.11.3.3 [unique.ptr.runtime.modifiers]/1: Change the first sentence of the +paragraph to say:

      -
      -
      T* pointer release();
      -... -
      void reset(T* pointer p = 0 pointer());
      +

      +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* +]

      +
      +
      • + + +

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

      -Change 20.6.5.3 [unique.ptr.runtime]:

      -
      template <class T, class D> class unique_ptr<T[], D> {
-public:
-  typedef implementation pointer;
-   ...
-   explicit unique_ptr(T* pointer p);
-   ...
-   unique_ptr(T* pointer p, implementation defined d);
-   unique_ptr(T* pointer p, implementation defined d);
-   ...
-   T* pointer get() const;
-   ...
-   T* pointer release();
-   void reset(T* pointer p = 0 pointer());
-};
-
      + + + +
      +

      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:

      -Change 20.6.5.3.1 [unique.ptr.runtime.ctor]: +23.1 [container.requirements]p10 states:

      -
      unique_ptr(T* pointer p);
-unique_ptr(T* pointer p, implementation defined d);
-unique_ptr(T* pointer p, implementation defined d);
-
      -

      -These constructors behave the same as in the primary template except -that they do not accept pointer types which are convertible to -T* pointer. [Note: One -implementation technique is to create private templated overloads of -these members. -- end note] +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.
        • + +

      -Change 20.6.5.3.3 [unique.ptr.runtime.modifiers]: +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():

      -
      void reset(T* pointer p = 0 pointer());
-
      +No erase() function throws an exception unless that exception +is thrown by the container's Hash or Pred object (if any). +

      --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] +Summary:

      -

      -Change 20.6.5.4 [unique.ptr.compiletime]: +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.

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

      -
      -
      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] +So:

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

      -Change 20.6.5.2.1 [unique.ptr.single.ctor]: +Create a new sub-section of 23.1.2 [associative.reqmts] (perhaps [associative.req.except]) titled "Exception +safety guarantees".

      -
      -
      unique_ptr();

      -Requires: D must be default constructible, and that -construction must not throw an exception. D must not be a -reference type or pointer type (diagnostic required). +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).

      -
      -
      unique_ptr(T* pointer p);
      -
      +

      -Requires: The expression D()(p) must be well formed. -The default constructor of D must not throw an exception. -D must not be a reference type or pointer type (diagnostic -required). +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 20.6.5.2.1 [unique.ptr.single.ctor]: +Change 23.1.3.1 [unord.req.except]p1:

      -
      unique_ptr();
      -
      +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). +
      +

      -Requires: D must be default constructible, and that -construction must not throw an exception. D must not be a -reference type or pointer type (diagnostic required). +Change 23.1 [container.requirements]p10 to add references to new sections:

      -
      -
      unique_ptr(T* pointer p);
      +
      +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: +
      +

      -Requires: The expression D()(p) must be well formed. -The default constructor of D must not throw an exception. -D must not be a reference type or pointer type (diagnostic -required). +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]).
        • -
      +
      @@ -9760,777 +13666,683 @@ 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.

      +

      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:

      -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. +Playing with g++'s C++0X mode, I noticed that the following +code, which used to compile:

      +
      #include <vector>
 
-
      Proposed resolution:
      
+int main()
+{
+    std::vector<char *> v;
+    v.push_back(0);
+}
+

      -Change 20.6.6.2 [util.smartptr.shared] as follows: +now fails with the following error message:

      -
      -
      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);
      +
      .../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*'

      -Change 20.6.6.2.1 [util.smartptr.shared.const] as follows: +As far as I know, g++ follows the current draft here.

      - -
      -
      template<class Y> shared_ptr(auto_ptr<Y>&&& r);
      -
      -

      -Add to 20.6.6.2.1 [util.smartptr.shared.const]: +Does the committee really intend to break compatibility for such cases?

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

      -
      - -
      +

      [ +Sylvain adds: +]

      -

      -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]: +I just noticed that std::pair has the same issue. +The following now fails with GCC's -std=c++0x mode:

      -
      -
      template<class Y, class D> shared_ptr& operator=(unique_ptr<Y,D>&& r);
      +
      #include <utility>
 
-
      
-
      
--4- Effects: Equivalent to shared_ptr(std::move(r)).swap(*this).
-
      
-
      
--5- Returns: *this.
-
      
-
      
+int main()
+{
+   std::pair<char *, char *> p (0,0);
+}
+
      +

      +I have not made any general audit for such problems elsewhere. +

      - -

      [ -Kona (2007): We may need to open an issue (743) to deal with the question of -whether shared_ptr needs an rvalue swap. +Related to 756 ]

      +

      [ +Bellevue: +]

      - - -
      -

      675. Move assignment of containers

      -

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

      -

      View other active issues in [container.requirements].

      -

      View all other issues in [container.requirements].

      -

      View all issues with Ready status.

      -

      Discussion:

      -

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

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

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

      -

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

      -

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

      -Change 23.1 [container.requirements]: +Add the following rows to Table 90 "Optional sequence container operations", 23.1.1 [sequence.reqmts]:

      - - - + + - - - + + + - -
      Table 86: Container requirements
      expressionreturn typeoperational semanticsassertion/note pre/post-conditioncomplexityexpression return type assertion/note
      pre-/post-condition      		 container
      a = rv;X&All existing elements of a are either move assigned or destructeda shall be equal to the -value that rv had -before this construction + +a.push_front(t) + +void + +a.insert(a.begin(), t)
      +Requires: T shall be CopyConstructible. +      		 +list, deque constant linear in a.size()
      -
      - + + +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 + + + +
      -
      -

      676. Moving the unordered containers

      -

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

      -

      View other active issues in [unord].

      -

      View all other issues in [unord].

      -

      View all issues with Ready status.

      -

      Discussion:

      -Move semantics are missing from the unordered containers. The proposed -resolution below adds move-support consistent with -N1858 -and the current working draft. +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);
+
      +

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

      - - -

      Proposed resolution:

      +
      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);
+

      -Add to 23.4 [unord]: +Change the synopsis in 23.2.4 [list]:

      -
      template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>& y); 
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>&& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
-
-...
-
-template <class Value, class Hash, class Pred, class Alloc> 
-  void swap(unordered_set<Value, Hash, Pred, Alloc>& x, 
-            unordered_set<Value, Hash, Pred, Alloc>& y); 
-
-template <class Value, class Hash, class Pred, class Alloc> 
-  void swap(unordered_set<Value, Hash, Pred, Alloc>& x, 
-            unordered_set<Value, Hash, Pred, Alloc>&& y);
-
-template <class Value, class Hash, class Pred, class Alloc> 
-  void swap(unordered_set<Value, Hash, Pred, Alloc>&& x, 
-            unordered_set<Value, Hash, Pred, Alloc>& y);
-
-template <class Value, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multiset<Value, Hash, Pred, Alloc>& x, 
-            unordered_multiset<Value, Hash, Pred, Alloc>& y);
-
-template <class Value, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multiset<Value, Hash, Pred, Alloc>& x, 
-            unordered_multiset<Value, Hash, Pred, Alloc>&& y);
-
-template <class Value, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multiset<Value, Hash, Pred, Alloc>&& x, 
-            unordered_multiset<Value, Hash, Pred, Alloc>& y);
+
      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);
 
      
 
-
      unordered_map
      
-
 
      
-Change 23.4.1 [unord.map]:
+Change 23.2.4.3 [list.modifiers]:
 
      
 
-
      class unordered_map
-{
-    ...
-    unordered_map(const unordered_map&);
-    unordered_map(unordered_map&&);
-    ~unordered_map();
-    unordered_map& operator=(const unordered_map&);
-    unordered_map& operator=(unordered_map&&);
-    ...
-    // modifiers 
-    std::pair<iterator, bool> insert(const value_type& obj); 
-    template <class P> pair<iterator, bool> insert(P&& obj);
-    iterator       insert(iterator hint, const value_type& obj);
-    template <class P> iterator       insert(iterator hint, P&& obj);
-    const_iterator insert(const_iterator hint, const value_type& obj);
-    template <class P> const_iterator insert(const_iterator hint, P&& obj);
-    ...
-    void swap(unordered_map&&);
-    ...
-    mapped_type& operator[](const key_type& k);
-    mapped_type& operator[](key_type&& k);
-    ...
-};
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>&& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>& y);
+
      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);
 
      
 
 
      
-Add to 23.4.1.1 [unord.map.cnstr]:
+Change the synopsis in 23.2.6 [vector]:
 
      
 
-
      
-
      template <class InputIterator>
-  unordered_map(InputIterator f, InputIterator l, 
-                size_type n = implementation-defined, 
-                const hasher& hf = hasher(), 
-                const key_equal& eql = key_equal(), 
-                const allocator_type& a = allocator_type());
-
      
-
-
      
-
-Requires: If the iterator's dereference operator returns an
-lvalue or a const rvalue pair<key_type, mapped_type>,
-then both key_type and mapped_type shall be
-CopyConstructible.
-
-
      
-
      
+
      void push_back(const T& x);
+void push_back(T&& x);
+template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
+
      
 
 
      
-Add to 23.4.1.2 [unord.map.elem]:
+Change 23.2.6.4 [vector.modifiers]:
 
      
 
-
      
-
-
      mapped_type& operator[](const key_type& k);
      
-
-
      
-
      ...
      
-
      
-Requires: key_type shall be CopyConstructible
-and mapped_type shall be DefaultConstructible.
-
      
-
      
+
      void push_back(const T& x);
+void push_back(T&& x);
+template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
+
      
 
-
      mapped_type& operator[](key_type&& k);
      
 
-
      
-
      
-Effects: If the unordered_map does not already contain an
-element whose key is equivalent to k , inserts the value
-std::pair<const key_type, mapped_type>(std::move(k), mapped_type()).
-
      
 
-
      
-Requires: mapped_type shall be DefaultConstructible.
-
      
 
-
      
-Returns: A reference to x.second, where x is the
-(unique) element whose key is equivalent to k.
-
      
 
-
      
 
-
      
 
+
      
+
      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:
      
 
      
-Add new section [unord.map.modifiers]:
+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:
 
      
 
-
      
-
      pair<iterator, bool> insert(const value_type& x);
-template <class P> pair<iterator, bool> insert(P&& x);
-iterator       insert(iterator hint, const value_type& x);
-template <class P> iterator       insert(iterator hint, P&& x);
-const_iterator insert(const_iterator hint, const value_type& x);
-template <class P> const_iterator insert(const_iterator hint, P&& x);
-template <class InputIterator>
-  void insert(InputIterator first, InputIterator last);
-
      
+
      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; 
 
-
      
-
      
-Requires: Those signatures taking a const value_type& parameter
-requires both the key_type and the mapped_type to be
-CopyConstructible.
-
      
+  atomic() = default; 
+  constexpr explicit atomic(T); 
+  atomic(const atomic&) = delete; 
+  atomic& operator=(const atomic&) = delete; 
 
-
      
-P shall be convertible to value_type.
- If P is instantiated as a reference
-type, then the argument x is copied from. Otherwise x
-is considered to be an rvalue as it is converted to value_type
-and inserted into the unordered_map. Specifically, in such
-cases CopyConstructible is not required of key_type or
-mapped_type unless the conversion from P specifically
-requires it (e.g. if P is a tuple<const key_type,
-mapped_type>, then key_type must be
-CopyConstructible).
-
      
+  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:
+
      
 
-
      
-The signature taking InputIterator
-parameters requires CopyConstructible of both
-key_type and mapped_type if the dereferenced
-InputIterator returns an lvalue or const rvalue
-value_type.
-
      
+
      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.
+
      
 
 
      
-Add to 23.4.1.3 [unord.map.swap]:
+Is there a true intent to remove them from the specialization or are
+they just missing from the definition because of a mistake?
 
      
 
+
      [
+Bellevue:
+]
      
+
+
 
      
-
      template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>& y);
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>&& y);
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>& y);
-
      
+
      
+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.
+
      
 
      
 
-
      unordered_multimap
      
 
+
      Proposed resolution:
      
 
      
-Change 23.4.2 [unord.multimap]:
+Change the synopsis in 29.4.3 [atomics.types.generic]:
 
      
 
-
      class unordered_multimap
-{
-    ...
-    unordered_multimap(const unordered_multimap&);
-    unordered_multimap(unordered_multimap&&);
-    ~unordered_multimap();
-    unordered_multimap& operator=(const unordered_multimap&);
-    unordered_multimap& operator=(unordered_multimap&&);
-    ...
-    // modifiers 
-    iterator insert(const value_type& obj); 
-    template <class P> iterator insert(P&& obj);
-    iterator       insert(iterator hint, const value_type& obj);
-    template <class P> iterator       insert(iterator hint, P&& obj);
-    const_iterator insert(const_iterator hint, const value_type& obj);
-    template <class P> const_iterator insert(const_iterator hint, P&& obj);
-    ...
-    void swap(unordered_multimap&&);
-    ...
-};
+
      template <class 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;
 
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
+  T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
+  T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
 
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);
+  atomic() = default; 
+  constexpr explicit atomic(T*); 
+  atomic(const atomic&) = delete; 
+  atomic& operator=(const atomic&) = delete; 
 
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
+  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:
      
 
      
-Add to 23.4.2.1 [unord.multimap.cnstr]:
+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".
 
      
 
-
      
-
      template <class InputIterator>
-  unordered_multimap(InputIterator f, InputIterator l, 
-                size_type n = implementation-defined, 
-                const hasher& hf = hasher(), 
-                const key_equal& eql = key_equal(), 
-                const allocator_type& a = allocator_type());
-
      
 
-
      
-
-Requires: If the iterator's dereference operator returns an
-lvalue or a const rvalue pair<key_type, mapped_type>,
-then both key_type and mapped_type shall be
-CopyConstructible.
-
-
      
-
      
+
      Proposed resolution:
      
 
 
      
-Add new section [unord.multimap.modifiers]:
+In 20.5 [function.objects], header <functional> synopsis replace:
 
      
 
-
      
-
      iterator insert(const value_type& x);
-template <class P> iterator       insert(P&& x);
-iterator       insert(iterator hint, const value_type& x);
-template <class P> iterator       insert(iterator hint, P&& x);
-const_iterator insert(const_iterator hint, const value_type& x);
-template <class P> const_iterator insert(const_iterator hint, P&& x);
-template <class InputIterator>
-  void insert(InputIterator first, InputIterator last);
-
      
+
      template<class 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...)>&);
+
      
 
-
      
-
      
-Requires: Those signatures taking a const value_type& parameter
-requires both the key_type and the mapped_type to be
-CopyConstructible.
-
      
+
      
+In the class function synopsis of 20.5.15.2 [func.wrap.func] replace
+
      
 
-
      
-P shall be convertible to value_type.
- If P is instantiated as a reference
-type, then the argument x is copied from. Otherwise x
-is considered to be an rvalue as it is converted to value_type
-and inserted into the unordered_multimap. Specifically, in such
-cases CopyConstructible is not required of key_type or
-mapped_type unless the conversion from P specifically
-requires it (e.g. if P is a tuple<const key_type,
-mapped_type>, then key_type must be
-CopyConstructible).
-
      
+
      function(unspecified-null-pointer-type nullptr_t);
+...
+function& operator=(unspecified-null-pointer-type nullptr_t);
+
      
 
-
      
-The signature taking InputIterator
-parameters requires CopyConstructible of both
-key_type and mapped_type if the dereferenced
-InputIterator returns an lvalue or const rvalue
-value_type.
-
      
-
      
+
      
+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...)>&);
+
      
 
 
      
-Add to 23.4.2.2 [unord.multimap.swap]:
+In 20.5.15.2.1 [func.wrap.func.con], replace
 
      
 
-
      
-
      template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
-
      
-
      
+
      function(unspecified-null-pointer-type nullptr_t);
+...
+function& operator=(unspecified-null-pointer-type nullptr_t);
+
      
 
-
      unordered_set
      
+
      
+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);
+
      
 
 
      
-Change 23.4.3 [unord.set]:
+and replace
 
      
 
-
      class unordered_set
-{
-    ...
-    unordered_set(const unordered_set&);
-    unordered_set(unordered_set&&);
-    ~unordered_set();
-    unordered_set& operator=(const unordered_set&);
-    unordered_set& operator=(unordered_set&&);
-    ...
-    // modifiers 
-    std::pair<iterator, bool> insert(const value_type& obj); 
-    pair<iterator, bool> insert(value_type&& obj);
-    iterator       insert(iterator hint, const value_type& obj);
-    iterator       insert(iterator hint, value_type&& obj);
-    const_iterator insert(const_iterator hint, const value_type& obj);
-    const_iterator insert(const_iterator hint, value_type&& obj);
-    ...
-    void swap(unordered_set&&);
-    ...
-};
+
      template <class 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);
+
      
 
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_set<Key, T, Hash, Pred, Alloc>& y);
 
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_set<Key, T, Hash, Pred, Alloc>&& y);
 
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_set<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_set<Key, T, Hash, Pred, Alloc>& y);
+
+
+
+
      
+
      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...)>&&);
 
      
 
 
      
-Add to 23.4.3.1 [unord.set.cnstr]:
+In 20.5.15.2 [func.wrap.func] class function definition, change
 
      
 
-
      
-
      template <class InputIterator>
-  unordered_set(InputIterator f, InputIterator l, 
-                size_type n = implementation-defined, 
-                const hasher& hf = hasher(), 
-                const key_equal& eql = key_equal(), 
-                const allocator_type& a = allocator_type());
-
      
+
      void swap(function&&);
+
      
 
-
      
-
-Requires: If the iterator's dereference operator returns an
-lvalue or a const rvalue value_type, then the
-value_type shall be CopyConstructible.
-
-
      
-
      
+
      
+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...)>&&);
+
      
 
 
      
-Add new section [unord.set.modifiers]:
+In 20.5.15.2.2 [func.wrap.func.mod] change
 
      
 
-
      
-
      pair<iterator, bool> insert(const value_type& x);
-pair<iterator, bool> insert(value_type&& x);
-iterator       insert(iterator hint, const value_type& x);
-iterator       insert(iterator hint, value_type&& x);
-const_iterator insert(const_iterator hint, const value_type& x);
-const_iterator insert(const_iterator hint, value_type&& x);
-template <class InputIterator>
-  void insert(InputIterator first, InputIterator last);
-
      
+
      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);
+
      
 
-
      
 
-
      
-Requires: Those signatures taking a const
-value_type& parameter requires the value_type to
-be CopyConstructible.
-
      
 
-
      
-The signature taking InputIterator parameters requires
-CopyConstructible of value_type if the dereferenced
-InputIterator returns an lvalue or const rvalue
-value_type.
-
      
 
-
      
 
-
      
 
+
      
+
      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:
      
 
      
-Add to 23.4.3.2 [unord.set.swap]:
+The new to_string and to_wstring functions described in 21.4 [string.conversions]
+have throws clauses (paragraphs 8 and 16) which say:
 
      
 
 
      
-
      template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_set<Key, T, Hash, Pred, Alloc>& y);
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_set<Key, T, Hash, Pred, Alloc>&& y);
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_set<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_set<Key, T, Hash, Pred, Alloc>& y);
-
      
+Throws: nothing
 
      
 
-
      unordered_multiset
      
-
 
      
-Change 23.4.4 [unord.multiset]:
+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:
 
      
 
-
      class unordered_multiset
-{
-    ...
-    unordered_multiset(const unordered_multiset&);
-    unordered_multiset(unordered_multiset&&);
-    ~unordered_multiset();
-    unordered_multiset& operator=(const unordered_multiset&);
-    unordered_multiset& operator=(unordered_multiset&&);
-    ...
-    // modifiers 
-    iterator insert(const value_type& obj); 
-    iterator insert(value_type&& obj);
-    iterator       insert(iterator hint, const value_type& obj);
-    iterator       insert(iterator hint, value_type&& obj);
-    const_iterator insert(const_iterator hint, const value_type& obj);
-    const_iterator insert(const_iterator hint, value_type&& obj);
-    ...
-    void swap(unordered_multiset&&);
-    ...
-};
+
      
+Throws: Nothing if the string construction throws nothing
+
      
 
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
+
      
+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).
+
      
 
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multiset<Key, T, Hash, Pred, Alloc>&& y);
 
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
-
      
 
+
      Proposed resolution:
      
 
      
-Add to 23.4.4.1 [unord.multiset.cnstr]:
+In 21.4 [string.conversions], remove the paragraphs 8 and 16.
 
      
 
 
      
-
      template <class InputIterator>
-  unordered_multiset(InputIterator f, InputIterator l, 
-                size_type n = implementation-defined, 
-                const hasher& hf = hasher(), 
-                const key_equal& eql = key_equal(), 
-                const allocator_type& a = allocator_type());
+
      string to_string(long long val); 
+string to_string(unsigned long long val); 
+string to_string(long double val); 
 
      
+
      
+Throws: nothing
+
      
+
      
 
-
      
-
-Requires: If the iterator's dereference operator returns an
-lvalue or a const rvalue value_type, then the
-value_type shall be CopyConstructible.
-
-
      
+
      
+
      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:
      
 
      
-Add new section [unord.multiset.modifiers]:
+The return clause 21.4 [string.conversions]/paragraph 15 of the new to_wstring
+overloads says:
 
      
 
 
      
-
      iterator insert(const value_type& x);
-iterator insert(value_type&& x);
-iterator       insert(iterator hint, const value_type& x);
-iterator       insert(iterator hint, value_type&& x);
-const_iterator insert(const_iterator hint, const value_type& x);
-const_iterator insert(const_iterator hint, value_type&& x);
-template <class InputIterator>
-  void insert(InputIterator first, InputIterator last);
-
      
+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:
+
      
 
-
      
-Requires: Those signatures taking a const
-value_type& parameter requires the value_type to
-be CopyConstructible.
-
      
+
      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.
+
      
 
-
      
-The signature taking InputIterator parameters requires
-CopyConstructible of value_type if the dereferenced
-InputIterator returns an lvalue or const rvalue
-value_type.
-
      
 
-
      
 
+
      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.
 
      
 
 
      
-Add to 23.4.4.2 [unord.multiset.swap]:
+[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:
 
      
 
 
      
-
      template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multiset<Key, T, Hash, Pred, Alloc>&& y);
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
-
      
+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.
 
      
 
 
@@ -10539,1166 +14351,1276 @@ 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.
      
+
      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:
      
 
      
-The C++98 standard specifies that one member function alone of the containers
-passes its parameter (T) by value instead of by const reference:
+It appears most containers declare but do not define a member-swap
+function.
 
      
 
-
      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:
+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])
 
      
 
-
      
 
      
-So that self referencing statements are guaranteed to work, for example:
+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.
 
      
-
      v.resize(v.size() + 1, v[0]);
-
      
-
      
 
 
      
-However this rationale is not convincing as the signature for push_back is:
+A quick survey of clause 23 shows that the following containers provide a
+definition for member-swap:
 
      
 
-
      void push_back(const T& x);
+
      array
+queue
+stack
+vector
 
      
 
 
      
-And push_back has similar semantics to resize (append).
-And push_back must also work in the self referencing case:
+Whereas the following declare it, but do not define the semantics:
 
      
 
-
      v.push_back(v[0]);  // must work
+
      deque
+list
+map
+multimap
+multiset
+priority_queue
+set
+unordered_map
+unordered_multi_map
+unordered_multi_set
+unordered_set
 
      
 
 
      
-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).
+Suggested resolution:
 
      
+
      
+Provide a definition for each of the affected containers...
+
      
+
+
      [
+Bellevue:
+]
      
+
+
+
      
+Move to Open and ask Alisdair to provide wording.
+
      
 
+
+
      Proposed resolution:
      
 
      
-Even with move semantics available, passing this parameter by value can be expensive.
-Consider for example vector<vector<int>>:
+Wording provided in
+N2590.
 
      
 
-
      std::vector<int> x(1000);
-std::vector<std::vector<int>> v;
-...
-v.resize(v.size()+1, x);
-
      
 
+
+
+
+
      
+
      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:
      
 
      
-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.
+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.
 
      
-
 
      
-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.
+In fact the proposal is to use std::size_t, matching the type used in the tuple_size API.
 
      
-
 
      
-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.
+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:
      
 
      
-Change 23.2.2 [deque], p2:
+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;
 
-
      class deque {
-   ...
-   void resize(size_type sz, const T& c);
-
      
+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>&);
+
      
 
      
-Change 23.2.2.2 [deque.capacity], p3:
+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.
 
      
-
-
      void resize(size_type sz, const T& c);
-
      
-
 
      
-Change 23.2.3 [list], p2:
+Throws: Nothing.
 
      
 
-
      class list {
-   ...
-   void resize(size_type sz, const T& c);
-
      
 
 
      
-Change 23.2.3.2 [list.capacity], p3:
+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...> >;
 
-
      void resize(size_type sz, const T& c);
-
      
+// 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...>&);
+
      
 
 
      
-Change 23.2.5 [vector], p2:
+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.
 
      
 
-
      class vector {
-   ...
-   void resize(size_type sz, const T& c);
-
      
 
 
      
-Change 23.2.5.2 [vector.capacity], p11:
+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>&);
+
      
 
-
      void resize(size_type sz, const T& c);
-
      
+
      
+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.
+]
      
 
 
 
 
 
      
-
      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.
      
+
      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:
      
 
      
-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].
+The class template array synopsis in 23.2.1 [array]/3 declares a member
+function
 
      
 
-
      template <class Iterator>
-class move_iterator {
-public:
-    ...
-    typedef typename iterator_traits<Iterator>::pointer pointer;
-    ...
-    pointer operator->() const {return current;}
-    ...
-private: 
-    Iterator current; // exposition only
-};
+
      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.
+
      
 
 
      
-There are two possible fixes.
+I found only one reference to this function in the issue list,
+588 where the question is raised:
 
      
 
-
        
-
      1. pointer operator->() const {return &*current;}
        2. 
-
      2. typedef Iterator pointer;
        3. 
-
      
+
      
+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);
+
      
 
 
      
-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.
+1: Effects: fill_n(begin(), N, u)
 
      
+
      
 
 
      
-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.
+[N.B: I wonder, why class array does not have a "modifiers"
+section. If it had, then assign would naturally belong to it]
 
      
 
-
      Proposed resolution:
      
 
      
-Change the synopsis in 24.4.3.1 [move.iterator]:
+Change the synopsis in 23.2.1 [array]/3:
 
      
 
-
      typedef typename iterator_traits<Iterator>::pointer pointer;
+
      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".
+
      
+
      
 
 
 
 
 
      
-
      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.
      
+
      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:
      
 
      
-In 28.4 [re.syn] of N2284, two template functions 
-are declared here: 
+The load functions are defined as
 
      
-
      // 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:
+
      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;
 
      
 
 
      
-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.
+which prevents their use in const contexts.
 
      
 
 
      [
-John adds:
+post Bellevue Peter 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.
-]
      
+
      
+
      
+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();
+}
+
      
 
-
      Proposed resolution:
      
 
      
-Add a new section after 28.10.6 [re.results.swap], which reads:
+dump core under a straightforward implementation that puts const objects in
+a read-only section.
 
      
 
      
-28.10.7 match_results non-member functions.
+There are ways to sidestep the problem, but it needs to be considered.
 
      
-
-
      
-
      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.
+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.
 
      
 
      
-
      
 
-
      
-
      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);
-
      
-
      
+
+
      Proposed resolution:
      
 
      
-Returns: m1.swap(m2).
+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;
+
      
+
 
 
 
 
 
 
      
-
      685. reverse_iterator/move_iterator difference has invalid signatures
      
-
      Section: 24.4.1.3.19 [reverse.iter.opdiff], 24.4.3.3.14 [move.iter.nonmember] Status: Review
- Submitter: Bo Persson Date: 2007-06-10
      
-
      View all issues with Review status.
      
+
      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:
      
 
      
-In C++03 the difference between two reverse_iterators
-
      
-
      ri1 - ri2
-
      
-
      
-is possible to compute only if both iterators have the same base 
-iterator. The result type is the difference_type of the base iterator. 
+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.
 
      
+
 
      
-In the current draft, the operator is defined as 24.4.1.3.19 [reverse.iter.opdiff] 
+Suggestion: Add
 
      
-
      template<class Iterator1, class Iterator2> 
-typename reverse_iterator<Iterator>::difference_type 
-   operator-(const reverse_iterator<Iterator1>& x, 
-                    const reverse_iterator<Iterator2>& y);
+
+
      explicit bitset( const char* str );
 
      
+
 
      
-The return type is the same as the C++03 one, based on the no longer 
-present Iterator template parameter. 
-
      
-
      
-Besides being slightly invalid, should this operator work only when 
-Iterator1 and Iterator2 has the same difference_type? Or should the 
-implementation choose one of them? Which one? 
-
      
-
      
-The same problem now also appears in operator-() for move_iterator
-24.4.3.3.14 [move.iter.nonmember]. 
+to std::bitset.
 
      
 
 
 
      Proposed resolution:
      
 
      
-Change the synopsis in 24.4.1.1 [reverse.iterator]:
+Add to synopsis in 23.3.5 [template.bitset]
 
      
 
-
      
-
      template <class Iterator1, class Iterator2> 
-  typename reverse_iterator<Iterator>::difference_type auto operator-( 
-    const reverse_iterator<Iterator1>& x, 
-    const reverse_iterator<Iterator2>& y) -> decltype(operator-(Iterator1, Iterator2));
-
      
-
      
-
      
-Returns: y.current - x.current.
-
      
-
      
-
      
+
      explicit bitset( const char* str );
+
      
 
 
      
-Change 24.4.1.3.19 [reverse.iter.opdiff]:
+Add to synopsis in 23.3.5.1 [bitset.cons]
 
      
 
-
      
-
      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));
+
      explicit bitset( const char* str );
 
      
-
      
 
      
-Returns: y.current - x.current.
+Effects: Constructs a bitset as if bitset(string(str)).
 
      
 
      
-
      
 
 
+
+
+
+
+
      
+
      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:
      
 
      
-Change the synopsis in 24.4.3.1 [move.iterator]:
+The resolution of 283 did not resolve similar necessary changes for algorithm
+remove_copy[_if],
+which seems to be an oversight.
 
      
 
-
      
-
      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));
-
      
-
      
+
+
      Proposed resolution:
      
 
      
-Returns: y.current - x.current.
+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.
 
      
 
 
      
-Change 24.4.3.3.14 [move.iter.nonmember]:
+or
 
      
 
 
      
-
      template <class Iterator1, class Iterator2> 
-  typename move_iterator<Iterator>::difference_type auto operator-( 
-    const move_iterator<Iterator1>& x, 
-    const move_iterator<Iterator2>& y) -> decltype(operator-(Iterator1, Iterator2));
-
      
-
      
-
      
-Returns: x.base() - y.base().
-
      
-
      
+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.
 
      
 
 
 
 
 
+
 
      
-
      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.
      
+
      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:
      
 
      
-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.
+Though issue 283 has fixed many open issues, it seems that some are still open:
 
      
 
-
-
      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:
+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:
 
      
-
      
-The return type shall not be convertible to int.
-
      
 
+
        
+
      • 
+no assignment requirements are specified (neither implicit nor explicit).
+
        • 
 
-
        [
-Kona (2007): Uncertain if nullptr will address this issue.
-]
        
+
      • 
+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)
+
        • 
+
      
 
 
 
-
      
-
      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:
      
+
      Proposed resolution:
      
 
      
-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:
+In 25.3.4 [alg.merge] replace p.1+ 2:
 
      
 
-
      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.
+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.
 
      
 
-
-
      Proposed resolution:
      
 
      
-In 20.6.6.2.1 [util.smartptr.shared.const], change:
+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.
 
      
-
-
      
--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:
+[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]
 
      
 
-
      
-
      template<class Y> weak_ptr(shared_ptr<Y> const& r);
-weak_ptr(weak_ptr const& r);
-template<class Y> weak_ptr(weak_ptr<Y> const& r);
-weak_ptr(weak_ptr const& r);
-template<class Y> weak_ptr(weak_ptr<Y> const& r);
-template<class Y> weak_ptr(shared_ptr<Y> const& r);
-
      
-
      
--4- Requires: For tThe second and
-third constructors, shall not participate in the
-overload resolution unless Y* shall be
-is implicitly convertible to T*.
-
      
-
      
-
 
 
 
 
 
 
      
-
      688. reference_wrapper, cref unsafe, allow binding to rvalues
      
-
      Section: 20.5.5.1 [refwrap.const] Status: Ready
- Submitter: Peter Dimov Date: 2007-05-10
      
-
      View other active issues in [refwrap.const].
      
-
      View all other issues in [refwrap.const].
      
+
      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 reference_wrapper can be constructed from an rvalue, either by using
-the constructor, or via cref (and ref in some corner cases). This leads
-to a dangling reference being stored into the reference_wrapper object.
-Now that we have a mechanism to detect an rvalue, we can fix them to
-disallow this source of undefined behavior.
-
      
-
-
      
-Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
+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. 
+
      
 
-
-
      Proposed resolution:
      
 
      
-In 20.5.5 [refwrap], add:
+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).
 
      
 
-
      private:
-  explicit reference_wrapper(T&&);
-
      
-
 
      
-In 20.5.5.1 [refwrap.const], add:
+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.
 
      
 
-
      
-
      explicit reference_wrapper(T&&);
-
      
-
      
--?- Not defined to disallow creating a reference_wrapper from an rvalue.
-
      
-
      
 
+
      Proposed resolution:
      
 
      
-In the synopsis of <functional> (20.5.5 [refwrap]), change the declarations
-of ref and cref to:
+In 26.3.1 [complex.synopsis] add just between the declaration of conj and fabs:
 
      
 
-
      template<class T> reference_wrapper<T> ref(T&&);
-template<class T> reference_wrapper<const T> cref(const T&&);
+
      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 20.5.5.5 [refwrap.helpers], change:
+In 26.3.7 [complex.value.ops] just after p.6 (return clause of conj) add:
 
      
 
 
      
-
      template<class T> reference_wrapper<T> ref(T&& t);
+
      template<class T> complex<T> proj(const complex<T>& x);
 
      
 
      
-
      
--1- Requires: t shall be an lvalue.
-
      
+
+Effects: Behaves the same as C99 function cproj, defined in
+subclause 7.3.9.4."
 
      
 
      
 
-
      and change:
      
+
      
+In 26.3.9 [cmplx.over]/1, add one further entry proj to
+the overload list.
+
      
 
-
      
-
      template<class T> reference_wrapper<const T> cref(const T&& t);
-
      
 
      
 
      
--6- Requires: t shall be an lvalue.
+The following function templates shall have additional overloads:
 
      
+
      arg           norm 
+conj          polar proj
+imag          real
+
      
 
      
-
      
-
 
 
-
      [
-N2292
-addresses the first part of the resolution but not the second.
-]
      
-
 
 
 
 
 
      
-
      689. reference_wrapper constructor overly constrained
      
-
      Section: 20.5.5.1 [refwrap.const] Status: Ready
- Submitter: Peter Dimov Date: 2007-05-10
      
-
      View other active issues in [refwrap.const].
      
-
      View all other issues in [refwrap.const].
      
+
      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:
      
 
      
-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.
+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);
+
      
 
-
      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.
+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:
+]
      
 
 
-
      
-
      691. const_local_iterator cbegin, cend missing from TR1
      
-
      Section: 23.4 [unord], TR1 6.3 [tr.hash] Status: Review
- Submitter: Joaquín M López Muñoz Date: 2007-06-14
      
-
      View other active issues in [unord].
      
-
      View all other issues in [unord].
      
-
      View all issues with Review status.
      
-
      Discussion:
      
+
      
 
      
-The last version of TR1 does not include the following member
-functions
-for unordered containers:
+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.
 
      
-
-
      const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;
-
      
-
 
      
-which looks like an oversight to me. I've checked th TR1 issues lists
-and the latest working draft of the C++0x std (N2284) and haven't
-found any mention to these menfuns or to their absence.
+Proposed Resolution: Accept Solution A.
 
      
+
      
+
 
      
-Is this really an oversight, or am I missing something?
+Issue 803 claims to make this issue moot.
 
      
 
 
 
 
      Proposed resolution:
      
+
        
+
      1. 
 
        
-Add the following two rows to table 93 (unordered associative container
-requirements) in section 23.1.3 [unord.req]:
+In 26.4.7.1 [rand.util.seedseq]/2, class seed_seq synopsis replace:
 
        
 
-
        
-
-
-
-
-
-
- 
-
-
- 
-
-
        Unordered associative container requirements (in addition to container)
        expression return type assertion/note pre/post-condition complexity
        b.cbegin(n) const_local_iterator n shall be in the range [0, bucket_count()). Note: [b.cbegin(n), b.cend(n)) is a valid range containing all of the elements in the nth bucket. Constant
        b.cend(n) const_local_iterator n shall be in the range [0, bucket_count()). Constant
        
-
        
+
        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);
+   ...
+};
+
        
 
 
        
-Add to the synopsis in 23.4.1 [unord.map]:
+and do a similar replacement in the member description between
+p.3 and p.4.
 
        
+
        2. 
 
-
        const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;
-
        
-
+
      2. 
 
        
-Add to the synopsis in 23.4.2 [unord.multimap]:
+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:
 
        
 
-
        const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;
+
        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);
 
        
 
 
        
-Add to the synopsis in 23.4.3 [unord.set]:
+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:
 
        
 
-
        const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;
+
        template<size_t u, class InputIterator>
+  seed_seq make_seed_seq(InputIterator begin, InputIterator end);
 
        
 
 
        
-Add to the synopsis in 23.4.4 [unord.multiset]:
+In 26.4.7.1 [rand.util.seedseq], just before p.5 insert two paragraphs:
 
        
 
-
        const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;
-
        
-
-
-
-
-
-
-
        
-
        692. get_money and put_money should be formatted I/O functions
        
-
        Section: 27.6.4 [ext.manip] Status: New
- Submitter: Martin Sebor Date: 2007-06-22
        
-
        View all other issues in [ext.manip].
        
-
        View all issues with New status.
        
-
        Discussion:
        
+
        
 
        
-In a private email Bill Plauger notes:
-
        
-
        
-I  believe that  the function  that  implements get_money
-[from N2072]
-should behave  as a  formatted input function,  and the  function that
-implements put_money should  behave as a formatted output
-function. This  has implications regarding the  skipping of whitespace
-and the handling of errors, among other things.
+The 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 words  don't say that  right now and  I'm far from  convinced that
-such a change is editorial.
-
        
-
        
-Martin's response:
-
        
-
        
-I agree that the manipulators should handle exceptions the same way as
-formatted I/O functions do. The text in N2072 assumes so but the
-Returns clause explicitly omits exception handling for the sake
-of brevity. The spec should be clarified to that effect.
+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.
 
        
-
        
-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.
-
        
+
        
 
+
        
+In 26.4.7.1 [rand.util.seedseq], just after the last paragraph add:
+
        
 
-
        Proposed resolution:
        
+
        
+
        template<size_t u, class InputIterator>
+   seed_seq make_seed_seq(InputIterator begin, InputIterator end);
+
        
+
        
 
        
-Add  a new  paragraph immediately  above  p4 of 27.6.4 [ext.manip] with  the
-following text:
+where u is used to construct an object s of implementation-defined type.
 
        
-
        
-Effects:  The   expression  in >> get_money(mon, intl)
-described below behaves as a formatted input function (as
-described in 27.6.1.2.1 [istream.formatted.reqmts]).
-
        
 
        
-Also change p4 of 27.6.4 [ext.manip] as follows:
+Returns: seed_seq(begin, end, s);
 
        
-
        
-Returns: An object s of unspecified type such that
-if in is  an object of type basic_istream<charT,
-traits>    then    the    expression   in >> get_money(mon, intl) behaves as a formatted input function
-that    calls    f(in, mon, intl)    were
-called. The function f can be defined as...
-
        
+
        
+
        
+
+
        3. 
+
      
+
 
 
 
 
 
 
      
-
      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].
      
+
      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  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).
+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.
 
      
 
-
-
      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:
+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.
 
      
 
-
      bool operator!=(const bitset<N>& rhs) const;
-bool test(size_t pos) const;
-bool all() const;
-bool any() const;
-bool none() const;
-
      
+
      [
+post Bellevue Peter adds:
+]
      
 
-
      
-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:
+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.
 
      
-
      
-bool any() const;
+
      
+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:
 
      
-
      
+
 
      
-Returns: true if any bit in *this
-is onecount() != 0.
+http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html
 
      
 
      
+
+
+
+
      Proposed resolution:
      
 
      
-bool none() const;
+Add a sentence to 30.2.1.1 [thread.thread.id]/p1:
 
      
+
 
      
 
      
-Returns: true if no bit in *this
-is onecount() == 0.
+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.
 
      
 
      
-
      
 
 
 
 
 
 
      
-
      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.
      
+
      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:
      
 
      
-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.
+Table 16 of TR1 requires that all Pseudo Random Number generators have a
 
      
 
+
      seed(integer-type s)
+
      
 
-
      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.)
+member function that is equivalent to:
 
      
-
      
-
      // [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);
-
      
-
      
+
+
      mygen = Generator(s)
+
      
+
 
      
-Make a corresponding change in 23.3.5.1 [bitset.cons], p2:
+But the generators xor_combine and discard_block have no such seed member, only the
 
      
-
      
+
+
      template <class Gen>
+seed(Gen&);
+
      
+
 
      
-bitset(unsigned long long val);
+member, which will not accept an integer literal as an argument: something that appears to violate the intent of Table 16.
 
      
-
      
-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:
+So... is this a bug in TR1?
 
      
-
      
-
      // 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:
+
+
      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:
      
 
      
-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.
      
+
      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   ctype<char>::classic_table()   static  member
-function    returns    a    pointer    to   an    array    of    const
-ctype_base::mask    objects    (enums)   that    contains
-ctype<char>::table_size    elements.    The   table
-describes the properties of the character set in the "C" locale (i.e.,
-whether a  character at an index  given by its value  is alpha, digit,
-punct,   etc.),   and   is    typically   used   to   initialize   the
-ctype<char>  facet in the  classic "C"  locale (the
-protected      ctype<char>      member     function
-table()    then    returns     the    same    value    as
-classic_table()).
+The draft 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.
+
        • 
+
      
+
 
      
-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.
+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.)
 
      
+
 
      
-The  same argument  can be  made for  the non-static  protected member
-function table().
+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.
+
        • 
+
      
 
-
      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:
+One possible minimal solution:
 
      
-
      
-
        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;
-
      
-
      
+
        
+
      • 
+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:
      
+
      
+
      
 
 
 
 
 
 
      
-
      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].
      
+
      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:
      
 
      
-From message c++std-lib-17897:
-
      
-
      
-The  code  shown  in  27.6.1.2.2 [istream.formatted.arithmetic] as  the  "as  if"
-implementation  of the  two arithmetic  extractors that  don't  have a
-corresponding     num_get     interface    (i.e.,     the
-short and int  overloads) is subtly buggy in
-how  it  deals  with  EOF, overflow,  and  other  similar
-conditions (in addition to containing a few typos).
+In 25.3.3.4 [binary.search]/3 the complexity of binary_search is described as
 
      
+
+
      
+At most log(last - first) + 2 comparisons.
+
      
+
 
      
-One  problem is  that if  num_get::get() reaches  the EOF
-after reading in  an otherwise valid value that  exceeds the limits of
-the    narrower    type     (but    not    LONG_MIN    or
-LONG_MAX),   it  will   set   err  to
-eofbit.   Because   of  the  if   condition  testing  for
-(err == 0),    the   extractor    won't   set
-failbit  (and presumably,  return  a bogus  value to  the
-caller).
+This should be precised and brought in line with the nomenclature used for
+lower_bound, upper_bound, and equal_range.
 
      
+
 
      
-Another  problem with  the code  is that  it never  actually  sets the
-argument to  the extracted  value. It can't  happen after the  call to
-setstate() since  the function may  throw, so we  need to
-show when  and how it's done (we  can't just punt as  say: "it happens
-afterwards"). However, it  turns out that showing how  it's done isn't
-quite so  easy since  the argument is  normally left unchanged  by the
-facet on error  except when the error is due  to a misplaced thousands
-separator,  which causes  failbit to  be set  but doesn't
-prevent the facet from storing the value.
+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.
+
      
+
 
 
 
 
 
      
-
      697. New <system_error> header leads to name clashes
      
-
      Section: 19.4 [syserr] Status: New
- Submitter: Daniel Krügler Date: 2007-06-24
      
+
      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 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:
+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:
 
      
 
-
      #include <system_error>
-#include <stdexcept>
-
-void foo() { throw std::invalid_argument("Don't call us - we call you!"); }
-
      
+
      
+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.
+
      
 
 
      
-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).
+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).
 
      
 
 
      
-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?
+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.
+
      
 
 
 
 
 
 
      
-
      698. Some system_error issues
      
-
      Section: 19.4.5.1 [syserr.syserr.overview] Status: New
- Submitter: Daniel Krügler Date: 2007-06-24
      
-
      View all issues with New status.
      
+
      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:
      
 
      
-In 19.4.5.1 [syserr.syserr.overview] we have the class definition of
-std::system_error. In contrast to all exception classes, which
-are constructible with a what_arg string (see 19.1 [std.exceptions],
-or ios_base::failure in 27.4.2.1.1 [ios::failure]), only overloads with with
-const string& are possible. For consistency with the re-designed
-remaining exception classes this class should also provide
-c'tors which accept a const char* what_arg string.
-
      
-
      
-Please note that this proposed addition makes sense even
-considering the given implementation hint for what(), because
-what_arg is required to be set as what_arg of the base class
-runtime_error, which now has the additional c'tor overload
-accepting a const char*.
+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.
 
      
 
 
@@ -11706,407 +15628,367 @@ accepting a const char*.
 
 
 
      
-
      700. N1856 defines struct identity
      
-
      Section: 20.2.2 [forward] Status: Ready
- Submitter: P.J. Plauger Date: 2007-07-01
      
+
      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:
      
 
      
-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.
+piecewise_constant_distribution is undefined for a range with just one
+endpoint. (Probably should be the same as an empty range.)
 
      
 
 
 
      Proposed resolution:
      
 
      
-Change 20.2.2 [forward]:
+Change 26.4.8.5.2 [rand.dist.samp.pconst] paragraph 3b:
 
      
 
 
      
-
      template <class T> struct identity
-{
-    typedef T type;
-    const T& operator()(const T& x) const;
-};
-
      
-
      
-
      const T& operator()(const T& x) const;
-
      
-
      
-
      
-Returns: x.
-
      
-
      
-
      
-
+b) If firstB == lastB or the sequence w has the length zero,
 
      
 
 
 
 
 
-
 
      
-
      701. assoc laguerre poly's
      
-
      Section: TR1 5.2.1.1 [tr.num.sf.Lnm] Status: New
- Submitter: Christopher Crawford Date: 2007-06-30
      
-
      View all issues with New status.
      
+
      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:
      
 
      
-I see that the definition the associated Laguerre
-polynomials TR1 5.2.1.1 [tr.num.sf.Lnm] has been corrected since
-N1687.
-However, the draft standard only specifies ranks of integer value m,
-while the associated Laguerre polynomials are actually valid for real
-values of m > -1.  In the case of non-integer values of m, the
-definition  Ln(m) = (1/n!)exx-m (d/dx)n (e-xxm+n)
-must be used, which also holds for integer values of m.  See
-Abramowitz & Stegun, 22.11.6 for the general case, and 22.5.16-17 for
-the integer case.  In fact fractional values are most commonly used in
-physics, for example to m = +/- 1/2 to describe the harmonic
-oscillator in 1 dimension, and 1/2, 3/2, 5/2, ... in 3
-dimensions.
+discrete_distribution should have a constructor like:
 
      
+
+
      template<class _Fn>
+  discrete_distribution(result_type _Count, double _Low, double _High,
+                        _Fn& _Func);
+
      
+
 
      
-If I am correct, the calculation of the more general case is no
-more difficult, and is in fact the function implemented in the GNU
-Scientific Library.  I would urge you to consider upgrading the 
-standard, either adding extra functions for real m or switching the
-current ones to double.
+(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:
      
-
      
-
      
 
 
 
 
 
 
      
-
      702. Restriction in associated Legendre functions
      
-
      Section: TR1 5.2.1.2 [tr.num.sf.Plm] Status: New
- Submitter: Christopher Crawford Date: 2007-06-30
      
+
      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:
      
 
      
-One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should  be
-|x| <= 1, not x >= 0.
      
+piecewise_constant_distribution should have a constructor like:
+
      
 
+
      template<class _Fn>
+   piecewise_constant_distribution(size_t _Count,
+            _Ty _Low, _Ty _High, _Fn& _Func);
+
      
 
-
      Proposed resolution:
      
 
      
+(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:
      
+
+
 
 
 
 
      
-
      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].
      
+
      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:
      
 
      
-map::at() need a complexity specification.
+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:
      
 
      
-Add the following to the specification of map::at(), 23.3.1.2 [map.access]:
+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; 
+};
+
      
+
 
      
 
      
-Complexity: logarithmic.
+-1- The constructor initializes fn op with x and value with y.
 
      
-
      
-
-
-
-
-
-
      
-
      704. MoveAssignable requirement for container value type overly strict
      
-
      Section: 23.1 [container.requirements] Status: Open
- Submitter: Howard Hinnant Date: 2007-05-20
      
-
      View other active issues in [container.requirements].
      
-
      View all other issues in [container.requirements].
      
-
      View all issues with Open status.
      
-
      Discussion:
      
 
      
-The move-related changes inadvertently overwrote the intent of 276.
-Issue 276 removed the requirement of CopyAssignable from
-most of the member functions of node-based containers.  But the move-related changes
-unnecessarily introduced the MoveAssignable requirement for those members which used to
-require CopyAssignable.
+-2- operator() returns fnop(value,x).
 
      
+
      
+
      
 
 
      
-We also discussed (c++std-lib-18722) the possibility of dropping MoveAssignable
-from some of the sequence requirements.  Additionally the in-place construction
-work may further reduce requirements.  For purposes of an easy reference, here are the
-minimum sequence requirements as I currently understand them.  Those items in requirements
-table in the working draft which do not appear below have been purposefully omitted for
-brevity as they do not have any requirements of this nature.  Some items which do not
-have any requirements of this nature are included below just to confirm that they were
-not omitted by mistake.
+Change D.8.3 [depr.lib.binder.2nd]:
 
      
 
-
-
-
-
-
-
-
-
      Container Requirements
      X u(a)value_type must be CopyConstructible
      X u(rv)array requires value_type to be MoveConstructible
      a = uSequences require value_type to be CopyConstructible and CopyAssignable.
-                               Associative containers require value_type to be CopyConstructible.
      a = rvarray requires value_type to be MoveAssignable.
-                                Sequences with non-Swappable allocators require value_type to be MoveConstructible and MoveAssignable.
-                                Associative containers with non-Swappable allocators require value_type to be MoveConstructible.
      swap(a,u)array requires value_type to be Swappable.
-                                Sequences with non-Swappable allocators require value_type to be Swappable, MoveConstructible and MoveAssignable.
-                                Associative containers with non-Swappable allocators require value_type to be MoveConstructible.
      
+
      
+
      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.
 
      
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
      Sequence Requirements
      X(n)value_type must be DefaultConstructible
      X(n, t)value_type must be CopyConstructible
      X(i, j)If the iterators return an lvalue the value_type must be CopyConstructible.
-                                 If the iterators return an rvalue the value_type must be MoveConstructible.
      a.insert(p, t)The value_type must be CopyConstructible.
-                                        The sequences vector and deque also require the value_type to be CopyAssignable.
      a.insert(p, rv)The value_type must be MoveConstructible.
-                                        The sequences vector and deque also require the value_type to be MoveAssignable.
      a.insert(p, n, t)The value_type must be CopyConstructible.
-                                        The sequences vector and deque also require the value_type to be CopyAssignable.
      a.insert(p, i, j)If the iterators return an lvalue the value_type must be CopyConstructible.
-                                        The sequences vector and deque also require the value_type to be CopyAssignable when the iterators return an lvalue.
-                                        If the iterators return an rvalue the value_type must be MoveConstructible.
-                                        The sequences vector and deque also require the value_type to be MoveAssignable when the iterators return an rvalue.
      a.erase(p)The sequences vector and deque require the value_type to be MoveAssignable.
      a.erase(q1, q2)The sequences vector and deque require the value_type to be MoveAssignable.
      a.clear()
      a.assign(i, j)If the iterators return an lvalue the value_type must be CopyConstructible and CopyAssignable.
-                                        If the iterators return an rvalue the value_type must be MoveConstructible and MoveAssignable.
      a.assign(n, t)The value_type must be CopyConstructible and CopyAssignable.
      a.resize(n)The value_type must be DefaultConstructible.
-                                     The sequences vector and deque also require the value_type to be MoveConstructible.
      a.resize(n, t)The value_type must be CopyConstructible.
      
-
 
      
+-2- operator() returns fnop(value,x).
 
      
+
      
+
      
 
-
-
-
-
-
-
-
-
-
-
-
-
-
      Optional Sequence Requirements
      a.front()
      a.back()
      a.push_front(t)The value_type must be CopyConstructible.
      a.push_front(rv)The value_type must be MoveConstructible.
      a.push_back(t)The value_type must be CopyConstructible.
      a.push_back(rv)The value_type must be MoveConstructible.
      a.pop_front()
      a.pop_back()
      a[n]
      a.at[n]
      
 
-
      
-
      
 
-
-
-
-
-
-
-
-
-
-
-
      Associative Container Requirements
      X(i, j)If the iterators return an lvalue the value_type must be CopyConstructible.
-                                 If the iterators return an rvalue the value_type must be MoveConstructible.
      a_uniq.insert(t)The value_type must be CopyConstructible.
      a_uniq.insert(rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
      a_eq.insert(t)The value_type must be CopyConstructible.
      a_eq.insert(rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
      a.insert(p, t)The value_type must be CopyConstructible.
      a.insert(p, rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
      a.insert(i, j)If the iterators return an lvalue the value_type must be CopyConstructible.
-                                        If the iterators return an rvalue the key_type and the mapped_type (if it exists) must be MoveConstructible..
      
 
+
+
+
      
+
      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.
 
      
 
-
-
-
-
-
-
-
-
-
-
-
      Unordered Associative Container Requirements
      X(i, j, n, hf, eq)If the iterators return an lvalue the value_type must be CopyConstructible.
-                                 If the iterators return an rvalue the value_type must be MoveConstructible.
      a_uniq.insert(t)The value_type must be CopyConstructible.
      a_uniq.insert(rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
      a_eq.insert(t)The value_type must be CopyConstructible.
      a_eq.insert(rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
      a.insert(p, t)The value_type must be CopyConstructible.
      a.insert(p, rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
      a.insert(i, j)If the iterators return an lvalue the value_type must be CopyConstructible.
-                                        If the iterators return an rvalue the key_type and the mapped_type (if it exists) must be MoveConstructible..
      
-
 
      
+There are two more minor issues:
 
      
 
-
-
-
-
-
      Miscellaneous Requirements
      map[lvalue-key]The key_type must be CopyConstructible.
-                                         The mapped_type must be DefaultConstructible and MoveConstructible.
      map[rvalue-key]The key_type must be MoveConstructible.
-                                         The mapped_type must be DefaultConstructible and MoveConstructible.
      
+
        
+
      • 
+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.
+
        • 
+
      
 
 
      [
-Kona (2007): Howard and Alan to update requirements table in issue with emplace signatures.
+Bellevue:
 ]
      
 
 
+
      
+Move to OPEN Bill will try to propose a resolution by the next meeting.
+
      
 
+
      [
+post Bellevue:  Bill provided wording.
+]
      
 
-
      Proposed resolution:
      
-
-
-
-
-
-
-
      
-
      705. type-trait decay incompletely specified
      
-
      Section: 20.4.7 [meta.trans.other] Status: Ready
- Submitter: Thorsten Ottosen Date: 2007-07-08
      
-
      View all issues with Ready status.
      
-
      Discussion:
      
-
      
-The current working draft has a type-trait decay in 20.4.7 [meta.trans.other].
-
      
 
 
      
-Its use is to turn C++03 pass-by-value parameters into efficient C++0x
-pass-by-rvalue-reference parameters. However, the current definition
-introduces an incompatible change where the cv-qualification of the
-parameter type is retained. The deduced type should loose such
-cv-qualification, as pass-by-value does.
+This issue is made moot if 803 is accepted.
 
      
 
 
-
      Proposed resolution:
      
-
      
-In 20.4.7 [meta.trans.other] change the last sentence:
-
      
-
-
      
-Otherwise the  member typedef type equals remove_cv<U>::type.
-
      
 
+
      Proposed resolution:
      
 
      
-In 20.3.1.2 [tuple.creation]/1 change:
+Replace 26.4.7.1 [rand.util.seedseq] paragraph 6 with:
 
      
 
-
      
-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.
-
      
+
      
+
      
+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;
+
      
+
      
 
 
 
 
 
 
      
-
      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.
      
+
      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:
      
 
      
-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.
+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.
 
      
-
-
-
      Proposed resolution:
      
 
      
-In 20.2 [utility] change the synopsis for make_pair() to read
+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
 
      
 
-
      template <class T1, class T2>
-  pair<typename decay<T1>::type V1, typename decay<T2>::type V2> make_pair(T1&&, T2&&);
+
      pair() = default;
 
      
 
 
      
-In 20.2.3 [pairs]/16 change the declaration to match the above synopsis.
-Then change the 20.2.3 [pairs]/17 to:
+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.
 
      
 
-
      
 
      
-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.
+** 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:
+]
      
 
-
      
-
      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:
+General agreement; the first half of the issue is NAD.
 
      
-
 
      
-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".
+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.
 
      
-
 
      
-Peter's response:
+Concensus: Go forward, but not at expense of other desired qualities.
 
      
-
 
      
-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.
+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:
      
@@ -12118,304 +16000,534 @@ to member, as in the unspecified bool type idiom.
 
 
 
      
-
      708. Locales need to be per thread and updated for POSIX changes
      
-
      Section: 22 [localization] Status: Open
- Submitter: Peter Dimov Date: 2007-07-28
      
-
      View all other issues in [localization].
      
+
      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:
      
 
      
-The POSIX "Extended API Set Part 4,"
+seed_seq(InputIterator begin, InputIterator end); constructs a seed_seq
+object repacking the bits of supplied sequence [begin, end) into a
+32-bit vector.
 
      
-
      
-http://www.opengroup.org/sib/details.tpl?id=C065
-
      
 
      
-introduces extensions to the C locale mechanism that
-allow multiple concurrent locales to be used in the same application
-by introducing a type locale_t that is very similar to
-std::locale, and a number of _l functions that make use of it.
+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. 
+
      
 
      
-The global locale (set by setlocale) is now specified to be per-
-process. If a thread does not call uselocale, the global locale is
-in effect for that thread. It can install a per-thread locale by
-using uselocale.
+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).
 
      
 
      
-There is also a nice querylocale mechanism by which one can obtain
-the name (such as "de_DE") for a specific facet, even for combined
-locales, with no std::locale equivalent.
+Here's how the description would read
 
      
+
      
 
      
-std::locale should be harmonized with the new POSIX locale_t
-mechanism and provide equivalents for uselocale and querylocale.
+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.
 
      
 
 
      [
-Kona (2007): Bill and Nick to provide wording.
+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);
+
      
+
      
+
      
+
      
 
 
 
 
 
 
      
-
      709. char_traits::not_eof has wrong signature
      
-
      Section: 21.1.3 [char.traits.specializations] Status: New
- Submitter: Bo Persson Date: 2007-08-13
      
+
      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. 
 
        
-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.
+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
+
        
 
        
-This doesn't work for type char, and is inconsistent with the 
-requirements in Table 56, Traits requirements, 21.1.1 [char.traits.require].
+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. 
+
        
 
        
-Pete adds:
+The simple fix would be to replace the reference by a pointer member.
 
        
+
        2. 
 
-
        
-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.
-
        
+
      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:
      
 
      
-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
+In 19.4.1.2 [syserr.errcat.virtuals], remove the throws clause p. 10.
 
      
 
-
      static constexpr int_type not_eof(char_type int_type c);
-
      
-
-
+
      
+
      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);
+
      
+
      
 
-
      
-
      710. Missing postconditions
      
-
      Section: 20.6.6.2 [util.smartptr.shared] Status: New
- Submitter: Peter Dimov Date: 2007-08-24
      
-
      View other active issues in [util.smartptr.shared].
      
-
      View all other issues in [util.smartptr.shared].
      
-
      View all issues with New status.
      
-
      Discussion:
      
 
      
-A discussion on
-comp.std.c++
-has identified a contradiction in the shared_ptr specification.
-The shared_ptr move constructor and the cast functions are
-missing postconditions for the get() accessor.
+In the private section of the same class replace the current
+data member cat_ definition by:
 
      
 
+
      
+const error_category&* cat_; // exposition only
+
      
 
-
      Proposed resolution:
      
 
      
-Add to 20.6.6.2.1 [util.smartptr.shared.const]:
+In 19.4.2.2 [syserr.errcode.constructors], change p. 2 to read:
 
      
 
 
      
-
      shared_ptr(shared_ptr&& r);
-template<class Y> shared_ptr(shared_ptr<Y>&& r);
+
      error_code();
 
      
 
      
 
      
-Postconditions:  *this shall contain the old value of r. r
-shall be empty. r.get() == 0.
+
      ...
      
+
+
      
+Postconditions: val_ == 0 and cat_ == &system_category.
 
      
 
      
 
      
 
 
      
-Add to 20.6.6.2.10 [util.smartptr.shared.cast]:
+Change 19.4.2.2 [syserr.errcode.constructors] p. 5 to read:
 
      
 
 
      
-
      template<class T, class U> shared_ptr<T> static_pointer_cast(shared_ptr<U> const& r);
+
      error_code(int val, const error_category& cat);
 
      
 
      
+
      ...
      
 
      
-Postconditions: If w is the return value,
-w.get() == static_cast<T*>(r.get()) && w.use_count() == r.use_count().
+Postconditions: val_ == val and cat_ == &cat.
 
      
 
      
 
      
 
-
      
-
      template<class T, class U> shared_ptr<T> dynamic_pointer_cast(shared_ptr<U> const& r);
-
      
-
      
 
      
-Postconditions: If w is the return value, w.get() == dynamic_cast<T*>(r.get()).
+In 19.4.2.3 [syserr.errcode.modifiers], change p. 1 to read:
 
      
-
      
-
      
 
 
      
-
      template<class T, class U> shared_ptr<T> const_pointer_cast(shared_ptr<U> const& r);
+
      void assign(int val, const error_category& cat);
 
      
 
      
 
      
-Postconditions: If w is the return value,
-w.get() == const_cast<T*>(r.get()) && w.use_count() == r.use_count().
+
      ...
      
+
+
      
+Postconditions: val_ == val and cat_ == &cat.
 
      
 
      
 
      
 
 
      
-Alberto Ganesh Barbati has written an
-alternative proposal
-where he suggests (among other things) that the casts be respecified in terms of
-the aliasing constructor as follows:
+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);
+
      
+
      
+
 
      
-Change 20.6.6.2.10 [util.smartptr.shared.cast]:
+In 19.4.2.4 [syserr.errcode.observers], change p. 3 to read:
 
      
 
+
      
+
      const error_category& category() const;
+
      
 
      
 
      
--2- Returns: If r is empty, an empty
-shared_ptr<T>; otherwise, a shared_ptr<T>
-object that stores static_cast<T*>(r.get()) and shares ownership with
-r. shared_ptr<T>(r, static_cast<T*>(r.get()).
+
      ...
      
+
+
      
+Returns: *cat_.
 
      
 
      
+
      
 
-
      
 
      
--6- Returns:
+In 19.4.2.4 [syserr.errcode.observers], remove the throws clause p. 8.
 
      
-
        
-
      • When dynamic_cast<T*>(r.get()) returns a nonzero value,
-a shared_ptr<T> object that stores a copy 
-of it and shares ownership with r;
        • 
-
      • Otherwise, an empty shared_ptr<T> object.
        • 
-
      • If p = dynamic_cast<T*>(r.get()) is a non-null pointer, shared_ptr<T>(r, p);
        • 
-
      • Otherwise, shared_ptr<T>().
        • 
-
      
-
      
 
-
      
+
      
+
      string message() const;
+
      
+
      
+
      
+
      ...
      
+
 
      
--10- Returns: If r is empty, an empty
-shared_ptr<T>; otherwise, a shared_ptr<T>
-object that stores const_cast<T*>(r.get()) and shares ownership with
-r. shared_ptr<T>(r, const_cast<T*>(r.get()).
+Throws: Nothing.
 
      
 
      
+
      
 
 
      
-This takes care of the missing postconditions for the casts by bringing
-in the aliasing constructor postcondition "by reference".
+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
+
      
 
-
      
-
      711. Contradiction in empty shared_ptr
      
-
      Section: 20.6.6.2.5 [util.smartptr.shared.obs] Status: New
- Submitter: Peter Dimov Date: 2007-08-24
      
-
      View all other issues in [util.smartptr.shared.obs].
      
-
      View all issues with New status.
      
-
      Discussion:
      
 
      
-A discussion on
-comp.std.c++
-has identified a contradiction in the shared_ptr specification.
-The note:
+In 19.4.3.2 [syserr.errcondition.constructors], change p. 2 to read:
 
      
 
-
      
-[ Note: this constructor allows creation of an empty shared_ptr instance with a non-NULL stored pointer.
--end note ]
-
      
+
      
+
      error_condition();
+
      
+
      
+
      
+
      ...
      
 
 
      
-after the aliasing constructor
+Postconditions: val_ == 0 and cat_ == &posix_category.
 
      
+
      
+
      
 
-
      template<class Y> shared_ptr(shared_ptr<Y> const& r, T *p);
-
      
+
      
+In the same section, change p. 5 to read:
+
      
 
+
      
+
      error_condition(int val, const error_category& cat);
+
      
+
      
 
      
-reflects the intent of
-N2351
-to, well, allow the creation of an empty shared_ptr
-with a non-NULL stored pointer.
+
      ...
      
+
+
      
+Postconditions: val_ == val and cat_ == &cat.
 
      
+
      
+
      
 
 
      
-This is contradicted by the second sentence in the Returns clause of 20.6.6.2.5 [util.smartptr.shared.obs]:
+In 19.4.3.3 [syserr.errcondition.modifiers], change p. 1 to read:
 
      
 
 
      
-
      T* get() const;
+
      void assign(int val, const error_category& cat);
 
      
-
      
-Returns: the stored pointer. Returns a null pointer if *this is empty.
-
      
+
      
+
      
+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);
+
      
 
-
      Proposed resolution:
      
 
      
-In keeping the N2351 spirit and obviously my preference, change 20.6.6.2.5 [util.smartptr.shared.obs]:
+In 19.4.3.4 [syserr.errcondition.observers], change p. 3 to read:
 
      
 
 
      
-
      T* get() const;
+
      const error_category& category() const;
 
      
-
      
-Returns: the stored pointer. Returns a null pointer if *this is empty.
-
      
-
      
-
+
      
 
      
-Alternative proposed resolution: (I won't be happy if we do this, but it's possible):
+Returns: *cat_.
 
      
+
      
+
      
 
 
      
-Change 20.6.6.2.1 [util.smartptr.shared.const]:
+In 19.4.3.4 [syserr.errcondition.observers], remove the throws clause p. 6.
 
      
 
 
      
-
      template<class Y> shared_ptr(shared_ptr<Y> const& r, T *p);
+
      string message() const;
 
      
 
      
 
      
-Requires: If r is empty, p shall be 0.
-
      
+
      ...
      
+
 
      
-[ Note: this constructor allows creation of an empty shared_ptr
-instance with a non-NULL stored pointer. 
--- end note ]
+Throws: Nothing.
 
      
 
      
 
      
@@ -12425,249 +16537,338 @@ instance with a non-NULL stored pointer.
 
 
 
+
 
      
-
      713. sort() complexity is too lax
      
-
      Section: 25.3.1.1 [sort] Status: New
- Submitter: Matt Austern Date: 2007-08-30
      
+
      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:
      
 
      
-The complexity of sort() is specified as "Approximately N
-log(N) (where N == last - first ) comparisons on the
-average", with no worst case complicity specified. The intention was to
-allow a median-of-three quicksort implementation, which is usually O(N
-log N) but can be quadratic for pathological inputs. However, there is
-no longer any reason to allow implementers the freedom to have a
-worst-cast-quadratic sort algorithm. Implementers who want to use
-quicksort can use a variant like David Musser's "Introsort" (Software
-Practice and Experience 27:983-993, 1997), which is guaranteed to be O(N
-log N) in the worst case without incurring additional overhead in the
-average case. Most C++ library implementers already do this, and there
-is no reason not to guarantee it in the standard.
+19.4 [syserr]
 
      
 
+
      namespace posix_error {
+  enum posix_errno {
+    address_family_not_supported, // EAFNOSUPPORT
+    ...
+
      
 
-
      Proposed resolution:
      
 
      
-In 25.3.1.1 [sort], change the complexity to "O(N log N)", and remove footnote 266:
+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:
+]
      
+
+
 
      
 
      
-Complexity: Approximately O(N log(N)) (where N == last - first )
-comparisons on the average.266)
+See N2347,
+Strongly Typed Enums, since renamed Scoped Enums.
 
      
 
      
-266)
-If the worst case behavior is important stable_sort() (25.3.1.2) or partial_sort()
-(25.3.1.3) should be used.
+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
+
      
 
-
      
-
      714. search_n complexity is too lax
      
-
      Section: 25.1.9 [alg.search] Status: New
- Submitter: Matt Austern Date: 2007-08-30
      
-
      View all other issues in [alg.search].
      
-
      View all issues with New status.
      
-
      Discussion:
      
 
      
-The complexity for search_n (25.1.9 [alg.search] par 7) is specified as "At most
-(last - first ) * count applications of the corresponding predicate if
-count is positive, or 0 otherwise." This is unnecessarily pessimistic.
-Regardless of the value of count, there is no reason to examine any
-element in the range more than once.
+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.
+
      
 
-
      Proposed resolution:
      
 
      
-Change the complexity to "At most (last - first) applications of the corresponding predicate".
+Change System error support 19.4 [syserr] and its subsections:
 
      
 
 
      
-
      template<class ForwardIterator, class Size, class T> 
-  ForwardIterator 
-    search_n(ForwardIterator first , ForwardIterator last , Size count , 
-             const T& value ); 
+
        
+
      • 
+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
+
        • 
+
      
+
      
 
-template<class ForwardIterator, class Size, class T, 
-         class BinaryPredicate> 
-  ForwardIterator 
-    search_n(ForwardIterator first , ForwardIterator last , Size count , 
-             const T& value , BinaryPredicate pred );
-
      
-
      
 
      
-Complexity: At most (last - first ) * count applications of the corresponding predicate
-if count is positive, or 0 otherwise.
+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".
+
      
 
-
      
-
      715. minmax_element complexity is too lax
      
-
      Section: 25.3.7 [alg.min.max] Status: New
- Submitter: Matt Austern Date: 2007-08-30
      
-
      View all other issues in [alg.min.max].
      
-
      View all issues with New status.
      
-
      Discussion:
      
 
      
-The complexity for minmax_element (25.3.7 [alg.min.max] par 16) says "At most max(2 *
-(last - first ) - 2, 0) applications of the corresponding comparisons",
-i.e. the worst case complexity is no better than calling min_element and
-max_element separately. This is gratuitously inefficient. There is a
-well known technique that does better: see section 9.1 of CLRS
-(Introduction to Algorithms, by Cormen, Leiserson, Rivest, and Stein).
+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).
+
      
+
      
 
-
      Proposed resolution:
      
 
      
-Change 25.3.7 [alg.min.max] to:
+Change 19.4.3.5 [syserr.errcondition.nonmembers] Class error_condition non-member functions as indicated:
 
      
 
 
      
-
      template<class ForwardIterator> 
-  pair<ForwardIterator, ForwardIterator> 
-    minmax_element(ForwardIterator first , ForwardIterator last); 
-template<class ForwardIterator, class Compare> 
-  pair<ForwardIterator, ForwardIterator> 
-    minmax_element(ForwardIterator first , ForwardIterator last , Compare comp);
+
      error_condition make_error_condition(posix_errno errc e);
 
      
+
 
      
-
      
-Returns: make_pair(m, M), where m is
-min_element(first, last) or min_element(first, last,
-comp) the first iterator i in [first,
-last) such that no other element in the range is smaller, and
-where M is max_element(first, last) or
-max_element(first, last, comp) the last iterator
-i in [first, last) such that no other element in the
-range is larger.
-
      
-
      
-Complexity: At most max(2 * (last - first ) - 2, 0)
-max(⌊(3/2) (N-1)⌋, 0) applications of the
-corresponding comparisons predicate, where N is distance(first, last).
-
      
+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.
+
      
+
+
 
 
 
 
      
-
      716. Production in [re.grammar] not actually modified
      
-
      Section: 28.13 [re.grammar] Status: New
- Submitter: Stephan T. Lavavej Date: 2007-08-31
      
+
      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:
      
 
      
-TR1 7.13 [tr.re.grammar]/3 and C++0x WP 28.13 [re.grammar]/3 say:
+void unique_ptr::reset(T* p = 0) is currently specified as:
 
      
 
 
      
-
      
-The following productions within the ECMAScript grammar are modified as follows:
-
      
-
-
      CharacterClass ::
-[ [lookahead ∉ {^}] ClassRanges ]
-[ ^ ClassRanges ]
-
      
-
+Effects: If p == get() there are no effects. Otherwise get_deleter()(get()).
 
      
 
 
      
-This definition for CharacterClass appears to be exactly identical to that in ECMA-262.
+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.)
 
      
 
 
      
-Was an actual modification intended here and accidentally omitted, or was this production accidentally included?
+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.
 
      
 
-
-
      Proposed resolution:
      
 
      
-Remove this mention of the CharacterClass production.
+One might think that self-resets are necessary for operator= to work; it's specified to perform
 
      
 
-
      CharacterClass ::
-[ [lookahead ∉ {^}] ClassRanges ]
-[ ^ ClassRanges ]
+
      reset( u.release() );
 
      
 
+
      
+and the self-assignment
+
      
 
+
      p = move(p);
+
      
 
-
-
-
-
      
-
      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.
+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 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.
+Change 20.6.11.2.5 [unique.ptr.single.modifiers]:
 
      
 
-
      
--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.
-
      
+
      
+
      void reset(T* p = 0);
+
      
+
      
+-4- Effects: If p == get() == 0 there are no effects. Otherwise get_deleter()(get()).
+
      
+
      
 
 
      
--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)
+Change 20.6.11.3.3 [unique.ptr.runtime.modifiers]:
 
      
 
+
      
+
      void reset(T* p = 0);
+
      
+
      
+
      ...
      
 
      
--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.
+-2- Effects: If p == get() == 0 there are no effects. Otherwise get_deleter()(get()).
 
      
-
+
      
 
      
 
 
@@ -12676,161 +16877,108 @@ of that array ends, whichever happens first.
 
 
 
      
-
      718. basic_string is not a sequence
      
-
      Section: 21.3 [basic.string] Status: New
- Submitter: Bo Persson Date: 2007-08-18
      
-
      View other active issues in [basic.string].
      
-
      View all other issues in [basic.string].
      
+
      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:
      
 
      
-Paragraph 21.3 [basic.string]/3 states:
+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.
 
      
 
-
      
-
      
-The class template basic_string conforms to the requirements for a 
-Sequence (23.1.1) and for a Reversible Container (23.1).
-
      
-
      
 
+
      Proposed resolution:
      
 
      
-First of all, 23.1.1 [sequence.reqmts] is no longer "Sequence" but "Sequence container". 
-Secondly, after the resent changes to containers (emplace, push_back, 
-const_iterator parameters to insert and erase), basic_string is not 
-even close to conform to the current requirements.
+Add to 20.3.1.2 [tuple.cnstr]:
 
      
 
-
-
      Proposed resolution:
      
+
      
 
      
-Remove this sentence, in recognition of the fact that basic_string is 
-not just a vector-light for literal types, but something quite 
-different, a string abstraction in its own right.
+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.
 
      
+
      
 
 
 
 
 
 
      
-
      719. std::is_literal type traits should be provided
      
-
      Section: 20.4 [meta] Status: New
- Submitter: Daniel Krügler Date: 2007-08-25
      
-
      View all other issues in [meta].
      
+
      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:
      
 
      
-Since the inclusion of constexpr in the standard draft N2369 we have
-a new type category "literal", which is defined in 3.9 [basic.types]/p.11:
+p4 (forward) says:
 
      
-
 
      
-
      
--11- A type is a literal type if it is:
-
      
-
        
-
      • a scalar type; or
        • 
-
      • a class type (clause 9) with
        
-
          
-
        • a trivial copy constructor,
          • 
-
        • a trivial destructor,
          • 
-
        • at least one constexpr constructor other than the copy constructor,
          • 
-
        • no virtual base classes, and
          • 
-
        • all non-static data members and base classes of literal types; or
          • 
-
        
-
        • 
-
      • an array of literal type.
        • 
-
      
+Return type: If T is an lvalue-reference type, an lvalue; otherwise, an rvalue.
 
      
 
 
      
-I strongly suggest that the standard provides a type traits for
-literal types in 20.4.4.3 [meta.unary.prop] for several reasons:
+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.)
 
      
-
-
        
-
      1. To keep the traits in sync with existing types.
        2. 
-
      2. I see many reasons for programmers to use this trait in template
-   code to provide optimized template definitions for these types,
-   see below.
        3. 
-
      3. A user-provided definition of this trait is practically impossible
-to write portably.
        4. 
-
      
-
 
      
-The special problem of reason (c) is that I don't see currently a
-way to portably test the condition for literal class types:
+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:
 
      
-
 
      
-
        
-
      • at least one constexpr constructor other than the copy constructor,
        • 
-
      
+Return type: an rvalue.
 
      
-
 
      
-Here follows a simply example to demonstrate it's usefulness:
+is just wrong and also redundant.
 
      
 
-
      template <typename T>
-constexpr typename std::enable_if<std::is_literal<T>::value, T>::type
-abs(T x) {
-  return x < T() ? -x : x;
-}
-
-template <typename T>
-typename std::enable_if<!std::is_literal<T>::value, T>::type
-abs(const T& x) {
-  return x < T() ? -x : x;
-}
-
      
 
+
      Proposed resolution:
      
 
      
-Here we have the possibility to provide a general abs function
-template that can be used in ICE's if it's argument is a literal
-type which's value is a constant expression, otherwise we
-have an optimized version for arguments which are expensive
-to copy and therefore need the usage of arguments of
-reference type (instead of const T& we could decide to
-use T&&, but that is another issue).
+Change 20.2.2 [forward] as indicated:
 
      
 
+
      
+
      template <class T> T&& forward(typename identity<T>::type&& t);
+
      
 
-
-
      Proposed resolution:
      
+
      
+
      ...
      
 
      
-In 20.4.2 [meta.type.synop] in the group "type properties",
-just below the line
+Return type: If T is an lvalue-reference type, an lvalue; otherwise, an rvalue.
 
      
-
-
      template <class T> struct is_pod;
-
      
-
+
      ...
      
 
      
-add a new one:
+-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> struct is_literal;
-
      
+
      template <class T> typename remove_reference<T>::type&& move(T&& t);
+
      
 
+
      
+
      ...
      
 
      
-In 20.4.4.3 [meta.unary.prop], table Type Property Predicates, just
-below the line for the is_pod property add a new line:
+Return type:  an rvalue.
 
      
+
      
 
-
-
-
-
-
-
-
-
-
-
      TemplateConditionPreconditions
      template <class T> struct is_literal;T is a literal type (3.9)T shall be a complete type, an
-array of unknown bound, or
-(possibly cv-qualified) void.
      
+
      
 
 
 
@@ -12838,512 +16986,476 @@ array of unknown bound, or
 
 
 
      
-
      720. Omissions in constexpr usages
      
-
      Section: 23.2.1 [array], 23.3.5 [template.bitset] Status: New
- Submitter: Daniel Krügler Date: 2007-08-25
      
-
      View other active issues in [array].
      
-
      View all other issues in [array].
      
+
      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:
      
-
        
-
      1. 
-The member function bool array<T,N>::empty() const should be a
-constexpr because this is easily to proof and to implement following it's operational
-semantics defined by Table 87 (Container requirements) which says: a.size() == 0.
-
        2. 
-
      2. 
-The member function bool bitset<N>::test() const must be a
-constexpr (otherwise it would violate the specification of constexpr
-bitset<N>::operator[](size_t) const, because it's return clause delegates to test()).
-
        3. 
-
      3. 
-I wonder how the constructor bitset<N>::bitset(unsigned long) can
-be declared as a constexpr. Current implementations usually have no such bitset
-c'tor which would fulfill the requirements of a constexpr c'tor because they have a
-non-empty c'tor body that typically contains for-loops or memcpy to compute the
-initialisation. What have I overlooked here?
-
        4. 
-
      
-
-
-
      Proposed resolution:
      
-
        
-
      1. 
-
        In the class template definition of 23.2.1 [array]/p. 3 change
        
-
        constexpr bool empty() const;
-
        
-
        2. 
-
-
      2. 
-
        In the class template definition of 23.3.5 [template.bitset]/p. 1 change
        
-
        constexpr bool test(size_t pos ) const;
-
        
-
 
        
-and in 23.3.5.2 [bitset.members] change
-
        
-
-
        constexpr bool test(size_t pos ) const;
-
        
-
-
        3. 
-
      
+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.
 
 
-
      
-
      721. wstring_convert inconsistensies
      
-
      Section: 22.1.3.2.2 [conversions.string] Status: New
- Submitter: Bo Persson Date: 2007-08-27
      
-
      View all issues with New status.
      
-
      Discussion:
      
 
      
-Paragraph 3 says that the Codecvt template parameter shall meet the 
-requirements of std::codecvt, even though std::codecvt itself cannot 
-be used (because of a protected destructor).
+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.
 
      
 
 
      
-How are we going to explain this code to beginning programmers?
+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?
 
      
 
-
      template<class I, class E, class S>
-struct codecvt : std::codecvt<I, E, S>
-{
-    ~codecvt()
-    { }
-};
-
-void main()
-{
-    std::wstring_convert<codecvt<wchar_t, char, std::mbstate_t> > compiles_ok;
-    
-    std::wstring_convert<std::codecvt<wchar_t, char, std::mbstate_t> >   not_ok;
-}
-
      
-
-
 
 
      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);
+
      
+
      
 
 
 
 
 
 
      
-
      722. Missing [c.math] functions nanf and nanl
      
-
      Section: 26.7 [c.math] Status: New
- Submitter: Daniel Krügler Date: 2007-08-27
      
-
      View other active issues in [c.math].
      
-
      View all other issues in [c.math].
      
+
      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:
      
 
      
-In the listing of 26.7 [c.math], table 108: Header <cmath> synopsis I miss
-the following C99 functions (from 7.12.11.2):
+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
 
      
 
-
      float nanf(const char *tagp);
-long double nanl(const char *tagp);
+
      istreambuf_iterator<charT>
 
      
 
 
      
-(Note: These functions cannot be overloaded and they are also not
-listed anywhere else)
+and
 
      
 
+
      ostreambuf_iterator<charT>
+
      
 
-
      Proposed resolution:
      
 
      
-In 26.7 [c.math], table 108, section "Functions", add nanf and nanl
-just after the existing entry nan.
+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.
 
      
-
-
-
-
-
-
      
-
      723. basic_regex should be moveable
      
-
      Section: 28.8 [re.regex] Status: New
- Submitter: Daniel Krügler Date: 2007-08-29
      
-
      View all other issues in [re.regex].
      
-
      View all issues with New status.
      
-
      Discussion:
      
 
      
-According to the current state of the standard draft, the class
-template basic_regex, as described in 28.8 [re.regex]/3, is
-neither MoveConstructible nor MoveAssignable.
-IMO it should be, because typical regex state machines tend
-to have a rather large data quantum and I have seen several
-use cases, where a factory function returns regex values,
-which would take advantage of moveabilities.
+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:
      
-
        
-
      1. 
 
        
-In the header <regex> synopsis 28.4 [re.syn], just below the function
-template swap add two further overloads:
+In 27.6.4 [ext.manip]/3 within function f replace the first line
 
        
-
        template <class charT, class traits> 
-  void swap(basic_regex<charT, traits>& e1,  basic_regex<charT, traits>& e2);
-template <class charT, class traits>
-  void swap(basic_regex<charT, traits>&& e1, basic_regex<charT, traits>& e2);
-template <class charT, class traits>
-  void swap(basic_regex<charT, traits>& e1,  basic_regex<charT, traits>&& e2);
+
+
        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 the class definition of basic_regex, just below 28.8 [re.regex]/3,
-perform the following changes:
+In 27.6.4 [ext.manip]/4 remove the first template charT parameter:
 
        
-
        2. 
 
-
      2. 
-
        Just after the copy c'tor:
        
-
        basic_regex(basic_regex&&);
+
        template <class charT, class moneyT> unspecified put_money(const moneyT& mon, bool intl = false);
 
        
-
        3. 
 
-
      3. 
-
        Just after the copy-assignment op.:
        
-
        basic_regex& operator=(basic_regex&&);
-
        
-
        4. 
+
        
+In 27.6.4 [ext.manip]/5 within function f replace the first line
+
        
 
-
      4. 
-
        Just after the first assign overload insert:
        
-
        basic_regex& assign(basic_regex&& that);
+
        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;
+  ...
 
        
-
        5. 
 
-
      5. 
-
        Change the current swap function to read:
        
-
        void swap(basic_regex&&);
-
        
-
        6. 
+
        
+In 27.6.4 [ext.manip]/7 within function f replace the first line
+
        
 
-
      6. 
-
        In 28.8.2 [re.regex.construct], just below the copy c'tor add a
-corresponding member definition of:
        
-
        basic_regex(basic_regex&&);
+
        template <class charT, class traits> 
+void f(basic_ios<charT, traits>& str, struct tm *tmb, const charT *fmt) { 
+  typedef istreambuf_iterator<charT, traits> Iter;
+  ...
 
        
-
        7. 
 
-
      7. 
-
        Also in 28.8.2 [re.regex.construct], just below the copy assignment
-c'tor add a corresponding member definition of:
        
-
        basic_regex& operator=(basic_regex&&);
-
        
-
        8. 
+
        
+In 27.6.4 [ext.manip]/8 add const:
+
        
 
-
      8. 
-
        In 28.8.3 [re.regex.assign], just below the first assign overload add
-a corresponding member definition of:
        
-
        basic_regex& assign(basic_regex&& that);
+
        template <class charT> unspecified put_time(const struct tm *tmb, const charT *fmt);
 
        
-
        9. 
 
-
      9. 
-
        In 28.8.6 [re.regex.swap], change the signature of swap to
-say:
        
-
        void swap(basic_regex&& e);
-
        
-
        10. 
+
        
+In 27.6.4 [ext.manip]/9 within function f replace the first line
+
        
 
-
      10. 
-
        In 28.8.7.1 [re.regex.nmswap], just below the single binary swap
-function, add the two missing overloads:
        
-
        template <class charT, class traits>
-  void swap(basic_regex<charT, traits>&& e1, basic_regex<charT, traits>& e2);
-template <class charT, class traits>
-  void swap(basic_regex<charT, traits>& e1, basic_regex<charT, traits>&& e2);
+
        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;
+  ...
 
        
-
        11. 
-
      
 
 
      
-Of course there would be need of corresponding proper standardese
-to describe these additions.
+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);
+
      
+
 
 
 
 
 
 
      
-
      724. DefaultConstructible is not defined
      
-
      Section: 20.1.1 [utility.arg.requirements] Status: New
- Submitter: Pablo Halpern Date: 2007-09-12
      
-
      View other active issues in [utility.arg.requirements].
      
-
      View all other issues in [utility.arg.requirements].
      
+
      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);
+}
+
      
+
 
      
-The DefaultConstructible requirement is referenced in
-several places in the August 2007 working draft
-N2369,
-but is not defined anywhere.
+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);
+
      
 
-
      Proposed resolution:
      
 
      
-In section 20.1.1 [utility.arg.requirements], before table 33, add the
-following table:
+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):
 
      
 
-
      Table 33: DefaultConstructible requirements
      
-
-
      
+
      template<class U , class V >
+requires Constructible<T1, U&&> && Constructible<T2, V&&>
+pair(U&& x , V&& y );
+
      
 
-
- 
-  
-  
- 
- 
-  
-  
- 
-
      
-  
      expression
      
-        		
-  
      post-condition
      
-  
      
-  
      T
-  t;
      
-  T()
      
-        		
-  
      T
-  is default constructed.
      
-  
      
 
-
      
 
+
      Proposed resolution:
      
+
      
+
      
 
 
 
 
 
 
      
-
      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].
      
+
      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:
      
 
      
-Table 90: (Optional sequence container operations) states the
-"assertion note pre/post-condition" of operator[] to be
+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.
 
      
-
-
      *(a.begin() + n)
-
      
-
 
      
-Surely that's meant to be "operational semantics?"
+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:
      
-
      
-
-
-
-
-
-
      Table 90: Optional sequence container operations
      expression return type assertion/note
      pre/post-condition
       operational semantics      		 container
      
-
      
 
+
      Proposed resolution:
      
+
      
+
      
 
 
 
 
 
 
      
-
      726. Missing regex_replace() overloads
      
-
      Section: 28.11.4 [re.alg.replace] Status: New
- Submitter: Stephan T. Lavavej Date: 2007-09-22
      
-
      View other active issues in [re.alg.replace].
      
-
      View all other issues in [re.alg.replace].
      
+
      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:
      
 
      
-Two overloads of regex_replace() are currently provided:
+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.
 
-
      template <class OutputIterator, class BidirectionalIterator, 
-    class traits, class charT> 
-  OutputIterator 
-  regex_replace(OutputIterator out, 
-                BidirectionalIterator first, BidirectionalIterator last, 
-                const basic_regex<charT, traits>& e, 
-                const basic_string<charT>& fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);
- 
-template <class traits, class charT> 
-  basic_string<charT> 
-  regex_replace(const basic_string<charT>& s, 
-                const basic_regex<charT, traits>& e, 
-                const basic_string<charT>& fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);
-
      
 
-
        
-
      1. Overloads taking const charT * are provided for regex_match() and
-regex_search(), but not regex_replace().  This is inconsistent.
        2. 
+
        [
+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.
+
          
+
          • 
+
 
        • 
-
          The absence of const charT * overloads prevents ordinary-looking code from compiling, such as:
          
-
-
          const string s("kitten");
-const regex r("en");
-cout << regex_replace(s, r, "y") << endl;
+
          
+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);
 
          
-
 
          
-The compiler error message will be something like "could not deduce
-template argument for 'const std::basic_string<_Elem> &' from 'const
-char[1]'".
+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.
 
          
 
 
          
-Users expect that anything taking a basic_string<charT> can also take a
-const charT *.  In their own code, when they write a function taking
-std::string (or std::wstring), they can pass a const char * (or const
-wchar_t *), thanks to basic_string's implicit constructor.  Because the
-regex algorithms are templated on charT, they can't rely on
-basic_string's implicit constructor (as the compiler error message
-indicates, template argument deduction fails first).
+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.
 
          
 
 
          
-If a user figures out what the compiler error message means, workarounds
-are available - but they are all verbose.  Explicit template arguments
-could be given to regex_replace(), allowing basic_string's implicit
-constructor to be invoked - but charT is the last template argument, not
-the first, so this would be extremely verbose.  Therefore, constructing
-a basic_string from each C string is the simplest workaround.
+Green and red are "nowhere defined" and completely defined at the same time.
 
          
 
          • 
+
        
 
-
      2. 
-There is an efficiency consideration: constructing basic_strings can
-impose performance costs that could be avoided by a library
-implementation taking C strings and dealing with them directly. 
-(Currently, for replacement sources, C strings can be converted into
-iterator pairs at the cost of verbosity, but for format strings, there
-is no way to avoid constructing a basic_string.)
-
        3. 
-
      
-
+
      
+Alisdair's wording is fine.
+
      
+
      
 
 
 
      Proposed resolution:
      
 
      
-Provide additional overloads for regex_replace(): one additional
-overload of the iterator-based form (taking const charT* fmt), and three
-additional overloads of the convenience form (one taking const charT*
-str, another taking const charT* fmt, and the third taking both const
-charT* str and const charT* fmt).  28.11.4 [re.alg.replace]:
+Append the following sentance to 20.6.12.2 [util.smartptr.shared]
 
      
-
 
      
-
      template <class OutputIterator, class BidirectionalIterator, 
-    class traits, class charT> 
-  OutputIterator 
-  regex_replace(OutputIterator out, 
-                BidirectionalIterator first, BidirectionalIterator last, 
-                const basic_regex<charT, traits>& e, 
-                const basic_string<charT>& fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);
+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.
+
      
 
-template <class OutputIterator, class BidirectionalIterator, 
-    class traits, class charT> 
-  OutputIterator 
-  regex_replace(OutputIterator out, 
-                BidirectionalIterator first, BidirectionalIterator last, 
-                const basic_regex<charT, traits>& e, 
-                const charT* fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);
-
      
-
      ...
      
-
      template <class traits, class charT> 
-  basic_string<charT> 
-  regex_replace(const basic_string<charT>& s, 
-                const basic_regex<charT, traits>& e, 
-                const basic_string<charT>& fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);
 
-template <class traits, class charT> 
-  basic_string<charT> 
-  regex_replace(const basic_string<charT>& s, 
-                const basic_regex<charT, traits>& e, 
-                const charT* fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);
 
-template <class traits, class charT> 
-  basic_string<charT> 
-  regex_replace(const charT* s, 
-                const basic_regex<charT, traits>& e, 
-                const basic_string<charT>& fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);
 
-template <class traits, class charT> 
-  basic_string<charT> 
-  regex_replace(const charT* s, 
-                const basic_regex<charT, traits>& e, 
-                const charT* fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);
-
      
-
      
 
+
      
+
      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:
      
+
      
+
      
 
 
 
 
 
 
      
-
      727. regex_replace() doesn't accept basic_strings with custom traits and allocators
      
-
      Section: 28.11.4 [re.alg.replace] Status: New
- Submitter: Stephan T. Lavavej Date: 2007-09-22
      
-
      View other active issues in [re.alg.replace].
      
-
      View all other issues in [re.alg.replace].
      
+
      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:
      
 
      
-regex_match() and regex_search() take const basic_string<charT, ST,
-SA>&.  regex_replace() takes const basic_string<charT>&.  This prevents
-regex_replace() from accepting basic_strings with custom traits and
-allocators.
+std::function and reference_closure should use "perfect forwarding" as
+described in the rvalue core proposal.
 
      
 
 
 
      Proposed resolution:
      
 
      
-Overloads of regex_replace() taking basic_string should be additionally
-templated on class ST, class SA and take const basic_string<charT, ST,
-SA>&.  Consistency with regex_match() and regex_search() would place
-class ST, class SA as the first template arguments; compatibility with
-existing code using TR1 and giving explicit template arguments to
-regex_replace() would place class ST, class SA as the last template
-arguments.
 
      
 
 
@@ -13351,482 +17463,566 @@ arguments.
 
 
 
      
-
      728. Problem in [rand.eng.mers]/6
      
-
      Section: 26.4.3.2 [rand.eng.mers] Status: New
- Submitter: Stephan Tolksdorf Date: 2007-09-21
      
+
      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:
      
 
      
-The mersenne_twister_engine is required to use a seeding method that is given 
-as an algorithm parameterized over the number of bits W. I doubt whether the given generalization 
-of an algorithm that was originally developed only for unsigned 32-bit integers is appropriate 
-for other bit widths. For instance, W could be theoretically 16 and UIntType a 16-bit integer, in 
-which case the given multiplier would not fit into the UIntType. Moreover, T. Nishimura and M. 
-Matsumoto have chosen a dif ferent multiplier for their 64 bit Mersenne Twister
-[reference].
+Library Issue 527 notes that bind(f, t1, ..., tN)
+should be nofail when f, t1, ..., tN have nofail copy ctors.
 
      
-
 
      
-I see two possible resolutions: 
+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?
 
      
 
-
        
-
      1. Restrict the parameter W of the mersenne_twister_template to values of 32 or 64 and use the 
-multiplier from [the above reference] for the 64-bit case (my preference)
        2. 
-
      2. Interpret the state array for any W as a 32-bit array of appropriate length (and a specified byte 
-order) and always employ the 32-bit algorithm for seeding
-
        3. 
-
      
+
      [
+Howard adds:
+]
      
+
+
+
      
+tuple construction should probably have a similar guarantee.
+
      
+
+
 
+
      Proposed resolution:
      
 
      
-See N2423
-for further discussion.
 
      
 
 
 
-
      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:
      
 
      
-See N2423
-for the proposed resolution.
+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:
      
+
      
+
      
+
 
 
 
 
 
      
-
      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].
      
+
      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:
      
 
      
-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.
+29.1 [atomics.order] p1 says in the table that
 
      
 
+
      
+
+
+
+
+
+
+
+
+
      ElementMeaning
      memory_order_acq_relthe operation has both acquire and release semantics
      
+
      
+
 
      
-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."
+To my naked eye, that seems to imply that even an atomic read has both
+acquire and release semantics.
 
      
 
 
      
-Additionally, the definition of s in 26.4.1.3 [rand.req.eng]/1 c) could be restricted to unsigned integer types.
+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
      
+
      
+
 
      
-Similarly, the type of the seed in 26.4.1.4 [rand.req.adapt]/3 e) could be left unspecified.
+So that seems to be "the same thing" as memory_order_acq_rel, with additional
+constraints.
 
      
 
 
      
-See N2423
-for further discussion.
+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?
+
      
 
-
      Proposed resolution:
      
 
      
-See N2423
-for further discussion.
+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.
+
      
 
-
      
-
      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.
+(Since this is exactly the same restriction as for "store", it seems to be a typo.)
 
      
 
 
      
-Posssible resolution: [As above]
+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.
+
      
+
 
      
-See N2423
-for further discussion.
+This is redundant with 1.10 [intro.multithread], see above for the reasoning.
 
      
 
 
-
 
      Proposed resolution:
      
 
      
-See N2423
-for the 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.
+
      
 
-
-
-
-
      
-
      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. 
+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.
 
      
+
 
      
-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:
+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.
 
      
+
      
 
 
      
-Possible resolution:
+Rephrase 29.1 [atomics.order] p2:
 
      
 
-
        
-
      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. 
+
        
+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]
+
        
+
 
        
-Supplement the seed_seq with a traits class
+Rephrase 29.4.4 [atomics.types.operations] p12 as:
 
        
-
        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. 
-
      
 
+
      
+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.
+
      
 
-
      Proposed resolution:
      
 
      
-See N2423
-for the proposed resolution.
+Same in p15, p20, p22.
 
      
 
 
 
 
 
+
 
      
-
      732. Defect in [rand.dist.samp.genpdf]
      
-
      Section: 26.4.8.5.3 [rand.dist.samp.genpdf] Status: New
- Submitter: Stephan Tolksdorf Date: 2007-09-21
      
+
      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:
      
 
      
-26.4.8.5.3 [rand.dist.samp.genpdf] describes the interface for a distribution template that is 
-meant to simulate random numbers from any general distribution given only the density and the 
-support of the distribution. I'm not aware of any general purpose algorithm that would be capable 
-of correctly and efficiently implementing the described functionality. From what I know, this is 
-essentially an unsolved research problem. Existing algorithms either require more knowledge 
-about the distribution and the problem domain or work only under very limited circumstances. 
-Even the state of the art special purpose library UNU.RAN does not solve the problem in full 
-generality, and in any case, testing and customer support for such a library feature would be a 
-nightmare.
+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.
 
      
+
      
+
      
 
 
      
-Possible resolution: For these reasons, I propose to delete section 26.4.8.5.3 [rand.dist.samp.genpdf].
+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:
      
-
      
-See N2423
-for the proposed resolution.
-
      
 
 
 
 
 
 
      
-
      733. Comment on [rand.req.dist]/9
      
-
      Section: 26.4.1.5 [rand.req.dist] Status: New
- Submitter: Stephan Tolksdorf Date: 2007-09-21
      
+
      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:
      
 
      
-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.]
+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.
 
      
 
 
      
-Proposed resolution: I propose to drop this requirement.
+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().
 
      
 
-
-
      Proposed resolution:
      
 
      
-See N2423
-for the proposed resolution.
+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.
+
      
 
-
-
      
-
      734. Unnecessary restriction in [rand.dist.norm.chisq]
      
-
      Section: 26.4.8.4.3 [rand.dist.norm.chisq] Status: New
- Submitter: Stephan Tolksdorf Date: 2007-09-21
      
-
      View all issues with New status.
      
-
      Discussion:
      
 
      
-chi_squared_distribution, fisher_f_distribution and student_t_distribution
-have parameters for the "degrees of freedom" n and m that are specified as integers. For the 
-following two reasons this is an unnecessary restriction: First, in many applications such as 
-Bayesian inference or Monte Carlo simulations it is more convenient to treat the respective param- 
-eters as continuous variables. Second, the standard non-naive algorithms (i.e. 
-O(1) algorithms) 
-for simulating from these distributions work with floating-point parameters anyway (all three 
-distributions could be easily implemented using the Gamma distribution, for instance).
+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.
+
      
+
 
      
-Similar arguments could in principle be made for the parameters t and k of the discrete 
-binomial_distribution and negative_binomial_distribution, though in both cases continuous
-parameters are less frequently used in practice and in case of the binomial_distribution
-the implementation would be significantly complicated by a non-discrete parameter (in most 
-implementations one would need an approximation of the log-gamma function instead of just the 
-log-factorial function).
+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.
 
      
 
 
      
-Possible resolution: For these reasons, I propose to change the type of the respective parameters 
-to double.
+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:
      
 
      
-See N2423
-for the 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.]
 
      
+
      
+
 
 
 
 
 
 
      
-
      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
      
+
      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:
      
 
      
-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.
+Reading resolution of LWG issue 673 I noticed the following:
 
      
 
-
      
-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.
-
      
+
      
+
      void reset(T* pointer p = 0 pointer());
+
      
 
 
      
-Choosing unusual names for the parameters causes confusion among users and makes the 
-interface unnecessarily inconvenient to use.
+-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]
 
      
+
      
 
 
      
-Possible resolution: For these reasons, I propose to change the name of the respective parameters
-to n and r.
+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:
      
 
      
-See N2423
-for the proposed resolution.
+Add to class template definition in 20.6.11.3 [unique.ptr.runtime]
 
      
 
-
-
-
-
-
      
-
      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. 
-
      
+
      
+
      // modifiers 
+T* release(); 
+void reset(T* p = 0); 
+void reset( nullptr_t );
+template< typename T > void reset( T ) = delete;
+void swap(unique_ptr&& u);
+
      
+
      
 
 
      
-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.
+Update 20.6.11.3.3 [unique.ptr.runtime.modifiers]
 
      
 
+
      
+
      void reset(pointer p = pointer());
+void reset(nullptr_t);
+
      
 
-
      Proposed resolution:
      
 
      
-See N2423
-for the proposed resolution.
+-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).
+]
      
+
 
 
 
 
 
 
      
-
      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
      
+
      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:
      
-
        
-
      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
+I just noticed that the following program is legal in C++03, but
+is forbidden in the current draft:
 
        
-
        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.
-
      
+
      #include <vector>
+#include <iostream>
 
+class Toto
+{
+public:
+    Toto() {}
+    explicit Toto( Toto const& ) {}
+} ;
+
+int
+main()
+{
+    std::vector< Toto > v( 10 ) ;
+    return 0 ;
+}
+
      
 
-
      Proposed resolution:
      
 
      
-See N2423
-for the proposed resolution.
+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.)
 
      
 
 
 
-
-
-
      
-
      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:
      
+
      Proposed resolution:
      
 
      
-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.
+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
      ...
      
+
      
 
-
      Proposed resolution:
      
 
      
-See N2423
-for the proposed resolution.
+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
      ...
      
+
      
+
 
 
 
 
 
      
-
      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].
      
+
      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:
      
 
      
-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)).
+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.
 
      
 
 
      
-See N2423
-for further discussion.
+Suggested resolution:  Specialize identity<void> so as not to require
+the member function's presence.
 
      
 
 
-
 
      Proposed resolution:
      
 
      
-See N2423
-for the proposed resolution.
 
      
 
 
@@ -13834,164 +18030,151 @@ for the proposed resolution.
 
 
 
      
-
      740. Please remove *_ptr<T[N]>
      
-
      Section: 20.6.5.4 [unique.ptr.compiletime] Status: New
- Submitter: Herb Sutter Date: 2007-10-04
      
+
      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:
      
 
      
-Please don't provide *_ptr<T[N]>. It doesn't enable any useful
-bounds-checking (e.g., you could imagine that doing op++ on a
-shared_ptr<T[N]> yields a shared_ptr<T[N-1]>, but that promising path
-immediately falters on op-- which can't reliably dereference because we
-don't know the lower bound). Also, most buffers you'd want to point to
-don't have a compile-time known size.
+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.
 
      
 
-
      
-To enable any bounds-checking would require run-time information, with
-the usual triplet: base (lower bound), current offset, and max offset
-(upper  bound). And I can sympathize with the point of view that you
-wouldn't want to require this on *_ptr itself. But please let's not
-follow the <T[N]> path, especially not with additional functions to
-query the bounds etc., because this sets wrong user expectations by
-embarking on a path that doesn't go all the way to bounds checking as it
-seems to imply.
-
      
+
      template<class charT, class traits, class Allocator>
+ basic_ostream<charT, traits>&
+   operator<<(basic_ostream<charT, traits>&& os,
+              const basic_string<charT,traits,Allocator>& str);
+
      
 
 
      
-If bounds checking is desired, consider a checked_*_ptr instead (e.g.,
-checked_shared_ptr). And make the interfaces otherwise identical so that
-user code could easily #define/typedef between prepending checked_ on
-debug builds and not doing so on release builds (for example).
+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);
+
      
+
 
      
-Note that some may object that checked_*_ptr may seem to make the smart
-pointer more like vector, and we don't want two ways to spell vector. I
-don't agree, but if that were true that would be another reason to
-remove *_ptr<T[N]> which equally makes the smart pointer more like
-std::array. :-)
+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:
      
 
      
-Change the synopsis under 20.6.5 [unique.ptr] p2:
 
      
 
-
      ...
-template<class T> struct default_delete; 
-template<class T> struct default_delete<T[]>; 
-template<class T, size_t N> struct default_delete<T[N]>;
 
-template<class T, class D = default_delete<T>> class unique_ptr; 
-template<class T, class D> class unique_ptr<T[], D>; 
-template<class T, class D, size_t N> class unique_ptr<T[N], D>;
-...
-
      
 
+
+
+
      
+
      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:
      
 
      
-Remove the entire section 20.6.5.1.3 [unique.ptr.dltr.dflt2] default_delete<T[N]>.
+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:
      
 
      
-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].
 
      
 
 
 
 
 
-
 
      
-
      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].
      
+
      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:
      
 
      
-The following issue was raised by Alf P. Steinbach in c.l.c++.mod:
+In the spirit of printf vs iostream...
 
      
 
 
      
-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:
+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?
 
      
 
-
      template<class D, class T> D* get_deleter(shared_ptr<T> const& p);
-
      
+
      [
+Pablo Halpern:
+]
      
 
-
      
-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:
+
      
+I'm not sure it constitutes a defect, but I would be in favor of adding
+another flag (and corresponding manipulator).
+
      
 
-
      
-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):
-
      
+
      [
+Martin Sebor:
+]
      
 
-
        
-
      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. 
-
      
+
      
+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).
+
      
 
-
      
-Alberto Ganesh Barbati adds:
-
      
 
-
        
-
      1. 
+
        Proposed resolution:
        
 
        
-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:
-
      
 
-
      
+
+
+
      
+
      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:
      
 
      
-My favorite option is "not a defect". A, B and C break useful code.
+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:
      
@@ -14003,126 +18186,127 @@ My favorite option is "not a defect". A, B and C break useful code.
 
 
 
      
-
      742. Enabling swap for proxy iterators
      
-
      Section: 20.1.1 [utility.arg.requirements] Status: New
- Submitter: Howard Hinnant Date: 2007-10-10
      
-
      View other active issues in [utility.arg.requirements].
      
-
      View all other issues in [utility.arg.requirements].
      
+
      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:
      
 
      
-This issue was split from 672. 672 now just
-deals with changing the requirements of T in the Swappable
-requirement from CopyConstructible and CopyAssignable to
-MoveConstructible and MoveAssignable.
+[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:
      
 
      
-This issue seeks to widen the Swappable requirement to support proxy iterators.  Here
-is example code:
 
      
 
-
      namespace Mine {
 
-template <class T>
-struct proxy {...};
 
-template <class T>
-struct proxied_iterator
-{
-   typedef T value_type;
-   typedef proxy<T> reference;
-   reference operator*() const;
-   ...
-};
 
-struct A
-{
-   // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
-   void swap(A&);
-   ...
-};
 
-void swap(A&, A&);
-void swap(proxy<A>, A&);
-void swap(A&, proxy<A>);
-void swap(proxy<A>, proxy<A>);
+
      
+
      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:
      
 
-}  // Mine
+
      
+
      exception_ptr xp;
      
+
      try {do_something(); }
+
+catch (const runtime_error& ) {xp = current_exception();}
 
 ...
 
-Mine::proxied_iterator<Mine::A> i(...)
-Mine::A a;
-swap(*i1, a);
-
      
+rethrow_exception(xp);
      
+
      
 
 
      
-The key point to note in the above code is that in the call to swap, *i1
-and a are different types (currently types can only be Swappable with the
-same type).  A secondary point is that to support proxies, one must be able to pass rvalues
-to swap.  But note that I am not stating that the general purpose std::swap
-should accept rvalues!  Only that overloaded swaps, as in the example above, be allowed
-to take rvalues.
+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.
 
      
 
 
      
-That is, no standard library code needs to change.  We simply need to have a more flexible
-definition of Swappable.
+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:
      
+
 
      
-Change 20.1.1 [utility.arg.requirements]:
+After 18.7.5 [propagation] , paragraph 7, add the indicated text:
 
      
 
 
      
+
      exception_ptr current_exception();
      
 
+
      
 
      
--1- The template definitions in the C++ Standard Library refer to various
-named requirements whose details are set out in tables 31-38. In these
-tables, T and V are is a types to be supplied by a C++ program
-instantiating a template; a, b, and c are
-values of type const T; s and t are modifiable
-lvalues of type T; u is a value of type (possibly
-const) T; and rv is a non-const
-rvalue of type T; w is a value of type T; and v is a value of type V.
+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]
 
      
 
-
-
-
-
-
-
-
      Table 37: Swappable requirements [swappable]
      expressionreturn typepost-condition
      swap(sw,tv)voidtw has the value originally
-held by uv, and
-uv has the value originally held
-by tw
      
 
      
-The Swappable requirement is met by satisfying one or more of the following conditions:
+Remarks: The type of the exception object 
+referred to by the returned exception_ptr is the most-derived 
+type of the currently handled exception.
 
      
-
        
-
      • 
-T is Swappable if T and V are
-the same type and  T satisfies the
-CopyConstructible
-MoveConstructible requirements (Table 34
-33) and the CopyAssignable
-MoveAssignable requirements (Table 36
-35);
-
        • 
-
      • 
-T is Swappable with V if a namespace scope function named
-swap exists in the same namespace as the definition of
-T or V, such that the expression
-swap(tw,u v) is valid and has the
-semantics described in this table.
-
        • 
-
      
-
      
+
+
      
+Throws: nothing.
+
      
+
+
      
 
      
 
 
@@ -14131,217 +18315,349 @@ semantics described in this table.
 
 
 
      
-
      743. rvalue swap for shared_ptr
      
-
      Section: 20.6.6.2.9 [util.smartptr.shared.spec] Status: New
- Submitter: Howard Hinnant Date: 2007-10-10
      
+
      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:
      
 
      
-When the LWG looked at 674 in Kona the following note was made:
+  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.
 
      
 
-
      
-We may need to open an issue to deal with the question of
-whether shared_ptr needs an rvalue swap.
-
      
+
      [
+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:
      
 
      
-This issue was opened in response to that note.
+  Replace paragraph 4 of 21.1 [char.traits] by:
 
      
-
+
      
 
      
-I believe allowing rvalue shared_ptrs to swap is both
-appropriate, and consistent with how other library components are currently specified.
+  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.
 
      
+
      
 
 
 
-
      Proposed resolution:
      
-
      
-Change the synopsis in 20.6.6.2 [util.smartptr.shared]:
-
      
 
-
      void swap(shared_ptr&& r);
-...
-template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b);
-template<class T> void swap(shared_ptr<T>&& a, shared_ptr<T>& b);
-template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>&& b);
-
      
 
+
      
+
      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:
      
 
      
-Change 20.6.6.2.4 [util.smartptr.shared.mod]:
+  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.
 
      
 
-
      void swap(shared_ptr&& r);
-
      
 
+
      Proposed resolution:
      
 
      
-Change 20.6.6.2.9 [util.smartptr.shared.spec]:
+  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.
 
      
 
-
      template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b);
-template<class T> void swap(shared_ptr<T>&& a, shared_ptr<T>& b);
-template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>&& b);
-
      
-
 
 
 
 
 
      
-
      744. What is the lifetime of an exception pointed to by an exception_ptr?
      
-
      Section: 18.7.5 [propagation] Status: New
- Submitter: Alisdair Meredith Date: 2007-10-10
      
-
      View other active issues in [propagation].
      
-
      View all other issues in [propagation].
      
+
      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:
      
 
      
-Without some lifetime guarantee, it is hard to know how this type can be
-used.  Very specifically, I don't see how the current wording would
-guarantee and exception_ptr caught at the end of one thread could be safely
-stored and rethrown in another thread - the original motivation for this
-API.
+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. 
 
      
+
 
      
-(Peter Dimov agreed it should be clearer, maybe a non-normative note to
-explain?)
+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:
+
      
 
-
      
-
      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:
      
+
      
+
      extern const error_category&* const get_generic_category();
+
      
 
      
-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.
+Returns: A reference generic_category shall point
+to an a statically initialized object of a type derived from
+class error_category.
 
      
+
 
      
-(Peter Dimov suggests NAD)
+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();
+
      
 
-
      Proposed resolution:
      
 
      
+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
+
      
 
-
      
-
      746. current_exception may fail with bad_alloc
      
-
      Section: 18.7.5 [propagation] Status: New
- Submitter: Alisdair Meredith Date: 2007-10-10
      
-
      View other active issues in [propagation].
      
-
      View all other issues in [propagation].
      
-
      View all issues with New status.
      
-
      Discussion:
      
 
      
-I understand that the attempt to copy an exception may run out of memory,
-but I believe this is the only part of the standard that mandates failure
-with specifically bad_alloc, as opposed to allowing an
-implementation-defined type derived from bad_alloc.  For instance, the Core
-language for a failed new expression is:
+Change 19.4.2.2 [syserr.errcode.constructors] Class error_code constructors as indicated:
 
      
+
 
      
+
      constexpr error_code(int val, const error_category&* cat);
+
      
 
      
-Any other allocation function that fails to allocate storage shall indicate
-failure only by throwing an exception of a type that would match a handler
-(15.3) of type std::bad_alloc (18.5.2.1).
+Effects: Constructs an object of type error_code.
 
      
-
      
 
      
-I think we should allow similar freedom here (or add a blanket
-compatible-exception freedom paragraph in 17)
+Postconditions: val_ == val and cat_ == cat.
 
      
 
      
-I prefer the clause 17 approach myself, and maybe clean up any outstanding
-wording that could also rely on it.
+Throws: Nothing.
 
      
+
      
 
+
      
+Change 19.4.2.3 [syserr.errcode.modifiers] Class error_code modifiers  as indicated:
+
      
 
-
      Proposed resolution:
      
+
      
+
      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
+
      
+
      
 
-
      
-
      747. We have 3 separate type traits to identify classes supporting no-throw operations
      
-
      Section: 20.4.4.3 [meta.unary.prop] Status: New
- Submitter: Alisdair Meredith Date: 2007-10-10
      
-
      View other active issues in [meta.unary.prop].
      
-
      View all other issues in [meta.unary.prop].
      
-
      View all issues with New status.
      
-
      Discussion:
      
 
      
-We have 3 separate type traits to identify classes supporting no-throw
-operations, which are very useful when trying to provide exception safety
-guarantees.  However, I'm not entirely clear on what the current wording
-requires of a conforming implementation.  To quote from
-has_nothrow_default_constructor:
+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.
 
      
-
      
-or T is a class type with a default constructor that is known not to throw
-any exceptions
-
      
 
      
-What level of magic do we expect to deduce if this is known?
+Postconditions: val_ == val and cat_ == cat.
 
      
 
      
-E.g.
+Throws: Nothing.
 
      
+
      
 
-
      struct test{
- int x;
- test() : x() {}
-};
-
      
 
      
-Should I expect a conforming compiler to 
- assert( has_nothrow_constructor<test>::value )
+Change 19.4.3.3 [syserr.errcondition.modifiers] Class error_condition modifiers as indicated:
 
      
+
+
      
+
      void assign(int val, const error_category&* cat);
+
      
 
      
-Is this a QoI issue?
+Postconditions: val_ == val and cat_ == cat.
 
      
 
      
-Should I expect to 'know' only if-and-only-if there is an inline definition
-available?
+Throws: Nothing.
 
      
+
      
+
 
      
-Should I never expect that to be true, and insist that the user supplies an
-empty throw spec if they want to assert the no-throw guarantee?
+Change 19.4.3.4 [syserr.errcondition.observers] Class error_condition observers as indicated:
 
      
+
+
      
+
      const error_category&* category() const;
+
      
 
      
-It would be helpful to maybe have a footnote explaining what is required,
-but right now I don't know what to suggest putting in the footnote.
+Returns: cat_.
 
      
 
      
-(agreement since is that trivial ops and explicit no-throws are required.
-Open if QoI should be allowed to detect further)
+Throws: Nothing.
 
      
+
      
 
+
      
+Throughout 19.4 [syserr] System error support, change "category()."  to "category()->".
+Appears approximately six times.
+
      
 
-
      Proposed resolution:
      
 
      
+[Partially Editorial] In 19.4.4 [syserr.compare] Comparison operators,
+paragraphs 2 and 4, change "category.equivalent("  to
+"category()->equivalent(".
 
      
 
 
@@ -14349,346 +18665,550 @@ Open if QoI should be allowed to detect further)
 
 
 
      
-
      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].
      
+
      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:
      
 
      
-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)
+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:
      
-
      
-
      
 
 
 
 
 
 
      
-
      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].
      
+
      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:
      
 
      
-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.
+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).
 
      
 
      
-For instance:
+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).
 
      
-
      
-
      struct awkward {
- awkward( const awkward & ) throw() {}
- awkward( awkward & ) { throw "oops"; } };
-
      
-
      
 
 
 
      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.
+
      
+
 
 
 
 
 
      
-
      750. The current definition for is_convertible requires that the type be
-implicitly convertible, so explicit constructors are ignored.
      
-
      Section: 20.4.5 [meta.rel] Status: New
- Submitter: Alisdair Meredith Date: 2007-10-10
      
+
      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:
      
-
      
-With the pending arrival of explicit conversion functions though, I'm
-wondering if we want an additional trait, is_explictly_convertible?
-
      
+       
      
+
+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:
 
+       
      
+       
      
 
-
      Proposed resolution:
      
-
      
-
      
+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().
 
+       
      
+   
 
 
 
 
      
-
      751. change pass-by-reference members of vector<bool> to pass-by-value?
      
-
      Section: 23.2.6 [vector.bool] Status: New
- Submitter: Alisdair Meredith Date: 2007-10-10
      
+
      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:
      
-
      
-A number of vector<bool> members take const bool& as arguments.
-Is there any chance we could change them to pass-by-value or would I 
-be wasting everyone's time if wrote up an issue?
-
      
+       
      
 
+In paragraph 2, 22.2.6.1.2 [locale.money.get.virtuals] specifies the following:
 
-
      Proposed resolution:
      
-
      
-
      
+       
      
+       
      
 
+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. 
 
-
        
-
        752. Allocator complexity requirement
        
-
        Section: 20.1.2 [allocator.requirements] Status: New
- Submitter: Hans Boehm Date: 2007-10-11
        
-
        View other active issues in [allocator.requirements].
        
-
        View all other issues in [allocator.requirements].
        
-
        View all issues with New status.
        
-
        Discussion:
        
-
        
-Did LWG recently discuss 20.1.2 [allocator.requirements]-2, which states that "All the operations
-on the allocators are expected to be amortized constant time."?
-
        
-
        
-As I think I pointed out earlier, this is currently fiction for
-allocate() if it has to obtain memory from the OS, and it's unclear to
-me how to interpret this for construct() and destroy() if they deal with
-large objects.  Would it be controversial to officially let these take
-time linear in the size of the object, as they already do in real life?
-
        
-
        
-Allocate() more blatantly takes time proportional to the size of the
-object if you mix in GC.  But it's not really a new problem, and I think
-we'd be confusing things by leaving the bogus requirements there.  The
-current requirement on allocate() is generally not important anyway,
-since it takes O(size) to construct objects in the resulting space.
-There are real performance issues here, but they're all concerned with
-the constants, not the asymptotic complexity.
-
        
+where money_base::space appears in the format, at least
+one space is required, and
 
+               
        2. 
+               
      2. 
 
-
        Proposed resolution:
        
-
        
-Change 20.1.2 [allocator.requirements]/2:
-
        
+where money_base::none appears in the format, space is
+allowed but not required.
 
-
        
-
        
--2- Table 39 describes the requirements on types manipulated through
-allocators. All the operations on the allocators are expected to be
-amortized constant time, except that allocate and
-construct may require time proportional to the size of the
-object allocated or constructed. Table 40 describes the
-requirements on allocator types.
-
        
-
        
+               
        3. 
+           
      
+       
      
+       
      
 
+The other is that:
 
+       
      
+       
      
 
+where either money_base::space or money_base::none appears in the format, white space is optional.
 
+       
      
+   
 
-
      
-
      753. Move constructor in draft
      
-
      Section: 20.1.1 [utility.arg.requirements] Status: New
- Submitter: Yechezkel Mett Date: 2007-10-14
      
-
      View other active issues in [utility.arg.requirements].
      
-
      View all other issues in [utility.arg.requirements].
      
-
      View all issues with New status.
      
-
      Discussion:
      
-
      
-The draft standard n2369 uses the term move constructor in a few
-places, but doesn't seem to define it.
-
      
+   
      Proposed resolution:
      
+       
      
 
-
      
-MoveConstructible requirements are defined in Table 33 in 20.1.1 [utility.arg.requirements] as
-follows:
-
      
+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:
 
-
      
-
-
-
-
-
-
-
-
-
-
-
-
      MoveConstructible requirements
      expression post-condition
      T t = rv t is equivalent to the value of rv before the construction
      [Note: There is no requirement on the value of rv after the 
-construction. -- end note]
      
-
      
+       
      
 
-
      
-(where rv is a non-const rvalue of type T).
-
      
+       
      
 
-
      
-So I assume the move constructor is the constructor that would be used
-in filling the above requirement.
-
      
+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, ...
 
-
      
-For vector::reserve, vector::resize and the vector modifiers given in
-23.2.5.4 [vector.modifiers] we have
-
      
+       
      
+   
 
-
      
-Requires: If value_type has a move constructor, that constructor shall
-not throw any exceptions.
-
      
 
-
      
-Firstly "If value_type has a move constructor" is superfluous; every
-type which can be put into a vector has a move constructor (a copy
-constructor is also a move constructor). Secondly it means that for
-any value_type which has a throwing copy constructor and no other move
-constructor these functions cannot be used -- which I think will come
-as a shock to people who have been using such types in vector until
-now!
-
      
 
-
      
-I can see two ways to correct this. The simpler, which is presumably
-what was intended, is to say "If value_type has a move constructor and
-no copy constructor, the move constructor shall not throw any
-exceptions" or "If value_type has a move constructor which changes the
-value of its parameter,".
-
      
+
      
+
      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 other alternative is add to MoveConstructible the requirement that
-the expression does not throw. This would mean that not every type
-that satisfies the CopyConstructible requirements also satisfies the
-MoveConstructible requirements. It would mean changing requirements in
-various places in the draft to allow either MoveConstructible or
-CopyConstructible, but I think the result would be clearer and
-possibly more concise too.
-
      
+The basic_ios::copyfmt() member function is specified in 27.4.4.2 [basic.ios.members] to have the following effects:
 
+   
      
+   
      
 
-
      Proposed resolution:
      
-
      
-
      
+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.
+
+   
      
+ 
 
 
 
 
      
-
      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].
      
+
      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:
      
-
      
-14882-2003, [lib.uninitialized.copy] is currently written as follows:
-
      
+   
      
+
+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:
 
-
      
-
      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.4.1 [uninitialized.copy].
-
      
+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...
 
-
      
-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. 
-
      
+Add pre/postconditions to the member function descriptions of istream_iterator like so:
 
-
      
-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.
-
      
+   
      
+   
      
 
+
      istream_iterator();
      
 
+Effects: Constructs the end-of-stream iterator.
      
+Postcondition: in_stream == 0.
 
-
      Proposed resolution:
      
-
      
-Change the wording of the return clause to say (20.6.4.1 [uninitialized.copy]):
-
      
+
      istream_iterator(istream_type &s);
      
 
-
      
-
      
--2- Returns: The value of result after effects have taken place.
-
      
-
      
+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;
+     
      
+     
      
+   
      
+ 
 
 
 
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}
 
    • 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.
      • @@ -123,7 +206,7 @@ del {background-color:#FFA0A0}
    • 696 issues total, up by 20.
  • Details:
  • Details:
  • Details:
    • @@ -201,7 +284,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.
    • @@ -245,9 +328,9 @@ del {background-color:#FFA0A0}
  • 574 issues total, up by 8.
  • Details:
  • Details:
    • @@ -323,12 +406,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. @@ -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)
  • R9: @@ -492,7 +575,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: @@ -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,287 +5861,166 @@ 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: +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.

    -
    #include <memory>
-using std::auto_ptr;
 
-struct B {};
-struct D : B {};
+
    [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.]
    
 
-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. -

    +

    [ +Batavia: Send to core with our recommendation that we should permit deferred +destruction but not 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. -

    -

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

    [ +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'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>());
-
    +
    #include <cstdlib>
+#include <iostream>
+#include <type_traits>
+#include <new>
 
-
    
-IMHO no one ever wrote such awkward code and the reasonable workaround for
-#1 is:
-
    
-
    int y = sink( auto_ptr<B>(source()) );
-
    
+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";
+    }
+};
 
-
    
-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
-
    
+void deallocate_resource();
 
-
    
-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.
-
    
+// 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;
+}
 
-
    
-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();
+void deallocate_resource()
+{
+    get_resource(false);
+}
 
-// string constructor throws while auto_ptr_ref
-// "holds" the pointer
-int x4 = f(source2(), "xyz"); // #4
-
    
+void use_A(const char* message)
+{
+    A& a = get_resource();
+    std::cout << "Using A " << message << "\n";
+    a.use();
+}
 
-
    
-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. 
-
    
+struct B
+{
+    ~B() {use_A("from ~B()");}
+};
 
-
    
-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
-
    
+B b;
 
-
    
-Dave Abrahams noticed that there is no specification saying that
-auto_ptr_ref copy constructor can't throw.
-
    
+int main()
+{
+    use_A("from main()");
+}
+

    -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. +The correct output is:

    -

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

    +
    A()
+Using A from main()
+A is alive
+~A()
+A()
+Using A from ~B()
+A is alive
+~A()
+
    -

    The proposed auto_ptr interface:

    +

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

    -
    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; };
-
    +

    Proposed resolution:

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

    - - - -

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

    - - - - - -
    -

    466. basic_string ctor should prevent null pointer error

    -

    Section: 21.3.1 [string.require] Status: NAD - Submitter: Daniel Frey Date: 2004-06-10

    -

    View all other issues in [string.require].

    -

    View all issues with NAD status.

    -

    Discussion:

    +
    +

    466. basic_string ctor should prevent null pointer error

    +

    Section: 21.3.1 [string.require] Status: NAD + Submitter: Daniel Frey Date: 2004-06-10

    +

    View all other issues in [string.require].

    +

    View all issues with NAD status.

    +

    Discussion:

    Today, my colleagues and me wasted a lot of time. After some time, I found the problem. It could be reduced to the following short example: @@ -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 @@ -9598,69 +9844,270 @@ Recommend NAD, editorial. Send to Pete.

    -

    633. Return clause mentions undefined "type()"

    -

    Section: 20.5.15.2.5 [func.wrap.func.targ] Status: NAD Editorial - Submitter: Daniel Krügler Date: 2007-02-03

    -

    View all issues with NAD Editorial status.

    +

    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:

    -

    -20.5.15.2.5 [func.wrap.func.targ], p4 says: -

    -

    -Returns: If type() == typeid(T), a pointer to the stored -function target; otherwise a null pointer. -

    +

    -

      -
    1. -There exists neither a type, a typedef type, nor member -function type() in class template function nor in the global or -std namespace. -
      2. -
    2. -Assuming that type should have been target_type(), -this description would lead to false results, if T = cv -void due to returns clause 20.5.15.2.5 [func.wrap.func.targ], p1. -
      3. -
    +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. +

    +

    -

    Proposed resolution:

    -

    -Change 20.5.15.2.5 [func.wrap.func.targ], p4: -

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

    -Returns: If type() target_type() == typeid(T) && typeid(T) != -typeid(void), a pointer to the stored function target; -otherwise a null pointer. -

    +

    +

    -

    [ -Pete: Agreed. It's editorial, so I'll fix it. -]

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

    636. 26.5.2.3 valarray::operator[]

    -

    Section: 26.5.2.3 [valarray.access] Status: NAD Editorial - Submitter: Bo Persson Date: 2007-02-11

    -

    View all other issues in [valarray.access].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -The signature of the const operator[] has been changed to return a const -reference. -

    -

    -The description in paragraph 1 still says that the operator returns by -value. +

    +

    + +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 + Submitter: Daniel Krügler Date: 2007-02-03

    +

    View all issues with NAD Editorial status.

    +

    Discussion:

    +

    +20.5.15.2.5 [func.wrap.func.targ], p4 says: +

    +

    +Returns: If type() == typeid(T), a pointer to the stored +function target; otherwise a null pointer. +

    + +
      +
    1. +There exists neither a type, a typedef type, nor member +function type() in class template function nor in the global or +std namespace. +
      2. +
    2. +Assuming that type should have been target_type(), +this description would lead to false results, if T = cv +void due to returns clause 20.5.15.2.5 [func.wrap.func.targ], p1. +
      3. +
    + + + +

    Proposed resolution:

    +

    +Change 20.5.15.2.5 [func.wrap.func.targ], p4: +

    + +

    +Returns: If type() target_type() == typeid(T) && typeid(T) != +typeid(void), a pointer to the stored function target; +otherwise a null pointer. +

    + +

    [ +Pete: Agreed. It's editorial, so I'll fix it. +]

    + + + + + + + +
    +

    636. 26.5.2.3 valarray::operator[]

    +

    Section: 26.5.2.3 [valarray.access] Status: NAD Editorial + Submitter: Bo Persson Date: 2007-02-11

    +

    View all other issues in [valarray.access].

    +

    View all issues with NAD Editorial status.

    +

    Discussion:

    +

    +The signature of the const operator[] has been changed to return a const +reference. +

    +

    +The description in paragraph 1 still says that the operator returns by +value.

    [ Pete recommends editorial fix. @@ -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 @@ -10585,15 +11226,168 @@ Yep, looks like a typo/administrative fix to me.

    -

    690. abs(long long) should return long long

    -

    Section: 26.7 [c.math] Status: NAD Editorial - Submitter: Niels Dekker Date: 2007-06-10

    -

    View other active issues in [c.math].

    -

    View all other issues in [c.math].

    +

    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:

    -Quoting the latest draft (n2135), 26.7 [c.math]: +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 + Submitter: Niels Dekker Date: 2007-06-10

    +

    View other active issues in [c.math].

    +

    View all other issues in [c.math].

    +

    View all issues with NAD Editorial status.

    +

    Discussion:

    +

    +Quoting the latest draft (n2135), 26.7 [c.math]:

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

    • @@ -96,13 +179,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.
      • @@ -123,7 +206,7 @@ del {background-color:#FFA0A0}
    • 696 issues total, up by 20.
  • Details:
  • Details:
  • Details:
    • @@ -201,7 +284,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.
    • @@ -245,9 +328,9 @@ del {background-color:#FFA0A0}
  • 574 issues total, up by 8.
  • Details:
  • Details:
    • @@ -323,12 +406,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. @@ -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)
  • R9: @@ -492,7 +575,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: @@ -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).

  • 17.3.2.3 [objects.within.classes] Private members/1/(2 places)
  • 17.4 [requirements] Library-wide requirements/1
  • 17.4.1.2 [headers] Headers/4
    • -
  • 17.4.3.4 [replacement.functions] Replacement functions/1
    • +
  • 17.4.3.5 [replacement.functions] Replacement functions/1
  • 17.4.4.3 [global.functions] Global or non-member functions/2
  • 17.4.4.6 [protection.within.classes] Protection within classes/1
    • @@ -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.

    • 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:
 
    
 
    
 
    
@@ -21746,498 +21918,535 @@ automatically.
 
 
 
    
-
    566. array forms of unformatted input function undefined for zero-element arrays
    
-
    Section: 27.6.1.3 [istream.unformatted] Status: WP
- Submitter: Martin Sebor Date: 2006-02-23
    
-
    View all other issues in [istream.unformatted].
    
+
    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 array forms of unformatted input functions don't have well-defined
-semantics for zero-element  arrays in a couple of  cases. The affected
-ones (istream::get() and  getline()) are supposed to
-terminate when (n - 1) characters are stored, which obviously
-can never be true when (n == 0) to start with.
-
-        
    
-
-
-
    Proposed resolution:
    
-        
    
-
-I  propose  the following  changes  (references  are  relative to  the
-Working Draft (document N1804).
-
-        
    
-        
    
-
-Change 27.6.1.3, p8 (istream::get()), bullet 1 as follows:
-
-        
    
-        
    
-            
    
-
-if  (n  < 1)  is  true  or   (n  -  1)
-characters are stored;
+
    
+The declaration of std::inserter is:
+
    
 
-            
    
-        
    
-        
    
+
    template <class Container, class Iterator>
+insert_iterator<Container>
+inserter(Container& x, Iterator i);
+
    
 
-Similarly, change  27.6.1.3, p18 (istream::getline()), bullet
-3 as follows:
+
    
+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:
+
    
 
-(n < 1) is  true or (n - 1) characters
-are     stored     (in    which     case     the    function     calls
-setstate(failbit)).
+
    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.
+
    
 
-Finally, change p21 as follows:
+
    
+This can adversely impact well written code.  Consider:
+
    
 
-        
    
-        
    
-            
    
+
    #include <iterator>
+#include <string>
 
-In any  case, provided  (n > 0)  is true,  it then
-stores  a null  character  (using charT())  into  the next  successive
-location of the array.
+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);
+}
+
    
 
-
    
-
    575. the specification of ~shared_ptr is MT-unfriendly, makes implementation assumptions
    
-
    Section: 20.6.6.2.2 [util.smartptr.shared.dest], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] Status: WP
- Submitter: Peter Dimov Date: 2006-04-23
    
-
    View all issues with WP status.
    
-
    Discussion:
    
 
    
-[tr.util.smartptr.shared.dest] says in its second bullet:
+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.
 
    
 
 
    
-"If *this shares ownership with another shared_ptr instance (use_count() > 1),
-decrements that instance's use count."
+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);
+
    
+
 
    
-The problem with this formulation is that it presupposes the existence of an
-"use count" variable that can be decremented and that is part of the state of a
-shared_ptr instance (because of the "that instance's use count".)
+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.
 
    
 
 
    
-This is contrary to the spirit of the rest of the specification that carefully
-avoids to require an use count variable. Instead, use_count() is specified to
-return a value, a number of instances.
+And it will fail again for such inocuous reaons as my_type or
+my_container privately deriving from any std type.
 
    
 
 
    
-In multithreaded code, the usual implicit assumption is that a shared variable
-should not be accessed by more than one thread without explicit synchronization,
-and by introducing the concept of an "use count" variable, the current wording
-implies that two shared_ptr instances that share ownership cannot be destroyed
-simultaneously.
+It seems unfortunate that such simple changes in the client's code can result
+in such radically differing behavior.
 
    
 
+
+
+
    Proposed resolution:
    
 
    
-In addition, if we allow the interpretation that an use count variable is part
-of shared_ptr's state, this would lead to other undesirable consequences WRT
-multiple threads. For example,
+Change 24.2:
 
    
 
-
    p1 = p2;
+
    
+24.2 Header <iterator> synopsis
+
    
+
    ...
+template <class Container, class Iterator>
+   insert_iterator<Container> inserter(Container& x, Iterator typename Container::iterator i);
+...
 
    
+
    
 
 
    
-would now visibly modify the state of p2, a "write" operation, requiring a lock.
+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);
+...
+
    
+
    
 
-
    Proposed resolution:
    
 
    
-Change the first two bullets of [lib.util.smartptr.shared.dest]/1 to:
+Change 24.4.2.6.5:
 
    
 
 
    
-
      
-
    • If *this is empty or shares ownership with another
-shared_ptr instance (use_count() > 1), there are no side effects.
      • 
-
    • If *this shares ownership with another shared_ptr instance
-(use_count() > 1), decrements that instance's use count.
      • 
-
    
-
    
-
 
    
-Add the following paragraph after [lib.util.smartptr.shared.dest]/1:
+24.4.2.6.5 inserter
 
    
-
+
    template <class Container, class Inserter>
+   insert_iterator<Container> inserter(Container& x, Inserter typename Container::iterator i);
+
    
 
    
-[Note: since the destruction of *this decreases the number of instances in
-*this's ownership group by one, all shared_ptr instances that share ownership
-with *this will report an use_count() that is one lower than its previous value
-after *this is destroyed. --end note]
+-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
+]
    
 
 
 
 
 
 
    
-
    576. find_first_of is overconstrained
    
-
    Section: 25.1.4 [alg.find.first.of] Status: WP
- Submitter: Doug Gregor Date: 2006-04-25
    
-
    View all other issues in [alg.find.first.of].
    
+
    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);
+
    
+
 
    
-In 25.1.4 Find First [lib.alg.find.first], the two iterator type parameters to
-find_first_of are specified to require Forward Iterators, as follows:
+-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.
 
    
+
    
 
-
    template<class ForwardIterator1, class ForwardIterator2>
-  ForwardIterator1
-  find_first_of(ForwardIterator1 first1, ForwardIterator1 last1,
-                        ForwardIterator2 first2, ForwardIterator2 last2);
-template<class ForwardIterator1, class ForwardIterator2,
-                  class BinaryPredicate>
-ForwardIterator1
-  find_first_of(ForwardIterator1 first1, ForwardIterator1 last1,
-                         ForwardIterator2 first2, ForwardIterator2 last2,
-                        BinaryPredicate pred);
-
    
+        
    
+
+Change the Effects clause of the str() in 27.7.1.2, p2 to
+read:
 
+        
    
+
    
 
    
-However, ForwardIterator1 need not actually be a Forward Iterator; an Input
-Iterator suffices, because we do not need the multi-pass property of the Forward
-Iterator or a true reference.
+-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.
 
    
 
+        
    
 
-
    Proposed resolution:
    
-
    
-Change the declarations of find_first_of to:
-
    
+-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.
+
+        
    
+
    
 
-
    template<class ForwardIterator1InputIterator1, class ForwardIterator2>
-  ForwardIterator1InputIterator1
-  find_first_of(ForwardIterator1InputIterator1 first1, ForwardIterator1InputIterator1 last1,
-                        ForwardIterator2 first2, ForwardIterator2 last2);
-template<class ForwardIterator1InputIterator1, class ForwardIterator2,
-                  class BinaryPredicate>
-ForwardIterator1InputIterator1
-  find_first_of(ForwardIterator1InputIterator1 first1, ForwardIterator1InputIterator1 last1,
-                         ForwardIterator2 first2, ForwardIterator2 last2,
-                        BinaryPredicate pred);
-
    
 
+
    [
+Kona (2007) Moved to Ready.
+]
    
 
 
 
 
 
 
    
-
    577. upper_bound(first, last, ...) cannot return last
    
-
    Section: 25.3.3.2 [upper.bound] Status: WP
- Submitter: Seungbeom Kim Date: 2006-05-03
    
+
    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:
    
 
    
-ISO/IEC 14882:2003 says:
+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().
 
    
+        
    
 
-
    
-
    
-25.3.3.2 upper_bound
-
    
-
    
-Returns: The furthermost iterator i in the range
-[first, last) such that
-for any iterator j in the range [first, i) the following corresponding
-conditions hold: !(value < *j) or comp(value, *j) == false.
-
    
-
    
+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.
 
-
    
-From the description above, upper_bound cannot return last, since it's
-not in the interval [first, last). This seems to be a typo, because if
-value is greater than or equal to any other values in the range, or if
-the range is empty, returning last seems to be the intended behaviour.
-The corresponding interval for lower_bound is also [first, last].
-
    
+        
    
+        
    
+
+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 [lib.upper.bound]:
-
    
+        
    
+
+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).
+
+
    
 
-
    
-
    
-Returns: The furthermost iterator i in the range
-[first, last)] such that
-for any iterator j in the range [first, i) the following corresponding
-conditions hold: !(value < *j) or comp(value, *j) == false.
-
    
-
    
 
+
    [
+Kona (2007) Moved to Ready.
+]
    
 
 
 
 
 
 
    
-
    578. purpose of hint to allocator::allocate()
    
-
    Section: 20.6.1.1 [allocator.members] Status: WP
- Submitter: Martin Sebor Date: 2006-05-17
    
-
    View all other issues in [allocator.members].
    
+
    566. array forms of unformatted input function undefined for zero-element arrays
    
+
    Section: 27.6.1.3 [istream.unformatted] Status: WP
+ Submitter: Martin Sebor Date: 2006-02-23
    
+
    View all other issues in [istream.unformatted].
    
 
    View all issues with WP status.
    
 
    Discussion:
    
         
    
 
-The     description    of     the     allocator    member     function
-allocate()  requires  that  the hint  argument  be
-either 0 or a  value previously returned from allocate().
-Footnote 227 further suggests that  containers may pass the address of
-an adjacent element as this argument.
+The array forms of unformatted input functions don't have well-defined
+semantics for zero-element  arrays in a couple of  cases. The affected
+ones (istream::get() and  getline()) are supposed to
+terminate when (n - 1) characters are stored, which obviously
+can never be true when (n == 0) to start with.
 
         
    
+
+
+
    Proposed resolution:
    
         
    
 
-I  believe  that  either  the  footnote  is  wrong  or  the  normative
-requirement that  the argument be  a value previously returned  from a
-call to  allocate() is wrong. The latter  is supported by
-the resolution  to issue 20-004 proposed in  c++std-lib-3736 by Nathan
-Myers. In addition,  the hint is an ordinary  void* and not the
-pointer  type returned  by  allocate(), with
-the  two  types potentially  being  incompatible  and the  requirement
-impossible to satisfy.
+I  propose  the following  changes  (references  are  relative to  the
+Working Draft (document N1804).
 
         
    
         
    
 
-See also c++std-lib-14323 for some  more context on where this came up
-(again).
+Change 27.6.1.3, p8 (istream::get()), bullet 1 as follows:
 
         
    
-    
+        
    
+            
    
 
-    
    Proposed resolution:
    
+if  (n  < 1)  is  true  or   (n  -  1)
+characters are stored;
+
+            
    
+        
    
         
    
 
-Remove  the requirement  in  20.6.1.1, p4  that  the hint  be a  value
-previously returned from allocate(). Specifically, change
-the paragraph as follows:
+Similarly, change  27.6.1.3, p18 (istream::getline()), bullet
+3 as follows:
 
         
    
-
    
-Requires: hint either 0 or previously obtained  from  member
-allocate  and  not  yet passed  to member  deallocate.
-The value hint may be used by an implementation to help improve performance
-223). [Note: The value hint may be used by an
-implementation to help improve performance. -- end note]
-
    
-
    
-[Footnote: 223)In a container member function, the address of an
-adjacent element is often a good choice to pass for this argument.
-
    
-    
+        
    
+            
    
+
+(n < 1) is  true or (n - 1) characters
+are     stored     (in    which     case     the    function     calls
+setstate(failbit)).
+
+            
    
+        
    
+        
    
+
+Finally, change p21 as follows:
+
+        
    
+        
    
+            
    
+
+In any  case, provided  (n > 0)  is true,  it then
+stores  a null  character  (using charT())  into  the next  successive
+location of the array.
+
+            
    
+        
    
+
+
 
 
 
 
    
-
    586. string inserter not a formatted function
    
-
    Section: 21.3.8.9 [string.io] Status: WP
- Submitter: Martin Sebor Date: 2006-06-22
    
-
    View all other issues in [string.io].
    
+
    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:
    
         
    
 
-Section  and paragraph  numbers  in  this paper  are  relative to  the
-working draft document number N2009 from 4/21/2006.
+Issue  60 explicitly made  the extractor  and inserter  operators that
+take a  basic_streambuf* argument formatted  input and output
+functions,  respectively.  I  believe that's  wrong, certainly  in the
+case of  the extractor, since formatted functions  begin by extracting
+and  discarding  whitespace.  The  extractor  should  not discard  any
+characters.
 
         
    
 
+
+
    Proposed resolution:
    
         
    
 
-The  basic_string extractor  in 21.3.7.9,  p1  is clearly
-required  to  behave  as  a   formatted  input  function,  as  is  the
-std::getline() overload for string described in p7.
+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.
 
         
    
         
    
 
-However, the basic_string inserter described in p5 of the
-same section has no such requirement. This has implications on how the
-operator  responds  to  exceptions thrown  from  xsputn()
-(formatted  output functions are  required to  set badbit
-and swallow  the exception unless  badbit is also  set in
-exceptions(); the  string inserter doesn't  have any such
-requirement).
+Specifically, change 27.6.1.2.3, p14 as follows:
 
         
    
+
+            
    
         
    
 
-I don't  see anything in the  spec for the string  inserter that would
-justify requiring  it to treat  exceptions differently from  all other
-similar operators. (If it did, I think it should be made this explicit
-by saying  that the  operator "does not  behave as a  formatted output
-function" as has been made customary by the adoption of the resolution
-of issue 60).
+Effects:  Behaves as  an unformatted  input function
+(as   described   in   27.6.1.2.127.6.1.3,   paragraph
+1).
 
         
    
-    
-
-    
    Proposed resolution:
    
+            
    
         
    
 
-I propose to change the Effects clause in 21.3.7.9, p5, as follows:
+And change 27.6.2.5.3, p7 as follows:
 
         
    
+
             
    
         
    
 
-Effects: Begins by constructing a  sentry object k as if k
-were    constructed    by    typename    basic_ostream<charT,
-traits>::sentry   k   (os).    If  bool(k)   is
-true, Behaves  as a formatted  output function
-(27.6.2.5.1).   After constructing  a  sentry object,  if
-this  object returns true  when converted  to a  value of
-type   bool,   determines   padding   as   described   in
-22.2.2.2.2,  then inserts the  resulting sequence  of characters
-seq as if by calling os.rdbuf()->sputn(seq ,
-n),    where   n    is   the    larger   of
-os.width()   and   str.size();  then   calls
-os.width(0).  If  the  call  to sputn  fails,  calls
-os.setstate(ios_base::failbit).
+Effects: Behaves  as an unformatted  output function
+(as   described   in   27.6.2.5.127.6.2.6,   paragraph
+1).
 
         
    
             
    
-        
    
 
-This proposed  resilution assumes the  resolution of issue  394 (i.e.,
-that   all   formatted   output   functions  are   required   to   set
-ios_base::badbit  in response  to any  kind  of streambuf
-failure),   and   implicitly   assumes   that  a   return   value   of
-sputn(seq,  n)  other  than  n
-indicates a failure.
 
-        
    
-    
+
    [
+Kona (2007): Proposed Disposition: Ready
+]
    
+
+
 
 
 
 
    
-
    589. Requirements on iterators of member template functions of containers
    
-
    Section: 23.1 [container.requirements] Status: WP
- Submitter: Peter Dimov Date: 2006-08-02
    
-
    View other active issues in [container.requirements].
    
-
    View all other issues in [container.requirements].
    
+
    575. the specification of ~shared_ptr is MT-unfriendly, makes implementation assumptions
    
+
    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.
    
-
    Duplicate of: 536
    
 
    Discussion:
    
 
    
-There appears to be no requirements on the InputIterators used in sequences in 23.1.1 in
-terms of their value_type, and the requirements in 23.1.2 appear to be overly strict
-(requires InputIterator::value_type be the same type as the container's value_type).
+[tr.util.smartptr.shared.dest] says in its second bullet:
 
    
 
+
    
+"If *this shares ownership with another shared_ptr instance (use_count() > 1),
+decrements that instance's use count."
+
    
 
-
    Proposed resolution:
    
 
    
-Change 23.1.1 p3:
+The problem with this formulation is that it presupposes the existence of an
+"use count" variable that can be decremented and that is part of the state of a
+shared_ptr instance (because of the "that instance's use count".)
 
    
 
-
    
-In Tables 82 and 83, X denotes a sequence class, a denotes a
-value of X, i and j denote iterators satisfying input
-iterator requirements and refer to elements implicitly
-convertible to value_type, [i, j) denotes a valid
-range, n denotes a value of X::size_type, p denotes a
-valid iterator to a, q denotes a valid dereferenceable
-iterator to a, [q1, q2) denotes a valid range in a,
-and t denotes a value of X::value_type.
-
    
-
 
    
-Change 23.1.2 p7:
+This is contrary to the spirit of the rest of the specification that carefully
+avoids to require an use count variable. Instead, use_count() is specified to
+return a value, a number of instances.
 
    
 
-
    
-In Table 84, X is an associative container class, a is a value
-of X, a_uniq is a value of X when X supports
-unique keys, and a_eq is a value of X when X supports
-multiple keys, i and j satisfy input iterator requirements and
-refer to elements of implicitly convertible to
-value_type, [i, j) is a valid range, p is a valid
-iterator to a, q is a valid dereferenceable iterator to
-a, [q1, q2) is a valid range in a, t is a
-value of X::value_type, k is a value of X::key_type
-and c is a value of type X::key_compare.
-
    
-
-
-
-
    Rationale:
    
 
    
-Concepts will probably come in and rewrite this section anyway.  But just in case it is
-easy to fix this up as a safety net and as a clear statement of intent.
+In multithreaded code, the usual implicit assumption is that a shared variable
+should not be accessed by more than one thread without explicit synchronization,
+and by introducing the concept of an "use count" variable, the current wording
+implies that two shared_ptr instances that share ownership cannot be destroyed
+simultaneously.
 
    
 
-
-
-
-
-
    
-
    593. __STDC_CONSTANT_MACROS
    
-
    Section: 18.3 [cstdint], TR1 8.22 [tr.c99.cstdint] Status: WP
- Submitter: Walter Brown Date: 2006-08-28
    
-
    View all other issues in [cstdint].
    
-
    View all issues with WP status.
    
-
    Discussion:
    
 
    
-Clause 18.3 of the current Working Paper (N2009) deals with the new C++ headers
-<cstdint> and <stdint.h>.  These are of course based on the C99 header
-<stdint.h>, and were part of TR1.
+In addition, if we allow the interpretation that an use count variable is part
+of shared_ptr's state, this would lead to other undesirable consequences WRT
+multiple threads. For example,
 
    
 
+
    p1 = p2;
+
    
+
 
    
-Per 18.3.1/1, these headers define a number of macros and function macros. 
-While the WP does not mention __STDC_CONSTANT_MACROS in this context, C99
-footnotes do mention __STDC_CONSTANT_MACROS.  Further, 18.3.1/2 states that "The
-header defines all ... macros the same as C99 subclause 7.18."
+would now visibly modify the state of p2, a "write" operation, requiring a lock.
 
    
 
+
+
    Proposed resolution:
    
 
    
-Therefore, if I wish to have the above-referenced macros and function macros
-defined, must I #define __STDC_CONSTANT_MACROS before I #include <cstdint>, or
-does the C++ header define these macros/function macros unconditionally?
+Change the first two bullets of [lib.util.smartptr.shared.dest]/1 to:
 
    
 
+
    
+
      
+
    • If *this is empty or shares ownership with another
+shared_ptr instance (use_count() > 1), there are no side effects.
      • 
+
    • If *this shares ownership with another shared_ptr instance
+(use_count() > 1), decrements that instance's use count.
      • 
+
    
+
    
 
-
    Proposed resolution:
    
 
    
-To put this issue to rest for C++0X, I propose the following addition to 
-18.3.1/2 of the Working Paper N2009:
+Add the following paragraph after [lib.util.smartptr.shared.dest]/1:
 
    
 
 
    
-[Note: The macros defined by <cstdint> are provided unconditionally: in
-particular, the symbols __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS
-(mentioned in C99 footnotes 219, 220, and 222) play no role in C++. --end note]
+[Note: since the destruction of *this decreases the number of instances in
+*this's ownership group by one, all shared_ptr instances that share ownership
+with *this will report an use_count() that is one lower than its previous value
+after *this is destroyed. --end note]
 
    
 
 
@@ -22245,78 +22454,52 @@ particular, the symbols __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS
 
 
 
    
-
    598. Decimal: Conversion to integral should truncate, not round.
    
-
    Section: TRDecimal 3.2 [trdec.types.types] Status: TRDec
- Submitter: Daniel Krugler Date: 2006-05-28
    
-
    View other active issues in [trdec.types.types].
    
-
    View all other issues in [trdec.types.types].
    
-
    View all issues with TRDec status.
    
+
    576. find_first_of is overconstrained
    
+
    Section: 25.1.4 [alg.find.first.of] Status: WP
+ Submitter: Doug Gregor Date: 2006-04-25
    
+
    View all other issues in [alg.find.first.of].
    
+
    View all issues with WP status.
    
 
    Discussion:
    
-
-
    
-In a private email, Daniel writes:
-
    
-
    
 
    
-I would like to 
-ask, what where the reason for the decision to 
-define the semantics of the integral conversion of the decimal types, namely
+In 25.1.4 Find First [lib.alg.find.first], the two iterator type parameters to
+find_first_of are specified to require Forward Iterators, as follows:
 
    
-
    "operator long long() const;
 
-     Returns: Returns the result of the 
-conversion of *this to the type long long, as if 
-performed by the expression llrounddXX(*this)."
-
    
-
    
-where XX stands for either 32, 64, or 128, 
-corresponding to the proper decimal type. The 
-exact meaning of llrounddXX is not given in that 
-paper, so I compared it to the corresponding 
-definition given in C99, 2nd edition (ISO 9899), which says in 7.12.9.7 p. 2:
-
    
-
    
-"The lround and llround functions round their 
-argument to the nearest integer value,
-rounding halfway cases away from zero, regardless 
-of the current rounding direction. [..]"
-
    
-
    
-Now considering the fact that integral conversion 
-of the usual floating-point types ("4.9 
-Floating-integral conversions") has truncation 
-semantic I wonder why this conversion behaviour 
-has not been transferred for the decimal types. 
-
    
-
    
-
    
-Robert comments:
-
    
+
    template<class ForwardIterator1, class ForwardIterator2>
+  ForwardIterator1
+  find_first_of(ForwardIterator1 first1, ForwardIterator1 last1,
+                        ForwardIterator2 first2, ForwardIterator2 last2);
+template<class ForwardIterator1, class ForwardIterator2,
+                  class BinaryPredicate>
+ForwardIterator1
+  find_first_of(ForwardIterator1 first1, ForwardIterator1 last1,
+                         ForwardIterator2 first2, ForwardIterator2 last2,
+                        BinaryPredicate pred);
+
    
+
 
    
-Also, there is a further error in the Returns: clause for converting decimal::decimal128 to long long.  It currently calls llroundd64, not llroundd128.
+However, ForwardIterator1 need not actually be a Forward Iterator; an Input
+Iterator suffices, because we do not need the multi-pass property of the Forward
+Iterator or a true reference.
 
    
 
 
-
 
    Proposed resolution:
    
 
    
-Change the Returns: clause in 3.2.2.4 to:
-
    
-
    
-Returns: Returns the result of the conversion of *this to the type long long, as if performed by the expression llroundd32(*this) while the decimal rounding direction mode [3.5.2] FE_DEC_TOWARD_ZERO is in effect.
-
    
-
    
-Change the Returns: clause in 3.2.3.4 to:
-
    
-
    
-Returns: Returns the result of the conversion of *this to the type long long, as if performed by the expression llroundd64(*this) while the decimal rounding direction mode [3.5.2] FE_DEC_TOWARD_ZERO is in effect.
-
    
-
    
-Change the Returns: clause in 3.2.4.4 to:
+Change the declarations of find_first_of to:
 
    
-
    
-Returns: Returns the result of the conversion of *this to the type long long, as if performed by the expression llroundd64(*this) llroundd128(*this) while the decimal rounding direction mode [3.5.2] FE_DEC_TOWARD_ZERO is in effect.
-
    
+
+
    template<class ForwardIterator1InputIterator1, class ForwardIterator2>
+  ForwardIterator1InputIterator1
+  find_first_of(ForwardIterator1InputIterator1 first1, ForwardIterator1InputIterator1 last1,
+                        ForwardIterator2 first2, ForwardIterator2 last2);
+template<class ForwardIterator1InputIterator1, class ForwardIterator2,
+                  class BinaryPredicate>
+ForwardIterator1InputIterator1
+  find_first_of(ForwardIterator1InputIterator1 first1, ForwardIterator1InputIterator1 last1,
+                         ForwardIterator2 first2, ForwardIterator2 last2,
+                        BinaryPredicate pred);
+
    
 
 
 
@@ -22324,402 +22507,2078 @@ Change the Returns: clause in 3.2.4.4 to:
 
 
 
    
-
    599. Decimal: Say "octets" instead of "bytes."
    
-
    Section: TRDecimal 3.1 [trdec.types.encodings] Status: TRDec
- Submitter: Daniel Krugler Date: 2006-05-28
    
-
    View all issues with TRDec status.
    
+
    577. upper_bound(first, last, ...) cannot return last
    
+
    Section: 25.3.3.2 [upper.bound] Status: WP
+ Submitter: Seungbeom Kim Date: 2006-05-03
    
+
    View all issues with WP status.
    
 
    Discussion:
    
 
    
-Daniel writes in a private email:
+ISO/IEC 14882:2003 says:
 
    
 
 
    
 
    
-- 3.1 'Decimal type encodings' says in its note:
+25.3.3.2 upper_bound
 
    
-
    "this implies that 
-sizeof(std::decimal::decimal32) == 4, 
-sizeof(std::decimal::decimal64) == 8, and 
-sizeof(std::decimal::decimal128) == 16."
-
    
 
    
-This is a wrong assertion, because the definition 
-of 'byte' in 1.7 'The C+ + memory model' of ISO 
-14882 (2nd edition) does not specify that a byte 
-must be necessarily 8 bits large, which would be 
-necessary to compare with the specified bit sizes 
-of the types decimal32, decimal64, and decimal128.
+Returns: The furthermost iterator i in the range
+[first, last) such that
+for any iterator j in the range [first, i) the following corresponding
+conditions hold: !(value < *j) or comp(value, *j) == false.
 
    
 
    
 
-
-
    Proposed resolution:
    
 
    
-Change 3.1 as follows:
+From the description above, upper_bound cannot return last, since it's
+not in the interval [first, last). This seems to be a typo, because if
+value is greater than or equal to any other values in the range, or if
+the range is empty, returning last seems to be the intended behaviour.
+The corresponding interval for lower_bound is also [first, last].
 
    
-
    
+
+
+
    Proposed resolution:
    
 
    
-The three decimal encoding formats defined in IEEE-754R correspond to the three decimal floating types as follows:
+Change [lib.upper.bound]:
 
    
-
      
-
    • 
-decimal32 is a decimal32 number, which is encoded in four consecutive bytes octets (32 bits)
-
      • 
-
    • 
-decimal64 is a decimal64 number, which is encoded in eight consecutive bytes octets (64 bits)
 
-
      • 
-
    • 
-decimal128 is a decimal128 number, which is encoded in 16 consecutive bytes octets (128 bits)
-
      • 
-
    
+
    
 
    
-[Note: this implies that sizeof(std::decimal::decimal32) == 4, sizeof(std::decimal::decimal64) == 8, and sizeof(std::decimal::decimal128) == 16.  --end note]
+Returns: The furthermost iterator i in the range
+[first, last)] such that
+for any iterator j in the range [first, i) the following corresponding
+conditions hold: !(value < *j) or comp(value, *j) == false.
 
    
 
    
 
 
 
 
+
+
 
    
-
    600. Decimal: Wrong parameters for wcstod* functions
    
-
    Section: TRDecimal 3.9 [trdec.types.cwchar] Status: TRDec
- Submitter: Daniel Krugler Date: 2006-05-28
    
-
    View all issues with TRDec status.
    
+
    578. purpose of hint to allocator::allocate()
    
+
    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.
    
 
    Discussion:
    
-
    
-Daniel writes:
-
    
-
    
-- 3.9.1 'Additions to <cwchar>' provides wrong 
-signatures to the wcstod32, wcstod64, and 
-wcstod128 functions ([the parameters have type pointer-to-] char instead of wchar_t).
-
    
+        
    
+
+The     description    of     the     allocator    member     function
+allocate()  requires  that  the hint  argument  be
+either 0 or a  value previously returned from allocate().
+Footnote 227 further suggests that  containers may pass the address of
+an adjacent element as this argument.
+
+        
    
+        
    
+
+I  believe  that  either  the  footnote  is  wrong  or  the  normative
+requirement that  the argument be  a value previously returned  from a
+call to  allocate() is wrong. The latter  is supported by
+the resolution  to issue 20-004 proposed in  c++std-lib-3736 by Nathan
+Myers. In addition,  the hint is an ordinary  void* and not the
+pointer  type returned  by  allocate(), with
+the  two  types potentially  being  incompatible  and the  requirement
+impossible to satisfy.
+
+        
    
+        
    
+
+See also c++std-lib-14323 for some  more context on where this came up
+(again).
+
+        
    
+    
+
+    
    Proposed resolution:
    
+        
    
+
+Remove  the requirement  in  20.6.1.1, p4  that  the hint  be a  value
+previously returned from allocate(). Specifically, change
+the paragraph as follows:
+
+        
    
+
    
+Requires: hint either 0 or previously obtained  from  member
+allocate  and  not  yet passed  to member  deallocate.
+The value hint may be used by an implementation to help improve performance
+223). [Note: The value hint may be used by an
+implementation to help improve performance. -- end note]
+
    
+
    
+[Footnote: 223)In a container member function, the address of an
+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
+ Submitter: Martin Sebor Date: 2006-06-22
    
+
    View all other issues in [string.io].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+        
    
+
+Section  and paragraph  numbers  in  this paper  are  relative to  the
+working draft document number N2009 from 4/21/2006.
+
+        
    
+
+        
    
+
+The  basic_string extractor  in 21.3.7.9,  p1  is clearly
+required  to  behave  as  a   formatted  input  function,  as  is  the
+std::getline() overload for string described in p7.
+
+        
    
+        
    
+
+However, the basic_string inserter described in p5 of the
+same section has no such requirement. This has implications on how the
+operator  responds  to  exceptions thrown  from  xsputn()
+(formatted  output functions are  required to  set badbit
+and swallow  the exception unless  badbit is also  set in
+exceptions(); the  string inserter doesn't  have any such
+requirement).
+
+        
    
+        
    
+
+I don't  see anything in the  spec for the string  inserter that would
+justify requiring  it to treat  exceptions differently from  all other
+similar operators. (If it did, I think it should be made this explicit
+by saying  that the  operator "does not  behave as a  formatted output
+function" as has been made customary by the adoption of the resolution
+of issue 60).
+
+        
    
+    
+
+    
    Proposed resolution:
    
+        
    
+
+I propose to change the Effects clause in 21.3.7.9, p5, as follows:
+
+        
    
+            
    
+        
    
+
+Effects: Begins by constructing a  sentry object k as if k
+were    constructed    by    typename    basic_ostream<charT,
+traits>::sentry   k   (os).    If  bool(k)   is
+true, Behaves  as a formatted  output function
+(27.6.2.5.1).   After constructing  a  sentry object,  if
+this  object returns true  when converted  to a  value of
+type   bool,   determines   padding   as   described   in
+22.2.2.2.2,  then inserts the  resulting sequence  of characters
+seq as if by calling os.rdbuf()->sputn(seq ,
+n),    where   n    is   the    larger   of
+os.width()   and   str.size();  then   calls
+os.width(0).  If  the  call  to sputn  fails,  calls
+os.setstate(ios_base::failbit).
+
+        
    
+            
    
+        
    
+
+This proposed  resilution assumes the  resolution of issue  394 (i.e.,
+that   all   formatted   output   functions  are   required   to   set
+ios_base::badbit  in response  to any  kind  of streambuf
+failure),   and   implicitly   assumes   that  a   return   value   of
+sputn(seq,  n)  other  than  n
+indicates a failure.
+
+        
    
+    
+
+
+
+
    
+
    589. Requirements on iterators of member template functions of containers
    
+
    Section: 23.1 [container.requirements] Status: WP
+ Submitter: Peter Dimov Date: 2006-08-02
    
+
    View other active issues in [container.requirements].
    
+
    View all other issues in [container.requirements].
    
+
    View all issues with WP status.
    
+
    Duplicate of: 536
    
+
    Discussion:
    
+
    
+There appears to be no requirements on the InputIterators used in sequences in 23.1.1 in
+terms of their value_type, and the requirements in 23.1.2 appear to be overly strict
+(requires InputIterator::value_type be the same type as the container's value_type).
+
    
+
+
+
    Proposed resolution:
    
+
    
+Change 23.1.1 p3:
+
    
+
+
    
+In Tables 82 and 83, X denotes a sequence class, a denotes a
+value of X, i and j denote iterators satisfying input
+iterator requirements and refer to elements implicitly
+convertible to value_type, [i, j) denotes a valid
+range, n denotes a value of X::size_type, p denotes a
+valid iterator to a, q denotes a valid dereferenceable
+iterator to a, [q1, q2) denotes a valid range in a,
+and t denotes a value of X::value_type.
+
    
+
+
    
+Change 23.1.2 p7:
+
    
+
+
    
+In Table 84, X is an associative container class, a is a value
+of X, a_uniq is a value of X when X supports
+unique keys, and a_eq is a value of X when X supports
+multiple keys, i and j satisfy input iterator requirements and
+refer to elements of implicitly convertible to
+value_type, [i, j) is a valid range, p is a valid
+iterator to a, q is a valid dereferenceable iterator to
+a, [q1, q2) is a valid range in a, t is a
+value of X::value_type, k is a value of X::key_type
+and c is a value of type X::key_compare.
+
    
+
+
+
+
    Rationale:
    
+
    
+Concepts will probably come in and rewrite this section anyway.  But just in case it is
+easy to fix this up as a safety net and as a clear statement of intent.
+
    
+
+
+
+
+
+
    
+
    593. __STDC_CONSTANT_MACROS
    
+
    Section: 18.3 [cstdint], TR1 8.22 [tr.c99.cstdint] Status: WP
+ Submitter: Walter Brown Date: 2006-08-28
    
+
    View all other issues in [cstdint].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+Clause 18.3 of the current Working Paper (N2009) deals with the new C++ headers
+<cstdint> and <stdint.h>.  These are of course based on the C99 header
+<stdint.h>, and were part of TR1.
+
    
+
+
    
+Per 18.3.1/1, these headers define a number of macros and function macros. 
+While the WP does not mention __STDC_CONSTANT_MACROS in this context, C99
+footnotes do mention __STDC_CONSTANT_MACROS.  Further, 18.3.1/2 states that "The
+header defines all ... macros the same as C99 subclause 7.18."
+
    
+
+
    
+Therefore, if I wish to have the above-referenced macros and function macros
+defined, must I #define __STDC_CONSTANT_MACROS before I #include <cstdint>, or
+does the C++ header define these macros/function macros unconditionally?
+
    
+
+
+
    Proposed resolution:
    
+
    
+To put this issue to rest for C++0X, I propose the following addition to 
+18.3.1/2 of the Working Paper N2009:
+
    
+
+
    
+[Note: The macros defined by <cstdint> are provided unconditionally: in
+particular, the symbols __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS
+(mentioned in C99 footnotes 219, 220, and 222) play no role in C++. --end note]
+
    
+
+
+
+
+
+
    
+
    598. Decimal: Conversion to integral should truncate, not round.
    
+
    Section: TRDecimal 3.2 [trdec.types.types] Status: TRDec
+ Submitter: Daniel Krugler Date: 2006-05-28
    
+
    View other active issues in [trdec.types.types].
    
+
    View all other issues in [trdec.types.types].
    
+
    View all issues with TRDec status.
    
+
    Discussion:
    
+
+
    
+In a private email, Daniel writes:
+
    
+
    
+
    
+I would like to 
+ask, what where the reason for the decision to 
+define the semantics of the integral conversion of the decimal types, namely
+
    
+
    "operator long long() const;
+
+     Returns: Returns the result of the 
+conversion of *this to the type long long, as if 
+performed by the expression llrounddXX(*this)."
+
    
+
    
+where XX stands for either 32, 64, or 128, 
+corresponding to the proper decimal type. The 
+exact meaning of llrounddXX is not given in that 
+paper, so I compared it to the corresponding 
+definition given in C99, 2nd edition (ISO 9899), which says in 7.12.9.7 p. 2:
+
    
+
    
+"The lround and llround functions round their 
+argument to the nearest integer value,
+rounding halfway cases away from zero, regardless 
+of the current rounding direction. [..]"
+
    
+
    
+Now considering the fact that integral conversion 
+of the usual floating-point types ("4.9 
+Floating-integral conversions") has truncation 
+semantic I wonder why this conversion behaviour 
+has not been transferred for the decimal types. 
+
    
+
    
+
    
+Robert comments:
+
    
+
    
+Also, there is a further error in the Returns: clause for converting decimal::decimal128 to long long.  It currently calls llroundd64, not llroundd128.
+
    
+
+
+
+
    Proposed resolution:
    
+
    
+Change the Returns: clause in 3.2.2.4 to:
+
    
+
    
+Returns: Returns the result of the conversion of *this to the type long long, as if performed by the expression llroundd32(*this) while the decimal rounding direction mode [3.5.2] FE_DEC_TOWARD_ZERO is in effect.
+
    
+
    
+Change the Returns: clause in 3.2.3.4 to:
+
    
+
    
+Returns: Returns the result of the conversion of *this to the type long long, as if performed by the expression llroundd64(*this) while the decimal rounding direction mode [3.5.2] FE_DEC_TOWARD_ZERO is in effect.
+
    
+
    
+Change the Returns: clause in 3.2.4.4 to:
+
    
+
    
+Returns: Returns the result of the conversion of *this to the type long long, as if performed by the expression llroundd64(*this) llroundd128(*this) while the decimal rounding direction mode [3.5.2] FE_DEC_TOWARD_ZERO is in effect.
+
    
+
+
+
+
+
+
+
    
+
    599. Decimal: Say "octets" instead of "bytes."
    
+
    Section: TRDecimal 3.1 [trdec.types.encodings] Status: TRDec
+ Submitter: Daniel Krugler Date: 2006-05-28
    
+
    View all issues with TRDec status.
    
+
    Discussion:
    
+
    
+Daniel writes in a private email:
+
    
+
+
    
+
    
+- 3.1 'Decimal type encodings' says in its note:
+
    
+
    "this implies that 
+sizeof(std::decimal::decimal32) == 4, 
+sizeof(std::decimal::decimal64) == 8, and 
+sizeof(std::decimal::decimal128) == 16."
+
    
+
    
+This is a wrong assertion, because the definition 
+of 'byte' in 1.7 'The C+ + memory model' of ISO 
+14882 (2nd edition) does not specify that a byte 
+must be necessarily 8 bits large, which would be 
+necessary to compare with the specified bit sizes 
+of the types decimal32, decimal64, and decimal128.
+
    
+
    
+
+
+
    Proposed resolution:
    
+
    
+Change 3.1 as follows:
+
    
+
    
+
    
+The three decimal encoding formats defined in IEEE-754R correspond to the three decimal floating types as follows:
+
    
+
      
+
    • 
+decimal32 is a decimal32 number, which is encoded in four consecutive bytes octets (32 bits)
+
      • 
+
    • 
+decimal64 is a decimal64 number, which is encoded in eight consecutive bytes octets (64 bits)
+
+
      • 
+
    • 
+decimal128 is a decimal128 number, which is encoded in 16 consecutive bytes octets (128 bits)
+
      • 
+
    
+
    
+[Note: this implies that sizeof(std::decimal::decimal32) == 4, sizeof(std::decimal::decimal64) == 8, and sizeof(std::decimal::decimal128) == 16.  --end note]
+
    
+
    
+
+
+
+
+
    
+
    600. Decimal: Wrong parameters for wcstod* functions
    
+
    Section: TRDecimal 3.9 [trdec.types.cwchar] Status: TRDec
+ Submitter: Daniel Krugler Date: 2006-05-28
    
+
    View all issues with TRDec status.
    
+
    Discussion:
    
+
    
+Daniel writes:
+
    
+
    
+- 3.9.1 'Additions to <cwchar>' provides wrong 
+signatures to the wcstod32, wcstod64, and 
+wcstod128 functions ([the parameters have type pointer-to-] char instead of wchar_t).
+
    
+
+
+
    Proposed resolution:
    
+
    
+Change "3.9.1 Additions to <cwchar> synopsis" to:
+
    
+
           namespace std {
+       namespace decimal {
+         // 3.9.2 wcstod functions:
+         decimal32  wcstod32  (const char wchar_t * nptr, char wchar_t ** endptr);
+         decimal64  wcstod64  (const char wchar_t * nptr, char wchar_t ** endptr);
+         decimal128 wcstod128 (const char wchar_t * nptr, char wchar_t ** endptr);
+       }
+       }
+
    
+
+
+
+
+
    
+
    601. Decimal: numeric_limits typos
    
+
    Section: TRDecimal 3.3 [trdec.types.limits] Status: TRDec
+ Submitter: Daniel Krugler Date: 2006-05-28
    
+
    View all issues with TRDec status.
    
+
    Discussion:
    
+
    
+Daniel writes in a private email:
+
    
+
+
    
+
    
+- 3.3 'Additions to header <limits>' contains two 
+errors in the specialisation of numeric_limits<decimal::decimal128>:
+
    
+
      
+
    1. The static member max() returns DEC128_MIN, this should be DEC128_MAX.
      2. 
+
    2. The static member digits is assigned to 384,
+this should be 34 (Probably mixed up with the
+max. exponent for decimal::decimal64).
      3. 
+
    
+
    
+
+
+
    Proposed resolution:
    
+
    
+In "3.3 Additions to header <limits>" change numeric_limits<decimal::decimal128> as follows:
+
    
+
            template<> class numeric_limits<decimal::decimal128> {
+          public:
+            static const bool is_specialized = true;
+
+            static decimal::decimal128 min() throw() { return DEC128_MIN; }
+            static decimal::decimal128 max() throw() { return DEC128_MIN; DEC128_MAX; }
+
+            static const int digits       = 384 34;
+            /* ... */
+
    
+
+
+
+
+
    
+
    602. Decimal: "generic floating type" not defined.
    
+
    Section: TRDecimal 3 [trdec.types] Status: TRDec
+ Submitter: Daniel Krugler Date: 2006-05-28
    
+
    View all other issues in [trdec.types].
    
+
    View all issues with TRDec status.
    
+
    Discussion:
    
+
    
+The document uses the term "generic floating types," but defines it nowhere.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Change the first paragraph of "3 Decimal floating-point types" as follows:
+
    
+
    
+This Technical Report introduces three decimal floating-point types, named
+decimal32, decimal64, and decimal128. The set of values of type decimal32 is a
+subset of the set of values of type decimal64; the set of values of the type
+decimal64 is a subset of the set of values of the type decimal128. Support for
+decimal128 is optional.  These types supplement the Standard C++ types
+float, double, and long double, which are
+collectively described as the basic floating types.
+
    
+
+
+
+
+
    
+
    603. Decimal: Trivially simplifying decimal classes.
    
+
    Section: TRDecimal 3 [trdec.types] Status: TRDec
+ Submitter: Martin Sebor Date: 2006-05-28
    
+
    View all other issues in [trdec.types].
    
+
    View all issues with TRDec status.
    
+
    Discussion:
    
+
    In c++std-lib-17198, Martin writes:
    
+
+
    
+Each of the three classes proposed in the paper (decimal32, decimal64,
+and decimal128) explicitly declares and specifies the semantics of its
+copy constructor, copy assignment operator, and destructor. Since the
+semantics of all three functions are identical to the trivial versions
+implicitly generated by the compiler in the absence of any declarations
+it is safe to drop them from the spec. This change would make the
+proposed classes consistent with other similar classes already in the
+standard (e.g., std::complex).
+
    
+
+
+
    Proposed resolution:
    
+
    
+Change "3.2.2 Class decimal32" as follows:
+
    
+
          namespace std {
+      namespace decimal {
+        class decimal32 {
+          public:
+            // 3.2.2.1 construct/copy/destroy:
+            decimal32();
+            decimal32(const decimal32 & d32);
+            decimal32 & operator=(const decimal32 & d32);
+            ~decimal32();
+            /* ... */
+
    
+
    
+Change "3.2.2.1 construct/copy/destroy" as follows:
+
    
+
            decimal32();
+
+    Effects: Constructs an object of type decimal32 with the value 0;
+
+        decimal32(const decimal32 & d32);
+        decimal32 & operator=(const decimal32 & d32);
+
+    Effects: Copies an object of type decimal32.
+
+        ~decimal32();
+
+    Effects: Destroys an object of type decimal32.
+
+
    
+
    
+Change "3.2.3 Class decimal64" as follows:
+
    
+
          namespace std {
+      namespace decimal {
+        class decimal64 {
+          public:
+            // 3.2.3.1 construct/copy/destroy:
+            decimal64();
+            decimal64(const decimal64 & d64);
+            decimal64 & operator=(const decimal64 & d64);
+            ~decimal64();
+            /* ... */
+
    
+
    
+Change "3.2.3.1 construct/copy/destroy" as follows:
+
    
+
            decimal64();
+
+    Effects: Constructs an object of type decimal64 with the value 0;
+
+        decimal64(const decimal64 & d64);
+        decimal64 & operator=(const decimal64 & d64);
+
+    Effects: Copies an object of type decimal64.
+
+        ~decimal64();
+
+    Effects: Destroys an object of type decimal64.
+
+
    
+
    
+Change "3.2.4 Class decimal128" as follows:
+
    
+
          namespace std {
+      namespace decimal {
+        class decimal128 {
+          public:
+            // 3.2.4.1 construct/copy/destroy:
+            decimal128();
+            decimal128(const decimal128 & d128);
+            decimal128 & operator=(const decimal128 & d128);
+            ~decimal128();
+            /* ... */
+
    
+
    
+Change "3.2.4.1 construct/copy/destroy" as follows:
+
    
+
            decimal128();
+
+    Effects: Constructs an object of type decimal128 with the value 0;
+
+        decimal128(const decimal128 & d128);
+        decimal128 & operator=(const decimal128 & d128);
+
+    Effects: Copies an object of type decimal128.
+
+        ~decimal128();
+
+    Effects: Destroys an object of type decimal128.
+
+
    
+
+
+
+
+
    
+
    604. Decimal: Storing a reference to a facet unsafe.
    
+
    Section: TRDecimal 3 [trdec.types] Status: TRDec
+ Submitter: Martin Sebor Date: 2006-05-28
    
+
    View all other issues in [trdec.types].
    
+
    View all issues with TRDec status.
    
+
    Discussion:
    
+
    
+In c++std-lib-17197, Martin writes:
+
    
+
    
+The extended_num_get and extended_num_put facets are designed
+to store a reference to a num_get or num_put facet which the
+extended facets delegate the parsing and formatting of types
+other than decimal. One form of the extended facet's ctor (the
+default ctor and the size_t overload) obtains the reference
+from the global C++ locale while the other form takes this
+reference as an argument.
+
    
+
    
+The problem with storing a reference to a facet in another
+object (as opposed to storing the locale object in which the
+facet is installed) is that doing so bypasses the reference
+counting mechanism designed to prevent a facet that is still
+being referenced (i.e., one that is still installed in some
+locale) from being destroyed when another locale that contains
+it is destroyed. Separating a facet reference from the locale
+it comes from van make it cumbersome (and in some cases might
+even make it impossible) for programs to prevent invalidating
+the reference. (The danger of this design is highlighted in
+the paper.)
+
    
+
    
+This problem could be easily avoided by having the extended
+facets store a copy of the locale from which they would extract
+the base facet either at construction time or when needed. To
+make it possible, the forms of ctors of the extended facets that
+take a reference to the base facet would need to be changed to
+take a locale argument instead.
+
    
+
+
+
    Proposed resolution:
    
+
    
+1. Change the extended_num_get synopsis in 3.10.2 as follows:
+
    
+
                extended_num_get(const std::num_get<charT, InputIterator> std::locale & b, size_t refs = 0);
+
+            /* ... */
+
+            // const std::num_get<charT, InputIterator> & base;        exposition only
+            // std::locale baseloc;                                    exposition only
+
    
+
    
+2. Change the description of the above constructor in 3.10.2.1:
+
    
+
                extended_num_get(const std::num_get<charT, InputIterator> std::locale & b, size_t refs = 0);
+
+
    
+
    
+
    
+Effects: Constructs an extended_num_get facet as if by:
+
    
+
           extended_num_get(const std::num_get<charT, InputIterator> std::locale & b, size_t refs = 0)
+                : facet(refs), baseloc(b)
+                { /* ... */ }
+
+
    
+
    
+Notes: Care must be taken by the implementation to ensure that the lifetime of the facet referenced by base exceeds that of the resulting extended_num_get facet.
+
    
+
    
+
    
+3. Change the Returns: clause for do_get(iter_type, iter_type, ios_base &, ios_base::iostate &, bool &) const, et al to
+
    
+
    
+Returns: base std::use_facet<std::num_get<charT, InputIterator> >(baseloc).get(in, end, str, err, val). 
+
    
+
    
+4. Change the extended_num_put synopsis in 3.10.3 as follows:
+
    
+
                extended_num_put(const std::num_put<charT, OutputIterator> std::locale & b, size_t refs = 0);
+
+            /* ... */
+
+            // const std::num_put<charT, OutputIterator> & base;       exposition only
+            // std::locale baseloc;                                    exposition only
+
    
+
    
+5. Change the description of the above constructor in 3.10.3.1:
+
    
+
                extended_num_put(const std::num_put<charT, OutputIterator> std::locale & b, size_t refs = 0);
+
    
+
    
+
    
+Effects: Constructs an extended_num_put facet as if by:
+
    
+
           extended_num_put(const std::num_put<charT, OutputIterator> std::locale & b, size_t refs = 0)
+                : facet(refs), baseloc(b)
+                { /* ... */ }
+
+
    
+
    
+Notes: Care must be taken by the implementation to ensure that the lifetime of the facet referenced by base exceeds that of the resulting extended_num_put facet.
+
    
+
    
+
    
+6. Change the Returns: clause for do_put(iter_type, ios_base &, char_type, bool &) const, et al to
+
    
+
    
+Returns: base std::use_facet<std::num_put<charT, OutputIterator> >(baseloc).put(s, f, fill, val). 
+
    
+
+
    [
+Redmond:  We would prefer to rename "extended" to "decimal".
+]
    
+
+
+
+
+
+
+
    
+
    605. Decimal: <decfloat.h> doesn't live here anymore.
    
+
    Section: TRDecimal 3.4 [trdec.types.cdecfloat] Status: TRDec
+ Submitter: Robert Klarer Date: 2006-10-17
    
+
    View all issues with TRDec status.
    
+
    Discussion:
    
+
    
+In Berlin, WG14 decided to drop the <decfloat.h> header. The
+contents of that header have been moved into <float.h>. For the
+sake of C compatibility, we should make corresponding changes.
+
    
+
+
+
    Proposed resolution:
    
+
    
+1. Change the heading of subclause 3.4, "Headers <cdecfloat> and <decfloat.h>" to "Additions to headers <cfloat> and <float.h>."
+
    
+
    
+2. Change the text of subclause 3.4 as follows:
+
    
+
    
+
    
+The standard C++ headers <cfloat> and <float.h> define characteristics of the floating-point types float, double, and long double.  Their contents remain unchanged by this Technical Report.
+
    
+
    
+Headers <cdecfloat> and <decfloat.h> define characteristics of the decimal floating-point types decimal32, decimal64, and decimal128.  As well, <decfloat.h> defines the convenience typedefs _Decimal32, _Decimal64, and _Decimal128, for compatibilty with the C programming language.
+
    
+
    
+The header <cfloat> is described in [tr.c99.cfloat].  The header <float.h>
+is described in [tr.c99.floath]. These headers are extended by this
+Technical Report to define characteristics of the decimal
+floating-point types decimal32, decimal64, and decimal128.  As well, <float.h> is extended to define the convenience typedefs _Decimal32, _Decimal64, and _Decimal128 for compatibility with the C programming language.
+
    
+
    
+
    
+3. Change the heading of subclause 3.4.1, "Header <cdecfloat> synopsis"  to "Additions to header <cfloat> synopsis."
+
    
+
    
+4. Change the heading of subclause 3.4.2, "Header <decfloat.h> synopsis" to "Additions to header <float.h> synopsis."
+
    
+
    
+5. Change the contents of 3.4.2 as follows:
+
    
+
          #include <cdecfloat>
+
+      // C-compatibility convenience typedefs:
+
+      typedef std::decimal::decimal32  _Decimal32;
+      typedef std::decimal::decimal64  _Decimal64;
+      typedef std::decimal::decimal128 _Decimal128;
+
    
+
+
+
+
+
+
    
+
    607. Concern about short seed vectors
    
+
    Section: 26.4.7.1 [rand.util.seedseq] Status: 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 WP status.
    
+
    Discussion:
    
+
    
+Short seed vectors of 32-bit quantities all result in different states. However
+this is not true of seed vectors of 16-bit (or smaller) quantities.  For example
+these two seeds
+
    
+
+
    unsigned short seed = {1, 2, 3};
+unsigned short seed = {1, 2, 3, 0};
+
    
+
+
    
+both pack to
+
    
+
+
    unsigned seed = {0x20001, 0x3};
+
    
+
+
    
+yielding the same state.
+
    
+
+
    
+See N2391 and
+N2423
+for some further discussion.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Adopt the proposed resolution in
+N2423.
+
    
+
+
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]
    
+
+
+
+
+
+
    
+
    608. Unclear seed_seq construction details
    
+
    Section: 26.4.7.1 [rand.util.seedseq] Status: 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 WP status.
    
+
    Discussion:
    
+
    
+In 26.4.7.1 [rand.util.seedseq] /6, the order of packing the inputs into b and the
+treatment of signed quantities is unclear. Better to spell it out.
+
    
+
+
    
+See N2391 and
+N2423
+for some further discussion.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Adopt the proposed resolution in
+N2423.
+
    
+
+
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]
    
+
+
+
+
+
+
    
+
    609. missing static const
    
+
    Section: 26.4.4.2 [rand.adapt.ibits], TR1 5.1 [tr.rand] Status: WP
+ Submitter: Walter E. Brown Date: 2006-11-02
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+In preparing N2111, an error on my part resulted in the omission of the
+following line from the template synopsis in the cited section:
+
    
+
+
    static const size_t word_size = w;
+
    
+
+
    
+(This same constant is found, for example, in 26.4.3.3 [rand.eng.sub].)
+
    
+
+
+
    Proposed resolution:
    
+
    
+Add the above declaration as the first line after the comment in [rand.adapt.ibits] p4:
+
    
+
+
    // engine characteristics
+static const size_t word_size = w;
+
    
+
+
    
+and accept my apologies for the oversight.
+
    
+
+
+
+
+
+
    
+
    610. Suggested non-normative note for C++0x
    
+
    Section: 20.5.15.2.1 [func.wrap.func.con], TR1 3.7.2.1 [tr.func.wrap.func.con] Status: WP
+ Submitter: Scott Meyers Date: 2006-11-02
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+My suggestion is that implementers of both tr1::function and its 
+official C++0x successor be explicitly encouraged (but not required) to 
+optimize for the cases mentioned above, i.e., function pointers and 
+small function objects.  They could do this by using a small internal 
+buffer akin to the buffer used by implementations of the small string 
+optimization.  (That would make this the small functor optimization -- 
+SFO :-})  The form of this encouragement could be a note in the standard 
+akin to footnote 214 of the current standard.
+
    
+
+
    
+Dave Abrahams notes:
+
    
+
+
    
+"shall not throw exceptions" should really be "nothing," both to be more
+grammatical and to be consistent with existing wording in the standard.
+
    
+
+
    
+Doug Gregor comments: I think this is a good idea. Currently, implementations of
+tr1::function are required to have non-throwing constructors and assignment
+operators when the target function object is a function pointer or a
+reference_wrapper. The common case, however, is for a tr1::function to store
+either an empty function object or a member pointer + an object pointer.
+
    
+
    
+The function implementation in the upcoming Boost 1.34.0 uses the
+"SFO", so that the function objects for typical bind expressions like
+
    
+
    bind(&X::f, this, _1, _2, _3)
+
    
+
+
    
+do not require heap allocation when stored in a boost::function. I
+believe Dinkumware's implementation also performs this optimization.
+
    
+
+
+
+
    Proposed resolution:
    
+
    
+Revise 20.5.14.2.1 p6 [func.wrap.func.con] to add a note as follows:
+
    
+
+
    
+
    
+Throws: shall not throw exceptions if f's target is a function
+pointer or a function object passed via reference_wrapper. Otherwise,
+may throw bad_alloc or any exception thrown by the copy constructor of
+the stored function object.
+
    
+
    
+Note: Implementations are encouraged to avoid the use of dynamically
+allocated memory for "small" function objects, e.g., where f's target
+is an object holding only a pointer or reference to an object and a member
+function pointer (a "bound member function").
+
    
+
    
+
+
+
+
+
+
    
+
    611. Standard library templates and incomplete types
    
+
    Section: 17.4.3.7 [res.on.functions] Status: WP
+ Submitter: Nicola Musatti Date: 2006-11-13
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+In the latest available draft standard 
+(N2134)
+§ 17.4.3.6 [res.on.functions] states:
+
    
+
+
    
+
    
+-1- In certain cases (replacement functions, handler functions, operations on
+types used to instantiate standard library template components), the C++
+Standard Library depends on components supplied by a C++ program. If these
+components do not meet their requirements, the Standard places no requirements
+on the implementation.
+
    
+
+
    
+-2- In particular, the effects are undefined in the following cases:
+
    
+
    
+[...]
+
    
+
      
+
    • if an incomplete type (3.9) is used as a template argument when
+instantiating a template component. 
      • 
+
    
+
    
+
+
    
+This is contradicted by § 20.6.6.2/2 [util.smartptr.shared] which
+states:
+
    
+
+
    
+
    
+[...]
+
    
+
+
    
+The template parameter T of shared_ptr may be an incomplete type.
+
    
+
    
+
+
+
    Proposed resolution:
    
+
    
+Modify the last bullet of § 17.4.3.6/2 [res.on.functions] to allow for
+exceptions:
+
    
+
+
    
+
      
+
    • if an incomplete type (3.9) is used as a template argument when
+instantiating a template component, unless specifically allowed for the
+component. 
      • 
+
    
+
    
+
+
+
+
+
+
+
    
+
    613. max_digits10 missing from numeric_limits
    
+
    Section: 18.2.1.5 [numeric.special] Status: WP
+ Submitter: Bo Persson Date: 2006-11-20
    
+
    View all other issues in [numeric.special].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+Section 18.2.1.5 [numeric.special] starts out by saying that "All members shall be provided 
+for all specializations."
+
    
+
    
+Then it goes on to show specializations for float and bool, where one member 
+is missing (max_digits10).
+
    
+
+
    
+Maarten Kronenburg adds:
+
    
+
+
    
+I agree, just adding the comment that the exact number of decimal digits
+is digits * ln(radix) / ln(10), where probably this real number is
+rounded downward for digits10, and rounded upward for max_digits10
+(when radix=10, then digits10=max_digits10).
+Why not add this exact definition also to the standard, so the user
+knows what these numbers exactly mean.
+
    
+
+
    
+Howard adds:
+
    
+
+
    
+For reference, here are the correct formulas from
+N1822:
+
    
+
+
    digits10 = floor((digits-1) * log10(2))
+max_digits10 = ceil((1 + digits) * log10(2))
+
    
+
+
    
+We are also missing a statement regarding for what specializations this member has meaning.
+
    
+
+
+
+
    Proposed resolution:
    
+
    
+Change and add after 18.2.1.2 [numeric.limits.members], p11:
+
    
+
+
    
+
    static const int max_digits10;
    
+
    
+
    
+-11- Number of base 10 digits required to ensure that values which
+differ by only one epsilon are always differentiated.
+
    
+
    
+-12- Meaningful for all floating point types.
+
    
+
    
+
    
+
+
    
+Change 18.2.1.5 [numeric.special], p2:
+
    
+
+
    template<> class numeric_limits<float> { 
+public: 
+  static const bool is_specialized = true; 
+  ...
+  static const int digits10 = 6;
+  static const int max_digits10 = 9;
+  ...
+
    
+
+
    
+Change 18.2.1.5 [numeric.special], p3:
+
    
+
+
    template<> class numeric_limits<bool> { 
+public: 
+  static const bool is_specialized = true; 
+  ...
+  static const int digits10 = 0;
+  static const int max_digits10 = 0;
+  ...
+
    
+
+
+
+
+
+
+
+
    
+
    616. missing 'typename' in ctype_byname
    
+
    Section: 22.2.1.2 [locale.ctype.byname] Status: WP
+ Submitter: Bo Persson Date: 2006-12-16
    
+
    View all other issues in [locale.ctype.byname].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+Section 22.2.1.2 defines the ctype_byname class template. It contains the 
+line
+
    
+
+
    typedef ctype<charT>::mask   mask;
+
    
+
+
+
+
    Proposed resolution:
    
+
    
+as this is a dependent type, it should obviously be
+
    
+
+
    typedef typename ctype<charT>::mask   mask;
+
    
+
+
+
+
+
+
    
+
    619. Longjmp wording problem
    
+
    Section: 18.8 [support.runtime] Status: WP
+ Submitter: Lawrence Crowl Date: 2007-01-12
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+The wording for longjmp is confusing.
+
    
+
    
+18.8 [support.runtime] -4- Other runtime support
+
    
+
    
+The function signature longjmp(jmp_buf jbuf, int val) has more restricted
+behavior in this International Standard.  If any automatic objects would
+be destroyed by a thrown exception transferring control to another
+(destination) point in the program, then a call to longjmp(jbuf, val) that
+the throw point that transfers control to the same (destination) point has
+undefined behavior.
+
    
+
    
+Someone at Google thinks that should say "then a call to longjmp(jbuf, val)
+*at* the throw point that transfers control".
+
    
+
    
+Bill Gibbons thinks it should say something like "If any automatic objects
+would be destroyed by an exception thrown at the point of the longjmp and
+caught only at the point of the setjmp, the behavior is undefined."
+
    
+
+
+
    Proposed resolution:
    
+
    
+In general, accept Bill Gibbons' recommendation,
+but add "call" to indicate that the undefined behavior
+comes from the dynamic call, not from its presence in the code.
+In 18.8 [support.runtime] paragraph 4, change
+
    
+
+
    
+The function signature longjmp(jmp_buf jbuf, int val) has more
+restricted behavior in this International Standard.  If any automatic
+objects would be destroyed by a thrown exception transferring control to another
+(destination) point in the program, then a call to longjmp(jbuf, val)
+that the throw point that transfers control to the same (destination) point has
+undefined behavior. A setjmp/longjmp call pair has
+undefined behavior if replacing the setjmp and longjmp by
+catch and throw would destroy any automatic objects.
+
    
+
+
+
+
+
+
    
+
    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:
    
-
    
-Change "3.9.1 Additions to <cwchar> synopsis" to:
-
    
-
           namespace std {
-       namespace decimal {
-         // 3.9.2 wcstod functions:
-         decimal32  wcstod32  (const char wchar_t * nptr, char wchar_t ** endptr);
-         decimal64  wcstod64  (const char wchar_t * nptr, char wchar_t ** endptr);
-         decimal128 wcstod128 (const char wchar_t * nptr, char wchar_t ** endptr);
-       }
-       }
-
    
+        
    
+
+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. ...
+
+        
    
+
 
 
 
 
 
    
-
    601. Decimal: numeric_limits typos
    
-
    Section: TRDecimal 3.3 [trdec.types.limits] Status: TRDec
- Submitter: Daniel Krugler Date: 2006-05-28
    
-
    View all issues with TRDec status.
    
+
    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.
+
+        
    
+
 
    
-Daniel writes in a private email:
+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.
+
    
 
-
    
 
    
-- 3.3 'Additions to header <limits>' contains two 
-errors in the specialisation of numeric_limits<decimal::decimal128>:
+And see more history in
+N0280.
 
    
-
      
-
    1. The static member max() returns DEC128_MIN, this should be DEC128_MAX.
      2. 
-
    2. The static member digits is assigned to 384,
-this should be 34 (Probably mixed up with the
-max. exponent for decimal::decimal64).
      3. 
-
    
-
    
 
+        
    
 
-
    Proposed resolution:
    
-
    
-In "3.3 Additions to header <limits>" change numeric_limits<decimal::decimal128> as follows:
-
    
-
            template<> class numeric_limits<decimal::decimal128> {
-          public:
-            static const bool is_specialized = true;
+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.
 
-            static decimal::decimal128 min() throw() { return DEC128_MIN; }
-            static decimal::decimal128 max() throw() { return DEC128_MIN; DEC128_MAX; }
+        
    
+        
    
 
-            static const int digits       = 384 34;
-            /* ... */
-
    
+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().
 
+        
    
 
+        
    
 
-
    
-
    602. Decimal: "generic floating type" not defined.
    
-
    Section: TRDecimal 3 [trdec.types] Status: TRDec
- Submitter: Daniel Krugler Date: 2006-05-28
    
-
    View all other issues in [trdec.types].
    
-
    View all issues with TRDec status.
    
-
    Discussion:
    
-
    
-The document uses the term "generic floating types," but defines it nowhere.
-
    
+Note that it's  far from clear that such leeway  is necessary in order
+to implement valarray efficiently.
+
+        
    
 
 
 
    Proposed resolution:
    
 
    
-Change the first paragraph of "3 Decimal floating-point types" as follows:
+Insert new paragraph into 26.5.2.2 [valarray.assign]:
 
    
-
    
-This Technical Report introduces three decimal floating-point types, named
-decimal32, decimal64, and decimal128. The set of values of type decimal32 is a
-subset of the set of values of type decimal64; the set of values of the type
-decimal64 is a subset of the set of values of the type decimal128. Support for
-decimal128 is optional.  These types supplement the Standard C++ types
-float, double, and long double, which are
-collectively described as the basic floating types.
-
    
+
+
    
+
    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.
+
    
+
    
+
    
+
 
 
 
 
 
    
-
    603. Decimal: Trivially simplifying decimal classes.
    
-
    Section: TRDecimal 3 [trdec.types] Status: TRDec
- Submitter: Martin Sebor Date: 2006-05-28
    
-
    View all other issues in [trdec.types].
    
-
    View all issues with TRDec status.
    
+
    628. Inconsistent definition of basic_regex constructor
    
+
    Section: 28.8 [re.regex] Status: WP
+ Submitter: Bo Persson Date: 2007-01-23
    
+
    View all other issues in [re.regex].
    
+
    View all issues with WP status.
    
 
    Discussion:
    
-
    In c++std-lib-17198, Martin writes:
    
-
-
    
-Each of the three classes proposed in the paper (decimal32, decimal64,
-and decimal128) explicitly declares and specifies the semantics of its
-copy constructor, copy assignment operator, and destructor. Since the
-semantics of all three functions are identical to the trivial versions
-implicitly generated by the compiler in the absence of any declarations
-it is safe to drop them from the spec. This change would make the
-proposed classes consistent with other similar classes already in the
-standard (e.g., std::complex).
-
    
+
    
+Section 28.8 [re.regex] lists a constructor
+
    
 
+
    template<class InputIterator>
+basic_regex(InputIterator first, InputIterator last,
+                       flag_type f = regex_constants::ECMAScript);
+
    
 
-
    Proposed resolution:
    
 
    
-Change "3.2.2 Class decimal32" as follows:
+However, in section 28.8.2 [re.regex.construct], this constructor takes a 
+pair of ForwardIterator.
 
    
-
          namespace std {
-      namespace decimal {
-        class decimal32 {
-          public:
-            // 3.2.2.1 construct/copy/destroy:
-            decimal32();
-            decimal32(const decimal32 & d32);
-            decimal32 & operator=(const decimal32 & d32);
-            ~decimal32();
-            /* ... */
-
    
+
+
+
    Proposed resolution:
    
 
    
-Change "3.2.2.1 construct/copy/destroy" as follows:
+Change 28.8.2 [re.regex.construct]:
 
    
-
            decimal32();
 
-    Effects: Constructs an object of type decimal32 with the value 0;
+
    template <class ForwardIterator InputIterator>
+  basic_regex(ForwardIterator InputIterator first, ForwardIterator InputIterator last, 
+              flag_type f = regex_constants::ECMAScript);
+
    
 
-        decimal32(const decimal32 & d32);
-        decimal32 & operator=(const decimal32 & d32);
 
-    Effects: Copies an object of type decimal32.
 
-        ~decimal32();
 
-    Effects: Destroys an object of type decimal32.
 
-
    
+
+
    
+
    634. allocator.address() doesn't work for types overloading operator&
    
+
    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.
    
+
    Duplicate of: 350
    
+
    Discussion:
    
+
 
    
-Change "3.2.3 Class decimal64" as follows:
+20.6.5.1 [allocator.members] says:
 
    
-
          namespace std {
-      namespace decimal {
-        class decimal64 {
-          public:
-            // 3.2.3.1 construct/copy/destroy:
-            decimal64();
-            decimal64(const decimal64 & d64);
-            decimal64 & operator=(const decimal64 & d64);
-            ~decimal64();
-            /* ... */
-
    
+
    
+
    pointer address(reference x) const;
    
+
    
 
    
-Change "3.2.3.1 construct/copy/destroy" as follows:
+-1- Returns: &x.
 
    
-
            decimal64();
+
    
+
    
 
-    Effects: Constructs an object of type decimal64 with the value 0;
+
    
+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
+that we should disallow overloading operator& to return something other
+than the address of *this.
+
    
 
-        decimal64(const decimal64 & d64);
-        decimal64 & operator=(const decimal64 & d64);
+
    
+An example of when you want to overload operator& to return something
+other than the object's address is proxy references such as vector<bool>
+(or its replacement, currently code-named bit_vector).  Taking the address of
+such a proxy reference should logically yield a proxy pointer, which when dereferenced,
+yields a copy of the original proxy reference again.
+
    
 
-    Effects: Copies an object of type decimal64.
+
    
+On the other hand, some code truly needs the address of an object, and not a proxy
+(typically for determining the identity of an object compared to a reference object).
+boost has long recognized this dilemma and solved it with 
+boost::addressof.
+It appears to me that this would be useful functionality for the default allocator.  Adopting
+this definition for allocator::address would free the standard of requiring
+anything special from types which overload operator&.  Issue 580
+is expected to make use of allocator::address mandatory for containers.
+
    
 
-        ~decimal64();
 
-    Effects: Destroys an object of type decimal64.
 
-
    +

    Proposed resolution:

    -Change "3.2.4 Class decimal128" as follows: +Change 20.6.5.1 [allocator.members]:

    -
          namespace std {
-      namespace decimal {
-        class decimal128 {
-          public:
-            // 3.2.4.1 construct/copy/destroy:
-            decimal128();
-            decimal128(const decimal128 & d128);
-            decimal128 & operator=(const decimal128 & d128);
-            ~decimal128();
-            /* ... */
-
    + +
    +
    pointer address(reference x) const;
    +
    +

    +-1- Returns: &x. The actual address of object referenced by x, +even in the presence of an overloaded operator&. +

    +
    + +
    const_pointer address(address(const_reference x) const;
    +

    -Change "3.2.4.1 construct/copy/destroy" as follows: +-2- Returns: &x. The actual address of object referenced by x, +even in the presence of an overloaded operator&.

    -
            decimal128();
+
    +
    - Effects: Constructs an object of type decimal128 with the value 0; +

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

    - decimal128(const decimal128 & d128); - decimal128 & operator=(const decimal128 & d128); - Effects: Copies an object of type decimal128. +

    [ +Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which +was subsequently split out into a separate paper N2436 for the purposes of voting. +The resolution in N2436 addresses this issue. The LWG voted to accelerate this +issue to Ready status to be voted into the WP at Kona. +]

    - ~decimal128(); - Effects: Destroys an object of type decimal128. -
    -

    604. Decimal: Storing a reference to a facet unsafe.

    -

    Section: TRDecimal 3 [trdec.types] Status: TRDec - Submitter: Martin Sebor Date: 2006-05-28

    -

    View all other issues in [trdec.types].

    -

    View all issues with TRDec status.

    +

    640. 27.6.2.5.2 does not handle (unsigned) long long

    +

    Section: 27.6.2.6.2 [ostream.inserters.arithmetic] Status: WP + Submitter: Daniel Krügler Date: 2007-02-17

    +

    View all other issues in [ostream.inserters.arithmetic].

    +

    View all issues with WP status.

    Discussion:

    -In c++std-lib-17197, Martin writes: +The arithmetic inserters are described in 27.6.2.6.2 [ostream.inserters.arithmetic]. +Although the section starts with a listing of the inserters including +the new ones:

    -

    -The extended_num_get and extended_num_put facets are designed -to store a reference to a num_get or num_put facet which the -extended facets delegate the parsing and formatting of types -other than decimal. One form of the extended facet's ctor (the -default ctor and the size_t overload) obtains the reference -from the global C++ locale while the other form takes this -reference as an argument. -

    -

    -The problem with storing a reference to a facet in another -object (as opposed to storing the locale object in which the -facet is installed) is that doing so bypasses the reference -counting mechanism designed to prevent a facet that is still -being referenced (i.e., one that is still installed in some -locale) from being destroyed when another locale that contains -it is destroyed. Separating a facet reference from the locale -it comes from van make it cumbersome (and in some cases might -even make it impossible) for programs to prevent invalidating -the reference. (The danger of this design is highlighted in -the paper.) -

    -

    -This problem could be easily avoided by having the extended -facets store a copy of the locale from which they would extract -the base facet either at construction time or when needed. To -make it possible, the forms of ctors of the extended facets that -take a reference to the base facet would need to be changed to -take a locale argument instead. -

    +
    operator<<(long long val );
+operator<<(unsigned long long val );
+
    -

    Proposed resolution:

    -1. Change the extended_num_get synopsis in 3.10.2 as follows: +the text in paragraph 1, which describes the corresponding effects +of the inserters, depending on the actual type of val, does not +handle the types long long and unsigned long long.

    -
                extended_num_get(const std::num_get<charT, InputIterator> std::locale & b, size_t refs = 0);
 
-            /* ... */
+
    [
+Alisdair: In addition to the (unsigned) long long problem, that whole paragraph
+misses any reference to extended integral types supplied by the
+implementation - one of the additions by core a couple of working papers
+back.
+]
    
 
-            // const std::num_get<charT, InputIterator> & base;        exposition only
-            // std::locale baseloc;                                    exposition only
-
    + + + +

    Proposed resolution:

    -2. Change the description of the above constructor in 3.10.2.1: +In 27.6.2.6.2 [ostream.inserters.arithmetic]/1 change the third sentence

    -
                extended_num_get(const std::num_get<charT, InputIterator> std::locale & b, size_t refs = 0);
 
-
    +When val is of type bool, long, unsigned +long, long long, unsigned long long, double, +long double, or const void*, the formatting conversion +occurs as if it performed the following code fragment: +
    + + + + + +
    +

    643. Impossible "as if" clauses

    +

    Section: 27.8.1.1 [filebuf], 22.2.2.2.2 [facet.num.put.virtuals] Status: WP + Submitter: Daniel Krügler Date: 2007-02-20

    +

    View all issues with WP status.

    +

    Discussion:

    -Effects: Constructs an extended_num_get facet as if by: +The current standard 14882:2003(E) as well as N2134 have the +following +defects:

    -
           extended_num_get(const std::num_get<charT, InputIterator> std::locale & b, size_t refs = 0)
-                : facet(refs), baseloc(b)
-                { /* ... */ }
 
-

    -Notes: Care must be taken by the implementation to ensure that the lifetime of the facet referenced by base exceeds that of the resulting extended_num_get facet. +27.8.1.1 [filebuf]/5 says: +

    + +
    +

    +In order to support file I/O and multibyte/wide character conversion, conversions are performed using members of a +facet, referred to as a_codecvt in following sections, obtained "as if" by

    +
    codecvt<charT,char,typename traits::state_type> a_codecvt =
+  use_facet<codecvt<charT,char,typename traits::state_type> >(getloc());
+
    +

    -3. Change the Returns: clause for do_get(iter_type, iter_type, ios_base &, ios_base::iostate &, bool &) const, et al to +use_facet returns a const facet reference and no facet is +copyconstructible, so the codecvt construction should fail to compile.

    -

    -Returns: base std::use_facet<std::num_get<charT, InputIterator> >(baseloc).get(in, end, str, err, val). -

    +

    -4. Change the extended_num_put synopsis in 3.10.3 as follows: +A similar issue arises in 22.2.2.2.2 [facet.num.put.virtuals]/15 for num_punct.

    -
                extended_num_put(const std::num_put<charT, OutputIterator> std::locale & b, size_t refs = 0);
 
-            /* ... */
 
-            // const std::num_put<charT, OutputIterator> & base;       exposition only
-            // std::locale baseloc;                                    exposition only
-
    +

    Proposed resolution:

    -5. Change the description of the above constructor in 3.10.3.1: +In 27.8.1.1 [filebuf]/5 change the "as if" code

    -
                extended_num_put(const std::num_put<charT, OutputIterator> std::locale & b, size_t refs = 0);
-
    -
    + +
    const codecvt<charT,char,typename traits::state_type>& a_codecvt =
+  use_facet<codecvt<charT,char,typename traits::state_type> >(getloc());
+
    +

    -Effects: Constructs an extended_num_put facet as if by: +In 22.2.2.2.2 [facet.num.put.virtuals]/15 (This is para 5 in N2134) change

    -
           extended_num_put(const std::num_put<charT, OutputIterator> std::locale & b, size_t refs = 0)
-                : facet(refs), baseloc(b)
-                { /* ... */ }
 
-
    +

    -Notes: Care must be taken by the implementation to ensure that the lifetime of the facet referenced by base exceeds that of the resulting extended_num_put facet. +A local variable punct is initialized via

    +
    const numpunct<charT>& punct = use_facet< numpunct<charT> >(str.getloc() );
+
    +

    -6. Change the Returns: clause for do_put(iter_type, ios_base &, char_type, bool &) const, et al to +(Please note also the additional provided trailing semicolon)

    -

    -Returns: base std::use_facet<std::num_put<charT, OutputIterator> >(baseloc).put(s, f, fill, val). -

    - -

    [ -Redmond: We would prefer to rename "extended" to "decimal". -]

    @@ -22727,105 +24586,115 @@ Redmond: We would prefer to rename "extended" to "decimal".
    -

    605. Decimal: <decfloat.h> doesn't live here anymore.

    -

    Section: TRDecimal 3.4 [trdec.types.cdecfloat] Status: TRDec - Submitter: Robert Klarer Date: 2006-10-17

    -

    View all issues with TRDec status.

    +

    644. Possible typos in 'function' description

    +

    Section: X [func.wrap.func.undef] Status: Pending WP + Submitter: Bo Persson Date: 2007-02-25

    Discussion:

    -In Berlin, WG14 decided to drop the <decfloat.h> header. The -contents of that header have been moved into <float.h>. For the -sake of C compatibility, we should make corresponding changes. +X [func.wrap.func.undef] +

    +

    +The note in paragraph 2 refers to 'undefined void operators', while the +section declares a pair of operators returning bool.

    Proposed resolution:

    -1. Change the heading of subclause 3.4, "Headers <cdecfloat> and <decfloat.h>" to "Additions to headers <cfloat> and <float.h>." -

    -

    -2. Change the text of subclause 3.4 as follows: -

    -
    -

    -The standard C++ headers <cfloat> and <float.h> define characteristics of the floating-point types float, double, and long double. Their contents remain unchanged by this Technical Report. -

    -

    -Headers <cdecfloat> and <decfloat.h> define characteristics of the decimal floating-point types decimal32, decimal64, and decimal128. As well, <decfloat.h> defines the convenience typedefs _Decimal32, _Decimal64, and _Decimal128, for compatibilty with the C programming language. -

    -

    -The header <cfloat> is described in [tr.c99.cfloat]. The header <float.h> -is described in [tr.c99.floath]. These headers are extended by this -Technical Report to define characteristics of the decimal -floating-point types decimal32, decimal64, and decimal128. As well, <float.h> is extended to define the convenience typedefs _Decimal32, _Decimal64, and _Decimal128 for compatibility with the C programming language. -

    -
    -

    -3. Change the heading of subclause 3.4.1, "Header <cdecfloat> synopsis" to "Additions to header <cfloat> synopsis." -

    -

    -4. Change the heading of subclause 3.4.2, "Header <decfloat.h> synopsis" to "Additions to header <float.h> synopsis." +Change 20.5.15.2 [func.wrap.func]

    + +
    ...
+private:
+   // X [func.wrap.func.undef], undefined operators:
+   template<class Function2> bool void operator==(const function<Function2>&);
+   template<class Function2> bool void operator!=(const function<Function2>&);
+};
+
    +

    -5. Change the contents of 3.4.2 as follows: +Change X [func.wrap.func.undef]

    -
          #include <cdecfloat>
 
-      // C-compatibility convenience typedefs:
+
    template<class Function2> bool void operator==(const function<Function2>&);
+template<class Function2> bool void operator!=(const function<Function2>&);
+
    
 
-      typedef std::decimal::decimal32  _Decimal32;
-      typedef std::decimal::decimal64  _Decimal64;
-      typedef std::decimal::decimal128 _Decimal128;
-
    + + + + +
    +

    646. const incorrect match_result members

    +

    Section: 28.10.4 [re.results.form] Status: WP + Submitter: Daniel Krügler Date: 2007-02-26

    +

    View all issues with WP status.

    +

    Discussion:

    +

    +28.10.4 [re.results.form] (root and para 3) in N2134 defines the two function template +members format as non-const functions, although they are declared +as const in 28.10 [re.results]/3. +

    + + +

    Proposed resolution:

    +

    +Add the missing const specifier to both format overloads described +in section 28.10.4 [re.results.form]. +

    -

    607. Concern about short seed vectors

    -

    Section: 26.4.7.1 [rand.util.seedseq] Status: Pending WP - Submitter: Charles Karney Date: 2006-10-26

    -

    View all other issues in [rand.util.seedseq].

    -

    View all issues with Pending WP status.

    +

    650. regex_token_iterator and const correctness

    +

    Section: 28.12.2 [re.tokiter] Status: WP + Submitter: Daniel Krügler Date: 2007-03-05

    +

    View all other issues in [re.tokiter].

    +

    View all issues with WP status.

    Discussion:

    -Short seed vectors of 32-bit quantities all result in different states. However -this is not true of seed vectors of 16-bit (or smaller) quantities. For example -these two seeds +Both the class definition of regex_token_iterator (28.12.2 +[re.tokiter]/6) and the latter member specifications (28.12.2.2 +[re.tokiter.comp]/1+2) declare both comparison operators as +non-const functions. Furtheron, both dereference operators are +unexpectedly also declared as non-const in 28.12.2 [re.tokiter]/6 +as well as in (28.12.2.3 [re.tokiter.deref]/1+2).

    -
    unsigned short seed = {1, 2, 3};
-unsigned short seed = {1, 2, 3, 0};
-
    +

    Proposed resolution:

    -both pack to +1) In (28.12.2 [re.tokiter]/6) change the current declarations

    -
    unsigned seed = {0x20001, 0x3};
+
    bool operator==(const regex_token_iterator&) const;
+bool operator!=(const regex_token_iterator&) const;
+const value_type& operator*() const;
+const value_type* operator->() const;
 
    
 
 
    
-yielding the same state.
-
    
-
-
    
-See N2391 and
-N2423
-for some further discussion.
+2) In 28.12.2.2 [re.tokiter.comp] change the following declarations
 
    
 
+
    bool operator==(const regex_token_iterator& right) const;
+bool operator!=(const regex_token_iterator& right) const;
+
    
 
-
    Proposed resolution:
    
 
    
-Adopt the proposed resolution in
-N2423.
+3) In 28.12.2.3 [re.tokiter.deref] change the following declarations
 
    
 
+
    const value_type& operator*() const;
+const value_type* operator->() const;
+
    
+
 
 
    [
-Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
+is to adopt the proposed wording in this issue).
 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
 ]
    
 
@@ -22834,33 +24703,47 @@ 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
- Submitter: Charles Karney Date: 2006-10-26
    
-
    View all other issues in [rand.util.seedseq].
    
-
    View all issues with Pending WP status.
    
+
    651. Missing preconditions for regex_token_iterator c'tors
    
+
    Section: 28.12.2.1 [re.tokiter.cnstr] Status: WP
+ Submitter: Daniel Krügler Date: 2007-03-05
    
+
    View all other issues in [re.tokiter.cnstr].
    
+
    View all issues with WP status.
    
 
    Discussion:
    
 
    
-In 26.4.7.1 [rand.util.seedseq] /6, the order of packing the inputs into b and the
-treatment of signed quantities is unclear. Better to spell it out.
+The text provided in 28.12.2.1 [re.tokiter.cnstr]/2+3 describes
+the effects of the three non-default constructors of class
+template regex_token_iterator but is does not clarify which values
+are legal values for submatch/submatches. This becomes
+an issue, if one takes 28.12.2 [re.tokiter]/9 into account, which explains
+the notion of a "current match" by saying:
 
    
 
+
    
+The current match is (*position).prefix() if subs[N]
+== -1, or (*position)[subs[N]] for any other value of
+subs[N].
+
    
+
 
    
-See N2391 and
-N2423
-for some further discussion.
+It's not clear to me, whether other negative values except -1
+are legal arguments or not - it seems they are not.
 
    
 
 
 
    Proposed resolution:
    
 
    
-Adopt the proposed resolution in
-N2423.
+Add the following precondition paragraph just before the current
+28.12.2.1 [re.tokiter.cnstr]/2:
 
    
 
+
    
+Requires: Each of the initialization values of subs must be >= -1.
+
    
+
 
 
    [
-Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
+is to adopt the proposed wording in this issue).
 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
 ]
    
 
@@ -22869,819 +24752,1035 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
 
    
-
    609. missing static const
    
-
    Section: 26.4.4.2 [rand.adapt.ibits], TR1 5.1 [tr.rand] Status: WP
- Submitter: Walter E. Brown Date: 2006-11-02
    
+
    652. regex_iterator and const correctness
    
+
    Section: 28.12.1 [re.regiter] Status: WP
+ Submitter: Daniel Krügler Date: 2007-03-05
    
 
    View all issues with WP status.
    
 
    Discussion:
    
-
    
-In preparing N2111, an error on my part resulted in the omission of the
-following line from the template synopsis in the cited section:
+
    Both the class definition of regex_iterator (28.12.1 [re.regiter]/1)
+and the latter member specification (28.12.1.2 [re.regiter.comp]/1+2)
+declare both comparison operators as
+non-const functions. Furtheron, both dereference operators are
+unexpectedly also declared as non-const in 28.12.1 [re.regiter]/1
+as well as in (28.12.1.3 [re.regiter.deref]/1+2).
 
    
 
-
    static const size_t word_size = w;
-
    
 
+
    Proposed resolution:
    
 
    
-(This same constant is found, for example, in 26.4.3.3 [rand.eng.sub].)
+1) In (28.12.1 [re.regiter]/1) change the current declarations
 
    
 
+
    bool operator==(const regex_iterator&) const;
+bool operator!=(const regex_iterator&) const;
+const value_type& operator*() const;
+const value_type* operator->() const;
+
    
 
-
    Proposed resolution:
    
 
    
-Add the above declaration as the first line after the comment in [rand.adapt.ibits] p4:
+2) In 28.12.1.3 [re.regiter.deref] change the following declarations
 
    
 
-
    // engine characteristics
-static const size_t word_size = w;
+
    const value_type& operator*() const;
+const value_type* operator->() const;
 
    
 
 
    
-and accept my apologies for the oversight.
+3) In 28.12.1.2 [re.regiter.comp] change the following declarations
 
    
 
+
    bool operator==(const regex_iterator& right) const;
+bool operator!=(const regex_iterator& right) const;
+
    
+
+
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
+is to adopt the proposed wording in this issue).
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]
    
+
 
 
 
 
 
    
-
    610. Suggested non-normative note for C++0x
    
-
    Section: 20.5.15.2.1 [func.wrap.func.con], TR1 3.7.2.1 [tr.func.wrap.func.con] Status: WP
- Submitter: Scott Meyers Date: 2006-11-02
    
+
    654. Missing IO roundtrip for random number engines
    
+
    Section: 26.4.1.3 [rand.req.eng] Status: WP
+ Submitter: Daniel Krügler Date: 2007-03-08
    
+
    View all other issues in [rand.req.eng].
    
 
    View all issues with WP status.
    
 
    Discussion:
    
 
    
-My suggestion is that implementers of both tr1::function and its 
-official C++0x successor be explicitly encouraged (but not required) to 
-optimize for the cases mentioned above, i.e., function pointers and 
-small function objects.  They could do this by using a small internal 
-buffer akin to the buffer used by implementations of the small string 
-optimization.  (That would make this the small functor optimization -- 
-SFO :-})  The form of this encouragement could be a note in the standard 
-akin to footnote 214 of the current standard.
+Table 98 and para 5 in 26.4.1.3 [rand.req.eng] specify
+the IO insertion and extraction semantic of random
+number engines. It can be shown, v.i., that the specification
+of the extractor cannot guarantee to fulfill the requirement
+from para 5:
 
    
 
-
    
-Dave Abrahams notes:
-
    
+
    
+If a textual representation written via os << x was
+subsequently read via is >> v, then x == v provided that
+there have been no intervening invocations of x or of v.
+
    
 
 
    
-"shall not throw exceptions" should really be "nothing," both to be more
-grammatical and to be consistent with existing wording in the standard.
+The problem is, that the extraction process described in
+table 98 misses to specify that it will initially set the
+if.fmtflags to ios_base::dec, see table 104:
 
    
 
+
    
+dec: converts integer input or generates integer output
+in decimal base
+
    
+
 
    
-Doug Gregor comments: I think this is a good idea. Currently, implementations of
-tr1::function are required to have non-throwing constructors and assignment
-operators when the target function object is a function pointer or a
-reference_wrapper. The common case, however, is for a tr1::function to store
-either an empty function object or a member pointer + an object pointer.
+Proof: The following small program demonstrates the violation
+of requirements (exception safety not fulfilled):
 
    
+
+
    #include <cassert>
+#include <ostream>
+#include <iostream>
+#include <iomanip>
+#include <sstream>
+
+class RanNumEngine {
+  int state;
+public:
+  RanNumEngine() : state(42) {}
+
+  bool operator==(RanNumEngine other) const {
+	  return state == other.state;
+  }
+
+  template <typename Ch, typename Tr>
+  friend std::basic_ostream<Ch, Tr>& operator<<(std::basic_ostream<Ch, Tr>& os, RanNumEngine engine) {
+	Ch old = os.fill(os.widen(' ')); // Sets space character
+	std::ios_base::fmtflags f = os.flags();
+	os << std::dec << std::left << engine.state; // Adds ios_base::dec|ios_base::left
+	os.fill(old); // Undo
+	os.flags(f);
+	return os;
+  }
+
+  template <typename Ch, typename Tr>
+  friend std::basic_istream<Ch, Tr>& operator>>(std::basic_istream<Ch, Tr>& is, RanNumEngine& engine) {
+       // Uncomment only for the fix.
+
+	//std::ios_base::fmtflags f = is.flags();
+	//is >> std::dec;
+	is >> engine.state;
+	//is.flags(f);
+	return is;
+  }
+};
+
+int main() {
+	std::stringstream s;
+	s << std::setfill('#'); // No problem
+        s << std::oct; // Yikes!
+        // Here starts para 5 requirements:
+	RanNumEngine x;
+	s << x;
+	RanNumEngine v;
+	s >> v;
+	assert(x == v); // Fails: 42 == 34
+}
+
    
+
 
    
-The function implementation in the upcoming Boost 1.34.0 uses the
-"SFO", so that the function objects for typical bind expressions like
+A second, minor issue seems to be, that the insertion
+description from table 98 unnecessarily requires the
+addition of ios_base::fixed (which only influences floating-point
+numbers). Its not entirely clear to me whether the proposed
+standard does require that the state of random number engines
+is stored in integral types or not, but I have the impression
+that this is the indent, see e.g. p. 3
 
    
-
    bind(&X::f, this, _1, _2, _3)
-
    
+
+
    
+The specification of each random number engine defines the
+size of its state in multiples of the size of its result_type.
+
    
 
 
    
-do not require heap allocation when stored in a boost::function. I
-believe Dinkumware's implementation also performs this optimization.
+If other types than integrals are supported, then I wonder why
+no requirements are specified for the precision of the stream.
 
    
 
+
    
+See N2391 and
+N2423
+for some further discussion.
+
    
 
 
 
    Proposed resolution:
    
 
    
-Revise 20.5.14.2.1 p6 [func.wrap.func.con] to add a note as follows:
+Adopt the proposed resolution in
+N2423.
 
    
 
-
    
-
    
-Throws: shall not throw exceptions if f's target is a function
-pointer or a function object passed via reference_wrapper. Otherwise,
-may throw bad_alloc or any exception thrown by the copy constructor of
-the stored function object.
-
    
-
    
-Note: Implementations are encouraged to avoid the use of dynamically
-allocated memory for "small" function objects, e.g., where f's target
-is an object holding only a pointer or reference to an object and a member
-function pointer (a "bound member function").
-
    
-
    
+
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]
    
 
 
 
 
 
 
    
-
    611. Standard library templates and incomplete types
    
-
    Section: 17.4.3.6 [res.on.functions] Status: WP
- Submitter: Nicola Musatti Date: 2006-11-13
    
+
    655. Signature of generate_canonical not useful
    
+
    Section: 26.4.7.2 [rand.util.canonical] Status: WP
+ Submitter: Daniel Krügler Date: 2007-03-08
    
+
    View all other issues in [rand.util.canonical].
    
 
    View all issues with WP status.
    
 
    Discussion:
    
 
    
-In the latest available draft standard 
-(N2134)
-§ 17.4.3.6 [res.on.functions] states:
-
    
-
-
    
-
    
--1- In certain cases (replacement functions, handler functions, operations on
-types used to instantiate standard library template components), the C++
-Standard Library depends on components supplied by a C++ program. If these
-components do not meet their requirements, the Standard places no requirements
-on the implementation.
-
    
-
-
    
--2- In particular, the effects are undefined in the following cases:
-
    
-
    
-[...]
+In 26.4.2 [rand.synopsis] we have the declaration
 
    
-
      
-
    • if an incomplete type (3.9) is used as a template argument when
-instantiating a template component. 
      • 
-
    
-
    
 
-
    
-This is contradicted by § 20.6.6.2/2 [util.smartptr.shared] which
-states:
-
    
+
    template<class RealType, class UniformRandomNumberGenerator,
+  size_t bits>
+result_type generate_canonical(UniformRandomNumberGenerator& g);
+
    
 
-
    
 
    
-[...]
+Besides the "result_type" issue (already recognized by Bo Persson
+at Sun, 11 Feb 2007 05:26:47 GMT in this group) it's clear, that
+the template parameter order is not reasonably choosen: Obviously
+one always needs to specify all three parameters, although usually
+only two are required, namely the result type RealType and the
+wanted bits, because UniformRandomNumberGenerator can usually
+be deduced.
 
    
 
 
    
-The template parameter T of shared_ptr may be an incomplete type.
+See N2391 and
+N2423
+for some further discussion.
 
    
-
    
 
 
 
    Proposed resolution:
    
 
    
-Modify the last bullet of § 17.4.3.6/2 [res.on.functions] to allow for
-exceptions:
+Adopt the proposed resolution in
+N2423.
 
    
 
-
    
-
      
-
    • if an incomplete type (3.9) is used as a template argument when
-instantiating a template component, unless specifically allowed for the
-component. 
      • 
-
    
-
    
 
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]
    
 
 
 
 
 
 
    
-
    613. max_digits10 missing from numeric_limits
    
-
    Section: 18.2.1.5 [numeric.special] Status: WP
- Submitter: Bo Persson Date: 2006-11-20
    
-
    View all other issues in [numeric.special].
    
+
    660. Missing Bitwise Operations
    
+
    Section: 20.5 [function.objects] Status: WP
+ Submitter: Beman Dawes Date: 2007-04-02
    
+
    View all other issues in [function.objects].
    
 
    View all issues with WP status.
    
 
    Discussion:
    
-
    
-Section 18.2.1.5 [numeric.special] starts out by saying that "All members shall be provided 
-for all specializations."
-
    
-
    
-Then it goes on to show specializations for float and bool, where one member 
-is missing (max_digits10).
-
    
+
    Section 20.5 [function.objects] provides function
+objects for some unary and binary 
+operations, but others are missing. In a LWG reflector discussion, beginning 
+with c++std-lib-18078, pros and cons of adding some of the missing operations 
+were discussed. Bjarne Stroustrup commented "Why standardize what isn't used? 
+Yes, I see the chicken and egg problems here, but it would be nice to see a 
+couple of genuine uses before making additions."
    
+
    A number of libraries, including Rogue Wave, GNU, Adobe ASL, and Boost, have 
+already added these functions, either publicly or for internal use. For example, 
+Doug Gregor commented: "Boost will also add ... (|, &, ^) in 1.35.0, because we 
+need those function
+objects to represent various parallel 
+collective operations (reductions, prefix reductions, etc.) in the new Message 
+Passing Interface (MPI) library."
    
+
    Because the bitwise operators have the strongest use cases, the proposed 
+resolution is limited to them.
    
 
-
    
-Maarten Kronenburg adds:
-
    
 
-
    
-I agree, just adding the comment that the exact number of decimal digits
-is digits * ln(radix) / ln(10), where probably this real number is
-rounded downward for digits10, and rounded upward for max_digits10
-(when radix=10, then digits10=max_digits10).
-Why not add this exact definition also to the standard, so the user
-knows what these numbers exactly mean.
-
    
+
    Proposed resolution:
    
+
    To 20.5 [function.objects], Function objects, paragraph 2, add to the header 
+<functional> synopsis:
    
+
    
+  
    template <class T> struct bit_and;
+template <class T> struct bit_or;
+template <class T> struct bit_xor;
    
+
    
+
    At a location in clause 20 to be determined by the Project Editor, add:
    
+
    
+  
    The library provides basic function object classes for all of the bitwise 
+  operators in the language ([expr.bit.and], [expr.or], [exp.xor]).
    
+  
    template <class T> struct bit_and : binary_function<T,T,T> {
+  T operator()(const T& x , const T& y ) const;
+};
    
+  
    
+    
    operator() returns x & y .
    
+  
    
+  
    template <class T> struct bit_or : binary_function<T,T,T> {
+  T operator()(const T& x , const T& y ) const;
+};
    
+  
    
+    
    operator() returns x | y .
    
+  
    
+  
    template <class T> struct bit_xor : binary_function<T,T,T> {
+  T operator()(const T& x , const T& y ) const;
+};
    
+  
    
+    
    operator() returns x ^ y .
    
+  
    
+
    
 
-
    
-Howard adds:
-
    
 
-
    
-For reference, here are the correct formulas from
-N1822:
-
    
 
-
    digits10 = floor((digits-1) * log10(2))
-max_digits10 = ceil((1 + digits) * log10(2))
-
    
 
+
+
    
+
    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:
    
 
    
-We are also missing a statement regarding for what specializations this member has meaning.
+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. 
 
      
-Change and add after 18.2.1.2 [numeric.limits.members], p11:
-
      
-
-
      
-
      static const int max_digits10;
      
-
      
-
      
--11- Number of base 10 digits required to ensure that values which
-differ by only one epsilon are always differentiated.
-
      
-
      
--12- Meaningful for all floating point types.
-
      
-
      
-
      
-
-
      
-Change 18.2.1.5 [numeric.special], p2:
-
      
-
-
      template<> class numeric_limits<float> { 
-public: 
-  static const bool is_specialized = true; 
-  ...
-  static const int digits10 = 6;
-  static const int max_digits10 = 9;
-  ...
+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);
 
      
 
 
      
-Change 18.2.1.5 [numeric.special], p3:
+Similarily in 27.6.1.2.2 [istream.formatted.arithmetic]/3 change the current as-if fragment
 
      
 
-
      template<> class numeric_limits<bool> { 
-public: 
-  static const bool is_specialized = true; 
-  ...
-  static const int digits10 = 0;
-  static const int max_digits10 = 0;
-  ...
+
      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.
+]
    
 
 
 
 
 
 
    
-
    616. missing 'typename' in ctype_byname
    
-
    Section: 22.2.1.2 [locale.ctype.byname] Status: WP
- Submitter: Bo Persson Date: 2006-12-16
    
-
    View all other issues in [locale.ctype.byname].
    
+
    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:
    
 
    
-Section 22.2.1.2 defines the ctype_byname class template. It contains the 
-line
+22.2.1.4.2 [locale.codecvt.virtuals], para 7 says (regarding do_unshift):
 
    
 
-
    typedef ctype<charT>::mask   mask;
-
    
+
    
+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:
    
 
    
-as this is a dependent type, it should obviously be
+Change 22.2.1.4.2 [locale.codecvt.virtuals], p7:
 
    
 
-
    typedef typename ctype<charT>::mask   mask;
-
    
+
    
+
    
+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.
+
    
+
    
 
 
 
 
 
 
    
-
    619. Longjmp wording problem
    
-
    Section: 18.8 [support.runtime] Status: WP
- Submitter: Lawrence Crowl Date: 2007-01-12
    
+
    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:
    
 
    
-The wording for longjmp is confusing.
-
    
-
    
-18.8 [support.runtime] -4- Other runtime support
+22.2.1.4.2 [locale.codecvt.virtuals], para 8 says:
 
    
+
 
    
-The function signature longjmp(jmp_buf jbuf, int val) has more restricted
-behavior in this International Standard.  If any automatic objects would
-be destroyed by a thrown exception transferring control to another
-(destination) point in the program, then a call to longjmp(jbuf, val) that
-the throw point that transfers control to the same (destination) point has
-undefined behavior.
+codecvt<char,char,mbstate_t>, returns noconv.
 
    
+
 
    
-Someone at Google thinks that should say "then a call to longjmp(jbuf, val)
-*at* the throw point that transfers control".
+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.
+
    
+
 
    
-Bill Gibbons thinks it should say something like "If any automatic objects
-would be destroyed by an exception thrown at the point of the longjmp and
-caught only at the point of the setjmp, the behavior is undefined."
+[Plum ref _222152Y62]
 
    
 
 
 
    Proposed resolution:
    
 
    
-In general, accept Bill Gibbons' recommendation,
-but add "call" to indicate that the undefined behavior
-comes from the dynamic call, not from its presence in the code.
-In 18.8 [support.runtime] paragraph 4, change
+Change 22.2.1.4.2 [locale.codecvt.virtuals], p8:
 
    
 
-
    
-The function signature longjmp(jmp_buf jbuf, int val) has more
-restricted behavior in this International Standard.  If any automatic
-objects would be destroyed by a thrown exception transferring control to another
-(destination) point in the program, then a call to longjmp(jbuf, val)
-that the throw point that transfers control to the same (destination) point has
-undefined behavior. A setjmp/longjmp call pair has
-undefined behavior if replacing the setjmp and longjmp by
-catch and throw would destroy any automatic objects.
-
    
+
    
+
    Returns: An enumeration value, as summarized in Table 76:
    
+
    ...
    
+
    
+codecvt<char,char,mbstate_t>, returns noconv.
+
    
+
    
+
 
 
 
 
 
 
    
-
    628. Inconsistent definition of basic_regex constructor
    
-
    Section: 28.8 [re.regex] Status: WP
- Submitter: Bo Persson Date: 2007-01-23
    
-
    View all other issues in [re.regex].
    
+
    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:
    
 
    
-Section 28.8 [re.regex] lists a constructor
+22.2.6.3.2 [locale.moneypunct.virtuals], para 4 footnote 257 says
 
    
 
-
    template<class InputIterator>
-basic_regex(InputIterator first, InputIterator last,
-                       flag_type f = regex_constants::ECMAScript);
-
    
+
    
+257) For international 
+specializations (second template parameter true) this is always four 
+characters long, usually three letters and a space.
+
    
 
 
    
-However, in section 28.8.2 [re.regex.construct], this constructor takes a 
-pair of ForwardIterator.
+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 28.8.2 [re.regex.construct]:
+Change footnote 253 in 22.2.6.3.2 [locale.moneypunct.virtuals]:
 
    
 
-
    template <class ForwardIterator InputIterator>
-  basic_regex(ForwardIterator InputIterator first, ForwardIterator InputIterator last, 
-              flag_type f = regex_constants::ECMAScript);
-
    
-
+
    
+
    
+253) For international specializations (second template
+parameter true) this is always typically
+four characters long, usually three letters and a space.
+
    
+
    
 
 
 
 
 
 
    
-
    634. allocator.address() doesn't work for types overloading operator&
    
-
    Section: 20.6.1.1 [allocator.members] Status: WP
- Submitter: Howard Hinnant Date: 2007-02-07
    
-
    View all other issues in [allocator.members].
    
+
    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.
    
-
    Duplicate of: 350
    
 
    Discussion:
    
-
 
    
-20.6.1.1 [allocator.members] says:
+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.
 
    
-
    
-
    pointer address(reference x) const;
    
-
    
+
+
+
    Proposed resolution:
    
+
 
    
--1- Returns: &x.
+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);
    
 
    
 
 
    
-20.6.1.1 [allocator.members] defines CopyConstructible which currently not
-only defines the semantics of copy construction, but also restricts what an overloaded
-operator& may do.  I believe proposals are in the works (such as concepts
-and rvalue reference) to decouple these two requirements.  Indeed it is not evident
-that we should disallow overloading operator& to return something other
-than the address of *this.
+Change 20.6.12.2.1 [util.smartptr.shared.const] as follows:
 
    
 
-
    
-An example of when you want to overload operator& to return something
-other than the object's address is proxy references such as vector<bool>
-(or its replacement, currently code-named bit_vector).  Taking the address of
-such a proxy reference should logically yield a proxy pointer, which when dereferenced,
-yields a copy of the original proxy reference again.
-
    
+
    
+
    template<class Y> shared_ptr(auto_ptr<Y>&&& r);
    
+
    
 
 
    
-On the other hand, some code truly needs the address of an object, and not a proxy
-(typically for determining the identity of an object compared to a reference object).
-boost has long recognized this dilemma and solved it with 
-boost::addressof.
-It appears to me that this would be useful functionality for the default allocator.  Adopting
-this definition for allocator::address would free the standard of requiring
-anything special from types which overload operator&.  Issue 580
-is expected to make use of allocator::address mandatory for containers.
+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.
+
    
+
    
+
+
    
 
-
    Proposed resolution:
    
 
    
-Change 20.6.1.1 [allocator.members]:
+Change 20.6.12.2.3 [util.smartptr.shared.assign] as follows:
 
    
 
 
    
-
    pointer address(reference x) const;
    
-
    
-
    
--1- Returns: &x. The actual address of object referenced by x,
-even in the presence of an overloaded operator&.
-
    
+
    template<class Y> shared_ptr& operator=(auto_ptr<Y>&&& r);
    
 
    
 
-
    const_pointer address(address(const_reference x) const;
    
-
    
 
    
--2- Returns: &x. The actual address of object referenced by x,
-even in the presence of an overloaded operator&.
+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.
+
    
 
    
+
 
    
 
-
    [
-post Oxford:  This would be rendered NAD Editorial by acceptance of
-N2257.
-]
    
 
 
 
    [
-Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which
-was subsequently split out into a separate paper N2436 for the purposes of voting.
-The resolution in N2436 addresses this issue.  The LWG voted to accelerate this
-issue to Ready status to be voted into the WP at Kona.
+Kona (2007): We may need to open an issue (743) to deal with the question of
+whether shared_ptr needs an rvalue swap.
 ]
    
 
 
 
 
 
-
-
 
    
-
    640. 27.6.2.5.2 does not handle (unsigned) long long
    
-
    Section: 27.6.2.6.2 [ostream.inserters.arithmetic] Status: WP
- Submitter: Daniel Krügler Date: 2007-02-17
    
-
    View all other issues in [ostream.inserters.arithmetic].
    
+
    677. Weaknesses in seed_seq::randomize [rand.util.seedseq]
    
+
    Section: 26.4.7.1 [rand.util.seedseq] Status: WP
+ Submitter: Charles Karney Date: 2007-05-15
    
+
    View other active issues in [rand.util.seedseq].
    
+
    View all other issues in [rand.util.seedseq].
    
 
    View all issues with WP status.
    
 
    Discussion:
    
 
    
-The arithmetic inserters are described in 27.6.2.6.2 [ostream.inserters.arithmetic].
-Although the section starts with a listing of the inserters including
-the new ones:
+seed_seq::randomize provides a mechanism for initializing random number
+engines which ideally would yield "distant" states when given "close"
+seeds.  The algorithm for seed_seq::randomize given in the current
+Working Draft for C++,
+N2284
+(2007-05-08), has 3 weaknesses
 
    
 
-
    operator<<(long long val );
-operator<<(unsigned long long val );
-
    
+
      
+
    1. 
+
       Collisions in state.  Because of the way the state is initialized,
+    seeds of different lengths may result in the same state.  The
+    current version of seed_seq has the following properties:
      
+
        
+
      •   For a given s <= n, each of the 2^(32s) seed vectors results in a
+      distinct state.
        • 
+
      
+
      
+    The proposed algorithm (below) has the considerably stronger
+    properties:
      
+
        
+
      •    All of the (2^(32n)-1)/(2^32-1) seed vectors of lengths s < n
+      result in distinct states.
+
        • 
+
      •   All of the 2^(32n) seed vectors of length s == n result in
+      distinct states.
+
        • 
+
      
+
      2. 
+
    2. 
+
       Poor mixing of v's entropy into the state.  Consider v.size() == n
+    and hold v[n/2] thru v[n-1] fixed while varying v[0] thru v[n/2-1],
+    a total of 2^(16n) possibilities.  Because of the simple recursion
+    used in seed_seq, begin[n/2] thru begin[n-1] can take on only 2^64
+    possible states.
      
 
+
       The proposed algorithm uses a more complex recursion which results
+    in much better mixing.
      
+
      3. 
+
    3.  seed_seq::randomize is undefined for v.size() == 0.  The proposed
+    algorithm remedies this.
+
      4. 
+
    
 
    
-the text in paragraph 1, which describes the corresponding effects
-of the inserters, depending on the actual type of val, does not
-handle the types long long and unsigned long long.
+The current algorithm for seed_seq::randomize is adapted by me from the
+initialization procedure for the Mersenne Twister by Makoto Matsumoto
+and Takuji Nishimura.  The weakness (2) given above was communicated to
+me by Matsumoto last year.
+
    
+
    
+The proposed replacement for seed_seq::randomize is due to Mutsuo Saito,
+a student of Matsumoto, and is given in the implementation of the
+SIMD-oriented Fast Mersenne Twister random number generator SFMT.
+http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html
+http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/SFMT-src-1.2.tar.gz
+
    
+
    
+See
+Mutsuo Saito,
+An Application of Finite Field: Design and Implementation of 128-bit
+Instruction-Based Fast Pseudorandom Number Generator,
+Master's Thesis, Dept. of Math., Hiroshima University (Feb. 2007)
+http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/M062821.pdf
+
    
+
    
+One change has been made here, namely to treat the case of small n
+(setting t = (n-1)/2 for n < 7).
+
    
+
    
+Since seed_seq was introduced relatively recently there is little cost
+in making this incompatible improvement to it.
 
    
 
-
    [
-Alisdair: In addition to the (unsigned) long long problem, that whole paragraph
-misses any reference to extended integral types supplied by the
-implementation - one of the additions by core a couple of working papers
-back.
-]
    
-
-
+
    
+See N2391 and
+N2423
+for some further discussion.
+
    
 
 
 
    Proposed resolution:
    
 
    
-In 27.6.2.6.2 [ostream.inserters.arithmetic]/1 change the third sentence
+Adopt the proposed resolution in
+N2423.
 
    
 
-
    
-When val is of type bool, long, unsigned
-long, long long, unsigned long long, double,
-long double, or const void*, the formatting conversion
-occurs as if it performed the following code fragment:
-
    
+
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]
    
 
 
 
 
 
 
    
-
    643. Impossible "as if" clauses
    
-
    Section: 27.8.1.1 [filebuf], 22.2.2.2.2 [facet.num.put.virtuals] Status: WP
- Submitter: Daniel Krügler Date: 2007-02-20
    
+
    678. Changes for [rand.req.eng]
    
+
    Section: 26.4.1.3 [rand.req.eng] Status: WP
+ Submitter: Charles Karney Date: 2007-05-15
    
+
    View all other issues in [rand.req.eng].
    
 
    View all issues with WP status.
    
 
    Discussion:
    
 
    
-The current standard 14882:2003(E) as well as N2134 have the
-following
-defects:
+Section 26.4.1.3 [rand.req.eng] Random number engine requirements:
 
    
 
 
    
-27.8.1.1 [filebuf]/5 says:
+This change follows naturally from the proposed change to
+seed_seq::randomize in 677.
 
    
 
-
    
 
    
-In order to support file I/O and multibyte/wide character conversion, conversions are performed using members of a 
-facet, referred to as a_codecvt in following sections, obtained "as if" by
+In table 104 the description of X(q) contains a special treatment of
+the case q.size() == 0.  This is undesirable for 4 reasons:
 
    
-
    codecvt<charT,char,typename traits::state_type> a_codecvt =
-  use_facet<codecvt<charT,char,typename traits::state_type> >(getloc());
-
    
-
    
+
+
      
+
    1. It replicates the functionality provided by X().
      2. 
+
    2. It leads to the possibility of a collision in the state provided
+    by some other X(q) with q.size() > 0.
      3. 
+
    3. It is inconsistent with the description of the X(q) in
+paragraphs 26.4.3.1 [rand.eng.lcong] p5, 26.4.3.2 [rand.eng.mers] p8, and 26.4.3.3 [rand.eng.sub] p10 where
+there is no special treatment of q.size() == 0.
      4. 
+
    4. The proposed replacement for seed_seq::randomize given above
+    allows for the case q.size() == 0.
      5. 
+
    
 
 
    
-use_facet returns a const facet reference and no facet is
-copyconstructible, so the codecvt construction should fail to compile.
+See N2391 and
+N2423
+for some further discussion.
 
    
 
+
+
    Proposed resolution:
    
 
    
-A similar issue arises in 22.2.2.2.2 [facet.num.put.virtuals]/15 for num_punct.
+Adopt the proposed resolution in
+N2423.
 
    
 
 
-
    Proposed resolution:
    
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]
    
+
+
+
+
+
+
    
+
    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:
    
 
    
-In 27.8.1.1 [filebuf]/5 change the "as if" code
+The C++98 standard specifies that one member function alone of the containers
+passes its parameter (T) by value instead of by const reference:
 
    
 
-
    const codecvt<charT,char,typename traits::state_type>& a_codecvt =
-  use_facet<codecvt<charT,char,typename traits::state_type> >(getloc());
+
    void resize(size_type sz, T c = T());
 
    
 
 
    
-In 22.2.2.2.2 [facet.num.put.virtuals]/15 (This is para 5 in N2134) change
+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:
 
    
 
 
    
 
    
-A local variable punct is initialized via
+So that self referencing statements are guaranteed to work, for example:
 
    
-
    const numpunct<charT>& punct = use_facet< numpunct<charT> >(str.getloc() );
+
    v.resize(v.size() + 1, v[0]);
 
    
 
    
 
 
    
-(Please note also the additional provided trailing semicolon)
+However this rationale is not convincing as the signature for push_back is:
 
    
 
+
    void push_back(const T& x);
+
    
 
-
-
-
-
-
    
-
    644. Possible typos in 'function' description
    
-
    Section: X [func.wrap.func.undef] Status: Pending WP
- Submitter: Bo Persson Date: 2007-02-25
    
-
    View all issues with Pending WP status.
    
-
    Discussion:
    
 
    
-X [func.wrap.func.undef]
-
    
-
    
-The note in paragraph 2 refers to 'undefined void operators', while the 
-section declares a pair of operators returning bool.
+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
+
    
 
-
    Proposed resolution:
    
 
    
-Change 20.5.15.2 [func.wrap.func]
+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).
 
    
 
-
    ...
-private:
-   // X [func.wrap.func.undef], undefined operators:
-   template<class Function2> bool void operator==(const function<Function2>&);
-   template<class Function2> bool void operator!=(const function<Function2>&);
-};
-
    
-
 
    
-Change X [func.wrap.func.undef]
+Even with move semantics available, passing this parameter by value can be expensive.
+Consider for example vector<vector<int>>:
 
    
 
-
    template<class Function2> bool void operator==(const function<Function2>&);
-template<class Function2> bool void operator!=(const function<Function2>&);
+
    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.
+
    
 
-
-
-
    
-
    646. const incorrect match_result members
    
-
    Section: 28.10.4 [re.results.form] Status: WP
- Submitter: Daniel Krügler Date: 2007-02-26
    
-
    View all issues with WP status.
    
-
    Discussion:
    
 
    
-28.10.4 [re.results.form] (root and para 3) in N2134 defines the two function template
-members format as non-const functions, although they are declared
-as const in 28.10 [re.results]/3.
+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:
    
 
    
-Add the missing const specifier to both format overloads described
-in section 28.10.4 [re.results.form].
+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);
+
    
 
-
-
    
-
    650. regex_token_iterator and const correctness
    
-
    Section: 28.12.2 [re.tokiter] Status: WP
- Submitter: Daniel Krügler Date: 2007-03-05
    
-
    View all other issues in [re.tokiter].
    
-
    View all issues with WP status.
    
-
    Discussion:
    
 
    
-Both the class definition of regex_token_iterator (28.12.2
-[re.tokiter]/6) and the latter member specifications (28.12.2.2
-[re.tokiter.comp]/1+2) declare both comparison operators as
-non-const functions. Furtheron, both dereference operators are
-unexpectedly also declared as non-const in 28.12.2 [re.tokiter]/6
-as well as in (28.12.2.3 [re.tokiter.deref]/1+2).
+Change 23.2.4 [list], p2:
 
    
 
+
    class list {
+   ...
+   void resize(size_type sz, const T& c);
+
    
 
-
    Proposed resolution:
    
 
    
-1) In (28.12.2 [re.tokiter]/6) change the current declarations
+Change 23.2.4.2 [list.capacity], p3:
 
    
 
-
    bool operator==(const regex_token_iterator&) const;
-bool operator!=(const regex_token_iterator&) const;
-const value_type& operator*() const;
-const value_type* operator->() const;
+
    void resize(size_type sz, const T& c);
 
    
 
 
    
-2) In 28.12.2.2 [re.tokiter.comp] change the following declarations
+Change 23.2.6 [vector], p2:
 
    
 
-
    bool operator==(const regex_token_iterator& right) const;
-bool operator!=(const regex_token_iterator& right) const;
+
    class vector {
+   ...
+   void resize(size_type sz, const T& c);
 
    
 
 
    
-3) In 28.12.2.3 [re.tokiter.deref] change the following declarations
+Change 23.2.6.2 [vector.capacity], p11:
 
    
 
-
    const value_type& operator*() const;
-const value_type* operator->() const;
+
    void resize(size_type sz, const T& c);
 
    
 
 
-
    [
-Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
-is to adopt the proposed wording in this issue).
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]
    
-
 
 
 
 
 
    
-
    651. Missing preconditions for regex_token_iterator c'tors
    
-
    Section: 28.12.2.1 [re.tokiter.cnstr] Status: WP
- Submitter: Daniel Krügler Date: 2007-03-05
    
-
    View all other issues in [re.tokiter.cnstr].
    
+
    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:
    
 
    
-The text provided in 28.12.2.1 [re.tokiter.cnstr]/2+3 describes
-the effects of the three non-default constructors of class
-template regex_token_iterator but is does not clarify which values
-are legal values for submatch/submatches. This becomes
-an issue, if one takes 28.12.2 [re.tokiter]/9 into account, which explains
-the notion of a "current match" by saying:
+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].
 
    
 
-
    
-The current match is (*position).prefix() if subs[N]
-== -1, or (*position)[subs[N]] for any other value of
-subs[N].
-
    
+
    template <class Iterator>
+class move_iterator {
+public:
+    ...
+    typedef typename iterator_traits<Iterator>::pointer pointer;
+    ...
+    pointer operator->() const {return current;}
+    ...
+private: 
+    Iterator current; // exposition only
+};
+
    
+
 
 
    
-It's not clear to me, whether other negative values except -1
-are legal arguments or not - it seems they are not.
+There are two possible fixes.
 
    
 
+
      
+
    1. pointer operator->() const {return &*current;}
      2. 
+
    2. typedef Iterator pointer;
      3. 
+
    
 
-
    Proposed resolution:
    
 
    
-Add the following precondition paragraph just before the current
-28.12.2.1 [re.tokiter.cnstr]/2:
+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.
 
    
 
-
    
-Requires: Each of the initialization values of subs must be >= -1.
-
    
+
    
+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;
+
    
 
-
    [
-Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
-is to adopt the proposed wording in this issue).
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]
    
 
 
 
 
 
 
    
-
    652. regex_iterator and const correctness
    
-
    Section: 28.12.1 [re.regiter] Status: WP
- Submitter: Daniel Krügler Date: 2007-03-05
    
+
    681. Operator functions impossible to compare are defined in [re.submatch.op]
    
+
    Section: 28.9.2 [re.submatch.op] Status: WP
+ Submitter: Nozomu Katoo Date: 2007-05-27
    
 
    View all issues with WP status.
    
 
    Discussion:
    
-
    Both the class definition of regex_iterator (28.12.1 [re.regiter]/1)
-and the latter member specification (28.12.1.2 [re.regiter.comp]/1+2)
-declare both comparison operators as
-non-const functions. Furtheron, both dereference operators are
-unexpectedly also declared as non-const in 28.12.1 [re.regiter]/1
-as well as in (28.12.1.3 [re.regiter.deref]/1+2).
+
    
+In 28.9.2 [re.submatch.op] of N2284, 
+operator functions numbered 31-42 seem impossible to compare.  E.g.: 
 
    
 
-
-
    Proposed resolution:
    
+
    
+
    template <class BiIter>
+    bool operator==(typename iterator_traits<BiIter>::value_type const& lhs,
+                    const sub_match<BiIter>& rhs);
+
    
+
    
 
    
-1) In (28.12.1 [re.regiter]/1) change the current declarations
+-31- Returns: lhs == rhs.str().
 
    
-
-
    bool operator==(const regex_iterator&) const;
-bool operator!=(const regex_iterator&) const;
-const value_type& operator*() const;
-const value_type* operator->() const;
-
    
+
    
+
    
 
 
    
-2) In 28.12.1.3 [re.regiter.deref] change the following declarations
+When char* is used as BiIter, iterator_traits<BiIter>::value_type would be 
+char, so that lhs == rhs.str() ends up comparing a char value and an object 
+of std::basic_string<char>.  However, the behaviour of comparison between 
+these two types is not defined in 21.3.8 [string.nonmembers] of N2284.
+ This applies when wchar_t* is used as BiIter. 
 
    
 
-
    const value_type& operator*() const;
-const value_type* operator->() const;
-
    
 
+
    Proposed resolution:
    
 
    
-3) In 28.12.1.2 [re.regiter.comp] change the following declarations
+Adopt the proposed resolution in
+N2409.
 
    
 
-
    bool operator==(const regex_iterator& right) const;
-bool operator!=(const regex_iterator& right) const;
-
    
-
 
 
    [
-Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
-is to adopt the proposed wording in this issue).
+Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
 ]
    
 
@@ -23690,128 +25789,59 @@ 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
- Submitter: Daniel Krügler Date: 2007-03-08
    
-
    View all other issues in [rand.req.eng].
    
-
    View all issues with Pending WP status.
    
+
    682. basic_regex ctor takes InputIterator or ForwardIterator?
    
+
    Section: 28.8.2 [re.regex.construct] Status: WP
+ Submitter: Eric Niebler Date: 2007-06-03
    
+
    View all issues with WP status.
    
 
    Discussion:
    
 
    
-Table 98 and para 5 in 26.4.1.3 [rand.req.eng] specify
-the IO insertion and extraction semantic of random
-number engines. It can be shown, v.i., that the specification
-of the extractor cannot guarantee to fulfill the requirement
-from para 5:
-
    
-
-
    
-If a textual representation written via os << x was
-subsequently read via is >> v, then x == v provided that
-there have been no intervening invocations of x or of v.
-
    
-
-
    
-The problem is, that the extraction process described in
-table 98 misses to specify that it will initially set the
-if.fmtflags to ios_base::dec, see table 104:
+Looking at N2284, 28.8 [re.regex], p3 basic_regex class template synopsis shows this 
+constructor: 
 
    
-
-
    
-dec: converts integer input or generates integer output
-in decimal base
-
    
+
    template <class InputIterator>
+     basic_regex(InputIterator first, InputIterator last, 
+                 flag_type f = regex_constants::ECMAScript);
+
    
 
 
    
-Proof: The following small program demonstrates the violation
-of requirements (exception safety not fulfilled):
+In 28.8.2 [re.regex.construct], p15, the constructor appears with this signature: 
 
    
 
-
    #include <cassert>
-#include <ostream>
-#include <iostream>
-#include <iomanip>
-#include <sstream>
-
-class RanNumEngine {
-  int state;
-public:
-  RanNumEngine() : state(42) {}
-
-  bool operator==(RanNumEngine other) const {
-	  return state == other.state;
-  }
-
-  template <typename Ch, typename Tr>
-  friend std::basic_ostream<Ch, Tr>& operator<<(std::basic_ostream<Ch, Tr>& os, RanNumEngine engine) {
-	Ch old = os.fill(os.widen(' ')); // Sets space character
-	std::ios_base::fmtflags f = os.flags();
-	os << std::dec << std::left << engine.state; // Adds ios_base::dec|ios_base::left
-	os.fill(old); // Undo
-	os.flags(f);
-	return os;
-  }
-
-  template <typename Ch, typename Tr>
-  friend std::basic_istream<Ch, Tr>& operator>>(std::basic_istream<Ch, Tr>& is, RanNumEngine& engine) {
-       // Uncomment only for the fix.
-
-	//std::ios_base::fmtflags f = is.flags();
-	//is >> std::dec;
-	is >> engine.state;
-	//is.flags(f);
-	return is;
-  }
-};
-
-int main() {
-	std::stringstream s;
-	s << std::setfill('#'); // No problem
-        s << std::oct; // Yikes!
-        // Here starts para 5 requirements:
-	RanNumEngine x;
-	s << x;
-	RanNumEngine v;
-	s >> v;
-	assert(x == v); // Fails: 42 == 34
-}
+
    template <class ForwardIterator>
+     basic_regex(ForwardIterator first, ForwardIterator last, 
+                 flag_type f = regex_constants::ECMAScript);
 
    
 
 
    
-A second, minor issue seems to be, that the insertion
-description from table 98 unnecessarily requires the
-addition of ios_base::fixed (which only influences floating-point
-numbers). Its not entirely clear to me whether the proposed
-standard does require that the state of random number engines
-is stored in integral types or not, but I have the impression
-that this is the indent, see e.g. p. 3
+ForwardIterator is probably correct, so the synopsis is wrong.
 
    
 
-
    
-The specification of each random number engine defines the
-size of its state in multiples of the size of its result_type.
-
    
+
    [
+John adds:
+]
    
 
+
+
    
 
    
-If other types than integrals are supported, then I wonder why
-no requirements are specified for the precision of the stream.
+I think either could be implemented?  Although an input iterator would 
+probably require an internal copy of the string being made.
 
    
-
 
    
-See N2391 and
-N2423
-for some further discussion.
+I have no strong feelings either way, although I think my original intent 
+was InputIterator. 
 
    
+
    
 
 
 
    Proposed resolution:
    
 
    
 Adopt the proposed resolution in
-N2423.
+N2409.
 
    
 
 
 
    [
-Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
 ]
    
 
@@ -23820,250 +25850,355 @@ 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
- Submitter: Daniel Krügler Date: 2007-03-08
    
-
    View all other issues in [rand.util.canonical].
    
-
    View all issues with Pending WP status.
    
+
    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:
    
 
    
-In 26.4.2 [rand.synopsis] we have the declaration
+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:
 
    
 
-
    template<class RealType, class UniformRandomNumberGenerator,
-  size_t bits>
-result_type generate_canonical(UniformRandomNumberGenerator& g);
+
    void f( shared_ptr<void> );
+void f( shared_ptr<int> );
+
+int main()
+{
+  f( shared_ptr<double>() ); // ambiguous
+}
 
    
 
 
    
-Besides the "result_type" issue (already recognized by Bo Persson
-at Sun, 11 Feb 2007 05:26:47 GMT in this group) it's clear, that
-the template parameter order is not reasonably choosen: Obviously
-one always needs to specify all three parameters, although usually
-only two are required, namely the result type RealType and the
-wanted bits, because UniformRandomNumberGenerator can usually
-be deduced.
+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:
    
 
    
-See N2391 and
-N2423
-for some further discussion.
+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*.
+
    
 
-
    Proposed resolution:
    
 
    
-Adopt the proposed resolution in
-N2423.
+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*.
+
    
+
    
 
-
    [
-Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]
    
 
 
 
 
 
 
    
-
    660. Missing Bitwise Operations
    
-
    Section: 20.5 [function.objects] Status: WP
- Submitter: Beman Dawes Date: 2007-04-02
    
-
    View all other issues in [function.objects].
    
+
    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:
    
-
    Section 20.5 [function.objects] provides function
-objects for some unary and binary 
-operations, but others are missing. In a LWG reflector discussion, beginning 
-with c++std-lib-18078, pros and cons of adding some of the missing operations 
-were discussed. Bjarne Stroustrup commented "Why standardize what isn't used? 
-Yes, I see the chicken and egg problems here, but it would be nice to see a 
-couple of genuine uses before making additions."
    
-
    A number of libraries, including Rogue Wave, GNU, Adobe ASL, and Boost, have 
-already added these functions, either publicly or for internal use. For example, 
-Doug Gregor commented: "Boost will also add ... (|, &, ^) in 1.35.0, because we 
-need those function
-objects to represent various parallel 
-collective operations (reductions, prefix reductions, etc.) in the new Message 
-Passing Interface (MPI) library."
    
-
    Because the bitwise operators have the strongest use cases, the proposed 
-resolution is limited to them.
    
+
    
+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:
    
-
    To 20.5 [function.objects], Function objects, paragraph 2, add to the header 
-<functional> synopsis:
    
-
    
-  
    template <class T> struct bit_and;
-template <class T> struct bit_or;
-template <class T> struct bit_xor;
    
-
    
-
    At a location in clause 20 to be determined by the Project Editor, add:
    
-
    
-  
    The library provides basic function object classes for all of the bitwise 
-  operators in the language ([expr.bit.and], [expr.or], [exp.xor]).
    
-  
    template <class T> struct bit_and : binary_function<T,T,T> {
-  T operator()(const T& x , const T& y ) const;
-};
    
-  
    
-    
    operator() returns x & y .
    
-  
    
-  
    template <class T> struct bit_or : binary_function<T,T,T> {
-  T operator()(const T& x , const T& y ) const;
-};
    
-  
    
-    
    operator() returns x | y .
    
-  
    
-  
    template <class T> struct bit_xor : binary_function<T,T,T> {
-  T operator()(const T& x , const T& y ) const;
-};
    
-  
    
-    
    operator() returns x ^ y .
    
-  
    
-
    
+
    
+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.
+
    
 
 
 
 
 
 
    
-
    677. Weaknesses in seed_seq::randomize [rand.util.seedseq]
    
-
    Section: 26.4.7.1 [rand.util.seedseq] Status: Pending WP
- Submitter: Charles Karney Date: 2007-05-15
    
-
    View all other issues in [rand.util.seedseq].
    
-
    View all issues with Pending WP status.
    
+
    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:
    
 
    
-seed_seq::randomize provides a mechanism for initializing random number
-engines which ideally would yield "distant" states when given "close"
-seeds.  The algorithm for seed_seq::randomize given in the current
-Working Draft for C++,
-N2284
-(2007-05-08), has 3 weaknesses
+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).
 
    
 
-
      
-
    1. 
-
       Collisions in state.  Because of the way the state is initialized,
-    seeds of different lengths may result in the same state.  The
-    current version of seed_seq has the following properties:
      
-
        
-
      •   For a given s <= n, each of the 2^(32s) seed vectors results in a
-      distinct state.
        • 
-
      
-
      
-    The proposed algorithm (below) has the considerably stronger
-    properties:
      
-
        
-
      •    All of the (2^(32n)-1)/(2^32-1) seed vectors of lengths s < n
-      result in distinct states.
-
        • 
-
      •   All of the 2^(32n) seed vectors of length s == n result in
-      distinct states.
-
        • 
-
      
-
      2. 
-
    2. 
-
       Poor mixing of v's entropy into the state.  Consider v.size() == n
-    and hold v[n/2] thru v[n-1] fixed while varying v[0] thru v[n/2-1],
-    a total of 2^(16n) possibilities.  Because of the simple recursion
-    used in seed_seq, begin[n/2] thru begin[n-1] can take on only 2^64
-    possible states.
      
 
-
       The proposed algorithm uses a more complex recursion which results
-    in much better mixing.
      
-
      3. 
-
    3.  seed_seq::randomize is undefined for v.size() == 0.  The proposed
-    algorithm remedies this.
-
      4. 
-
    
+
    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;
+
    
+
 
    
-The current algorithm for seed_seq::randomize is adapted by me from the
-initialization procedure for the Mersenne Twister by Makoto Matsumoto
-and Takuji Nishimura.  The weakness (2) given above was communicated to
-me by Matsumoto last year.
+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().
+
    
+
    
+
 
    
-The proposed replacement for seed_seq::randomize is due to Mutsuo Saito,
-a student of Matsumoto, and is given in the implementation of the
-SIMD-oriented Fast Mersenne Twister random number generator SFMT.
-http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html
-http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/SFMT-src-1.2.tar.gz
+In  addition,   change  the  description   of  any()  and
+none()   for  consistency   with   all()  as
+follows:
+
    
+
    
+bool any() const;
 
    
+
    
 
    
-See
-Mutsuo Saito,
-An Application of Finite Field: Design and Implementation of 128-bit
-Instruction-Based Fast Pseudorandom Number Generator,
-Master's Thesis, Dept. of Math., Hiroshima University (Feb. 2007)
-http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/M062821.pdf
+Returns: true if any bit in *this
+is onecount() != 0.
 
    
+
    
 
    
-One change has been made here, namely to treat the case of small n
-(setting t = (n-1)/2 for n < 7).
+bool none() const;
 
    
+
    
 
    
-Since seed_seq was introduced relatively recently there is little cost
-in making this incompatible improvement to it.
+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:
    
 
    
-See N2391 and
-N2423
-for some further 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:
    
 
    
-Adopt the proposed resolution in
-N2423.
+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.
+
    
+
    
 
-
-
    [
-Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]
    
+
    
+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.
+
    
+
    
 
 
 
 
 
 
    
-
    678. Changes for [rand.req.eng]
    
-
    Section: 26.4.1.3 [rand.req.eng] Status: WP
- Submitter: Charles Karney Date: 2007-05-15
    
-
    View all other issues in [rand.req.eng].
    
+
    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:
    
 
    
-Section 26.4.1.3 [rand.req.eng] Random number engine requirements:
+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()).
 
    
-
 
    
-This change follows naturally from the proposed change to
-seed_seq::randomize in 677.
+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:
    
 
    
-In table 104 the description of X(q) contains a special treatment of
-the case q.size() == 0.  This is undesirable for 4 reasons:
+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:
 
-
      
-
    1. It replicates the functionality provided by X().
      2. 
-
    2. It leads to the possibility of a collision in the state provided
-    by some other X(q) with q.size() > 0.
      3. 
-
    3. It is inconsistent with the description of the X(q) in
-paragraphs 26.4.3.1 [rand.eng.lcong] p5, 26.4.3.2 [rand.eng.mers] p8, and 26.4.3.3 [rand.eng.sub] p10 where
-there is no special treatment of q.size() == 0.
      4. 
-
    4. The proposed replacement for seed_seq::randomize given above
-    allows for the case q.size() == 0.
      5. 
-
    
+~ctype(); // virtual
+virtual char do_toupper(char c) const;
+
    
+
    
+
+
+
+
+
+
    
+
    699. N2111 changes min/max
    
+
    Section: 26.4 [rand] Status: WP
+ Submitter: P.J. Plauger Date: 2007-07-01
    
+
    View all other issues in [rand].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+N2111
+changes min/max in several places in random from member
+functions to static data members. I believe this introduces
+a needless backward compatibility problem between C++0X and
+TR1. I'd like us to find new names for the static data members,
+or perhaps change min/max to constexprs in C++0X.
+
    
 
 
    
 See N2391 and
@@ -24089,149 +26224,171 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
 
    
-
    681. Operator functions impossible to compare are defined in [re.submatch.op]
    
-
    Section: 28.9.2 [re.submatch.op] Status: WP
- Submitter: Nozomu Katoo Date: 2007-05-27
    
+
    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:
    
 
    
-In 28.9.2 [re.submatch.op] of N2284, 
-operator functions numbered 31-42 seem impossible to compare.  E.g.: 
+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 BiIter>
-    bool operator==(typename iterator_traits<BiIter>::value_type const& lhs,
-                    const sub_match<BiIter>& rhs);
+
    template <class T> struct identity
+{
+    typedef T type;
+    const T& operator()(const T& x) const;
+};
+
    
+
    
+
    const T& operator()(const T& x) const;
 
    
 
    
 
    
--31- Returns: lhs == rhs.str().
+Returns: x.
 
    
 
    
 
    
 
-
    
-When char* is used as BiIter, iterator_traits<BiIter>::value_type would be 
-char, so that lhs == rhs.str() ends up comparing a char value and an object 
-of std::basic_string<char>.  However, the behaviour of comparison between 
-these two types is not defined in 21.3.8 [string.nonmembers] of N2284.
- This applies when wchar_t* is used as BiIter. 
-
    
-
-
-
    Proposed resolution:
    
-
    
-Adopt the proposed resolution in
-N2409.
-
    
-
+
    
 
-
    [
-Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]
    
 
 
 
 
 
 
    
-
    682. basic_regex ctor takes InputIterator or ForwardIterator?
    
-
    Section: 28.8.2 [re.regex.construct] Status: Pending WP
- Submitter: Eric Niebler Date: 2007-06-03
    
-
    View all issues with Pending WP status.
    
+
    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:
    
 
    
-Looking at N2284, 28.8 [re.regex], p3 basic_regex class template synopsis shows this 
-constructor: 
+map::at() need a complexity specification.
 
    
-
    template <class InputIterator>
-     basic_regex(InputIterator first, InputIterator last, 
-                 flag_type f = regex_constants::ECMAScript);
-
    
 
+
+
    Proposed resolution:
    
 
    
-In 28.8.2 [re.regex.construct], p15, the constructor appears with this signature: 
+Add the following to the specification of map::at(), 23.3.1.2 [map.access]:
 
    
-
-
    template <class ForwardIterator>
-     basic_regex(ForwardIterator first, ForwardIterator last, 
-                 flag_type f = regex_constants::ECMAScript);
-
    
-
+
    
 
    
-ForwardIterator is probably correct, so the synopsis is wrong.
+Complexity: logarithmic.
 
    
+
    
 
-
    [
-John adds:
-]
    
 
 
-
    
+
+
+
    
+
    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:
    
 
    
-I think either could be implemented?  Although an input iterator would 
-probably require an internal copy of the string being made.
+The current working draft has a type-trait decay in 20.4.7 [meta.trans.other].
 
    
+
 
    
-I have no strong feelings either way, although I think my original intent 
-was InputIterator. 
+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:
    
 
    
-Adopt the proposed resolution in
-N2409.
+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.
+
    
 
-
    [
-Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]
    
 
 
 
 
 
 
    
-
    699. N2111 changes min/max
    
-
    Section: 26.4 [rand] Status: WP
- Submitter: P.J. Plauger Date: 2007-07-01
    
-
    View all other issues in [rand].
    
+
    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:
    
 
    
-N2111
-changes min/max in several places in random from member
-functions to static data members. I believe this introduces
-a needless backward compatibility problem between C++0X and
-TR1. I'd like us to find new names for the static data members,
-or perhaps change min/max to constexprs in C++0X.
+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:
    
 
    
-See N2391 and
-N2423
-for some further discussion.
+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&&);
+
    
 
-
    Proposed resolution:
    
 
    
-Adopt the proposed resolution in
-N2423.
+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.
+
    
+
    
 
-
    [
-Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]
    
 
 
 
@@ -24241,6 +26398,7 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
    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