From: paolo Date: Mon, 22 Sep 2008 15:17:09 +0000 (+0000) Subject: 2008-09-22 Paolo Carlini X-Git-Tag: upstream/4.9.2~39564 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=b106be5b86152b42172099dac49abcf38ee3cecc;p=platform%2Fupstream%2Flinaro-gcc.git 2008-09-22 Paolo Carlini * doc/html/ext/lwg-closed.html: Update to Revision R59. * doc/html/ext/lwg-active.html: Likewise. * doc/html/ext/lwg-defects.html: Likewise. * doc/xml/manual/intro.xml: Adjust. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@140552 138bc75d-0d04-0410-961f-82ee72b054a4 --- diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog index cbb6671..c4a4926 100644 --- a/libstdc++-v3/ChangeLog +++ b/libstdc++-v3/ChangeLog @@ -1,3 +1,10 @@ +2008-09-22 Paolo Carlini + + * doc/html/ext/lwg-closed.html: Update to Revision R59. + * doc/html/ext/lwg-active.html: Likewise. + * doc/html/ext/lwg-defects.html: Likewise. + * doc/xml/manual/intro.xml: Adjust. + 2008-09-21 Paolo Carlini * include/bits/stl_algo.h (minmax(initializer_list<>): Use make_pair, diff --git a/libstdc++-v3/doc/html/ext/lwg-active.html b/libstdc++-v3/doc/html/ext/lwg-active.html index 27e0ed2..94b57c0 100644 --- a/libstdc++-v3/doc/html/ext/lwg-active.html +++ b/libstdc++-v3/doc/html/ext/lwg-active.html @@ -1,22 +1,24 @@ -C++ Standard Library Active Issues List - + + +C++ Standard Library Active Issues List + + - + - + @@ -27,7 +29,7 @@ del {background-color:#FFA0A0}
Doc. no.N2612=08-0122N2727=08-0237
Date:2008-05-182008-08-24
Project:Howard Hinnant <howard.hinnant@gmail.com>
-

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

+

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

Reference ISO/IEC IS 14882:1998(E)

Also see:

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

Revision History

    +
  • R59: +2008-08-22 pre-San Francisco mailing. +
      +
    • Summary:
        +
      • 192 open issues, up by 9.
        • +
      • 686 closed issues, up by 0.
        • +
      • 878 issues total, up by 9.
        • +
      • +
    • Details:
      • +
    +
    • +
  • R58: +2008-07-28 mid-term mailing. +
      +
    • Summary:
        +
      • 183 open issues, up by 12.
        • +
      • 686 closed issues, down by 4.
        • +
      • 869 issues total, up by 8.
        • +
      • +
    • Details:
        +
      • Added the following New issues: 862, 863, 864, 865, 866, 867, 868, 869.
        • +
      • Changed the following issues from Pending NAD Editorial to NAD Editorial: 393, 557, 592, 754, 757.
        • +
      • Changed the following issues from Pending WP to Open: 644.
        • +
      • Changed the following issues from WP to Ready: 387, 629.
        • +
      • Changed the following issues from Pending NAD Editorial to Review: 709.
        • +
      • +
    +
    • +
  • R57: +2008-06-27 post-Sophia Antipolis mailing. + +
  • R56: 2008-05-16 pre-Sophia Antipolis mailing.
      @@ -103,7 +166,7 @@ del {background-color:#FFA0A0}
    • 838 issues total, up by 25.
  • Details:
@@ -121,7 +184,7 @@ del {background-color:#FFA0A0}
  • Added the following NAD issues: 790, 791, 796, 797, 799.
  • Added the following New issues: 788, 794, 802, 804, 805, 806, 807, 808, 809, 810, 811, 812, 813.
  • Added the following Open issues: 793, 800, 801, 803.
    • -
  • Added the following Ready issues: 789, 792, 798.
    • +
  • Added the following Ready issues: 789, 792, 798.
  • Changed the following issues from NAD Future to Dup: 116.
  • Changed the following issues from NAD Future to NAD: 188, 323.
  • Changed the following issues from New to NAD: 729, 730, 731, 733, 735, 736, 737, 739, 741, 745, 748, 763, 764, 773, 784.
    • @@ -130,13 +193,13 @@ del {background-color:#FFA0A0}
  • Changed the following issues from Open to NAD Editorial: 529, 626.
  • Changed the following issues from Review to NAD Editorial: 645, 684.
  • Changed the following issues from NAD Future to Open: 128, 180, 190.
    • -
  • Changed the following issues from New to Open: 617, 718, 719, 720, 724, 732, 734, 742, 747, 750, 753, 756, 760, 762, 767, 774.
    • +
  • Changed the following issues from New to Open: 617, 718, 719, 720, 724, 732, 734, 742, 747, 750, 753, 756, 760, 762, 767, 774.
  • Changed the following issues from Ready to Open: 675, 676, 688.
    • -
  • Changed the following issues from New to Pending NAD Editorial: 709, 717, 725, 738, 754, 757.
    • +
  • Changed the following issues from New to Pending NAD Editorial: 709, 717, 725, 738, 754, 757.
  • Changed the following issues from Open to Pending NAD Editorial: 424, 557, 625.
    • -
  • Changed the following issues from New to Ready: 710, 715, 722, 740, 743, 744, 746, 749, 755, 758, 759, 761, 766, 768, 770, 775, 777, 778, 781, 782, 783.
    • -
  • Changed the following issues from Open to Ready: 387, 471, 550, 612, 629, 673.
    • -
  • Changed the following issues from Review to Ready: 518, 574, 596, 618, 638, 672, 685.
    • +
  • Changed the following issues from New to Ready: 710, 715, 722, 740, 743, 744, 746, 749, 755, 758, 759, 761, 766, 768, 770, 775, 777, 778, 781, 782, 783.
    • +
  • Changed the following issues from Open to Ready: 387, 471, 550, 612, 629, 673.
    • +
  • Changed the following issues from Review to Ready: 518, 574, 596, 618, 638, 672, 685.
  • Changed the following issues from New to Review: 711, 728, 771, 776.
  • Changed the following issues from Open to Review: 539.
  • Changed the following issues from Ready to WP: 561, 562, 563, 567, 581, 620, 621, 622, 623, 624, 661, 664, 665, 666, 674, 679, 680, 687, 689, 693, 694, 695, 700, 703, 705, 706.
    • @@ -153,7 +216,7 @@ del {background-color:#FFA0A0}
  • 787 issues total, up by 23.
  • Details:
  • Details:
    • @@ -186,16 +249,16 @@ del {background-color:#FFA0A0}
  • 754 issues total, up by 31.
  • Details:
  • Details:
    • @@ -232,10 +295,10 @@ del {background-color:#FFA0A0}
  • 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 Pending WP to Open: 258.
    • -
  • Changed the following issues from Ready to Pending WP: 644.
    • +
  • Changed the following issues from Ready to Pending WP: 644.
  • Changed the following issues from New to Ready: 577, 660.
  • Changed the following issues from Open to Ready: 488.
    • -
  • Changed the following issues from Open to Review: 518.
    • +
  • Changed the following issues from Open to Review: 518.
  • Changed the following issues from Ready to TRDec: 604.
  • Changed the following issues from DR to WP: 453.
  • Changed the following issues from Ready to WP: 531, 551, 566, 628, 640, 643, 646.
    • @@ -251,7 +314,7 @@ del {background-color:#FFA0A0}
  • 696 issues total, up by 20.
  • Details:
  • Details:
  • Details:
      -
    • Added the following New issues: 620, 621, 622, 623, 624, 627, 628, 629, 630, 631, 632, 633, 634, 635, 636, 637, 638, 639, 640, 641, 642, 643, 644, 645, 646, 647, 648, 649, 650, 651, 652, 653, 654, 655, 656.
      • +
    • Added the following New issues: 620, 621, 622, 623, 624, 627, 628, 629, 630, 631, 632, 633, 634, 635, 636, 637, 638, 639, 640, 641, 642, 643, 644, 645, 646, 647, 648, 649, 650, 651, 652, 653, 654, 655, 656.
    • Added the following Open issues: 625, 626.
      • -
    • Changed the following issues from New to Open: 570, 580, 582, 590, 612, 614.
      • +
    • Changed the following issues from New to Open: 570, 580, 582, 590, 612, 614.
    • Changed the following issues from New to Tentatively Ready: 547, 553, 560, 571, 572, 575, 576, 578, 586, 589, 591, 593, 594, 609, 610, 611, 613, 615, 616, 619.
    • Changed the following issues from Open to Tentatively Ready: 201, 206, 233, 254, 258, 385, 416, 422, 456, 463, 466, 470, 471, 479, 482, 515, 526, 532, 536, 542, 559.
    • Changed the following issues from Review to Tentatively Ready: 534.
      • @@ -329,7 +392,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.
      • @@ -418,7 +481,7 @@ Moved issues 498, 504, 506, 509, 510, 511, 512, 513, 514 from New to Open. Moved issues 505, 507, 508, 519 from New to Ready. Moved issue 500 from New to NAD. -Moved issue 518 from New to Review. +Moved issue 518 from New to Review.
    • R38: 2005-07-03 pre-Mont Tremblant mailing. @@ -753,11 +816,11 @@ format, 23. Num_get overflow result -

      Section: 22.2.2.1.2 [facet.num.get.virtuals] Status: Open +

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

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

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

      -

      View all issues with Open status.

      +

      View all issues with Review status.

      Discussion:

      The current description of numeric input does not account for the possibility of overflow. This is an implicit result of changing the @@ -1107,11 +1170,11 @@ retained for future reference.

      180. Container member iterator arguments constness has unintended consequences

      -

      Section: 23 [containers] Status: Open +

      Section: 21.3 [basic.string] Status: Ready 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.

      +

      View other active issues in [basic.string].

      +

      View all other issues in [basic.string].

      +

      View all issues with Ready 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 @@ -1149,22 +1212,81 @@ single container?

      +

      [ +Sophia Antipolis: +]

      + + +
      +

      +This was a fix that was intended for all standard library containers, +and has been done for other containers, but string was missed. +

      +

      +The wording updated. +

      +

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

      +

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

      +
      +

      Proposed resolution:

      -

      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.

      +

      +Update the following signature in the basic_string class template definition in +21.3 [basic.string], p5: +

      +
      namespace std {
+  template<class charT, class traits = char_traits<charT>,
+    class Allocator = allocator<charT> >
+  class basic_string {
 
-
      For example, in   21.3.5.5  change:
      
-
      
-       iterator erase(iterator p);
      
-
      
-to:
      
-       iterator erase(const_iterator p);
+    ...
+
+    iterator insert(const_iterator p, charT c);
+    void insert(const_iterator p, size_type n, charT c);
+    template<class InputIterator>
+      void insert(const_iterator p, InputIterator first, InputIterator last);
+    void insert(const_iterator p, initializer_list<charT>);
+
+    ...
+
+    iterator erase(const_iterator const_position);
+    iterator erase(const_iterator first, const_iterator last);
+
+    ...
+
+  };
+}
+
      + +

      +Update the following signatures in 21.3.6.4 [string::insert]:

      +
      iterator insert(const_iterator p, charT c);
+void insert(const_iterator p, size_type n, charT c);
+template<class InputIterator>
+  void insert(const_iterator p, InputIterator first, InputIterator last);
+void insert(const_iterator p, initializer_list<charT>);
+
      + +

      +Update the following signatures in 21.3.6.5 [string::erase]: +

      + +
      iterator erase(const_iterator const_position);
+iterator erase(const_iterator first, const_iterator last);
+
      + +

      Rationale:

      The issue was discussed at length. It was generally agreed that 1) @@ -1186,7 +1308,6 @@ standard. Also see issue 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:

      @@ -1294,7 +1415,7 @@ signature.

      290. Requirements to for_each and its function object

      -

      Section: 25.1.1 [alg.foreach] Status: Open +

      Section: 25.1.4 [alg.foreach] Status: Open Submitter: Angelika Langer Date: 2001-01-03

      View all other issues in [alg.foreach].

      View all issues with Open status.

      @@ -2309,7 +2430,8 @@ imaginary part of a[i].

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

      void real(T);
@@ -2367,6 +2489,26 @@ Bellevue:
 Second half of proposed wording replaced and moved to Ready.
      +

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

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

      [ +Post-Sophia Antipolis: +]

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

      Rationale:

      The LWG believes that C99 compatibility would be enough @@ -2484,11 +2626,10 @@ functions should be changed as proposed below.

      396. what are characters zero and one

      -

      Section: 23.3.5.1 [bitset.cons] Status: Open +

      Section: 23.3.5.1 [bitset.cons] Status: Ready 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.

      +

      View all issues with Ready status.

      Discussion:

      23.3.5.1, p6 [lib.bitset.cons] talks about a generic character @@ -2521,6 +2662,25 @@ http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#303 Also note the typo in 23.3.5.1, p6: the object under construction is a bitset, not a string.

      + +

      [ +Sophia Antipolis: +]

      + + +
      +

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

      +

      +Disposition: move to ready. +

      +

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

      +
      +

      Proposed resolution:

      @@ -2586,6 +2746,15 @@ post Bellevue: We are happy with the resolution as proposed, and we move this to Ready. +

      [ +Howard adds: +]

      + + +
      +The proposed wording neglects the 3 newer to_string overloads. +
      + @@ -3655,7 +3824,6 @@ reachability.

      454. basic_filebuf::open should accept wchar_t names

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

      -

      View other active issues in [filebuf.members].

      View all other issues in [filebuf.members].

      View all issues with Open status.

      Duplicate of: 105

      @@ -3703,6 +3871,38 @@ Implementors are free to add specific overloads for non-char character types.

      +

      [ +Martin adds pre-Sophia Antipolis: +]

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

      [ +Sophia Antipolis: +]

      + + +
      +

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

      +

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

      +
      + +

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

      + +

      Proposed resolution:

      @@ -4341,10 +4541,10 @@ The expression delete get() is well formed.

      471. result of what() implementation-defined

      -

      Section: 18.6.1 [type.info] Status: Ready +

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

      +

      View all issues with Open status.

      Discussion:

      [lib.exception] specifies the following:

      @@ -4418,6 +4618,17 @@ Move to Ready as we are accepting words unmodified.

      +

      [ +Sophia Antipolis: +]

      + + +
      +The issue was pulled from Ready. It needs to make clear that only homogenous copying +is intended to be supported. Not coping from a dervied to a base. +
      + +

      Proposed resolution:

      @@ -5059,80 +5270,12 @@ 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: Ready - Submitter: Matt Austern Date: 2005-07-03

      -

      View all other issues in [unord.req].

      -

      View all issues with Ready status.

      -

      Discussion:

      -

      -Issue 371 deals with stability of multiset/multimap under insert and erase -(i.e. do they preserve the relative order in ranges of equal elements). -The same issue applies to unordered_multiset and unordered_multimap. -

      -

      [ -Moved to open (from review): There is no resolution. -]

      - - -

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

      - - - - -

      Proposed resolution:

      -

      -Wording for the proposed resolution is taken from the equivalent text for associative containers. -

      - -

      -Change 23.1.3 [unord.req], Unordered associative containers, paragraph 6 to: -

      - -

      -An unordered associative container supports unique keys if it may -contain at most one element for each key. Otherwise, it supports equivalent -keys. unordered_set and unordered_map support -unique keys. unordered_multiset and unordered_multimap -support equivalent keys. In containers that support equivalent keys, elements -with equivalent keys are adjacent to each other. For -unordered_multiset -and unordered_multimap, insert and erase -preserve the relative ordering of equivalent elements. -

      - -

      -Change 23.1.3 [unord.req], Unordered associative containers, paragraph 8 to: -

      - -
      -

      The elements of an unordered associative container are organized into -buckets. Keys with the same hash code appear in the same bucket. The number -of buckets is automatically increased as elements are added to an unordered -associative container, so that the average number of elements per bucket is kept -below a bound. Rehashing invalidates iterators, changes ordering between -elements, and changes which buckets elements appear in, but does not invalidate -pointers or references to elements. For unordered_multiset -and unordered_multimap, rehashing -preserves the relative ordering of equivalent elements.

      -
      - - - - - - -

      522. Tuple doesn't define swap

      -

      Section: 20.3 [tuple], TR1 6.1 [tr.tuple] Status: Open +

      Section: 20.4 [tuple], TR1 6.1 [tr.tuple] Status: Ready Submitter: Andy Koenig Date: 2005-07-03

      View other active issues in [tuple].

      View all other issues in [tuple].

      -

      View all issues with Open status.

      +

      View all issues with Ready status.

      Discussion:

      Tuple doesn't define swap(). It should. @@ -5160,7 +5303,7 @@ Bellevue: Alisdair provided wording.

      Proposed resolution:

      -Add these signatures to 20.3 [tuple] +Add these signatures to 20.4 [tuple] 

      template <class... Types>
@@ -5172,7 +5315,7 @@ template <class... Types>

      -Add this signature to 20.3.1 [tuple.tuple] +Add this signature to 20.4.1 [tuple.tuple] 

      void swap(tuple&&);
@@ -5363,9 +5506,9 @@ Pete: Possible general problem with case insensitive ranges.
 
 
      
 
      539. partial_sum and adjacent_difference should mention requirements
      
-
      Section: 26.6.3 [partial.sum] Status: Review
+
      Section: 26.6.3 [partial.sum] Status: Open
  Submitter: Marc Schoolderman Date: 2006-02-06
      
-
      View all issues with Review status.
      
+
      View all issues with Open status.
      
 
      Discussion:
      
 
      
 There are some problems in the definition of partial_sum and
@@ -5521,6 +5664,21 @@ The intent of the algorithms is to perform their calculations using the type of
 Proposed wording provided.
      +

      [ +Sophia Antipolis: +]

      + + +
      +We did not agree that the proposed resolution was correct. For example, +when the arguments are types (float*, float*, double*), the +highest-quality solution would use double as the type of the +accumulator. If the intent of the wording is to require that the type of +the accumulator must be the input_iterator's value_type, the wording +should specify it. +
      + +

      Proposed resolution:

      @@ -5575,199 +5733,60 @@ 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: 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 Ready status.

      +

      556. is Compare a BinaryPredicate?

      +

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

      +

      View all other issues in [alg.sorting].

      +

      View all issues with Open status.

      Discussion:

      -Assuming we adopt the -C -compatibility package from C99 what should be the return type of the -following signature be: -

      -
      ?  pow(float, int);
-
      -

      -C++03 says that the return type should be float. - -TR1 and C90/99 say the return type should be double. This can put -clients into a situation where C++03 provides answers that are not as high -quality as C90/C99/TR1. For example: +In 25, p8 we allow BinaryPredicates to return a type that's convertible +to bool but need not actually be bool. That allows predicates to return +things like proxies and requires that implementations be careful about +what kinds of expressions they use the result of the predicate in (e.g., +the expression in if (!pred(a, b)) need not be well-formed since the +negation operator may be inaccessible or return a type that's not +convertible to bool).

      -
      #include <math.h>
-
-int main()
-{
-    float x = 2080703.375F;
-    double y = pow(x, 2);
-}
-

      -Assuming an IEEE 32 bit float and IEEE 64 bit double, C90/C99/TR1 all suggest: +Here's the text for reference:

      - -
      y = 4329326534736.390625
-
      +

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

      -which is exactly right. While C++98/C++03 demands: +In 25.3, p2 we require that the Compare function object return true +of false, which would seem to preclude such proxies. The relevant text +is here:

      +

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

      -
      y = 4329326510080.
-
      +

      Proposed resolution:

      -which is only approximately right. +I think we could fix this by rewording 25.3, p2 to read somthing like:

      +

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

      -

      -I recommend that C++0X adopt the mixed mode arithmetic already adopted by -Fortran, C and TR1 and make the return type of pow(float,int) be -double. -

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

      - - -

      [ -

      -Howard, post Kona: -

      -
      -

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

      -

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

      -

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

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

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

      -

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

      -
      -]

      - - -

      [ -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] p10: -

      - -
      -

      -The added signatures are: -

      -
      ...
-float pow(float, int);
-...
-double pow(double, int);
-...
-long double pow(long double, int);
-
      -
      - - - - - - -
      -

      556. is Compare a BinaryPredicate?

      -

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

      -

      View all other issues in [alg.sorting].

      -

      View all issues with Open status.

      -

      Discussion:

      -

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

      -

      -Here's the text for reference: -

      -

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

      - -

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

      -

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

      - - -

      Proposed resolution:

      -

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

      -

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

      - - -

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

      @@ -5933,66 +5952,6 @@ Add log2 to the list of functions in TR1 8.16.4 [tr.c99.cmath.over] p1.
      -

      570. Request adding additional explicit specializations of char_traits

      -

      Section: 21.1 [char.traits] Status: Open - Submitter: Jack Reeves Date: 2006-04-06

      -

      View other active issues in [char.traits].

      -

      View all other issues in [char.traits].

      -

      View all issues with Open status.

      -

      Discussion:

      -

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

      - - -

      [ -post Bellevue: -]

      - - -
      -

      -We suggest that Jack be asked about the status of his paper, and if it -is not forthcoming, the work-item be assigned to someone else. If no one -steps forward to do the paper before the next meeting, we propose to -make this NAD without further discussion. We leave this Open for now, -but our recommendation is NAD. -

      -

      -Note: the issue statement should be updated, as the Toronto comment has -already been resolved. E.g., char_traits specializations for char16_t -and char32_t are now in the working paper. -

      -
      - - - -

      Proposed resolution:

      - - - - - -

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

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

      @@ -6047,58 +6006,6 @@ these definitions are horrible. Proposed Disposition: Open
      -

      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:

      -

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

      -

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

      - - -

      Proposed resolution:

      -

      -Change 27.3 [iostream.objects]/1: -

      - -
      -

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

      -
      - - -

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

      - - - - - -

      580. unused allocator members

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

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

      582. specialized algorithms and volatile storage

      -

      Section: 20.6.10.1 [uninitialized.copy] Status: Open +

      Section: 20.7.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.

      @@ -6637,396 +6544,104 @@ requirements? Alisdair will prepare a paper. Proposed Disposition: Open
      -

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

      -

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

      -

      View other active issues in [complex.value.ops].

      -

      View all other issues in [complex.value.ops].

      -

      View all issues with Ready status.

      +

      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:

      -TR1 introduced, in the C compatibility chapter, the function -fabs(complex<T>): +In a private email, Daveed writes:

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

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

      -But in C99 (ISO/IEC 9899:1999 as well as the 9899:TC2 draft document -n1124), the referenced subclause reads +Here is an example:

      +
      +
      +		 struct S {
+		   S(_Decimal32 const&);  // Converting constructor
+		 };
+		 void f(S);
 
-
      ----- SNIP -----
-7.3.8.1 The cabs functions
-
-  Synopsis
-
-1 #include <complex.h>
-  double cabs(double complex z);
-  float cabsf(float complex z);
-  long double cabsl(long double z);
-
-  Description
-
-2 The cabs functions compute the complex absolute value (also called
-  norm, modulus, or magnitude) of z.
-
-  Returns
+		 void f(_Decimal64);
 
-3 The cabs functions return the complex absolute value.
------ SNIP -----
-
      
+		 void g(_Decimal32 d) {
+		   f(d);
+		 }
+
      +

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

      -So either the return value of fabs() is specified wrongly, or fabs() -does not behave the same as C99's cabs*(). +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.

      - -Possible Resolutions - +

      -This depends on the intention behind the introduction of fabs(). +Robert comments:

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

      -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 +In preparing the decimal TR, we have three options:

      -
        complex<double> x, y;
-  y = fabs(x);
-  complex<double> z(fabs(x));
-
      +
        +
      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. +

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

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

      Note that neither example above implies any problems with respect to +C-to-C++ compatibility, since neither example can be expressed in C.

      -

      [ -Bellevue: -]

      - -
      -Bill believes that abs() is a suitable overload. We should remove fabs(). -
      +

      Proposed resolution:

      -

      Proposed resolution:

      -

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

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

      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:

      -Remove 26.3.7 [complex.value.ops], p7: -

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

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

      -
      -
      - - - -

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

      - - - - - -
      -

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

      -

      Section: 27.8.1.4 [filebuf.members] Status: 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:

      -

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

      - -

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

      -

      -Add to the table "File open modes" in 27.8.1.4 [filebuf.members]: -

      - -
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      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: +In c++std-lib-17205, Martin writes:

      ...was it a deliberate design choice to make narrowing assignments ill-formed while permitting narrowing compound assignments? @@ -7078,61 +6693,6 @@ 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

      @@ -7240,86 +6800,29 @@ std::array does have, but array isn't mentioned.
      -

      618. valarray::cshift() effects on empty array

      -

      Section: 26.5.2.7 [valarray.members] Status: Ready - Submitter: Gabriel Dos Reis Date: 2007-01-10

      +

      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:

      -I would respectfully request an issue be opened with the intention to -clarify the wording for size() == 0 for cshift. +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.

      - -

      Proposed resolution:

      -Change 26.5.2.7 [valarray.members], paragraph 10: +Further notes/ideas from the lib-reflector, messages 17982-17984:

      - -
      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. +Add additional entries in num_punct to cover the complex separator (French would be ';').

      -
      -
      - - - -

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

      Solve the problem for ordered sequences in general, perhaps with a @@ -7347,6 +6850,32 @@ And move this to READY status.

      +

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

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

      [ +Post-Sophia Antipolis: +]

      + + +
      +

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

      +

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

      +
      + +

      Proposed resolution:

      @@ -7355,7 +6884,7 @@ 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 +inserting showpoint into the output stream forces all outputs to show an explicit decimal point character; then all inserted complex sequences will extract unambiguously.]
      @@ -7368,6 +6897,7 @@ will extract unambiguously.]

      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:

      @@ -7505,6 +7035,46 @@ performing the assignment.

      +

      [ +pre-Sophia Antipolis, Martin adds the following compromise wording, but +prefers the original proposed resolution: +]

      + + +

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

      + +
      +

      + -1- Requires: size() == 0 || size() == x.size(). +

      +

      + -2- Effects: If size() == 0 calls x.resize(x.size()) first. + Each element of the *this array is assigned the value of the + corresponding element of the argument array. +

      +

      + -3- Postcondition: size() == x.size(). +

      +
      + +

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

      + +
      +

      + -?- When size() == 0 and 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. Otherwise, + when size() > 0 and size() != N, the behavior is undefined. +

      +
      + +

      [ Kona (2007): Gaby to propose wording for an alternative resolution in @@ -7764,97 +7334,53 @@ 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.

      +

      644. Possible typos in 'function' description

      +

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

      +

      View all issues with Open status.

      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: +X [func.wrap.func.undef]

      -

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

      -

      -This would handle situations like: +The note in paragraph 2 refers to 'undefined void operators', while the +section declares a pair of operators returning bool.

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

      [ -Post Kona, Steve LoBasso notes: +Post-Sophia Antipolis: ]

      -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. +Changed from Pending WP to Open. This issue was voted to WP at the same time the operators were +changed from private to deleted. The two issues stepped on each other. What do we want the return +type of these deleted functions to be?

      Proposed resolution:

      -Change 23.2.2.3 [deque.modifiers], p4: +Change 20.6.15.2 [func.wrap.func]

      -
      -
      iterator erase(const_iterator position); 
-iterator erase(const_iterator first, const_iterator last);
-
      +
      ...
+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>&);
+};
+
      -

      --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. +Change X [func.wrap.func.undef]

      -
      -
      - - - -

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

      - - -

      [ -Bellevue: -]

      +
      template<class Function2> bool void operator==(const function<Function2>&);
+template<class Function2> bool void operator!=(const function<Function2>&);
+
      -
      -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. -
      @@ -8144,7 +7670,10 @@ Bill to provide proposed wording and interpretation of existing wording.

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

      View all issues with Open status.

      +

      Duplicate of: 836

      Discussion:

      + +

      22.2.6.3 [locale.moneypunct], para 2 says:

      @@ -8259,159 +7788,109 @@ 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.

      +

      675. Move assignment of containers

      +

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

      +

      View other active issues in [container.requirements].

      +

      View all other issues in [container.requirements].

      +

      View all issues with Review status.

      Discussion:

      -The current Swappable is: +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).

      -
      - - - - - -
      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. -
        • -
      -
      -
      +
      vector<shared_ptr<ostream>> v1;
+vector<shared_ptr<ostream>> v2;
+...
+v1 = v2;               // #1
+v1 = std::move(v2);    // #2
+

      -With the passage of rvalue reference into the language, Swappable needs to be updated to -require only MoveConstructible and MoveAssignable. This is a minimum. +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.

      -Additionally we may want to support proxy references such that the following code is acceptable: +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()).

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

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

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

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

      [ +post Bellevue Howard adds: +]

      + + +

      -The Swappable requirement is met by satisfying one or more of the following conditions: +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.

      -
        -
      • -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). +post Sophia Antipolis Howard updated proposed wording: ]

      @@ -8419,592 +7898,302 @@ 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.

      +

      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:

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

      -
        - -

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

        -

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

        -
        • +

        Proposed resolution:

        -

      • -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. +Add to 23.4 [unord]:

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

      +
      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);
 
-
      [
-Post Kona: Howard adds example user code related to the first bullet:
-]
      
+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);
 
-
      
-
      void legacy_code(void*, std::size_t);
+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);
 
-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
-
      
-
      
+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);
 
-
      
-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;
-
      
+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);
 
-
      Proposed resolution:
      
+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);
 
-
      [
-I am grateful for the generous aid of Peter Dimov and Ion Gaztañaga in helping formulate and review
-the proposed resolutions below.
-]
      
+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 20.6.11.2 [unique.ptr.single]: +Change 23.4.1 [unord.map]:

        -
        template <class T, class D = default_delete<T>> class unique_ptr {
-   ...
-   T& typename add_lvalue_reference<T>::type operator*() const;
-   ...
+
        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);
+    ...
 };
-
        
 
-
        
-Change 20.6.11.2.4 [unique.ptr.single.observers]:
-
        
+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);
 
-
        T& typename add_lvalue_reference<T>::type operator*() const;
-
        
+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); + -

      • -Change 20.6.11.2 [unique.ptr.single]: +Add to 23.4.1.1 [unord.map.cnstr]:

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

        +

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

        - -

        -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. +Add to 23.4.1.2 [unord.map.elem]:

        -

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

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

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

        +

        ...

        +

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

        -

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

        +
        mapped_type& operator[](key_type&& k);
        -
        T* pointer operator->() const;
        -... -
        T* pointer get() const;
        -
        +

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

        -

        -Change 20.6.11.2.5 [unique.ptr.single.modifiers]: -

        +

        +Requires: mapped_type shall be DefaultConstructible. +

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

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

        -

        -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]: +Add new section [unord.map.modifiers]:

        -
        unique_ptr(T* pointer p);
-unique_ptr(T* pointer p, implementation defined d);
-unique_ptr(T* pointer p, implementation defined d);
+
        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);
 
        
 
-
        
-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]
-
        
-
        +
        +

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

        -

        -Change 20.6.11.3.3 [unique.ptr.runtime.modifiers]: -

        +

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

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

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

        -

        --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]: +Add to 23.4.1.3 [unord.map.swap]:

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

      +

      unordered_multimap

      -Change 23.4.1 [unord.map]: +Change 23.4.2 [unord.multimap]:

      -
      class unordered_map
+
      class unordered_multimap
 {
     ...
-    unordered_map(const unordered_map&);
-    unordered_map(unordered_map&&);
-    ~unordered_map();
-    unordered_map& operator=(const unordered_map&);
-    unordered_map& operator=(unordered_map&&);
+    unordered_multimap(const unordered_multimap&);
+    unordered_multimap(unordered_multimap&&);
+    ~unordered_multimap();
+    unordered_multimap& operator=(const unordered_multimap&);
+    unordered_multimap& operator=(unordered_multimap&&);
     ...
     // modifiers 
-    std::pair<iterator, bool> insert(const value_type& obj); 
-    template <class P> pair<iterator, bool> insert(P&& obj);
+    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_map&&);
-    ...
-    mapped_type& operator[](const key_type& k);
-    mapped_type& operator[](key_type&& k);
+    void swap(unordered_multimap&&);
     ...
 };
 
 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 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_map<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>&& y);
+  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_map<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>& y);
+  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x, 
+            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
 
      
 
 
      
-Add to 23.4.1.1 [unord.map.cnstr]:
+Add to 23.4.2.1 [unord.multimap.cnstr]:
 
      
 
 
      
 
      template <class InputIterator>
-  unordered_map(InputIterator f, InputIterator l, 
+  unordered_multimap(InputIterator f, InputIterator l, 
                 size_type n = implementation-defined, 
                 const hasher& hf = hasher(), 
                 const key_equal& eql = key_equal(), 
@@ -9022,184 +8211,19 @@ then both key_type and mapped_type shall be
 
      
 
 
      
-Add to 23.4.1.2 [unord.map.elem]:
+Add new section [unord.multimap.modifiers]:
 
      
 
 
      
-
-
      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);
-
      
+
      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);
+
      
 
 
      
 
      
@@ -9512,117 +8536,8 @@ that it requires. Please put it back into Open status.
 
 
 
      
-
      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]. 
-
      
-
-
-
      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]:
-
      
-
-
      
-
      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.
-
      
-
      
-
      
-
-
-
      
-Change the synopsis in 24.4.3.1 [move.iterator]:
-
      
-
-
      
-
      template <class Iterator1, class Iterator2> 
-  typename move_iterator<Iterator>::difference_type auto operator-( 
-    const move_iterator<Iterator1>& x, 
-    const move_iterator<Iterator2>& y) -> decltype(x.base() - y.base());
-
      
-
      
-
-
      
-Change 24.4.3.3.14 [move.iter.nonmember]:
-
      
-
-
      
-
      template <class Iterator1, class Iterator2> 
-  typename move_iterator<Iterator>::difference_type auto operator-( 
-    const move_iterator<Iterator1>& x, 
-    const move_iterator<Iterator2>& y) -> decltype(x.base() - y.base());
-
      
-
      
-
      
-Returns: x.base() - y.base().
-
      
-
      
-
      
-
-
      [
-Pre Bellevue:  This issue needs to wait until the auto -> return language feature
-goes in.
-]
      
-
-
-
-
-
-
-
-
      
 
      688. reference_wrapper, cref unsafe, allow binding to rvalues
      
-
      Section: 20.5.5.1 [refwrap.const] Status: Open
+
      Section: 20.6.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.
      
@@ -9643,7 +8558,7 @@ Also please see the thread starting at c++std-lib-17398 for some good discussion
 
 
      Proposed resolution:
      
 
      
-In 20.5 [function.objects], add the following two signatures to the synopsis:
+In 20.6 [function.objects], add the following two signatures to the synopsis:
 
      
 
 
      template <class T> void ref(const T&& t) = delete;
@@ -9679,11 +8594,11 @@ the "special deduction rule" is disabled with the const T&& pattern.
 
 
      
 
      691. const_local_iterator cbegin, cend missing from TR1
      
-
      Section: 23.4 [unord], TR1 6.3 [tr.hash] Status: Review
+
      Section: 23.4 [unord], TR1 6.3 [tr.hash] Status: Ready
  Submitter: Joaquín M López Muñoz Date: 2007-06-14
      
 
      View other active issues in [unord].
      
 
      View all other issues in [unord].
      
-
      View all issues with Review status.
      
+
      View all issues with Ready status.
      
 
      Discussion:
      
 
      
 The last version of TR1 does not include the following member
@@ -9709,7 +8624,7 @@ Is this really an oversight, or am I missing something?
 
      Proposed resolution:
      
 
      
 Add the following two rows to table 93 (unordered associative container
-requirements) in section 23.1.3 [unord.req]:
+requirements) in section 23.1.5 [unord.req]:
 
      
 
 
      
@@ -9766,11 +8681,11 @@ 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
+
      Section: 27.6.4 [ext.manip] Status: Review
  Submitter: Martin Sebor Date: 2007-06-22
      
 
      View other active issues in [ext.manip].
      
 
      View all other issues in [ext.manip].
      
-
      View all issues with New status.
      
+
      View all issues with Review status.
      
 
      Discussion:
      
 
      
 In a private email Bill Plauger notes:
@@ -9891,10 +8806,10 @@ prevent the facet from storing the value.
 
 
 
      
-
      698. Some system_error issues
      
-
      Section: 19.4.5.1 [syserr.syserr.overview] Status: New
+
      698. system_error needs const char* constructors
      
+
      Section: 19.4.5.1 [syserr.syserr.overview] Status: Review
  Submitter: Daniel Krügler Date: 2007-06-24
      
-
      View all issues with New status.
      
+
      View all issues with Review status.
      
 
      Discussion:
      
 
      
 In 19.4.5.1 [syserr.syserr.overview] we have the class definition of
@@ -9916,13 +8831,59 @@ accepting a const char*.
 
 
      Proposed resolution:
      
 
      
+This proposed wording assumes issue 832 has been accepted and applied to the working paper.
 
      
 
+
      
+Change 19.4.5.1 [syserr.syserr.overview] Class system_error overview, as indicated:
+
      
 
+
      public:
+  system_error(error_code ec, const string& what_arg);
+  system_error(error_code ec, const char* what_arg);
+  system_error(error_code ec);
+  system_error(int ev, const error_category* ecat,
+      const string& what_arg);
+  system_error(int ev, const error_category* ecat,
+      const char* what_arg);
+  system_error(int ev, const error_category* ecat);
+
      
 
+
      
+To 19.4.5.2 [syserr.syserr.members] Class system_error members add:
+
      
 
+
      
+
      system_error(error_code ec, const char* what_arg);
+
      
+
      
+
      
+Effects: Constructs an object of class system_error.
+
      
+
      
+Postconditions: code() == ec and strcmp(runtime_error::what(), what_arg) == 0.
+
      
+
      
 
-
      
+
      system_error(int ev, const error_category* ecat, const char* what_arg);
+
      
+
+
      
+
      
+Effects: Constructs an object of class system_error.
+
      
+
      
+Postconditions: code() == error_code(ev, ecat) and strcmp(runtime_error::what(), what_arg) == 0.
+
      
+
      
+
      
+
+
+
+
+
+
+
      
 
      701. assoc laguerre poly's
      
 
      Section: TR1 5.2.1.1 [tr.num.sf.Lnm] Status: New
  Submitter: Christopher Crawford Date: 2007-06-30
      
@@ -10009,15 +8970,13 @@ not omitted by mistake.
 
-
+
-
+                                Sequences and Associative containers with propagate_never and propagate_on_copy_construction allocators require value_type to be MoveConstructible.
+
      
 Container Requirements
 
      X u(a)value_type must be CopyConstructible
      X u(rv)array requires value_type to be MoveConstructible
      X u(rv)array and containers with a propagate_never allocator require value_type to be MoveConstructible
      
 
      a = uSequences require value_type to be CopyConstructible and CopyAssignable.
                                Associative containers require value_type to be CopyConstructible.
      
 
      a = rvarray requires value_type to be MoveAssignable.
-                                Sequences 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.
      swap(a,u)array and containers with propagate_never and
+                  propagate_on_copy_construction allocators require value_type to be Swappable.
      
 
      
 
 
      
@@ -10046,7 +9005,7 @@ not omitted by mistake.
                                         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.
+                                     The sequence vector also requires the value_type to be MoveConstructible.
 a.resize(n, t)The value_type must be CopyConstructible.
 
 
@@ -10182,151 +9141,77 @@ Kona (2007): Bill and Nick to provide wording.
 
 
 
      
-
      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.
      
+
      709. char_traits::not_eof has wrong signature
      
+
      Section: 21.1.3 [char.traits.specializations] Status: Review
+ Submitter: Bo Persson Date: 2007-08-13
      
+
      View all other issues in [char.traits.specializations].
      
+
      View all issues with Review status.
      
 
      Discussion:
      
 
      
-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.
-
      
-
-
      [
-Bellevue:
-]
      
-
-
-
      
-
      
-Move to "ready", adopting the first (Peter's) proposed resolution.
+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.
 
      
 
      
-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...".
+This doesn't work for type char, and is inconsistent with the 
+requirements in Table 56, Traits requirements, 21.1.1 [char.traits.require].
 
      
-
      
-
 
-
      Proposed resolution:
      
 
      
-Add to 20.6.12.2.1 [util.smartptr.shared.const]:
+Pete adds:
 
      
 
-
      
-
      shared_ptr(shared_ptr&& r);
-template<class Y> shared_ptr(shared_ptr<Y>&& r);
-
      
-
      
-
      
-Postconditions:  *this shall contain the old value of r. r
-shall be empty. r.get() == 0.
-
      
-
      
-
      
+
      
+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.
+
      
 
-
      
-Add to 20.6.12.2.10 [util.smartptr.shared.cast]:
-
      
 
-
      
-
      template<class T, class U> shared_ptr<T> static_pointer_cast(shared_ptr<U> const& r);
-
      
-
      
-
      
-Postconditions: If w is the return value,
-w.get() == static_cast<T*>(r.get()) && w.use_count() == r.use_count().
-
      
-
      
-
      
 
-
      
-
      template<class T, class U> shared_ptr<T> dynamic_pointer_cast(shared_ptr<U> const& r);
-
      
-
      
+
      Proposed resolution:
      
 
      
-Postconditions: If w is the return value, w.get() == dynamic_cast<T*>(r.get()).
+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
 
      
-
      
-
      
 
-
      
-
      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().
-
      
-
      
-
      
+
      static constexpr int_type not_eof(char_type int_type c);
+
      
 
-
      
-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()).
-
      
-
      
+
      [
+Bellevue:
+]
      
 
-
      
-
      
--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()).
-
      
+Resolution: NAD editorial - up to Pete's judgment
 
      
 
-
      
-This takes care of the missing postconditions for the casts by bringing
-in the aliasing constructor postcondition "by reference".
-
      
+
      [
+Post Sophia Antipolis
+]
      
 
 
+
      
+Moved from Pending NAD Editorial to Review.  The proposed wording appears to be correct but non-editorial.
+
      
 
 
 
 
 
      
 
      711. Contradiction in empty shared_ptr
      
-
      Section: 20.6.12.2.5 [util.smartptr.shared.obs] Status: Review
+
      Section: 20.7.12.2.5 [util.smartptr.shared.obs] Status: Open
  Submitter: Peter Dimov Date: 2007-08-24
      
 
      View all other issues in [util.smartptr.shared.obs].
      
-
      View all issues with Review status.
      
+
      View all issues with Open status.
      
 
      Discussion:
      
 
      
 A discussion on
@@ -10355,7 +9240,7 @@ with a non-NULL stored pointer.
 
      
 
 
      
-This is contradicted by the second sentence in the Returns clause of 20.6.12.2.5 [util.smartptr.shared.obs]:
+This is contradicted by the second sentence in the Returns clause of 20.7.12.2.5 [util.smartptr.shared.obs]:
 
      
 
 
      
@@ -10390,10 +9275,48 @@ on it, but there isn't support for removing this feature at this time.
 
      
 
      
 
+
      [
+Sophia Antipolis:
+]
      
+
+
+
      
+
      
+We heard from Peter Dimov, who explained his reason for preferring solution 1.
+
      
+
      
+Because it doesn't seem to add anything. It simply makes the behavior
+for p = 0 undefined. For programmers who don't create empty pointers
+with p = 0, there is no difference. Those who do insist on creating them
+presumably have a good reason, and it costs nothing for us to define the
+behavior in this case.
+
      
+
      
+The aliasing constructor is sharp enough as it is, so "protecting" users
+doesn't make much sense in this particular case.
+
      
+
      
+> Do you have a use case for r being empty and r being non-null? 
+
      
+
      
+I have received a few requests for it from "performance-conscious"
+people (you should be familiar with this mindset) who don't like the
+overhead of allocating and maintaining a control block when a null
+deleter is used to approximate a raw pointer. It is obviously an "at
+your own risk", low-level feature; essentially a raw pointer behind a
+shared_ptr facade.
+
      
+
      
+We could not agree upon a resolution to the issue; some of us thought
+that Peter's description above is supporting an undesirable behavior.
+
      
+
      
+
+
 
 
      Proposed resolution:
      
 
      
-In keeping the N2351 spirit and obviously my preference, change 20.6.12.2.5 [util.smartptr.shared.obs]:
+In keeping the N2351 spirit and obviously my preference, change 20.7.12.2.5 [util.smartptr.shared.obs]:
 
      
 
 
      
@@ -10409,7 +9332,7 @@ Alternative proposed resolution: (I won't be happy if we do this, but it's possi
 
      
 
 
      
-Change 20.6.12.2.1 [util.smartptr.shared.const]:
+Change 20.7.12.2.1 [util.smartptr.shared.const]:
 
      
 
 
      
@@ -10434,9 +9357,9 @@ instance with a non-NULL stored pointer.
 
 
      
 
      713. sort() complexity is too lax
      
-
      Section: 25.3.1.1 [sort] Status: New
+
      Section: 25.3.1.1 [sort] Status: Ready
  Submitter: Matt Austern Date: 2007-08-30
      
-
      View all issues with New status.
      
+
      View all issues with Ready status.
      
 
      Discussion:
      
 
      
 The complexity of sort() is specified as "Approximately N
@@ -10461,8 +9384,8 @@ In 25.3.1.1 [sort], change the complexity to "O(N log N)", and remove footnote 2
 
 
      
 
      
-Complexity: Approximately O(N log(N)) (where N == last - first )
-comparisons on the average.266)
+Complexity: Approximately O(N log(N)) (where N == last - first )
+comparisons on the average.266)
 
      
 
      
 266)
@@ -10478,13 +9401,13 @@ If the worst case behavior is important stable_sort() (25.3.1.2) or 
 
      714. search_n complexity is too lax
      
-
      Section: 25.1.9 [alg.search] Status: New
+
      Section: 25.1.12 [alg.search] Status: Ready
  Submitter: Matt Austern Date: 2007-08-30
      
 
      View all other issues in [alg.search].
      
-
      View all issues with New status.
      
+
      View all issues with Ready status.
      
 
      Discussion:
      
 
      
-The complexity for search_n (25.1.9 [alg.search] par 7) is specified as "At most
+The complexity for search_n (25.1.12 [alg.search] par 7) is specified as "At most
 (last - first ) * count applications of the corresponding predicate if
 count is positive, or 0 otherwise." This is unnecessarily pessimistic.
 Regardless of the value of count, there is no reason to examine any
@@ -10523,60 +9446,6 @@ template<class ForwardIterator, class Size, class T,
 
 
 
      
-
      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).
-
      
-
-
-
      Proposed resolution:
      
-
      
-Change 25.3.7 [alg.min.max] to:
-
      
-
-
      
-
      template<class ForwardIterator> 
-  pair<ForwardIterator, ForwardIterator> 
-    minmax_element(ForwardIterator first , ForwardIterator last); 
-template<class ForwardIterator, class Compare> 
-  pair<ForwardIterator, ForwardIterator> 
-    minmax_element(ForwardIterator first , ForwardIterator last , Compare comp);
-
      
-
      
-
      
-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.
-
      
-
      
-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).
-
      
-
      
-
      
-
-
-
-
-
-
-
      
 
      716. Production in [re.grammar] not actually modified
      
 
      Section: 28.13 [re.grammar] Status: New
  Submitter: Stephan T. Lavavej Date: 2007-08-31
      
@@ -10642,7 +9511,7 @@ Sequence (23.1.1) and for a Reversible Container (23.1).
 
      
 
 
      
-First of all, 23.1.1 [sequence.reqmts] is no longer "Sequence" but "Sequence container". 
+First of all, 23.1.3 [sequence.reqmts] is no longer "Sequence" but "Sequence container". 
 Secondly, after the resent changes to containers (emplace, push_back, 
 const_iterator parameters to insert and erase), basic_string is not 
 even close to conform to the current requirements.
@@ -10689,7 +9558,7 @@ different, a string abstraction in its own right.
 
 
      
 
      719. std::is_literal type traits should be provided
      
-
      Section: 20.4 [meta] Status: Open
+
      Section: 20.5 [meta] Status: Open
  Submitter: Daniel Krügler Date: 2007-08-25
      
 
      View all other issues in [meta].
      
 
      View all issues with Open status.
      
@@ -10720,7 +9589,7 @@ a new type category "literal", which is defined in 3.9 [basic.types]/p.11:
 
 
      
 I strongly suggest that the standard provides a type traits for
-literal types in 20.4.4.3 [meta.unary.prop] for several reasons:
+literal types in 20.5.4.3 [meta.unary.prop] for several reasons:
 
      
 
 
        
@@ -10782,7 +9651,7 @@ 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",
+In 20.5.2 [meta.type.synop] in the group "type properties",
 just below the line
 
        
 
@@ -10797,7 +9666,7 @@ add a new one:
 
      
 
 
      
-In 20.4.4.3 [meta.unary.prop], table Type Property Predicates, just
+In 20.5.4.3 [meta.unary.prop], table Type Property Predicates, just
 below the line for the is_pod property add a new line:
 
      
 
@@ -10821,11 +9690,11 @@ array of unknown bound, or
 
 
      
 
      720. Omissions in constexpr usages
      
-
      Section: 23.2.1 [array], 23.3.5 [template.bitset] Status: Open
+
      Section: 23.2.1 [array], 23.3.5 [template.bitset] Status: Ready
  Submitter: Daniel Krügler Date: 2007-08-25
      
 
      View other active issues in [array].
      
 
      View all other issues in [array].
      
-
      View all issues with Open status.
      
+
      View all issues with Ready status.
      
 
      Discussion:
      
 
        
 
      1. 
@@ -10847,6 +9716,33 @@ initialisation. What have I overlooked here?
 
        2. 
 
      
 
+
      [
+Sophia Antipolis:
+]
      
+
+
+
      
+
      
+We handle this as two parts
+
      
+
        
+
      1. 
+The proposed resolution is correct; move to ready.
+
        2. 
+
      2. 
+The issue points out a real problem, but the issue is larger than just
+this solution. We believe a paper is needed, applying the full new
+features of C++ (including extensible literals) to update std::bitset.
+We note that we do not consider this new work, and that is should be
+handled by the Library Working Group.
+
        3. 
+
      
+
      
+In order to have a consistent working paper, Alisdair and Daniel produced a new wording for the resolution.
+
      
+
      
+
+
 
 
      Proposed resolution:
      
 
        
@@ -10917,44 +9813,11 @@ void main()
 
 
 
        
-
        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):
-
        
-
-
        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)
-
        
-
-
-
        Proposed resolution:
        
-
        
-In 26.7 [c.math], table 108, section "Functions", add nanf and nanl
-just after the existing entry nan.
-
        
-
-
-
-
-
-
        
 
        723. basic_regex should be moveable
        
-
        Section: 28.8 [re.regex] Status: New
+
        Section: 28.8 [re.regex] Status: Open
  Submitter: Daniel Krügler Date: 2007-08-29
        
 
        View all other issues in [re.regex].
        
-
        View all issues with New status.
        
+
        View all issues with Open status.
        
 
        Discussion:
        
 
        
 According to the current state of the standard draft, the class
@@ -10966,6 +9829,15 @@ use cases, where a factory function returns regex values,
 which would take advantage of moveabilities.
 
        
 
+
        [
+Sophia Antipolis:
+]
        
+
+
+
        
+Needs wording for the semantics, the idea is agreed upon.
+
        
+
 
 
        Proposed resolution:
        
 
          
@@ -11154,11 +10026,11 @@ following table:
 
 
          
 
          726. Missing regex_replace() overloads
          
-
          Section: 28.11.4 [re.alg.replace] Status: New
+
          Section: 28.11.4 [re.alg.replace] Status: Open
  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.
          
+
          View all issues with Open status.
          
 
          Discussion:
          
 
          
 Two overloads of regex_replace() are currently provided:
@@ -11230,6 +10102,18 @@ is no way to avoid constructing a basic_string.)
 
 
        
 
+
        [
+Sophia Antipolis:
+]
        
+
+
+
        
+We note that Boost already has these overloads. However, the proposed
+wording is provided only for 28.11.4 [re.alg.replace]; wording is needed for the synopsis
+as well. We also note that this has impact on match_results::format,
+which may require further overloads.
+
        
+
 
 
 
        Proposed resolution:
        
@@ -11335,10 +10219,10 @@ arguments.
 
 
        
 
        728. Problem in [rand.eng.mers]/6
        
-
        Section: 26.4.3.2 [rand.eng.mers] Status: Review
+
        Section: 26.4.3.2 [rand.eng.mers] Status: Ready
  Submitter: Stephan Tolksdorf Date: 2007-09-21
        
 
        View all other issues in [rand.eng.mers].
        
-
        View all issues with Review status.
        
+
        View all issues with Ready status.
        
 
        Discussion:
        
 
        
 The mersenne_twister_engine is required to use a seeding method that is given 
@@ -11411,6 +10295,16 @@ proposed by Charles Karney should also be included in the proposed
 wording.
 
      
 
+
      [
+Sophia Antipolis:
+]
      
+
+
+
      
+Note the main part of the issue is resolved by
+N2424.
+
      
+
 
 
 
@@ -11489,9 +10383,9 @@ for the proposed resolution.
 
 
      
 
      734. Unnecessary restriction in [rand.dist.norm.chisq]
      
-
      Section: 26.4.8.4.3 [rand.dist.norm.chisq] Status: Open
+
      Section: 26.4.8.4.3 [rand.dist.norm.chisq] Status: Review
  Submitter: Stephan Tolksdorf Date: 2007-09-21
      
-
      View all issues with Open status.
      
+
      View all issues with Review status.
      
 
      Discussion:
      
 
      
 chi_squared_distribution, fisher_f_distribution and student_t_distribution
@@ -11528,6 +10422,27 @@ In N2424. Not wildly enthusiastic, not really felt necessary. Less
 frequently used in practice. Not terribly bad either. Move to OPEN.
 
      
 
+
      [
+Sophia Antipolis:
+]
      
+
+
+
      
+
      
+Marc Paterno: The generalizations were explicitly left out when designing the facility. It's harder to test.
+
      
+
      
+Marc Paterno: Ask implementers whether floating-point is a significant burden.
+
      
+
      
+Alisdair: It's neater to do it now, do ask Bill Plauger.
+
      
+
      
+Disposition: move to review with the option for "NAD" if it's not straightforward to implement; unanimous consent.
+
      
+
      
+
+
 
 
      Proposed resolution:
      
 
      
@@ -11615,126 +10530,29 @@ Replace both occurrences of "int n() const;" with "RealType n() con
 
 
 
      
-
      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.
      
+
      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:
      
 
      
-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.
+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.
 
      
 
 
      
-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.
+This issue seeks to widen the Swappable requirement to support proxy iterators.  Here
+is example code:
 
      
 
-
      
-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).
-
      
+
      namespace Mine {
 
-
      
-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. :-)
-
      
-
-
      [
-Bellevue:
-]
      
-
-
-
      
-
      Suggestion that fixed-size array instantiations are going to fail at
-compile time anyway (if we remove specialization) due to pointer decay,
-at least that appears to be result from available compilers.
-
      
-
      
-So concerns about about requiring static_assert seem unfounded.
-
      
-
      After a little more experimentation with compiler, it appears that
-fixed size arrays would only work at all if we supply these explicit
-specialization. So removing them appears less breaking than originally
-thought.
-
      
-
      
-straw poll unanimous move to Ready.
-
      
-
      
-
-
-
-
      Proposed resolution:
      
-
      
-Change the synopsis under 20.6.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].
-
      
-
-
-
-
-
-
-
      
-
      742. Enabling swap for proxy iterators
      
-
      Section: 20.1.1 [utility.arg.requirements] Status: Open
- Submitter: Howard Hinnant Date: 2007-10-10
      
-
      View other active issues in [utility.arg.requirements].
      
-
      View all other issues in [utility.arg.requirements].
      
-
      View all issues with Open status.
      
-
      Discussion:
      
-
      
-This issue was split from 672. 672 now just
-deals with changing the requirements of T in the Swappable
-requirement from CopyConstructible and CopyAssignable to
-MoveConstructible and MoveAssignable.
-
      
-
-
      
-This issue seeks to widen the Swappable requirement to support proxy iterators.  Here
-is example code:
-
      
-
-
      namespace Mine {
-
-template <class T>
-struct proxy {...};
+template <class T>
+struct proxy {...};
 
 template <class T>
 struct proxied_iterator
@@ -11871,224 +10689,9 @@ semantics described in this table.
 
 
 
      
-
      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:
      
-
      
-When the LWG looked at 674 in Kona the following note was made:
-
      
-
-
      
-We may need to open an issue to deal with the question of
-whether shared_ptr needs an rvalue swap.
-
      
-
-
      
-This issue was opened in response to that note.
-
      
-
-
      
-I believe allowing rvalue shared_ptrs to swap is both
-appropriate, and consistent with how other library components are currently specified.
-
      
-
-
      [
-Bellevue:
-]
      
-
-
-
      
-
      
-Concern that the three signatures for swap is needlessly complicated,
-but this issue merely brings shared_ptr into equal complexity with the
-rest of the library. Will open a new issue for concern about triplicate
-signatures.
-
      
-
      
-Adopt issue as written.
-
      
-
      
-
-
-
      Proposed resolution:
      
-
      
-Change the synopsis in 20.6.12.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);
-
      
-
-
      
-Change 20.6.12.2.4 [util.smartptr.shared.mod]:
-
      
-
-
      void swap(shared_ptr&& r);
-
      
-
-
      
-Change 20.6.12.2.9 [util.smartptr.shared.spec]:
-
      
-
-
      template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b);
-template<class T> void swap(shared_ptr<T>&& a, shared_ptr<T>& b);
-template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>&& b);
-
      
-
-
-
-
-
-
      
-
      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:
      
-
      
-Without some lifetime guarantee, it is hard to know how this type can be
-used.  Very specifically, I don't see how the current wording would
-guarantee and exception_ptr caught at the end of one thread could be safely
-stored and rethrown in another thread - the original motivation for this
-API.
-
      
-
      
-(Peter Dimov agreed it should be clearer, maybe a non-normative note to
-explain?)
-
      
-
-
      [
-Bellevue:
-]
      
-
-
-
      
-
      
-Agree the issue is real.
-
      
-
      
-Intent is lifetime is similar to a shared_ptr (and we might even want to
-consider explicitly saying that it is a shared_ptr< unspecified type >).
-
      
-
      
-We expect that most implementations will use shared_ptr, and the
-standard should be clear that the exception_ptr type is intended to be
-something whose semantics are smart-pointer-like so that the user does
-not need to worry about lifetime management. We still need someone to
-draught those words - suggest emailing Peter Dimov.
-
      
-
      
-Move to Open.
-
      
-
      
-
-
-
      Proposed resolution:
      
-
      
-Change 18.7.5 [propagation]/7:
-
      
-
-
      
--7- Returns: An exception_ptr object that refers to the currently
-handled exception or a copy of the currently handled exception, or a
-null exception_ptr object if no exception is being handled.
-The referenced object remains valid at least as long as there is an
-exception_ptr that refers to it.
-If the function needs to allocate memory and the attempt
-fails, it returns an exception_ptr object that refers to an instance of
-bad_alloc. It is unspecified whether the return values of two successive
-calls to current_exception refer to the same exception object. [Note:
-that is, it is unspecified whether current_exception creates a new copy
-each time it is called. --end note]
-
      
-
-
-
-
-
-
      
-
      746. current_exception may fail with bad_alloc
      
-
      Section: 18.7.5 [propagation] Status: 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:
      
-
      
-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:
-
      
-
      
-
      
-Any other allocation function that fails to allocate storage shall indicate
-failure only by throwing an exception of a type that would match a handler
-(15.3) of type std::bad_alloc (18.5.2.1).
-
      
-
      
-
      
-I think we should allow similar freedom here (or add a blanket
-compatible-exception freedom paragraph in 17)
-
      
-
      
-I prefer the clause 17 approach myself, and maybe clean up any outstanding
-wording that could also rely on it.
-
      
-
      
-Although filed against a specific case, this issue is a problem throughout
-the library. 
-
      
-
-
      [
-Bellevue:
-]
      
-
-
-
      
-
      
-Is issue bigger than library?
-
      
-
      
-No - Core are already very clear about their wording, which is inspiration for the issue.
-
      
-
      
-While not sold on the original 18.7.5 use case, the generalised 17.4.4.8 wording is the real issue.
-
      
-
      
-Accept the broad view and move to ready
-
      
-
      
-
-
-
      Proposed resolution:
      
-
      
-Add the following exemption clause to 17.4.4.8 [res.on.exception.handling]:
-
      
-
-
      
-A function may throw a type not listed in its Throws clause so long as it is
-derived from a class named in the Throws clause, and would be caught by an
-exception handler for the base type.
-
      
-
-
-
-
-
-
      
 
      747. We have 3 separate type traits to identify classes supporting no-throw operations
      
-
      Section: 20.4.4.3 [meta.unary.prop] Status: Open
+
      Section: 20.5.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:
      
@@ -12160,80 +10763,9 @@ Move to OPEN. Need to talk to Core about this.
 
 
 
      
-
      749. Currently has_nothrow_copy_constructor<T>::value is true if T has 'a' nothrow copy constructor.
      
-
      Section: 20.4.4.3 [meta.unary.prop] Status: Ready
- Submitter: Alisdair Meredith Date: 2007-10-10
      
-
      View other active issues in [meta.unary.prop].
      
-
      View all other issues in [meta.unary.prop].
      
-
      View all issues with Ready status.
      
-
      Discussion:
      
-
      
-Unfortunately a class can have multiple copy constructors, and I believe to
-be useful this trait should only return true is ALL copy constructors are
-no-throw.
-
      
-
      
-For instance:
-
      
-
      
-
      struct awkward {
- awkward( const awkward & ) throw() {}
- awkward( awkward & ) { throw "oops"; } };
-
      
-
      
-
-
-
      Proposed resolution:
      
-
      
-Change 20.4.4.3 [meta.unary.prop]:
-
      
-
-
      
-
      has_trivial_copy_constructor
      
-
      
-T is a trivial type (3.9) or a reference type or a class type with a trivial copy constructor
-where all copy constructors are trivial (12.8).
-
      
-
      
-
-
      
-
      has_trivial_assign
      
-
      
-T is neither const nor a reference type, and T is a trivial type (3.9)
-or a class type with a trivial copy assignment operator where all copy assignment operators are trivial (12.8).
-
      
-
      
-
-
      
-
      has_nothrow_copy_constructor
      
-
      
-has_trivial_copy_constructor<T>::value is true or T is a class type with
-a where all copy constructors that is are 
-known not to throw any exceptions or T is an
-array of such a class type
-
      
-
      
-
-
      
-
      has_nothrow_assign
      
-
      
-T is neither const nor a reference type, and
-has_trivial_assign<T>::value is true or T is a class type with a
-where all copy
-assignment operators takeing an lvalue of type T that is known not to
-throw any exceptions or T is an array of such a class type.
-
      
-
      
-
-
-
-
-
-
-
      
 
      750. The current definition for is_convertible requires that the type be
 implicitly convertible, so explicit constructors are ignored.
      
-
      Section: 20.4.5 [meta.rel] Status: Open
+
      Section: 20.5.5 [meta.rel] Status: Open
  Submitter: Alisdair Meredith Date: 2007-10-10
      
 
      View all issues with Open status.
      
 
      Discussion:
      
@@ -12321,11 +10853,11 @@ as-if rule.
 
 
      
 
      752. Allocator complexity requirement
      
-
      Section: 20.1.2 [allocator.requirements] Status: New
+
      Section: 20.1.2 [allocator.requirements] Status: Review
  Submitter: Hans Boehm Date: 2007-10-11
      
 
      View other active issues in [allocator.requirements].
      
 
      View all other issues in [allocator.requirements].
      
-
      View all issues with New status.
      
+
      View all issues with Review status.
      
 
      Discussion:
      
 
      
 Did LWG recently discuss 20.1.2 [allocator.requirements]-2, which states that "All the operations
@@ -12335,13 +10867,13 @@ 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
+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
+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
@@ -12357,10 +10889,8 @@ Change 20.1.2 [allocator.requirements]/2:
 
      
 
      
 -2- Table 39 describes the requirements on types manipulated through
-allocators. All the operations on the allocators are expected to be
-amortized constant time, except that allocate and
-construct may require time proportional to the size of the
-object allocated or constructed. Table 40 describes the
+allocators. All the operations on the allocators are expected to be
+amortized constant time. Table 40 describes the
 requirements on allocator types.
 
      
 
      
@@ -12500,189 +11030,15 @@ unfortunately pulling it back to Open.  But I'm drafting wording to atone for th
 
 
 
      
-
      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.
      
+
      758. shared_ptr and nullptr
      
+
      Section: 20.7.12.2 [util.smartptr.shared] Status: Review
+ Submitter: Joe Gottman Date: 2007-10-31
      
+
      View other active issues in [util.smartptr.shared].
      
+
      View all other issues in [util.smartptr.shared].
      
+
      View all issues with Review status.
      
 
      Discussion:
      
 
      
-A std::vector can be shrunk-to-fit via the swap idiom:
-
      
-
-
      vector<int> v;
-...
-v.swap(vector<int>(v));  // shrink to fit
-
      
-
      
-or:
-
      
-
      vector<int>(v).swap(v);  // shrink to fit
-
      
-
      
-or:
-
      
-
      swap(v, vector<int>(v));  // shrink to fit
-
      
-
      
-
-
      
-A non-binding request for shrink-to-fit can be made to a std::string via:
-
      
-
-
      string s;
-...
-s.reserve(0);
-
      
-
-
      
-Neither of these is at all obvious to beginners, and even some
-experienced C++ programmers are not aware that shrink-to-fit is
-trivially available.
-
      
-
      
-Lack of explicit functions to perform these commonly requested
-operations makes vector and string less usable for non-experts. Because
-the idioms are somewhat obscure, code readability is impaired. It is
-also unfortunate that two similar vector-like containers use different
-syntax for the same operation.
-
      
-
      
-The proposed resolution addresses these concerns. The proposed function
-takes no arguments to keep the solution simple and focused.
-
      
-
-
-
      Proposed resolution:
      
-
      
-To Class template basic_string 21.3 [basic.string] synopsis,
-Class template vector 23.2.6 [vector] synopsis, and Class
-vector<bool> 23.2.7 [vector.bool] synopsis, add:
-
      
-
-
          
-void shrink_to_fit();
-
      
-
-
      
-To basic_string capacity 21.3.4 [string.capacity] and vector
-capacity 23.2.6.2 [vector.capacity], add:
-
      
-
-
      
-
      void shrink_to_fit();
-
      
-
      
-Remarks: shrink_to_fit is a non-binding request to reduce
-capacity() to size(). [Note: The request is non-binding to
-allow latitude for implementation-specific optimizations.
--- end note]
-
      
-
      
-
-
-
-
-
-
      
-
      756. Container adaptors push
      
-
      Section: 23.2.5 [container.adaptors] Status: Open
- Submitter: Paolo Carlini Date: 2007-10-31
      
-
      View all issues with Open status.
      
-
      Discussion:
      
-
      
-After n2369 we have a single push_back overload in the sequence containers,
-of the "emplace" type. At variance with that, still in n2461, we have
-two separate overloads, the C++03 one + one taking an rvalue reference
-in the container adaptors. Therefore, simply from a consistency point of
-view, I was wondering whether the container adaptors should be aligned
-with the specifications of the sequence container themselves: thus have
-a single push along the lines:
-
      
-
-
      template<typename... _Args>
-void
-push(_Args&&... __args)
-  { c.push_back(std::forward<_Args>(__args)...); }
-
      
-
-
      [
-Related to 767
-]
      
-
-
-
-
      Proposed resolution:
      
-
      
-Change 23.2.5.1.1 [queue.defn]:
-
      
-
-
      void push(const value_type& x) { c.push_back(x); }
-void push(value_type&& x) { c.push_back(std::move(x)); }
-template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }
-
      
-
-
      
-Change 23.2.5.2 [priority.queue]:
-
      
-
-
      void push(const value_type& x) { c.push_back(x); }
-void push(value_type&& x) { c.push_back(std::move(x)); }
-template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }
-
      
-
-
      
-Change 23.2.5.2.2 [priqueue.members]:
-
      
-
-
      
-
      void push(const value_type& x);
-
      
-
      
-
      
-Effects:
-
      
-
      c.push_back(x);
-push_heap(c.begin(), c.end(), comp);
-
      
-
      
-
-
      template<class... Args> void push(value_type Args&&... x args);
-
      
-
      
-
      
-Effects:
-
      
-
      c.push_back(std::moveforward<Args>(x args)...);
-push_heap(c.begin(), c.end(), comp);
-
      
-
      
-
      
-
-
      
-Change 23.2.5.3.1 [stack.defn]:
-
      
-
-
      void push(const value_type& x) { c.push_back(x); }
-void push(value_type&& x) { c.push_back(std::move(x)); }
-template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }
-
      
-
-
-
-
-
-
-
      
-
      758. shared_ptr and nullptr
      
-
      Section: 20.6.12.2 [util.smartptr.shared] Status: Ready
- Submitter: Joe Gottman Date: 2007-10-31
      
-
      View other active issues in [util.smartptr.shared].
      
-
      View all other issues in [util.smartptr.shared].
      
-
      View all issues with Ready status.
      
-
      Discussion:
      
-
      
-Consider the following program:
+Consider the following program:
 
      
 
 
      int main() {
@@ -12774,7 +11130,7 @@ The following wording changes are less intrusive:
 
      
 
 
      
-In 20.6.12.2.1 [util.smartptr.shared.const], add:
+In 20.7.12.2.1 [util.smartptr.shared.const], add:
 
      
 
 
      shared_ptr(nullptr_t);
@@ -12832,11 +11188,28 @@ unnecessary; this is effectively an alias for the default constructor.
 
      
 
      
 
+
      [
+Sophia Antipolis:
+]
      
+
+
+
      
+
      
+We want to remove the reset functions from the proposed resolution.
+
      
+
      
+The remaining proposed resolution text (addressing the constructors) are wanted.
+
      
+
      
+Disposition: move to review. The review should check the wording in the then-current working draft.
+
      
+
      
+
 
 
 
      Proposed resolution:
      
 
      
-Add the following constructors to 20.6.12.2 [util.smartptr.shared]:
+Add the following constructors to 20.7.12.2 [util.smartptr.shared]:
 
      
 
 
      shared_ptr(nullptr_t);
@@ -12844,17 +11217,10 @@ 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]:
+Add the following constructor definitions to 20.7.12.2.1 [util.smartptr.shared.const]:
 
      
 
 
      
@@ -12905,90 +11271,7 @@ resource other than memory could not be obtained.
 
      
 
      
 
-
      
-Add the following method definitions to 20.6.12.2.4 [util.smartptr.shared.mod]:
-
      
-
-
      
-
      void reset(nullptr_t);
-
      
-
      
-
      
-Effects: Equivalent to shared_ptr(nullptr).swap(*this).
-
      
-
      
-
      
-
-
      
-
      template <class D> void reset(nullptr_t, const D d)
-
      
-
      
-
      
-Effects: Equivalent to shared_ptr(nullptr, d).swap(*this).
-
      
-
      
-
      
-
-
      
-
      template <class D, class A> void reset(nullptr_t, D d, A a);
-
      
-
      
-
      
-Effects: Equivalent to shared_ptr(nullptr, d, a).swap(*this).
-
      
-
      
-
      
-
-
-
-
-
-
-
      
-
      759. A reference is not an object
      
-
      Section: 23.1 [container.requirements] Status: Ready
- Submitter: Jens Maurer Date: 2007-11-06
      
-
      View other active issues in [container.requirements].
      
-
      View all other issues in [container.requirements].
      
-
      View all issues with Ready status.
      
-
      Discussion:
      
-
      
-23.1 [container.requirements] says:
-
      
-
-
      
--12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No 
-diagnostic required.
-
      
-
-
      
-A reference is not an object, but this sentence appears to claim so.
-
      
-
-
      
-What is probably meant here:
-
      
-
      
-An object bound to an rvalue
-reference parameter of a member function of a container shall not be
-an element of that container; no diagnostic required.
-
      
-
-
-
-
      Proposed resolution:
      
-
      
-Change 23.1 [container.requirements]:
-
      
 
-
      
--12- Objects passed to member functions of a container as rvalue references shall not be elements
-An object bound to an rvalue
-reference parameter of a member function of a container shall not be
-an element
-of that container.; Nno 
-diagnostic required.
-
      
 
 
 
@@ -13015,7 +11298,7 @@ this problem, can be efficiently implemented anyway
 
      
 
 
      [
-Related to 767
+Related to 767
 ]
      
 
 
@@ -13062,68 +11345,11 @@ sub-objects of elements of the container. No diagnostic required.
 
 
 
      
-
      761. unordered_map needs an at() member function
      
-
      Section: 23.4.1.2 [unord.map.elem] Status: Ready
- Submitter: Joe Gottman Date: 2007-11-15
      
-
      View all issues with Ready status.
      
-
      Discussion:
      
-
      
-The new member function at() was recently added to std::map().  It acts 
-like operator[](), except it throws an exception when the input key is 
-not found.  It is useful when the map is const, the value_type of the 
-key doesn't have  a default constructor, it is an error if the key is 
-not found, or the user wants to avoid accidentally adding an element to 
-the map.  For exactly these same reasons, at() would be equally useful 
-in std::unordered_map.
-
      
-
-
-
      Proposed resolution:
      
-
      
-Add the following functions to the definition of unordered_map under "lookup" (23.4.1 [unord.map]):
-
      
-
-
      mapped_type& at(const key_type& k);
-const mapped_type &at(const key_type &k) const;
-
      
-
-
      
-Add the following definitions to 23.4.1.2 [unord.map.elem]:
-
      
-
-
      
-
      mapped_type& at(const key_type& k);
-const mapped_type &at(const key_type &k) const;
-
      
-
      
-
      
-Returns: A reference to x.second, where x is the (unique) element 
-whose key is equivalent to k.
-
      
-
      
-Throws: An exception object of type out_of_range if no such element 
-is present.
-
      
-
      
-
      
-
-
      [
-Bellevue:  Editorial note: the "(unique)" differs from map.
-]
      
-
-
-
-
-
-
-
-
      
 
      762. std::unique_ptr requires complete type?
      
-
      Section: 20.6.11 [unique.ptr] Status: Open
+
      Section: 20.7.11 [unique.ptr] Status: Ready
  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.
      
+
      View all issues with Ready status.
      
 
      Discussion:
      
 
      
 In contrast to the proposed std::shared_ptr, std::unique_ptr
@@ -13158,22 +11384,22 @@ produce new wording.
 
      Proposed resolution:
      
 
      
 The proposed changes in the following revision refers to the current state of
-N2521 including the assumption that 20.6.11.4 [unique.ptr.compiletime] will be removed
-according to the current state of 740.
+N2521 including the assumption that 20.7.11.4 [unique.ptr.compiletime] will be removed
+according to the current state of 740.
 
      
 
      
 The specialization unique_ptr<T[]> has some more restrictive constraints on
 type-completeness on T than unique_ptr<T>. The following proposed wordings
 try to cope with that. If the committee sees less usefulness on relaxed
 constraints on unique_ptr<T[]>, the alternative would be to stop this relaxation
-e.g. by adding one further bullet to 20.6.11.3 [unique.ptr.runtime]/1:
+e.g. by adding one further bullet to 20.7.11.3 [unique.ptr.runtime]/1:
 "T shall be a complete type, if used as template argument of
 unique_ptr<T[], D>
 
      
 
      
-This issue has some overlap with 673, but it seems not to cause any
+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
+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,
@@ -13185,7 +11411,7 @@ current specification of unique_ptr.
 
        
 
      1. 
 
        
-In 20.6.11 [unique.ptr]/2 add as the last sentence to the existing para:
+In 20.7.11 [unique.ptr]/2 add as the last sentence to the existing para:
 
        
 
 
        
@@ -13204,7 +11430,7 @@ function. -- end note ]
 
 
      2. 
 
        
-20.6.11.2.1 [unique.ptr.single.ctor]/1: No changes necessary.
+20.7.11.2.1 [unique.ptr.single.ctor]/1: No changes necessary.
 
        
 
 
        
@@ -13218,14 +11444,14 @@ The current wording says just this.
 
 
      3. 
 
        
-In 20.6.11.2.1 [unique.ptr.single.ctor]/5 change the requires clause to say:
+In 20.7.11.2.1 [unique.ptr.single.ctor]/5 change the requires clause to say:
 
        
 
 
        
 
        
 Requires: The expression D()(p) shall be well formed. The default constructor
 of D shall not throw an exception.
-D must shall not be a reference type.
+D must not be a reference type.
 
 D shall be default constructible, and that construction
 shall not throw an exception.
@@ -13255,7 +11481,7 @@ again requires Completeness of Y, if !SameType<X, Y>
 
 
      4. 
 
        
-Merge 20.6.11.2.1 [unique.ptr.single.ctor]/12+13 thereby removing the sentence
+Merge 20.7.11.2.1 [unique.ptr.single.ctor]/12+13 thereby removing the sentence
 of 12, but transferring the "requires" to 13:
 
        
 
@@ -13274,10 +11500,20 @@ pointer and the D deleter are well-formed and well-defined.
 
        5. 
 
 
      5. 
-20.6.11.2.1 [unique.ptr.single.ctor]/17: No changes necessary.
+20.7.11.2.1 [unique.ptr.single.ctor]/17: No changes necessary.
 
        6. 
 
      6. 
-
        20.6.11.2.1 [unique.ptr.single.ctor]/21: No changes necessary.
        
+
        20.7.11.2.1 [unique.ptr.single.ctor]/21:
        
+
+
        
+Requires: If D is not a reference type, construction of
+the deleter D from an rvalue of type E shall be well
+formed and shall not throw an exception. If D is a reference
+type, then E shall be the same type as D (diagnostic
+required). U* shall be implicitly convertible to T*.
+[Note: These requirements imply that T and U
+be complete types. -- end note]
+
        
 
 
        [
 N.B.: The current wording of 21 already implicitly guarantees that U
@@ -13290,12 +11526,14 @@ e.g. "U shall be a complete type."
 
 
      7. 
 
        
-20.6.11.2.2 [unique.ptr.single.dtor]: Just before p1 add a new paragraph:
+20.7.11.2.2 [unique.ptr.single.dtor]: Just before p1 add a new paragraph:
 
        
 
        
 
        
 Requires: The expression get_deleter()(get()) shall be well-formed,
 shall have well-defined behavior, and shall not throw exceptions.
+[Note: The use of default_delete requires T to
+be a complete type. -- end note]
 
        
 
        [
 N.B.: This requirement ensures that the whole responsibility on
@@ -13307,7 +11545,7 @@ type-completeness of T is delegated to this expression.
 
 
      8. 
 
        
-20.6.11.2.3 [unique.ptr.single.asgn]/1: No changes necessary, except the
+20.7.11.2.3 [unique.ptr.single.asgn]/1: No changes necessary, except the
 current editorial issue, that "must shall" has to be changed to
 "shall", but this change is not a special part of this resolution.
 
        
@@ -13321,8 +11559,17 @@ further requirements on the requirements of the effects clause
 
 
      9. 
 
        
-20.6.11.2.3 [unique.ptr.single.asgn]/6: No changes necessary.
+20.7.11.2.3 [unique.ptr.single.asgn]/6:
 
        
+
+
        
+Requires: Assignment of the deleter D from an rvalue
+D shall not throw an exception. U* shall be implicitly
+convertible to T*.
+[Note: These requirements imply that T and U
+be complete types. -- end note]
+
        
+
 
        [
 N.B.: The current wording of p. 6 already implicitly guarantees that
 U is completely defined, because it requires that Convertible<U*, T*>
@@ -13333,7 +11580,7 @@ is true, see (6)+(8).
 
 
      10. 
 
        
-20.6.11.2.3 [unique.ptr.single.asgn]/11: No changes necessary.
+20.7.11.2.3 [unique.ptr.single.asgn]/11: No changes necessary.
 
        
 
        [
 N.B.: Delegation to requirements of effects clause is sufficient.
@@ -13342,16 +11589,23 @@ N.B.: Delegation to requirements of effects clause is sufficient.
 
        11. 
 
 
      11. 
-20.6.11.2.4 [unique.ptr.single.observers]/1+4+7+9+11: No changes necessary.
+20.7.11.2.4 [unique.ptr.single.observers]/1+4+7+9+11:
 
        12. 
 
+
        
+
        T* operator->() const;
        
+
        
+Note: Use typically requires T shall be complete. -- end note]
+
        
+
        
+
 
      12. 
-20.6.11.2.5 [unique.ptr.single.modifiers]/1: No changes necessary.
+20.7.11.2.5 [unique.ptr.single.modifiers]/1: No changes necessary.
 
        13. 
 
 
      13. 
 
        
-20.6.11.2.5 [unique.ptr.single.modifiers]/4: Just before p. 4 add a new paragraph:
+20.7.11.2.5 [unique.ptr.single.modifiers]/4: Just before p. 4 add a new paragraph:
 
        
 
        
 Requires: The expression get_deleter()(get()) shall be well-formed,
@@ -13360,54 +11614,28 @@ shall have well-defined behavior, and shall not throw exceptions.
 
        14. 
 
 
      14. 
-20.6.11.2.5 [unique.ptr.single.modifiers]/7: No changes necessary.
+20.7.11.2.5 [unique.ptr.single.modifiers]/7: No changes necessary.
 
        15. 
 
 
      15. 
 
        
-20.6.11.3.1 [unique.ptr.runtime.ctor]: Add one additional paragraph just
-before the current one:
+20.7.11.3 [unique.ptr.runtime]: Add one additional bullet on paragraph 1:
 
        
 
 
        
 
        
-Requires: T shall be a complete type.
+A specialization for array types is provided with a slightly altered interface.
 
        
-
        [
-N.B.: We need this requirement, because otherwise it is not
-guaranteed that the c'tors can fulfill their requirements to reject
-any type that is convertible to T*.
-]
        
-
-
        
-
        16. 
 
+
          
 
        • 
-20.6.11.3.2 [unique.ptr.runtime.observers]/1: Change the clause to says:
+...
 
          • 
-
-
          
-Requires: i < the size of the array to which the stored pointer
-points. T shall be a complete type.
-
          
-
 
        • 
-
          
-20.6.11.3.3 [unique.ptr.runtime.modifiers]/1: Change the first sentence of the
-paragraph to say:
-
          
-
          
-
          
-Requires: T shall be a complete type. Does not accept pointer types
-which are convertible to T* (diagnostic required). [ Note: ...]
-
          
-
          [
-N.B. Similar to (15) we need this requirement such that reset can
-reject types which are convertible to T*
-]
          
-
+T shall be a complete type.
+
          • 
+
        
 
        
-
 
        16. 
 
      
 
@@ -13507,157 +11735,233 @@ popular implementations for some standard Containers.
 
 
 
      
-
      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].
      
+
      769. std::function should use nullptr_t instead of "unspecified-null-pointer-type"
      
+
      Section: 20.6.15.2 [func.wrap.func] Status: Ready
+ Submitter: Daniel Krügler Date: 2008-01-10
      
 
      View all issues with Ready status.
      
 
      Discussion:
      
 
      
-23.1 [container.requirements]p10 states:
-
      
-
-
      
-
      
-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:
+N2461 already replaced in 20.6.15.2 [func.wrap.func] it's originally proposed
+(implicit) conversion operator to "unspecified-bool-type" by the new
+explicit bool conversion, but the inverse conversion should also
+use the new std::nullptr_t type instead of "unspecified-null-pointer-
+type".
 
      
-
        
 
-
      • [...]
        • 
 
-
      • no erase(), pop_back() or pop_front() function throws an exception.
        • 
+
        Proposed resolution:
        
 
-
      
-
      
+
      
+In 20.6 [function.objects], header <functional> synopsis replace:
+
      
+
+
      template<class R, class... ArgTypes>
+  bool operator==(const function<R(ArgTypes...)>&, unspecified-null-pointer-type nullptr_t);
+template<class R, class... ArgTypes>
+  bool operator==(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>&);
+template<class R, class... ArgTypes>
+  bool operator!=(const function<R(ArgTypes...)>&, unspecified-null-pointer-type nullptr_t);
+template<class R, class... ArgTypes>
+  bool operator!=(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>&);
+
      
 
 
      
-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():
+In the class function synopsis of 20.6.15.2 [func.wrap.func] replace
 
      
 
-
      
-No erase() function throws an exception unless that exception
-is thrown by the container's Hash or Pred object (if any).
-
      
+
      function(unspecified-null-pointer-type nullptr_t);
+...
+function& operator=(unspecified-null-pointer-type nullptr_t);
+
      
 
 
      
-Summary:
+In 20.6.15.2 [func.wrap.func], "Null pointer comparisons" replace:
 
      
 
+
      template <class R, class... ArgTypes>
+  bool operator==(const function<R(ArgTypes...)>&, unspecified-null-pointer-type nullptr_t);
+template <class R, class... ArgTypes>
+  bool operator==(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>&);
+template <class R, class... ArgTypes>
+  bool operator!=(const function<R(ArgTypes...)>&, unspecified-null-pointer-type nullptr_t);
+template <class R, class... ArgTypes>
+  bool operator!=(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>&);
+
      
+
 
      
-According to 23.1 [container.requirements]p10 no
-erase() function should throw an exception unless otherwise
-specified. Although does not explicitly mention 23.1.3.1 [unord.req.except], this section offers additional guarantees
-for unordered containers, allowing erase() to throw if
-predicate or hash function throws.
+In 20.6.15.2.1 [func.wrap.func.con], replace
 
      
 
+
      function(unspecified-null-pointer-type nullptr_t);
+...
+function& operator=(unspecified-null-pointer-type nullptr_t);
+
      
+
 
      
-In 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.
+In 20.6.15.2.6 [func.wrap.func.nullptr], replace
 
      
 
+
      template <class R, class... ArgTypes>
+  bool operator==(const function<R(ArgTypes...)>& f, unspecified-null-pointer-type nullptr_t);
+template <class R, class... ArgTypes>
+  bool operator==(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>& f);
+
      
+
 
      
-So:
+and replace
 
      
 
-
        
-
      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. 
-
      
+
      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);
+
      
 
 
-
      Proposed resolution:
      
+
+
+
+
+
      
+
      771. Impossible throws clause in [string.conversions]
      
+
      Section: 21.4 [string.conversions] Status: Ready
+ Submitter: Daniel Krügler Date: 2008-01-13
      
+
      View other active issues in [string.conversions].
      
+
      View all other issues in [string.conversions].
      
+
      View all issues with Ready status.
      
+
      Discussion:
      
 
      
-Create a new sub-section of 23.1.2 [associative.reqmts] (perhaps [associative.req.except]) titled "Exception
-safety guarantees".
+The new to_string and to_wstring functions described in 21.4 [string.conversions]
+have throws clauses (paragraphs 8 and 16) which say:
 
      
 
 
      
+Throws: nothing
+
      
+
 
      
-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).
+Since all overloads return either a std::string or a std::wstring by value
+this throws clause is impossible to realize in general, since the basic_string
+constructors can fail due to out-of-memory conditions. Either these throws
+clauses should be removed or should be more detailled like:
 
      
 
+
      
+Throws: Nothing if the string construction throws nothing
+
      
+
 
      
-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.
+Further there is an editorial issue in p. 14: All three to_wstring
+overloads return a string, which should be wstring instead (The
+header <string> synopsis of 21.2 [string.classes] is correct in this
+regard).
 
      
 
+
+
+
      Proposed resolution:
      
 
      
-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).
+In 21.4 [string.conversions], remove the paragraphs 8 and 16.
 
      
+
+
      
+
      string to_string(long long val); 
+string to_string(unsigned long long val); 
+string to_string(long double val); 
+
      
+
      
+Throws: nothing
+
      
+
      
+
+
      
+
      wstring to_wstring(long long val); 
+wstring to_wstring(unsigned long long val); 
+wstring to_wstring(long double val); 
+
      
+
      
+Throws: nothing
+
      
 
      
 
+
+
+
+
+
+
      
+
      772.  Impossible return clause in [string.conversions]
      
+
      Section: 21.4 [string.conversions] Status: Ready
+ Submitter: Daniel Krügler Date: 2008-01-13
      
+
      View other active issues in [string.conversions].
      
+
      View all other issues in [string.conversions].
      
+
      View all issues with Ready status.
      
+
      Discussion:
      
 
      
-Change 23.1.3.1 [unord.req.except]p1:
+The return clause 21.4 [string.conversions]/paragraph 15 of the new to_wstring
+overloads says:
 
      
 
 
      
-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).
+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.
 
      
 
 
      
-Change 23.1 [container.requirements]p10 to add references to new sections:
+Problem is: There does not exist any wsprintf function in C99 (I checked
+the 2nd edition of ISO 9899, and the first and the second corrigenda from
+2001-09-01 and 2004-11-15). What probably meant here is the function
+swprintf from <wchar.h>/<cwchar>, but this has the non-equivalent
+declaration:
+
      
+
+
      int swprintf(wchar_t * restrict s, size_t n,
+const wchar_t * restrict format, ...);
+
      
+
+
      
+therefore the paragraph needs to mention the size_t parameter n.
+
      
+
+
+
+
      Proposed resolution:
      
+
      
+Change the current wording of 21.4 [string.conversions]/p. 15 to:
 
      
 
 
      
-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:
+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.
 
      
 
 
      
-Change 23.1 [container.requirements]p10 referring to 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:
 
      
 
 
      
-
        
-
      • 
-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]).
-
        • 
-
      
+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.
 
      
 
 
@@ -13666,333 +11970,162 @@ Compare object (if any; see [associative.reqmts]).
 
 
 
      
-
      767. Forwarding and backward compatibility
      
+
      774. Member swap undefined for most containers
      
 
      Section: 23 [containers] Status: Open
- Submitter: Sylvain Pion Date: 2007-12-28
      
+ 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:
      
 
      
-Playing with g++'s C++0X mode, I noticed that the following
-code, which used to compile:
+It appears most containers declare but do not define a member-swap
+function.
 
      
 
-
      #include <vector>
-
-int main()
-{
-    std::vector<char *> v;
-    v.push_back(0);
-}
-
      
-
 
      
-now fails with the following error message:
+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])
 
      
 
-
      .../include/c++/4.3.0/ext/new_allocator.h: In member
-function 'void __gnu_cxx::new_allocator<_Tp>::construct(_Tp*,
-_Args&& ...) [with _Args = int, _Tp = char*]':
-.../include/c++/4.3.0/bits/stl_vector.h:707: instantiated from 'void
-std::vector<_Tp, _Alloc>::push_back(_Args&& ...) [with
-_Args = int, _Tp = char*, _Alloc = std::allocator<char*>]'
-test.cpp:6: instantiated from here
-.../include/c++/4.3.0/ext/new_allocator.h:114: error: invalid
-conversion from 'int' to 'char*'
-
      
-
 
      
-As far as I know, g++ follows the current draft here.
+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.
 
      
+
 
      
-Does the committee really intend to break compatibility for such cases?
+A quick survey of clause 23 shows that the following containers provide a
+definition for member-swap:
 
      
 
-
      [
-Sylvain adds: 
-]
      
-
+
      array
+queue
+stack
+vector
+
      
 
-
      
 
      
-I just noticed that std::pair has the same issue.
-The following now fails with GCC's -std=c++0x mode:
+Whereas the following declare it, but do not define the semantics:
 
      
 
-
      #include <utility>
-
-int main()
-{
-   std::pair<char *, char *> p (0,0);
-}
+
      deque
+list
+map
+multimap
+multiset
+priority_queue
+set
+unordered_map
+unordered_multi_map
+unordered_multi_set
+unordered_set
 
      
 
 
      
-I have not made any general audit for such problems elsewhere.
+Suggested resolution:
 
      
+
      
+Provide a definition for each of the affected containers...
 
      
 
 
      [
-Related to 756
-]
      
-
-
-
      [
 Bellevue:
 ]
      
 
 
 
      
-
      
-Motivation is to handle the old-style int-zero-valued NULL pointers.
-Problem: this solution requires concepts in some cases, which some users
-will be slow to adopt. Some discussion of alternatives involving
-prohibiting variadic forms and additional library-implementation
-complexity.
-
      
-
      
-Discussion of "perfect world" solutions, the only such solution put
-forward being to retroactively prohibit use of the integer zero for a
-NULL pointer. This approach was deemed unacceptable given the large
-bodies of pre-existing code that do use integer zero for a NULL pointer.
-
      
-
      
-Another approach is to change the member names. Yet another approach is
-to forbid the extension in absence of concepts.
-
      
-
      
-Resolution: These issues (756, 767, 760, 763) will be subsumed into a
-paper to be produced by Alan Talbot in time for review at the 2008
-meeting in France. Once this paper is produced, these issues will be
-moved to NAD.
-
      
+Move to Open and ask Alisdair to provide wording.
 
      
 
 
-
 
      Proposed resolution:
      
 
      
-Add the following rows to Table 90 "Optional sequence container operations", 23.1.1 [sequence.reqmts]:
+Wording provided in
+N2590.
 
      
 
-
      
-
-
-
-
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
 
-
-
-
-
-
-
 
-
      expression return type assertion/note
      pre-/post-condition      		 container
      
-a.push_front(t)
-
-void
-
-a.insert(a.begin(), t)
      
-Requires: T shall be CopyConstructible.
-      		
-list, deque
-
      
-a.push_front(rv)
-
-void
-
-a.insert(a.begin(), rv)
      
-Requires: T shall be MoveConstructible.
-      		
-list, deque
-
      
-a.push_back(t)
-
-void
-
-a.insert(a.end(), t)
      
-Requires: T shall be CopyConstructible.
-      		
-list, deque, vector, basic_string
-
      
-a.push_back(rv)
-
-void
-
-a.insert(a.end(), rv)
      
-Requires: T shall be MoveConstructible.
-      		
-list, deque, vector, basic_string
-
      
-
      
 
+
      
+
      776. Undescribed assign function of std::array
      
+
      Section: 23.2.1 [array] Status: Ready
+ Submitter: Daniel Krügler Date: 2008-01-20
      
+
      View other active issues in [array].
      
+
      View all other issues in [array].
      
+
      View all issues with Ready status.
      
+
      Discussion:
      
 
      
-Change the synopsis in 23.2.2 [deque]:
+The class template array synopsis in 23.2.1 [array]/3 declares a member
+function
 
      
 
-
      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);
+
      void assign(const T& u);
 
      
 
 
      
-Change 23.2.2.3 [deque.modifiers]:
+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.
 
      
 
-
      void push_front(const T& x);
-void push_front(T&& x);
-void push_back(const T& x);
-void push_back(T&& x);
-template <class... Args> requires Constructible<T, Args&&...> void push_front(Args&&... args);
-template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
-
      
-
 
      
-Change the synopsis in 23.2.4 [list]:
+I found only one reference to this function in the issue list,
+588 where the question is raised:
 
      
 
-
      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);
-
      
+
      
+what's the effect of calling assign(T&) on a zero-sized array?
+
      
 
 
      
-Change 23.2.4.3 [list.modifiers]:
+which does not answer the basic question of this issue.
 
      
 
-
      void push_front(const T& x);
-void push_front(T&& x);
-void push_back(const T& x);
-void push_back(T&& x);
-template <class... Args> requires Constructible<T, Args&&...> void push_front(Args&&... args);
-template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
-
      
-
 
      
-Change the synopsis in 23.2.6 [vector]:
+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.
 
      
 
-
      void push_back(const T& x);
-void push_back(T&& x);
-template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
-
      
 
+
      Proposed resolution:
      
 
      
-Change 23.2.6.4 [vector.modifiers]:
+Just after the section 23.2.1.4 [array.data] add the following new section:
 
      
 
-
      void push_back(const T& x);
-void push_back(T&& x);
-template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
-
      
-
-
-
-
-
-
-
-
      
-
      768. Typos in [atomics]?
      
-
      Section: 29.4.3 [atomics.types.generic] Status: Ready
- Submitter: Alberto Ganesh Barbati Date: 2007-12-28
      
-
      View all issues with Ready status.
      
-
      Discussion:
      
 
      
-in the latest publicly available draft, paper
-N2641,
-in section 29.4.3 [atomics.types.generic], the following specialization of the template
-atomic<> is provided for pointers:
+23.2.1.5 array::fill [array.fill]
 
      
 
-
      template <class T> struct atomic<T*> : atomic_address { 
-  T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
-  T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
-
-  atomic() = default; 
-  constexpr explicit atomic(T); 
-  atomic(const atomic&) = delete; 
-  atomic& operator=(const atomic&) = delete; 
-
-  T* operator=(T*) volatile; 
-  T* operator++(int) volatile; 
-  T* operator--(int) volatile; 
-  T* operator++() volatile; 
-  T* operator--() volatile; 
-  T* operator+=(ptrdiff_t) volatile;
-  T* operator-=(ptrdiff_t) volatile; 
-};
-
      
+
      
+
      void fill(const T& u);
+
      
 
 
      
-First of all, there is a typo in the non-default constructor which
-should take a T* rather than a T.
+1: Effects: fill_n(begin(), N, u)
 
      
+
      
 
 
      
-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:
+[N.B: I wonder, why class array does not have a "modifiers"
+section. If it had, then assign would naturally belong to it]
 
      
 
-
      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.
+Change the synopsis in 23.2.1 [array]/3:
 
      
 
-
      
-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.
-
      
+
      template <class T, size_t N>
+struct array { 
+  ...
+  void assign fill(const T& u);
+  ...
+
      
 
-
      
-Is there a true intent to remove them from the specialization or are
-they just missing from the definition because of a mistake?
-
      
 
 
      [
 Bellevue:
@@ -14001,46 +12134,40 @@ Bellevue:
 
 
      
 
      
-The proposed revisions are accepted.
+Suggest substituting "fill" instead of "assign".
 
      
 
      
-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.
+Set state to Review given substitution of "fill" for "assign".
 
      
 
      
 
 
-
      Proposed resolution:
      
+
+
+
      
+
      779. Resolution of #283 incomplete
      
+
      Section: 25.2.8 [alg.remove] Status: Ready
+ Submitter: Daniel Krügler Date: 2008-01-25
      
+
      View all other issues in [alg.remove].
      
+
      View all issues with Ready status.
      
+
      Discussion:
      
 
      
-Change the synopsis in 29.4.3 [atomics.types.generic]:
+The resolution of 283 did not resolve similar necessary changes for algorithm
+remove_copy[_if],
+which seems to be an oversight.
 
      
 
-
      template <class T> struct atomic<T*> : atomic_address { 
-  void store(T*, memory_order = memory_order_seq_cst) volatile;
-  T* load( memory_order = memory_order_seq_cst ) volatile;
-  T* swap( T*, memory_order = memory_order_seq_cst ) volatile;
-  bool compare_swap( T*&, T*, memory_order, memory_order ) volatile;
-  bool compare_swap( T*&, T*, memory_order = memory_order_seq_cst ) volatile;
 
-  T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
-  T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
-
-  atomic() = default; 
-  constexpr explicit atomic(T*); 
-  atomic(const atomic&) = delete; 
-  atomic& operator=(const atomic&) = delete; 
+
      Proposed resolution:
      
+
      
+In 25.2.8 [alg.remove]/p.6, replace the N2461 requires clause with:
+
      
 
-  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; 
-};
-
      
+
      
+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.
+
      
 
 
 
@@ -14048,87 +12175,80 @@ Change the synopsis in 29.4.3 [atomics.types.generic]:
 
 
 
      
-
      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
      
+
      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:
      
 
      
-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".
+Though issue 283 has fixed many open issues, it seems that some are still open:
 
      
 
-
-
      Proposed resolution:
      
-
 
      
-In 20.5 [function.objects], header <functional> synopsis replace:
+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:
 
      
 
-
      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...)>&);
-
      
+
        
+
      • 
+no assignment requirements are specified (neither implicit nor explicit).
+
        • 
 
-
        
-In the class function synopsis of 20.5.15.2 [func.wrap.func] replace
-
        
+
      • 
+the effects clause just speaks of "merges", which is badly worded
+near to a circular definition.
+
        • 
 
-
        function(unspecified-null-pointer-type nullptr_t);
-...
-function& operator=(unspecified-null-pointer-type nullptr_t);
-
        
+
      • 
+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)
+
        • 
+
      
 
-
      
-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...)>&);
-
      
 
+
      Proposed resolution:
      
 
      
-In 20.5.15.2.1 [func.wrap.func.con], replace
+In 25.3.4 [alg.merge] replace p.1+ 2:
 
      
 
-
      function(unspecified-null-pointer-type nullptr_t);
-...
-function& operator=(unspecified-null-pointer-type nullptr_t);
-
      
-
+
      
 
      
-In 20.5.15.2.6 [func.wrap.func.nullptr], replace
+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.
 
      
 
-
      template <class R, class... ArgTypes>
-  bool operator==(const function<R(ArgTypes...)>& f, unspecified-null-pointer-type nullptr_t);
-template <class R, class... ArgTypes>
-  bool operator==(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>& f);
-
      
-
 
      
-and replace
+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.
 
      
+
      
 
-
      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);
-
      
+
      
+[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]
+
      
 
 
 
@@ -14136,648 +12256,524 @@ template <class R, class... ArgTypes>
 
 
 
      
-
      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.
      
+
      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:
      
 
      
-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.
+Table 16 of TR1 requires that all Pseudo Random Number generators have a
 
      
 
+
      seed(integer-type s)
+
      
 
-
      Proposed resolution:
      
 
      
-In 20.5 [function.objects], header <functional> synopsis, just below of
+member function that is equivalent to:
 
      
 
-
      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...)>&&);
+
      mygen = Generator(s)
 
      
 
 
      
-In 20.5.15.2 [func.wrap.func] class function definition, change
+But the generators xor_combine and discard_block have no such seed member, only the
 
      
 
-
      void swap(function&&);
+
      template <class Gen>
+seed(Gen&);
 
      
 
 
      
-In 20.5.15.2 [func.wrap.func], just below of
+member, which will not accept an integer literal as an argument: something that appears to violate the intent of Table 16.
 
      
 
-
      template <class R, class... ArgTypes>
-  void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&);
-template <class R, class... ArgTypes>
-  void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&);
-template <class R, class... ArgTypes>
-  void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&&);
-
      
-
 
      
-In 20.5.15.2.2 [func.wrap.func.mod] change
+So... is this a bug in TR1?
 
      
 
-
      void swap(function&& other);
-
      
-
-
      
-In 20.5.15.2.7 [func.wrap.func.alg] add the two overloads
+
      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.
 
      
 
-
      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);
-
      
+
      [
+Jens adds:
+]
      
+
+
+
      
+Both engines do have the necessary
+constructor, therefore the omission of the seed() member
+functions appears to be an oversight.
+
      
+
 
 
+
      Proposed resolution:
      
+
      
+
      
+
 
 
 
 
 
      
-
      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.
      
+
      787. complexity of binary_search
      
+
      Section: 25.3.3.4 [binary.search] Status: Ready
+ Submitter: Daniel Krügler Date: 2007-09-08
      
+
      View all issues with Ready status.
      
 
      Discussion:
      
 
      
-The new to_string and to_wstring functions described in 21.4 [string.conversions]
-have throws clauses (paragraphs 8 and 16) which say:
+In 25.3.3.4 [binary.search]/3 the complexity of binary_search is described as
 
      
 
 
      
-Throws: nothing
+At most log(last - first) + 2 comparisons.
 
      
 
 
      
-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:
+This should be precised and brought in line with the nomenclature used for
+lower_bound, upper_bound, and equal_range.
 
      
 
-
      
-Throws: Nothing if the string construction throws nothing
-
      
-
 
      
-Further there is an editorial issue in p. 14: All three to_wstring
-overloads return a string, which should be wstring instead (The
-header <string> synopsis of 21.2 [string.classes] is correct in this
-regard).
+All existing libraries I'm aware of, delegate to
+lower_bound (+ one further comparison). Since
+issue 384
+has now WP status, the resolution of #787 should
+be brought in-line with 384 by changing the + 2
+to + O(1).
 
      
 
+
      [
+Sophia Antipolis:
+]
      
+
+
+
      
+Alisdair prefers to apply an upper bound instead of O(1), but that would
+require fixing for lower_bound, upper_bound etc. as well. If he really
+cares about it, he'll send an issue to Howard.
+
      
+
 
 
 
      Proposed resolution:
      
 
      
-In 21.4 [string.conversions], remove the paragraphs 8 and 16.
+Change 25.3.3.4 [binary.search]/3
 
      
 
 
      
-
      string to_string(long long val); 
-string to_string(unsigned long long val); 
-string to_string(long double val); 
-
      
-
      
-Throws: nothing
-
      
-
      
-
-
      
-
      wstring to_wstring(long long val); 
-wstring to_wstring(unsigned long long val); 
-wstring to_wstring(long double val); 
-
      
-
      
-Throws: nothing
-
      
+Complexity: At most log2(last - first) + 2 O(1) comparisons.
 
      
 
 
 
 
 
-
 
      
-
      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].
      
+
      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 return clause 21.4 [string.conversions]/paragraph 15 of the new to_wstring
-overloads says:
+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:
 
      
 
 
      
-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.
+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.
 
      
 
 
      
-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:
+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).
 
      
 
-
      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.
+Also I would prefer to be explicit about calling fail() here
+(there is no operator void*() anymore.)
 
      
 
 
-
 
      Proposed resolution:
      
 
      
-Change the current wording of 21.4 [string.conversions]/p. 15 to:
-
      
-
-
      
-Returns: eEach function returns a
-wstring object holding the character representation of the
-value of its argument that would be generated by calling
-wsswprintf(buf, bufsz, fmt,
-val) with a format specifier fmt of L"%lld",
-L"%ulld", or L"%f", respectively, where buf
-designates an internal character buffer of sufficient size bufsz.
-
      
-
-
      
-[Hint to the editor: The resolution also adds to mention the name of
-the format specifier "fmt"]
-
      
-
-
      
-I also would like to remark that the current wording of it's equivalent
-paragraph 7 should also mention the meaning of buf and fmt.
-
      
-
-
      
-Change the current wording of 21.4 [string.conversions]/p. 7 to:
+Change 24.5.1 [istream.iterator]/1:
 
      
 
 
      
-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.
+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.
 
      
 
 
 
 
 
-
 
      
-
      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].
      
+
      793. discrete_distribution missing constructor
      
+
      Section: 26.4.8.5.1 [rand.dist.samp.discrete] Status: Open
+ Submitter: P.J. Plauger Date: 2008-02-09
      
+
      View other active issues in [rand.dist.samp.discrete].
      
+
      View all other issues in [rand.dist.samp.discrete].
      
 
      View all issues with Open status.
      
 
      Discussion:
      
 
      
-It appears most containers declare but do not define a member-swap
-function.
-
      
-
-
      
-This is unfortunate, as all overload the swap algorithm to call the
-member-swap function!
-(required for swappable guarantees [Table 37] and Container Requirements
-[Table 87])
-
      
-
-
      
-Note in particular that Table 87 gives semantics of a.swap(b) as swap(a,b),
-yet for all containers we define swap(a,b) to call a.swap(b) - a circular
-definition.
-
      
-
-
      
-A quick survey of clause 23 shows that the following containers provide a
-definition for member-swap:
+discrete_distribution should have a constructor like:
 
      
 
-
      array
-queue
-stack
-vector
+
      template<class _Fn>
+  discrete_distribution(result_type _Count, double _Low, double _High,
+                        _Fn& _Func);
 
      
 
 
      
-Whereas the following declare it, but do not define the semantics:
+(Makes it easier to fill a histogram with function values over a range.)
 
      
 
-
      deque
-list
-map
-multimap
-multiset
-priority_queue
-set
-unordered_map
-unordered_multi_map
-unordered_multi_set
-unordered_set
-
      
+
      [
+Bellevue:
+]
      
+
 
-
      
-Suggested resolution:
-
      
 
      
-Provide a definition for each of the affected containers...
+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.
 
      
 
 
      [
-Bellevue:
+Sophia Antipolis:
 ]
      
 
 
 
      
-Move to Open and ask Alisdair to provide wording.
-
      
-
-
-
      Proposed resolution:
      
 
      
-Wording provided in
-N2590.
+Bill is not requesting this.
 
      
-
-
-
-
-
-
      
-
      775. Tuple indexing should be unsigned?
      
-
      Section: 20.3.1.4 [tuple.helper] Status: Ready
- Submitter: Alisdair Meredith Date: 2008-01-16
      
-
      View all issues with Ready status.
      
-
      Discussion:
      
 
      
-The tuple element access API identifies the element in the sequence
-using signed integers, and then goes on to enforce the requirement that
-I be >= 0.  There is a much easier way to do this - declare I as
-unsigned.
+Marc Paterno: _Fn cannot return negative values at the points where the
+function is sampled. It is sampled in the middle of each bin. _Fn cannot
+return 0 everywhere it is sampled.
 
      
 
      
-In fact the proposal is to use std::size_t, matching the type used in the tuple_size API.
+Jens: lambda expressions are rvalues
 
      
 
      
-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.
+Add a library issue to provide an
+initializer_list<double> constructor for
+discrete_distribution.
 
      
 
      
-In addition to tuple, update the API applies to
-pair and array, and should be updated
-accordingly.
+Marc Paterno: dislikes reference for _Fn parameter. Make it pass-by-value (to use lambda),
+use std::ref to wrap giant-state function objects.
 
      
-
 
      
-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.
+Daniel: See random_shuffle, pass-by-rvalue-reference.
 
      
-
-
-
      Proposed resolution:
      
 
      
-Update header <utility> synopsis in 20.2 [utility]
+Daniel to draft wording.
 
      
-
      // 20.2.3, tuple-like access to pair:
-template <class T> class tuple_size;
-template <intsize_t I, class T> class tuple_element;
+
      
 
-template <class T1, class T2> struct tuple_size<std::pair<T1, T2> >;
-template <class T1, class T2> struct tuple_element<0, std::pair<T1, T2> >;
-template <class T1, class T2> struct tuple_element<1, std::pair<T1, T2> >;
+
      [
+Pre San Francisco, Daniel provided wording:
+]
      
 
-template<intsize_t I, class T1, class T2>
-  Ptypename tuple_element<I, std::pair<T1, T2> >::type & get(std::pair<T1, T2>&);
-template<intsize_t I, class T1, class T2>
-  const Ptypename tuple_element<I, std::pair<T1, T2> >::type & get(const std::pair<T1, T2>&);
-
      
-
      
-Update 20.2.3 [pairs] Pairs
-
      
-
      template<intsize_t I, class T1, class T2>
-  Ptypename tuple_element<I, std::pair<T1, T2> >::type & get(pair<T1, T2>&);
-template<intsize_t I, class T1, class T2>
-  const Ptypename tuple_element<I, std::pair<T1, T2> >::type & get(const pair<T1, T2>&);
-
      
-
      
-24 Return type: If I == 0 then P is T1, if I == 1 then P is T2, and otherwise the program is ill-formed.
-
      
-
      
-25 Returns: If I == 0 returns p.first, otherwise if I == 1 returns p.second, and otherwise the program is ill-formed.
-
      
-
      
-Throws: Nothing.
-
      
 
+
      
+The here proposed changes of the WP refer to the current state of
+N2691.
+During the Sophia Antipolis meeting two different proposals came up
+regarding the functor argument type, either by value or by rvalue-reference.
+For consistence with existing conventions (state-free algorithms and the
+general_pdf_distribution c'tor signature) the author decided to propose a
+function argument that is provided by value. If severe concerns exists that
+stateful functions would be of dominant relevance, it should be possible to
+replace the two occurrences of Func by Func&& in this proposal as part
+of an editorial process.
+
      
 
-
      
-Update header <tuple> synopsis in 20.3 [tuple] with a APIs as below:
-
      
-
      template <intsize_t I, class T> class tuple_element; // undefined
-template <intsize_t I, class... Types> class tuple_element<I, tuple<Types...> >;
 
-// 20.3.1.4, element access:
-template <intsize_t I, class... Types>
-  typename tuple_element<I, tuple<Types...> >::type& get(tuple<Types...>&);
-template <intsize_t I, class ... types>
-  typename tuple_element<I, tuple<Types...> >::type const& get(const tuple<Types...>&);
-
      
 
+
      Proposed resolution:
      
+
        
+
      1. 
 
        
-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.
+In 26.4.8.5.1 [rand.dist.samp.discrete]/1, class discrete_distribution, just
+before the member declaration
 
        
 
+
        explicit discrete_distribution(const param_type& parm);
+
        
 
 
        
-Update header <array> synopsis in 20.2 [utility]
+insert:
 
        
-
        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>&);
-
        
 
+
+
        template<typename Func>
+discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
+
        
+
        2. 
+
+
      2. 
 
        
-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.
+Between p.4 and p.5 insert a series of new paragraphs as part of the
+new member description::
 
        
-
        template <intsize_t I, class T, size_t N> const T& get(const array<T, N>& a);
+
        template<typename Func>
+discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
 
        
+
 
        
-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.
+Complexity: Exactly nf invocations of fw.
 
        
 
        
-Throws: Nothing.
+Requires:
 
        
+
          
+
        1. 
+fw shall be callable with one argument of type double, and shall
+return values of a type convertible to double;
          2. 
 
+
        2. If nf > 0, the relation xmin < xmax shall hold, and for all sample values
+xk, fw(xk) shall return a weight value wk that is non-negative, non-NaN,
+and non-infinity;
          3. 
 
-
          [
-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.
-]
          
-
-
+
        3. The following relations shall hold: nf ≥ 0, and 0 < S = w0+. . .+wn-1.
          4. 
 
+
        
 
-
        
-
        776. Undescribed assign function of std::array
        
-
        Section: 23.2.1 [array] Status: Review
- Submitter: Daniel Krügler Date: 2008-01-20
        
-
        View other active issues in [array].
        
-
        View all other issues in [array].
        
-
        View all issues with Review status.
        
-
        Discussion:
        
 
        
-The class template array synopsis in 23.2.1 [array]/3 declares a member
-function
+Effects:
 
        
+
          
+
        1. If nf == 0, sets n = 1 and lets the sequence w have length n = 1 and
+   consist of the single value w0 = 1.
          2. 
 
-
          void assign(const T& u);
+
        2. 
+
          Otherwise, sets n = nf, deltax = (xmax - xmin)/n and xcent = xmin +
+0.5 * deltax.
          
+
          For each k = 0, . . . ,n-1, calculates:
+  xk = xcent + k * deltax
+  wk = fw(xk)
+
          
+
          3. 
+
        3. 
+
          Constructs a discrete_distribution object with probabilities:
          
+
          pk = wk/S  for k = 0, . . . , n-1.
 
          
+
          4. 
+
        
+
        
+
        3. 
+
      
 
-
      
-which's semantic is no-where described. Since this signature is
-not part of the container requirements, such a semantic cannot
-be derived by those.
-
      
 
-
      
-I found only one reference to this function in the issue list,
-588 where the question is raised:
-
      
 
-
      
-what's the effect of calling assign(T&) on a zero-sized array?
-
      
 
-
      
-which does not answer the basic question of this issue.
-
      
 
+
      
+
      794. piecewise_constant_distribution missing constructor
      
+
      Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: Open
+ Submitter: P.J. Plauger Date: 2008-02-09
      
+
      View other active issues in [rand.dist.samp.pconst].
      
+
      View all other issues in [rand.dist.samp.pconst].
      
+
      View all issues with Open status.
      
+
      Discussion:
      
 
      
-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.
+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:
      
 
      
-Just after the section 23.2.1.4 [array.data] add the following new section:
+(Makes it easier to fill a histogram with function values over a range.
+The two (reference 793) make a sensible replacement for
+general_pdf_distribution.)
 
      
 
-
      
-23.2.1.5 array::fill [array.fill]
-
      
+
      [
+Sophia Antipolis:
+]
      
 
-
      
-
      void fill(const T& u);
-
      
 
+
      
 
      
-1: Effects: fill_n(begin(), N, u)
+Marc: uses variable width of bins and weight for each bin. This is not
+giving enough flexibility to control both variables.
 
      
-
      
-
 
      
-[N.B: I wonder, why class array does not have a "modifiers"
-section. If it had, then assign would naturally belong to it]
+Add a library issue to provide an constructor taking an
+initializer_list<double> and _Fn for piecewise_constant_distribution.
 
      
-
 
      
-Change the synopsis in 23.2.1 [array]/3:
+Daniel to draft wording.
 
      
-
-
      template <class T, size_t N>
-struct array { 
-  ...
-  void assign fill(const T& u);
-  ...
-
      
-
+
      
 
 
      [
-Bellevue:
+Pre San Francisco, Daniel provided wording.
 ]
      
 
 
 
      
-
      
-Suggest substituting "fill" instead of "assign".
-
      
-
      
-Set state to Review given substitution of "fill" for "assign".
-
      
+The here proposed changes of the WP refer to the current state of
+N2691.
+For reasons explained in 793, the author decided to propose a function
+argument that is provided by value. The issue proposes a c'tor signature,
+that does not take advantage of the full flexibility of
+piecewise_constant_distribution,
+because it restricts on a constant bin width, but the use-case seems to
+be popular enough to justify it's introduction.
 
      
 
 
 
+
      Proposed resolution:
      
 
-
      
-
      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:
      
+
        
+
      1. 
 
        
-The load functions are defined as
+In 26.4.8.5.2 [rand.dist.samp.pconst]/1, class piecewise_constant_distribution,
+just before the member declaration
 
        
 
-
        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;
+
        explicit piecewise_constant_distribution(const param_type& parm);
 
        
-
 
        
-which prevents their use in const contexts.
+insert:
 
        
+
        template<typename Func>
+piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
+
        
+
        2. 
 
-
        [
-post Bellevue Peter adds:
-]
        
-
-
-
        
+
      2. 
 
        
-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:
+Between p.4 and p.5 insert a new sequence of paragraphs nominated
+below as [p5_1], [p5_2],
+[p5_3], and [p5_4] as part of the new member description:
 
        
 
-
        const atomic_int x{};
-
-int main()
-{
-  x.load();
-}
-
        
-
+
        template<typename Func>
+piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
+
        
+
        
 
        
-dump core under a straightforward implementation that puts const objects in
-a read-only section.
+[p5_1] Complexity: Exactly nf invocations of fw.
 
        
 
        
-There are ways to sidestep the problem, but it needs to be considered.
+[p5_2] Requires:
 
        
+
          
+
        1. fw shall be callable with one argument of type RealType, and shall
+return values of a type convertible to double;
+
          2. 
+
        2. 
+For all sample values xk defined below, fw(xk) shall return a weight
+value wk that is non-negative, non-NaN, and non-infinity;
+
          3. 
+
        3. 
+The following relations shall hold: xmin < xmax, and
+0 < S = w0+. . .+wn-1.
+
          4. 
+
        
 
        
-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.
+[p5_3] Effects:
 
        
-
        
-
-
-
-
        Proposed resolution:
        
+
          
+
        1. 
+
          If nf == 0,
          
+ 
            
+ 
          1. 
+sets deltax = xmax - xmin, and
            2. 
+
          2.  lets the sequence w have length n = 1 and consist of the single
+    value w0 = 1, and
            3. 
+
          3.  lets the sequence b have length n+1 with b0 = xmin and 
+              b1 = xmax
+
            4. 
+
          
+
          2. 
+
        2. 
+
          Otherwise,
          
+
            
+
          1.  sets n = nf, deltax = (xmax - xmin)/n,
+                 xcent = xmin + 0.5 * deltax, and
+
            2. 
+
          2. lets the sequences w and b have length n and n+1, resp. and
            
+
            for each k = 0, . . . ,n-1, calculates:
+  dxk = k * deltax
+  bk = xmin + dxk
+  xk = xcent + dxk
+  wk = fw(xk),
+
             
+
             and
            
+
            3. 
+
          3.  sets bn = xmax
            4. 
+
          
+
          3. 
+
        3. 
 
          
-Add the const qualifier to *object and *this.
+Constructs a piecewise_constant_distribution object with
+the above computed sequence b as the interval boundaries
+and with the probability densities:
 
          
-
-
          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;
-
          
+
          ρk = wk/(S * deltax)  for k = 0, . . . , n-1.
+
           
+
          4. 
+
        
+
        
+[p5_4] Remarks: In this context, the subintervals [bk, bk+1) are commonly
+ known as the bins of a histogram.
+ 
        
+
        
+
        3. 
+
+
      
 
 
 
@@ -14785,1025 +12781,1193 @@ C A::load(memory_order order = memory_order_seq_cst) const volatile;
 
 
 
      
-
      778. std::bitset does not have any constructor taking a string literal
      
-
      Section: 23.3.5.1 [bitset.cons] Status: Ready
- Submitter: Thorsten Ottosen Date: 2008-01-24
      
-
      View other active issues in [bitset.cons].
      
-
      View all other issues in [bitset.cons].
      
-
      View all issues with Ready status.
      
-
      Duplicate of: 116
      
+
      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:
      
 
      
-A small issue with std::bitset: it does not have any constructor
-taking a string literal, which is clumsy and looks like an oversigt when
-we tried to enable uniform use of string and const char* in the library.
-
      
-
-
      
-Suggestion: Add
+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.
 
      
 
-
      explicit bitset( const char* str );
-
      
-
 
      
-to std::bitset.
+There are two more minor issues:
 
      
 
+
        
+
      • 
+Strictly speaking end - begin is not defined since
+InputIterator is not required to be a random access iterator.
+
        • 
+
      • 
+Currently all integral types are allowed as input to the seed_seq
+constructor, including bool. IMHO allowing bools unnecessarily
+complicates the implementation without any real benefit to the user.
+I'd suggest to exclude bools as input.
+
        • 
+
      
 
-
      Proposed resolution:
      
-
      
-Add to synopsis in 23.3.5 [template.bitset]
-
      
-
-
      explicit bitset( const char* str );
-
      
+
      [
+Bellevue:
+]
      
 
-
      
-Add to synopsis in 23.3.5.1 [bitset.cons]
-
      
 
-
      explicit bitset( const char* str );
-
      
-
      
-Effects: Constructs a bitset as if bitset(string(str)).
-
      
+
      
+Move to OPEN Bill will try to propose a resolution by the next meeting.
 
      
 
+
      [
+post Bellevue:  Bill provided wording.
+]
      
 
 
-
-
-
-
      
-
      779. Resolution of #283 incomplete
      
-
      Section: 25.2.8 [alg.remove] Status: New
- Submitter: Daniel Krügler Date: 2008-01-25
      
-
      View all other issues in [alg.remove].
      
-
      View all issues with New status.
      
-
      Discussion:
      
 
      
-The resolution of 283 did not resolve similar necessary changes for algorithm
-remove_copy[_if],
-which seems to be an oversight.
+This issue is made moot if 803 is accepted.
 
      
 
 
+
 
      Proposed resolution:
      
 
      
-In 25.2.8 [alg.remove]/p.6, replace the N2461 requires clause with one of:
+Replace 26.4.7.1 [rand.util.seedseq] paragraph 6 with:
 
      
 
 
      
-Requires: Type T is EqualityComparable (31). The ranges [first,last)
-and [result,result + (last - first)) shall not overlap. The expression *result = *first shall be
-valid.
-
      
-
 
      
-or
+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:
 
      
 
-
      
-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.
+
      for( v.clear(); n > 0; n -= 32 )
+   v.push_back(b mod 232), b /= 232;
+
      
 
      
 
 
 
 
 
-
 
      
-
      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.
      
+
      801. tuple and pair trivial members
      
+
      Section: 20.4 [tuple] Status: Open
+ Submitter: Lawrence Crowl Date: 2008-02-18
      
+
      View other active issues in [tuple].
      
+
      View all other issues in [tuple].
      
+
      View all issues with Open status.
      
 
      Discussion:
      
 
      
-Though issue 283 has fixed many open issues, it seems that some are still open:
+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.
 
      
-
 
      
-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 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.
 
      
-
-
        
-
      • 
-no assignment requirements are specified (neither implicit nor explicit).
-
        • 
-
-
      • 
-the effects clause just speaks of "merges", which is badly worded
-near to a circular definition.
-
        • 
-
-
      • 
-p. 2 mentions a range [first, last), which is not defined by the
-function arguments or otherwise.
-
        • 
-
-
      • 
-p. 2 says "according to the ordering defined by comp" which is both
-incomplete (because
-this excludes the first variant with <) and redundant (because the
-following subordinate
-clause mentions comp again)
-
        • 
-
      
-
-
-
-
      Proposed resolution:
      
 
      
-In 25.3.4 [alg.merge] replace p.1+ 2:
+There are at least two cases where specification of an explicitly
+defaulted function may be desirable.
 
      
-
-
      
 
      
-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.
+First, the std::pair template has a non-trivial default constructor,
+which prevents static initialization of the pair even when the
+types are statically initializable.  Changing the definition to
 
      
 
+
      pair() = default;
+
      
+
 
      
-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.
+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.
 
      
-
      
 
 
      
-[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]
+** 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?
 
      
-
-
-
-
-
-
-
      
-
      781. std::complex should add missing C99 functions
      
-
      Section: 26.3.7 [complex.value.ops] Status: Ready
- Submitter: Daniel Krügler Date: 2008-01-26
      
-
      View other active issues in [complex.value.ops].
      
-
      View all other issues in [complex.value.ops].
      
-
      View all issues with Ready status.
      
-
      Discussion:
      
 
      
-A comparision of the N2461 header <complex> synopsis ([complex.synopsis])
-with the C99 standard (ISO 9899, 2nd edition and the two corrigenda) show
-some complex functions that are missing in C++. These are:
+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:
 
      
 
-
        
-
      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. 
-
      
+
      tuple() = default;
+tuple(const tuple&) = default;
+
      
 
 
      
-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).
+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.
 
      
-
 
      
-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.
+** How does the committee wish to trade implementation
+efficiency versus implementation flexibility?
 
      
 
+
      [
+Bellevue:
+]
      
+
 
-
      Proposed resolution:
      
+
      
 
      
-In 26.3.1 [complex.synopsis] add just between the declaration of conj and fabs:
+General agreement; the first half of the issue is NAD.
 
      
-
-
      template<class T> complex<T> conj(const complex<T>&);
-template<class T> complex<T> proj(const complex<T>&);
-template<class T> complex<T> fabs(const complex<T>&);
-
      
-
 
      
-In 26.3.7 [complex.value.ops] just after p.6 (return clause of conj) add:
+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.
 
      
-
-
      
-
      template<class T> complex<T> proj(const complex<T>& x);
-
      
-
      
-
-Effects: Behaves the same as C99 function cproj, defined in
-subclause 7.3.9.4."
-
      
-
      
-
 
      
-In 26.3.9 [cmplx.over]/1, add one further entry proj to
-the overload list.
+Concensus: Go forward, but not at expense of other desired qualities.
 
      
-
-
      
 
      
-The following function templates shall have additional overloads:
+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.
 
      
-
      arg           norm 
-conj          polar proj
-imag          real
-
      
 
      
 
 
+
      Proposed resolution:
      
+
      
+
      
+
 
 
 
 
 
      
-
      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
      
+
      803. Simplification of seed_seq::seq_seq
      
+
      Section: 26.4.7.1 [rand.util.seedseq] Status: Review
+ Submitter: Charles Karney Date: 2008-02-22
      
 
      View other active issues in [rand.util.seedseq].
      
 
      View all other issues in [rand.util.seedseq].
      
-
      View all issues with Ready status.
      
+
      View all issues with Review status.
      
 
      Discussion:
      
 
      
-Part of the resolution of n2423, issue 8 was the proposal to
-extend the seed_seq constructor accepting an input range
-as follows (which is now part of N2461):
+seed_seq(InputIterator begin, InputIterator end); constructs a seed_seq
+object repacking the bits of supplied sequence [begin, end) into a
+32-bit vector.
 
      
-
-
      template<class InputIterator,
-size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>
-seed_seq(InputIterator begin, InputIterator end);
-
      
-
 
      
-First, the expression iterator_traits<InputIterator>::value_type
-is invalid due to missing typename keyword, which is easy to
-fix.
+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. 
+
      
 
      
-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).
+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).
 
      
-
 
      
-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)].
+Here's how the description would read
 
      
-
-
      [
-Bellevue:
-]
      
-
-
 
      
 
      
-Fermilab does not have a strong opinion. Would prefer to go with
-solution A. Bill agrees that solution A is a lot simpler and does the
-job.
+26.4.7.1 [rand.util.seedseq] Class seed_seq
 
      
-
      
-Proposed Resolution: Accept Solution A.
+
+
      
+
      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);
+
      
+
      
+
      
+
      
 
      
 
 
      
-Issue 803 claims to make this issue moot.
+Discussion:
 
      
-
-
-
-
      Proposed resolution:
      
-
        
+
        
+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:
+
        
+
          
 
        • 
 
          
-In 26.4.7.1 [rand.util.seedseq]/2, class seed_seq synopsis replace:
+The user can pass an array of unsigned char and seed_seq will nicely
+ repack it.
 
          
-
-
          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);
-   ...
-};
+
          
+ 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 };
 
          
-
 
          
-and do a similar replacement in the member description between
-p.3 and p.4.
+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.
 
          
 
          • 
-
 
        • 
 
          
-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:
+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.
 
          
-
-
          template<class InputIterator,
-  size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>
-	  seed_seq(InputIterator begin, InputIterator end);
-template<class InputIterator, size_t u>
-seed_seq(InputIterator begin, InputIterator end, implementation-defined s);
-
          
-
 
          
-In 26.4.2 [rand.synopsis], header <random> synopsis, immediately after the
-class seed_seq declaration and in 26.4.7.1 [rand.util.seedseq]/2, immediately
-after the class seed_seq definition add:
+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.
 
          
-
-
          template<size_t u, class InputIterator>
-  seed_seq make_seed_seq(InputIterator begin, InputIterator end);
+
          • 
+
        • 
+
          
+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.
+
          
+
          • 
+
        
 
 
        
-In 26.4.7.1 [rand.util.seedseq], just before p.5 insert two paragraphs:
+Note: this proposal renders moot issues 782 and 800.
 
        
 
+
        [
+Bellevue:
+]
        
+
+
+
        
+Walter needs to ask Fermilab for guidance. Defer till tomorrow. Bill likes the proposed resolution.
+
        
+
+
        [
+Sophia Antipolis:
+]
        
+
+
 
        
 
        
-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.
+Marc Paterno wants portable behavior between 32bit and 64bit machines;
+we've gone to significant trouble to support portability of engines and
+their values.
+
        
+
        
+Jens: the new algorithm looks perfectly portable
+
        
+
        
+Marc Paterno to review off-line.
 
        
 
        
-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.
+Modify the proposed resolution to read "Constructs a seed_seq object by the following algorithm ..."
+
        
+
        
+Disposition: move to review; unanimous consent.
+
        
+
        
+(moots 782 and 800)
 
        
 
        
 
+
+
+
        Proposed resolution:
        
 
        
-In 26.4.7.1 [rand.util.seedseq], just after the last paragraph add:
+Change 26.4.7.1 [rand.util.seedseq]:
 
        
 
 
        
-
        template<size_t u, class InputIterator>
-   seed_seq make_seed_seq(InputIterator begin, InputIterator end);
+
        template<class InputIterator, 
+  size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>
+  seed_seq(InputIterator begin, InputIterator end);
 
        
 
        
 
        
-where u is used to construct an object s of implementation-defined type.
+-5- Requires: InputIterator shall satisfy the requirements of an input iterator (24.1.1)
+such that iterator_traits<InputIterator>::value_type shall denote an integral type.
+
        
+
        
+-6- Constructs a seed_seq object by the following algorithm rearranging some or all of the bits of the supplied sequence
+[begin,end) of w-bit quantities into 32-bit units, as if by the following: 
 
        
 
        
-Returns: seed_seq(begin, end, s);
+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);
+
        
+
        
 
        
 
        
-
-
-
      
-
 
 
 
 
 
 
      
-
      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.
      
+
      804. Some problems with classes error_code/error_condition
      
+
      Section: 19.4 [syserr] Status: Review
+ Submitter: Daniel Krügler Date: 2008-02-24
      
+
      View other active issues in [syserr].
      
+
      View all other issues in [syserr].
      
+
      View all issues with Review status.
      
 
      Discussion:
      
+
        
+
      1. 
 
        
-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.
+19.4.2.1 [syserr.errcode.overview]/1, class error_code and
+19.4.3.1 [syserr.errcondition.overview]/, class error_condition synopses
+declare an expository data member cat_:
 
        
-
+
        const error_category& cat_; // exposition only
+
        
+
        
+which is used to define the semantics of several members. The decision
+to use a member of reference type lead to several problems:
+
        
+
          
+
        1. 
+The classes are not (Copy)Assignable, which is probably not the intent.
+
          2. 
+
        2. 
+The post conditions of all modifiers from
+19.4.2.3 [syserr.errcode.modifiers] and 19.4.3.3 [syserr.errcondition.modifiers], resp.,
+cannot be fulfilled.
+
          3. 
+
        
 
        
-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.
+The simple fix would be to replace the reference by a pointer member.
 
        
+
        2. 
+
+
      2. 
+I would like to give the editorial remark that in both classes the
+constrained operator=
+overload (template with ErrorCodeEnum argument) makes in invalid
+usage of std::enable_if: By using the default value for the second enable_if
+parameter the return type would be defined to be void& even in otherwise
+valid circumstances - this return type must be explicitly provided (In
+error_condition the first declaration uses an explicit value, but of wrong
+type).
+
        3. 
+
+
      3. 
+The member function message throws clauses (
+19.4.1.2 [syserr.errcat.virtuals]/10, 19.4.2.4 [syserr.errcode.observers]/8, and
+19.4.3.4 [syserr.errcondition.observers]/6) guarantee "throws nothing",
+although
+they return a std::string by value, which might throw in out-of-memory
+conditions (see related issue 771).
+
        4. 
+
      
 
 
      [
-post Bellevue Peter adds:
+Sophia Antipolis:
 ]
      
 
 
 
      
 
      
-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.
+Part A: NAD (editorial), cleared by the resolution of issue 832.
 
      
 
      
-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:
+Part B: Technically correct, save for typo. Rendered moot by the concept proposal 
+(N2620) NAD (editorial).
 
      
-
 
      
-http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html
+Part C: We agree; this is consistent with the resolution of issue 721.
 
      
-
      
-
-
-
-
      Proposed resolution:
      
 
      
-Add a sentence to 30.2.1.1 [thread.thread.id]/p1:
+Howard: please ping Beman, asking him to clear away parts A and B from
+the wording in the proposed resolution, so it is clear to the editor
+what needs to be applied to the working paper.
 
      
-
-
      
 
      
-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.
+Beman provided updated wording. Since issue 832 is not going
+forward, the provided wording includes resolution of part A.
 
      
 
      
 
 
 
+
      Proposed resolution:
      
 
-
-
      
-
      785. Random Number Requirements in TR1
      
-
      Section: TR1 5.1.4.5 [tr.rand.eng.disc], TR1 5.1.4.6 [tr.rand.eng.xor] Status: New
- Submitter: John Maddock Date: 2008-01-15
      
-
      View all issues with New status.
      
-
      Discussion:
      
 
      
-Table 16 of TR1 requires that all Pseudo Random Number generators have a
+Resolution of part A:
 
      
-
-
      seed(integer-type s)
-
      
-
+
      
 
      
-member function that is equivalent to:
+Change 19.4.2.1 [syserr.errcode.overview] Class error_code overview synopsis as indicated:
 
      
 
-
      mygen = Generator(s)
+
      private:
+  int val_;                    // exposition only
+  const error_category&* cat_; // exposition only
 
      
 
 
      
-But the generators xor_combine and discard_block have no such seed member, only the
+Change 19.4.2.2 [syserr.errcode.constructors] Class error_code constructors as indicated:
 
      
 
-
      template <class Gen>
-seed(Gen&);
-
      
-
+
      
+
      error_code();
+
      
+
      
 
      
-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 type error_code.
 
      
-
 
      
-So... is this a bug in TR1?
+Postconditions: val_ == 0 and cat_ == &system_category.
+
      
+
      
+Throws: Nothing.
+
      
+
      
+
      error_code(int val, const error_category& cat);
+
      
+
      
+
      
+Effects: Constructs an object of type error_code.
+
      
+
      
+Postconditions: val_ == val and cat_ == &cat.
+
      
+
      
+Throws: Nothing.
 
      
+
      
+
      
 
-
      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.
+
      
+Change 19.4.2.3 [syserr.errcode.modifiers] Class error_code modifiers as indicated:
 
      
 
-
      [
-Jens adds:
-]
      
+
      
+
      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:
+
      
 
 
      
-Both engines do have the necessary
-constructor, therefore the omission of the seed() member
-functions appears to be an oversight.
+const error_category& category() const;
+
      
+
      
+Returns: *cat_.
+
      
+
      
+Throws: Nothing.
+
      
+
      
 
      
 
+
      
+Change 19.4.3.1 [syserr.errcondition.overview] Class error_condition overview synopsis as indicated:
+
      
 
+
      private:
+  int val_;                    // exposition only
+  const error_category&* cat_; // exposition only
+
      
 
-
      Proposed resolution:
      
 
      
+Change 19.4.3.2 [syserr.errcondition.constructors] Class error_condition constructors as indicated:
 
      
+
      [
+(If the proposed resolution of issue 805 has already been applied, the
+name posix_category will have been changed to generic_category. That has
+no effect on this resolution.)
+]
      
 
 
+
      
+
      error_condition();
+
      
+
      
+
      
+Effects: Constructs an object of type error_condition.
+
      
+
      
+Postconditions: val_ == 0 and cat_ == &posix_category.
+
      
+
      
+Throws: Nothing.
+
      
+
      
+
      error_condition(int val, const error_category& cat);
+
      
+
      
+
      
+Effects: Constructs an object of type error_condition.
+
      
+
      
+Postconditions: val_ == val and cat_ == &cat.
+
      
+
      
+Throws: Nothing.
+
      
+
      
+
      
 
+
      
+Change 19.4.3.3 [syserr.errcondition.modifiers] Class error_condition modifiers as indicated:
+
      
 
-
-
      
-
      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:
      
+
      
+void assign(int val, const error_category& cat);
+
      
+
      
+Postconditions: val_ == val and cat_ == &cat.
+
      
 
      
-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:
+Throws: Nothing.
 
      
+
      
+
      
 
-
        
-
      • 
-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.
-
        • 
+
        
+Change 19.4.3.4 [syserr.errcondition.observers] Class error_condition observers as indicated:
+
        
 
-
      • 
-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.
-
        • 
+
        
+const error_category& category() const;
+
        
+
        
+Returns: *cat_.
+
        
+
        
+Throws: Nothing.
+
        
+
        
+
        
+
      
 
-
    • 
-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.
-
      • 
+
      
+Resolution of part C:
+
      
 
-
    • 
-Should the clock change during a timed wait operation, the actual
-duration of the wait will not be the expected length. For example, a
-user may intend a timed wait of one second duration but, due to an
-adjustment of the system clock backwards by a minute, the wait instead
-takes 61 seconds.
-
      • 
-
    +

    -POSIX solves the problem by introducing a new monotonic clock, which is -unaffected by changes to the system time. When a condition variable is -initialized, the user may specify whether the monotonic clock is to be -used. (It is worth noting that on POSIX systems it is not possible to -use condition_variable::native_handle() to access this facility, since -the desired clock type must be specified during construction of the -condition variable object.) +In 19.4.1.2 [syserr.errcat.virtuals], remove the throws clause p. 10.

    +
    +
    virtual string message(int ev) const = 0;
+
    + +

    -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: +Returns: A string that describes the error condition denoted by ev.

    +

    +Throws: Nothing. +

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

      +In 19.4.2.4 [syserr.errcode.observers], remove the throws clause p. 8. +

      -
    • -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. -
      • -
    +
    +
    string message() const;
+
    +
    +

    +Returns: category().message(value()). +

    +

    +Throws: Nothing. +

    +
    +

    -One possible minimal solution: +In 19.4.3.4 [syserr.errcondition.observers], remove the throws clause p. 6.

    -
      -
    • -Strike normative references to UTC and an epoch based on 1970-01-01. -
      • +
      +
      string message() const;
+
      +
      +

      +Returns: category().message(value()). +

      +

      +Throws: Nothing. +

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

    +
    +

    805. posix_error::posix_errno concerns

    +

    Section: 19.4 [syserr] Status: Ready + Submitter: Jens Maurer Date: 2008-02-24

    +

    View other active issues in [syserr].

    +

    View all other issues in [syserr].

    +

    View all issues with Ready status.

    +

    Discussion:

    +19.4 [syserr]

    +
    namespace posix_error {
+  enum posix_errno {
+    address_family_not_supported, // EAFNOSUPPORT
+    ...
+
    +

    +should rather use the new scoped-enum facility (7.2 [dcl.enum]), +which would avoid the necessity for a new posix_error +namespace, if I understand correctly. +

    +

    [ +Further discussion: +]

    -
    -

    787. complexity of binary_search

    -

    Section: 25.3.3.4 [binary.search] Status: New - Submitter: Daniel Krügler Date: 2007-09-08

    -

    View all issues with New status.

    -

    Discussion:

    +

    -In 25.3.3.4 [binary.search]/3 the complexity of binary_search is described as +See N2347, +Strongly Typed Enums, since renamed Scoped Enums.

    - -
    -At most log(last - first) + 2 comparisons. -
    -

    -This should be precised and brought in line with the nomenclature used for -lower_bound, upper_bound, and equal_range. +Alberto Ganesh Barbati also raised this issue in private email, and also proposed the scoped-enum solution.

    -

    -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). +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 25.3.3.4 [binary.search]/3 +Change System error support 19.4 [syserr] as indicated:

    -
    -Complexity: At most log2(last - first) + 2 O(1) comparisons. -
    +
    namespace posix_error {
+  enum posix_errno class errc {
+    address_family_not_supported, // EAFNOSUPPORT
+    ...
+    wrong_protocol_type, // EPROTOTYPE
+  };
+} // namespace posix_error
 
+template <> struct is_error_condition_enum<posix_error::posix_errno errc>
+  : public true_type {}
 
+namespace posix_error {
+  error_code make_error_code(posix_errno errc e);
+  error_condition make_error_condition(posix_errno errc e);
+} // namespace posix_error
+
    +

    +Change System error support 19.4 [syserr] : +

    +
    +The is_error_code_enum and is_error_condition_enum templates may be +specialized for user-defined types to indicate that such a type is +eligible for class error_code and class error_condition automatic +conversions, respectively. +
    -
    -

    788. ambiguity in [istream.iterator]

    -

    Section: 24.5.1 [istream.iterator] Status: New - Submitter: Martin Sebor Date: 2008-02-06

    -

    View other active issues in [istream.iterator].

    -

    View all other issues in [istream.iterator].

    -

    View all issues with New status.

    -

    Discussion:

    -The description of how an istream_iterator object becomes an -end-of-stream iterator is a) ambiguous and b) out of date WRT -issue 468: +Change System error support 19.4 [syserr] and its subsections:

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

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

    -Also I would prefer to be explicit about calling fail() here -(there is no operator void*() anymore.) +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 24.5.1 [istream.iterator]/1: +Change 19.4.3.5 [syserr.errcondition.nonmembers] Class error_condition non-member functions as indicated:

    -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. +
    error_condition make_error_condition(posix_errno errc e);
+
    + +
    +Returns: error_condition(static_cast<int>(e), posixgeneric_category). +
    +

    Rationale:

    + + + + + + + + -
    -

    789. xor_combine_engine(result_type) should be explicit

    -

    Section: 26.4.4.4 [rand.adapt.xor] Status: Ready - Submitter: P.J. Plauger Date: 2008-02-09

    -

    View all other issues in [rand.adapt.xor].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -xor_combine_engine(result_type) should be explicit. (Obvious oversight.) -

    + + + + -

    [ -Bellevue: -]

    + + + + + + + + -
    -Non-controversial. Bill is right, but Fermilab believes that this is -easy to use badly and hard to use right, and so it should be removed -entirely. Got into TR1 by well defined route, do we have permission to -remove stuff? Should probably check with Jens, as it is believed he is -the originator. Broad consensus that this is not a robust engine -adapter. -
    + + + + + + + + -

    Proposed resolution:

    -

    -Remove xor_combine_engine from synopsis of 26.4.2 [rand.synopsis]. -

    -

    -Remove 26.4.4.4 [rand.adapt.xor] xor_combine_engine. -

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

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

    +

    806. unique_ptr::reset effects incorrect, too permissive

    +

    Section: 20.7.11.2.5 [unique.ptr.single.modifiers] Status: Ready + Submitter: Peter Dimov Date: 2008-03-13

    View all issues with Ready status.

    Discussion:

    -piecewise_constant_distribution is undefined for a range with just one -endpoint. (Probably should be the same as an empty range.) +void unique_ptr::reset(T* p = 0) is currently specified as:

    +
    +Effects: If p == get() there are no effects. Otherwise get_deleter()(get()). +
    -

    Proposed resolution:

    -Change 26.4.8.5.2 [rand.dist.samp.pconst] paragraph 3b: +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.)

    -
    -b) If firstB == lastB or the sequence w has the length zero, -
    +

    +Two, the special check for get() == p is generally not needed and such a +situation usually indicates an error in the client code, which is being +masked. As a data point, boost::shared_ptr was changed to assert on such +self-resets in 2001 and there were no complaints. +

    +

    +One might think that self-resets are necessary for operator= to work; it's specified to perform +

    +
    reset( u.release() );
+
    +

    +and the self-assignment +

    +
    p = move(p);
+
    -
    -

    793. discrete_distribution missing constructor

    -

    Section: 26.4.8.5.1 [rand.dist.samp.discrete] Status: Open - Submitter: P.J. Plauger Date: 2008-02-09

    -

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

    -

    View all issues with Open status.

    -

    Discussion:

    -discrete_distribution should have a constructor like: +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.

    -
    template<class _Fn>
-  discrete_distribution(result_type _Count, double _Low, double _High,
-                        _Fn& _Func);
-
    + + +

    Proposed resolution:

    -(Makes it easier to fill a histogram with function vaues over a range.) +Change 20.7.11.2.5 [unique.ptr.single.modifiers]:

    -

    [ -Bellevue: -]

    +
    +
    void reset(T* p = 0);
+
    +
    +-4- Effects: If p == get() == 0 there are no effects. Otherwise get_deleter()(get()). +
    +
    +

    +Change 20.7.11.3.3 [unique.ptr.runtime.modifiers]: +

    -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. +
    void reset(T* p = 0);
+
    +
    +

    ...

    +

    +-2- Effects: If p == get() == 0 there are no effects. Otherwise get_deleter()(get()). +

    +
    -

    Proposed resolution:

    -
    -

    794. piecewise_constant_distribution missing constructor

    -

    Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: New - Submitter: P.J. Plauger Date: 2008-02-09

    -

    View other active issues in [rand.dist.samp.pconst].

    -

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

    -

    View all issues with New status.

    +

    807. tuple construction should not fail unless its element's construction fails

    +

    Section: 20.4.1.2 [tuple.cnstr] Status: Ready + Submitter: Howard Hinnant Date: 2008-03-13

    +

    View all issues with Ready status.

    Discussion:

    -piecewise_constant_distribution should have a constructor like: +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.

    -
    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.) +Add to 20.4.1.2 [tuple.cnstr]:

    - -

    Proposed resolution:

    +
    +

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

    +
    -

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

    +

    808. [forward] incorrect redundant specification

    +

    Section: 20.2.2 [forward] Status: Ready + Submitter: Jens Maurer Date: 2008-03-13

    +

    View other active issues in [forward].

    +

    View all other issues in [forward].

    View all issues with Ready status.

    Discussion:

    -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. +p4 (forward) says: +

    +
    +Return type: If T is an lvalue-reference type, an lvalue; otherwise, an rvalue. +
    + +

    +First of all, lvalue-ness and rvalue-ness are properties of an expression, +not of a type (see 3.10 [basic.lval]). Thus, the phrasing "Return type" is wrong. +Second, the phrase says exactly what the core language wording says for +folding references in 14.3.1 [temp.arg.type]/p4 and for function return values +in 5.2.2 [expr.call]/p10. (If we feel the wording should be retained, it should +at most be a note with cross-references to those sections.) +

    +

    +The prose after the example talks about "forwarding as an int& (an lvalue)" etc. +In my opinion, this is a category error: "int&" is a type, "lvalue" is a +property of an expression, orthogonal to its type. (Btw, expressions cannot +have reference type, ever.) +

    +

    +Similar with move: +

    +
    +Return type: an rvalue. +
    +

    +is just wrong and also redundant.

    Proposed resolution:

    -Change D.8.1 [depr.lib.binder.1st]: +Change 20.2.2 [forward] as indicated:

    -
    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; 
-};
+
    template <class T> T&& forward(typename identity<T>::type&& t);
 
    
 
 
    
+
    ...
    
 
    
--1- The constructor initializes fn op with x and value with y.
+Return type: If T is an lvalue-reference type, an lvalue; otherwise, an rvalue.
 
    
+
    ...
    
 
    
--2- operator() returns fnop(value,x).
+-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).
 
    
 
    
-
    - -

    -Change D.8.3 [depr.lib.binder.2nd]: -

    -
    -
    template <class Fn> 
-class binder2nd
-  : public unary_function<typename Fn::first_argument_type, 
-                          typename Fn::result_type> { 
-protected: 
-  Fn fn op; 
-  typename Fn::second_argument_type value; 
-public: 
-  binder2nd(const Fn& x, 
-            const typename Fn::second_argument_type& y); 
-  typename Fn::result_type 
-    operator()(const typename Fn::first_argument_type& x) const; 
-  typename Fn::result_type 
-    operator()(typename Fn::first_argument_type& x) const; 
-};
+
    template <class T> typename remove_reference<T>::type&& move(T&& t);
 
    
 
 
    
+
    ...
    
 
    
--1- The constructor initializes fn op with x and value with y.
-
    
-
    
--2- operator() returns fnop(value,x).
+Return type:  an rvalue.
 
    
 
    
+
    @@ -15812,80 +13976,91 @@ public:
    -

    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.

    +

    809. std::swap should be overloaded for array types

    +

    Section: 25.2.3 [alg.swap] Status: Ready + Submitter: Niels Dekker Date: 2008-02-28

    +

    View all other issues in [alg.swap].

    +

    View all issues with Ready status.

    Discussion:

    -The for-loop in the algorithm specification has n iterations, where n is -defined to be end - begin, i.e. the number of supplied w-bit quantities. -Previous versions of this algorithm and the general logic behind it -suggest that this is an oversight and that in the context of the -for-loop n should be the number of full 32-bit quantities in b (rounded -upwards). If w is 64, the current algorithm throws away half of all bits -in b. If w is 16, the current algorithm sets half of all elements in v -to 0. -

    - -

    -There are two more minor issues: -

    - -
      -
    • -Strictly speaking end - begin is not defined since -InputIterator is not required to be a random access iterator. -
      • -
    • -Currently all integral types are allowed as input to the seed_seq -constructor, including bool. IMHO allowing bools unnecessarily -complicates the implementation without any real benefit to the user. -I'd suggest to exclude bools as input. -
      • -
    - -

    [ -Bellevue: -]

    +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]);
+
    -
    -Move to OPEN Bill will try to propose a resolution by the next meeting. -
    +

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

    [ -post Bellevue: Bill provided wording. -]

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

    -This issue is made moot if 803 is accepted. +Note that such an overload of std::swap should also support multi-dimensional +arrays. Fortunately that isn't really an issue, because it would do so automatically, by +means of recursion.

    +

    +For your information, there was a discussion on this issue at comp.lang.c++.moderated: [Standard +Library] Shouldn't std::swap be overloaded for C-style arrays? +

    Proposed resolution:

    -Replace 26.4.7.1 [rand.util.seedseq] paragraph 6 with: +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. +

    -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: +Add the following to 25.2.3 [alg.swap]:

    - -
    for( v.clear(); n > 0; n -= 32 )
-   v.push_back(b mod 232), b /= 232;
-
    +
    +
    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); +
    @@ -15893,102 +14068,154 @@ algorithm:
    -

    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.

    +

    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:

    -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 recent draft (as well as the original proposal n2072) uses an +operational semantic +for get_money ([ext.manip]/3) and put_money ([ext.manip]/5), which uses

    + +
    istreambuf_iterator<charT>
+
    +

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

    + +
    ostreambuf_iterator<charT>
+
    +

    -There are at least two cases where specification of an explicitly -defaulted function may be desirable. +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.

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

    -
    pair() = default;
-
    +

    Proposed resolution:

    -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. +In 27.6.4 [ext.manip]/3 within function f replace the first line

    +
    template <class charT, class traits, class moneyT> 
+void f(basic_ios<charT, traits>& str, moneyT& mon, bool intl) { 
+   typedef istreambuf_iterator<charT, traits> Iter;
+   ...
+
    +

    -** 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? +In 27.6.4 [ext.manip]/4 remove the first template charT parameter:

    + +
    template <class charT, class moneyT> unspecified put_money(const moneyT& mon, bool intl = false);
+
    +

    -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: +In 27.6.4 [ext.manip]/5 within function f replace the first line

    -
    tuple() = default;
-tuple(const tuple&) = default;
+
    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;
+  ...
 
    
 
 
    
-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.
+In 27.6.4 [ext.manip]/7 within function f replace the first line
 
    
+
+
    template <class charT, class traits> 
+void f(basic_ios<charT, traits>& str, struct tm *tmb, const charT *fmt) { 
+  typedef istreambuf_iterator<charT, traits> Iter;
+  ...
+
    
+
 
    
-** How does the committee wish to trade implementation
-efficiency versus implementation flexibility?
+In 27.6.4 [ext.manip]/8 add const:
 
    
 
-
    [
-Bellevue:
-]
    
-
+
    template <class charT> unspecified put_time(const struct tm *tmb, const charT *fmt);
+
    
 
-
    
 
    
-General agreement; the first half of the issue is NAD.
+In 27.6.4 [ext.manip]/9 within function f replace the first line
 
    
+
+
    template <class charT, class traits> 
+void f(basic_ios<charT, traits>& str, const struct tm *tmb, const charT *fmt) { 
+  typedef ostreambuf_iterator<charT, traits> Iter;
+  ...
+
    
+
 
    
-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.
+Add to the <iomanip> synopsis in 27.6 [iostream.format]
 
    
+
+
    template <class moneyT> unspecified get_money(moneyT& mon, bool intl = false);
+template <class moneyT> unspecified put_money(const moneyT& mon, bool intl = false);
+template <class charT> unspecified get_time(struct tm *tmb, const charT *fmt);
+template <class charT> unspecified put_time(const struct tm *tmb, const charT *fmt);
+
    
+
+
+
+
+
+
+
    
+
    811. pair of pointers no longer works with literal 0
    
+
    Section: 20.2.3 [pairs] Status: New
+ Submitter: Doug Gregor Date: 2008-03-14
    
+
    View all other issues in [pairs].
    
+
    View all issues with New status.
    
+
    Discussion:
    
+
    #include <utility>
+
+int main()
+{
+   std::pair<char *, char *> p (0,0);
+}
+
    
+
 
    
-Concensus: Go forward, but not at expense of other desired qualities.
+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);
+
    
+
 
    
-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.
+Now, concepts will address this issue by constraining that pair
+constructor to only U's and V's that can properly construct "first" and
+"second", e.g. (from
+N2322):
 
    
-
    
+
+
    template<class U , class V >
+requires Constructible<T1, U&&> && Constructible<T2, V&&>
+pair(U&& x , V&& y );
+
    
+
 
 
 
    Proposed resolution:
    
@@ -16000,217 +14227,184 @@ tabled until Alisdair's proposals are disposed of.
 
 
 
    
-
    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.
    
+
    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:
    
 
    
-seed_seq(InputIterator begin, InputIterator end); constructs a seed_seq
-object repacking the bits of supplied sequence [begin, end) into a
-32-bit vector.
+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.
 
    
 
    
-This repacking triggers several problems:
+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.
 
    
-
      
-
    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. 
-
    
+
+
    [
+This may be covered by
+N2410
+Thread-Safety in the Standard Library (Rev 1).
+]
    
+
+
+
+
    Proposed resolution:
    
 
    
-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).
 
    
+
+
+
+
+
+
    
+
    813. "empty" undefined for shared_ptr
    
+
    Section: 20.7.12.2 [util.smartptr.shared] Status: Ready
+ Submitter: Matt Austern Date: 2008-02-26
    
+
    View other active issues in [util.smartptr.shared].
    
+
    View all other issues in [util.smartptr.shared].
    
+
    View all issues with Ready status.
    
+
    Discussion:
    
 
    
-Here's how the description would read
+Several places in 20.7.12.2 [util.smartptr.shared] refer to an "empty" shared_ptr.
+However, that term is nowhere defined. The closest thing we have to a
+definition is that the default constructor creates an empty shared_ptr
+and that a copy of a default-constructed shared_ptr is empty. Are any
+other shared_ptrs empty? For example, is shared_ptr((T*) 0) empty? What
+are the properties of an empty shared_ptr? We should either clarify this
+term or stop using it.
+
    
 
    
+One reason it's not good enough to leave this term up to the reader's
+intuition is that, in light of
+N2351
+and issue 711, most readers'
+intuitive understanding is likely to be wrong. Intuitively one might
+expect that an empty shared_ptr is one that doesn't store a pointer,
+but, whatever the definition is, that isn't it.
+
+
+
    [
+Peter adds:
+]
    
+
+
 
    
 
    
-26.4.7.1 [rand.util.seedseq] Class seed_seq
+Or, what is an "empty" shared_ptr?
 
    
 
-
    
-
    template<class InputIterator>
-  seed_seq(InputIterator begin, InputIterator end);
-
    
-
    
+
      
+
    • 
 
      
-5 Requires: NO CHANGE
+Are any other shared_ptrs empty?
 
      
 
      
-6 Effects: Constructs a seed_seq object by
+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.
 
      
 
      
-
      for (InputIterator s = begin; s != end; ++s)
-   v.push_back((*s) mod 2^32);
-
      
-
      
-
    
-
    
+(*) If it isn't, this is a legitimate defect.
 
    
+
 
+
  • 
 
    
-Discussion:
+For example, is shared_ptr((T*) 0) empty?
 
    
 
    
-The chief virtues here are simplicity, portability, and generality.
+No. If it were empty, it would have a use_count() of 0, whereas it is
+specified to have an use_count() of 1.
 
    
-
      
-
    • 
-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:
+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.
+
      
+
+
 
    • 
 
      
-The user can pass an array of unsigned char and seed_seq will nicely
- repack it.
+We should either clarify this term or stop using it.
 
      
 
      
- Response: So what?  Consider the seed string "ABC".  The
- n2461
- proposal results in
+I don't agree with the imperative tone
 
      
-
      v = { 0x3, 0x434241 };
-
      
 
      
-while the simplified proposal yields
+A clarification would be either a no-op - if it doesn't contradict the
+existing wording - or a big mistake if it does.
 
      
-
      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.
+I agree that a clarification that is formally a no-op may add value.
 
      
 
      • 
+
 
    • 
 
      
-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.
+However, that term is nowhere defined.
 
      
 
      
-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.
+Terms can be useful without a definition. Consider the following
+simplistic example. We have a type X with the following operations
+defined:
 
      
-
      • 
-
    • 
+
      X x;
+X x2(x);
+X f(X x);
+X g(X x1, X x2);
+
      
 
      
-A user can pass an array of 64-bit integers and all the bits will be
- used.
+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.
 
      
+
 
      
- 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
+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.
 
      
-
      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.
+Green and red are "nowhere defined" and completely defined at the same time.
 
      
 
      • 
 
    
 
 
    
-Note: this proposal renders moot issues 782 and 800.
+Alisdair's wording is fine.
 
    
-
-
    [
-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:
+Append the following sentance to 20.7.12.2 [util.smartptr.shared]
 
    
-
    
-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);
-
    
-
    
-
    
+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.
 
    
 
 
@@ -16218,858 +14412,938 @@ for (InputIterator s = begin; s != end; ++s)
 
 
 
    
-
    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].
    
+
    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:
    
-
      
-
    1. 
-
      
-19.4.2.1 [syserr.errcode.overview]/1, class error_code and
-19.4.3.1 [syserr.errcondition.overview]/, class error_condition synopses
-declare an expository data member cat_:
-
      
-
      const error_category& cat_; // exposition only
-
      
 
      
-which is used to define the semantics of several members. The decision
-to use a member of reference type lead to several problems:
+vector<bool>::swap(reference, reference) has no definition.
 
      
-
        
-
      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. 
-
      
+
+
+
      Proposed resolution:
      
 
      
-The simple fix would be to replace the reference by a pointer member.
 
      
-
      2. 
 
-
    2. 
-I would like to give the editorial remark that in both classes the
-constrained operator=
-overload (template with ErrorCodeEnum argument) makes in invalid
-usage of std::enable_if: By using the default value for the second enable_if
-parameter the return type would be defined to be void& even in otherwise
-valid circumstances - this return type must be explicitly provided (In
-error_condition the first declaration uses an explicit value, but of wrong
-type).
-
      3. 
 
-
    3. 
-The member function message throws clauses (
-19.4.1.2 [syserr.errcat.virtuals]/10, 19.4.2.4 [syserr.errcode.observers]/8, and
-19.4.3.4 [syserr.errcondition.observers]/6) guarantee "throws nothing",
-although
-they return a std::string by value, which might throw in out-of-memory
-conditions (see related issue 771).
-
      4. 
-
    
 
 
-
    Proposed resolution:
    
+
+
    
+
    815. std::function and reference_closure do not use perfect forwarding
    
+
    Section: 20.6.15.2.4 [func.wrap.func.inv] Status: Open
+ Submitter: Alisdair Meredith Date: 2008-03-16
    
+
    View all issues with Open status.
    
+
    Discussion:
    
 
    
-In 19.4.1.2 [syserr.errcat.virtuals], remove the throws clause p. 10.
+std::function and reference_closure should use "perfect forwarding" as
+described in the rvalue core proposal.
 
    
 
-
    
-
    virtual string message(int ev) const = 0;
-
    
+
    [
+Sophia Antipolis:
+]
    
+
 
 
    
-
    
-Returns: A string that describes the error condition denoted by ev.
-
    
-
    
-Throws: Nothing.
-
    
-
    
+According to Doug Gregor, as far as std::function is concerned, perfect
+forwarding can not be obtained because of type erasure. Not everyone
+agreed with this diagnosis of forwarding.
 
    
 
+
+
+
    Proposed resolution:
    
 
    
-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);
-
    
-
    
 
+
+
+
+
    
+
    816. Should bind()'s returned functor have a nofail copy ctor when bind() is nofail?
    
+
    Section: 20.6.11.1.3 [func.bind.bind] Status: New
+ Submitter: Stephan T. Lavavej Date: 2008-02-08
    
+
    View other active issues in [func.bind.bind].
    
+
    View all other issues in [func.bind.bind].
    
+
    View all issues with New status.
    
+
    Discussion:
    
+
    
+Library Issue 527 notes that bind(f, t1, ..., tN)
+should be nofail when f, t1, ..., tN have nofail copy ctors.
+
    
 
    
-In the private section of the same class replace the current
-data member cat_ definition by:
+However, no guarantees are provided for the copy ctor of the functor
+returned by bind().  (It's guaranteed to have a copy ctor, which can
+throw implementation-defined exceptions: bind() returns a forwarding
+call wrapper, TR1 3.6.3/2.  A forwarding call wrapper is a call wrapper,
+TR1 3.3/4.  Every call wrapper shall be CopyConstructible, TR1 3.3/4. 
+Everything without an exception-specification may throw
+implementation-defined exceptions unless otherwise specified, C++03
+17.4.4.8/3.)
 
    
+
    
+Should the nofail guarantee requested by Library Issue 527 be extended
+to cover both calling bind() and copying the returned functor?
+
    
+
+
    [
+Howard adds:
+]
    
+
 
 
    
-const error_category&* cat_; // exposition only
+tuple construction should probably have a similar guarantee.
 
    
 
+
+
+
    Proposed resolution:
    
 
    
-In 19.4.2.2 [syserr.errcode.constructors], change p. 2 to read:
 
    
 
-
    
-
    error_code();
-
    
-
    
-
    
-
    ...
    
 
+
+
+
+
    
+
    817. bind needs to be moved
    
+
    Section: 20.6.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:
    
 
    
-Postconditions: val_ == 0 and cat_ == &system_category.
+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.
 
    
-
    
-
    
-
 
    
-Change 19.4.2.2 [syserr.errcode.constructors] p. 5 to read:
+This issue is related to issue 816.
 
    
 
-
    
-
    error_code(int val, const error_category& cat);
-
    
-
    
-
    ...
    
+
+
    Proposed resolution:
    
 
    
-Postconditions: val_ == val and cat_ == &cat.
 
    
-
    
-
    
 
+
+
+
+
+
    
+
    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:
    
 
    
-In 19.4.2.3 [syserr.errcode.modifiers], change p. 1 to read:
+29.1 [atomics.order] p1 says in the table that
 
    
 
 
    
-
    void assign(int val, const error_category& cat);
-
    
-
    
-
    
-
    ...
    
+
+
+
+
+
+
+
+
+
    ElementMeaning
    memory_order_acq_relthe operation has both acquire and release semantics
    
+
    
 
 
    
-Postconditions: val_ == val and cat_ == &cat.
+To my naked eye, that seems to imply that even an atomic read has both
+acquire and release semantics.
 
    
-
    
-

    • -In 19.4.2.3 [syserr.errcode.modifiers], change the operator= signature to read: +Then, p1 says in the table:

    -
    template <class ErrorCodeEnum> 
-  typename enable_if<is_error_code_enum<ErrorCodeEnum>::value, error_code>::type& 
-    operator=(ErrorCodeEnum e);
-
    + + + + + + + + +
    ElementMeaning
    memory_order_seq_cstthe operation has both acquire and release semantics, + and, in addition, has sequentially-consistent operation ordering

    -In 19.4.2.4 [syserr.errcode.observers], change p. 3 to read: +So that seems to be "the same thing" as memory_order_acq_rel, with additional +constraints.

    -
    -
    const error_category& category() const;
-
    -

    -

    ...

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

    -Returns: *cat_. +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?

    -
    -

    -In 19.4.2.4 [syserr.errcode.observers], remove the throws clause p. 8. +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.

    -
    -
    string message() const;
-
    -

    -

    ...

    +Double-check 29.4 [atomics.types.operations] that each +operation clearly says whether it's a load or a store operation, or +both. (It could be clearer, IMO. Solution not in current proposed resolution.) +

    -Throws: Nothing. +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.

    -
    -

    -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" +And why does 29.4 [atomics.types.operations] p9 for "load" say:

    +
    -
    template <class ErrorConditionEnum>
-  error_condition(ErrorConditionEnum e,
-    typename enable_if<is_error_condition_enum<ErrorConditionEnum>::value>::type* = 0);
-
    +Requires: The order argument shall not be memory_order_acquire +nor memory_order_acq_rel.

    -In 19.4.3.1 [syserr.errcondition.overview]/1, class error_condition synopsis, -modifiers section, -replace the operator= overload declaration by: +(Since this is exactly the same restriction as for "store", it seems to be a typo.) +

    + +

    +And then: 29.4 [atomics.types.operations] p12:

    -
    template<typename ErrorConditionEnum> 
-  typename enable_if<is_error_condition_enum<ErrorConditionEnum>::value, error_code error_condition>::type & 
-     operator=( ErrorConditionEnum e );
-
    +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.

    -In the private section of the same class replace the current -data member cat_ definition by: +This is redundant with 1.10 [intro.multithread], see above for the reasoning.

    -
    const error_category&* cat_; // exposition only
-
    +

    Proposed resolution:

    -In 19.4.3.2 [syserr.errcondition.constructors], change p. 2 to read: +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):

    -
    error_condition();
-
    -
    -

    -

    ...

    -

    -Postconditions: val_ == 0 and cat_ == &posix_category. +For memory_order_relaxed, no operation orders memory.

    -
    -

    -In the same section, change p. 5 to read: +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.

    -
    -
    error_condition(int val, const error_category& cat);
-
    -
    -

    -

    ...

    -

    -Postconditions: val_ == val and cat_ == &cat. +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.

    -

    -In 19.4.3.3 [syserr.errcondition.modifiers], change p. 1 to read: +Rephrase 29.1 [atomics.order] p2:

    -
    void assign(int val, const error_category& cat);
-
    -
    -

    -Postconditions: val_ == val and cat_ == &cat. -

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

    -In the same section replace the current operator= overload declaration by: +Rephrase 29.4 [atomics.types.operations] p12 as:

    -
    template <class ErrorConditionEnum> 
-  typename enable_if<is_error_condition_enum<ErrorConditionEnum>::value, error_condition>::type&
-    operator=(ErrorConditionEnum e);
-
    +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. +

    -In 19.4.3.4 [syserr.errcondition.observers], change p. 3 to read: +Same in p15, p20, p22.

    -
    -
    const error_category& category() const;
-
    -
    + + + + + +
    +

    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:

    -Returns: *cat_. +Looking at the wording I submitted for rethrow_if_nested, I don't think I +got it quite right.

    -
    -

    -In 19.4.3.4 [syserr.errcondition.observers], remove the throws clause p. 6. +The current wording says:

    -
    string message() const;
+
    template <class E> void rethrow_if_nested(const E& e);
 
    
 
    
 
    
-
    ...
    
-
-
    
-Throws: Nothing.
+Effects: Calls e.rethrow_nested() only if e
+is publicly derived from nested_exception.
    +

    +This is trying to be a bit subtle, by requiring e (not E) to be publicly +derived from nested_exception the idea is that a dynamic_cast would be +required to be sure. Unfortunately, if e is dynamically but not statically +derived from nested_exception, e.rethrow_nested() is ill-formed. +

    +

    Proposed resolution:

    +
    -

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

    +

    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:

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

    -
    namespace posix_error {
-  enum posix_errno {
-    address_family_not_supported, // EAFNOSUPPORT
-    ...
-
    +

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

    -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. +I believe that terminate() is the most reasonable course of action, but +before we go implement that, I wanted to raise this issue.

    [ -Further discussion: +Peter's summary: ]

    -See N2347, -Strongly Typed Enums, since renamed Scoped Enums. +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.

    +

    -Alberto Ganesh Barbati also raised this issue in private email, and also proposed the scoped-enum solution. +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. +
    +

    -Nick Stoughton asked in Bellevue that posix_error and posix_errno not be used as names. The LWG agreed. +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.

    +

    -The wording for the Proposed resolution was provided by Beman Dawes. +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:

    -Change System error support 19.4 [syserr] as indicated: +Add the following paragraph after 18.7.5 [propagation]/7:

    -
    namespace posix_error {
-  enum posix_errno class errc {
-    address_family_not_supported, // EAFNOSUPPORT
-    ...
-    wrong_protocol_type, // EPROTOTYPE
-  };
-} // namespace posix_error
+
    
+
    
+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.]
+
    
+
    
+
+
 
-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
-
    + +
    +

    821. Minor cleanup : unique_ptr

    +

    Section: 20.7.11.3.3 [unique.ptr.runtime.modifiers] Status: New + Submitter: Alisdair Meredith Date: 2008-03-30

    +

    View all issues with New status.

    +

    Discussion:

    -Change System error support 19.4 [syserr] : +Reading resolution of LWG issue 673 I noticed the following:

    -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. +
    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 System error support 19.4 [syserr] and its subsections: +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...

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

    Proposed resolution:

    -Change Error category objects 19.4.1.5 [syserr.errcat.objects], paragraph 2: +Add to class template definition in 20.7.11.3 [unique.ptr.runtime]

    -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". +
    // modifiers 
+T* release(); 
+void reset(T* p = 0); 
+void reset( nullptr_t );
+template< typename T > void reset( T ) = delete;
+void swap(unique_ptr&& u);
+

    -Change 19.4.2.5 [syserr.errcode.nonmembers] Class error_code non-member functions as indicated: +Update 20.7.11.3.3 [unique.ptr.runtime.modifiers]

    -
    error_code make_error_code(posix_errno errc e);
+
    void reset(pointer p = pointer());
+void reset(nullptr_t);
 
    
 
-
    
-Returns: error_code(static_cast<int>(e), posixgeneric_category).
-
    
+
    
+-1- Requires: Does not accept pointer types which are convertible
+to pointer (diagnostic
+required). [Note: One implementation technique is to create a private
+templated overload. -- end note]
+
    
+
    
+Effects: If get() == nullptr there are no effects. Otherwise get_deleter()(get()). 
+
    
+
    ...
    +

    [ +Note this wording incorporates resolutions for 806 (New) and 673 (Ready). +]

    + + + + + + +
    +

    822. Object with explicit copy constructor no longer CopyConstructible

    +

    Section: 20.1.1 [utility.arg.requirements] Status: New + Submitter: James Kanze Date: 2008-04-01

    +

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

    +

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

    +

    View all issues with New status.

    +

    Discussion:

    -Change 19.4.3.5 [syserr.errcondition.nonmembers] Class error_condition non-member functions as indicated: +I just noticed that the following program is legal in C++03, but +is forbidden in the current draft:

    -
    -
    error_condition make_error_condition(posix_errno errc e);
-
    +
    #include <vector>
+#include <iostream>
 
-
    
-Returns: error_condition(static_cast<int>(e), posixgeneric_category).
-
    
-
    +class Toto +{ +public: + Toto() {} + explicit Toto( Toto const& ) {} +} ; + +int +main() +{ + std::vector< Toto > v( 10 ) ; + return 0 ; +} +
    + +

    +Is this change intentional? (And if so, what is the +justification? I wouldn't call such code good, but I don't see +any reason to break it unless we get something else in return.) +

    -

    Rationale:

    +

    Proposed resolution:

    +

    +In 20.1.1 [utility.arg.requirements] change Table 33: MoveConstructible requirements [moveconstructible]: +

    + +
    - + - - - + - - - + +
    Names Consideredexpressionpost-condition
    portable -Too non-specific. Did not wish to reserve such a common word in -namespace std. Not quite the right meaning, either. -T t(rv) = rvt is equivalent to the value of rv before the construction
    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. -...
    +
    + +

    +In 20.1.1 [utility.arg.requirements] change Table 34: CopyConstructible requirements [copyconstructible]: +

    +
    + + + + - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
    expressionpost-condition
    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. -T t(u) = uthe value of u is unchanged and is equivalent to t
    generic -Short enough. The category could be generic_category. Fully qualified -names like std::generic::not_enough_memory read well. Reserving in -namespace std seems dicey. -
    generic_error -Longish. The category could be generic_category. Fully qualified names -like std::generic_error::not_enough_memory read well. Misleading because -*_error in the std lib is usually an exception class name. -
    generic_err -A bit less longish. The category could be generic_category. Fully -qualified names like std::generic_err::not_enough_memory read well. -
    gen_err -Shorter still. The category could be generic_category. Fully qualified -names like std::gen_err::not_enough_memory read well. -
    generr -Shorter still. The category could be generic_category. Fully qualified -names like std::generr::not_enough_memory read well. -
    error -Shorter still. The category could be generic_category. Fully qualified -names like std::error::not_enough_memory read well. Do we want to use -this general a name? -
    err -Shorter still. The category could be generic_category. Fully qualified -names like std::err::not_enough_memory read well. Although alone it -looks odd as a name, given the existing errno and namespace std names, -it seems fairly intuitive. -Problem: err is used throughout the standard library as an argument name -and in examples as a variable name; it seems too confusing to add yet -another use of the name. -
    errc -Short enough. The "c" stands for "constant". The category could be -generic_category. Fully qualified names like -std::errc::not_enough_memory read well. Although alone it looks odd as a -name, given the existing errno and namespace std names, it seems fairly -intuitive. There are no uses of errc in the current C++ standard. -...
    +
    -

    806. unique_ptr::reset effects incorrect, too permissive

    -

    Section: 20.6.11.2.5 [unique.ptr.single.modifiers] Status: New - Submitter: Peter Dimov Date: 2008-03-13

    -

    View all issues with New status.

    +

    823. identity<void> seems broken

    +

    Section: 20.2.2 [forward] Status: Review + Submitter: Walter Brown Date: 2008-04-09

    +

    View other active issues in [forward].

    +

    View all other issues in [forward].

    +

    View all issues with Review status.

    Discussion:

    -void unique_ptr::reset(T* p = 0) is currently specified as: +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.

    -
    -Effects: If p == get() there are no effects. Otherwise get_deleter()(get()). -
    -

    -There are two problems with this. One, if get() == 0 and p != 0, the -deleter is called with a NULL pointer, and this is probably not what's -intended (the destructor avoids calling the deleter with 0.) +Suggested resolution: Specialize identity<void> so as not to require +the member function's presence.

    +

    [ +Sophia Antipolis: +]

    + + +

    -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. +Jens: suggests to add a requires clause to avoid specializing on void.

    -

    -One might think that self-resets are necessary for operator= to work; it's specified to perform +Alisdair: also consider cv-qualified void. +

    +

    +Alberto provided proposed wording.

    +
    -
    reset( u.release() );
-
    +

    Proposed resolution:

    -and the self-assignment +Change definition of identity in 20.2.2 [forward], paragraph 2, to:

    -
    p = move(p);
+
    template <class T>  struct identity {
+    typedef T type;
+
+    requires ReferentType<T>
+      const T& operator()(const T& x) const;
+  };
+
    
+
    ...
    
+
      requires ReferentType<T>
+    const T& operator()(const T& x) const;
 
    
 
+
+
    Rationale:
    
 
    
-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.
+The point here is to able to write T& given T and ReferentType is
+precisely the concept that guarantees so, according to N2677
+(Foundational concepts). Because of this, it seems preferable than an
+explicit check for cv void using SameType/remove_cv as it was suggested
+in Sophia. In particular, Daniel remarked that there may be types other
+than cv void which aren't referent types (int[], perhaps?).
 
    
 
 
 
-
    Proposed resolution:
    
+
+
+
    
+
    824. rvalue ref issue with basic_string inserter
    
+
    Section: 21.3.8.9 [string.io] Status: Ready
+ Submitter: Alisdair Meredith Date: 2008-04-10
    
+
    View all other issues in [string.io].
    
+
    View all issues with Ready status.
    
+
    Discussion:
    
+
    
+In the current working paper, the <string> header synopsis at the end of
+21.2 [string.classes] lists a single operator<< overload
+for basic_string.
+
    
+
+
    template<class charT, class traits, class Allocator>
+ basic_ostream<charT, traits>&
+   operator<<(basic_ostream<charT, traits>&& os,
+              const basic_string<charT,traits,Allocator>& str);
+
    
 
 
    
-Change 20.6.11.2.5 [unique.ptr.single.modifiers]:
+The definition in 21.3.8.9 [string.io] lists two:
 
    
 
-
    
-
    void reset(T* p = 0);
-
    
-
    
--4- Effects: If p == get() == 0 there are no effects. Otherwise get_deleter()(get()).
-
    
-
    
+
    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);
+
    
 
 
    
-Change 20.6.11.3.3 [unique.ptr.runtime.modifiers]:
+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.
 
    
 
-
    
-
    void reset(T* p = 0);
-
    
-
    
-
    ...
    
+
+
    Proposed resolution:
    
 
    
--2- Effects: If p == get() == 0 there are no effects. Otherwise get_deleter()(get()).
+Delete the first of the two signatures in 21.3.8.9 [string.io]:
 
    
-
    
-
    
 
+
    template<class charT, class traits, class Allocator>
+ basic_ostream<charT, traits>&
+   operator<<(basic_ostream<charT, traits>& os,
+              const basic_string<charT,traits,Allocator>& str);
+
+template<class charT, class traits, class Allocator>
+ basic_ostream<charT, traits>&
+   operator<<(basic_ostream<charT, traits>&& os,
+              const basic_string<charT,traits,Allocator>& str);
+
    
 
 
 
 
 
 
    
-
    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.
    
+
    825. Missing rvalues reference stream insert/extract operators?
    
+
    Section: 19.4.2.1 [syserr.errcode.overview], 20.7.12.2.8
+[util.smartptr.shared.io], 22.2.8 [facets.examples], 23.3.5.3
+[bitset.operators], 26.3.6 [complex.ops], 27.5 [stream.buffers], 28.9
+[re.submatch] Status: Open
+ Submitter: Alisdair Meredith Date: 2008-04-10
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
-527 Added a throws clause to bind constructors.  I believe the same throws clause
-should be added to tuple except it ought to take into account move constructors as well.
+Should the following use rvalues references to stream in insert/extract
+operators?
 
    
 
+
      
+
    • 19.4.2.1 [syserr.errcode.overview]
      • 
+
    • 20.7.12.2.8 [util.smartptr.shared.io]
      • 
+
    • 22.2.8 [facets.examples]
      • 
+
    • 23.3.5.3 [bitset.operators]
      • 
+
    • 26.3.6 [complex.ops]
      • 
+
    • Doubled signatures in 27.5 [stream.buffers] for character inserters
+(ref 27.6.2.6.4 [ostream.inserters.character])
++ definition 27.6.2.6.4 [ostream.inserters.character]
      • 
+
    • 28.9 [re.submatch]
      • 
+
    
+
+
    [
+Sophia Antipolis
+]
    
 
-
    Proposed resolution:
    
-
    
-Add to 20.3.1.2 [tuple.cnstr]:
-
    
 
 
    
+Agree with the idea in the issue, Alisdair to provide wording.
+
    
+
+
+
+
    Proposed resolution:
    
 
    
-For each tuple constructor and assignment operator, an exception is thrown only if the construction
-or assignment of one of the types in Types throws an exception.
 
    
-
    -

    808. [forward] incorrect redundant specification

    -

    Section: 20.2.2 [forward] Status: New - Submitter: Jens Maurer Date: 2008-03-13

    -

    View other active issues in [forward].

    -

    View all other issues in [forward].

    +

    827. constexpr shared_ptr::shared_ptr()?

    +

    Section: 20.7.12.2.1 [util.smartptr.shared.const] Status: New + Submitter: Peter Dimov Date: 2008-04-11

    +

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

    View all issues with New status.

    Discussion:

    -p4 (forward) says: +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.

    -
    -Return type: If T is an lvalue-reference type, an lvalue; otherwise, an rvalue. -
    + +

    Proposed resolution:

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

    + + + + + +
    +

    828. Static initialization for std::mutex?

    +

    Section: 30.3.1.1 [thread.mutex.class] Status: Review + Submitter: Peter Dimov Date: 2008-04-18

    +

    View all issues with Review status.

    +

    Discussion:

    -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: +[Note: I'm assuming here that 3.6.2 [basic.start.init]/1 will be fixed.]

    -
    -Return type: an rvalue. -

    -is just wrong and also redundant. +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.

    +

    [ +Sophia Antipolis: +]

    -

    Proposed resolution:

    -

    -Change 20.2.2 [forward] as indicated: -

    - -
    -
    template <class T> T&& forward(typename identity<T>::type&& t);
-
    -

    ...

    -Return type: If T is an lvalue-reference type, an lvalue; otherwise, an rvalue. +We believe this is implementable on POSIX, because the initializer-list +feature and the constexpr feature make this work. Double-check core +language about static initialization for this case. Ask core for a core +issue about order of destruction of statically-initialized objects wrt. +dynamically-initialized objects (should come afterwards). Check +non-POSIX systems for implementability.

    -

    ...

    --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). +If ubiquitous implementability cannot be assured, plan B is to introduce +another constructor, make this constexpr, which is +conditionally-supported. To avod ambiguities, this new constructor needs +to have an additional parameter.

    -
    template <class T> typename remove_reference<T>::type&& move(T&& t);
-
    -
    -

    ...

    +

    Proposed resolution:

    -Return type: an rvalue. +Change 30.3.1.1 [thread.mutex.class]:

    -
    - -
    +
    class mutex { 
+public: 
+  constexpr mutex(); 
+  ...
+
    -

    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.

    +

    829. current_exception wording unclear about exception type

    +

    Section: 18.7.5 [propagation] Status: Ready + Submitter: Beman Dawes Date: 2008-04-20

    +

    View other active issues in [propagation].

    +

    View all other issues in [propagation].

    +

    View all issues with Ready status.

    Discussion:

    -

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

    Consider this code:

    +
    +
    exception_ptr xp;
    +
    try {do_something(); }
 
-
    
-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!!!
-
    
+catch (const runtime_error& ) {xp = current_exception();}
 
-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.
+...
 
+rethrow_exception(xp);
    +

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

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

    -

    Proposed resolution:

    + +

    -Add an extra condition to the definition of Swappable requirements [swappable] in 20.1.1 [utility.arg.requirements]: +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.

    -
    -- T is Swappable if T is an array type whose element type is Swappable.
    + + + +

    Proposed resolution:

    +

    -Add the following to 25.2.3 [alg.swap]: +After 18.7.5 [propagation] , paragraph 7, add the indicated text:

    +
    -
    template<class T, size_t N> void swap(T (&a)[N], T (&b)[N]);
-
    -
    -Requires: Type T shall be Swappable. -
    +
    exception_ptr current_exception();
    +
    -Effects: swap_ranges(a, a + N, b); +

    +Returns: exception_ptr object that refers +to the currently handled exception (15.3 [except.handle]) or a copy of the currently handled +exception, or a null exception_ptr object if no exception is being handled. If +the function needs to allocate memory and the attempt fails, it returns an +exception_ptr object that refers to an instance of bad_alloc. +It is unspecified whether the return values of two successive calls to +current_exception refer to the same exception object. +[Note: that is, it +is unspecified whether current_exception +creates a new copy each time it is called. +-- end note] +

    + +

    +Throws: nothing. +

    +
    @@ -17077,843 +15351,2727 @@ Add the following to 25.2.3 [alg.swap]: +
    -

    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.

    +

    830. Incomplete list of char_traits specializations

    +

    Section: 21.1 [char.traits] Status: Open + Submitter: Dietmar Kühl Date: 2008-04-23

    +

    View all other issues in [char.traits].

    +

    View all issues with Open status.

    Discussion:

    -The recent draft (as well as the original proposal n2072) uses an -operational semantic -for get_money ([ext.manip]/3) and put_money ([ext.manip]/5), which uses + 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.

    -
    istreambuf_iterator<charT>
-
    +

    [ +Alisdair adds: +]

    -

    -and -

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

    [ +Sophia Antipolis: +]

    + +

    -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. +Idea of the issue is ok.

    -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). +Alisdair to provide wording, once that wording arrives, move to review.

    +
    +

    Proposed resolution:

    -In 27.6.4 [ext.manip]/3 within function f replace the first line + Replace paragraph 4 of 21.1 [char.traits] by:

    - -
    template <class charT, class traits, class moneyT> 
-void f(basic_ios<charT, traits>& str, moneyT& mon, bool intl) { 
-   typedef istreambuf_iterator<charT, traits> Iter;
-   ...
-
    - +

    -In 27.6.4 [ext.manip]/4 remove the first template charT parameter: + 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.

    +
    -
    template <class charT, class moneyT> unspecified put_money(const moneyT& mon, bool intl = false);
-
    -

    -In 27.6.4 [ext.manip]/5 within function f replace the first line -

    -
    template <class charT, class traits, class moneyT> 
-void f(basic_ios<charT, traits>& str, const moneyT& mon, bool intl) { 
-  typedef ostreambuf_iterator<charT, traits> Iter;
-  ...
-
    -

    -In 27.6.4 [ext.manip]/7 within function f replace the first line -

    - -
    template <class charT, class traits> 
-void f(basic_ios<charT, traits>& str, struct tm *tmb, const charT *fmt) { 
-  typedef istreambuf_iterator<charT, traits> Iter;
-  ...
-
    +
    +

    832. Applying constexpr to System error support

    +

    Section: 19.4 [syserr] Status: Open + Submitter: Beman Dawes Date: 2008-05-14

    +

    View other active issues in [syserr].

    +

    View all other issues in [syserr].

    +

    View all issues with Open status.

    +

    Discussion:

    -In 27.6.4 [ext.manip]/8 add const: +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.

    -
    template <class charT> unspecified put_time(const struct tm *tmb, const charT *fmt);
-
    -

    -In 27.6.4 [ext.manip]/9 within function f replace the first line +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.

    -
    template <class charT, class traits> 
-void f(basic_ios<charT, traits>& str, const struct tm *tmb, const charT *fmt) { 
-  typedef ostreambuf_iterator<charT, traits> Iter;
-  ...
-
    -

    -Add to the <iomanip> synopsis in 27.6 [iostream.format] +Thanks to Jens Maurer, Gabriel Dos Reis, and Bjarne Stroustrup for clarification of constexpr requirements.

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

    +LWG issue 804 is related in that it raises the question of whether the +exposition only member cat_ of class error_code (19.4.2 [syserr.errcode]) and class +error_condition (19.4.3 [syserr.errcondition]) should be presented as a reference or pointer. +While in the context of 804 that is arguably an editorial question, +presenting it as a pointer becomes more or less required with this +proposal, given constexpr does not play well with references. The +proposed resolution thus changes the private member to a pointer, which +also brings it in sync with real implementations. +

    +

    [ +Sophia Antipolis: +]

    +
    +On going question of extern pointer vs. inline functions for interface. +
    -
    -

    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>
+
    [
+Pre-San Francisco:
+]
    
 
-int main()
-{
-   std::pair<char *, char *> p (0,0);
-}
-
    +

    -I just got a bug report about that, because it's valid C++03, but not -C++0x. The important realization, for me, is that the emplace -proposal---which made push_back variadic, causing the push_back(0) -issue---didn't cause this break in backward compatibility. The break -actually happened when we added this pair constructor as part of adding -rvalue references into the language, long before variadic templates or -emplace came along: +Beman Dawes reports that this proposal is unimplementable, and thus NAD.

    - -
    template<class U, class V> pair(U&& x, V&& y);
-
    -

    -Now, concepts will address this issue by constraining that pair -constructor to only U's and V's that can properly construct "first" and -"second", e.g. (from -N2322): +Implementation would require constexpr objects of classes derived +from class error_category, which has virtual functions, and that is +not allowed by the core language. This was determined when trying to +implement the proposal using a constexpr enabled compiler provided +by Gabriel Dos Reis, and subsequently verified in discussions with +Gabriel and Jens Maurer.

    -
    template<class U , class V >
-requires Constructible<T1, U&&> && Constructible<T2, V&&>
-pair(U&& x , V&& y );
-
    - +

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

    812. unsolicited multithreading considered harmful?

    -

    Section: 25.3.1 [alg.sort] Status: New - Submitter: Paul McKenney Date: 2008-02-27

    -

    View all issues with New status.

    -

    Discussion:

    -Multi-threading is a good thing, but unsolicited multi-threading can -potentially be harmful. For example, sort() performance might be -greatly increased via a multithreaded implementation. However, such -a multithreaded implementation could result in concurrent invocations -of the user-supplied comparator. This would in turn result in problems -given a caching comparator that might be written for complex sort keys. -Please note that this is not a theoretical issue, as multithreaded -implementations of sort() already exist. +Change 19.4.1.5 [syserr.errcat.objects] Error category objects as indicated:

    + +
    +
    extern const error_category&* const get_generic_category();
+

    -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. +Returns: A reference generic_category shall point +to an a statically initialized object of a type derived from +class error_category.

    -

    [ -This may be covered by -N2410 -Thread-Safety in the Standard Library (Rev 1). -]

    - - - -

    Proposed resolution:

    +Remarks: The object's default_error_condition and equivalent virtual +functions shall behave as specified for the class error_category. The +object's name virtual function shall return a pointer to the string +"GENERIC".

    +
    extern const error_category&* const get_system_category();
+
    +

    +Returns: A reference system_category shall point +to an a statically +initialized object of a type derived from class error_category. +

    +

    +Remarks: The object's equivalent virtual functions shall behave as +specified for class error_category. The object's name virtual function +shall return a pointer to the string "system". The object's +default_error_condition virtual function shall behave as follows: +

    - -
    -

    813. "empty" undefined for shared_ptr

    -

    Section: 20.6.12.2 [util.smartptr.shared] Status: New - Submitter: Matt Austern Date: 2008-02-26

    -

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

    -

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

    -

    View all issues with New status.

    -

    Discussion:

    -Several places in 20.6.12.2 [util.smartptr.shared] refer to an "empty" shared_ptr. -However, that term is nowhere defined. The closest thing we have to a -definition is that the default constructor creates an empty shared_ptr -and that a copy of a default-constructed shared_ptr is empty. Are any -other shared_ptrs empty? For example, is shared_ptr((T*) 0) empty? What -are the properties of an empty shared_ptr? We should either clarify this -term or stop using it. -

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

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

    +Change 19.4.2.1 [syserr.errcode.overview] Class error_code overview as indicated: +

    -

    [ -Peter adds: -]

    +
    class error_code {
+public:
+  ...;
+  constexpr error_code(int val, const error_category&* cat);
+  ...
+  void assign(int val, const error_category&* cat);
+  ...
+  const error_category&* category() const;
+  ...
+private:
+  int val_;                    // exposition only
+  const error_category&* cat_; // exposition only
+
    +

    +Change 19.4.2.2 [syserr.errcode.constructors] Class error_code constructors as indicated: +

    +
    constexpr error_code(int val, const error_category&* cat);
+

    -Or, what is an "empty" shared_ptr? +Effects: Constructs an object of type error_code.

    - -
      -

    • -Are any other shared_ptrs empty? +Postconditions: val_ == val and cat_ == cat.

      -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. +Throws: Nothing.

      -
      -(*) 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. +Change 19.4.2.3 [syserr.errcode.modifiers] Class error_code modifiers as indicated:

      -
      • -
    • +
      +
      void assign(int val, const error_category&* cat);
+

      -What are the properties of an empty shared_ptr? +Postconditions: val_ == val and cat_ == cat.

      -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. +Throws: Nothing.

      -
      • +
    -

  • -We should either clarify this term or stop using it. +Change 19.4.2.4 [syserr.errcode.observers] Class error_code observers as indicated:

    + +
    +
    const error_category&* category() const;
+
    +

    -I don't agree with the imperative tone +Returns: cat_.

    -A clarification would be either a no-op - if it doesn't contradict the -existing wording - or a big mistake if it does. +Throws: Nothing.

    +
    +

    -I agree that a clarification that is formally a no-op may add value. +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
+
    +
    +

    -However, that term is nowhere defined. +Change 19.4.3.2 [syserr.errcondition.constructors] Class error_condition constructors as indicated:

    + +
    +
    constexpr error_condition(int val, const error_category&* cat);
+

    -Terms can be useful without a definition. Consider the following -simplistic example. We have a type X with the following operations -defined: +Effects: Constructs an object of type error_condition.

    -
    X x;
-X x2(x);
-X f(X x);
-X g(X x1, X x2);
-

    -A default-constructed value is green.
    -A copy has the same color as the original.
    -f(x) returns a red value if the argument is green, a green value otherwise.
    -g(x1,x2) returns a green value if the arguments are of the same color, a red value otherwise. +Postconditions: val_ == val and cat_ == cat.

    -

    -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. +Throws: Nothing.

    +

    -Green and red are "nowhere defined" and completely defined at the same time. +Change 19.4.3.3 [syserr.errcondition.modifiers] Class error_condition modifiers as indicated:

    -
    • - +
    +
    void assign(int val, const error_category&* cat);
+

    -Alisdair's wording is fine. +Postconditions: val_ == val and cat_ == cat. +

    +

    +Throws: Nothing.

    - -

    Proposed resolution:

    -Append the following sentance to 20.6.12.2 [util.smartptr.shared] +Change 19.4.3.4 [syserr.errcondition.observers] Class error_condition observers as indicated:

    +
    -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. +
    const error_category&* category() const;
+
    +

    +Returns: cat_. +

    +

    +Throws: Nothing. +

    +

    +Throughout 19.4 [syserr] System error support, change "category()." to "category()->". +Appears approximately six times. +

    +

    +[Partially Editorial] In 19.4.4 [syserr.compare] Comparison operators, +paragraphs 2 and 4, change "category.equivalent(" to +"category()->equivalent(". +

    +

    +Change 19.4.5.1 [syserr.syserr.overview] Class system_error overview as indicated: +

    +
    public:
+  system_error(error_code ec, const string& what_arg);
+  system_error(error_code ec);
+  system_error(int ev, const error_category&* ecat,
+      const string& what_arg);
+  system_error(int ev, const error_category&* ecat);
+
    -
    -

    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. +Change 19.4.5.2 [syserr.syserr.members] Class system_error members as indicated:

    +
    +
    system_error(int ev, const error_category&* ecat, const string& what_arg);
+
    +
    +

    +Effects: Constructs an object of class system_error. +

    +

    +Postconditions: code() == error_code(ev, ecat) and +strcmp(runtime_error::what(), what_arg.c_str()) == 0. +

    +
    -

    Proposed resolution:

    +
    system_error(int ev, const error_category&* ecat);
+
    +
    +

    +Effects: Constructs an object of class system_error. +

    +Postconditions: code() == error_code(ev, ecat) and +strcmp(runtime_error::what(), "") == 0.

    +
    +
    +
    -

    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.

    +

    833. Freestanding implementations header list needs review for C++0x

    +

    Section: 17.4.1.3 [compliance] Status: Open + Submitter: Beman Dawes Date: 2008-05-14

    +

    View all issues with Open status.

    Discussion:

    -std::function and reference_closure should use "perfect forwarding" as -described in the rvalue core proposal. +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:

    -

    -

    -

    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.

    +

    834. Unique_ptr::pointer requirements underspecified

    +

    Section: 20.7.11.2 [unique.ptr.single] Status: Open + Submitter: Daniel Krügler Date: 2008-05-14

    +

    View all issues with Open status.

    Discussion:

    -Library Issue 527 notes that bind(f, t1, ..., tN) -should be nofail when f, t1, ..., tN have nofail copy ctors. +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).

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

    -Should the nofail guarantee requested by Library Issue 527 be extended -to cover both calling bind() and copying the returned functor? +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).

    [ -Howard adds: +Sophia Antipolis: ]

    -tuple construction should probably have a similar guarantee. +

    +Howard: We maybe need a core concept PointerLike, but we don't need the +arithmetic (see shared_ptr vs. vector<T>::iterator. +

    +

    +Howard will go through and enumerate the individual requirements wrt. pointer for each member function. +

    Proposed resolution:

    +Add the following sentence just at the end of the newly proposed +20.7.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. +
    +
    -

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

    +

    835. tying two streams together (correction to DR 581)

    +

    Section: 27.4.4.2 [basic.ios.members] Status: New + Submitter: Martin Sebor Date: 2008-05-17

    +

    View other active issues in [basic.ios.members].

    +

    View all other issues in [basic.ios.members].

    View all issues with New status.

    Discussion:

    -

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

    -

    -

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

    -

    818. wording for memory ordering

    -

    Section: 29.1 [atomics.order] Status: New - Submitter: Jens Maurer Date: 2008-03-22

    -

    View all issues with New status.

    -

    Discussion:

    -

    -29.1 [atomics.order] p1 says in the table that -

    +

    +
    + 
    #include <iostream>
 
-
    
-
-
-
-
-
-
-
-
-
    ElementMeaning
    memory_order_acq_relthe operation has both acquire and release semantics
    
+int main ()
+{
+   std::cout.tie (&std::cerr);
+   std::cerr.tie (&std::cout);
+   std::cout << "cout\n";
+   std::cerr << "cerr\n";
+} 
+
    +
    + +

    Proposed resolution:

    +

    + +I think an easy way to plug the first hole is to add a requires clause +to ostream::tie(ostream *tiestr) requiring the this +pointer not be equal to any pointer on the list starting +with tiestr->tie() +through tiestr()->tie()->tie() and so on. I am not +proposing that we require implementations to traverse this list, +although I think we could since the list is unlikely to be very long. + +

    +

    + +Add a Requires clause to 27.4.4.2 [basic.ios.members] withethe following +text: + +

    +
    + +Requires: If (tiestr != 0) is +true, tiestr must not be reachable by traversing the +linked list of tied stream objects starting +from tiestr->tie(). + +
    +

    + +In addition, to prevent the infinite recursion that Bo writes about in +his comp.lang.c++.moderated post, I propose to change +27.6.2.4 [ostream::sentry], p2 like so: + +

    +
    + +If ((os.flags() & ios_base::unitbuf) && +!uncaught_exception()) is true, +calls os.flush() os.rdbuf()->pubsync(). + +
    + + + + +
    +

    836. + effects of money_base::space and + money_base::none on money_get +

    +

    Section: 22.2.6.1.2 [locale.money.get.virtuals] Status: New + Submitter: Martin Sebor Date: 2008-05-17

    +

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

    +

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

    +

    View all issues with New status.

    +

    Duplicate of: 670

    +

    Discussion:

    +

    + +In paragraph 2, 22.2.6.1.2 [locale.money.get.virtuals] specifies the following: + +

    +
    + +Where space or none appears in the format +pattern, except at the end, optional white space (as recognized +by ct.is) is consumed after any required space. + +
    +

    + +This requirement can be (and has been) interpreted two mutually +exclusive ways by different readers. One possible interpretation +is that: + +

    +
    +
      +
    1. + +where money_base::space appears in the format, at least +one space is required, and + +
      2. +
    2. + +where money_base::none appears in the format, space is +allowed but not required. + +
      3. +
    +
    +

    + +The other is that: + +

    +
    + +where either money_base::space or money_base::none appears in the format, white space is optional. + +
    + + +

    Proposed resolution:

    +

    + +I propose to change the text to make it clear that the first +interpretation is intended, that is, to make following change to +22.2.6.1.2 [locale.money.get.virtuals], p2: + +

    + +
    + +When money_base::space +or money_base::none appears as the last +element in the format pattern, except at the end, optional +white space (as recognized by ct.is) is consumed after +any required space. no white space is consumed. Otherwise, +where money_base::space appears in any of the initial +elements of the format pattern, at least one white space character is +required. Where money_base::none appears in any of the +initial elements of the format pattern, white space is allowed but not +required. In either case, any required followed by all optional white +space (as recognized by ct.is()) is consumed. +If (str.flags() & str.showbase) is false, ... + +
    + + + + +
    +

    837. + basic_ios::copyfmt() overly loosely specified +

    +

    Section: 27.4.4.2 [basic.ios.members] Status: New + Submitter: Martin Sebor Date: 2008-05-17

    +

    View other active issues in [basic.ios.members].

    +

    View all other issues in [basic.ios.members].

    +

    View all issues with New status.

    +

    Discussion:

    +

    + +The basic_ios::copyfmt() member function is specified in 27.4.4.2 [basic.ios.members] to have the following effects: + +

    +
    + +Effects: If (this == &rhs) does +nothing. Otherwise assigns to the member objects of *this +the corresponding member objects of rhs, except that + +
      +
    • + +rdstate() and rdbuf() are left unchanged; + +
      • +
    • + +exceptions() is altered last by +calling exceptions(rhs.except) + +
      • +
    • + +the contents of arrays pointed at by pword +and iword are copied not the pointers themselves + +
      • +
    +
    +

    + +Since the rest of the text doesn't specify what the member objects +of basic_ios are this seems a little too loose. + +

    + + +

    Proposed resolution:

    +

    + +I propose to tighten things up by adding a Postcondition clause +to the function like so: + +

    +
    + Postconditions: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    copyfmt() postconditions
    ElementValue
    rdbuf()unchanged
    tie()rhs.tie()
    rdstate()unchanged
    exceptions()rhs.exceptions()
    flags()rhs.flags()
    width()rhs.width()
    precision()rhs.precision()
    fill()rhs.fill()
    getloc()rhs.getloc()
    +
    +

    + +The format of the table follows Table 117 (as +of N2588): basic_ios::init() +effects. + +

    +

    + +The intent of the new table is not to impose any new requirements or +change existing ones, just to be more explicit about what I believe is +already there. + +

    + + + + +
    +

    838. + can an end-of-stream iterator become a non-end-of-stream one? +

    +

    Section: 24.5.1 [istream.iterator] Status: New + Submitter: Martin Sebor Date: 2008-05-17

    +

    View other active issues in [istream.iterator].

    +

    View all other issues in [istream.iterator].

    +

    View all issues with New status.

    +

    Discussion:

    +

    + +From message c++std-lib-20003... + +

    +

    + +The description of istream_iterator in +24.5.1 [istream.iterator], p1 specifies that objects of the +class become the end-of-stream (EOS) iterators under the +following condition (see also issue 836 another problem +with this paragraph): + +

    +
    + +If the end of stream is reached (operator void*() on the +stream returns false), the iterator becomes equal to +the end-of-stream iterator value. + +
    +

    + +One possible implementation approach that has been used in practice is +for the iterator to set its in_stream pointer to 0 when +it reaches the end of the stream, just like the default ctor does on +initialization. The problem with this approach is that +the Effects clause for operator++() says the +iterator unconditionally extracts the next value from the stream by +evaluating *in_stream >> value, without checking +for (in_stream == 0). + +

    +

    + +Conformance to the requirement outlined in the Effects clause +can easily be verified in programs by setting eofbit +or failbit in exceptions() of the associated +stream and attempting to iterate past the end of the stream: each +past-the-end access should trigger an exception. This suggests that +some other, more elaborate technique might be intended. + +

    +

    + +Another approach, one that allows operator++() to attempt +to extract the value even for EOS iterators (just as long +as in_stream is non-0) is for the iterator to maintain a +flag indicating whether it has reached the end of the stream. This +technique would satisfy the presumed requirement implied by +the Effects clause mentioned above, but it isn't supported by +the exposition-only members of the class (no such flag is shown). This +approach is also found in existing practice. + +

    +

    + +The inconsistency between existing implementations raises the question +of whether the intent of the specification is that a non-EOS iterator +that has reached the EOS become a non-EOS one again after the +stream's eofbit flag has been cleared? That is, are the +assertions in the program below expected to pass? + +

    +
    + 
       sstream strm ("1 ");
+   istream_iterator eos;
+   istream_iterator it (strm);
+   int i;
+   i = *it++
+   assert (it == eos);
+   strm.clear ();
+   strm << "2 3 ";
+   assert (it != eos);
+   i = *++it;
+   assert (3 == i);
+
    +
    +

    + +Or is it intended that once an iterator becomes EOS it stays EOS until +the end of its lifetime? + +

    + + +

    Proposed resolution:

    +

    + +The discussion of this issue on the reflector suggests that the intent +of the standard is for an istreambuf_iterator that has +reached the EOS to remain in the EOS state until the end of its +lifetime. Implementations that permit EOS iterators to return to a +non-EOS state may only do so as an extension, and only as a result of +calling istream_iterator member functions on EOS +iterators whose behavior is in this case undefined. + +

    +

    + +To this end we propose to change 24.5.1 [istream.iterator], p1, +as follows: + +

    +
    + +The result of operator-> on an end-of-stream +is not defined. For any other iterator value a const T* +is returned. Invoking operator++() on +an end-of-stream iterator is undefined. It is impossible +to store things into istream iterators... + +
    +

    + +Add pre/postconditions to the member function descriptions of istream_iterator like so: + +

    +
    + +
    istream_iterator();
    + +Effects: Constructs the end-of-stream iterator.
    +Postcondition: in_stream == 0. + +
    istream_iterator(istream_type &s);
    + +Effects: Initializes in_stream with &s. value +may be initialized during construction or the first time it is +referenced.
    +Postcondition: in_stream == &s. + +
    istream_iterator(const istream_iterator &x);
    + +Effects: Constructs a copy of x.
    +Postcondition: in_stream == x.in_stream. + +
    istream_iterator& operator++();
    + +Requires: in_stream != 0.
    +Effects: *in_stream >> value. + +
    istream_iterator& operator++(int);
    + +Requires: in_stream != 0.
    +Effects: + 
    istream_iterator tmp (*this);
+*in_stream >> value;
+return tmp;
+
    +
    +
    + + + + +
    +

    839. Maps and sets missing splice operation

    +

    Section: 23.3 [associative], 23.4 [unord] Status: Open + Submitter: Alan Talbot Date: 2008-05-18

    +

    View all issues with Open status.

    +

    Discussion:

    +

    +Splice is a very useful feature of list. This functionality is also very +useful for any other node based container, and I frequently wish it were +available for maps and sets. It seems like an omission that these +containers lack this capability. Although the complexity for a splice is +the same as for an insert, the actual time can be much less since the +objects need not be reallocated and copied. When the element objects are +heavy and the compare operations are fast (say a map<int, huge_thingy>) +this can be a big win. +

    + +

    +Suggested resolution: +

    + +

    +Add the following signatures to map, set, multimap, multiset, and the unordered associative containers: +

    +
     
+void splice(list<T,Allocator>&& x);
+void splice(list<T,Allocator>&& x, const_iterator i);
+void splice(list<T,Allocator>&& x, const_iterator first, const_iterator last);
+
    + +

    +Hint versions of these are also useful to the extent hint is useful. +(I'm looking for guidance about whether hints are in fact useful.) +

    + +
     
+void splice(const_iterator position, list<T,Allocator>&& x);
+void splice(const_iterator position, list<T,Allocator>&& x, const_iterator i);
+void splice(const_iterator position, list<T,Allocator>&& x, const_iterator first, const_iterator last);
+
    + +

    [ +Sophia Antipolis: +]

    + + +
    +

    +Don't try to splice "list" into the other containers, it should be container-type. +

    +

    +forward_list already has splice_after. +

    +

    +Would "splice" make sense for an unordered_map? +

    +

    +Jens, Robert: "splice" is not the right term, it implies maintaining ordering in lists. +

    +

    +Howard: adopt? +

    +

    +Jens: absorb? +

    +

    +Alan: subsume? +

    +

    +Robert: recycle? +

    +

    +Howard: transfer? (but no direction) +

    +

    +Jens: transfer_from. No. +

    +

    +Alisdair: Can we give a nothrow guarantee? If your compare() and hash() doesn't throw, yes. +

    +

    +Daniel: For unordered_map, we can't guarantee nothrow. +

    +
    + + + +

    Proposed resolution:

    + + + + + +
    +

    841. cstdint.syn inconsistent with C99

    +

    Section: 18.3.1 [cstdint.syn] Status: New + Submitter: Martin Sebor Date: 2008-05-17

    +

    View all other issues in [cstdint.syn].

    +

    View all issues with New status.

    +

    Discussion:

    +

    + +In specifying the names of macros and types defined in +header <stdint.h>, C99 makes use of the +symbol N to accommodate unusual platforms with +word sizes that aren't powers of two. C99 +permits N to take on any positive integer value +(including, for example, 24). + +

    +

    + +In cstdint.syn Header <cstdint> +synopsis, C++ on the other hand, fixes the value +of N to 8, 16, 32, and 64, and specifies only +types with these exact widths. + +

    +

    +

    + +In addition, paragraph 1 of the same section makes use of a rather +informal shorthand notation to specify sets of macros. When +interpreted strictly, the notation specifies macros such +as INT_8_MIN that are not intended to be specified. + +

    + +Finally, the section is missing the usual table of symbols defined +in that header, making it inconsistent with the rest of the +specification. + +

    + +

    Proposed resolution:

    +

    + +I propose to use the same approach in the C++ spec as C99 uses, that +is, to specify the header synopsis in terms of "exposition only" types +that make use of the symbol N to denote one or +more of a theoretically unbounded set of widths. + +

    +

    + +Further, I propose to add a new table to section listing the symbols +defined in the header using a more formal notation that avoids +introducing inconsistencies. + +

    +

    + +To this effect, in cstdint.syn +Header <cstdint> synopsis, replace both the +synopsis and paragraph 1 with the following text: + +

    +
    +

    +

      +
    1. + +In the names defined in the <cstdint> header, the +symbol N represents a positive decimal integer +with no leading zeros (e.g., 8 or 24, but not 0, 04, or 048). With the +exception of exact-width types, macros and types for values +of N in the set of 8, 16, 32, and 64 are +required. Exact-width types, and any macros and types for values +of N other than 8, 16, 32, and 64 are +optional. However, if an implementation provides integer types with +widths of 8, 16, 32, or 64 bits, the corresponding exact-width types +and macros are required. + +
      2. +
    + + 
    namespace std {
+
+   // required types
+
+   // Fastest minimum-width integer types
+   typedef signed integer type   int_fast8_t;
+   typedef signed integer type   int_fast16_t;
+   typedef signed integer type   int_fast32_t;
+   typedef signed integer type   int_fast64_t;
+
+   typedef unsigned integer type uint_fast8_t;
+   typedef unsigned integer type uint_fast16_t;
+   typedef unsigned integer type uint_fast32_t;
+   typedef unsigned integer type uint_fast64_t;
+
+   // Minimum-width integer types
+   typedef signed integer type   int_least8_t;
+   typedef signed integer type   int_least16_t;
+   typedef signed integer type   int_least32_t;
+   typedef signed integer type   int_least64_t;
+
+   typedef unsigned integer type uint_least8_t;
+   typedef unsigned integer type uint_least16_t;
+   typedef unsigned integer type uint_least32_t;
+   typedef unsigned integer type uint_least64_t;
+
+   // Greatest-width integer types
+   typedef signed integer type   intmax_t;
+   typedef unsigned integer type uintmax_t;
+
+   // optionally defined types
+
+   // Exact-width integer types
+   typedef signed integer type   intN_t;
+   typedef unsigned integer type uintN_t;
+
+   // Fastest minimum-width integer types for values
+   // of N other than 8, 16, 32, and 64
+   typedef signed integer type   uint_fastN_t;
+   typedef unsigned integer type uint_fastN_t;
+
+   // Minimum-width integer types for values
+   // of N other than 8, 16, 32, and 64
+   typedef signed integer type   uint_leastN_t;
+   typedef unsigned integer type uint_leastN_t;
+
+   // Integer types capable of holding object pointers
+   typedef signed integer type   intptr_t;
+   typedef signed integer type   intptr_t;
+
+}
    +
    +

    + +[Note to editor: Remove all of the existing paragraph 1 from cstdint.syn.] + +

    +
    + Table ??: Header <cstdint> synopsis + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    TypeName(s)
    Macros:INTN_MININTN_MAXUINTN_MAX
    INT_FASTN_MININT_FASTN_MAXUINT_FASTN_MAX
    INT_LEASTN_MININT_LEASTN_MAXUINT_LEASTN_MAX
    INTPTR_MININTPTR_MAXUINTPTR_MAX
    INTMAX_MININTMAX_MAXUINTMAX_MAX
    PTRDIFF_MINPTRDIFF_MAXPTRDIFF_MAX
    SIG_ATOMIC_MINSIG_ATOMIC_MAXSIZE_MAX
    WCHAR_MINWCHAR_MAX
    WINT_MINWINT_MAX
    INTN_C()UINTN_C()
    INTMAX_C()UINTMAX_C()
    Types:intN_tuintN_t
    int_fastN_tuint_fastN_t
    int_leastN_tuint_leastN_t
    intptr_tuintptr_t
    intmax_tuintmax_t
    +
    + + + + + +
    +

    842. ConstructibleAsElement and bit containers

    +

    Section: 23.1 [container.requirements], 23.2.7 [vector.bool], 23.3.5 [template.bitset] Status: Ready + Submitter: Howard Hinnant Date: 2008-06-03

    +

    View other active issues in [container.requirements].

    +

    View all other issues in [container.requirements].

    +

    View all issues with Ready status.

    +

    Discussion:

    +

    +23.1 [container.requirements]/p3 says: +

    + +
    +Objects stored in these components shall be constructed using +construct_element (20.6.9). For each operation that inserts an +element of type T into a container (insert, +push_back, push_front, emplace, etc.) with +arguments args... T shall be ConstructibleAsElement, +as described in table 88. [Note: If the component is instantiated +with a scoped allocator of type A (i.e., an allocator for which +is_scoped_allocator<A>::value is true), then +construct_element may pass an inner allocator argument to +T's constructor. -- end note] +
    + +

    +However vector<bool, A> (23.2.7 [vector.bool]) and bitset<N> +(23.3.5 [template.bitset]) store bits, not bools, and bitset<N> +does not even have an allocator. But these containers are governed by this clause. Clearly this +is not implementable. +

    + + +

    Proposed resolution:

    +

    +Change 23.1 [container.requirements]/p3: +

    + +
    +Objects stored in these components shall be constructed using +construct_element (20.6.9), unless otherwise specified. +For each operation that inserts an +element of type T into a container (insert, +push_back, push_front, emplace, etc.) with +arguments args... T shall be ConstructibleAsElement, +as described in table 88. [Note: If the component is instantiated +with a scoped allocator of type A (i.e., an allocator for which +is_scoped_allocator<A>::value is true), then +construct_element may pass an inner allocator argument to +T's constructor. -- end note] +
    + +

    +Change 23.2.7 [vector.bool]/p2: +

    + +
    +Unless described below, all operations have the same requirements and semantics as the primary vector template, +except that operations dealing with the bool value type map to bit values in the container storage, +and construct_element (23.1 [container.requirements]) is not used to construct these values. +
    + +

    +Move 23.3.5 [template.bitset] to clause 20. +

    + + + + + + +
    +

    843. Reference Closure

    +

    Section: 20.6.17.1 [func.referenceclosure.cons] Status: New + Submitter: Lawrence Crowl Date: 2008-06-02

    +

    View all issues with New status.

    +

    Discussion:

    +

    +The std::reference_closure type has a deleted copy assignment operator +under the theory that references cannot be assigned, and hence the +assignment of its reference member must necessarily be ill-formed. +

    +

    +However, other types, notably std::reference_wrapper and std::function +provide for the "copying of references", and thus the current definition +of std::reference_closure seems unnecessarily restrictive. In particular, +it should be possible to write generic functions using both std::function +and std::reference_closure, but this generality is much harder when +one such type does not support assignment. +

    +

    +The definition of reference_closure does not necessarily imply direct +implementation via reference types. Indeed, the reference_closure is +best implemented via a frame pointer, for which there is no standard +type. +

    +

    +The semantics of assignment are effectively obtained by use of the +default destructor and default copy assignment operator via +

    + +
    x.~reference_closure(); new (x) reference_closure(y);
+
    + +

    +So the copy assignment operator generates no significant real burden +to the implementation. +

    + + +

    Proposed resolution:

    +

    +In 20.6.17 [func.referenceclosure] Class template reference_closure, +replace the =delete in the copy assignment operator in the synopsis +with =default. +

    + +
    template<class R , class... ArgTypes > 
+  class reference_closure<R (ArgTypes...)> { 
+  public:
+     ...
+     reference_closure& operator=(const reference_closure&) = delete default;
+     ...
+
    + +

    +In 20.6.17.1 [func.referenceclosure.cons] Construct, copy, destroy, +add the member function description +

    + +
    +
    reference_closure& operator=(const reference_closure& f)
+
    +
    +

    +Postcondition: *this is a copy of f. +

    +

    +Returns: *this. +

    +
    +
    + + + + + + + +
    +

    844. complex pow return type is ambiguous

    +

    Section: 26.3.9 [cmplx.over] Status: Ready + Submitter: Howard Hinnant Date: 2008-06-03

    +

    View all issues with Ready status.

    +

    Discussion:

    +

    +The current working draft is in an inconsistent state. +

    + +

    +26.3.8 [complex.transcendentals] says that: +

    + +
    +pow(complex<float>(), int()) returns a complex<float>. +
    + +

    +26.3.9 [cmplx.over] says that: +

    + +
    +pow(complex<float>(), int()) returns a complex<double>. +
    + +

    [ +Sophia Antipolis: +]

    + + +
    +

    +Since int promotes to double, and C99 doesn't have an int-based +overload for pow, the C99 result is complex<double>, see also C99 +7.22, see also library issue 550. +

    +

    +Special note: ask P.J. Plauger. +

    +
    +Looks fine. +
    +
    + + +

    Proposed resolution:

    +

    +Strike this pow overload in 26.3.1 [complex.synopsis] and in 26.3.8 [complex.transcendentals]: +

    + +
    template<class T> complex<T> pow(const complex<T>& x, int y);
+
    + + + + + +
    +

    845. atomics cannot support aggregate initialization

    +

    Section: 29.3 [atomics.types] Status: New + Submitter: Alisdair Meredith Date: 2008-06-03

    +

    View other active issues in [atomics.types].

    +

    View all other issues in [atomics.types].

    +

    View all issues with New status.

    +

    Discussion:

    +

    +The atomic classes (and class templates) are required to support aggregate +initialization (29.3.1 [atomics.types.integral]p2 / 29.3.2 [atomics.types.address]p1) +yet also have user declared constructors, so cannot be aggregates. +

    +

    +This problem might be solved with the introduction of the proposed +initialization syntax at Antipolis, but the wording above should be altered. +Either strike the sentence as redundant with new syntax, or refer to 'brace +initialization'. +

    + +

    [ +Jens adds: +]

    + + +
    +

    +Note that +

    +
    atomic_itype a1 = { 5 };
+
    +

    +would be aggregate-initialization syntax (now coming under the disguise +of brace initialization), but would be ill-formed, because the corresponding +constructor for atomic_itype is explicit. This works, though: +

    +
    atomic_itype a2 { 6 };
+
    + +
    + + +

    Proposed resolution:

    +

    +In 29.3.1 [atomics.types.integral], strike the following sentence from paragraph 2: +

    + +
    +The atomic integral types shall have standard layout. They shall each have a trivial default constructor, a constexpr +explicit value constructor, a deleted copy constructor, a deleted copy assignment operator, and a trivial destructor. +They shall each support aggregate initialization syntax. +
    + +

    [ +2008-08-18, Lawrence adds: +]

    + +
    +The syntactic compatibility of initialization with C is important. +I suggest a different resolution; remove the explicit from the +constructor. For the same reasons we can have implicit conversions, +we can also have implicit constructors. +
    + + + + + +
    +

    846. No definition for constructor

    +

    Section: 29.3 [atomics.types] Status: New + Submitter: Alisdair Meredith Date: 2008-06-03

    +

    View other active issues in [atomics.types].

    +

    View all other issues in [atomics.types].

    +

    View all issues with New status.

    +

    Discussion:

    +

    +The atomic classes and class templates (29.3.1 [atomics.types.integral] / +29.3.2 [atomics.types.address]) have a constexpr +constructor taking a value of the appropriate type for that atomic. +However, neither clause provides semantics or a definition for this +constructor. I'm not sure if the initialization is implied by use of +constexpr keyword (which restricts the form of a constructor) but even if +that is the case, I think it is worth spelling out explicitly as the +inference would be far too subtle in that case. +

    + + +

    Proposed resolution:

    +

    +

    + + + + + +
    +

    847. string exception safety guarantees

    +

    Section: 21.3.1 [string.require] Status: New + Submitter: Hervé Brönnimann Date: 2008-06-05

    +

    View all other issues in [string.require].

    +

    View all issues with New status.

    +

    Discussion:

    +

    +In March, on comp.lang.c++.moderated, I asked what were the +string exception safety guarantees are, because I cannot see +*any* in the working paper, and any implementation I know offers +the strong exception safety guarantee (string unchanged if a +member throws exception). The closest the current draft comes to +offering any guarantees is 21.3 [basic.string], para 3: +

    + +
    +The class template basic_string conforms to the requirements +for a Sequence Container (23.1.1), for a Reversible Container (23.1), +and for an Allocator-aware container (91). The iterators supported by +basic_string are random access iterators (24.1.5). +
    + +

    +However, the chapter 23 only says, on the topic of exceptions: 23.1 [container.requirements], +para 10: +

    + +
    +

    +Unless otherwise specified (see 23.2.2.3 and 23.2.6.4) all container types defined in this clause meet the following +additional requirements: +

    + +
      +
    • if an exception is thrown by...
      • +
    +
    + +

    +I take it as saying that this paragraph has *no* implication on +std::basic_string, as basic_string isn't defined in Clause 23 and +this paragraph does not define a *requirement* of Sequence +nor Reversible Container, just of the models defined in Clause 23. +In addition, LWG Issue 718 proposes to remove 23.1 [container.requirements], para 3. +

    + +

    +Finally, the fact that no operation on Traits should throw +exceptions has no bearing, except to suggest (since the only +other throws should be allocation, out_of_range, or length_error) +that the strong exception guarantee can be achieved. +

    + +

    +The reaction in that group by Niels Dekker, Martin Sebor, and +Bo Persson, was all that this would be worth an LWG issue. +

    + +

    +A related issue is that erase() does not throw. This should be +stated somewhere (and again, I don't think that the 23.1 [container.requirements], para 1 +applies here). +

    + + + +

    Proposed resolution:

    +

    +Add a blanket statement in 21.3.1 [string.require]: +

    + +
    +

    +- if any member function or operator of basic_string<charT, traits, Allocator> +throws, that function or operator has no effect. +

    +

    +- no erase() or pop_back() function throws. +

    +
    + +

    +As far as I can tell, this is achieved by any implementation. If I made a +mistake and it is not possible to offer this guarantee, then +either state all the functions for which this is possible +(certainly at least operator+=, append, assign, and insert), +or add paragraphs to Effects clauses wherever appropriate. +

    + + + + + +
    +

    848. missing std::hash specializations for std::bitset/std::vector<bool>

    +

    Section: 20.6.16 [unord.hash] Status: Ready + Submitter: Thorsten Ottosen Date: 2008-06-05

    +

    View all issues with Ready status.

    +

    Discussion:

    +

    +In the current working draft, std::hash<T> is specialized for builtin +types and a few other types. Bitsets seems like one that is missing from +the list, not because it cannot not be done by the user, but because it +is hard or impossible to write an efficient implementation that works on +32bit/64bit chunks at a time. For example, std::bitset is too much +encapsulated in this respect. +

    + + +

    Proposed resolution:

    +

    +Add the following to the synopsis in 20.6 [function.objects]/2: +

    + +
    template<class Allocator> struct hash<std::vector<bool,Allocator>>;
+template<size_t N> struct hash<std::bitset<N>>;
+
    + +

    +Modify the last sentence of 20.6.16 [unord.hash]/1 to end with: +

    + +
    +... and std::string, std::u16string, std::u32string, std::wstring, +std::error_code, std::thread::id, std::bitset, and std::vector<bool>.
    + + + + + +
    +

    849. missing type traits to compute root class and derived class of types in a class hierachy

    +

    Section: 20.5.7 [meta.trans.other] Status: New + Submitter: Thorsten Ottosen Date: 2008-06-05

    +

    View other active issues in [meta.trans.other].

    +

    View all other issues in [meta.trans.other].

    +

    View all issues with New status.

    +

    Discussion:

    +

    +The type traits library contains various traits to dealt with +polymorphic types, e.g. std::has_virtual_destructor, std::is_polymorphic +and std::is_base_of. However, there is no way to compute the unique +public base class of a type if such one exists. Such a trait could be +very useful if one needs to instantiate a specialization made for the +root class whenever a derived class is passed as parameter. For example, +imagine that you wanted to specialize std::hash for a class +hierarchy---instead of specializing each class, you could specialize the +std::hash<root_class> and provide a partial specialization that worked +for all derived classes. +

    +

    -To my naked eye, that seems to imply that even an atomic read has both -acquire and release semantics. +This ability---to specify operations in terms of their equivalent in the +root class---can be done with e.g. normal functions, but there is, +AFAIK, no way to do it for class templates. Being able to access +compile-time information about the type-hierachy can be very powerful, +and I therefore also suggest traits that computes the directly derived +class whenever that is possible.

    -Then, p1 says in the table: +If the computation can not be done, the traits should fall back on an +identity transformation. I expect this gives the best overall usability. +

    + + +

    Proposed resolution:

    +

    +Add the following to the synopsis in 20.5.2 [meta.type.synop] under "other transformations": +

    + +
    template< class T > struct direct_base_class;
+template< class T > struct direct_derived_class;
+template< class T > struct root_base_class;
+
    + +

    +Add three new entries to table 51 (20.5.7 [meta.trans.other]) with the following content

    - + - - + + + + + + + + + + + + +
    ElementMeaningTemplateConditionComments
    memory_order_seq_cstthe operation has both acquire and release semantics, - and, in addition, has sequentially-consistent operation orderingtemplate< class T > struct direct_base_class;T shall be a complete type.The member typedef type shall equal the accessible unambiguous direct base class of T. +If no such type exists, the member typedef type shall equal T.
    template< class T > struct direct_derived_class;T shall be a complete type.The member typedef type shall equal the unambiguous type which has T +as an accessible unambiguous direct base class. If no such type exists, the member typedef +type shall equal T.
    template< class T > struct root_base_class;T shall be a complete type.The member typedef type shall equal the accessible unambiguous most indirect base class of +T. If no such type exists, the member typedef type shall equal T.
    + + + + + +
    +

    850. Should shrink_to_fit apply to std::deque?

    +

    Section: 23.2.2.2 [deque.capacity] Status: Ready + Submitter: Niels Dekker Date: 2008-06-05

    +

    View other active issues in [deque.capacity].

    +

    View all other issues in [deque.capacity].

    +

    View all issues with Ready status.

    +

    Discussion:

    -So that seems to be "the same thing" as memory_order_acq_rel, with additional -constraints. +Issue 755 added a shrink_to_fit function to std::vector and std::string. +It did not yet deal with std::deque, because of the fundamental +difference between std::deque and the other two container types. The +need for std::deque may seem less evident, because one might think that +for this container, the overhead is a small map, and some number of +blocks that's bounded by a small constant. +

    +

    +The container overhead can in fact be arbitrarily large (i.e. is not +necessarily O(N) where N is the number of elements currently held by the +deque). As Bill Plauger noted in a reflector message, unless the map of +block pointers is shrunk, it must hold at least maxN/B pointers where +maxN is the maximum of N over the lifetime of the deque since its +creation. This is independent of how the map is implemented +(vector-like circular buffer and all), and maxN bears no relation to N, +the number of elements it currently holds. +

    +

    +Hervé Brönnimann reports a situation where a deque of requests grew very +large due to some temporary backup (the front request hanging), and the +map of the deque grew quite large before getting back to normal. Just +to put some color on it, assuming a deque with 1K pointer elements in +steady regime, that held, at some point in its lifetime, maxN=10M +pointers, with one block holding 128 elements, the spine must be at +least (maxN / 128), in that case 100K. In that case, shrink-to-fit +would allow to reuse about 100K which would otherwise never be reclaimed +in the lifetime of the deque. +

    +

    +An added bonus would be that it *allows* implementations to hang on to +empty blocks at the end (but does not care if they do or not). A +shrink_to_fit would take care of both shrinks, and guarantee that at +most O(B) space is used in addition to the storage to hold the N +elements and the N/B block pointers.

    + +

    Proposed resolution:

    -I'm then reading p2, where it says: +To Class template deque 23.2.2 [deque] synopsis, add: +

    +
    void shrink_to_fit();
+
    + +

    +To deque capacity 23.2.2.2 [deque.capacity], add:

    +
    void shrink_to_fit();
+
    -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. +Remarks: shrink_to_fit is a non-binding request to reduce memory +use. [Note: The request is non-binding to allow latitude for +implementation-specific optimizations. -- end note] +
    + + + + +
    +

    851. simplified array construction

    +

    Section: 23.2.1 [array] Status: Review + Submitter: Benjamin Kosnik Date: 2008-06-05

    +

    View other active issues in [array].

    +

    View all other issues in [array].

    +

    View all issues with Review status.

    +

    Discussion:

    +

    +This is an issue that came up on the libstdc++ list, where a +discrepency between "C" arrays and C++0x's std::array was pointed +out. +

    +

    -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? +In "C," this array usage is possible: +

    + +
    int ar[] = {1, 4, 6};
+
    + +

    +But for C++, +

    + +
    std::array<int> a = { 1, 4, 6 }; // error
+
    + +

    +Instead, the second parameter of the array template must be +explicit, like so: +

    + +
    std::array<int, 3> a = { 1, 4, 6 };
+
    + +

    +Doug Gregor proposes the following solution, that assumes +generalized initializer lists. +

    + +
    template<typename T, typename... Args>
+inline array<T, sizeof...(Args)> 
+make_array(Args&&... args) 
+{ return { std::forward<Args>(args)... };  }
+
    + +

    +Then, the way to build an array from a list of unknown size is: +

    + +
    auto a = make_array<T>(1, 4, 6);
+
    + + + +

    Proposed resolution:

    +

    +Add to the array synopis in 23.2 [sequences]: +

    + +
    template<typename T, typename... Args>
+  requires Convertible<Args, T>...
+  array<T, sizeof...(Args)> 
+  make_array(Args&&... args);
+
    + +

    +Append after 23.2.1.6 [array.tuple] Tuple interface to class template array the +following new section. +

    + +
    +

    +23.2.1.7 Convenience interface to class template array [array.tuple] +

    + +
    template<typename T, typename... Args>
+  requires Convertible<Args, T>...
+  array<T, sizeof...(Args)> 
+  make_array(Args&&... args);
+
    + +
    +

    +Returns: {std::forward<Args>(args)...} +

    +
    +
    + + + + + +
    +

    852. unordered containers begin(n) mistakenly const

    +

    Section: 23.4 [unord] Status: Ready + Submitter: Robert Klarer Date: 2008-06-12

    +

    View other active issues in [unord].

    +

    View all other issues in [unord].

    +

    View all issues with Ready status.

    +

    Discussion:

    +

    +In 3 of the four unordered containers the local begin member is mistakenly declared const: +

    + +
    local_iterator begin(size_type n) const;
+
    + + +

    Proposed resolution:

    +

    +Change the synopsis in 23.4.1 [unord.map], 23.4.2 [unord.multimap], and 23.4.4 [unord.multiset]: +

    + +
    local_iterator begin(size_type n) const;
+
    + + + + + +
    +

    853. to_string needs updating with zero and one

    +

    Section: 23.3.5 [template.bitset] Status: New + Submitter: Howard Hinnant Date: 2008-06-18

    +

    View all other issues in [template.bitset].

    +

    View all issues with New status.

    +

    Discussion:

    +

    +Issue 396 adds defaulted arguments to the to_string member, but neglects to update +the three newer to_string overloads. +

    + + +

    Proposed resolution:

    +

    +Change the synopsis in 23.3.5 [template.bitset], and the signatures in 23.3.5.2 [bitset.members] to: +

    + +
    template <class charT, class traits> 
+  basic_string<charT, traits, allocator<charT> > to_string(charT zero = charT('0'), charT one = charT('1')) const; 
+template <class charT> 
+  basic_string<charT, char_traits<charT>, allocator<charT> > to_string(charT zero = charT('0'), charT one = charT('1')) const; 
+basic_string<char, char_traits<char>, allocator<char> > to_string(char zero = '0', char one = '1') const; 
+
    + + + + + +
    +

    854. default_delete converting constructor underspecified

    +

    Section: 20.7.11.1.1 [unique.ptr.dltr.dflt] Status: New + Submitter: Howard Hinnant Date: 2008-06-18

    +

    View all issues with New status.

    +

    Discussion:

    +

    +No relationship between U and T in the converting constructor for default_delete template. +

    +

    +Requirements: U* is convertible to T* and has_virtual_destructor<T>; +the latter should also become a concept. +

    +

    +Rules out cross-casting. +

    +

    +The requirements for unique_ptr conversions should be the same as those on the deleter. +

    + + +

    Proposed resolution:

    +

    +Change 20.7.11.1.1 [unique.ptr.dltr.dflt]: +

    + +
    namespace std { 
+  template <class T> struct default_delete { 
+    default_delete(); 
+    template <class U>
+      requires Convertible<U*, T*> && HasVirtualDestructor<T>
+      default_delete(const default_delete<U>&); 
+    void operator()(T*) const; 
+  }; 
+}
+
    + +

    +... +

    + +
    template <class U>
+  requires Convertible<U*, T*> && HasVirtualDestructor<T>
+  default_delete(const default_delete<U>& other);
+
    + + + + + + +
    +

    855. capacity() and reserve() for deque?

    +

    Section: 23.2.2.2 [deque.capacity] Status: New + Submitter: Hervé Brönnimann Date: 2008-06-11

    +

    View other active issues in [deque.capacity].

    +

    View all other issues in [deque.capacity].

    +

    View all issues with New status.

    +

    Discussion:

    +

    +The main point is that capacity can be viewed as a mechanism to +guarantee the validity of iterators when only push_back/pop_back +operations are used. For vector, this goes with reallocation. For +deque, this is a bit more subtle: capacity() of a deque may shrink, +whereas that of vector doesn't. In a circular buffer impl. of the +map, as Howard did, there is very similar notion of capacity: as long +as size() is less than B * (total size of the map - 2), it is +guaranteed that no iterator is invalidated after any number of +push_front/back and pop_front/back operations. But this does not +hold for other implementations. +

    +

    +Still, I believe, capacity() can be defined by size() + how many +push_front/back minus pop_front/back that can be performed before +terators are invalidated. In a classical impl., capacity() = size() ++ the min distance to either "physical" end of the deque (i.e., +counting the empty space in the last block plus all the blocks until +the end of the map of block pointers). In Howard's circular buffer +impl., capacity() = B * (total size of the map - 2) still works with +this definition, even though the guarantee could be made stronger. +

    +

    +A simple picture of a deque: +

    +
    A-----|----|-----|---F+|++++|++B--|-----|-----Z
+
    +

    +(A,Z mark the beginning/end, | the block boundaries, F=front, B=back, +and - are uninitialized, + are initialized) +In that picture: capacity = size() + min(dist(A,F),dist(B,Z)) = min +(dist(A,B),dist(F,Z)). +

    +

    +Reserve(n) can grow the map of pointers and add possibly a number of +empty blocks to it, in order to guarantee that the next n-size() +push_back/push_front operations will not invalidate iterators, and +also will not allocate (i.e. cannot throw). The second guarantee is +not essential and can be left as a QoI. I know well enough existing +implementations of deque (sgi/stl, roguewave, stlport, and +dinkumware) to know that either can be implemented with no change to +the existing class layout and code, and only a few modifications if +blocks are pre-allocated (instead of always allocating a new block, +check if the next entry in the map of block pointers is not zero). +

    +

    +Due to the difference with vector, wording is crucial. Here's a +proposed wording to make things concrete; I tried to be reasonably +careful but please double-check me: +

    + + + +

    Proposed resolution:

    + +

    +Add new signatures to synopsis in 23.2.2 [deque]: +

    + +
    size_type capacity() const;
+bool reserve(size_type n);
+
    + +

    +Add new signatures to 23.2.2.2 [deque.capacity]: +

    + +
    +
    size_type capacity() const;
+
    +
    +

    +1 Returns: An upper bound on n + max(n_f - m_f, n_b - m_b) such +that, for any sequence of n_f push_front, m_f pop_front, n_b +push_back, and m_b pop_back operations, interleaved in any order, +starting with the current deque of size n, the deque does not +invalidate any of its iterators except to the erased elements. +

    +

    +2 Remarks: Unlike a vector's capacity, the capacity of a deque can +decrease after a sequence of insertions at both ends, even if none of +the operations caused the deque to invalidate any of its iterators +except to the erased elements. +

    +
    +
    + +
    +
    bool reserve(size_type n);
+
    +
    +

    +2 Effects: A directive that informs a deque of a planned sequence of +push_front, pop_front, push_back, and pop_back operations, so that it +can manage iterator invalidation accordingly. After reserve(), +capacity() is greater or equal to the argument of reserve if this +operation returns true; and equal to the previous value of capacity() +otherwise. If an exception is thrown, there are no effects. +

    +

    +3 Returns: true if iterators are invalidated as a result of this +operation, and false otherwise. +

    +

    +4 Complexity: It does not change the size of the sequence and takes +at most linear time in n.

    -

    -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. +5 Throws: length_error if n > max_size().

    -

    -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.) +6 Remarks: It is guaranteed that no invalidation takes place during a +sequence of insert or erase operations at either end that happens +after a call to reserve() except to the erased elements, until the +time when an insertion would make max(n_f-m_f, n_b-m_b) larger than +capacity(), where n_f is the number of push_front, m_f of pop_front, +n_b of push_back, and m_b of pop_back operations since the call to +reserve().

    -

    -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. +7 An implementation is free to pre-allocate buffers so as to +offer the additional guarantee that no exception will be thrown +during such a sequence other than by the element constructors.

    +
    +

    -And why does 29.4.4 [atomics.types.operations] p9 for "load" say: +And 23.2.2.3 [deque.modifiers] para 1, can be enhanced:

    -
    -Requires: The order argument shall not be memory_order_acquire -nor memory_order_acq_rel. +1 Effects: An insertion in the middle of the deque invalidates all the iterators and references to elements of the +deque. An insertion at either end of the deque invalidates all the iterators to the deque, +unless provisions have been made with reserve, +but has no effect on the validity of references to elements of the deque.
    -

    -(Since this is exactly the same restriction as for "store", it seems to be a typo.) -

    -

    -And then: 29.4.4 [atomics.types.operations] p12: -

    -
    -These operations are read-modify-write operations in the sense of the -"synchronizes with" definition (1.10 [intro.multithread]), so both such an operation and the -evaluation that produced the input value synchronize with any evaluation -that reads the updated value. -
    + +
    +

    856. Removal of aligned_union

    +

    Section: 20.5.7 [meta.trans.other] Status: New + Submitter: Jens Maurer Date: 2008-06-12

    +

    View other active issues in [meta.trans.other].

    +

    View all other issues in [meta.trans.other].

    +

    View all issues with New status.

    +

    Discussion:

    -This is redundant with 1.10 [intro.multithread], see above for the reasoning. +With the arrival of extended unions +(N2544), +there is no +known use of aligned_union that couldn't be handled by +the "extended unions" core-language facility.

    Proposed resolution:

    -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): +Remove the following signature from 20.5.2 [meta.type.synop]:

    +
    template <std::size_t Len, class... Types> struct aligned_union;
+
    -

    -For memory_order_relaxed, no operation orders memory. +Remove the second row from table 51 in 20.5.7 [meta.trans.other], +starting with:

    +
    template <std::size_t Len,
+class... Types>
+struct aligned_union;
+
    + + + + + +
    +

    857. condition_variable::time_wait return bool error prone

    +

    Section: 30.4.1 [thread.condition.condvar] Status: New + Submitter: Beman Dawes Date: 2008-06-13

    +

    View all issues with New status.

    +

    Discussion:

    -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. +The meaning of the bool returned by condition_variable::timed_wait is so +obscure that even the class' designer can't deduce it correctly. Several +people have independently stumbled on this issue.

    -

    -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. +It might be simpler to change the return type to a scoped enum:

    -
    +
    enum class timeout { not_reached, reached };
+

    -Rephrase 29.1 [atomics.order] p2: +That's the same cost as returning a bool, but not subject to mistakes. Your example below would be:

    -
    -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] -
    +
    if (cv.wait_until(lk, time_limit) == timeout::reached )
+  throw time_out();
+
    + +

    [ +Beman to supply exact wording. +]

    + + + +

    Proposed resolution:

    + + + + +
    +

    858. Wording for Minimal Support for Garbage Collection

    +

    Section: X [garbage.collection] Status: New + Submitter: Pete Becker Date: 2008-06-21

    +

    View all issues with New status.

    +

    Discussion:

    -Rephrase 29.4.4 [atomics.types.operations] p12 as: +The first sentence of the Effects clause for undeclare_reachable seems +to be missing some words. I can't parse

    -
    -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. +... for all non-null p referencing the argument is no longer declared reachable...
    +

    +I take it the intent is that undeclare_reachable should be called only +when there has been a corresponding call to declare_reachable. In +particular, although the wording seems to allow it, I assume that code +shouldn't call declare_reachable once then call undeclare_reachable +twice. +

    +

    +I don't know what "shall be live" in the Requires clause means. +

    +

    +In the final Note for undeclare_reachable, what does "cannot be +deallocated" mean? Is this different from "will not be able to collect"? +

    -Same in p15, p20, p22. +For the wording on nesting of declare_reachable and +undeclare_reachable, the words for locking and unlocking recursive +mutexes probably are a good model.

    +

    Proposed resolution:

    +

    +

    +
    -

    819. rethrow_if_nested

    -

    Section: 18.7.6 [except.nested] Status: New - Submitter: Alisdair Meredith Date: 2008-03-25

    +

    859. Monotonic Clock is Conditionally Supported?

    +

    Section: X [datetime] Status: New + Submitter: Pete Becker Date: 2008-06-23

    View all issues with New status.

    Discussion:

    -Looking at the wording I submitted for rethrow_if_nested, I don't think I -got it quite right. +N2661 +says that there is a class named monotonic_clock. It also says that this +name may be a synonym for system_clock, and that it's conditionally +supported. So the actual requirement is that it can be monotonic or not, +and you can tell by looking at is_monotonic, or it might not exist at +all (since it's conditionally supported). Okay, maybe too much +flexibility, but so be it. +

    +

    +A problem comes up in the threading specification, where several +variants of wait_for explicitly use monotonic_clock::now(). What is the +meaning of an effects clause that says

    +
    wait_until(lock, chrono::monotonic_clock::now() + rel_time)
+
    +

    -The current wording says: +when monotonic_clock is not required to exist?

    -
    -
    template <class E> void rethrow_if_nested(const E& e);
-
    -
    + +

    Proposed resolution:

    -Effects: Calls e.rethrow_nested() only if e -is publicly derived from nested_exception.

    -
    -
    + + + + +
    +

    860. Floating-Point State

    +

    Section: 26 [numerics] Status: New + Submitter: Lawrence Crowl Date: 2008-06-23

    +

    View all issues with New status.

    +

    Discussion:

    -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. +There are a number of functions that affect the floating point state. +These function need to be thread-safe, but I'm unsure of the right +approach in the standard, as we inherit them from C.

    Proposed resolution:

    +

    +

    -

    820. current_exception()'s interaction with throwing copy ctors

    -

    Section: 18.7.5 [propagation] Status: New - Submitter: Stephan T. Lavavej Date: 2008-03-26

    -

    View other active issues in [propagation].

    -

    View all other issues in [propagation].

    +

    861. Incomplete specification of EqualityComparable for std::forward_list

    +

    Section: 23.1 [container.requirements] Status: New + Submitter: Daniel Krügler Date: 2008-06-24

    +

    View other active issues in [container.requirements].

    +

    View all other issues in [container.requirements].

    View all issues with New status.

    Discussion:

    -As of N2521, the Working Paper appears to be silent about what -current_exception() should do if it tries to copy the currently handled -exception and its copy constructor throws. 18.7.5 [propagation]/7 says "If the -function needs to allocate memory and the attempt fails, it returns an -exception_ptr object that refers to an instance of bad_alloc.", but -doesn't say anything about what should happen if memory allocation -succeeds but the actual copying fails. +Table 89, Container requirements, defines operator== in terms of the container +member function size() and the algorithm std::equal:

    +
    +== is an equivalence relation. a.size() == b.size() && +equal(a.begin(), a.end(), b.begin() +
    +

    -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(). +The new container forward_list does not provide a size member function +by design but does provide operator== and operator!= without specifying it's semantic. +

    +

    +Other parts of the (sequence) container requirements do also depend on +size(), e.g. empty() +or clear(), but this issue explicitly attempts to solve the missing +EqualityComparable specification, +because of the special design choices of forward_list. +

    +

    +I propose to apply one of the following resolutions, which are described as:

    +
      +
    1. +Provide a definition, which is optimal for this special container without +previous size test. This choice prevents two O(N) calls of std::distance() +with the corresponding container ranges and instead uses a special +equals implementation which takes two container ranges instead of 1 1/2. +
      2. +
    2. +The simple fix where the usual test is adapted such that size() is replaced +by distance with corresponding performance disadvantages. +
      3. +

    -I believe that terminate() is the most reasonable course of action, but -before we go implement that, I wanted to raise this issue. +Both proposal choices are discussed, the preferred choice of the author is +to apply (A).

    -

    [ -Peter's summary: -]

    +

    Proposed resolution:

    +

    +Common part: +

    +
      +
    • +

      +Just betwen 23.2.3.5 [forwardlist.ops] and 23.2.3.6 [forwardlist.spec] +add a new +section "forwardlist comparison operators" [forwardlist.compare] (and +also add the +new section number to 23.2.3 [forwardlist]/2 in front of "Comparison operators"): +

      +
      +forwardlist comparison operators [forwardlist.compare] +
      +
      • +
    +

    +Option (A): +

    +
      +

    • -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. +Add to the new section [forwardlist.compare] the following paragraphs:

      +
      +
      template <class T, class Allocator>
+bool operator==(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y);
+
      +

      -However, the resolution of core issue 475 may relax this requirement: +Requires: Type T is EqualityComparable ([equalitycomparable]). +

      +

      +Returns: true if +

      +
        +
      • +

        +for every iterator i in the range [x.begin(), E), where E == +x.begin() + M and M == + min(distance(x.begin(), x.end()), distance(y.begin(), y.end())), +the following condition holds: +

        +
        *i == *(y.begin() + (i - x.begin())).
+
        +
        • +
      • +if i == E then i == x.end() && (y.begin() + (i - x.begin())) == y.end(). +
        • +
      • +Otherwise, returns false. +
        • +
      +

      +Throws: Nothing unless an exception is thrown by the equality comparison. +

      +

      +Complexity: At most M comparisons.

      +
      +
      template <class T, class Allocator>
+bool operator!=(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y);
+
      +
      +Returns: !(x == y). +
      +
      +
      • +
    +
    +

    +Option (B): +

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

      +Add to the new section [forwardlist.compare] the following paragraphs: +

      +
      +
      template <class T, class Allocator>
+bool operator==(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y);
+
      +
      +

      +Requires: Type T is EqualityComparable ([equalitycomparable]). +

      +

      +Returns: distance(x.begin(), x.end()) == distance(y.begin(), y.end()) +&& equal(x.begin(), x.end(), y.begin()). +

      +
      +
      template <class T, class Allocator>
+bool operator!=(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y);
+
      +
      +Returns: !(x == y). +
      +
      +
      • +
    + + + + +
    +

    862. Impossible complexity for 'includes'

    +

    Section: 25.3.5.1 [includes] Status: New + Submitter: Alisdair Meredith Date: 2008-07-02

    +

    View all issues with New status.

    +

    Discussion:

    -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. +In 25.3.5.1 [includes] the complexity is "at most -1 comparisons" if passed +two empty ranges. I don't know how to perform a negative number of +comparisions!

    -Option (2) cannot be adopted by itself, because a potential infinite -recursion will need to be terminated by one of the other options. +This same issue also applies to:

    -
    +
      +
    • set_union
      • +
    • set_intersection
      • +
    • set_difference
      • +
    • set_symmetric_difference
      • +
    • merge
      • +

    Proposed resolution:

    -Add the following paragraph after 18.7.5 [propagation]/7:

    -
    + + + + +
    +

    863. What is the state of a stream after close() succeeds

    +

    Section: 27.8.1 [fstreams] Status: New + Submitter: Steve Clamage Date: 2008-07-08

    +

    View all other issues in [fstreams].

    +

    View all issues with New status.

    +

    Discussion:

    -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. +Suppose writing to an [o]fstream fails and you later close the stream. +The overflow() function is called to flush the buffer (if it exists). +Then the file is unconditionally closed, as if by calling flcose.

    -[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.] +If either overflow or fclose fails, close() reports failure, and clearly +the stream should be in a failed or bad state. +

    +

    +Suppose the buffer is empty or non-existent (so that overflow() does not +fail), and fclose succeeds. The close() function reports success, but +what is the state of the stream?

    -
    +

    Proposed resolution:

    +

    +

    +
    -

    821. Minor cleanup : unique_ptr

    -

    Section: 20.6.11.3.3 [unique.ptr.runtime.modifiers] Status: New - Submitter: Alisdair Meredith Date: 2008-03-30

    +

    864. Defect in atomic wording

    +

    Section: 29.4 [atomics.types.operations] Status: New + Submitter: Anthony Williams Date: 2008-07-10

    +

    View all other issues in [atomics.types.operations].

    View all issues with New status.

    Discussion:

    -Reading resolution of LWG issue 673 I noticed the following: +There's an error in 29.4 [atomics.types.operations]/p9:

    -
    void reset(T* pointer p = 0 pointer());
+
    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;
 
    
-
+
    
 
    
--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]
+Requires: The order argument shall not be memory_order_acquire nor
+memory_order_acq_rel.
 
    
 
    
+

    -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... +I believe that this should state

    +
    +shall not be memory_order_release. +
    - -

    Proposed resolution:

    -Add to class template definition in 20.6.11.3 [unique.ptr.runtime] +There's also an error in 29.4 [atomics.types.operations]/p17:

    -
    // modifiers 
-T* release(); 
-void reset(T* p = 0); 
-void reset( nullptr_t );
-template< typename T > void reset( T ) = delete;
-void swap(unique_ptr&& u);
-
    +... When only one memory_order argument is supplied, the value of success +is order, and +the value of failure is order except that a value of +memory_order_acq_rel shall be replaced by the value +memory_order_require ... +
    +

    +I believe this should state +

    +
    +shall be replaced by the value memory_order_acquire ...
    + +

    Proposed resolution:

    -Update 20.6.11.3.3 [unique.ptr.runtime.modifiers] +Change 29.4 [atomics.types.operations]/p9:

    -
    void reset(pointer p = pointer());
-void reset(nullptr_t);
+
    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;
 
    
-
+
    
 
    
--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]
+Requires: The order argument shall not be memory_order_acquire
+memory_order_release nor memory_order_acq_rel.
 
    
+
    
+
    +

    -Effects: If get() == nullptr there are no effects. Otherwise get_deleter()(get()). +Change 29.4 [atomics.types.operations]/p17:

    -

    ...

    - -

    [ -Note this wording incorporates resolutions for 806 (New) and 673 (Ready). -]

    +
    +... When only one memory_order argument is supplied, the value of success +is order, and +the value of failure is order except that a value of +memory_order_acq_rel shall be replaced by the value +memory_order_require memory_order_acquire ... +
    @@ -17921,1295 +18079,1639 @@ Note this wording incorporates resolutions for 822. Object with explicit copy constructor no longer CopyConstructible -

    Section: 20.1.1 [utility.arg.requirements] Status: New - Submitter: James Kanze Date: 2008-04-01

    -

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

    -

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

    +

    865. More algorithms that throw away information

    +

    Section: 25.2.6 [alg.fill], 25.2.7 [alg.generate] Status: New + Submitter: Daniel Krügler Date: 2008-07-13

    View all issues with New status.

    Discussion:

    -I just noticed that the following program is legal in C++03, but -is forbidden in the current draft: +In regard to library defect 488 I found some more algorithms which +unnecessarily throw away information. These are typically algorithms, +which sequentially write into an OutputIterator, but do not return the +final value of this output iterator. These cases are:

    -
    #include <vector>
-#include <iostream>
-
-class Toto
-{
-public:
-    Toto() {}
-    explicit Toto( Toto const& ) {}
-} ;
-
-int
-main()
-{
-    std::vector< Toto > v( 10 ) ;
-    return 0 ;
-}
-
    +
      +
    1. +
      template<class OutputIterator, class Size, class T>
+void fill_n(OutputIterator first, Size n, const T& value);
      2. +
    2. +
      template<class OutputIterator, class Size, class Generator>
+void generate_n(OutputIterator first, Size n, Generator gen);
      3. +

    -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.) +In both cases the minimum requirements on the iterator are +OutputIterator, which means according to the requirements of +24.1.2 [output.iterators]/2 that only single-pass iterations are guaranteed. +So, if users of fill_n and generate_n have *only* an OutputIterator +available, they have no chance to continue pushing further values +into it, which seems to be a severe limitation to me.

    -

    Proposed resolution:

    +
      +

    1. -In 20.1.1 [utility.arg.requirements] change Table 33: MoveConstructible requirements [moveconstructible]: +Replace the current declaration of fill_n in 25 [algorithms]/2, header +<algorithm> synopsis and in 25.2.6 [alg.fill] by

      +
      template<class OutputIterator, class Size, class T>
+void OutputIterator fill_n(OutputIterator first, Size n, const T& value);
+
      +

      +Just after the effects clause p.2 add a new returns clause saying: +

      - - - - - - - - - - -
      expressionpost-condition
      T t(rv) = rvt is equivalent to the value of rv before the construction
      ...
      +Returns: first + n for fill_n.
      - +
      2. +

    2. -In 20.1.1 [utility.arg.requirements] change Table 34: CopyConstructible requirements [copyconstructible]: +Replace the current declaration of generate_n in 25 [algorithms]/2, header +<algorithm> synopsis and in 25.2.7 [alg.generate] by +

      +
      template<class OutputIterator, class Size, class Generator>
+void OutputIterator generate_n(OutputIterator first, Size n, Generator gen);
+
      +

      +Just after the effects clause p.1 add a new returns clause saying:

      -
      - - - - - - - - - - -
      expressionpost-condition
      T t(u) = uthe value of u is unchanged and is equivalent to t
      ...
      +Returns: first + n for generate_n.
      +
      3. +
    -

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

    +

    866. Qualification of placement new-expressions

    +

    Section: 20.7.10 [specialized.algorithms], 20.7.12.2.6 [util.smartptr.shared.create] Status: New + Submitter: Alberto Ganesh Barbati Date: 2008-07-14

    View all issues with New status.

    Discussion:

    -N2588 seems to have added an operator() member function to the -identity<> helper in 20.2.2 [forward]. I believe this change makes it no -longer possible to instantiate identity<void>, as it would require -forming a reference-to-void type as this operator()'s parameter type. -

    - -

    -Suggested resolution: Specialize identity<void> so as not to require -the member function's presence. +LWG issue 402 replaced "new" with "::new" in the placement +new-expression in 20.7.5.1 [allocator.members]. I believe the rationale +given in 402 applies also to the following other contexts:

    - - -

    Proposed resolution:

    +
      +

    • +in 20.7.10 [specialized.algorithms], all four algorithms unitialized_copy, +unitialized_copy_n, unitialized_fill and unitialized_fill_n use +the unqualified placement new-expression in some variation of the form:

      - - - - - -
      -

      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:

      +
      new  (static_cast<void*>(&*result)) typename  iterator_traits<ForwardIterator>::value_type(*first);
+
      +
      • +

    • -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. +in 20.7.12.2.6 [util.smartptr.shared.create] there is a reference to the unqualified placement new-expression:

      - -
      template<class charT, class traits, class Allocator>
- basic_ostream<charT, traits>&
-   operator<<(basic_ostream<charT, traits>&& os,
-              const basic_string<charT,traits,Allocator>& str);
+
      new  (pv)  T(std::forward<Args>(args)...),
 
      
-
+
      • +

    -The definition in 21.3.8.9 [string.io] lists two: +I suggest to add qualification in all those places. As far as I know, +these are all the remaining places in the whole library that explicitly +use a placement new-expression. Should other uses come out, they should +be qualified as well.

    - -
    template<class charT, class traits, class Allocator>
- basic_ostream<charT, traits>&
-   operator<<(basic_ostream<charT, traits>& os,
-              const basic_string<charT,traits,Allocator>& str);
-
-template<class charT, class traits, class Allocator>
- basic_ostream<charT, traits>&
-   operator<<(basic_ostream<charT, traits>&& os,
-              const basic_string<charT,traits,Allocator>& str);
-
    -

    -I believe the synopsis in 21.2 [string.classes] is correct, and the first of the two -signatures in 21.3.8.9 [string.io] should be deleted. +As an aside, a qualified placement new-expression does not need +additional requirements to be compiled in a constrained context. By +adding qualification, the HasPlacementNew concept introduced recently in +N2677 (Foundational Concepts) +would no longer be needed by library and +should therefore be removed.

    Proposed resolution:

    +Replace "new" with "::new" in:

    +
      +
    • +20.7.10.1 [uninitialized.copy], paragraphs 1 and 3 +
      • +
    • +20.7.10.2 [uninitialized.fill] paragraph 1 +
      • +
    • +20.7.10.3 [uninitialized.fill.n] paragraph 1 +
      • +
    • +20.7.12.2.6 [util.smartptr.shared.create] once in paragraph 1 and twice in paragraph 2. +
      • +
    +
    -

    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

    +

    867. Valarray and value-initialization

    +

    Section: 26.5.2.1 [valarray.cons] Status: New + Submitter: Alberto Ganesh Barbati Date: 2008-07-20

    +

    View other active issues in [valarray.cons].

    +

    View all other issues in [valarray.cons].

    View all issues with New status.

    Discussion:

    -Should the following use rvalues references to stream in insert/extract -operators? +From 26.5.2.1 [valarray.cons], paragraph 2:

    -
      -
    • 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]
      • -
    - +
    explicit  valarray(size_t);
+
    +
    +The array created by this constructor has a length equal to the value of the argument. The elements +of the array are constructed using the default constructor for the instantiating type T. +
    +
    -

    Proposed resolution:

    +The problem is that the most obvious Ts for valarray are float +and double, they don't have a default constructor. I guess the intent is to value-initialize +the elements, so I suggest replacing:

    - - - - -
    -

    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 elements of the array are constructed using the default constructor for the instantiating type T. +

    -In the spirit of printf vs iostream... +with

    +
    +The elements of the array are value-initialized. +

    -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? +There is another reference to the default constructor of T in the non-normative note in paragraph 9. +That reference should also be replaced. (The normative wording in paragraph 8 refers to T() +and so it doesn't need changes).

    -

    [ -Pablo Halpern: -]

    +

    Proposed resolution:

    +

    +Change 26.5.2.1 [valarray.cons], paragraph 2: +

    -I'm not sure it constitutes a defect, but I would be in favor of adding -another flag (and corresponding manipulator). +
    explicit  valarray(size_t);
+
    +
    +The array created by this constructor has a length equal to the value of the argument. The elements +of the array are constructed using the default constructor for the instantiating type T +value-initialized (8.5 [dcl.init]). +
    -

    [ -Martin Sebor: -]

    - +

    +Change 26.5.2.7 [valarray.members], paragraph 9: +

    -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). +[Example: If the argument has the value -2, the first two elements of the result will be constructed using the +default constructor +value-initialized (8.5 [dcl.init]); +the third element of the result will be assigned the value of the first element of the argument; etc. -- end example]
    -

    Proposed resolution:

    -

    -

    -
    -

    827. constexpr shared_ptr::shared_ptr()?

    -

    Section: 20.6.12.2.1 [util.smartptr.shared.const] Status: New - Submitter: Peter Dimov Date: 2008-04-11

    -

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

    +

    868. default construction and value-initialization

    +

    Section: 23 [containers] Status: New + Submitter: Alberto Ganesh Barbati Date: 2008-07-22

    +

    View other active issues in [containers].

    +

    View all other issues in [containers].

    View all issues with New status.

    Discussion:

    -Would anyone object to making the default constructor of shared_ptr (and -weak_ptr and enable_shared_from_this) constexpr? This would enable -static initialization for shared_ptr variables, eliminating another -unfair advantage of raw pointers. +The term "default constructed" is often used in wording that predates +the introduction of the concept of value-initialization. In a few such +places the concept of value-initialization is more correct than the +current wording (for example when the type involved can be a built-in) +so a replacement is in order. Two of such places are already covered by +issue 867. This issue deliberately addresses the hopefully +non-controversial changes in the attempt of being approved more quickly. +A few other occurrences (for example in std::tuple, +std::reverse_iterator and std::move_iterator) are left to separate +issues. For std::reverse_iterator, see also issue 408. This issue is +related with issue 724.

    Proposed resolution:

    +Change 20.1.1 [utility.arg.requirements], paragraph 2: +

    + +
    +In general, a default constructor is not required. Certain container class member function signatures specify +the default constructor +T() +as a default argument. T() shall be a well-defined expression (8.5 [dcl.init]) if one of +those signatures is called using the default argument (8.3.6 [dcl.fct.default]). +
    + +

    +In all the following paragraphs in clause 23 [containers], replace "default constructed" with "value-initialized +(8.5 [dcl.init])":

    +
      +
    • 23.2.2.1 [deque.cons] para 2
      • +
    • 23.2.2.2 [deque.capacity] para 1
      • +
    • 23.2.3.1 [forwardlist.cons] para 3
      • +
    • 23.2.3.4 [forwardlist.modifiers] para 21
      • +
    • 23.2.4.1 [list.cons] para 3
      • +
    • 23.2.4.2 [list.capacity] para 1
      • +
    • 23.2.6.1 [vector.cons] para 3
      • +
    • 23.2.6.2 [vector.capacity] para 10
      • +
    +
    -

    828. Static initialization for std::mutex?

    -

    Section: 30.3.1.1 [thread.mutex.class] Status: New - Submitter: Peter Dimov Date: 2008-04-18

    +

    869. Bucket (local) iterators and iterating past end

    +

    Section: 23.1.5 [unord.req] Status: New + Submitter: Sohail Somani Date: 2008-07-22

    +

    View other active issues in [unord.req].

    +

    View all other issues in [unord.req].

    View all issues with New status.

    Discussion:

    -[Note: I'm assuming here that 3.6.2 [basic.start.init]/1 will be fixed.] +Is there any language in the current draft specifying the behaviour of the following snippet?

    + +
    unordered_set<int> s;
+unordered_set<int>::local_iterator it = s.end(0);
+
+// Iterate past end - the unspecified part
+it++;
+
    +

    -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. +I don't think there is anything about s.end(n) being considered an +iterator for the past-the-end value though (I think) it should be.

    Proposed resolution:

    +Change Table 97 "Unordered associative container requirements" in 23.1.5 [unord.req]:

    +
    + + + + + + + + + + + + + + + + + +
    Table 97: Unordered associative container requirements
    expressionreturn typeassertion/note pre/post-conditioncomplexity
    b.begin(n)local_iterator
    const_local_iterator for const b.    		Pre: n shall be in the range [0,b.bucket_count()). Note: [b.begin(n), b.end(n)) is a +valid range containing all of the elements in the nth bucket. +b.begin(n) returns an iterator referring to the first element in the bucket. +If the bucket is empty, then b.begin(n) == b.end(n).Constant
    b.end(n)local_iterator
    const_local_iterator for const b.    		Pre: n shall be in the range [0, b.bucket_count()). +b.end(n) returns an iterator which is the past-the-end value for the bucket.Constant
    +
    + +
    -

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

    +

    870. Do unordered containers not support function pointers for predicate/hasher?

    +

    Section: 23.1.5 [unord.req] Status: New + Submitter: Daniel Krügler Date: 2008-08-17

    +

    View other active issues in [unord.req].

    +

    View all other issues in [unord.req].

    View all issues with New status.

    Discussion:

    -

    Consider this code:

    +

    +Good ol' associative containers allow both function pointers and +function objects as feasible +comparators, as described in 23.1.4 [associative.reqmts]/2: +

    -
    exception_ptr xp;
    -
    try {do_something(); }
-
-catch (const runtime_error& ) {xp = current_exception();}
-
-...
-
-rethrow_exception(xp);
    +Each associative container is parameterized on Key and an ordering +relation Compare that +induces a strict weak ordering (25.3) on elements of Key. [..]. The +object of type Compare is +called the comparison object of a container. This comparison object +may be a pointer to +function or an object of a type with an appropriate function call operator.[..]

    -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. +The corresponding wording for unordered containers is not so clear, +but I read it to disallow +function pointers for the hasher and I miss a clear statement for the +equality predicate, see +23.1.5 [unord.req]/3+4+5:

    +

    -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. +Each unordered associative container is parameterized by Key, by a +function object Hash that +acts as a hash function for values of type Key, and by a binary +predicate Pred that induces an +equivalence relation on values of type Key.[..]

    - -

    [ -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 hash function is a function object that takes a single argument of +type Key and returns a +value of type std::size_t.

    -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. +Two values k1 and k2 of type Key are considered equal if the +container's equality function object +returns true when passed those values.[..]

    - - -

    Proposed resolution:

    -

    -After 18.7.5 [propagation] , paragraph 7, add the indicated text: +and table 97 says in the column "assertion...post-condition" for the +expression X::hasher:

    -
    exception_ptr current_exception();
    +Hash shall be a unary function object type such that the expression +hf(k) has type std::size_t. +
    -

    -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] +Note that 20.6 [function.objects]/1 defines as "Function objects are +objects with an operator() defined.[..]"

    -

    -Remarks: The type of the exception object -referred to by the returned exception_ptr is the most-derived -type of the currently handled exception. +Does this restriction exist by design or is it an oversight? If an +oversight, I suggest that to apply +the following

    + +

    Proposed resolution:

    -Throws: nothing. +In 23.1.5 [unord.req]/3, just after the second sentence which is written as

    +
    +Additionally, unordered_map and unordered_multimap associate an +arbitrary mapped type T with the Key.
    + +

    +add one further sentence: +

    + +
    +Both Hash and Pred may be pointers to function or objects of a type +with an appropriate function call operator.
    +

    +[Note1: Since the detailed requirements for Pred and Hash are given in +p.4 and p.5, it an alternative resolution +would be to insert a new paragraph just after p.5, which contains the +above proposed sentence] +

    +

    +[Note2: I do not propose a change of above quoted element in table 97, +because the mis-usage of the +notion of "function object" seems already present in the standard at +several places, even if it includes +function pointers, see e.g. 25 [algorithms]/7. The important point is +that in those places a statement is +given that the actually used symbol, like "Predicate" applies for +function pointers as well] +

    -

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

    +

    871. Iota's requirements on T are too strong

    +

    Section: 26.6.5 [numeric.iota] Status: New + Submitter: Daniel Krügler Date: 2008-08-20

    View all issues with New status.

    Discussion:

    - 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. +According to the recent WP +N2691, +26.6.5 [numeric.iota]/1, the requires clause +of std::iota says:

    -

    [ -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. +T shall meet the requirements of CopyConstructible and Assignable types, and +shall be convertible to ForwardIterator's value type.[..]
    +

    +Neither CopyConstructible nor Assignable is needed, instead MoveConstructible +seems to be the correct choice. I guess the current wording resulted as an +artifact from comparing it with similar numerical algorithms like accumulate. +

    -

    Proposed resolution:

    - Replace paragraph 4 of 21.1 [char.traits] by: +Note: If this function will be conceptualized, the here proposed +MoveConstructible +requirement can be removed, because this is an implied requirement of +function arguments, see +N2710/[temp.req.impl]/3, last bullet.

    -
    + + + +

    Proposed resolution:

    +

    - 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. +Change the first sentence of 26.6.5 [numeric.iota]/1:

    + +
    +Requires: T shall meet the requirements of +CopyConstructible and Assignable types, + +be MoveConstructible (Table 34) + +and shall be +convertible to ForwardIterator's value type. [..]
    +
    -

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

    +

    872. move_iterator::operator[] has wrong return type

    +

    Section: 24.4.3.3.12 [move.iter.op.index] Status: New + Submitter: Doug Gregor Date: 2008-08-21

    View all issues with New status.

    Discussion:

    - 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. +move_iterator's operator[] is declared as:

    + +
    reference operator[](difference_type n) const;
+
    +

    - 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. +This has the same problem that reverse_iterator's operator[] used to +have: if the underlying iterator's operator[] returns a proxy, the +implicit conversion to value_type&& could end up referencing a temporary +that has already been destroyed. This is essentially the same issue that +we dealt with for reverse_iterator in DR 386.

    Proposed resolution:

    - In 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. +In 24.4.3.1 [move.iterator] and 24.4.3.3.12 [move.iter.op.index], change the declaration of +move_iterator's operator[] to:

    +
    reference unspecified operator[](difference_type n) const;
+
    + +
    -

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

    +

    873. signed integral type and unsigned integral type are not clearly defined

    +

    Section: 3.9.1 [basic.fundamental] Status: New + Submitter: Travis Vitek Date: 2008-06-30

    View all issues with New status.

    Discussion:

    -

    -Initialization of objects of class error_code -(19.4.2 [syserr.errcode]) and class -error_condition (19.4.3 [syserr.errcondition]) can be made simpler and more reliable by use of -the new constexpr feature -[N2349] -of C++0x. Less code will need to be -generated for both library implementations and user programs when -manipulating constant objects of these types. -

    +

    + Neither the term "signed integral type" nor the term "unsigned + integral type" is defined in the core language section of the + standard, therefore the library section should avoid its use. The + terms signed integer type and unsigned integer type are + indeed defined (in 3.9.1 [basic.fundamental]), thus the usages should be + replaced accordingly. +

    -

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

    +

    + Note that the key issue here is that "signed" + "integral type" != + "signed integral type". + + The types bool, char, char16_t, + char32_t and wchar_t are all listed as + integral types, but are neither of signed integer type or + unsigned integer type. According to 3.9 [basic.types] p7, a synonym for + integral type is integer type. + + Given this, one may choose to assume that an integral type that + can represent values less than zero is a signed integral type. + Unfortunately this can cause ambiguities. + + As an example, if T is unsigned char, the + expression make_signed<T>::type, is supposed to + name a signed integral type. There are potentially two types that + satisfy this requirement, namely signed char and + char (assuming CHAR_MIN < 0). +

    + + +

    Proposed resolution:

    +

    + I propose to use the terms "signed integer type" and "unsigned integer + type" in place of "signed integral type" and "unsigned integral type" + to eliminate such ambiguities. +

    + +

    + The proposed change makes it absolutely clear that the difference + between two pointers cannot be char or wchar_t, + but could be any of the signed integer types. + 5.7 [expr.add] paragraph 6... +

    +
    +

    +

      +
    1. + When two pointers to elements of the same array object are + subtracted, the result is the difference of the subscripts of + the two array elements. The type of the result is an + implementation-defined signed integral + typesigned integer type; this type shall be the + same type that is defined as std::ptrdiff_t in the + <cstdint> header (18.1)... +
      2. +
    + +
    + +

    + The proposed change makes it clear that X::size_type and + X::difference_type cannot be char or + wchar_t, but could be one of the signed or unsigned integer + types as appropriate. + 20.1.2 [allocator.requirements] table 40... +

    +
    + Table 40: Allocator requirements + + + + + + + + + + + + + + + + + + + + +
    expressionreturn typeassertion/note/pre/post-condition
    X::size_type + unsigned integral type + unsigned integer type + a type that can represent the size of the largest object in + the allocation model.
    X::difference_type + signed integral type + signed integer type + a type that can represent the difference between any two + pointers in the allocation model.
    +
    + +

    + The proposed change makes it clear that make_signed<T>::type + must be one of the signed integer types as defined in 3.9.1. Ditto for + make_unsigned<T>type and unsigned integer types. + 20.5.6.3 [meta.trans.sign] table 48... +

    +
    + Table 48: Sign modifications + + + + + + + + + + + + + + + + + +
    TemplateComments
    + template <class T> struct make_signed; + + If T names a (possibly cv-qualified) signed + integral typesigned integer type (3.9.1) then + the member typedef type shall name the type + T; otherwise, if T names a (possibly + cv-qualified) unsigned integral typeunsigned + integer type then type shall name the + corresponding signed integral typesigned + integer type, with the same cv-qualifiers as + T; otherwise, type shall name the + signed integral typesigned integer type + with the smallest rank (4.13) for which sizeof(T) == + sizeof(type), with the same cv-qualifiers as + T. + + Requires: T shall be a (possibly + cv-qualified) integral type or enumeration but not a + bool type. +
    + template <class T> struct make_unsigned; + + If T names a (possibly cv-qualified) + unsigned integral typeunsigned integer + type (3.9.1) then the member typedef type + shall name the type T; otherwise, if + T names a (possibly cv-qualified) signed + integral typesigned integer type then + type shall name the corresponding unsigned + integral typeunsigned integer type, with the + same cv-qualifiers as T; otherwise, + type shall name the unsigned integral + typeunsigned integer type with the smallest + rank (4.13) for which sizeof(T) == sizeof(type), + with the same cv-qualifiers as T. + + Requires: T shall be a (possibly + cv-qualified) integral type or enumeration but not a + bool type. +
    +
    + + +

    + Note: I believe that the basefield values should probably be + prefixed with ios_base:: as they are in 22.2.2.2.2 [facet.num.put.virtuals] + + The listed virtuals are all overloaded on signed and unsigned integer + types, the new wording just maintains consistency. + + 22.2.2.1.2 [facet.num.get.virtuals] table 78... +

    +
    + Table 78: Integer Conversions + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Statestdio equivalent
    basefield == oct%o
    basefield == hex%X
    basefield == 0%i
    signed integral typesigned integer + type%d
    unsigned integral typeunsigned integer + type%u
    +
    + + +

    + Rationale is same as above. + 22.2.2.2.2 [facet.num.put.virtuals] table 80... +

    +
    + Table 80: Integer Conversions + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Statestdio equivalent
    basefield == ios_base::oct%o
    (basefield == ios_base::hex) && + !uppercase%x
    (basefield == ios_base::hex)%X
    basefield == 0%i
    for a signed integral typesigned integer + type%d
    for a unsigned integral typeunsigned integer + type%u
    +
    + + +

    + 23.1 [container.requirements] table 80... +

    +
    + Table 89: Container requirements + + + + + + + + + + + + + + + + + + + + + + + + + + +
    expressionreturn typeoperational semanticsassertion/note/pre/post-conditioncomplexity
    X::difference_typesigned integral typesigned integer type is identical to the difference type of X::iterator + and X::const_iteratorcompile time
    X::size_typeunsigned integral typeunsigned integer type size_type can represent any non-negative value of + difference_typecompile time
    +
    + +

    + 24.1 [iterator.requirements] paragraph 1... +

    +
    + Iterators are a generalization of pointers that allow a C++ program to + work with different data structures (containers) in a uniform manner. + To be able to construct template algorithms that work correctly and + efficiently on different types of data structures, the library + formalizes not just the interfaces but also the semantics and + complexity assumptions of iterators. All input iterators + i support the expression *i, resulting in a + value of some class, enumeration, or built-in type T, + called the value type of the iterator. All output iterators + support the expression *i = o where o is a + value of some type that is in the set of types that are + writable to the particular iterator type of i. All + iterators i for which the expression (*i).m + is well-defined, support the expression i->m with the + same semantics as (*i).m. For every iterator type + X for which equality is defined, there is a corresponding + signed integral type signed integer type called + the difference type of the iterator. +
    + +

    + I'm a little unsure of this change. Previously this paragraph would + allow instantiations of linear_congruential_engine on + char, wchar_t, bool, and other types. The + new wording prohibits this. + 26.4.3.1 [rand.eng.lcong] paragraph 2... +

    +
    + The template parameter UIntType shall denote an + unsigned integral typeunsigned integer type + large enough to store values as large as m - 1. If the + template parameter m is 0, the modulus m + used throughout this section 26.4.3.1 is + numeric_limits<result_type>::max() plus 1. [Note: + The result need not be representable as a value of type + result_type. --end note] Otherwise, the following + relations shall hold: a < m and c < + m. +
    + +

    + Same rationale as the previous change. + 26.4.4.4 [rand.adapt.xor] paragraph 6... +

    +
    + Both Engine1::result_type and + Engine2::result_type shall denote (possibly different) + unsigned integral typesunsigned integer types. + The member result_type shall denote either the type + Engine1::result_type or the type Engine2::result_type, + whichever provides the most storage according to clause 3.9.1. +
    + +

    + 26.4.7.1 [rand.util.seedseq] paragraph 7... +

    +
    + Requires:RandomAccessIterator shall meet the + requirements of a random access iterator (24.1.5) such that + iterator_traits<RandomAccessIterator>::value_type + shall denote an unsigned integral typeunsigned integer + type capable of accomodating 32-bit quantities. +
    + +

    + By making this change, integral types that happen to have a signed + representation, but are not signed integer types, would no longer be + required to use a two's complement representation. This may go against + the original intent, and should be reviewed. + 29.4 [atomics.types.operations] paragraph 24... +

    +
    + Remark: For signed integral typessigned integer + types, arithmetic is defined using two's complement + representation. There are no undefined results. For address types, the + result may be an undefined address, but the operations otherwise have + no undefined behavior. +
    + + + + + + +
    +

    874. Missing initializer_list constructor for discrete_distribution

    +

    Section: 26.4.8.5.1 [rand.dist.samp.discrete] Status: New + Submitter: Daniel Krügler Date: 2008-08-22

    +

    View other active issues in [rand.dist.samp.discrete].

    +

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

    +

    View all issues with New status.

    +

    Discussion:

    -Thanks to Jens Maurer, Gabriel Dos Reis, and Bjarne Stroustrup for clarification of constexpr requirements. +During the Sophia Antipolis meeting it was decided to separate from 793 a +subrequest that adds initializer list support to +discrete_distribution, specifically, +the issue proposed to add a c'tor taking a initializer_list<double>.

    -

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

    +
      +

    1. -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. +In 26.4.8.5.1 [rand.dist.samp.discrete]/1, class discrete_distribution, +just before the member declaration

      +
      explicit discrete_distribution(const param_type& parm);
+
      +

      -Change 19.4.1.1 [syserr.errcat.overview] Class -error_category overview error_category synopsis as -indicated: +insert

      -
      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();
+
      discrete_distribution(initializer_list<double> wl);
 
      
+
      2. +

    2. -Change 19.4.1.5 [syserr.errcat.objects] Error category objects as indicated: +Between p.4 and p.5 of the same section insert a new +paragraph as part of the new member description:

      -
      -
      extern const error_category&* const get_generic_category();
+
      discrete_distribution(initializer_list<double> wl);
 
      
-
      
-Returns: A reference generic_category shall point
-to an a statically initialized object of a type derived from
-class error_category.
-
      
 
-
      
-Remarks: The object's default_error_condition and equivalent virtual
-functions shall behave as specified for the class error_category. The
-object's name virtual function shall return a pointer to the string
-"GENERIC".
-
      
+
      
+Effects: Same as discrete_distribution(wl.begin(), wl.end()).
+
      
+
      
+
      3. +
    -
    extern const error_category&* const get_system_category();
-
    -

    -Returns: A reference system_category shall point -to an a statically -initialized object of a type derived from class error_category. -

    -

    -Remarks: The object's equivalent virtual functions shall behave as -specified for class error_category. The object's name virtual function -shall return a pointer to the string "system". The object's -default_error_condition virtual function shall behave as follows: -

    + +
    +

    875. Missing initializer_list constructor for piecewise_constant_distribution

    +

    Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: New + Submitter: Daniel Krügler Date: 2008-08-22

    +

    View other active issues in [rand.dist.samp.pconst].

    +

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

    +

    View all issues with New status.

    +

    Discussion:

    -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] +During the Sophia Antipolis meeting it was decided to separate from +794 a subrequest that adds initializer list support to +piecewise_constant_distribution, specifically, the issue proposed +to add a c'tor taking a initializer_list<double> and a Callable to evaluate +weight values. For consistency with the remainder of this class and +the remainder of the initializer_list-aware library the author decided to +change the list argument type to the template parameter RealType +instead. For the reasoning to use Func instead of Func&& as c'tor +function argument see issue 793.

    -
    + +

    Proposed resolution:

    +
      +

    1. -Change 19.4.2.1 [syserr.errcode.overview] Class error_code overview as indicated: +In 26.4.8.5.2 [rand.dist.samp.pconst]/1, class piecewise_constant_distribution, +just before the member declaration

      -
      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
+
      explicit piecewise_constant_distribution(const param_type& parm);
 
      
 
 
      
-Change 19.4.2.2 [syserr.errcode.constructors] Class error_code constructors as indicated:
+insert
 
      
 
-
      
-
      constexpr error_code(int val, const error_category&* cat);
-
      
-
      
-Effects: Constructs an object of type error_code.
-
      
-
      
-Postconditions: val_ == val and cat_ == cat.
-
      
-
      
-Throws: Nothing.
-
      
-
      
+
      template<typename Func>
+piecewise_constant_distribution(initializer_list<RealType> bl, Func fw);
+
      
+
      2. +

    2. -Change 19.4.2.3 [syserr.errcode.modifiers] Class error_code modifiers as indicated: +Between p.4 and p.5 of the same section insert a series of +new paragraphs nominated below as [p5_1], [p5_2], and [p5_3] +as part of the new member description:

      -
      -
      void assign(int val, const error_category&* cat);
+
      template<typename Func>
+piecewise_constant_distribution(initializer_list<RealType> bl, Func fw);
 
      
+
+
      
+
 
      
-Postconditions: val_ == val and cat_ == cat.
-
      
-
      
-Throws: Nothing.
+[p5_1] Complexity: Exactly nf = max(bl.size(), 1) - 1 invocations of fw.
 
      
-
      
 
 
      
-Change 19.4.2.4 [syserr.errcode.observers] Class error_code observers  as indicated:
+[p5_2] Requires:
 
      
 
-
      
-
      const error_category&* category() const;
-
      
+
        
+
      1. 
+fw shall be callable with one argument of type RealType, and shall
+   return values of a type convertible to double;
+
        2. 
+
      2. 
+The relation 0 < S = w0+. . .+wn-1 shall hold. 
+For all sampled values xk defined below, fw(xk) shall return a weight
+   value wk that is non-negative, non-NaN, and non-infinity;
+
        3. 
+
      3. 
+If nf > 0 let bk = *(bl.begin() + k), k = 0, . . . , bl.size()-1 and the
+following relations shall hold for k = 0, . . . , nf-1: bk < bk+1.
+
        4. 
+
      
 
 
      
-Returns: cat_.
-
      
-
      
-Throws: Nothing.
+[p5_3] Effects:
 
      
-
      
 
+
        
+
      1. 
+
        If nf == 0,
        
+
          
+
        1. 
+lets the sequence w have length n = 1 and consist of the single
+     value w0 = 1, and
+
          2. 
+
        2. 
+lets the sequence b have length n+1 with b0 = 0 and b1 = 1.
+
          3. 
+
        
+
        2. 
+
+
      2. 
+
        Otherwise,
        
+
          
+
        1. 
+sets n = nf, and [bl.begin(), bl.end()) shall form the sequence b of
+length n+1, and
+
          2. 
+
        2. 
+
          lets the sequences w have length n and for each k = 0, . . . ,n-1,
+     calculates:
          
+
          xk = 0.5*(bk+1 + bk)
+wk = fw(xk)
+
          
+
          3. 
+
        
+
        3. 
+
+
      3. 
 
        
-Change 19.4.3.1 [syserr.errcondition.overview] Class error_condition overview   as indicated:
+Constructs a piecewise_constant_distribution object with
+the above computed sequence b as the interval boundaries
+and with the probability densities:
 
        
+
        ρk = wk/(S * (bk+1 - bk)) for k = 0, . . . , n-1.
+
        
+
+
        4. 
+
      
 
-
      
-
      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
-
      
 
      
+
      
+
      3. +
    -

    -Change 19.4.3.2 [syserr.errcondition.constructors] Class error_condition constructors as indicated: -

    -
    -
    constexpr error_condition(int val, const error_category&* cat);
-
    + + + +
    +

    876. basic_string access operations should give stronger guarantees

    +

    Section: 21.3 [basic.string] Status: New + Submitter: Daniel Krügler Date: 2008-08-22

    +

    View other active issues in [basic.string].

    +

    View all other issues in [basic.string].

    +

    View all issues with New status.

    +

    Discussion:

    -Effects: Constructs an object of type error_condition. +During the Sophia Antipolis meeting it was decided to split-off some +parts of the +n2647 +("Concurrency modifications for basic_string") +proposal into a separate issue, because these weren't actually +concurrency-related. The here proposed changes refer to the recent +update document +n2668 +and attempt to take advantage of the +stricter structural requirements.

    -Postconditions: val_ == val and cat_ == cat. +Indeed there exists some leeway for more guarantees that would be +very useful for programmers, especially if interaction with transactionary +or exception-unaware C API code is important. This would also allow +compilers to take advantage of more performance optimizations, because +more functions can have throw() specifications. This proposal uses the +form of "Throws: Nothing" clauses to reach the same effect, because +there already exists a different issue in progress to clean-up the current +existing "schizophrenia" of the standard in this regard.

    -Throws: Nothing. +Due to earlier support for copy-on-write, we find the following +unnecessary limitations for C++0x:

    -
    + +
      +
    1. +Missing no-throw guarantees: data() and c_str() simply return +a pointer to their guts, which is a non-failure operation. This should +be spelled out. It is also noteworthy to mention that the same +guarantees should also be given by the size query functions, +because the combination of pointer to content and the length is +typically needed during interaction with low-level API. +
      2. +
    2. +Missing complexity guarantees: data() and c_str() simply return +a pointer to their guts, which is guaranteed O(1). This should be +spelled out. +
      3. +
    3. +Missing reading access to the terminating character: Only the +const overload of operator[] allows reading access to the terminator +char. For more intuitive usage of strings, reading access to this +position should be extended to the non-const case. In contrast +to C++03 this reading access should now be homogeneously +an lvalue access. +
      4. +

    -Change 19.4.3.3 [syserr.errcondition.modifiers] Class error_condition modifiers as indicated: +The proposed resolution is split into a main part (A) and a +secondary part (B) (earlier called "Adjunct Adjunct Proposal"). +(B) extends (A) by also making access to index position +size() of the at() overloads a no-throw operation. This was +separated, because this part is theoretically observable in +specifically designed test programs.

    -
    -
    void assign(int val, const error_category&* cat);
-
    -

    -Postconditions: val_ == val and cat_ == cat. + +

    Proposed resolution:

    +
      +
    1. +
        +
      1. +

        In 21.3.4 [string.capacity], just after p. 1 add a new paragraph:

        -

        +

        Throws: Nothing. -

        +
        2. +

      2. -Change 19.4.3.4 [syserr.errcondition.observers] Class error_condition observers as indicated: +In 21.3.5 [string.access] replace p. 1 by the following 4 paragraghs:

        -
        const error_category&* category() const;
-
        -

        -Returns: cat_. -

        -Throws: Nothing. +Requires: pos ≤ size().

        -
        -

        -Throughout 19.4 [syserr] System error support, change "category()." to "category()->". -Appears approximately six times. +Returns: If pos < size(), returns *(begin() + pos). Otherwise, returns +a reference to a charT() that shall not be modified.

        -

        -[Partially Editorial] In 19.4.4 [syserr.compare] Comparison operators, -paragraphs 2 and 4, change "category.equivalent(" to -"category()->equivalent(". +Throws: Nothing.

        - - - - - -
        -

        833. Freestanding implementations header list needs review for C++0x

        -

        Section: 17.4.1.3 [compliance] Status: New - Submitter: Beman Dawes Date: 2008-05-14

        -

        View all issues with New status.

        -

        Discussion:

        -

        -Once the C++0x standard library is feature complete, the LWG needs to -review 17.4.1.3 [compliance] Freestanding implementations header list to -ensure it reflects LWG consensus. +

        +Complexity: Constant time.

        +
    - -

    Proposed resolution:

    - - - - - -
    -

    834. Unique_ptr::pointer requirements underspecified

    -

    Section: 20.6.11.2 [unique.ptr.single] Status: New - Submitter: Daniel Krügler Date: 2008-05-14

    -

    View all issues with New status.

    -

    Discussion:

    + +

  • -Issue 673 (including recent updates by 821) proposes a useful -extension point for unique_ptr by granting support for an optional -deleter_type::pointer to act as pointer-like replacement for element_type* -(In the following: pointer). +In 21.3.7.1 [string.accessors] replace the now common returns +clause of c_str() and data() by the following three paragraphs:

    +

    -Unfortunately no requirements are specified for the type pointer which has -impact on at least two key features of unique_ptr: +Returns: A pointer p such that p+i == &operator[](i) for each i +in [0, size()].

    - -
      -
    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). +Throws: Nothing.

    - - -

    Proposed resolution:

    -Add the following sentence just at the end of the newly proposed -20.6.11.2 [unique.ptr.single]/p. 3: +Complexity: Constant time. +

    +
    +
    • + + +
  • +
      +
    1. +

      +In 21.3.5 [string.access] replace p.2 and p.3 by:

      -
      -unique_ptr<T, D>::pointer's operations shall be well-formed, shall have well -defined behavior, and shall not throw exceptions. +

      +Requires: pos ≤ size() +

      +

      +Throws: out_of_range if pos > size(). +

      +
      2. +
    +
    • + +
    -

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

    +

    877. to throw() or to Throw: Nothing.

    +

    Section: 17 [library] Status: New + Submitter: Martin Sebor Date: 2008-08-23

    +

    View all other issues in [library].

    View all issues with New status.

    Discussion:

    -The fix for -issue 581, -now integrated into the working paper, overlooks a couple of minor -problems. - -

    -

    - -First, being an unformatted function once again, flush() -is required to create a sentry object whose constructor must, among -other things, flush the tied stream. When two streams are tied -together, either directly or through another intermediate stream -object, flushing one will also cause a call to flush() on -the other tied stream(s) and vice versa, ad infinitum. The program -below demonstrates the problem. +Recent changes to +the working +draft have introduced a gratuitous inconsistency with the C++ 2003 +version of the specification with respect to exception guarantees +provided by standard functions. While the C++ 2003 standard +consistenly uses the empty exception specification, throw(), +to declare functions that are guaranteed not to throw exceptions, the +current working draft contains a number of "Throws: Nothing." +clause to specify essentially the same requirement. The difference +between the two approaches is that the former specifies the behavior +of programs that violate the requirement (std::unexpected() +is called) while the latter leaves the behavior undefined.

    -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; +A survey of the working draft reveals that there are a total of 209 +occurrences of throw() in the library portion of the spec, +the majority in clause 18, a couple (literally) in 19, a handful in +20, a bunch in 22, four in 24, one in 27, and about a dozen in D.9.

    -
    - 
    #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. +There are also 203 occurrences of "Throws: Nothing." scattered +throughout the spec.

    -Add a Requires clause to 27.4.4.2 [basic.ios.members] withethe following -text: +While sometimes there are good reasons to use the "Throws: +Nothing." approach rather than making use of throw(), these +reasons do not apply in most of the cases where this new clause has +been introduced and the empty exception specification would be a +better approach.

    -
    - -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: +First, functions declared with the empty exception specification +permit compilers to generate better code for calls to such +functions. In some cases, the compiler might even be able to eliminate +whole chunks of user-written code when instantiating a generic +template on a type whose operations invoked from the template +specialization are known not to throw. The prototypical example are +the std::uninitialized_copy() +and std::uninitialized_fill() algorithms where the +entire catch(...) block can be optimized away.

    -
    - -If ((os.flags() & ios_base::unitbuf) && -!uncaught_exception()) is true, -calls os.flush() os.rdbuf()->pubsync(). - -
    - - - - -
    -

    836. - effects of money_base::space and - money_base::none on money_get -

    -

    Section: 22.2.6.1.2 [locale.money.get.virtuals] Status: New - Submitter: Martin Sebor Date: 2008-05-17

    -

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

    -

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

    -

    View all issues with New status.

    -

    Discussion:

    -In paragraph 2, 22.2.6.1.2 [locale.money.get.virtuals] specifies the following: +For example, given the following definition of +the std::uninitialized_copy function template and a +user-defined type SomeType:

    + 
    template <class InputIterator, class ForwardIterator>
+ForwardIterator
+uninitialized_copy (InputIterator first, InputIterator last, ForwardIterator res)
+{
+   typedef iterator_traits<ForwardIterator>::value_type ValueType;
+
+   ForwardIterator start = res;
+
+   try {
+       for (; first != last; ++first, ++res)
+           ::new (&*res) ValueType (*first);
+   }
+   catch (...) {
+       for (; start != res; --start)
+           (&*start)->~ValueType ();
+       throw;
+   }
+   return res;
+}
 
-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.
-
+struct SomeType {
+   SomeType (const SomeType&) throw ();
+}

    -This requirement can be (and has been) interpreted two mutually -exclusive ways by different readers. One possible interpretation -is that: +compilers are able to emit the following efficient specialization +of std::uninitialized_copy<const SomeType*, SomeType*> +(note that the catch block has been optimized away):

    -
      -
    1. - -where money_base::space appears in the format, at least -one space is required, and - -
      2. -
    2. - -where money_base::none appears in the format, space is -allowed but not required. + 
      template <> SomeType*
+uninitialized_copy (const SomeType *first, const SomeType *last, SomeType *res)
+{
+   for (; first != last; ++first, ++res)
+       ::new (res) SomeType (*first);
 
-
      3. -
    + return res; +}

    -The other is that: +Another general example is default constructors which, when decorated +with throw(), allow the compiler to eliminate the +implicit try and catch blocks that it otherwise must +emit around each the invocation of the constructor +in new-expressions.

    -
    - -where either money_base::space or money_base::none appears in the format, white space is optional. - -
    - - -

    Proposed resolution:

    -I propose to change the text to make it clear that the first -interpretation is intended, that is, to make following change to -22.2.6.1.2 [locale.money.get.virtuals], p2: - -

    - -
    - -When money_base::space -or money_base::none appears as the last -element in the format pattern, except at the end, optional -white space (as recognized by ct.is) is consumed after -any required space. no white space is consumed. Otherwise, -where money_base::space appears in any of the initial -elements of the format pattern, at least one white space character is -required. Where money_base::none appears in any of the -initial elements of the format pattern, white space is allowed but not -required. In either case, any required followed by all optional white -space (as recognized by ct.is()) is consumed. -If (str.flags() & str.showbase) is false, ... - -
    - - - - -
    -

    837. - basic_ios::copyfmt() overly loosely specified -

    -

    Section: 27.4.4.2 [basic.ios.members] Status: New - Submitter: Martin Sebor Date: 2008-05-17

    -

    View other active issues in [basic.ios.members].

    -

    View all other issues in [basic.ios.members].

    -

    View all issues with New status.

    -

    Discussion:

    -

    - -The basic_ios::copyfmt() member function is specified in 27.4.4.2 [basic.ios.members] to have the following effects: - -

    -
    - -Effects: If (this == &rhs) does -nothing. Otherwise assigns to the member objects of *this -the corresponding member objects of rhs, except that - -
      -
    • - -rdstate() and rdbuf() are left unchanged; - -
      • -
    • - -exceptions() is altered last by -calling exceptions(rhs.except) - -
      • -
    • - -the contents of arrays pointed at by pword -and iword are copied not the pointers themselves - -
      • -
    -
    -

    - -Since the rest of the text doesn't specify what the member objects -of basic_ios are this seems a little too loose. - -

    - +For example, given the following definitions of +class MayThrow and WontThrow and the two +statements below: -

    Proposed resolution:

    -

    +

    +
    + 
    struct MayThrow {
+   MayThrow ();
+};
 
-I propose to tighten things up by adding a Postcondition clause
-to the function like so:
+struct WontThrow {
+   WontThrow () throw ();
+};
 
-   
    
-   
    
-     Postconditions:
+MayThrow  *a = new MayThrow [N];
+WontThrow *b = new WontThrow [N];
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    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 compiler generates the following code for the first statement: -

    -

    +

    +
    + 
    MayThrow *a;
+{
+   MayThrow *first = operator new[] (N * sizeof (*a));
+   MayThrow *last  = first + N;
+   MayThrow *next  = first;
+   try {
+       for ( ; next != last; ++next)
+           new (next) MayThrow;
+   }
+   catch (...) {
+       for ( ; first != first; --next)
+           next->~MayThrow ();
+       operator delete[] (first);
+       throw;
+   }
+   a = first;
+}
    +
    +

    -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. +but it is can generate much more compact code for the second statement: -

    - +

    +
    + 
    WontThrow *b    = operator new[] (N * sizeof (*b));
+WontThrow *last = b + N;
+for (WontThrow *next = b; next != last; ++next)
+   new (next) WontThrow;
+
    +
    +

    +Second, in order for users to get the maximum benefit out of the new +std::has_nothrow_xxx traits when using standard library types +it will be important for implementations to decorate all non throwing +copy constructors and assignment operators with throw(). Note +that while an optimizer may be able to tell whether a function without +an explicit exception specification can throw or not based on its +definition, it can only do so when it can see the source code of the +definition. When it can't it must assume that the function may +throw. To prevent violating the One Definition Rule, +the std::has_nothrow_xxx trait must return the most +pessimistic guess across all translation units in the program, meaning +that std::has_nothrow_xxx<T>::value must evaluate to +false for any T whose xxx +(where xxx is default or copy ctor, or assignment operator) +is defined out-of-line. +

    +

    -

    -

    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:

    -

    +Counterarguments: -From message c++std-lib-20003... +

    +

    -

    -

    +During the discussion of this issue +on c++std-lib@accu.org +(starting with post c++std-lib-21950) the following arguments +in favor of the "Throws: Nothing." style have been made. -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): +

    +

    +

      +
    1. + +Decorating functions that cannot throw with the empty exception +specification can cause the compiler to generate suboptimal code for +the implementation of the function when it calls other functions that +aren't known to the compiler not to throw (i.e., that aren't decorated +with throw() even if they don't actually throw). This is a +common situation when the called function is a C or POSIX function. + +
      2. +
    2. + +Alternate, proprietary mechanisms exist (such as +GCC __attribute__((nothrow)) +or Visual +C++ __declspec(nothrow)) +that let implementers mark up non-throwing functions, often without +the penalty mentioned in (1) above. The C++ standard shouldn't +preclude the use of these potentially more efficient mechanisms. + +
      3. +
    3. + +There are functions, especially function templates, that invoke +user-defined functions that may or may not be +declared throw(). Declaring such functions with the empty +exception specification will cause compilers to generate suboptimal +code when the user-defined function isn't also declared not to throw. + +
      4. +
    + +

    -

    -
    +The answer to point (1) above is that implementers can (and some have) +declare functions with throw() to indicate to the compiler +that calls to the function can safely be assumed not to throw in order +to allow it to generate efficient code at the call site without also +having to define the functions the same way and causing the compiler +to generate suboptimal code for the function definition. That is, the +function is declared with throw() in a header but it's +defined without it in the source file. The throw() +declaration is suppressed when compiling the definition to avoid +compiler errors. This technique, while strictly speaking no permitted +by the language, is safe and has been employed in practice. For +example, the GNU C library takes this approach. Microsoft Visual C++ +takes a similar approach by simply assuming that no function with C +language linkage can throw an exception unless it's explicitly +declared to do so using the language extension throw(...). -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. +

    +

    -

    -

    +Our answer to point (2) above is that there is no existing practice +where C++ Standard Library implementers have opted to make use of the +proprietary mechanisms to declare functions that don't throw. The +language provides a mechanism specifically designed for this +purpose. Avoiding its use in the specification itself in favor of +proprietary mechanisms defeats the purpose of the feature. In +addition, making use of the empty exception specification +inconsistently, in some areas of the standard, while conspicuously +avoiding it and making use of the "Throws: Nothing." form in +others is confusing to users. -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). +

    +

    -

    -

    +The answer to point (3) is simply to exercise caution when declaring +functions and especially function templates with the empty exception +specification. Functions that required not to throw but that may call +back into user code are poor candidates for the empty exception +specification and should instead be specified using "Throws: +Nothing." clause. -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. +

    + +

    Proposed resolution:

    +

    -

    -

    +We propose two possible solutions. Our recommendation is to adopt +Option 1 below. -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. +

    +

    -

    -

    +Option 1: -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);
-
    -
    -

    +Except for functions or function templates that make calls back to +user-defined functions that may not be declared throw() +replace all occurrences of the "Throws: Nothing." clause with +the empty exception specification. Functions that are required not to +throw but that make calls back to user code should be specified to +"Throw: Nothing." -Or is it intended that once an iterator becomes EOS it stays EOS until -the end of its lifetime? +

    +

    -

    - +Option 2: -

    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. +For consistency, replace all occurrences of the empty exception +specification with a "Throws: Nothing." clause. -

    -

    +

    + -To this end we propose to change 24.5.1 [istream.iterator], p1, -as follows: -

    -
    -The result of operator-> on an end-of-stream -is not defined. For any other iterator value a const T* -is returned. Invoking operator++() on -an end-of-stream iterator is undefined. It is impossible -to store things into istream iterators... +
    +

    878. forward_list preconditions

    +

    Section: 23.2.3 [forwardlist] Status: New + Submitter: Martin Sebor Date: 2008-08-23

    +

    View all issues with New status.

    +

    Discussion:

    +

    -

    -

    +forward_list member functions that take +a forward_list::iterator (denoted position in the +function signatures) argument have the following precondition: -Add pre/postconditions to the member function descriptions of istream_iterator like so: +

    +
    -

    -
    +Requires: position is dereferenceable or equal +to before_begin(). -
    istream_iterator();
    +
    +

    -Effects: Constructs the end-of-stream iterator.
    -Postcondition: in_stream == 0. +I believe what's actually intended is this: -

    istream_iterator(istream_type &s);
    +

    +
    -Effects: Initializes in_stream with &s. value -may be initialized during construction or the first time it is -referenced.
    -Postcondition: in_stream == &s. +Requires: position is in the range +[before_begin(), end()). -
    istream_iterator(const istream_iterator &x);
    +
    +

    -Effects: Constructs a copy of x.
    -Postcondition: in_stream == x.in_stream. +That is, when it's dereferenceable, position must point +into *this, not just any forward_list object. -

    istream_iterator& operator++();
    +

    + +

    Proposed resolution:

    +

    -Requires: in_stream != 0.
    -Effects: *in_stream >> value. +Change the Requires clause as follows: -

    istream_iterator& operator++(int);
    +

    +
    -Requires: in_stream != 0.
    -Effects: - 
    istream_iterator tmp (*this);
-*in_stream >> value;
-return tmp;
-
    -
    -
    - +Requires: position is in the range +[before_begin(), end()) dereferenceable +or equal to before_begin(). +
    + diff --git a/libstdc++-v3/doc/html/ext/lwg-closed.html b/libstdc++-v3/doc/html/ext/lwg-closed.html index 68bca50..a056c3e 100644 --- a/libstdc++-v3/doc/html/ext/lwg-closed.html +++ b/libstdc++-v3/doc/html/ext/lwg-closed.html @@ -1,22 +1,24 @@ -C++ Standard Library Closed Issues List - + + +C++ Standard Library Closed Issues List + + - + - + @@ -27,7 +29,7 @@ del {background-color:#FFA0A0}
    Doc. no.N2614=08-0124N2729=08-0239
    Date:2008-05-182008-08-24
    Project:Howard Hinnant <howard.hinnant@gmail.com>
    -

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

    +

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

    Reference ISO/IEC IS 14882:1998(E)

    Also see:

    @@ -49,6 +51,67 @@ del {background-color:#FFA0A0}

    Revision History

      +
    • R59: +2008-08-22 pre-San Francisco mailing. +
        +
      • Summary:
          +
        • 192 open issues, up by 9.
          • +
        • 686 closed issues, up by 0.
          • +
        • 878 issues total, up by 9.
          • +
        • +
      • Details:
        • +
      +
      • +
    • R58: +2008-07-28 mid-term mailing. +
        +
      • Summary:
          +
        • 183 open issues, up by 12.
          • +
        • 686 closed issues, down by 4.
          • +
        • 869 issues total, up by 8.
          • +
        • +
      • Details:
          +
        • Added the following New issues: 862, 863, 864, 865, 866, 867, 868, 869.
          • +
        • Changed the following issues from Pending NAD Editorial to NAD Editorial: 393, 557, 592, 754, 757.
          • +
        • Changed the following issues from Pending WP to Open: 644.
          • +
        • Changed the following issues from WP to Ready: 387, 629.
          • +
        • Changed the following issues from Pending NAD Editorial to Review: 709.
          • +
        • +
      +
      • +
    • R57: +2008-06-27 post-Sophia Antipolis mailing. + +
    • R56: 2008-05-16 pre-Sophia Antipolis mailing.
        @@ -58,7 +121,7 @@ del {background-color:#FFA0A0}
      • 838 issues total, up by 25.
    • Details:
    @@ -76,7 +139,7 @@ del {background-color:#FFA0A0}
  • Added the following NAD issues: 790, 791, 796, 797, 799.
  • Added the following New issues: 788, 794, 802, 804, 805, 806, 807, 808, 809, 810, 811, 812, 813.
  • Added the following Open issues: 793, 800, 801, 803.
    • -
  • Added the following Ready issues: 789, 792, 798.
    • +
  • Added the following Ready issues: 789, 792, 798.
  • Changed the following issues from NAD Future to Dup: 116.
  • Changed the following issues from NAD Future to NAD: 188, 323.
  • Changed the following issues from New to NAD: 729, 730, 731, 733, 735, 736, 737, 739, 741, 745, 748, 763, 764, 773, 784.
    • @@ -85,13 +148,13 @@ del {background-color:#FFA0A0}
  • Changed the following issues from Open to NAD Editorial: 529, 626.
  • Changed the following issues from Review to NAD Editorial: 645, 684.
  • Changed the following issues from NAD Future to Open: 128, 180, 190.
    • -
  • Changed the following issues from New to Open: 617, 718, 719, 720, 724, 732, 734, 742, 747, 750, 753, 756, 760, 762, 767, 774.
    • +
  • Changed the following issues from New to Open: 617, 718, 719, 720, 724, 732, 734, 742, 747, 750, 753, 756, 760, 762, 767, 774.
  • Changed the following issues from Ready to Open: 675, 676, 688.
    • -
  • Changed the following issues from New to Pending NAD Editorial: 709, 717, 725, 738, 754, 757.
    • +
  • Changed the following issues from New to Pending NAD Editorial: 709, 717, 725, 738, 754, 757.
  • Changed the following issues from Open to Pending NAD Editorial: 424, 557, 625.
    • -
  • Changed the following issues from New to Ready: 710, 715, 722, 740, 743, 744, 746, 749, 755, 758, 759, 761, 766, 768, 770, 775, 777, 778, 781, 782, 783.
    • -
  • Changed the following issues from Open to Ready: 387, 471, 550, 612, 629, 673.
    • -
  • Changed the following issues from Review to Ready: 518, 574, 596, 618, 638, 672, 685.
    • +
  • Changed the following issues from New to Ready: 710, 715, 722, 740, 743, 744, 746, 749, 755, 758, 759, 761, 766, 768, 770, 775, 777, 778, 781, 782, 783.
    • +
  • Changed the following issues from Open to Ready: 387, 471, 550, 612, 629, 673.
    • +
  • Changed the following issues from Review to Ready: 518, 574, 596, 618, 638, 672, 685.
  • Changed the following issues from New to Review: 711, 728, 771, 776.
  • Changed the following issues from Open to Review: 539.
  • Changed the following issues from Ready to WP: 561, 562, 563, 567, 581, 620, 621, 622, 623, 624, 661, 664, 665, 666, 674, 679, 680, 687, 689, 693, 694, 695, 700, 703, 705, 706.
    • @@ -108,7 +171,7 @@ del {background-color:#FFA0A0}
  • 787 issues total, up by 23.
  • Details:
  • Details:
    • @@ -141,16 +204,16 @@ del {background-color:#FFA0A0}
  • 754 issues total, up by 31.
  • Details:
  • Details:
    • @@ -187,10 +250,10 @@ del {background-color:#FFA0A0}
  • 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 Pending WP to Open: 258.
    • -
  • Changed the following issues from Ready to Pending WP: 644.
    • +
  • Changed the following issues from Ready to Pending WP: 644.
  • Changed the following issues from New to Ready: 577, 660.
  • Changed the following issues from Open to Ready: 488.
    • -
  • Changed the following issues from Open to Review: 518.
    • +
  • Changed the following issues from Open to Review: 518.
  • Changed the following issues from Ready to TRDec: 604.
  • Changed the following issues from DR to WP: 453.
  • Changed the following issues from Ready to WP: 531, 551, 566, 628, 640, 643, 646.
    • @@ -206,7 +269,7 @@ del {background-color:#FFA0A0}
  • 696 issues total, up by 20.
  • Details:
  • Details:
  • Details:
      -
    • Added the following New issues: 620, 621, 622, 623, 624, 627, 628, 629, 630, 631, 632, 633, 634, 635, 636, 637, 638, 639, 640, 641, 642, 643, 644, 645, 646, 647, 648, 649, 650, 651, 652, 653, 654, 655, 656.
      • +
    • Added the following New issues: 620, 621, 622, 623, 624, 627, 628, 629, 630, 631, 632, 633, 634, 635, 636, 637, 638, 639, 640, 641, 642, 643, 644, 645, 646, 647, 648, 649, 650, 651, 652, 653, 654, 655, 656.
    • Added the following Open issues: 625, 626.
      • -
    • Changed the following issues from New to Open: 570, 580, 582, 590, 612, 614.
      • +
    • Changed the following issues from New to Open: 570, 580, 582, 590, 612, 614.
    • Changed the following issues from New to Tentatively Ready: 547, 553, 560, 571, 572, 575, 576, 578, 586, 589, 591, 593, 594, 609, 610, 611, 613, 615, 616, 619.
    • Changed the following issues from Open to Tentatively Ready: 201, 206, 233, 254, 258, 385, 416, 422, 456, 463, 466, 470, 471, 479, 482, 515, 526, 532, 536, 542, 559.
    • Changed the following issues from Review to Tentatively Ready: 534.
      • @@ -284,7 +347,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.
      • @@ -373,7 +436,7 @@ Moved issues 498, 504, 506, 509, 510, 511, 512, 513, 514 from New to Open. Moved issues 505, 507, 508, 519 from New to Ready. Moved issue 500 from New to NAD. -Moved issue 518 from New to Review. +Moved issue 518 from New to Review.
    • R38: 2005-07-03 pre-Mont Tremblant mailing. @@ -617,7 +680,7 @@ exists.)

      Proposed resolution:

      -

      Change 20.4.4.3 [meta.unary.prop] paragraph 1 Effects from +

      Change 20.5.4.3 [meta.unary.prop] paragraph 1 Effects from "Calls p->release()" to "Calls p.release()".

      @@ -980,7 +1043,7 @@ otherwise possible.

      82. Missing constant for set elements

      -

      Section: 23.1.2 [associative.reqmts] Status: NAD +

      Section: 23.1.4 [associative.reqmts] Status: NAD Submitter: Nico Josuttis Date: 1998-09-29

      View all other issues in [associative.reqmts].

      View all issues with NAD status.

      @@ -1212,7 +1275,7 @@ may be provided by a non-Standard implementation class:

      Proposed resolution:

      -

      Add a new subclause [presumably 17.4.4.9] following 17.4.4.8 [res.on.exception.handling]:

      +

      Add a new subclause [presumably 17.4.4.9] following 17.4.4.9 [res.on.exception.handling]:

      17.4.4.9 Template Parameters

      A specialization of a @@ -1385,7 +1448,7 @@ expressed in a single line of code (where v is

      102. Bug in insert range in associative containers

      -

      Section: 23.1.2 [associative.reqmts] Status: Dup +

      Section: 23.1.4 [associative.reqmts] Status: Dup Submitter: AFNOR Date: 1998-10-07

      View all other issues in [associative.reqmts].

      View all issues with Dup status.

      @@ -1579,7 +1642,7 @@ desired functionality.

      Submitter: Judy Ward Date: 1998-11-06

      View all other issues in [template.bitset].

      View all issues with Dup status.

      -

      Duplicate of: 778

      +

      Duplicate of: 778

      Discussion:

      @@ -1958,7 +2021,7 @@ set. Consider Arabic or Hebrew, for example. See 22.2.2.2.2 [facet.num.put.virtu

      149. Insert should return iterator to first element inserted

      -

      Section: 23.1.1 [sequence.reqmts] Status: NAD Future +

      Section: 23.1.3 [sequence.reqmts] Status: NAD Future Submitter: Andrew Koenig Date: 1999-06-28

      View all other issues in [sequence.reqmts].

      View all issues with NAD Future status.

      @@ -2297,7 +2360,7 @@ iterators.

      192. a.insert(p,t) is inefficient and overconstrained

      -

      Section: 23.1.2 [associative.reqmts] Status: NAD +

      Section: 23.1.4 [associative.reqmts] Status: NAD Submitter: Ed Brey Date: 1999-06-06

      View all other issues in [associative.reqmts].

      View all issues with NAD status.

      @@ -2343,7 +2406,7 @@ providing no disadvantage to the container implementation.

      Proposed resolution:

      -

      In 23.1.2 [associative.reqmts] paragraph 7, replace the row in table 69 +

      In 23.1.4 [associative.reqmts] paragraph 7, replace the row in table 69 for a.insert(p,t) with the following two rows:

      @@ -2703,7 +2766,6 @@ paragraphs.

      213. Math function overloads ambiguous

      Section: 26.7 [c.math] Status: NAD Submitter: Nico Josuttis Date: 2000-02-26

      -

      View other active issues in [c.math].

      View all other issues in [c.math].

      View all issues with NAD status.

      Discussion:

      @@ -2728,7 +2790,7 @@ or write floating point expressions as arguments.

      215. Can a map's key_type be const?

      -

      Section: 23.1.2 [associative.reqmts] Status: NAD +

      Section: 23.1.4 [associative.reqmts] Status: NAD Submitter: Judy Ward Date: 2000-02-29

      View all other issues in [associative.reqmts].

      View all issues with NAD status.

      @@ -2753,7 +2815,7 @@ too.

      Rationale:

      The "key is assignable" requirement from table 69 in -23.1.2 [associative.reqmts] already implies the key cannot be const.

      +23.1.4 [associative.reqmts] already implies the key cannot be const.

      @@ -2847,7 +2909,7 @@ operator<.

      219. find algorithm missing version that takes a binary predicate argument

      -

      Section: 25.1.2 [alg.find] Status: NAD Future +

      Section: 25.1.5 [alg.find] Status: NAD Future Submitter: Pablo Halpern Date: 2000-03-06

      View all other issues in [alg.find].

      View all issues with NAD Future status.

      @@ -2863,7 +2925,7 @@ simple, alternative interface to find.

      Proposed resolution:

      -

      In section 25.1.2 [alg.find], add a second prototype for find +

      In section 25.1.5 [alg.find], add a second prototype for find (between the existing prototype and the prototype for find_if), as follows:

          template<class InputIterator, class T, class BinaryPredicate>
@@ -2928,7 +2990,7 @@ ie. the do_is() method as described in 22.2.1.1.2 [locale.ctype.virtual
 
 
      
 
      244. Must find's third argument be CopyConstructible?
      
-
      Section: 25.1.2 [alg.find] Status: NAD
+
      Section: 25.1.5 [alg.find] Status: NAD
  Submitter: Andrew Koenig Date: 2000-05-02
      
 
      View all other issues in [alg.find].
      
 
      View all issues with NAD status.
      
@@ -3003,7 +3065,7 @@ how many times find may invoke operator++.
      
 
 
      
 
      246. a.insert(p,t) is incorrectly specified
      
-
      Section: 23.1.2 [associative.reqmts] Status: Dup
+
      Section: 23.1.4 [associative.reqmts] Status: Dup
  Submitter: Mark Rodgers Date: 2000-05-19
      
 
      View all other issues in [associative.reqmts].
      
 
      View all issues with Dup status.
      
@@ -3133,7 +3195,7 @@ code.
      
 
 
      
 
      257. STL functional object and iterator inheritance.
      
-
      Section: 20.5.3 [base], 24.3.2 [iterator.basic] Status: NAD
+
      Section: 20.6.3 [base], 24.3.2 [iterator.basic] Status: NAD
  Submitter: Robert Dick  Date: 2000-08-17
      
 
      View all other issues in [base].
      
 
      View all issues with NAD status.
      
@@ -3558,7 +3620,6 @@ version of setf, to avoid unexpected behavior.
 
      289. <cmath> requirements missing C float and long double versions
      
 
      Section: 26.7 [c.math] Status: NAD
  Submitter: Judy Ward Date: 2000-12-30
      
-
      View other active issues in [c.math].
      
 
      View all other issues in [c.math].
      
 
      View all issues with NAD status.
      
 
      Discussion:
      
@@ -3941,7 +4002,6 @@ about when terminate() is called; it merely specifies which
 
      323. abs() overloads in different headers
      
 
      Section: 26.7 [c.math] Status: NAD
  Submitter: Dave Abrahams Date: 2001-06-04
      
-
      View other active issues in [c.math].
      
 
      View all other issues in [c.math].
      
 
      View all issues with NAD status.
      
 
      Discussion:
      
@@ -4228,7 +4288,7 @@ operator< on any pair type which contains a pointer.
 
 
      
 
      350. allocator<>::address
      
-
      Section: 20.6.5.1 [allocator.members], 20.1.2 [allocator.requirements], 17.4.1.1 [contents] Status: Dup
+
      Section: 20.7.5.1 [allocator.members], 20.1.2 [allocator.requirements], 17.4.1.1 [contents] Status: Dup
  Submitter: Nathan Myers Date: 2001-10-25
      
 
      View all other issues in [allocator.members].
      
 
      View all issues with Dup status.
      
@@ -4313,15 +4373,15 @@ exhibiting a problem.
      
 
 
      
 
      351. unary_negate and binary_negate: struct or class?
      
-
      Section: 20.5 [function.objects] Status: NAD Editorial
+
      Section: 20.6 [function.objects] Status: NAD Editorial
  Submitter: Dale Riley Date: 2001-11-12
      
 
      View all other issues in [function.objects].
      
 
      View all issues with NAD Editorial status.
      
 
      Discussion:
      
 
      
-In 20.5 [function.objects] the header <functional> synopsis declares
+In 20.6 [function.objects] the header <functional> synopsis declares
 the unary_negate and binary_negate function objects as struct.
-However in 20.5.10 [negators] the unary_negate and binary_negate
+However in 20.6.10 [negators] the unary_negate and binary_negate
 function objects are defined as class.  Given the context, they are
 not "basic function objects" like negate, so this is either a typo or
 an editorial oversight.
@@ -4332,7 +4392,7 @@ an editorial oversight.
 
 
 
      Proposed resolution:
      
-
      Change the synopsis to reflect the useage in 20.5.10 [negators]
      
+
      Change the synopsis to reflect the useage in 20.6.10 [negators]
      
 
 
      [Curaçao: Since the language permits "struct", the LWG
 views this as NAD. They suggest, however, that the Project Editor
@@ -4558,7 +4618,6 @@ to see which interpretation is being used.
      
 
      357. <cmath> float functions cannot return HUGE_VAL
      
 
      Section: 26.7 [c.math] Status: NAD Editorial
  Submitter: Ray Lischner Date: 2002-02-26
      
-
      View other active issues in [c.math].
      
 
      View all other issues in [c.math].
      
 
      View all issues with NAD Editorial status.
      
 
      Discussion:
      
@@ -4865,13 +4924,13 @@ part of the "Effects" paragraph.
 
 
      
 
      372. Inconsistent description of stdlib exceptions
      
-
      Section: 17.4.4.8 [res.on.exception.handling], 18.6.1 [type.info] Status: NAD
+
      Section: 17.4.4.9 [res.on.exception.handling], 18.6.1 [type.info] Status: NAD
  Submitter: Randy Maddox Date: 2002-07-22
      
 
      View all other issues in [res.on.exception.handling].
      
 
      View all issues with NAD status.
      
 
      Discussion:
      
 
-
      Paragraph 3 under clause 17.4.4.8 [res.on.exception.handling], Restrictions on
+
      Paragraph 3 under clause 17.4.4.9 [res.on.exception.handling], Restrictions on
 Exception Handling, states that "Any other functions defined in the
 C++ Standard Library that do not have an exception-specification may
 throw implementation-defined exceptions unless otherwise specified."
@@ -5021,7 +5080,7 @@ out of scope?
 
      
 Many function templates have parameters that are passed by value;
 a typical example is find_if's pred parameter in
-25.1.2 [alg.find].  Are the corresponding template parameters
+25.1.5 [alg.find].  Are the corresponding template parameters
 (Predicate in this case) implicitly required to be
 CopyConstructible, or does that need to be spelled out explicitly?
 
      
@@ -5296,10 +5355,10 @@ 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
+
      Section: 22.2.1.4.2 [locale.codecvt.virtuals] Status: NAD Editorial
  Submitter: Alberto Barbati Date: 2002-12-24
      
 
      View all other issues in [locale.codecvt.virtuals].
      
-
      View all issues with Pending NAD Editorial status.
      
+
      View all issues with NAD Editorial status.
      
 
      Discussion:
      
 
      
 this DR follows the discussion on the previous thread "codecvt::do_in
@@ -5427,8 +5486,8 @@ 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,
      
+20.7.5.1 [allocator.members], p3,
      
+20.7.5.1 [allocator.members], p10,
      
 21.3.2 [string.cons], p11,
      
 22.1.1.2 [locale.cons], p11,
      
 23.2.2.3 [deque.modifiers], p2,
      
@@ -5443,7 +5502,7 @@ 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,
      
+25.1.4 [alg.foreach], p4,
      
 26.3.5 [complex.member.ops], p1,
      
 27.4.2.5 [ios.base.storage], p6.
      
 
      
@@ -5785,7 +5844,7 @@ table, in this regard.
 
 
      
 
      451. Associative erase should return an iterator
      
-
      Section: 23.1.2 [associative.reqmts], 23.3 [associative] Status: Dup
+
      Section: 23.1.4 [associative.reqmts], 23.3 [associative] Status: Dup
  Submitter: Bill Plauger Date: 2004-01-30
      
 
      View all other issues in [associative.reqmts].
      
 
      View all issues with Dup status.
      
@@ -6284,7 +6343,7 @@ support that the eventual solution should make this code well formed.
 
 
      
 
      480. unary_function and binary_function should have protected nonvirtual destructors
      
-
      Section: 20.5.3 [base] Status: NAD
+
      Section: 20.6.3 [base] Status: NAD
  Submitter: Joe Gottman Date: 2004-08-19
      
 
      View all other issues in [base].
      
 
      View all issues with NAD status.
      
@@ -6386,7 +6445,7 @@ explicit, but it's hard to think that's a major problem.
      
 
 
      
 
      482. Swapping pairs
      
-
      Section: 20.2.3 [pairs], 20.3 [tuple] Status: NAD Editorial
+
      Section: 20.2.3 [pairs], 20.4 [tuple] Status: NAD Editorial
  Submitter: Andrew Koenig Date: 2004-09-14
      
 
      View all other issues in [pairs].
      
 
      View all issues with NAD Editorial status.
      
@@ -6535,7 +6594,6 @@ 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
      
@@ -7294,7 +7352,7 @@ not guarantee the substitution property or referential transparency).
      
 
 
      
 
      494. Wrong runtime complexity for associative container's insert and delete
      
-
      Section: 23.1.2 [associative.reqmts] Status: NAD
+
      Section: 23.1.4 [associative.reqmts] Status: NAD
  Submitter: Hans B os Date: 2004-12-19
      
 
      View all other issues in [associative.reqmts].
      
 
      View all issues with NAD status.
      
@@ -7447,7 +7505,7 @@ Contradiction.
 
 
      
 
      501. Proposal: strengthen guarantees of lib.comparisons
      
-
      Section: 20.5.3 [base] Status: NAD
+
      Section: 20.6.3 [base] Status: NAD
  Submitter: Me <anti_spam_email2003@yahoo.com> Date: 2005-06-07
      
 
      View all other issues in [base].
      
 
      View all issues with NAD status.
      
@@ -8129,7 +8187,7 @@ Berlin: N1932 considers this NAD. This is a QOI issue.
 
 
      
 
      525. type traits definitions not clear
      
-
      Section: 20.4.4 [meta.unary], TR1 4.5 [tr.meta.unary] Status: NAD Editorial
+
      Section: 20.5.4 [meta.unary], TR1 4.5 [tr.meta.unary] Status: NAD Editorial
  Submitter: Robert Klarer Date: 2005-07-11
      
 
      View all issues with NAD Editorial status.
      
 
      Discussion:
      
@@ -8164,7 +8222,7 @@ in the WP.
 
 
      
 
      526. Is it undefined if a function in the standard changes in parameters?
      
-
      Section: 23.1.1 [sequence.reqmts] Status: NAD
+
      Section: 23.1.3 [sequence.reqmts] Status: NAD
  Submitter: Chris Jefferson Date: 2005-09-14
      
 
      View all other issues in [sequence.reqmts].
      
 
      View all issues with NAD status.
      
@@ -8299,7 +8357,7 @@ doesn't give permission for it not to work.
 
    • list::remove(value) is required to work because the standard
 doesn't give permission for it not to work.
      • 
 
    • vector::insert(iter, iter, iter) is not required to work because
-23.1.1 [sequence.reqmts], p4 says so.
      • 
+23.1.3 [sequence.reqmts], p4 says so.
 
    • copy has to work, except where 25.2.1 [alg.copy] says
 it doesn't have to work.  While a language lawyer can tear this wording apart,
 it is felt that the wording is not prone to accidental interpretation.
      • 
@@ -8391,7 +8449,7 @@ chapter 17 wording.
 
 
      
 
      529. The standard encourages redundant and confusing preconditions
      
-
      Section: 17.4.3.9 [res.on.required] Status: NAD Editorial
+
      Section: 17.4.3.10 [res.on.required] Status: NAD Editorial
  Submitter: David Abrahams Date: 2005-10-25
      
 
      View all issues with NAD Editorial status.
      
 
      Discussion:
      
@@ -8485,7 +8543,7 @@ Alan provided the survey
 
 
      
 
      532. Tuple comparison
      
-
      Section: 20.3.1.6 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] Status: Pending NAD Editorial
+
      Section: 20.4.1.6 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] Status: Pending NAD Editorial
  Submitter: David Abrahams Date: 2005-11-29
      
 
      View all issues with Pending NAD Editorial status.
      
 
      Duplicate of: 348
      
@@ -8782,6 +8840,7 @@ Portland:  Subsumed by N2111.
 
      553. very minor editorial change intptr_t / uintptr_t
      
 
      Section: 18.3.1 [cstdint.syn], TR1 8.22.1 [tr.c99.cstdint.syn] Status: NAD Editorial
  Submitter: Paolo Carlini Date: 2006-01-30
      
+
      View all other issues in [cstdint.syn].
      
 
      View all issues with NAD Editorial status.
      
 
      Discussion:
      
 
      
@@ -8914,10 +8973,10 @@ 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
+
      Section: 18.3 [cstdint], TR1 8.22 [tr.c99.cstdint] Status: NAD Editorial
  Submitter: Paolo Carlini Date: 2006-02-06
      
 
      View all other issues in [cstdint].
      
-
      View all issues with Pending NAD Editorial status.
      
+
      View all issues with NAD Editorial status.
      
 
      Discussion:
      
 
      
 I'm seeing a problem with such overloads: when, _Longlong == intmax_t ==
@@ -9230,6 +9289,73 @@ committee meant.
 
 
 
      
+
      570. Request adding additional explicit specializations of char_traits
      
+
      Section: 21.1 [char.traits] Status: NAD
+ Submitter: Jack Reeves Date: 2006-04-06
      
+
      View all other issues in [char.traits].
      
+
      View all issues with NAD 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.
+]
      
+
+
+
      [
+post Bellevue:
+]
      
+
+
+
      
+
      
+We suggest that Jack be asked about the status of his paper, and if it
+is not forthcoming, the work-item be assigned to someone else. If no one
+steps forward to do the paper before the next meeting, we propose to
+make this NAD without further discussion. We leave this Open for now,
+but our recommendation is NAD.
+
      
+
      
+Note: the issue statement should be updated, as the Toronto comment has
+already been resolved. E.g., char_traits specializations for char16_t
+and char32_t are now in the working paper.
+
      
+
      
+
+
      [
+Sophia Antipolis:
+]
      
+
+
+
      
+Nobody has submitted the requested paper, so we move to NAD, as suggested by the decision at the last meeting.
+
      
+
+
+
      Proposed resolution:
      
+
+
+
+
+
+
      
 
      571. Update C90 references to C99?
      
 
      Section: 1.2 [intro.refs] Status: NAD Editorial
  Submitter: Beman Dawes Date: 2006-04-08
      
@@ -9303,8 +9429,9 @@ is adopted.
 
 
      
 
      579. erase(iterator) for unordered containers should not return an iterator
      
-
      Section: 23.1.3 [unord.req] Status: NAD
+
      Section: 23.1.5 [unord.req] Status: NAD
  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 NAD status.
      
 
      Discussion:
      
@@ -9392,7 +9519,6 @@ uses depend on the iterator being returned.
 
      583. div() for unsigned integral types
      
 
      Section: 26.7 [c.math] Status: NAD
  Submitter: Beman Dawes Date: 2006-06-15
      
-
      View other active issues in [c.math].
      
 
      View all other issues in [c.math].
      
 
      View all issues with NAD status.
      
 
      Discussion:
      
@@ -9431,7 +9557,6 @@ behavior and thus does not need this treatment.
 
      584. missing int pow(int,int) functionality
      
 
      Section: 26.7 [c.math] Status: NAD
  Submitter: Beman Dawes Date: 2006-06-15
      
-
      View other active issues in [c.math].
      
 
      View all other issues in [c.math].
      
 
      View all issues with NAD status.
      
 
      Discussion:
      
@@ -9493,7 +9618,7 @@ post Oxford: Noted that it is already fixed in
 
 
      
 
      590. Type traits implementation latitude should be removed for C++0x
      
-
      Section: 20.4 [meta], TR1 4.9 [tr.meta.req] Status: NAD Editorial
+
      Section: 20.5 [meta], TR1 4.9 [tr.meta.req] Status: NAD Editorial
  Submitter: Beman Dawes Date: 2006-08-10
      
 
      View all other issues in [meta].
      
 
      View all issues with NAD Editorial status.
      
@@ -9603,10 +9728,10 @@ Recommend NAD / Editorial.  The proposed resolution is accepted as editorial.
 
 
      
 
      592. Incorrect treatment of rdbuf()->close() return type
      
-
      Section: 27.8.1.9 [ifstream.members] Status: Pending NAD Editorial
+
      Section: 27.8.1.9 [ifstream.members] Status: NAD Editorial
  Submitter: Christopher Kohlhoff Date: 2006-08-17
      
 
      View all other issues in [ifstream.members].
      
-
      View all issues with Pending NAD Editorial status.
      
+
      View all issues with NAD Editorial status.
      
 
      Discussion:
      
 
      
 I just spotted a minor problem in 27.8.1.7
@@ -9959,6 +10084,12 @@ Bellevue:  Marked as NAD Editorial.
 ]
      
 
 
+
      [
+Post-Sophia Antipolis:  Martin indicates there is still work to be done on this issue.
+Reopened.
+]
      
+
+
 
 
 
      Proposed resolution:
      
@@ -10046,12 +10177,12 @@ its resource limits", so no further escape hatch is necessary.
 
 
      
 
      633. Return clause mentions undefined "type()"
      
-
      Section: 20.5.15.2.5 [func.wrap.func.targ] Status: NAD Editorial
+
      Section: 20.6.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:
+20.6.15.2.5 [func.wrap.func.targ], p4 says:
 
      
 
      
 Returns: If type() == typeid(T), a pointer to the stored
@@ -10067,7 +10198,7 @@ function type() in class template function nor in the global or
 
    • 
 Assuming that type should have been target_type(),
 this description would lead to false results, if T = cv
-void due to returns clause 20.5.15.2.5 [func.wrap.func.targ], p1.
+void due to returns clause 20.6.15.2.5 [func.wrap.func.targ], p1.
 
      • 
 
 
@@ -10075,7 +10206,7 @@ void due to returns clause 20.5.15.2.5 [func.wrap.func.targ], p1.
 
 
      Proposed resolution:
      
 
      
-Change 20.5.15.2.5 [func.wrap.func.targ], p4:
+Change 20.6.15.2.5 [func.wrap.func.targ], p4:
 
      
 
 
      
@@ -10127,7 +10258,6 @@ Pete recommends editorial fix.
 
      637. [c.math]/10 inconsistent return values
      
 
      Section: 26.7 [c.math] Status: NAD Editorial
  Submitter: Bo Persson Date: 2007-02-13
      
-
      View other active issues in [c.math].
      
 
      View all other issues in [c.math].
      
 
      View all issues with NAD Editorial status.
      
 
      Discussion:
      
@@ -10949,13 +11079,13 @@ unlikely to be better than what's already in the standard.
 
 
      
 
      658. Two unspecified function comparators in [function.objects]
      
-
      Section: 20.5 [function.objects] Status: NAD Editorial
+
      Section: 20.6 [function.objects] Status: NAD Editorial
  Submitter: Daniel Krügler Date: 2007-03-19
      
 
      View all other issues in [function.objects].
      
 
      View all issues with NAD Editorial status.
      
 
      Discussion:
      
 
      
-The header <functional> synopsis in 20.5 [function.objects]
+The header <functional> synopsis in 20.6 [function.objects]
 contains the following two free comparison operator templates
 for the function class template
 
      
@@ -10969,7 +11099,7 @@ void operator!=(const function<Function1>&, const function<Function
 
      
 which are nowhere described. I assume that they are relicts before the
 corresponding two private and undefined member templates in the function
-template (see 20.5.15.2 [func.wrap.func] and X [func.wrap.func.undef]) have been introduced. The original free
+template (see 20.6.15.2 [func.wrap.func] and X [func.wrap.func.undef]) have been introduced. The original free
 function templates should be removed, because using an undefined entity
 would lead to an ODR violation of the user.
 
      
@@ -10978,7 +11108,7 @@ would lead to an ODR violation of the user.
 
      Proposed resolution:
      
 
      
 Remove the above mentioned two function templates from
-the header <functional> synopsis (20.5 [function.objects])
+the header <functional> synopsis (20.6 [function.objects])
 
      
 
 
      template<class Function1, class Function2>
@@ -11328,13 +11458,13 @@ Bellevue:  Proposed wording now in WP.
 
 
      
 
      686. Unique_ptr and shared_ptr fail to specify non-convertibility to int for unspecified-bool-type
      
-
      Section: 20.6.11.2.4 [unique.ptr.single.observers], 20.6.12.2.5 [util.smartptr.shared.obs] Status: NAD
+
      Section: 20.7.11.2.4 [unique.ptr.single.observers], 20.7.12.2.5 [util.smartptr.shared.obs] Status: NAD
  Submitter: Beman Dawes Date: 2007-06-14
      
 
      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 
+five places. In three of those places (20.6.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
 
      
@@ -11362,8 +11492,8 @@ makes it irrelevant.
 
      
 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:
+of 20.7.11.2.4 [unique.ptr.single.observers] paragraph 11 and
+20.7.12.2.5 [util.smartptr.shared.obs] paragraph 16, add the sentence:
 
      
 
      
 The return type shall not be convertible to int.
@@ -11382,7 +11512,6 @@ 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:
      
@@ -11542,63 +11671,6 @@ implementation details.
 
 
 
      
-
      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
      
@@ -11660,7 +11732,7 @@ of that array ends, whichever happens first.
 
 
      
 
      725. Optional sequence container requirements column label
      
-
      Section: 23.1.1 [sequence.reqmts] Status: Pending NAD Editorial
+
      Section: 23.1.3 [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.
      
@@ -12025,6 +12097,7 @@ for the proposed resolution.
 
      736. Comment on [rand.dist.samp.discrete]
      
 
      Section: 26.4.8.5.1 [rand.dist.samp.discrete] Status: NAD
  Submitter: Stephan Tolksdorf Date: 2007-09-21
      
+
      View other active issues in [rand.dist.samp.discrete].
      
 
      View all other issues in [rand.dist.samp.discrete].
      
 
      View all issues with NAD status.
      
 
      Discussion:
      
@@ -12372,7 +12445,7 @@ for the proposed resolution.
 
 
      
 
      741. Const-incorrect get_deleter function for shared_ptr
      
-
      Section: 20.6.12.2.11 [util.smartptr.getdeleter] Status: NAD
+
      Section: 20.7.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.
      
@@ -12383,7 +12456,7 @@ The following issue was raised by Alf P. Steinbach in c.l.c++.mod:
 
 
      
 According to the recent draft N2369, both the header memory synopsis
-of 20.6 [memory] and 20.6.12.2.11 [util.smartptr.getdeleter] declare:
+of 20.7 [memory] and 20.7.12.2.11 [util.smartptr.getdeleter] declare:
 
      
 
 
      template<class D, class T> D* get_deleter(shared_ptr<T> const& p);
@@ -12398,7 +12471,7 @@ the mutability of the owner (as seen for the both overloads of
 unique_ptr::get_deleter).
 Even the next similar counter-part of get_deleter - the two
 overloads of function::target in the class template function
-synopsis 20.5.15.2 [func.wrap.func] or in 20.5.15.2.5 [func.wrap.func.targ] - do
+synopsis 20.6.15.2 [func.wrap.func] or in 20.6.15.2.5 [func.wrap.func.targ] - do
 properly mirror the const-state of the owner.
 
      
 
@@ -12406,7 +12479,7 @@ properly mirror the const-state of the owner.
 
 
      
 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
+synopsis of 20.7 [memory] and in 20.7.12.2.11 [util.smartptr.getdeleter] by one of the
 following alternatives (A) or (B):
 
      
 
@@ -12519,9 +12592,8 @@ slicing involved.
 
 
      
 
      748. The is_abstract type trait is defined by reference to 10.4.
      
-
      Section: 20.4.4.3 [meta.unary.prop] Status: NAD
+
      Section: 20.5.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:
      
@@ -12556,10 +12628,10 @@ Core has clarified that the definition abstract is adequate. Issue withdrawn by
 
 
      
 
      754. Ambiguous return clause for std::uninitialized_copy
      
-
      Section: 20.6.10.1 [uninitialized.copy] Status: Pending NAD Editorial
+
      Section: 20.7.10.1 [uninitialized.copy] Status: 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.
      
+
      View all issues with NAD Editorial status.
      
 
      Discussion:
      
 
      
 14882-2003, [lib.uninitialized.copy] is currently written as follows:
@@ -12586,7 +12658,7 @@ Core has clarified that the definition abstract is adequate. Issue withdrawn by
 
 
      
 similarily for N2369, and its corresponding section
-20.6.10.1 [uninitialized.copy].
+20.7.10.1 [uninitialized.copy].
 
      
 
 
      
@@ -12634,7 +12706,7 @@ for std::copy.
 
 
      Proposed resolution:
      
 
      
-Change the wording of the return clause to say (20.6.10.1 [uninitialized.copy]):
+Change the wording of the return clause to say (20.7.10.1 [uninitialized.copy]):
 
      
 
 
      
@@ -12659,11 +12731,107 @@ occur.
 
 
 
      
+
      756. Container adaptors push
      
+
      Section: 23.2.5 [container.adaptors] Status: NAD Editorial
+ Submitter: Paolo Carlini Date: 2007-10-31
      
+
      View all issues with NAD Editorial status.
      
+
      Discussion:
      
+
      
+After n2369 we have a single push_back overload in the sequence containers,
+of the "emplace" type. At variance with that, still in n2461, we have
+two separate overloads, the C++03 one + one taking an rvalue reference
+in the container adaptors. Therefore, simply from a consistency point of
+view, I was wondering whether the container adaptors should be aligned
+with the specifications of the sequence container themselves: thus have
+a single push along the lines:
+
      
+
+
      template<typename... _Args>
+void
+push(_Args&&... __args)
+  { c.push_back(std::forward<_Args>(__args)...); }
+
      
+
+
      [
+Related to 767
+]
      
+
+
+
+
      Proposed resolution:
      
+
      
+Change 23.2.5.1.1 [queue.defn]:
+
      
+
+
      void push(const value_type& x) { c.push_back(x); }
+void push(value_type&& x) { c.push_back(std::move(x)); }
+template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }
+
      
+
+
      
+Change 23.2.5.2 [priority.queue]:
+
      
+
+
      void push(const value_type& x) { c.push_back(x); }
+void push(value_type&& x) { c.push_back(std::move(x)); }
+template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }
+
      
+
+
      
+Change 23.2.5.2.2 [priqueue.members]:
+
      
+
+
      
+
      void push(const value_type& x);
+
      
+
      
+
      
+Effects:
+
      
+
      c.push_back(x);
+push_heap(c.begin(), c.end(), comp);
+
      
+
      
+
+
      template<class... Args> void push(value_type Args&&... x args);
+
      
+
      
+
      
+Effects:
+
      
+
      c.push_back(std::moveforward<Args>(x args)...);
+push_heap(c.begin(), c.end(), comp);
+
      
+
      
+
      
+
+
      
+Change 23.2.5.3.1 [stack.defn]:
+
      
+
+
      void push(const value_type& x) { c.push_back(x); }
+void push(value_type&& x) { c.push_back(std::move(x)); }
+template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }
+
      
+
+
+
+
      Rationale:
      
+
      
+Addressed by
+N2680 Proposed Wording for Placement Insert (Revision 1).
+
      
+
+
+
+
+
+
      
 
      757. Typo in the synopsis of vector
      
-
      Section: 23.2.6 [vector] Status: Pending NAD Editorial
+
      Section: 23.2.6 [vector] Status: NAD Editorial
  Submitter: Paolo Carlini Date: 2007-11-04
      
 
      View all other issues in [vector].
      
-
      View all issues with Pending NAD Editorial status.
      
+
      View all issues with NAD Editorial status.
      
 
      Discussion:
      
 
      
 In the synopsis 23.2.6 [vector], there is the signature:
@@ -12702,7 +12870,7 @@ void     insert(const_iterator position, size_type n, const T& x);
 
 
      
 
      763. Renaming emplace() overloads
      
-
      Section: 23.1.2 [associative.reqmts] Status: NAD
+
      Section: 23.1.4 [associative.reqmts] Status: NAD
  Submitter: Sylvain Pion Date: 2007-12-04
      
 
      View all other issues in [associative.reqmts].
      
 
      View all issues with NAD status.
      
@@ -12721,7 +12889,7 @@ a const_iterator as first argument.
 
      
 
 
      [
-Related to 767
+Related to 767
 ]
      
 
 
@@ -12754,8 +12922,9 @@ 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
+
      Section: 23.1.5 [unord.req] Status: NAD
  Submitter: Joe Gottman Date: 2007-11-29
      
+
      View other active issues in [unord.req].
      
 
      View all other issues in [unord.req].
      
 
      View all issues with NAD status.
      
 
      Discussion:
      
@@ -12812,7 +12981,7 @@ 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:
+Change the entry for equal_range in Table 93 (23.1.5 [unord.req]) as follows:
      @@ -12832,6 +13001,273 @@ Change the entry for equal_range in Table 93 (23.1.3 [unord.req]) as fo
      +

      767. Forwarding and backward compatibility

      +

      Section: 23 [containers] Status: NAD Editorial + Submitter: Sylvain Pion Date: 2007-12-28

      +

      View other active issues in [containers].

      +

      View all other issues in [containers].

      +

      View all issues with NAD Editorial status.

      +

      Discussion:

      +

      +Playing with g++'s C++0X mode, I noticed that the following +code, which used to compile: +

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

      +now fails with the following error message: +

      + +
      .../include/c++/4.3.0/ext/new_allocator.h: In member +function 'void __gnu_cxx::new_allocator<_Tp>::construct(_Tp*, +_Args&& ...) [with _Args = int, _Tp = char*]': +.../include/c++/4.3.0/bits/stl_vector.h:707: instantiated from 'void +std::vector<_Tp, _Alloc>::push_back(_Args&& ...) [with +_Args = int, _Tp = char*, _Alloc = std::allocator<char*>]' +test.cpp:6: instantiated from here +.../include/c++/4.3.0/ext/new_allocator.h:114: error: invalid +conversion from 'int' to 'char*' +
      + +

      +As far as I know, g++ follows the current draft here. +

      +

      +Does the committee really intend to break compatibility for such cases? +

      + +

      [ +Sylvain adds: +]

      + + +
      +

      +I just noticed that std::pair has the same issue. +The following now fails with GCC's -std=c++0x mode: +

      + +
      #include <utility>
+
+int main()
+{
+   std::pair<char *, char *> p (0,0);
+}
+
      + +

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

      +
      + +

      [ +Related to 756 +]

      + + +

      [ +Bellevue: +]

      + + +
      +

      +Motivation is to handle the old-style int-zero-valued NULL pointers. +Problem: this solution requires concepts in some cases, which some users +will be slow to adopt. Some discussion of alternatives involving +prohibiting variadic forms and additional library-implementation +complexity. +

      +

      +Discussion of "perfect world" solutions, the only such solution put +forward being to retroactively prohibit use of the integer zero for a +NULL pointer. This approach was deemed unacceptable given the large +bodies of pre-existing code that do use integer zero for a NULL pointer. +

      +

      +Another approach is to change the member names. Yet another approach is +to forbid the extension in absence of concepts. +

      +

      +Resolution: These issues (756, 767, 760, 763) will be subsumed into a +paper to be produced by Alan Talbot in time for review at the 2008 +meeting in France. Once this paper is produced, these issues will be +moved to NAD. +

      +
      + + + +

      Proposed resolution:

      +

      +Add the following rows to Table 90 "Optional sequence container operations", 23.1.3 [sequence.reqmts]: +

      + +
      +
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      expression return type assertion/note
      pre-/post-condition      		 container
      +a.push_front(t) + +void + +a.insert(a.begin(), t)
      +Requires: T shall be CopyConstructible. +      		 +list, deque +
      +a.push_front(rv) + +void + +a.insert(a.begin(), rv)
      +Requires: T shall be MoveConstructible. +      		 +list, deque +
      +a.push_back(t) + +void + +a.insert(a.end(), t)
      +Requires: T shall be CopyConstructible. +      		 +list, deque, vector, basic_string +
      +a.push_back(rv) + +void + +a.insert(a.end(), rv)
      +Requires: T shall be MoveConstructible. +      		 +list, deque, vector, basic_string +
      +
      + +

      +Change the synopsis in 23.2.2 [deque]: +

      + +
      void push_front(const T& x);
+void push_front(T&& x);
+void push_back(const T& x);
+void push_back(T&& x);
+template <class... Args> requires Constructible<T, Args&&...> void push_front(Args&&... args);
+template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
+
      + +

      +Change 23.2.2.3 [deque.modifiers]: +

      + +
      void push_front(const T& x);
+void push_front(T&& x);
+void push_back(const T& x);
+void push_back(T&& x);
+template <class... Args> requires Constructible<T, Args&&...> void push_front(Args&&... args);
+template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
+
      + +

      +Change the synopsis in 23.2.4 [list]: +

      + +
      void push_front(const T& x);
+void push_front(T&& x);
+void push_back(const T& x);
+void push_back(T&& x);
+template <class... Args> requires Constructible<T, Args&&...> void push_front(Args&&... args);
+template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
+
      + +

      +Change 23.2.4.3 [list.modifiers]: +

      + +
      void push_front(const T& x);
+void push_front(T&& x);
+void push_back(const T& x);
+void push_back(T&& x);
+template <class... Args> requires Constructible<T, Args&&...> void push_front(Args&&... args);
+template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
+
      + +

      +Change the synopsis in 23.2.6 [vector]: +

      + +
      void push_back(const T& x);
+void push_back(T&& x);
+template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
+
      + +

      +Change 23.2.6.4 [vector.modifiers]: +

      + +
      void push_back(const T& x);
+void push_back(T&& x);
+template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
+
      + + + + +

      Rationale:

      +

      +Addressed by +N2680 Proposed Wording for Placement Insert (Revision 1). +

      + +

      +If there is still an issue with pair, Howard should submit another issue. +

      + + + + + +

      773. issues with random

      Section: 26.4.8.1 [rand.dist.uni] Status: NAD Submitter: P.J. Plauger Date: 2008-01-14

      @@ -12949,6 +13385,132 @@ Change 30.3.3.2.3 [thread.lock.unique.mod]:
      +

      786. Thread library timed waits, UTC and monotonic clocks

      +

      Section: X [datetime.system] Status: NAD Editorial + Submitter: Christopher Kohlhoff, Jeff Garland Date: 2008-02-03

      +

      View all issues with NAD Editorial status.

      +

      Discussion:

      +

      +The draft C++0x thread library requires that the time points of type +system_time and returned by get_system_time() represent Coordinated +Universal Time (UTC) (section X [datetime.system]). This can lead to +surprising behavior when a library user performs a duration-based wait, +such as condition_variable::timed_wait(). A complete explanation of the +problem may be found in the +Rationale for the Monotonic Clock +section in POSIX, but in summary: +

      + +
        +
      • +Operations such as condition_variable::timed_wait() (and its POSIX +equivalent, pthread_cond_timedwait()) are specified using absolute times +to address the problem of spurious wakeups. +
        • + +
      • +The typical use of the timed wait operations is to perform a relative +wait. This may be achieved by first calculating an absolute time as the +sum of the current time and the desired duration. In fact, the C++0x +thread library includes duration-based overloads of +condition_variable::timed_wait() that behave as if by calling the +corresponding absolute time overload with a time point value of +get_system_time() + rel_time. +
        • + +
      • +A UTC clock may be affected by changes to the system time, such as +synchronization with an external source, leap seconds, or manual changes +to the clock. +
        • + +
      • +Should the clock change during a timed wait operation, the actual +duration of the wait will not be the expected length. For example, a +user may intend a timed wait of one second duration but, due to an +adjustment of the system clock backwards by a minute, the wait instead +takes 61 seconds. +
        • +
      + +

      +POSIX solves the problem by introducing a new monotonic clock, which is +unaffected by changes to the system time. When a condition variable is +initialized, the user may specify whether the monotonic clock is to be +used. (It is worth noting that on POSIX systems it is not possible to +use condition_variable::native_handle() to access this facility, since +the desired clock type must be specified during construction of the +condition variable object.) +

      + +

      +In the context of the C++0x thread library, there are added dimensions +to the problem due to the need to support platforms other than POSIX: +

      + +
        +
      • +Some environments (such as embedded systems) do not have a UTC clock, but do have a monotonic clock. +
        • + +
      • +Some environments do not have a monotonic clock, but do have a UTC clock. +
        • + +
      • +The Microsoft Windows API's synchronization functions use relative +timeouts based on an implied monotonic clock. A program that switches +from the Windows API to the C++0x thread library will now find itself +susceptible to clock changes. +
        • +
      + +

      +One possible minimal solution: +

      + +
        +
      • +Strike normative references to UTC and an epoch based on 1970-01-01. +
        • + +
      • +Make the semantics of system_time and get_system_time() +implementation-defined (i.e standard library implementors may choose the +appropriate underlying clock based on the capabilities of the target +platform). +
        • + +
      • +Add a non-normative note encouraging use of a monotonic clock. +
        • + +
      • +Remove system_time::seconds_since_epoch(). +
        • + +
      • +Change the constructor explicit system_time(time_t secs, nanoseconds ns += 0) to explicit system_time(nanoseconds ns). +
        • +
      + + + +

      Proposed resolution:

      +

      +

      + + +

      Rationale:

      +Addressed by +N2661: A Foundation to Sleep On. + + + + + +

      790. xor_combine::seed not specified

      Section: 26.4.4.4 [rand.adapt.xor] Status: NAD Submitter: P.J. Plauger Date: 2008-02-09

      @@ -12967,7 +13529,7 @@ Bellevue:
      -Overcome by the previous proposal. NAD mooted by resolution of 789. +Overcome by the previous proposal. NAD mooted by resolution of 789.
      @@ -13306,5 +13868,149 @@ Bellevue: Submitter withdraws defect. "We got the wrong value for entirely the r +
      +

      826. Equivalent of %'d, or rather, lack thereof?

      +

      Section: 22.2.2.2 [locale.nm.put] Status: NAD + Submitter: Peter Dimov Date: 2008-04-07

      +

      View all issues with NAD status.

      +

      Discussion:

      +

      +In the spirit of printf vs iostream... +

      + +

      +POSIX printf says that %'d should insert grouping characters (and the +implication is that in the absence of ' no grouping characters are +inserted). The num_put facet, on the other hand, seems to always insert +grouping characters. Can this be considered a defect worth fixing for +C++0x? Maybe ios_base needs an additional flag? +

      + +

      [ +Pablo Halpern: +]

      + + +
      +I'm not sure it constitutes a defect, but I would be in favor of adding +another flag (and corresponding manipulator). +
      + +

      [ +Martin Sebor: +]

      + + +
      +I don't know if it qualifies as a defect but I agree that there +should be an easy way to control whether the thousands separator +should or shouldn't be inserted. A new flag would be in line with +the current design of iostreams (like boolalpha, showpos, or +showbase). +
      + +

      [ +Sophia Antipolis: +]

      + + +
      +This is not a part of C99. LWG suggests submitting a paper may be appropriate. +
      + + + +

      Proposed resolution:

      +

      +

      + + + + + +
      +

      831. wrong type for not_eof()

      +

      Section: 21.1.3 [char.traits.specializations] Status: NAD Editorial + Submitter: Dietmar Kühl Date: 2008-04-23

      +

      View all other issues in [char.traits.specializations].

      +

      View all issues with NAD Editorial status.

      +

      Discussion:

      +

      + In Table 56 (Traits requirements) the not_eof() member function + is using an argument of type e which denotes an object of + type X::int_type. However, the specializations in + 21.1.3 [char.traits.specializations] all use char_type. + This would effectively mean that the argument type actually can't + represent EOF in the first place. I'm pretty sure that the type used + to be int_type which is quite obviously the only sensible + argument. +

      +

      + This issue is close to being editorial. I suspect that the proposal + changing this section to include the specializations for char16_t + and char32_t accidentally used the wrong type. +

      + + +

      Proposed resolution:

      +

      + In 21.1.3.1 [char.traits.specializations.char], + 21.1.3.2 [char.traits.specializations.char16_t], + 21.1.3.3 [char.traits.specializations.char32_t], and + [char.traits.specializations.wchar_t] correct the + argument type from char_type to int_type. +

      + + +

      Rationale:

      +Already fixed in WP. + + + + + +
      +

      840. pair default template argument

      +

      Section: 20.2.3 [pairs] Status: NAD + Submitter: Thorsten Ottosen Date: 2008-05-23

      +

      View all other issues in [pairs].

      +

      View all issues with NAD status.

      +

      Discussion:

      +

      +I have one issue with std::pair. Well, it might just be a very annoying +historical accident, but why is there no default template argument for +the second template argument? This is so annoying when the type in +question is looong and hard to write (type deduction with auto won't +help those cases where we use it as a return or argument type). +

      + + +

      Proposed resolution:

      +

      +Change the synopsis in 20.2 [utility] to read: +

      + +
      template <class T1, class T2 = T1> struct pair;
+
      + +

      +Change 20.2.3 [pairs] to read: +

      + +
      namespace std {
+ template <class T1, class T2 = T1>
+ struct pair {
+   typedef T1 first_type;
+   typedef T2 second_type;
+   ...
+
      + + +

      Rationale:

      +std::pair is a heterogeneous container. + + + + \ 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 0133503..5951a98 100644 --- a/libstdc++-v3/doc/html/ext/lwg-defects.html +++ b/libstdc++-v3/doc/html/ext/lwg-defects.html @@ -1,22 +1,24 @@ -C++ Standard Library Defect Report List - + + +C++ Standard Library Defect Report List + + - + - + @@ -27,7 +29,7 @@ del {background-color:#FFA0A0}
      Doc. no.N2613=08-0123N2728=08-0238
      Date:2008-05-182008-08-24
      Project:Howard Hinnant <howard.hinnant@gmail.com>
      -

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

      +

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

      Reference ISO/IEC IS 14882:1998(E)

      Also see:

      @@ -49,6 +51,67 @@ del {background-color:#FFA0A0}

      Revision History

        +
      • R59: +2008-08-22 pre-San Francisco mailing. +
          +
        • Summary:
            +
          • 192 open issues, up by 9.
            • +
          • 686 closed issues, up by 0.
            • +
          • 878 issues total, up by 9.
            • +
          • +
        • Details:
          • +
        +
        • +
      • R58: +2008-07-28 mid-term mailing. +
          +
        • Summary:
            +
          • 183 open issues, up by 12.
            • +
          • 686 closed issues, down by 4.
            • +
          • 869 issues total, up by 8.
            • +
          • +
        • Details:
            +
          • Added the following New issues: 862, 863, 864, 865, 866, 867, 868, 869.
            • +
          • Changed the following issues from Pending NAD Editorial to NAD Editorial: 393, 557, 592, 754, 757.
            • +
          • Changed the following issues from Pending WP to Open: 644.
            • +
          • Changed the following issues from WP to Ready: 387, 629.
            • +
          • Changed the following issues from Pending NAD Editorial to Review: 709.
            • +
          • +
        +
        • +
      • R57: +2008-06-27 post-Sophia Antipolis mailing. + +
      • R56: 2008-05-16 pre-Sophia Antipolis mailing.
          @@ -58,7 +121,7 @@ del {background-color:#FFA0A0}
        • 838 issues total, up by 25.
      • Details:
      @@ -76,7 +139,7 @@ del {background-color:#FFA0A0}
    • Added the following NAD issues: 790, 791, 796, 797, 799.
    • Added the following New issues: 788, 794, 802, 804, 805, 806, 807, 808, 809, 810, 811, 812, 813.
    • Added the following Open issues: 793, 800, 801, 803.
      • -
    • Added the following Ready issues: 789, 792, 798.
      • +
    • Added the following Ready issues: 789, 792, 798.
    • Changed the following issues from NAD Future to Dup: 116.
    • Changed the following issues from NAD Future to NAD: 188, 323.
    • Changed the following issues from New to NAD: 729, 730, 731, 733, 735, 736, 737, 739, 741, 745, 748, 763, 764, 773, 784.
      • @@ -85,13 +148,13 @@ del {background-color:#FFA0A0}
    • Changed the following issues from Open to NAD Editorial: 529, 626.
    • Changed the following issues from Review to NAD Editorial: 645, 684.
    • Changed the following issues from NAD Future to Open: 128, 180, 190.
      • -
    • Changed the following issues from New to Open: 617, 718, 719, 720, 724, 732, 734, 742, 747, 750, 753, 756, 760, 762, 767, 774.
      • +
    • Changed the following issues from New to Open: 617, 718, 719, 720, 724, 732, 734, 742, 747, 750, 753, 756, 760, 762, 767, 774.
    • Changed the following issues from Ready to Open: 675, 676, 688.
      • -
    • Changed the following issues from New to Pending NAD Editorial: 709, 717, 725, 738, 754, 757.
      • +
    • Changed the following issues from New to Pending NAD Editorial: 709, 717, 725, 738, 754, 757.
    • Changed the following issues from Open to Pending NAD Editorial: 424, 557, 625.
      • -
    • Changed the following issues from New to Ready: 710, 715, 722, 740, 743, 744, 746, 749, 755, 758, 759, 761, 766, 768, 770, 775, 777, 778, 781, 782, 783.
      • -
    • Changed the following issues from Open to Ready: 387, 471, 550, 612, 629, 673.
      • -
    • Changed the following issues from Review to Ready: 518, 574, 596, 618, 638, 672, 685.
      • +
    • Changed the following issues from New to Ready: 710, 715, 722, 740, 743, 744, 746, 749, 755, 758, 759, 761, 766, 768, 770, 775, 777, 778, 781, 782, 783.
      • +
    • Changed the following issues from Open to Ready: 387, 471, 550, 612, 629, 673.
      • +
    • Changed the following issues from Review to Ready: 518, 574, 596, 618, 638, 672, 685.
    • Changed the following issues from New to Review: 711, 728, 771, 776.
    • Changed the following issues from Open to Review: 539.
    • Changed the following issues from Ready to WP: 561, 562, 563, 567, 581, 620, 621, 622, 623, 624, 661, 664, 665, 666, 674, 679, 680, 687, 689, 693, 694, 695, 700, 703, 705, 706.
      • @@ -108,7 +171,7 @@ del {background-color:#FFA0A0}
    • 787 issues total, up by 23.
  • Details:
  • Details:
    • @@ -141,16 +204,16 @@ del {background-color:#FFA0A0}
  • 754 issues total, up by 31.
  • Details:
  • Details:
    • @@ -187,10 +250,10 @@ del {background-color:#FFA0A0}
  • 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 Pending WP to Open: 258.
    • -
  • Changed the following issues from Ready to Pending WP: 644.
    • +
  • Changed the following issues from Ready to Pending WP: 644.
  • Changed the following issues from New to Ready: 577, 660.
  • Changed the following issues from Open to Ready: 488.
    • -
  • Changed the following issues from Open to Review: 518.
    • +
  • Changed the following issues from Open to Review: 518.
  • Changed the following issues from Ready to TRDec: 604.
  • Changed the following issues from DR to WP: 453.
  • Changed the following issues from Ready to WP: 531, 551, 566, 628, 640, 643, 646.
    • @@ -206,7 +269,7 @@ del {background-color:#FFA0A0}
  • 696 issues total, up by 20.
  • Details:
  • Details:
  • Details:
    • -

    Option B. Add three new sentences to 23.1.2 [associative.reqmts]:

    +

    Option B. Add three new sentences to 23.1.4 [associative.reqmts]:

    At the end of paragraph 5: "Keys in an associative container @@ -4144,7 +4207,7 @@ first sentence, and before "In addition,...", add one line: type."

    -

    Option C. To 23.1.2 [associative.reqmts], paragraph 3, which +

    Option C. To 23.1.4 [associative.reqmts], paragraph 3, which currently reads:

    @@ -4170,7 +4233,7 @@ currently reads:

    Proposed resolution:

    -

    Add the following to 23.1.2 [associative.reqmts] at +

    Add the following to 23.1.4 [associative.reqmts] at the indicated location:

    @@ -4717,12 +4780,12 @@ operator>>(int& val);

    119. Should virtual functions be allowed to strengthen the exception specification?

    -

    Section: 17.4.4.8 [res.on.exception.handling] Status: TC +

    Section: 17.4.4.9 [res.on.exception.handling] Status: TC Submitter: Judy Ward Date: 1998-12-15

    View all other issues in [res.on.exception.handling].

    View all issues with TC status.

    Discussion:

    -

    Section 17.4.4.8 [res.on.exception.handling] states:

    +

    Section 17.4.4.9 [res.on.exception.handling] states:

    "An implementation may strengthen the exception-specification for a function by removing listed exceptions."

    @@ -4746,7 +4809,7 @@ public:

    Proposed resolution:

    -

    Change Section 17.4.4.8 [res.on.exception.handling] from:

    +

    Change Section 17.4.4.9 [res.on.exception.handling] from:

         "may strengthen the exception-specification for a function"

    @@ -5156,7 +5219,7 @@ object parameter may be bound to an rvalue [13.3.3.1.4/3]

    Tokyo: The LWG removed the following from the proposed resolution:

    -

    In 20.4.4 [meta.unary], paragraph 2, and 20.4.4.3 [meta.unary.prop], +

    In 20.5.4 [meta.unary], paragraph 2, and 20.5.4.3 [meta.unary.prop], paragraph 2, make the conversion to auto_ptr_ref const:

    template<class Y> operator auto_ptr_ref<Y>() const throw();
    @@ -5164,17 +5227,17 @@ object parameter may be bound to an rvalue [13.3.3.1.4/3]

    Proposed resolution:

    -

    In 20.4.4 [meta.unary], paragraph 2, move +

    In 20.5.4 [meta.unary], paragraph 2, move the auto_ptr_ref definition to namespace scope.

    -

    In 20.4.4 [meta.unary], paragraph 2, add +

    In 20.5.4 [meta.unary], paragraph 2, add a public assignment operator to the auto_ptr definition: 

    auto_ptr& operator=(auto_ptr_ref<X> r) throw();
    -

    Also add the assignment operator to 20.4.4.3 [meta.unary.prop]:

    +

    Also add the assignment operator to 20.5.4.3 [meta.unary.prop]: 

    auto_ptr& operator=(auto_ptr_ref<X> r) throw()
    @@ -5227,7 +5290,7 @@ stream state in case of failure.

    130. Return type of container::erase(iterator) differs for associative containers

    -

    Section: 23.1.2 [associative.reqmts], 23.1.1 [sequence.reqmts] Status: DR +

    Section: 23.1.4 [associative.reqmts], 23.1.3 [sequence.reqmts] Status: DR Submitter: Andrew Koenig Date: 1999-03-02

    View all other issues in [associative.reqmts].

    View all issues with DR status.

    @@ -5244,7 +5307,7 @@ fail to meet the requirements for containers.

    Proposed resolution:

    -In 23.1.2 [associative.reqmts], in Table 69 Associative container +In 23.1.4 [associative.reqmts], in Table 69 Associative container requirements, change the return type of a.erase(q) from void to iterator. Change the assertion/not/pre/post-condition from "erases the element pointed to @@ -5255,7 +5318,7 @@ is returned."

    -In 23.1.2 [associative.reqmts], in Table 69 Associative container +In 23.1.4 [associative.reqmts], in Table 69 Associative container requirements, change the return type of a.erase(q1, q2) from void to iterator. Change the assertion/not/pre/post-condition from "erases the elements in the @@ -5518,7 +5581,7 @@ in the standard.

    139. Optional sequence operation table description unclear

    -

    Section: 23.1.1 [sequence.reqmts] Status: TC +

    Section: 23.1.3 [sequence.reqmts] Status: TC Submitter: Andrew Koenig Date: 1999-03-30

    View all other issues in [sequence.reqmts].

    View all issues with TC status.

    @@ -5855,7 +5918,7 @@ two places:

    150. Find_first_of says integer instead of iterator

    -

    Section: 25.1.4 [alg.find.first.of] Status: TC +

    Section: 25.1.7 [alg.find.first.of] Status: TC Submitter: Matt McClure Date: 1999-06-30

    View all other issues in [alg.find.first.of].

    View all issues with TC status.

    @@ -5863,7 +5926,7 @@ two places:

    Proposed resolution:

    -

    Change 25.1.4 [alg.find.first.of] paragraph 2 from:

    +

    Change 25.1.7 [alg.find.first.of] paragraph 2 from:

    Returns: The first iterator i in the range [first1, last1) such @@ -5882,7 +5945,7 @@ that for some iterator j in the range [first2, last2) ...

    151. Can't currently clear() empty container

    -

    Section: 23.1.1 [sequence.reqmts] Status: TC +

    Section: 23.1.3 [sequence.reqmts] Status: TC Submitter: Ed Brey Date: 1999-06-21

    View all other issues in [sequence.reqmts].

    View all issues with TC status.

    @@ -7263,12 +7326,12 @@ Josuttis provided the above wording.]

    185. Questionable use of term "inline"

    -

    Section: 20.5 [function.objects] Status: WP +

    Section: 20.6 [function.objects] Status: WP Submitter: UK Panel Date: 1999-07-26

    View all other issues in [function.objects].

    View all issues with WP status.

    Discussion:

    -

    Paragraph 4 of 20.5 [function.objects] says:

    +

    Paragraph 4 of 20.6 [function.objects] says:

     [Example: To negate every element of a: transform(a.begin(), a.end(), a.begin(), negate<double>()); The corresponding functions will inline @@ -7295,17 +7358,17 @@ not required elsewhere.

    Proposed resolution:

    -

    In 20.5 [function.objects] paragraph 1, remove the sentence:

    +

    In 20.6 [function.objects] paragraph 1, remove the sentence:

    They are important for the effective use of the library.

    -

    Remove 20.5 [function.objects] paragraph 2, which reads:

    +

    Remove 20.6 [function.objects] paragraph 2, which reads:

    Using function objects together with function templates increases the expressive power of the library as well as making the resulting code much more efficient.

    -

    In 20.5 [function.objects] paragraph 4, remove the sentence:

    +

    In 20.6 [function.objects] paragraph 4, remove the sentence:

    The corresponding functions will inline the addition and the negation.

    @@ -8461,7 +8524,6 @@ 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:

    @@ -8760,7 +8822,7 @@ footnote.

    224. clear() complexity for associative containers refers to undefined N

    -

    Section: 23.1.2 [associative.reqmts] Status: TC +

    Section: 23.1.4 [associative.reqmts] Status: TC Submitter: Ed Brey Date: 2000-03-23

    View all other issues in [associative.reqmts].

    View all issues with TC status.

    @@ -9401,7 +9463,7 @@ change "T is Assignable" to "T is CopyConstructible and Assignable"

    -

    In 23.1.2 [associative.reqmts] table 69 X::key_type; change +

    In 23.1.4 [associative.reqmts] table 69 X::key_type; change "Key is Assignable" to "Key is CopyConstructible and Assignable"

    @@ -9585,7 +9647,7 @@ rationale.]

    233. Insertion hints in associative containers

    -

    Section: 23.1.2 [associative.reqmts] Status: WP +

    Section: 23.1.4 [associative.reqmts] Status: WP Submitter: Andrew Koenig Date: 2000-04-30

    View all other issues in [associative.reqmts].

    View all issues with WP status.

    @@ -9693,7 +9755,7 @@ is no longer needed (or reflected in the proposed wording below).

    Change the indicated rows of the "Associative container requirements" Table in -23.1.2 [associative.reqmts] to: +23.1.4 [associative.reqmts] to:

    @@ -9736,7 +9798,7 @@ logarithmic in general, but amortized constant if t is inserted right <

    234. Typos in allocator definition

    -

    Section: 20.6.5.1 [allocator.members] Status: WP +

    Section: 20.7.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.

    @@ -9888,7 +9950,7 @@ applications of the corresponding predicate.

    240. Complexity of adjacent_find() is meaningless

    -

    Section: 25.1.5 [alg.adjacent.find] Status: WP +

    Section: 25.1.8 [alg.adjacent.find] Status: WP Submitter: Angelika Langer Date: 2000-05-15

    View all issues with WP status.

    Discussion:

    @@ -9928,7 +9990,7 @@ an "as-if" specification.

    Proposed resolution:

    -

    Change the complexity section in 25.1.5 [alg.adjacent.find] to:

    +

    Change the complexity section in 25.1.8 [alg.adjacent.find] to:

    For a nonempty range, exactly min((i - first) + 1, (last - first) - 1) applications of the @@ -10519,6 +10581,7 @@ 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:

    @@ -11471,7 +11534,7 @@ Change the following sentence in 21.3 paragraph 5 from

    264. Associative container insert(i, j) complexity requirements are not feasible.

    -

    Section: 23.1.2 [associative.reqmts] Status: WP +

    Section: 23.1.4 [associative.reqmts] Status: WP Submitter: John Potter Date: 2000-09-07

    View all other issues in [associative.reqmts].

    View all issues with WP status.

    @@ -12425,7 +12488,6 @@ 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

    @@ -12675,11 +12737,11 @@ imposing a greater restriction that what the standard currently says

    284. unportable example in 20.3.7, p6

    -

    Section: 20.5.7 [comparisons] Status: WP +

    Section: 20.6.7 [comparisons] Status: WP Submitter: Martin Sebor Date: 2000-12-26

    View all issues with WP status.

    Discussion:

    -

    The example in 20.5.7 [comparisons], p6 shows how to use the C +

    The example in 20.6.7 [comparisons], p6 shows how to use the C library function strcmp() with the function pointer adapter ptr_fun(). But since it's unspecified whether the C library functions have extern "C" or extern @@ -12691,7 +12753,7 @@ well-formed is unspecified.

    Proposed resolution:

    -

    Change 20.5.7 [comparisons] paragraph 6 from:

    +

    Change 20.6.7 [comparisons] paragraph 6 from:

    [Example:

        replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++");
@@ -13035,7 +13097,6 @@ it isn't stringent enough.
    
 
    295. Is abs defined in <cmath>?
    
 
    Section: 26.7 [c.math] Status: WP
  Submitter: Jens Maurer Date: 2001-01-12
    
-
    View other active issues in [c.math].
    
 
    View all other issues in [c.math].
    
 
    View all issues with WP status.
    
 
    Discussion:
    
@@ -13072,7 +13133,7 @@ putting in <cstdlib>.  That's issue 297. const_mem_fun_t<>::argument_type should be const T*
-
    Section: 20.5.8 [logical.operations] Status: WP
+
    Section: 20.6.8 [logical.operations] Status: WP
  Submitter: Martin Sebor Date: 2001-01-06
    
 
    View all issues with WP status.
    
 
    Discussion:
    
@@ -14044,7 +14105,7 @@ comment in c++std-lib-8939.
 
    Discussion:
    
 
    Table 27 in section 20 lists the header <memory> (only) for
 Memory (lib.memory) but neglects to mention the headers
-<cstdlib> and <cstring> that are discussed in 20.4.5 [meta.rel].
    
+<cstdlib> and <cstring> that are discussed in 20.5.5 [meta.rel].
    
 
 
 
    Proposed resolution:
    
@@ -14084,7 +14145,7 @@ Change the "range" from (last - first) to [first, last).
 
 
    
 
    316. Vague text in Table 69
    
-
    Section: 23.1.2 [associative.reqmts] Status: WP
+
    Section: 23.1.4 [associative.reqmts] Status: WP
  Submitter: Martin Sebor Date: 2001-05-04
    
 
    View all other issues in [associative.reqmts].
    
 
    View all issues with WP status.
    
@@ -14306,7 +14367,7 @@ Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't.
 
    Effects: Replaces the contents of the list with the range [first, last).
    -

    In 23.1.1 [sequence.reqmts], in Table 67 (sequence requirements), +

    In 23.1.3 [sequence.reqmts], in Table 67 (sequence requirements), add two new rows:

          a.assign(i,j)     void      pre: i,j are not iterators into a.
                                   Replaces elements in a with a copy
@@ -14791,7 +14852,7 @@ reallocation guarantees was inadvertant.
    
 
    View all issues with WP status.
    
 
    Discussion:
    
 
    
-With the change in 17.4.4.8 [res.on.exception.handling] to state
+With the change in 17.4.4.9 [res.on.exception.handling] to state
    "An implementation may strengthen the exception-specification for a 
     non-virtual function by removing listed exceptions."
 (issue 119)
@@ -15093,7 +15154,7 @@ library (though a deprecated one).
    
 
  • 17.4.1.2 [headers] Headers/4
    • 
 
  • 17.4.3.5 [replacement.functions] Replacement functions/1
    • 
 
  • 17.4.4.3 [global.functions] Global or non-member functions/2
    • 
-
  • 17.4.4.6 [protection.within.classes] Protection within classes/1
    • 
+
  • 17.4.4.7 [protection.within.classes] Protection within classes/1
    • 
 
 
 
@@ -15687,7 +15748,7 @@ be considered NAD.
    
 
 
    
 
    354. Associative container lower/upper bound requirements
    
-
    Section: 23.1.2 [associative.reqmts] Status: WP
+
    Section: 23.1.4 [associative.reqmts] Status: WP
  Submitter: Hans Aberg Date: 2001-12-17
    
 
    View all other issues in [associative.reqmts].
    
 
    View all issues with WP status.
    
@@ -15727,7 +15788,7 @@ the intention (and not possible with the "const" versions).
 
 
    Proposed resolution:
    
 
-
    Change Table 69 of section 23.1.2 [associative.reqmts] indicated entries
+
    Change Table 69 of section 23.1.4 [associative.reqmts] indicated entries
 to:
    
 
 
    
@@ -15753,7 +15814,7 @@ key greater than k, or a.end() if such an element is not found.
 
 
    
 
    355. Operational semantics for a.back()
    
-
    Section: 23.1.1 [sequence.reqmts] Status: WP
+
    Section: 23.1.3 [sequence.reqmts] Status: WP
  Submitter: Yaroslav Mironov Date: 2002-01-23
    
 
    View all other issues in [sequence.reqmts].
    
 
    View all issues with WP status.
    
@@ -16453,7 +16514,7 @@ erase_if() member function that much greater.
 
 
    Proposed resolution:
    
 
-
    Add the following to the end of 23.1.2 [associative.reqmts] paragraph 4: 
+
    Add the following to the end of 23.1.4 [associative.reqmts] paragraph 4: 
 "For multiset and multimap, insertand erase
   are stable: they preserve the relative ordering of equivalent
   elements.
     
@@ -17052,7 +17113,6 @@ const in the header file synopsis in section 22.1 [locales].
 
    395. inconsistencies in the definitions of rand() and random_shuffle()
    
 
    Section: 26.7 [c.math] Status: WP
  Submitter: James Kanze Date: 2003-01-03
    
-
    View other active issues in [c.math].
    
 
    View all other issues in [c.math].
    
 
    View all issues with WP status.
    
 
    Discussion:
    
@@ -17105,13 +17165,13 @@ implementation is permitted to use rand.]
 
 
    
 
    400. redundant type cast in lib.allocator.members
    
-
    Section: 20.6.5.1 [allocator.members] Status: WP
+
    Section: 20.7.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.5.1 [allocator.members] allocator members, contains
+20.7.5.1 [allocator.members] allocator members, contains
 the following 3 lines:
 
    
 
@@ -17223,7 +17283,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.5.1 [allocator.members] Status: WP
+
    Section: 20.1.2 [allocator.requirements], 20.7.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].
    
@@ -17231,13 +17291,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.5.1 [allocator.members] and in par2 (table 32) of  [default.con.req].
+20.7.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.5.1 [allocator.members]  contains the following 3 lines:
    
+
    20.7.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);
@@ -18094,7 +18154,7 @@ use the right wording.]
    
 
 
    
 
    425. return value of std::get_temporary_buffer
    
-
    Section: 20.6.8 [temporary.buffer] Status: WP
+
    Section: 20.7.8 [temporary.buffer] Status: WP
  Submitter: Martin Sebor Date: 2003-09-18
    
 
    View all issues with WP status.
    
 
    Discussion:
    
@@ -18109,7 +18169,7 @@ is when the argument is less than 0.
 
 
 
    Proposed resolution:
    
-
    Change 20.4.3 [meta.help] paragraph 2 from "...or a pair of 0
+
    Change 20.5.3 [meta.help] paragraph 2 from "...or a pair of 0
 values if no storage can be obtained" to "...or a pair of 0 values if
 no storage can be obtained or if n <= 0."
    
 
    [Kona: Matt provided wording]
    
@@ -18120,7 +18180,7 @@ no storage can be obtained or if n <= 0."
    
 
 
    
 
    426. search_n(), fill_n(), and generate_n() with negative n
    
-
    Section: 25.1.9 [alg.search], 25.2.6 [alg.fill], 25.2.7 [alg.generate] Status: WP
+
    Section: 25.1.12 [alg.search], 25.2.6 [alg.fill], 25.2.7 [alg.generate] Status: WP
  Submitter: Martin Sebor Date: 2003-09-18
    
 
    View all other issues in [alg.search].
    
 
    View all issues with WP status.
    
@@ -18677,13 +18737,13 @@ text.]
    
 
 
    
 
    438. Ambiguity in the "do the right thing" clause
    
-
    Section: 23.1.1 [sequence.reqmts] Status: DR
+
    Section: 23.1.3 [sequence.reqmts] Status: DR
  Submitter: Howard Hinnant Date: 2003-10-20
    
 
    View all other issues in [sequence.reqmts].
    
 
    View all issues with DR status.
    
 
    Discussion:
    
 
-
    Section 23.1.1 [sequence.reqmts], paragraphs 9-11, fixed up the problem
+
    Section 23.1.3 [sequence.reqmts], paragraphs 9-11, fixed up the problem
 noticed with statements like:
    
 
    vector<int> v(10, 1);
 
    
@@ -18881,7 +18941,7 @@ T implicit_cast(const U& u)
 
 
    Proposed resolution:
    
 
-
    Replace 23.1.1 [sequence.reqmts] paragraphs 9 - 11 with:
    
+
    Replace 23.1.3 [sequence.reqmts] paragraphs 9 - 11 with:
    
 
 
    For every sequence defined in this clause and in clause lib.strings:
    
 
@@ -19068,7 +19128,6 @@ of sentry::operator bool() to const.
 
    443. filebuf::close() inconsistent use of EOF
    
 
    Section: 27.8.1.4 [filebuf.members] Status: WP
  Submitter: Vincent Leloup Date: 2003-11-20
    
-
    View other active issues in [filebuf.members].
    
 
    View all other issues in [filebuf.members].
    
 
    View all issues with WP status.
    
 
    Discussion:
    
@@ -19607,7 +19666,6 @@ 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:
    
@@ -20084,7 +20142,7 @@ I propose to strike the Footnote.
 
 
    
 
    475. May the function object passed to for_each modify the elements of the iterated sequence?
    
-
    Section: 25.1.1 [alg.foreach] Status: WP
+
    Section: 25.1.4 [alg.foreach] Status: WP
  Submitter: Stephan T. Lavavej, Jaakko Jarvi Date: 2004-07-09
    
 
    View all other issues in [alg.foreach].
    
 
    View all issues with WP status.
    
@@ -20149,7 +20207,7 @@ passed to for_each modify its argument.
    
 
 
 
    Proposed resolution:
    
-
    Add a nonnormative note to the Effects in 25.1.1 [alg.foreach]: If
+
    Add a nonnormative note to the Effects in 25.1.4 [alg.foreach]: If
 the type of 'first' satisfies the requirements of a mutable iterator,
 'f' may apply nonconstant functions through the dereferenced iterators
 passed to it.
@@ -20653,6 +20711,75 @@ just above paragraph 5.
 
 
 
    
+
    518. Are insert and erase stable for unordered_multiset and unordered_multimap?
    
+
    Section: 23.1.5 [unord.req], TR1 6.3.1 [tr.unord.req] Status: WP
+ Submitter: Matt Austern Date: 2005-07-03
    
+
    View other active issues in [unord.req].
    
+
    View all other issues in [unord.req].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+Issue 371 deals with stability of multiset/multimap under insert and erase
+(i.e. do they preserve the relative order in ranges of equal elements).
+The same issue applies to unordered_multiset and unordered_multimap.
+
    
+
    [
+Moved to open (from review):  There is no resolution.
+]
    
+
+
+
    [
+Toronto:  We have a resolution now.  Moved to Review.  Some concern was noted
+as to whether this conflicted with existing practice or not.  An additional
+concern was in specifying (partial) ordering for an unordered container.
+]
    
+
+
+
+
+
    Proposed resolution:
    
+
    
+Wording for the proposed resolution is taken from the equivalent text for associative containers.
+
    
+
+
    
+Change 23.1.5 [unord.req], Unordered associative containers, paragraph 6 to:
+
    
+
+
    
+An unordered associative container supports unique keys if it may 
+contain at most one element for each key. Otherwise, it supports equivalent 
+keys. unordered_set and unordered_map support 
+unique keys. unordered_multiset and unordered_multimap 
+support equivalent keys. In containers that support equivalent keys, elements 
+with equivalent keys are adjacent to each other. For
+unordered_multiset 
+and unordered_multimap, insert and erase 
+preserve the relative ordering of equivalent elements.
+
    
+
+
    
+Change 23.1.5 [unord.req], Unordered associative containers, paragraph 8 to:
+
    
+
+
    
+
    The elements of an unordered associative container are organized into 
+buckets. Keys with the same hash code appear in the same bucket. The number 
+of buckets is automatically increased as elements are added to an unordered 
+associative container, so that the average number of elements per bucket is kept 
+below a bound. Rehashing invalidates iterators, changes ordering between 
+elements, and changes which buckets elements appear in, but does not invalidate 
+pointers or references to elements. For unordered_multiset 
+and unordered_multimap, rehashing 
+preserves the relative ordering of equivalent elements.
    
+
    
+
+
+
+
+
+
+
    
 
    519. Data() undocumented
    
 
    Section: 23.2.1 [array], TR1 6.2.2 [tr.array.array] Status: WP
  Submitter: Pete Becker Date: 2005-07-03
    
@@ -20689,7 +20816,7 @@ of data() is unspecified.
 
 
    
 
    520. Result_of and pointers to data members
    
-
    Section: 20.5.11.1 [func.bind], TR1 3.6 [tr.func.bind] Status: WP
+
    Section: 20.6.11.1 [func.bind], TR1 3.6 [tr.func.bind] Status: WP
  Submitter: Pete Becker Date: 2005-07-03
    
 
    View all issues with WP status.
    
 
    Discussion:
    
@@ -20732,7 +20859,7 @@ Peter provided wording.
 
 
    
 
    521. Garbled requirements for argument_type in reference_wrapper
    
-
    Section: 20.5.5 [refwrap], TR1 2.1.2 [tr.util.refwrp.refwrp] Status: WP
+
    Section: 20.6.5 [refwrap], TR1 2.1.2 [tr.util.refwrp.refwrp] Status: WP
  Submitter: Pete Becker Date: 2005-07-03
    
 
    View all issues with WP status.
    
 
    Discussion:
    
@@ -20881,7 +21008,7 @@ 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
+
    Section: 20.6.11.1.3 [func.bind.bind], TR1 3.6.3 [tr.func.bind.bind] Status: WP
  Submitter: Peter Dimov Date: 2005-10-01
    
 
    View other active issues in [func.bind.bind].
    
 
    View all other issues in [func.bind.bind].
    
@@ -20949,7 +21076,7 @@ throws an exception.
 
 
    Proposed resolution:
    
 
    
-In 20.5.11.1.3 [func.bind.bind], add a new paragraph after p2:
+In 20.6.11.1.3 [func.bind.bind], add a new paragraph after p2:
 
    
 
 
    
@@ -20958,7 +21085,7 @@ in the BoundArgs... pack expansion throws an exception.
 
    
 
 
    
-In 20.5.11.1.3 [func.bind.bind], add a new paragraph after p4:
+In 20.6.11.1.3 [func.bind.bind], add a new paragraph after p4:
 
    
 
 
    
@@ -21103,7 +21230,7 @@ writing to out of bounds memory when n == 0.  Martin provided fix.
 
 
    
 
    533. typo in 2.2.3.10/1
    
-
    Section: 20.6.12.2.11 [util.smartptr.getdeleter], TR1 2.2.3.10 [tr.util.smartptr.getdeleter] Status: DR
+
    Section: 20.7.12.2.11 [util.smartptr.getdeleter], TR1 2.2.3.10 [tr.util.smartptr.getdeleter] Status: DR
  Submitter: Paolo Carlini Date: 2005-11-09
    
 
    View all other issues in [util.smartptr.getdeleter].
    
 
    View all issues with DR status.
    
@@ -21428,7 +21555,7 @@ Otherwise CopyConstructible is not required.
 
 
    
 
    540. shared_ptr<void>::operator*()
    
-
    Section: 20.6.12.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] Status: WP
+
    Section: 20.7.12.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] Status: WP
  Submitter: Martin Sebor Date: 2005-10-15
    
 
    View all other issues in [util.smartptr.shared.obs].
    
 
    View all issues with WP status.
    
@@ -21486,7 +21613,7 @@ definition) of the function shall be well-formed.
 
 
    
 
    541. shared_ptr template assignment and void
    
-
    Section: 20.6.12.2 [util.smartptr.shared], TR1 2.2.3 [tr.util.smartptr.shared] Status: WP
+
    Section: 20.7.12.2 [util.smartptr.shared], TR1 2.2.3 [tr.util.smartptr.shared] Status: WP
  Submitter: Martin Sebor Date: 2005-10-16
    
 
    View other active issues in [util.smartptr.shared].
    
 
    View all other issues in [util.smartptr.shared].
    
@@ -21567,7 +21694,7 @@ public:
 
 
    
 
    542. shared_ptr observers
    
-
    Section: 20.6.12.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] Status: WP
+
    Section: 20.7.12.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] Status: WP
  Submitter: Martin Sebor Date: 2005-10-18
    
 
    View all other issues in [util.smartptr.shared.obs].
    
 
    View all issues with WP status.
    
@@ -21607,7 +21734,7 @@ capture the intent.
 
 
    Proposed resolution:
    
 
    
-Change 20.6.12.2.5 [util.smartptr.shared.obs] p12:
+Change 20.7.12.2.5 [util.smartptr.shared.obs] p12:
 
    
 
    
 [Note: use_count() is not necessarily efficient. Use only for
@@ -21615,7 +21742,7 @@ debugging and testing purposes, not for production code. --end note
 
    
 
 
    
-Change 20.6.12.3.5 [util.smartptr.weak.obs] p3:
+Change 20.7.12.3.5 [util.smartptr.weak.obs] p3:
 
    
 
    
 [Note: use_count() is not necessarily efficient. Use only for
@@ -21704,7 +21831,7 @@ lengths, and strides, as explained in the previous section.
 
 
    
 
    545. When is a deleter deleted?
    
-
    Section: 20.6.12.2.11 [util.smartptr.getdeleter], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] Status: WP
+
    Section: 20.7.12.2.11 [util.smartptr.getdeleter], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] Status: WP
  Submitter: Matt Austern Date: 2006-01-10
    
 
    View all other issues in [util.smartptr.getdeleter].
    
 
    View all issues with WP status.
    
@@ -21722,7 +21849,7 @@ instances). We should say which it is.
 
 
    Proposed resolution:
    
 
    
-Add after the first sentence of 20.6.12.2.11 [util.smartptr.getdeleter]/1:
+Add after the first sentence of 20.7.12.2.11 [util.smartptr.getdeleter]/1:
 
    
 
    
 
    
@@ -21741,6 +21868,144 @@ This can happen if the implementation doesn't destroy the deleter until all
 
 
 
    
+
    550. What should the return type of pow(float,int) be?
    
+
    Section: 26.7 [c.math] Status: WP
+ Submitter: Howard Hinnant Date: 2006-01-12
    
+
    View all other issues in [c.math].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+Assuming we adopt the
+C
+compatibility package from C99  what should be the return type of the
+following signature be:
+
    
+
    ?  pow(float, int);
+
    
+
    
+C++03 says that the return type should be float. 
+
+TR1 and C90/99 say the return type should be double.  This can put
+clients into a situation where C++03 provides answers that are not as high
+quality as C90/C99/TR1.  For example:
+
    
+
    #include <math.h>
+
+int main()
+{
+    float x = 2080703.375F;
+    double y = pow(x, 2);
+}
+
    
+
    
+Assuming an IEEE 32 bit float and IEEE 64 bit double, C90/C99/TR1 all suggest:
+
    
+
+
    y = 4329326534736.390625
+
    
+
+
    
+which is exactly right.  While C++98/C++03 demands:
+
    
+
+
    y = 4329326510080.
+
    
+
+
    
+which is only approximately right.
+
    
+
+
    
+I recommend that C++0X adopt the mixed mode arithmetic already adopted by
+Fortran, C and TR1 and make the return type of pow(float,int) be
+double.
+
    
+
+
    [
+Kona (2007): Other functions that are affected by this issue include
+ldexp, scalbln, and scalbn. We also believe that there is a typo in
+26.7/10: float nexttoward(float, long double); [sic] should be float
+nexttoward(float, float); Proposed Disposition: Review (the proposed
+resolution appears above, rather than below, the heading "Proposed
+resolution")
+]
    
+
+
+
    [
+
    
+Howard, post Kona:
+
    
+
    
+
    
+Unfortunately I strongly disagree with a part of the resolution
+from Kona.  I am moving from New to Open instead of to Review because I do not believe
+we have consensus on the intent of the resolution.
+
    
+
    
+This issue does not include ldexp, scalbln, and scalbn because
+the second integral parameter in each of these signatures (from C99) is not a
+generic parameter according to C99 7.22p2.  The corresponding C++ overloads are
+intended (as far as I know) to correspond directly to C99's definition of generic parameter.
+
    
+
    
+For similar reasons, I do not believe that the second long double parameter of
+nexttoward, nor the return type of this function, is in error.  I believe the
+correct signature is:
+
    
+
    
+
    float nexttoward(float, long double);
+
    
+
    
+
    
+which is what both the C++0X working paper and C99 state (as far as I currently understand).
+
    
+
    
+This is really only about pow(float, int).  And this is because C++98 took one
+route (with pow only) and C99 took another (with many math functions in <tgmath.h>.
+The proposed resolution basically says: C++98 got it wrong and C99 got it right; let's go with C99.
+
    
+
    
+]
    
+
+
+
    [
+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] p10:
+
    
+
+
    
+
    
+The added signatures are:
+
    
+
    ...
+float pow(float, int);
+...
+double pow(double, int);
+...
+long double pow(long double, int);
+
    
+
    
+
+
+
+
+
+
+
    
 
    551. <ccomplex>
    
 
    Section: 26.3.11 [cmplxh], TR1 8.3 [tr.c99.cmplxh] Status: WP
  Submitter: Howard Hinnant Date: 2006-01-23
    
@@ -22376,8 +22641,60 @@ Kona (2007): Proposed Disposition: Ready
 
 
 
    
+
    574. DR 369 Contradicts Text
    
+
    Section: 27.3 [iostream.objects] Status: WP
+ Submitter: Pete Becker Date: 2006-04-18
    
+
    View all other issues in [iostream.objects].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+lib.iostream.objects requires that the standard stream objects are never
+destroyed, and it requires that they be destroyed.
+
    
+
    
+DR 369 adds words to say that we really mean for ios_base::Init objects to force
+construction of standard stream objects. It ends, though, with the phrase "these
+stream objects shall be destroyed after the destruction of dynamically ...".
+However, the rule for destruction is stated in the standard: "The objects are
+not destroyed during program execution."
+
    
+
+
+
    Proposed resolution:
    
+
    
+Change 27.3 [iostream.objects]/1:
+
    
+
+
    
+
    
+-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.
+
    
+
    
+
+
+
    [
+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
+]
    
+
+
+
+
+
+
    
 
    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
+
    Section: 20.7.12.2.2 [util.smartptr.shared.dest], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] Status: WP
  Submitter: Peter Dimov Date: 2006-04-23
    
 
    View all issues with WP status.
    
 
    Discussion:
    
@@ -22455,7 +22772,7 @@ after *this is destroyed. --end note]
 
 
    
 
    576. find_first_of is overconstrained
    
-
    Section: 25.1.4 [alg.find.first.of] Status: WP
+
    Section: 25.1.7 [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.
    
@@ -22558,7 +22875,7 @@ conditions hold: !(value < *j) or comp(value, *j)
 
 
    
 
    578. purpose of hint to allocator::allocate()
    
-
    Section: 20.6.5.1 [allocator.members] Status: WP
+
    Section: 20.7.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.
    
@@ -22867,96 +23184,386 @@ 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.
    
+
    595. TR1/C++0x: fabs(complex<T>) redundant / wrongly specified
    
+
    Section: 26.3.7 [complex.value.ops] Status: WP
+ Submitter: Stefan Große Pawig Date: 2006-09-24
    
+
    View all other issues in [complex.value.ops].
    
+
    View all issues with WP status.
    
 
    Discussion:
    
-
 
    
-In a private email, Daniel writes:
+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
+
+[...]
+
+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 -----
+
    
+
 
    
-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
+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.
 
    
-
    "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:
+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
+
+  Synopsis
+
+1 #include <complex.h>
+  double cabs(double complex z);
+  float cabsf(float complex z);
+  long double cabsl(long double z);
+
+  Description
+
+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 -----
+
    
+
 
    
-"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. [..]"
+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).
 
    
 
    
-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. 
+So either the return value of fabs() is specified wrongly, or fabs()
+does not behave the same as C99's cabs*().
 
    
-
    
+
+Possible Resolutions
+
 
    
-Robert comments:
+This depends on the intention behind the introduction of fabs().
 
    
 
    
-Also, there is a further error in the Returns: clause for converting decimal::decimal128 to long long.  It currently calls llroundd64, not llroundd128.
+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.
 
    
-
-
-
-
    Proposed resolution:
    
 
    
-Change the Returns: clause in 3.2.2.4 to:
+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
 
    
-
    
-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.
-
    
+
      complex<double> x, y;
+  y = fabs(x);
+  complex<double> z(fabs(x));
+
    
 
    
-Change the Returns: clause in 3.2.3.4 to:
+and
 
    
-
    
-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.
-
    
+
      complex<double> x, y;
+  y = abs(x);
+  complex<double> z(abs(x));
+
    
 
    
-Change the Returns: clause in 3.2.4.4 to:
+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().
 
    
-
    
-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.
-
    
 
+
    [
+Bellevue:
+]
    
 
 
+
    
+Bill believes that abs() is a suitable overload. We should remove fabs().
+
    
 
 
+
    Proposed resolution:
    
 
-
    
-
    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:
+Change the synopsis in 26.3.1 [complex.synopsis]:
 
    
 
-
    
-
    
+
    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);
+
    
+
    
+
    
+-7- Effects: Behaves the same as C99 function cabs, defined in subclause 7.3.8.1.
+
    
+
    
+
    
+
+
+
+
    [
+Kona (2007): Change the return type of fabs(complex) to T. 
+Proposed Disposition: Ready
+]
    
+
+
+
+
+
+
    
+
    596. 27.8.1.3 Table 112 omits "a+" and "a+b" modes
    
+
    Section: 27.8.1.4 [filebuf.members] Status: WP
+ Submitter: Thomas Plum Date: 2006-09-26
    
+
    View all other issues in [filebuf.members].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+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.
+
    
+
+
    [
+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:
    
+
    
+Add to the table "File open modes" in 27.8.1.4 [filebuf.members]:
+
    
+
+
    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
     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.
+]
    
+
+
+
+
+
+
    
+
    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 
@@ -23530,7 +24137,7 @@ 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
+
    Section: 20.6.15.2.1 [func.wrap.func.con], TR1 3.7.2.1 [tr.func.wrap.func.con] Status: WP
  Submitter: Scott Meyers Date: 2006-11-02
    
 
    View all issues with WP status.
    
 
    Discussion:
    
@@ -23668,6 +24275,61 @@ component. 
 
 
 
    
+
    612. numeric_limits::is_modulo insufficiently defined
    
+
    Section: 18.2.1.2 [numeric.limits.members] Status: WP
+ Submitter: Chris Jefferson Date: 2006-11-10
    
+
    View all other issues in [numeric.limits.members].
    
+
    View all issues with WP 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], 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).
+
    
+
+
+
+
+
+
+
    
 
    613. max_digits10 missing from numeric_limits
    
 
    Section: 18.2.1.5 [numeric.special] Status: WP
  Submitter: Bo Persson Date: 2006-11-20
    
@@ -23795,42 +24457,99 @@ as this is a dependent type, it should obviously be
 
 
 
    
-
    619. Longjmp wording problem
    
-
    Section: 18.8 [support.runtime] Status: WP
- Submitter: Lawrence Crowl Date: 2007-01-12
    
+
    618. valarray::cshift() effects on empty array
    
+
    Section: 26.5.2.7 [valarray.members] Status: WP
+ Submitter: Gabriel Dos Reis Date: 2007-01-10
    
 
    View all issues with WP status.
    
 
    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."
+I would respectfully request an issue be opened with the intention to
+clarify the wording for size() == 0 for cshift.
 
    
 
 
 
    Proposed resolution:
    
 
    
-In general, accept Bill Gibbons' recommendation,
-but add "call" to indicate that the undefined behavior
+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.
+]
    
+
+
+
+
+
+
    
+
    619. Longjmp wording problem
    
+
    Section: 18.9 [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.9 [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
+In 18.9 [support.runtime] paragraph 4, change
 
    
 
 
    
@@ -23852,6 +24571,7 @@ undefined behavior if replacing the setjmp and longjmp by
 
    620. valid uses of empty valarrays
    
 
    Section: 26.5.2.1 [valarray.cons] Status: WP
  Submitter: Martin Sebor Date: 2007-01-20
    
+
    View other active issues in [valarray.cons].
    
 
    View all other issues in [valarray.cons].
    
 
    View all issues with WP status.
    
 
    Discussion:
    
@@ -24053,7 +24773,7 @@ dtor? Should the  dtor catch and swallow it or  should it propagate it
 to the caller?  The text doesn't  seem to provide any guidance in this
 regard  other  than  the  general  restriction on  throwing  (but  not
 propagating)  exceptions  from   destructors  of  library  classes  in
-17.4.4.8 [res.on.exception.handling].
+17.4.4.9 [res.on.exception.handling].
 
         
    
         
    
@@ -24168,7 +24888,7 @@ And to make the following edits in 27.8.1.2 [filebuf.cons].
 close().    If  an   exception  occurs   during  the
 destruction of the object, including the call to close(),
 the     exception    is     caught    but     not     rethrown    (see
-17.4.4.8 [res.on.exception.handling]).
+17.4.4.9 [res.on.exception.handling]).
 
             
    
         
    
@@ -24379,7 +25099,7 @@ Change 28.8.2 [re.regex.construct]:
 
 
    
 
    634. allocator.address() doesn't work for types overloading operator&
    
-
    Section: 20.6.5.1 [allocator.members] Status: WP
+
    Section: 20.7.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.
    
@@ -24387,7 +25107,7 @@ Change 28.8.2 [re.regex.construct]:
 
    Discussion:
    
 
 
    
-20.6.5.1 [allocator.members] says:
+20.7.5.1 [allocator.members] says:
 
    
 
    
 
    pointer address(reference x) const;
    
@@ -24399,7 +25119,7 @@ Change 28.8.2 [re.regex.construct]:
 
    
 
 
    
-20.6.5.1 [allocator.members] defines CopyConstructible which currently not
+20.7.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
@@ -24430,7 +25150,7 @@ is expected to make use of allocator::address mandatory for containers.
 
 
    Proposed resolution:
    
 
    
-Change 20.6.5.1 [allocator.members]:
+Change 20.7.5.1 [allocator.members]:
 
    
 
 
    
@@ -24471,6 +25191,102 @@ issue to Ready status to be voted into the WP at Kona.
 
 
 
    
+
    638. deque end invalidation during erase
    
+
    Section: 23.2.2.3 [deque.modifiers] Status: WP
+ Submitter: Steve LoBasso Date: 2007-02-17
    
+
    View all issues with WP status.
    
+
    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.
+
    
+
+
+
+
+
    
 
    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
    
@@ -24586,45 +25402,6 @@ A local variable punct is initialized via
 
 
 
    
-
    644. Possible typos in 'function' description
    
-
    Section: X [func.wrap.func.undef] Status: Pending WP
- Submitter: Bo Persson Date: 2007-02-25
    
-
    Discussion:
    
-
    
-X [func.wrap.func.undef]
-
    
-
    
-The note in paragraph 2 refers to 'undefined void operators', while the 
-section declares a pair of operators returning bool.
-
    
-
-
-
    Proposed resolution:
    
-
    
-Change 20.5.15.2 [func.wrap.func]
-
    
-
-
    ...
-private:
-   // X [func.wrap.func.undef], undefined operators:
-   template<class Function2> bool void operator==(const function<Function2>&);
-   template<class Function2> bool void operator!=(const function<Function2>&);
-};
-
    
-
-
    
-Change X [func.wrap.func.undef]
-
    
-
-
    template<class Function2> bool void operator==(const function<Function2>&);
-template<class Function2> bool void operator!=(const function<Function2>&);
-
    
-
-
-
-
-
-
    
 
    646. const incorrect match_result members
    
 
    Section: 28.10.4 [re.results.form] Status: WP
  Submitter: Daniel Krügler Date: 2007-02-26
    
@@ -24985,12 +25762,12 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
    
 
    660. Missing Bitwise Operations
    
-
    Section: 20.5 [function.objects] Status: WP
+
    Section: 20.6 [function.objects] Status: WP
  Submitter: Beman Dawes Date: 2007-04-02
    
 
    View all other issues in [function.objects].
    
 
    View all issues with WP status.
    
 
    Discussion:
    
-
    Section 20.5 [function.objects] provides function
+
    Section 20.6 [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 
@@ -25009,7 +25786,7 @@ resolution is limited to them.
    
 
 
 
    Proposed resolution:
    
-
    To 20.5 [function.objects], Function objects, paragraph 2, add to the header 
+
    To 20.6 [function.objects], Function objects, paragraph 2, add to the header 
 <functional> synopsis:
    
 
    
   
    template <class T> struct bit_and;
@@ -25284,96 +26061,159 @@ four characters long, usually three letters and a space.
 
 
 
    
-
    674. shared_ptr interface changes for consistency with N1856
    
-
    Section: 20.6.12.2 [util.smartptr.shared] Status: WP
- Submitter: Peter Dimov Date: 2007-05-05
    
-
    View other active issues in [util.smartptr.shared].
    
-
    View all other issues in [util.smartptr.shared].
    
+
    672. Swappable requirements need updating
    
+
    Section: 20.1.1 [utility.arg.requirements] Status: WP
+ Submitter: Howard Hinnant Date: 2007-05-04
    
+
    View other active issues in [utility.arg.requirements].
    
+
    View all other issues in [utility.arg.requirements].
    
 
    View all issues with WP status.
    
 
    Discussion:
    
 
    
-N1856 does not propose
-any changes to shared_ptr. It needs to be updated to use a rvalue reference where appropriate
-and to interoperate with unique_ptr as it does with auto_ptr.
+The current Swappable is:
 
    
 
-
-
    Proposed resolution:
    
-
+
    
+
+
+
+
+
+
    Table 37: Swappable requirements [swappable]
    expressionreturn typepost-condition
    swap(s,t)voidt has the value originally held by u, and u has the value originally 
+held by t
    
 
    
-Change 20.6.12.2 [util.smartptr.shared] as follows:
+The Swappable requirement is met by satisfying one or more of the following conditions:
 
    
-
-
    
-
    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);
    
+
      
+
    • 
+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.
+
      • 
+
    
+
    
 
    
 
 
    
-Change 20.6.12.2.1 [util.smartptr.shared.const] as follows:
+With the passage of rvalue reference into the language, Swappable needs to be updated to
+require only MoveConstructible and MoveAssignable.  This is a minimum.
 
    
 
-
    
-
    template<class Y> shared_ptr(auto_ptr<Y>&&& r);
    
-
    
-
 
    
-Add to 20.6.12.2.1 [util.smartptr.shared.const]:
+Additionally we may want to support proxy references such that the following code is acceptable:
 
    
 
-
    
-
    template<class Y, class D> shared_ptr(unique_ptr<Y, D>&& r);
    
-
    
+
    namespace Mine {
 
-
    
-Effects: Equivalent to shared_ptr( r.release(), r.get_deleter() ) when D is
-          not a reference type, shared_ptr( r.release(), ref( r.get_deleter() ) )
-          otherwise.
-
    
+template <class T>
+struct proxy {...};
 
-
    
-Exception safety: If an exception is thrown, the constructor has no effect.
-
    
-
    
+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);
+
    
 
 
    
-Change 20.6.12.2.3 [util.smartptr.shared.assign] as follows:
+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.
 
    
 
-
    
-
    template<class Y> shared_ptr& operator=(auto_ptr<Y>&&& r);
    
-
    
+
+
+
    Proposed resolution:
    
 
 
    
-Add to 20.6.12.2.3 [util.smartptr.shared.assign]:
+Change 20.1.1 [utility.arg.requirements]:
 
    
 
 
    
-
    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.
-
    
-
    
+
    
+-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 may need to open an issue (743) to deal with the question of
-whether shared_ptr needs an rvalue swap.
+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).
 ]
    
 
 
@@ -25381,295 +26221,340 @@ whether shared_ptr needs an rvalue swap.
 
 
 
    
-
    677. Weaknesses in seed_seq::randomize [rand.util.seedseq]
    
-
    Section: 26.4.7.1 [rand.util.seedseq] Status: WP
- Submitter: Charles Karney Date: 2007-05-15
    
-
    View other active issues in [rand.util.seedseq].
    
-
    View all other issues in [rand.util.seedseq].
    
+
    673. unique_ptr update
    
+
    Section: 20.7.11 [unique.ptr] Status: WP
+ Submitter: Howard Hinnant Date: 2007-05-04
    
+
    View all other issues in [unique.ptr].
    
 
    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
+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.
 
    
 
-
      
-
    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.
        • 
-
      
+
+
    2. 
 
      
-    The proposed algorithm (below) has the considerably stronger
-    properties:
      
-
        
-
      •    All of the (2^(32n)-1)/(2^32-1) seed vectors of lengths s < n
-      result in distinct states.
-
        • 
-
      •   All of the 2^(32n) seed vectors of length s == n result in
-      distinct states.
-
        • 
-
      
-
      3. 
-
    3. 
-
       Poor mixing of v's entropy into the state.  Consider v.size() == n
-    and hold v[n/2] thru v[n-1] fixed while varying v[0] thru v[n/2-1],
-    a total of 2^(16n) possibilities.  Because of the simple recursion
-    used in seed_seq, begin[n/2] thru begin[n-1] can take on only 2^64
-    possible states.
      
-
-
       The proposed algorithm uses a more complex recursion which results
-    in much better mixing.
      
-
      4. 
-
    4.  seed_seq::randomize is undefined for v.size() == 0.  The proposed
-    algorithm remedies this.
-
      5. 
-
    
-
    
-The 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
+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.
 
    
+
 
    
-One change has been made here, namely to treat the case of small n
-(setting t = (n-1)/2 for n < 7).
+This resolution also supports instantiations such as unique_ptr<void, free_deleter>
+which could be very useful to the client.
 
    
+
+
+
+
  • 
 
    
-Since seed_seq was introduced relatively recently there is little cost
-in making this incompatible improvement to it.
+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.
 
    
+
    • 
 
+
  • 
 
    
-See N2391 and
-N2423
-for some further discussion.
+When the deleter type is a function pointer then it is unsafe to construct
+a unique_ptr without specifying the function pointer in the constructor.
+This case is easy to check for with a static_assert assuring that the
+deleter is not a pointer type in those constructors which do not accept deleters.
 
    
 
+
    unique_ptr<A, void(*)(void*)> p(new A);  // error, no function given to delete the pointer!
+
    
 
-
    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.
+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);
 
-
    
-
    678. Changes for [rand.req.eng]
    
-
    Section: 26.4.1.3 [rand.req.eng] Status: WP
- Submitter: Charles Karney Date: 2007-05-15
    
-
    View all other issues in [rand.req.eng].
    
-
    View all issues with WP status.
    
-
    Discussion:
    
-
    
-Section 26.4.1.3 [rand.req.eng] Random number engine requirements:
-
    
-
-
    
-This change follows naturally from the proposed change to
-seed_seq::randomize in 677.
-
    
+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
+
    
+
    
 
 
    
-In table 104 the description of X(q) contains a special treatment of
-the case q.size() == 0.  This is undesirable for 4 reasons:
+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:
 
    
 
-
      
-
    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. 
-
    
+
    T& operator*() const;
+T* operator->() const;
+
    
 
-
    
-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.
+I am grateful for the generous aid of Peter Dimov and Ion Gaztañaga in helping formulate and review
+the proposed resolutions below.
 ]
    
 
 
+
      
+
    • 
 
-
-
-
      
-
      679. resize parameter by value
      
-
      Section: 23.2 [sequences] Status: WP
- Submitter: Howard Hinnant Date: 2007-06-11
      
-
      View all issues with WP status.
      
-
      Discussion:
      
 
      
-The C++98 standard specifies that one member function alone of the containers
-passes its parameter (T) by value instead of by const reference:
+Change 20.7.11.2 [unique.ptr.single]:
 
      
 
-
      void resize(size_type sz, T c = T());
+
      template <class T, class D = default_delete<T>> class unique_ptr {
+   ...
+   T& typename add_lvalue_reference<T>::type operator*() const;
+   ...
+};
 
      
 
 
      
-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:
+Change 20.7.11.2.4 [unique.ptr.single.observers]:
 
      
 
-
      
-
      
-So that self referencing statements are guaranteed to work, for example:
-
      
-
      v.resize(v.size() + 1, v[0]);
+
      T& typename add_lvalue_reference<T>::type operator*() const;
 
      
-
      
 
+
      • 
+
+
    • 
 
      
-However this rationale is not convincing as the signature for push_back is:
+Change 20.7.11.2 [unique.ptr.single]:
 
      
 
-
      void push_back(const T& x);
+
      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());
+};
 
      
 
 
      
-And push_back has similar semantics to resize (append).
-And push_back must also work in the self referencing case:
+
+-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.
+
 
      
 
-
      v.push_back(v[0]);  // must work
+
      
+Change 20.7.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);
+...
 
      
 
 
      
-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).
+-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.
 
      
 
 
      
-Even with move semantics available, passing this parameter by value can be expensive.
-Consider for example vector<vector<int>>:
+-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().
 
      
 
-
      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.
+Change 20.7.11.2.3 [unique.ptr.single.asgn]:
 
      
 
+
      
 
      
-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.
+-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.
 
      
+
      
 
 
      
-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.
+Change 20.7.11.2.4 [unique.ptr.single.observers]:
 
      
 
+
      
+
      T* pointer operator->() const;
      
+...
+
      T* pointer get() const;
      
+
      
 
+
      
+Change 20.7.11.2.5 [unique.ptr.single.modifiers]:
+
      
+
+
      
+
      T* pointer release();
      
+...
+
      void reset(T* pointer p = 0 pointer());
      
+
      
 
-
      Proposed resolution:
      
 
      
-Change 23.2.2 [deque], p2:
+Change 20.7.11.3 [unique.ptr.runtime]:
 
      
 
-
      class deque {
+
      template <class T, class D> class unique_ptr<T[], D> {
+public:
+  typedef implementation pointer;
    ...
-   void resize(size_type sz, const T& c);
+   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 23.2.2.2 [deque.capacity], p3:
+Change 20.7.11.3.1 [unique.ptr.runtime.ctor]:
 
      
 
-
      void resize(size_type sz, const T& c);
-
      
+
      
+
      unique_ptr(T* pointer p);
+unique_ptr(T* pointer p, implementation defined d);
+unique_ptr(T* pointer p, implementation defined d);
+
      
 
 
      
-Change 23.2.4 [list], p2:
+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]
 
      
-
-
      class list {
-   ...
-   void resize(size_type sz, const T& c);
-
      
+
      
 
 
      
-Change 23.2.4.2 [list.capacity], p3:
+Change 20.7.11.3.3 [unique.ptr.runtime.modifiers]:
 
      
 
-
      void resize(size_type sz, const T& c);
-
      
+
      
+
      void reset(T* pointer p = 0 pointer());
+
      
 
 
      
-Change 23.2.6 [vector], p2:
+-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]
 
      
+
      
 
-
      class vector {
-   ...
-   void resize(size_type sz, const T& c);
-
      
+
      • 
+
+
    • 
 
 
      
-Change 23.2.6.2 [vector.capacity], p11:
+Change 20.7.11.2.1 [unique.ptr.single.ctor]:
 
      
 
-
      void resize(size_type sz, const T& c);
-
      
+
      
+
      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).
+
      
+
      
+
      
+
+
      • 
+
+
    
 
 
 
@@ -25677,110 +26562,200 @@ Change 23.2.6.2 [vector.capacity], p11:
 
 
 
    
-
    680. move_iterator operator-> return
    
-
    Section: 24.4.3.1 [move.iterator] Status: WP
- Submitter: Howard Hinnant Date: 2007-06-11
    
+
    674. shared_ptr interface changes for consistency with N1856
    
+
    Section: 20.7.12.2 [util.smartptr.shared] Status: WP
+ Submitter: Peter Dimov Date: 2007-05-05
    
+
    View other active issues in [util.smartptr.shared].
    
+
    View all other issues in [util.smartptr.shared].
    
 
    View all issues with WP status.
    
 
    Discussion:
    
 
    
-move_iterator's operator-> return type pointer
-does not consistently match the type which is returned in the description
-in 24.4.3.3.5 [move.iter.op.ref].
-
    
-
-
    template <class Iterator>
-class move_iterator {
-public:
-    ...
-    typedef typename iterator_traits<Iterator>::pointer pointer;
-    ...
-    pointer operator->() const {return current;}
-    ...
-private: 
-    Iterator current; // exposition only
-};
-
    
+N1856 does not propose
+any changes to shared_ptr. It needs to be updated to use a rvalue reference where appropriate
+and to interoperate with unique_ptr as it does with auto_ptr.
+
    
 
 
+
    Proposed resolution:
    
+
 
    
-There are two possible fixes.
+Change 20.7.12.2 [util.smartptr.shared] as follows:
 
    
 
-
      
-
    1. pointer operator->() const {return &*current;}
      2. 
-
    2. typedef Iterator pointer;
      3. 
-
    
+
    
+
    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);
    
+
    
 
 
    
-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.
+Change 20.7.12.2.1 [util.smartptr.shared.const] as follows:
 
    
 
+
    
+
    template<class Y> shared_ptr(auto_ptr<Y>&&& r);
    
+
    
+
 
    
-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.
+Add to 20.7.12.2.1 [util.smartptr.shared.const]:
 
    
 
-
    Proposed resolution:
    
+
    
+
    template<class Y, class D> shared_ptr(unique_ptr<Y, D>&& r);
    
+
    
+
+
    
+Effects: Equivalent to shared_ptr( r.release(), r.get_deleter() ) when D is
+          not a reference type, shared_ptr( r.release(), ref( r.get_deleter() ) )
+          otherwise.
+
    
+
+
    
+Exception safety: If an exception is thrown, the constructor has no effect.
+
    
+
    
+
+
    
+
 
    
-Change the synopsis in 24.4.3.1 [move.iterator]:
+Change 20.7.12.2.3 [util.smartptr.shared.assign] as follows:
 
    
 
-
    typedef typename iterator_traits<Iterator>::pointer pointer;
-
    
+
    
+
    template<class Y> shared_ptr& operator=(auto_ptr<Y>&&& r);
    
+
    
+
+
    
+Add to 20.7.12.2.3 [util.smartptr.shared.assign]:
+
    
+
+
    
+
    template<class Y, class D> shared_ptr& operator=(unique_ptr<Y,D>&& r);
    
+
+
    
+
    
+-4- Effects: Equivalent to shared_ptr(std::move(r)).swap(*this).
+
    
+
    
+-5- Returns: *this.
+
    
+
    
+
+
    
+
 
 
+
    [
+Kona (2007): We may need to open an issue (743) to deal with the question of
+whether shared_ptr needs an rvalue swap.
+]
    
+
 
 
 
 
 
    
-
    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
    
+
    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:
    
 
    
-In 28.9.2 [re.submatch.op] of N2284, 
-operator functions numbered 31-42 seem impossible to compare.  E.g.: 
+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
 
    
 
-
    
-
    template <class BiIter>
-    bool operator==(typename iterator_traits<BiIter>::value_type const& lhs,
-                    const sub_match<BiIter>& rhs);
-
    
-
    
+
      
+
    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.
        • 
+
      
 
      
--31- Returns: lhs == rhs.str().
+    The proposed algorithm (below) has the considerably stronger
+    properties:
      
+
        
+
      •    All of the (2^(32n)-1)/(2^32-1) seed vectors of lengths s < n
+      result in distinct states.
+
        • 
+
      •   All of the 2^(32n) seed vectors of length s == n result in
+      distinct states.
+
        • 
+
      
+
      2. 
+
    2. 
+
       Poor mixing of v's entropy into the state.  Consider v.size() == n
+    and hold v[n/2] thru v[n-1] fixed while varying v[0] thru v[n/2-1],
+    a total of 2^(16n) possibilities.  Because of the simple recursion
+    used in seed_seq, begin[n/2] thru begin[n-1] can take on only 2^64
+    possible states.
      
+
+
       The proposed algorithm uses a more complex recursion which results
+    in much better mixing.
      
+
      3. 
+
    3.  seed_seq::randomize is undefined for v.size() == 0.  The proposed
+    algorithm remedies this.
+
      4. 
+
    
+
    
+The current algorithm for seed_seq::randomize is adapted by me from the
+initialization procedure for the Mersenne Twister by Makoto Matsumoto
+and Takuji Nishimura.  The weakness (2) given above was communicated to
+me by Matsumoto last year.
+
    
+
    
+The proposed replacement for seed_seq::randomize is due to Mutsuo Saito,
+a student of Matsumoto, and is given in the implementation of the
+SIMD-oriented Fast Mersenne Twister random number generator SFMT.
+http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html
+http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/SFMT-src-1.2.tar.gz
+
    
+
    
+See
+Mutsuo Saito,
+An Application of Finite Field: Design and Implementation of 128-bit
+Instruction-Based Fast Pseudorandom Number Generator,
+Master's Thesis, Dept. of Math., Hiroshima University (Feb. 2007)
+http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/M062821.pdf
+
    
+
    
+One change has been made here, namely to treat the case of small n
+(setting t = (n-1)/2 for n < 7).
+
    
+
    
+Since seed_seq was introduced relatively recently there is little cost
+in making this incompatible improvement to it.
 
    
-
    
-
    
 
 
    
-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. 
+See N2391 and
+N2423
+for some further discussion.
 
    
 
 
 
    Proposed resolution:
    
 
    
 Adopt the proposed resolution in
-N2409.
+N2423.
 
    
 
 
 
    [
-Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
+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.
 ]
    
 
@@ -25789,59 +26764,53 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
 
    
-
    682. basic_regex ctor takes InputIterator or ForwardIterator?
    
-
    Section: 28.8.2 [re.regex.construct] Status: WP
- Submitter: Eric Niebler Date: 2007-06-03
    
+
    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:
    
 
    
-Looking at N2284, 28.8 [re.regex], p3 basic_regex class template synopsis shows this 
-constructor: 
+Section 26.4.1.3 [rand.req.eng] Random number engine requirements:
 
    
-
    template <class InputIterator>
-     basic_regex(InputIterator first, InputIterator last, 
-                 flag_type f = regex_constants::ECMAScript);
-
    
 
 
    
-In 28.8.2 [re.regex.construct], p15, the constructor appears with this signature: 
+This change follows naturally from the proposed change to
+seed_seq::randomize in 677.
 
    
 
-
    template <class ForwardIterator>
-     basic_regex(ForwardIterator first, ForwardIterator last, 
-                 flag_type f = regex_constants::ECMAScript);
-
    
-
 
    
-ForwardIterator is probably correct, so the synopsis is wrong.
+In table 104 the description of X(q) contains a special treatment of
+the case q.size() == 0.  This is undesirable for 4 reasons:
 
    
 
-
    [
-John adds:
-]
    
-
+
      
+
    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. 
+
    
 
-
    
-
    
-I think either could be implemented?  Although an input iterator would 
-probably require an internal copy of the string being made.
-
    
 
    
-I have no strong feelings either way, although I think my original intent 
-was InputIterator. 
+See N2391 and
+N2423
+for some further discussion.
 
    
-
    
 
 
 
    Proposed resolution:
    
 
    
 Adopt the proposed resolution in
-N2409.
+N2423.
 
    
 
 
 
    [
-Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
+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.
 ]
    
 
@@ -25850,419 +26819,2719 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
 
    
-
    687. shared_ptr conversion constructor not constrained
    
-
    Section: 20.6.12.2.1 [util.smartptr.shared.const], 20.6.12.3.1 [util.smartptr.weak.const] Status: WP
- Submitter: Peter Dimov Date: 2007-05-10
    
-
    View all other issues in [util.smartptr.shared.const].
    
+
    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:
    
 
    
-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:
+The C++98 standard specifies that one member function alone of the containers
+passes its parameter (T) by value instead of by const reference:
 
    
 
-
    void f( shared_ptr<void> );
-void f( shared_ptr<int> );
+
    void resize(size_type sz, T c = T());
+
    
 
-int main()
-{
-  f( shared_ptr<double>() ); // ambiguous
-}
+
    
+This fact has been discussed / debated repeatedly over the years, the first time
+being even before C++98 was ratified.  The rationale for passing this parameter by
+value has been:
+
    
+
+
    
+
    
+So that self referencing statements are guaranteed to work, for example:
+
    
+
    v.resize(v.size() + 1, v[0]);
 
    
+
    
 
 
    
-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.
+However this rationale is not convincing as the signature for push_back is:
+
    
+
+
    void push_back(const T& x);
+
    
+
+
    
+And push_back has similar semantics to resize (append).
+And push_back must also work in the self referencing case:
+
    
+
+
    v.push_back(v[0]);  // must work
+
    
+
+
    
+The problem with passing T by value is that it can be significantly more
+expensive than passing by reference.  The converse is also true, however when it is
+true it is usually far less dramatic (e.g. for scalar types).
+
    
+
+
    
+Even with move semantics available, passing this parameter by value can be expensive.
+Consider for example vector<vector<int>>:
+
    
+
+
    std::vector<int> x(1000);
+std::vector<std::vector<int>> v;
+...
+v.resize(v.size()+1, x);
+
    
+
+
    
+In the pass-by-value case, x is copied once to the parameter of
+resize.  And then internally, since the code can not know at compile
+time by how much resize is growing the vector, x is
+usually copied (not moved) a second time from resize's parameter into its proper place
+within the vector.
+
    
+
+
    
+With pass-by-const-reference, the x in the above example need be copied
+only once.  In this case, x has an expensive copy constructor and so any
+copies that can be saved represents a significant savings.
+
    
+
+
    
+If we can be efficient for push_back, we should be efficient for resize
+as well.  The resize taking a reference parameter has been coded and shipped in the
+CodeWarrior library with no reports of problems which I am aware of.
 
    
 
 
+
 
    Proposed resolution:
    
 
    
-In 20.6.12.2.1 [util.smartptr.shared.const], change:
+Change 23.2.2 [deque], p2:
 
    
 
-
    
--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*.
-
    
+
    class deque {
+   ...
+   void resize(size_type sz, const T& c);
+
    
+
+
    
+Change 23.2.2.2 [deque.capacity], p3:
+
    
+
+
    void resize(size_type sz, const T& c);
+
    
+
+
    
+Change 23.2.4 [list], p2:
+
    
+
+
    class list {
+   ...
+   void resize(size_type sz, const T& c);
+
    
+
+
    
+Change 23.2.4.2 [list.capacity], p3:
+
    
+
+
    void resize(size_type sz, const T& c);
+
    
+
+
    
+Change 23.2.6 [vector], p2:
+
    
+
+
    class vector {
+   ...
+   void resize(size_type sz, const T& c);
+
    
+
+
    
+Change 23.2.6.2 [vector.capacity], p11:
+
    
+
+
    void resize(size_type sz, const T& c);
+
    
+
+
+
+
+
 
+
    
+
    680. move_iterator operator-> return
    
+
    Section: 24.4.3.1 [move.iterator] Status: WP
+ Submitter: Howard Hinnant Date: 2007-06-11
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+move_iterator's operator-> return type pointer
+does not consistently match the type which is returned in the description
+in 24.4.3.3.5 [move.iter.op.ref].
+
    
+
+
    template <class Iterator>
+class move_iterator {
+public:
+    ...
+    typedef typename iterator_traits<Iterator>::pointer pointer;
+    ...
+    pointer operator->() const {return current;}
+    ...
+private: 
+    Iterator current; // exposition only
+};
+
    
+
+
+
    
+There are two possible fixes.
+
    
+
+
      
+
    1. pointer operator->() const {return &*current;}
      2. 
+
    2. typedef Iterator pointer;
      3. 
+
    
+
+
    
+The first solution is the one chosen by reverse_iterator.  A potential
+disadvantage of this is it may not work well with iterators which return a
+proxy on dereference and that proxy has overloaded operator&().  Proxy
+references often need to overloaad operator&() to return a proxy
+pointer.  That proxy pointer may or may not be the same type as the iterator's
+pointer type.
+
    
+
+
    
+By simply returning the Iterator and taking advantage of the fact that
+the language forwards calls to operator-> automatically until it
+finds a non-class type, the second solution avoids the issue of an overloaded
+operator&() entirely.
+
    
+
+
    Proposed resolution:
    
+
    
+Change the synopsis in 24.4.3.1 [move.iterator]:
+
    
+
+
    typedef typename iterator_traits<Iterator>::pointer pointer;
+
    
+
+
+
+
+
+
+
    
+
    681. Operator functions impossible to compare are defined in [re.submatch.op]
    
+
    Section: 28.9.2 [re.submatch.op] Status: WP
+ Submitter: Nozomu Katoo Date: 2007-05-27
    
+
    View all issues with WP status.
    
+
    Discussion:
    
 
    
-In 20.6.12.3.1 [util.smartptr.weak.const], change:
+In 28.9.2 [re.submatch.op] of N2284, 
+operator functions numbered 31-42 seem impossible to compare.  E.g.: 
 
    
 
 
    
-
    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);
+
    template <class BiIter>
+    bool operator==(typename iterator_traits<BiIter>::value_type const& lhs,
+                    const sub_match<BiIter>& rhs);
 
    
-
    
--4- Requires: For tThe second and
-third constructors, shall not participate in the
-overload resolution unless Y* shall be
-is implicitly convertible to T*.
-
    
+
    
+
    
+-31- Returns: lhs == rhs.str().
+
    
+
    
 
    
 
+
    
+When char* is used as BiIter, iterator_traits<BiIter>::value_type would be 
+char, so that lhs == rhs.str() ends up comparing a char value and an object 
+of std::basic_string<char>.  However, the behaviour of comparison between 
+these two types is not defined in 21.3.8 [string.nonmembers] of N2284.
+ This applies when wchar_t* is used as BiIter. 
+
    
+
+
+
    Proposed resolution:
    
+
    
+Adopt the proposed resolution in
+N2409.
+
    
+
+
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]
    
+
+
 
 
 
+
    
+
    682. basic_regex ctor takes InputIterator or ForwardIterator?
    
+
    Section: 28.8.2 [re.regex.construct] Status: WP
+ Submitter: Eric Niebler Date: 2007-06-03
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+Looking at N2284, 28.8 [re.regex], p3 basic_regex class template synopsis shows this 
+constructor: 
+
    
+
    template <class InputIterator>
+     basic_regex(InputIterator first, InputIterator last, 
+                 flag_type f = regex_constants::ECMAScript);
+
    
+
+
    
+In 28.8.2 [re.regex.construct], p15, the constructor appears with this signature: 
+
    
+
+
    template <class ForwardIterator>
+     basic_regex(ForwardIterator first, ForwardIterator last, 
+                 flag_type f = regex_constants::ECMAScript);
+
    
+
+
    
+ForwardIterator is probably correct, so the synopsis is wrong.
+
    
+
+
    [
+John adds:
+]
    
+
+
+
    
+
    
+I think either could be implemented?  Although an input iterator would 
+probably require an internal copy of the string being made.
+
    
+
    
+I have no strong feelings either way, although I think my original intent 
+was InputIterator. 
+
    
+
    
+
+
+
    Proposed resolution:
    
+
    
+Adopt the proposed resolution in
+N2409.
+
    
+
+
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]
    
+
+
+
+
+
+
    
+
    685. reverse_iterator/move_iterator difference has invalid signatures
    
+
    Section: 24.4.1.3.19 [reverse.iter.opdiff], 24.4.3.3.14 [move.iter.nonmember] Status: WP
+ Submitter: Bo Persson Date: 2007-06-10
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+In C++03 the difference between two reverse_iterators
+
    
+
    ri1 - ri2
+
    
+
    
+is possible to compute only if both iterators have the same base 
+iterator. The result type is the difference_type of the base iterator. 
+
    
+
    
+In the current draft, the operator is defined as 24.4.1.3.19 [reverse.iter.opdiff] 
+
    
+
    template<class Iterator1, class Iterator2> 
+typename reverse_iterator<Iterator>::difference_type 
+   operator-(const reverse_iterator<Iterator1>& x, 
+                    const reverse_iterator<Iterator2>& y);
+
    
+
    
+The return type is the same as the C++03 one, based on the no longer 
+present Iterator template parameter. 
+
    
+
    
+Besides being slightly invalid, should this operator work only when 
+Iterator1 and Iterator2 has the same difference_type? Or should the 
+implementation choose one of them? Which one? 
+
    
+
    
+The same problem now also appears in operator-() for move_iterator
+24.4.3.3.14 [move.iter.nonmember]. 
+
    
+
+
+
    Proposed resolution:
    
+
    
+Change the synopsis in 24.4.1.1 [reverse.iterator]:
+
    
+
+
    
+
    template <class Iterator1, class Iterator2> 
+  typename reverse_iterator<Iterator>::difference_type auto operator-( 
+    const reverse_iterator<Iterator1>& x, 
+    const reverse_iterator<Iterator2>& y) -> decltype(y.current - x.current);
+
    
+
    
+
+
    
+Change 24.4.1.3.19 [reverse.iter.opdiff]:
+
    
+
+
    
+
    template <class Iterator1, class Iterator2> 
+  typename reverse_iterator<Iterator>::difference_type auto operator-( 
+    const reverse_iterator<Iterator1>& x, 
+    const reverse_iterator<Iterator2>& y) -> decltype(y.current - x.current);
+
    
+
    
+
    
+Returns: y.current - x.current.
+
    
+
    
+
    
+
+
+
    
+Change the synopsis in 24.4.3.1 [move.iterator]:
+
    
+
+
    
+
    template <class Iterator1, class Iterator2> 
+  typename move_iterator<Iterator>::difference_type auto operator-( 
+    const move_iterator<Iterator1>& x, 
+    const move_iterator<Iterator2>& y) -> decltype(x.base() - y.base());
+
    
+
    
+
+
    
+Change 24.4.3.3.14 [move.iter.nonmember]:
+
    
+
+
    
+
    template <class Iterator1, class Iterator2> 
+  typename move_iterator<Iterator>::difference_type auto operator-( 
+    const move_iterator<Iterator1>& x, 
+    const move_iterator<Iterator2>& y) -> decltype(x.base() - y.base());
+
    
+
    
+
    
+Returns: x.base() - y.base().
+
    
+
    
+
    
+
+
    [
+Pre Bellevue:  This issue needs to wait until the auto -> return language feature
+goes in.
+]
    
+
+
+
+
+
+
+
+
    
+
    687. shared_ptr conversion constructor not constrained
    
+
    Section: 20.7.12.2.1 [util.smartptr.shared.const], 20.7.12.3.1 [util.smartptr.weak.const] Status: WP
+ Submitter: Peter Dimov Date: 2007-05-10
    
+
    View all other issues in [util.smartptr.shared.const].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+Since all conversions from shared_ptr<T> to shared_ptr<U> have the same
+rank regardless of the relationship between T and U, reasonable user
+code that works with raw pointers fails with shared_ptr:
+
    
+
+
    void f( shared_ptr<void> );
+void f( shared_ptr<int> );
+
+int main()
+{
+  f( shared_ptr<double>() ); // ambiguous
+}
+
    
+
+
    
+Now that we officially have enable_if, we can constrain the constructor
+and the corresponding assignment operator to only participate in the
+overload resolution when the pointer types are compatible.
+
    
+
+
+
    Proposed resolution:
    
+
    
+In 20.7.12.2.1 [util.smartptr.shared.const], change:
+
    
+
+
    
+-14- Requires: For the second constructor The
+second constructor shall not participate in the overload resolution
+unless Y* shall be is implicitly convertible
+to T*.
+
    
+
+
    
+In 20.7.12.3.1 [util.smartptr.weak.const], change:
+
    
+
+
    
+
    template<class Y> weak_ptr(shared_ptr<Y> const& r);
+weak_ptr(weak_ptr const& r);
+template<class Y> weak_ptr(weak_ptr<Y> const& r);
+weak_ptr(weak_ptr const& r);
+template<class Y> weak_ptr(weak_ptr<Y> const& r);
+template<class Y> weak_ptr(shared_ptr<Y> const& r);
+
    
+
    
+-4- Requires: For tThe second and
+third constructors, shall not participate in the
+overload resolution unless Y* shall be
+is implicitly convertible to T*.
+
    
+
    
+
+
+
+
+
+
+
    
+
    689. reference_wrapper constructor overly constrained
    
+
    Section: 20.6.5.1 [refwrap.const] Status: WP
+ Submitter: Peter Dimov Date: 2007-05-10
    
+
    View all other issues in [refwrap.const].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+The constructor of reference_wrapper is currently explicit. The primary
+motivation behind this is the safety problem with respect to rvalues,
+which is addressed by the proposed resolution of the previous issue.
+Therefore we should consider relaxing the requirements on the
+constructor since requests for the implicit conversion keep resurfacing.
+
    
+
    
+Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Remove the explicit from the constructor of reference_wrapper. If the
+proposed resolution of the previous issue is accepted, remove the
+explicit from the T&& constructor as well to keep them in sync.
+
    
+
+
+
+
+
+
    
+
    693. std::bitset::all() missing
    
+
    Section: 23.3.5 [template.bitset] Status: WP
+ Submitter: Martin Sebor Date: 2007-06-22
    
+
    View all other issues in [template.bitset].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+The  bitset class template  provides the  member function
+any() to determine whether an  object of the type has any
+bits  set, and  the member  function none()  to determine
+whether all of an object's  bits are clear. However, the template does
+not   provide  a   corresponding  function   to  discover   whether  a
+bitset  object  has  all  its  bits  set.   While  it  is
+possible,  even easy,  to  obtain this  information  by comparing  the
+result of count()  with the result of size()
+for  equality  (i.e.,  via  b.count()  ==  b.size())  the
+operation  is   less  efficient   than  a  member   function  designed
+specifically  for that purpose  could be.   (count() must
+count  all non-zero bits  in a  bitset a  word at  a time
+while all() could stop counting as soon as it encountered
+the first word with a zero bit).
+
    
+
+
+
    Proposed resolution:
    
+
    
+Add  a declaration of the new  member function all() to the
+defintion of the bitset template in 23.3.5 [template.bitset], p1,
+right above the declaration of any() as shown below:
+
    
+
+
    bool operator!=(const bitset<N>& rhs) const;
+bool test(size_t pos) const;
+bool all() const;
+bool any() const;
+bool none() const;
+
    
+
+
    
+Add a description of the new member function to the end of 23.3.5.2 [bitset.members] with the following text:
+
    
+
    
+bool all() const;
+
    
+
    
+Returns: count() == size().
+
    
+
    
+
+
    
+In  addition,   change  the  description   of  any()  and
+none()   for  consistency   with   all()  as
+follows:
+
    
+
    
+bool any() const;
+
    
+
    
+
    
+Returns: true if any bit in *this
+is onecount() != 0.
+
    
+
    
+
    
+bool none() const;
+
    
+
    
+
    
+Returns: true if no bit in *this
+is onecount() == 0.
+
    
+
    
+
    
+
+
+
+
+
+
    
+
    694. std::bitset and long long
    
+
    Section: 23.3.5 [template.bitset] Status: WP
+ Submitter: Martin Sebor Date: 2007-06-22
    
+
    View all other issues in [template.bitset].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+Objects of the  bitset class template specializations can
+be constructed from  and explicitly converted to values  of the widest
+C++ integer  type, unsigned long.   With the introduction
+of  long long into  the language  the template  should be
+enhanced to make it possible  to interoperate with values of this type
+as well, or  perhaps uintmax_t.  See c++std-lib-18274 for
+a brief discussion in support of this change.
+
    
+
+
+
    Proposed resolution:
    
+
    
+For simplicity,  instead of  adding overloads for  unsigned long
+long and dealing with possible ambiguities in the spec, replace
+the bitset ctor  that takes an unsigned long
+argument  with  one  taking  unsigned long  long  in  the
+definition  of the  template as  shown below.   (The  standard permits
+implementations  to add  overloads on  other integer  types  or employ
+template tricks to  achieve the same effect provided  they don't cause
+ambiguities or changes in behavior.)
+
    
+
    
+
    // [bitset.cons] constructors:
+bitset();
+bitset(unsigned long long val);
+template<class charT, class traits, class Allocator>
+explicit bitset(
+                const basic_string<charT,traits,Allocator>& str,
+                typename basic_string<charT,traits,Allocator>::size_type pos = 0,
+                typename basic_string<charT,traits,Allocator>::size_type n =
+                    basic_string<charT,traits,Allocator>::npos);
+
    
+
    
+
    
+Make a corresponding change in 23.3.5.1 [bitset.cons], p2:
+
    
+
    
+
    
+bitset(unsigned long long val);
+
    
+
    
+Effects:  Constructs   an  object  of   class  bitset<N>,
+initializing  the  first M  bit  positions to  the
+corresponding      bit     values      in     val.
+M is the  smaller of N and the
+number of bits in  the value representation (section [basic.types]) of
+unsigned   long long.   If  M <
+N  is  true,  the remaining  bit
+positions are initialized to zero.
+
    
+
    
+
+
    
+Additionally, introduce a new member function to_ullong()
+to make  it possible to  convert bitset to values  of the
+new  type. Add  the following  declaration  to the  definition of  the
+template, immediate  after the declaration  of to_ulong()
+in 23.3.5 [template.bitset], p1, as shown below:
+
    
+
    
+
    // element access:
+bool operator[](size_t pos) const; // for b[i];
+reference operator[](size_t pos); // for b[i];
+unsigned long to_ulong() const;
+unsigned long long to_ullong() const;
+template <class charT, class traits, class Allocator>
+basic_string<charT, traits, Allocator> to_string() const;
+
    
+
    
+
    
+And add a description of  the new member function to 23.3.5.2 [bitset.members],
+below  the  description of  the  existing to_ulong()  (if
+possible), with the following text:
+
    
+
    
+
    
+unsigned long long to_ullong() const;
+
    
+
    
+Throws:  overflow_error   if  the  integral  value
+x corresponding to  the bits in *this
+cannot be represented as type unsigned long long.
+
    
+
    
+Returns: x.
+
    
+
    
+
+
+
+
+
+
    
+
    695. ctype<char>::classic_table() not accessible
    
+
    Section: 22.2.1.3 [facet.ctype.special] Status: WP
+ Submitter: Martin Sebor Date: 2007-06-22
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+The   ctype<char>::classic_table()   static  member
+function    returns    a    pointer    to   an    array    of    const
+ctype_base::mask    objects    (enums)   that    contains
+ctype<char>::table_size    elements.    The   table
+describes the properties of the character set in the "C" locale (i.e.,
+whether a  character at an index  given by its value  is alpha, digit,
+punct,   etc.),   and   is    typically   used   to   initialize   the
+ctype<char>  facet in the  classic "C"  locale (the
+protected      ctype<char>      member     function
+table()    then    returns     the    same    value    as
+classic_table()).
+
    
+
    
+However, while ctype<char>::table_size (the size of
+the   table)    is   a   public    static   const   member    of   the
+ctype<char>           specialization,           the
+classic_table() static member function is protected. That
+makes getting at the classic  data less than convenient (i.e., one has
+to create  a whole derived class just  to get at the  masks array). It
+makes  little sense  to expose  the size  of the  table in  the public
+interface while making the table itself protected, especially when the
+table is a constant object.
+
    
+
    
+The  same argument  can be  made for  the non-static  protected member
+function table().
+
    
+
+
+
    Proposed resolution:
    
+
    
+Make     the    ctype<char>::classic_table()    and
+ctype<char>::table()  member  functions  public  by
+moving their declarations into the public section of the definition of
+specialization in 22.2.1.3 [facet.ctype.special] as shown below:
+
    
+
    
+
      static locale::id id;
+  static const size_t table_size = IMPLEMENTATION_DEFINED;
+protected:
+  const mask* table() const throw();
+  static const mask* classic_table() throw();
+protected:
+
+~ctype(); // virtual
+virtual char do_toupper(char c) const;
+
    
+
    
+
+
+
+
+
+
    
+
    699. N2111 changes min/max
    
+
    Section: 26.4 [rand] Status: WP
+ Submitter: P.J. Plauger Date: 2007-07-01
    
+
    View all other issues in [rand].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+N2111
+changes min/max in several places in random from member
+functions to static data members. I believe this introduces
+a needless backward compatibility problem between C++0X and
+TR1. I'd like us to find new names for the static data members,
+or perhaps change min/max to constexprs in C++0X.
+
    
+
+
    
+See N2391 and
+N2423
+for some further discussion.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Adopt the proposed resolution in
+N2423.
+
    
+
+
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]
    
+
+
+
+
+
+
    
+
    700. N1856 defines struct identity
    
+
    Section: 20.2.2 [forward] Status: WP
+ Submitter: P.J. Plauger Date: 2007-07-01
    
+
    View other active issues in [forward].
    
+
    View all other issues in [forward].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+N1856
+defines struct identity in <utility> which clashes with
+the traditional definition of struct identity in <functional>
+(not standard, but a common extension from old STL). Be nice
+if we could avoid this name clash for backward compatibility.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Change 20.2.2 [forward]:
+
    
+
+
    
+
    template <class T> struct identity
+{
+    typedef T type;
+    const T& operator()(const T& x) const;
+};
+
    
+
    
+
    const T& operator()(const T& x) const;
+
    
+
    
+
    
+Returns: x.
+
    
+
    
+
    
+
+
    
+
+
+
+
+
+
+
    
+
    703. map::at() need a complexity specification
    
+
    Section: 23.3.1.2 [map.access] Status: WP
+ Submitter: Joe Gottman Date: 2007-07-03
    
+
    View all other issues in [map.access].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+map::at() need a complexity specification.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Add the following to the specification of map::at(), 23.3.1.2 [map.access]:
+
    
+
    
+
    
+Complexity: logarithmic.
+
    
+
    
+
+
+
+
+
+
    
+
    705. type-trait decay incompletely specified
    
+
    Section: 20.5.7 [meta.trans.other] Status: WP
+ Submitter: Thorsten Ottosen Date: 2007-07-08
    
+
    View other active issues in [meta.trans.other].
    
+
    View all other issues in [meta.trans.other].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+The current working draft has a type-trait decay in 20.5.7 [meta.trans.other].
+
    
+
+
    
+Its use is to turn C++03 pass-by-value parameters into efficient C++0x
+pass-by-rvalue-reference parameters. However, the current definition
+introduces an incompatible change where the cv-qualification of the
+parameter type is retained. The deduced type should loose such
+cv-qualification, as pass-by-value does.
+
    
+
+
+
    Proposed resolution:
    
+
    
+In 20.5.7 [meta.trans.other] change the last sentence:
+
    
+
+
    
+Otherwise the  member typedef type equals remove_cv<U>::type.
+
    
+
+
    
+In 20.4.1.3 [tuple.creation]/1 change:
+
    
+
+
    
+where each Vi in VTypes is X& if, for the
+corresponding type Ti in Types,
+remove_cv<remove_reference<Ti>::type>::type equals
+reference_wrapper<X>, otherwise Vi is
+decay<Ti>::type.
+Let Ui be decay<Ti>::type for each
+Ti in Types. Then each Vi in VTypes
+is X& if Ui equals
+reference_wrapper<X>, otherwise Vi is
+Ui.
+
    
+
+
+
+
+
+
+
    
+
    706. make_pair() should behave as make_tuple() wrt. reference_wrapper()
    
+
    Section: 20.2.3 [pairs] Status: WP
+ Submitter: Thorsten Ottosen Date: 2007-07-08
    
+
    View all other issues in [pairs].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+The current draft has make_pair() in 20.2.3 [pairs]/16
+and make_tuple() in 20.4.1.3 [tuple.creation].
+make_tuple() detects the presence of
+reference_wrapper<X> arguments and "unwraps" the reference in
+such cases. make_pair() would OTOH create a
+reference_wrapper<X> member. I suggest that the two
+functions are made to behave similar in this respect to minimize
+confusion.
+
    
+
+
+
    Proposed resolution:
    
+
    
+In 20.2 [utility] change the synopsis for make_pair() to read
+
    
+
+
    template <class T1, class T2>
+  pair<typename decay<T1>::type V1, typename decay<T2>::type V2> make_pair(T1&&, T2&&);
+
    
+
+
    
+In 20.2.3 [pairs]/16 change the declaration to match the above synopsis.
+Then change the 20.2.3 [pairs]/17 to:
+
    
+
+
    
+
    
+Returns: pair<typename decay<T1>::type V1,typename decay<T2>::type V2>(forward<T1>(x),forward<T2>(y)) where V1 and
+V2 are determined as follows: Let Ui be
+decay<Ti>::type for each Ti. Then each
+Vi is X& if Ui equals
+reference_wrapper<X>, otherwise Vi is
+Ui.
+
    
+
    
+
+
+
+
+
+
+
    
+
    710. Missing postconditions
    
+
    Section: 20.7.12.2 [util.smartptr.shared] Status: WP
+ 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 WP 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.
+
    
+
+
    [
+Bellevue:
+]
    
+
+
+
    
+
    
+Move to "ready", adopting the first (Peter's) proposed resolution.
+
    
+
    
+Note to the project editor: there is an editorial issue here. The
+wording for the postconditions of the casts is slightly awkward, and the
+editor should consider rewording "If w is the return value...", e. g. as
+"For a return value w...".
+
    
+
    
+
+
+
    Proposed resolution:
    
+
    
+Add to 20.7.12.2.1 [util.smartptr.shared.const]:
+
    
+
+
    
+
    shared_ptr(shared_ptr&& r);
+template<class Y> shared_ptr(shared_ptr<Y>&& r);
+
    
+
    
+
    
+Postconditions:  *this shall contain the old value of r. r
+shall be empty. r.get() == 0.
+
    
+
    
+
    
+
+
    
+Add to 20.7.12.2.10 [util.smartptr.shared.cast]:
+
    
+
+
    
+
    template<class T, class U> shared_ptr<T> static_pointer_cast(shared_ptr<U> const& r);
+
    
+
    
+
    
+Postconditions: If w is the return value,
+w.get() == static_cast<T*>(r.get()) && w.use_count() == r.use_count().
+
    
+
    
+
    
+
+
    
+
    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()).
+
    
+
    
+
    
+
+
    
+
    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.7.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()).
+
    
+
    
+
+
    
+
    
+-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".
+
    
+
+
+
+
+
+
+
    
+
    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:
    
+
    
+One of the motivations for incorporating seed_seq::size()
+was to simplify the wording
+in other parts of 26.4 [rand].
+As a side effect of resolving related issues,
+all such references
+to seed_seq::size() will have been excised.
+More importantly,
+the present specification is contradictory,
+as "The number of 32-bit units the object can deliver"
+is not the same as "the result of v.size()."
+
    
+
+
    
+See N2391 and
+N2423
+for some further discussion.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Adopt the proposed resolution in
+N2423.
+
    
+
+
+
    [
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]
    
+
+
+
+
+
+
    
+
    715. minmax_element complexity is too lax
    
+
    Section: 25.3.7 [alg.min.max] Status: WP
+ Submitter: Matt Austern Date: 2007-08-30
    
+
    View all other issues in [alg.min.max].
    
+
    View all issues with WP status.
    
+
    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).
+
    
+
+
+
    Proposed resolution:
    
+
    
+Change 25.3.7 [alg.min.max] to:
+
    
+
+
    
+
    template<class ForwardIterator> 
+  pair<ForwardIterator, ForwardIterator> 
+    minmax_element(ForwardIterator first , ForwardIterator last); 
+template<class ForwardIterator, class Compare> 
+  pair<ForwardIterator, ForwardIterator> 
+    minmax_element(ForwardIterator first , ForwardIterator last , Compare comp);
+
    
+
    
+
    
+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.
+
    
+
    
+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).
+
    
+
    
+
    
+
+
+
+
+
+
+
    
+
    722. Missing [c.math] functions nanf and nanl
    
+
    Section: 26.7 [c.math] Status: WP
+ Submitter: Daniel Krügler Date: 2007-08-27
    
+
    View all other issues in [c.math].
    
+
    View all issues with WP 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):
+
    
+
+
    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)
+
    
+
+
+
    Proposed resolution:
    
+
    
+In 26.7 [c.math], table 108, section "Functions", add nanf and nanl
+just after the existing entry nan.
+
    
+
+
+
+
+
+
    
+
    740. Please remove *_ptr<T[N]>
    
+
    Section: 20.7.11.4 [unique.ptr.compiletime] Status: WP
+ Submitter: Herb Sutter Date: 2007-10-04
    
+
    View all issues with WP status.
    
+
    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.
+
    
+
+
    
+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).
+
    
+
+
    
+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. :-)
+
    
+
+
    [
+Bellevue:
+]
    
+
+
+
    
+
    Suggestion that fixed-size array instantiations are going to fail at
+compile time anyway (if we remove specialization) due to pointer decay,
+at least that appears to be result from available compilers.
+
    
+
    
+So concerns about about requiring static_assert seem unfounded.
+
    
+
    After a little more experimentation with compiler, it appears that
+fixed size arrays would only work at all if we supply these explicit
+specialization. So removing them appears less breaking than originally
+thought.
+
    
+
    
+straw poll unanimous move to Ready.
+
    
+
    
+
+
+
+
    Proposed resolution:
    
+
    
+Change the synopsis under 20.7.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.7.11.1.3 [unique.ptr.dltr.dflt2] default_delete<T[N]>.
+
    
+
+
    
+Remove the entire section 20.7.11.4 [unique.ptr.compiletime] unique_ptr for array objects with a compile time length
+and its subsections: 20.7.11.4.1 [unique.ptr.compiletime.dtor], 20.7.11.4.2 [unique.ptr.compiletime.observers],
+20.7.11.4.3 [unique.ptr.compiletime.modifiers].
+
    
+
+
+
+
+
+
+
    
+
    743. rvalue swap for shared_ptr
    
+
    Section: 20.7.12.2.9 [util.smartptr.shared.spec] Status: WP
+ Submitter: Howard Hinnant Date: 2007-10-10
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+When the LWG looked at 674 in Kona the following note was made:
+
    
+
+
    
+We may need to open an issue to deal with the question of
+whether shared_ptr needs an rvalue swap.
+
    
+
+
    
+This issue was opened in response to that note.
+
    
+
+
    
+I believe allowing rvalue shared_ptrs to swap is both
+appropriate, and consistent with how other library components are currently specified.
+
    
+
+
    [
+Bellevue:
+]
    
+
+
+
    
+
    
+Concern that the three signatures for swap is needlessly complicated,
+but this issue merely brings shared_ptr into equal complexity with the
+rest of the library. Will open a new issue for concern about triplicate
+signatures.
+
    
+
    
+Adopt issue as written.
+
    
+
    
+
+
+
    Proposed resolution:
    
+
    
+Change the synopsis in 20.7.12.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);
+
    
+
+
    
+Change 20.7.12.2.4 [util.smartptr.shared.mod]:
+
    
+
+
    void swap(shared_ptr&& r);
+
    
+
+
    
+Change 20.7.12.2.9 [util.smartptr.shared.spec]:
+
    
+
+
    template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b);
+template<class T> void swap(shared_ptr<T>&& a, shared_ptr<T>& b);
+template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>&& b);
+
    
+
+
+
+
+
+
    
+
    744. What is the lifetime of an exception pointed to by an exception_ptr?
    
+
    Section: 18.7.5 [propagation] Status: WP
+ Submitter: Alisdair Meredith Date: 2007-10-10
    
+
    View other active issues in [propagation].
    
+
    View all other issues in [propagation].
    
+
    View all issues with WP 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.
+
    
+
    
+(Peter Dimov agreed it should be clearer, maybe a non-normative note to
+explain?)
+
    
+
+
    [
+Bellevue:
+]
    
+
+
+
    
+
    
+Agree the issue is real.
+
    
+
    
+Intent is lifetime is similar to a shared_ptr (and we might even want to
+consider explicitly saying that it is a shared_ptr< unspecified type >).
+
    
+
    
+We expect that most implementations will use shared_ptr, and the
+standard should be clear that the exception_ptr type is intended to be
+something whose semantics are smart-pointer-like so that the user does
+not need to worry about lifetime management. We still need someone to
+draught those words - suggest emailing Peter Dimov.
+
    
+
    
+Move to Open.
+
    
+
    
+
+
+
    Proposed resolution:
    
+
    
+Change 18.7.5 [propagation]/7:
+
    
+
+
    
+-7- Returns: An exception_ptr object that refers to the currently
+handled exception or a copy of the currently handled exception, or a
+null exception_ptr object if no exception is being handled.
+The referenced object remains valid at least as long as there is an
+exception_ptr that refers to it.
+If the function needs to allocate memory and the attempt
+fails, it returns an exception_ptr object that refers to an instance of
+bad_alloc. It is unspecified whether the return values of two successive
+calls to current_exception refer to the same exception object. [Note:
+that is, it is unspecified whether current_exception creates a new copy
+each time it is called. --end note]
+
    
+
+
+
+
+
+
    
+
    746. current_exception may fail with bad_alloc
    
+
    Section: 18.7.5 [propagation] Status: WP
+ Submitter: Alisdair Meredith Date: 2007-10-10
    
+
    View other active issues in [propagation].
    
+
    View all other issues in [propagation].
    
+
    View all issues with WP 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:
+
    
+
    
+
    
+Any other allocation function that fails to allocate storage shall indicate
+failure only by throwing an exception of a type that would match a handler
+(15.3) of type std::bad_alloc (18.5.2.1).
+
    
+
    
+
    
+I think we should allow similar freedom here (or add a blanket
+compatible-exception freedom paragraph in 17)
+
    
+
    
+I prefer the clause 17 approach myself, and maybe clean up any outstanding
+wording that could also rely on it.
+
    
+
    
+Although filed against a specific case, this issue is a problem throughout
+the library. 
+
    
+
+
    [
+Bellevue:
+]
    
+
+
+
    
+
    
+Is issue bigger than library?
+
    
+
    
+No - Core are already very clear about their wording, which is inspiration for the issue.
+
    
+
    
+While not sold on the original 18.7.5 use case, the generalised 17.4.4.8 wording is the real issue.
+
    
+
    
+Accept the broad view and move to ready
+
    
+
    
+
+
+
    Proposed resolution:
    
+
    
+Add the following exemption clause to 17.4.4.9 [res.on.exception.handling]:
+
    
+
+
    
+A function may throw a type not listed in its Throws clause so long as it is
+derived from a class named in the Throws clause, and would be caught by an
+exception handler for the base type.
+
    
+
+
+
+
+
+
    
+
    749. Currently has_nothrow_copy_constructor<T>::value is true if T has 'a' nothrow copy constructor.
    
+
    Section: 20.5.4.3 [meta.unary.prop] Status: WP
+ Submitter: Alisdair Meredith Date: 2007-10-10
    
+
    View all other issues in [meta.unary.prop].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+Unfortunately a class can have multiple copy constructors, and I believe to
+be useful this trait should only return true is ALL copy constructors are
+no-throw.
+
    
+
    
+For instance:
+
    
+
    
+
    struct awkward {
+ awkward( const awkward & ) throw() {}
+ awkward( awkward & ) { throw "oops"; } };
+
    
+
    
+
+
+
    Proposed resolution:
    
+
    
+Change 20.5.4.3 [meta.unary.prop]:
+
    
+
+
    
+
    has_trivial_copy_constructor
    
+
    
+T is a trivial type (3.9) or a reference type or a class type with a trivial copy constructor
+where all copy constructors are trivial (12.8).
+
    
+
    
+
+
    
+
    has_trivial_assign
    
+
    
+T is neither const nor a reference type, and T is a trivial type (3.9)
+or a class type with a trivial copy assignment operator where all copy assignment operators are trivial (12.8).
+
    
+
    
+
+
    
+
    has_nothrow_copy_constructor
    
+
    
+has_trivial_copy_constructor<T>::value is true or T is a class type with
+a where all copy constructors that is are 
+known not to throw any exceptions or T is an
+array of such a class type
+
    
+
    
+
+
    
+
    has_nothrow_assign
    
+
    
+T is neither const nor a reference type, and
+has_trivial_assign<T>::value is true or T is a class type with a
+where all copy
+assignment operators takeing an lvalue of type T that is known not to
+throw any exceptions or T is an array of such a class type.
+
    
+
    
+
+
+
+
+
+
+
    
+
    755. std::vector and std:string lack explicit shrink-to-fit operations
    
+
    Section: 23.2.6.2 [vector.capacity], 21.3.4 [string.capacity] Status: WP
+ Submitter: Beman Dawes Date: 2007-10-31
    
+
    View all other issues in [vector.capacity].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+A std::vector can be shrunk-to-fit via the swap idiom:
+
    
+
+
    vector<int> v;
+...
+v.swap(vector<int>(v));  // shrink to fit
+
    
+
    
+or:
+
    
+
    vector<int>(v).swap(v);  // shrink to fit
+
    
+
    
+or:
+
    
+
    swap(v, vector<int>(v));  // shrink to fit
+
    
+
    
+
+
    
+A non-binding request for shrink-to-fit can be made to a std::string via:
+
    
+
+
    string s;
+...
+s.reserve(0);
+
    
+
+
    
+Neither of these is at all obvious to beginners, and even some
+experienced C++ programmers are not aware that shrink-to-fit is
+trivially available.
+
    
+
    
+Lack of explicit functions to perform these commonly requested
+operations makes vector and string less usable for non-experts. Because
+the idioms are somewhat obscure, code readability is impaired. It is
+also unfortunate that two similar vector-like containers use different
+syntax for the same operation.
+
    
+
    
+The proposed resolution addresses these concerns. The proposed function
+takes no arguments to keep the solution simple and focused.
+
    
+
+
+
    Proposed resolution:
    
+
    
+To Class template basic_string 21.3 [basic.string] synopsis,
+Class template vector 23.2.6 [vector] synopsis, and Class
+vector<bool> 23.2.7 [vector.bool] synopsis, add:
+
    
+
+
        
+void shrink_to_fit();
+
    
+
+
    
+To basic_string capacity 21.3.4 [string.capacity] and vector
+capacity 23.2.6.2 [vector.capacity], add:
+
    
+
+
    
+
    void shrink_to_fit();
+
    
+
    
+Remarks: shrink_to_fit is a non-binding request to reduce
+capacity() to size(). [Note: The request is non-binding to
+allow latitude for implementation-specific optimizations.
+-- end note]
+
    
+
    
+
+
    [
+850 has been added to deal with this issue with respect to deque.
+]
    
+
+
+
+
+
+
+
    
+
    759. A reference is not an object
    
+
    Section: 23.1 [container.requirements] Status: WP
+ Submitter: Jens Maurer Date: 2007-11-06
    
+
    View other active issues in [container.requirements].
    
+
    View all other issues in [container.requirements].
    
+
    View all issues with WP 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.
+
    
+
+
+
+
+
+
+
    
+
    761. unordered_map needs an at() member function
    
+
    Section: 23.4.1.2 [unord.map.elem] Status: WP
+ Submitter: Joe Gottman Date: 2007-11-15
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+The new member function at() was recently added to std::map().  It acts 
+like operator[](), except it throws an exception when the input key is 
+not found.  It is useful when the map is const, the value_type of the 
+key doesn't have  a default constructor, it is an error if the key is 
+not found, or the user wants to avoid accidentally adding an element to 
+the map.  For exactly these same reasons, at() would be equally useful 
+in std::unordered_map.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Add the following functions to the definition of unordered_map under "lookup" (23.4.1 [unord.map]):
+
    
+
+
    mapped_type& at(const key_type& k);
+const mapped_type &at(const key_type &k) const;
+
    
+
+
    
+Add the following definitions to 23.4.1.2 [unord.map.elem]:
+
    
+
+
    
+
    mapped_type& at(const key_type& k);
+const mapped_type &at(const key_type &k) const;
+
    
+
    
+
    
+Returns: A reference to x.second, where x is the (unique) element 
+whose key is equivalent to k.
+
    
+
    
+Throws: An exception object of type out_of_range if no such element 
+is present.
+
    
+
    
+
    
+
+
    [
+Bellevue:  Editorial note: the "(unique)" differs from map.
+]
    
+
+
+
+
+
+
+
+
    
+
    766. Inconsistent exception guarantees between ordered and unordered associative containers
    
+
    Section: 23.1 [container.requirements], 23.1.5.1 [unord.req.except] Status: WP
+ Submitter: Ion Gaztañaga Date: 2007-12-22
    
+
    View other active issues in [container.requirements].
    
+
    View all other issues in [container.requirements].
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+23.1 [container.requirements]p10 states:
+
    
+
+
    
+
    
+Unless otherwise specified (see 23.2.2.3 and 23.2.5.4) all container types defined in this clause meet the following
+additional requirements:
+
    
+
      
+
+
    • [...]
      • 
+
+
    • no erase(), pop_back() or pop_front() function throws an exception.
      • 
+
+
    
+
    
+
+
    
+23.2.2.3 [deque.modifiers] and 23.2.6.4 [vector.modifiers] offer
+additional guarantees for deque/vector insert() and
+erase() members. However, 23.1 [container.requirements]p10
+does not mention 23.1.5.1 [unord.req.except] that specifies exception
+safety guarantees
+for unordered containers. In addition, 23.1.5.1 [unord.req.except]p1
+offers the following guaratee for
+erase():
+
    
+
+
    
+No erase() function throws an exception unless that exception
+is thrown by the container's Hash or Pred object (if any).
+
    
+
+
    
+Summary:
+
    
+
+
    
+According to 23.1 [container.requirements]p10 no
+erase() function should throw an exception unless otherwise
+specified. Although does not explicitly mention 23.1.5.1 [unord.req.except], this section offers additional guarantees
+for unordered containers, allowing erase() to throw if
+predicate or hash function throws.
+
    
+
+
    
+In contrast, associative containers have no exception safety guarantees
+section so no erase() function should throw, including
+erase(k) that needs to use the predicate function to
+perform its work. This means that the predicate of an associative
+container is not allowed to throw.
+
    
+
+
    
+So:
+
    
+
+
      
+
    1. 
+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:
    
+
    
+Create a new sub-section of 23.1.4 [associative.reqmts] (perhaps [associative.req.except]) titled "Exception
+safety guarantees".
+
    
+
+
    
+
    
+1 For associative containers, no clear() function throws an exception.
+erase(k) does not throw an exception unless that exception is thrown by
+the container's Pred object (if any).
+
    
+
+
    
+2 For associative containers, if an exception is thrown by any operation
+from within an insert() function inserting a single element, the
+insert() function has no effect.
+
    
+
+
    
+3 For associative containers, no swap function throws an exception
+unless that exception is thrown by the copy constructor or copy
+assignment operator of the container's Pred object (if any).
+
    
+
    
+
+
    
+Change 23.1.5.1 [unord.req.except]p1:
+
    
+
+
    
+For unordered associative containers, no clear() function
+throws an exception. No erase(k)
+function does not throws an exception
+unless that exception is thrown by the container's Hash or Pred object
+(if any).
+
    
+
+
    
+Change 23.1 [container.requirements]p10 to add references to new sections:
+
    
+
+
    
+Unless otherwise specified (see [deque.modifiers],
+and [vector.modifiers], [associative.req.except],
+[unord.req.except]) all container types defined in this clause meet
+the following additional requirements:
+
    
+
+
    
+Change 23.1 [container.requirements]p10 referring to swap:
+
    
+
+
    
+
      
+
    • 
+no swap() function throws an exception unless that exception is thrown
+by the copy constructor or assignment operator of the container's
+Compare object (if any; see [associative.reqmts]).
+
      • 
+
    
+
    
+
+
+
+
+
+
+
    
+
    768. Typos in [atomics]?
    
+
    Section: 29.3.3 [atomics.types.generic] Status: WP
+ Submitter: Alberto Ganesh Barbati Date: 2007-12-28
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+in the latest publicly available draft, paper
+N2641,
+in section 29.3.3 [atomics.types.generic], the following specialization of the template
+atomic<> is provided for pointers:
+
    
+
+
    template <class T> struct atomic<T*> : atomic_address { 
+  T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
+  T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
+
+  atomic() = default; 
+  constexpr explicit atomic(T); 
+  atomic(const atomic&) = delete; 
+  atomic& operator=(const atomic&) = delete; 
+
+  T* operator=(T*) volatile; 
+  T* operator++(int) volatile; 
+  T* operator--(int) volatile; 
+  T* operator++() volatile; 
+  T* operator--() volatile; 
+  T* operator+=(ptrdiff_t) volatile;
+  T* operator-=(ptrdiff_t) volatile; 
+};
+
    
+
+
    
+First of all, there is a typo in the non-default constructor which
+should take a T* rather than a T.
+
    
+
+
    
+As you can see, the specialization redefine and therefore hide a few
+methods from the base class atomic_address, namely fetch_add, fetch_sub,
+operator=, operator+= and operator-=. That's good, but... what happened
+to the other methods, in particular these ones:
+
    
+
+
    void store(T*, memory_order = memory_order_seq_cst) volatile;
+T* load( memory_order = memory_order_seq_cst ) volatile;
+T* swap( T*, memory_order = memory_order_seq_cst ) volatile;
+bool compare_swap( T*&, T*, memory_order, memory_order ) volatile;
+bool compare_swap( T*&, T*, memory_order = memory_order_seq_cst ) volatile;
+
    
+
+
    
+By reading paper
+N2427 "C++ Atomic Types and Operations",
+I see that the
+definition of the specialization atomic<T*> matches the one in the
+draft, but in the example implementation the methods load(), swap()
+and compare_swap() are indeed present.
+
    
+
+
    
+Strangely, the example implementation does not redefine the method
+store(). It's true that a T* is always convertible to void*, but not
+hiding the void* signature from the base class makes the class
+error-prone to say the least: it lets you assign pointers of any type to
+a T*, without any hint from the compiler.
+
    
+
+
    
+Is there a true intent to remove them from the specialization or are
+they just missing from the definition because of a mistake?
+
    
+
+
    [
+Bellevue:
+]
    
+
+
+
    
+
    
+The proposed revisions are accepted.
+
    
+
    
+Further discussion: why is the ctor labeled "constexpr"? Lawrence said
+this permits the object to be statically initialized, and that's
+important because otherwise there would be a race condition on
+initialization.
+
    
+
    
+
+
+
    Proposed resolution:
    
+
    
+Change the synopsis in 29.3.3 [atomics.types.generic]:
+
    
+
+
    template <class T> struct atomic<T*> : atomic_address { 
+  void store(T*, memory_order = memory_order_seq_cst) volatile;
+  T* load( memory_order = memory_order_seq_cst ) volatile;
+  T* swap( T*, memory_order = memory_order_seq_cst ) volatile;
+  bool compare_swap( T*&, T*, memory_order, memory_order ) volatile;
+  bool compare_swap( T*&, T*, memory_order = memory_order_seq_cst ) volatile;
+
+  T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
+  T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
+
+  atomic() = default; 
+  constexpr explicit atomic(T*); 
+  atomic(const atomic&) = delete; 
+  atomic& operator=(const atomic&) = delete; 
+
+  T* operator=(T*) volatile; 
+  T* operator++(int) volatile; 
+  T* operator--(int) volatile; 
+  T* operator++() volatile; 
+  T* operator--() volatile; 
+  T* operator+=(ptrdiff_t) volatile;
+  T* operator-=(ptrdiff_t) volatile; 
+};
+
    
+
+
+
+
+
+
+
    
+
    770. std::function should use rvalue swap
    
+
    Section: 20.6.15 [func.wrap] Status: WP
+ Submitter: Daniel Krügler Date: 2008-01-10
    
+
    View all issues with WP status.
    
+
    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.6 [function.objects], header <functional> synopsis, just below of
+
    
+
+
    template<class R, class... ArgTypes>
+  void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&);
+template<class R, class... ArgTypes>
+  void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&);
+template<class R, class... ArgTypes>
+  void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&&);
+
    
+
+
    
+In 20.6.15.2 [func.wrap.func] class function definition, change
+
    
+
+
    void swap(function&&);
+
    
+
+
    
+In 20.6.15.2 [func.wrap.func], just below of
+
    
+
+
    template <class R, class... ArgTypes>
+  void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&);
+template <class R, class... ArgTypes>
+  void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&);
+template <class R, class... ArgTypes>
+  void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&&);
+
    
+
+
    
+In 20.6.15.2.2 [func.wrap.func.mod] change
+
    
+
+
    void swap(function&& other);
+
    
+
+
    
+In 20.6.15.2.7 [func.wrap.func.alg] add the two overloads
+
    
+
+
    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);
+
    
+
+
+
+
+
+
+
    
+
    775. Tuple indexing should be unsigned?
    
+
    Section: 20.4.1.4 [tuple.helper] Status: WP
+ Submitter: Alisdair Meredith Date: 2008-01-16
    
+
    View all issues with WP status.
    
+
    Discussion:
    
+
    
+The tuple element access API identifies the element in the sequence
+using signed integers, and then goes on to enforce the requirement that
+I be >= 0.  There is a much easier way to do this - declare I as
+unsigned.
+
    
+
    
+In fact the proposal is to use std::size_t, matching the type used in the tuple_size API.
+
    
+
    
+A second suggestion is that it is hard to imagine an API that deduces
+and index at compile time and returns a reference throwing an exception.
+Add a specific Throws: Nothing paragraph to each element
+access API.
+
    
+
    
+In addition to tuple, update the API applies to
+pair and array, and should be updated
+accordingly.
+
    
+
+
    
+A third observation is that the return type of the get
+functions for std::pair is pseudo-code, but it is not
+clearly marked as such.  There is actually no need for pseudo-code as
+the return type can be specified precisely with a call to
+tuple_element.  This is already done for
+std::tuple, and std::array does not have a
+problem as all elements are of type T.
+
    
+
+
+
    Proposed resolution:
    
+
    
+Update header <utility> synopsis in 20.2 [utility]
+
    
+
    // 20.2.3, tuple-like access to pair:
+template <class T> class tuple_size;
+template <intsize_t I, class T> class tuple_element;
+
+template <class T1, class T2> struct tuple_size<std::pair<T1, T2> >;
+template <class T1, class T2> struct tuple_element<0, std::pair<T1, T2> >;
+template <class T1, class T2> struct tuple_element<1, std::pair<T1, T2> >;
+
+template<intsize_t I, class T1, class T2>
+  Ptypename tuple_element<I, std::pair<T1, T2> >::type & get(std::pair<T1, T2>&);
+template<intsize_t I, class T1, class T2>
+  const Ptypename tuple_element<I, std::pair<T1, T2> >::type & get(const std::pair<T1, T2>&);
+
    
+
    
+Update 20.2.3 [pairs] Pairs
+
    
+
    template<intsize_t I, class T1, class T2>
+  Ptypename tuple_element<I, std::pair<T1, T2> >::type & get(pair<T1, T2>&);
+template<intsize_t I, class T1, class T2>
+  const Ptypename tuple_element<I, std::pair<T1, T2> >::type & get(const pair<T1, T2>&);
+
    
+
    
+24 Return type: If I == 0 then P is T1, if I == 1 then P is T2, and otherwise the program is ill-formed.
+
    
+
    
+25 Returns: If I == 0 returns p.first, otherwise if I == 1 returns p.second, and otherwise the program is ill-formed.
+
    
+
    
+Throws: Nothing.
+
    
+
+
+
    
+Update header <tuple> synopsis in 20.4 [tuple] with a APIs as below:
+
    
+
    template <intsize_t I, class T> class tuple_element; // undefined
+template <intsize_t I, class... Types> class tuple_element<I, tuple<Types...> >;
+
+// 20.3.1.4, element access:
+template <intsize_t I, class... Types>
+  typename tuple_element<I, tuple<Types...> >::type& get(tuple<Types...>&);
+template <intsize_t I, class ... types>
+  typename tuple_element<I, tuple<Types...> >::type const& get(const tuple<Types...>&);
+
    
+
+
    
+Update 20.4.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.4.1.5 [tuple.elem] Element access
+
    
+
    template <intsize_t I, class... types >
+typename tuple_element<I, tuple<Types...> >::type& get(tuple<Types...>& t);
+
    
+1 Requires: 0 <= I and I < sizeof...(Types). The program is ill-formed if I is out of bounds.
+
    
+2 Returns: A reference to the Ith element of t, where indexing is zero-based.
+
    
+Throws: Nothing.
+
    template <intsize_t I, class... types>
+typename tuple_element<I, tuple<Types...> >::type const& get(const tuple<Types...>& t);
+
    
+
    
+3 Requires: 0 <= I and I < sizeof...(Types). The program is ill-formed if I is out of bounds.
+
    
+
    
+4 Returns: A const reference to the Ith element of t, where indexing is zero-based.
+
    
+
    
+Throws: Nothing.
+
    
+
 
+
    
+Update header <array> synopsis in 20.2 [utility]
+
    
+
    template <class T> class tuple_size; // forward declaration
+template <intsize_t I, class T> class tuple_element; // forward declaration
+template <class T, size_t N>
+  struct tuple_size<array<T, N> >;
+template <intsize_t I, class T, size_t N>
+  struct tuple_element<I, array<T, N> >;
+template <intsize_t I, class T, size_t N>
+  T& get(array<T, N>&);
+template <intsize_t I, class T, size_t N>
+  const T& get(const array<T, N>&);
+
    
 
-
    
-
    689. reference_wrapper constructor overly constrained
    
-
    Section: 20.5.5.1 [refwrap.const] Status: WP
- Submitter: Peter Dimov Date: 2007-05-10
    
-
    View all other issues in [refwrap.const].
    
-
    View all issues with WP status.
    
-
    Discussion:
    
 
    
-The constructor of reference_wrapper is currently explicit. The primary
-motivation behind this is the safety problem with respect to rvalues,
-which is addressed by the proposed resolution of the previous issue.
-Therefore we should consider relaxing the requirements on the
-constructor since requests for the implicit conversion keep resurfacing.
+Update 23.2.1.6 [array.tuple] Tuple interface to class template array
 
    
+
    tuple_element<size_t I, array<T, N> >::type
+
    
 
    
-Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
+3 Requires: 0 <= I < N. The program is ill-formed if I is out of bounds.
 
    
-
-
-
    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.
+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.
+]
    
 
 
 
 
 
    
-
    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].
    
+
    777. Atomics Library Issue
    
+
    Section: 29.4 [atomics.types.operations] Status: WP
+ Submitter: Lawrence Crowl Date: 2008-01-21
    
+
    View all other issues in [atomics.types.operations].
    
 
    View all issues with WP status.
    
 
    Discussion:
    
 
    
-The  bitset class template  provides the  member function
-any() to determine whether an  object of the type has any
-bits  set, and  the member  function none()  to determine
-whether all of an object's  bits are clear. However, the template does
-not   provide  a   corresponding  function   to  discover   whether  a
-bitset  object  has  all  its  bits  set.   While  it  is
-possible,  even easy,  to  obtain this  information  by comparing  the
-result of count()  with the result of size()
-for  equality  (i.e.,  via  b.count()  ==  b.size())  the
-operation  is   less  efficient   than  a  member   function  designed
-specifically  for that purpose  could be.   (count() must
-count  all non-zero bits  in a  bitset a  word at  a time
-while all() could stop counting as soon as it encountered
-the first word with a zero bit).
+The load functions are defined as
 
    
 
+
    C atomic_load(volatile A* object);
+C atomic_load_explicit(volatile A* object, memory_order);
+C A::load(memory_order order = memory_order_seq_cst) volatile;
+
    
 
-
    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:
+which prevents their use in const contexts.
 
    
 
-
    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;
+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:
 
    
-
    
-Returns: count() == size().
-
    
-
    
+
+
    const atomic_int x{};
+
+int main()
+{
+  x.load();
+}
+
    
 
 
    
-In  addition,   change  the  description   of  any()  and
-none()   for  consistency   with   all()  as
-follows:
-
    
-
    
-bool any() const;
+dump core under a straightforward implementation that puts const objects in
+a read-only section.
 
    
-
    
 
    
-Returns: true if any bit in *this
-is onecount() != 0.
+There are ways to sidestep the problem, but it needs to be considered.
 
    
-
    
 
    
-bool none() const;
+The tradeoff is between making the data member of the atomic types
+mutable and requiring the user to explicitly mark atomic members as
+mutable, as is already the case with mutexes.
 
    
-
    
+
    
+
+
+
+
    Proposed resolution:
    
 
    
-Returns: true if no bit in *this
-is onecount() == 0.
+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;
+
    
+
 
 
 
 
 
 
    
-
    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].
    
+
    778. std::bitset does not have any constructor taking a string literal
    
+
    Section: 23.3.5.1 [bitset.cons] Status: WP
+ Submitter: Thorsten Ottosen Date: 2008-01-24
    
+
    View all other issues in [bitset.cons].
    
 
    View all issues with WP status.
    
+
    Duplicate of: 116
    
 
    Discussion:
    
 
    
-Objects of the  bitset class template specializations can
-be constructed from  and explicitly converted to values  of the widest
-C++ integer  type, unsigned long.   With the introduction
-of  long long into  the language  the template  should be
-enhanced to make it possible  to interoperate with values of this type
-as well, or  perhaps uintmax_t.  See c++std-lib-18274 for
-a brief discussion in support of this change.
+A 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.
 
    
 
-
-
    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.)
+Suggestion: Add
 
    
-
    
-
    // [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);
-
    
-
    
+
+
    explicit bitset( const char* str );
+
    
+
 
    
-Make a corresponding change in 23.3.5.1 [bitset.cons], p2:
+to std::bitset.
 
    
-
    
+
+
+
    Proposed resolution:
    
 
    
-bitset(unsigned long long val);
+Add to synopsis in 23.3.5 [template.bitset]
 
    
-
    
-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.
-
    
-
    
+
+
    explicit bitset( const char* str );
+
    
 
 
    
-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:
+Add to synopsis in 23.3.5.1 [bitset.cons]
 
    
-
    
-
    // 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;
+
+
    explicit bitset( const char* str );
 
    
-
    
-
    
-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;
+Effects: Constructs a bitset as if bitset(string(str)).
 
    
-
    
-Throws:  overflow_error   if  the  integral  value
-x corresponding to  the bits in *this
-cannot be represented as type unsigned long long.
-
    
-
    
-Returns: x.
-
    
 
    
 
 
 
 
 
+
 
    
-
    695. ctype<char>::classic_table() not accessible
    
-
    Section: 22.2.1.3 [facet.ctype.special] Status: WP
- Submitter: Martin Sebor Date: 2007-06-22
    
+
    781. std::complex should add missing C99 functions
    
+
    Section: 26.3.7 [complex.value.ops] Status: WP
+ Submitter: Daniel Krügler Date: 2008-01-26
    
+
    View all other issues in [complex.value.ops].
    
 
    View all issues with WP status.
    
 
    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()).
+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. 
+
    
+
 
    
-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.
+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).
 
    
+
 
    
-The  same argument  can be  made for  the non-static  protected member
-function table().
+Please note also that the current entry polar
+in 26.3.9 [cmplx.over]/1
+should be removed from the mentioned overload list. It does not make sense to require that a
+function already expecting scalar arguments
+should cast these arguments into corresponding
+complex<T> arguments, which are not accepted by
+this function.
 
    
 
 
 
    Proposed resolution:
    
 
    
-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:
+In 26.3.1 [complex.synopsis] add just between the declaration of conj and fabs:
+
    
+
+
    template<class T> complex<T> conj(const complex<T>&);
+template<class T> complex<T> proj(const complex<T>&);
+template<class T> complex<T> fabs(const complex<T>&);
+
    
+
+
    
+In 26.3.7 [complex.value.ops] just after p.6 (return clause of conj) add:
+
    
+
+
    
+
    template<class T> complex<T> proj(const complex<T>& x);
+
    
+
    
+
+Effects: Behaves the same as C99 function cproj, defined in
+subclause 7.3.9.4."
+
    
+
    
+
+
    
+In 26.3.9 [cmplx.over]/1, add one further entry proj to
+the overload list.
 
    
-
    
-
      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;
-
    
+
    
+
    
+The following function templates shall have additional overloads:
+
    
+
    arg           norm 
+conj          polar proj
+imag          real
+
    
 
    
 
 
 
 
 
+
 
    
-
    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].
    
+
    782. Extended seed_seq constructor is useless
    
+
    Section: 26.4.7.1 [rand.util.seedseq] Status: WP
+ Submitter: Daniel Krügler Date: 2008-01-27
    
+
    View other active issues in [rand.util.seedseq].
    
+
    View all other issues in [rand.util.seedseq].
    
 
    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.
+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);
+
    
+
 
    
-See N2391 and
-N2423
-for some further discussion.
+First, the expression iterator_traits<InputIterator>::value_type
+is invalid due to missing typename keyword, which is easy to
+fix.
 
    
 
-
-
    Proposed resolution:
    
 
    
-Adopt the proposed resolution in
-N2423.
+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)].
+
    
 
 
    [
-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.
+Bellevue:
 ]
    
 
 
+
    
+
    
+Fermilab does not have a strong opinion. Would prefer to go with
+solution A. Bill agrees that solution A is a lot simpler and does the
+job.
+
    
+
    
+Proposed Resolution: Accept Solution A.
+
    
+
    
+
+
    
+Issue 803 claims to make this issue moot.
+
    
 
 
 
-
    
-
    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:
    
+
    Proposed resolution:
    
+
      
+
    1. 
 
      
-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.
+In 26.4.7.1 [rand.util.seedseq]/2, class seed_seq synopsis replace:
 
      
 
+
      class seed_seq 
+{ 
+public:
+   ...
+   template<class InputIterator,
+      size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>
+          seed_seq(InputIterator begin, InputIterator end,
+          size_t u = numeric_limits<typename iterator_traits<InputIterator>::value_type>::digits);
+   ...
+};
+
      
+
+
      
+and do a similar replacement in the member description between
+p.3 and p.4.
+
      
+
      2. 
 
-
      Proposed resolution:
      
+
    2. 
 
      
-Change 20.2.2 [forward]:
+In 26.4.7.1 [rand.util.seedseq]/2, class seed_seq synopsis and in the
+member description between p.3 and p.4 replace:
+
      
+
+
      template<class InputIterator,
+  size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>
+	  seed_seq(InputIterator begin, InputIterator end);
+template<class InputIterator, size_t u>
+seed_seq(InputIterator begin, InputIterator end, implementation-defined s);
+
      
+
+
      
+In 26.4.2 [rand.synopsis], header <random> synopsis, immediately after the
+class seed_seq declaration and in 26.4.7.1 [rand.util.seedseq]/2, immediately
+after the class seed_seq definition add:
+
      
+
+
      template<size_t u, class InputIterator>
+  seed_seq make_seed_seq(InputIterator begin, InputIterator end);
+
      
+
+
      
+In 26.4.7.1 [rand.util.seedseq], just before p.5 insert two paragraphs:
 
      
 
 
      
-
      template <class T> struct identity
-{
-    typedef T type;
-    const T& operator()(const T& x) const;
-};
-
      
+
      
+The first constructor behaves as if it would provide an
+integral constant expression u of type size_t of value
+numeric_limits<typename iterator_traits<InputIterator>::value_type>::digits.
+
      
+
      
+The second constructor uses an implementation-defined mechanism
+to provide an integral constant expression u of type size_t and
+is called by the function make_seed_seq.
+
      
+
      
+
+
      
+In 26.4.7.1 [rand.util.seedseq], just after the last paragraph add:
+
      
+
 
      
-
      const T& operator()(const T& x) const;
+
      template<size_t u, class InputIterator>
+   seed_seq make_seed_seq(InputIterator begin, InputIterator end);
 
      
 
      
 
      
-Returns: x.
+where u is used to construct an object s of implementation-defined type.
+
      
+
      
+Returns: seed_seq(begin, end, s);
 
      
 
      
 
      
 
-
    
+
+
 
 
 
@@ -26270,24 +29539,82 @@ Change 20.2.2 [forward]:
 
 
 
    
-
    703. map::at() need a complexity specification
    
-
    Section: 23.3.1.2 [map.access] Status: WP
- Submitter: Joe Gottman Date: 2007-07-03
    
-
    View all other issues in [map.access].
    
+
    783. thread::id reuse
    
+
    Section: 30.2.1.1 [thread.thread.id] Status: WP
+ Submitter: Hans Boehm Date: 2008-02-01
    
 
    View all issues with WP status.
    
 
    Discussion:
    
 
    
-map::at() need a complexity specification.
+The current working paper 
+(N2497,
+integrated just before Bellevue) is
+not completely clear whether a given thread::id value may be reused once
+a thread has exited and has been joined or detached.  Posix allows
+thread ids (pthread_t values) to be reused in this case.  Although it is
+not completely clear whether this originally was the right decision, it
+is clearly the established practice, and we believe it was always the
+intent of the C++ threads API to follow Posix and allow this.  Howard
+Hinnant's example implementation implicitly relies on allowing reuse
+of ids, since it uses Posix thread ids directly.
+
    
+
+
    
+It is important to be clear on this point, since it the reuse of thread
+ids often requires extra care in client code, which would not be
+necessary if thread ids were unique across all time.  For example, a
+hash table indexed by thread id may have to be careful not to associate
+data values from an old thread with a new one that happens to reuse the
+id.  Simply removing the old entry after joining a thread may not be
+sufficient, if it creates a visible window between the join and removal
+during which a new thread with the same id could have been created and
+added to the table.
+
    
+
+
    [
+post Bellevue Peter adds:
+]
    
+
+
+
    
+
    
+There is a real issue with thread::id reuse, but I urge the LWG to
+reconsider fixing this by disallowing reuse, rather than explicitly allowing
+it. Dealing with thread id reuse is an incredibly painful exercise that
+would just force the world to reimplement a non-conflicting thread::id over
+and over.
+
    
+
    
+In addition, it would be nice if a thread::id could be manipulated
+atomically in a lock-free manner, as motivated by the recursive lock
+example:
+
    
+
+
    
+http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html
 
    
+
    
+
 
 
 
    Proposed resolution:
    
 
    
-Add the following to the specification of map::at(), 23.3.1.2 [map.access]:
+Add a sentence to 30.2.1.1 [thread.thread.id]/p1:
 
    
+
 
    
 
    
-Complexity: logarithmic.
+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.
 
    
 
    
 
@@ -26296,143 +29623,153 @@ Add the following to the specification of map::at(), 23.3.1.2 [map.acce
 
 
 
    
-
    705. type-trait decay incompletely specified
    
-
    Section: 20.4.7 [meta.trans.other] Status: WP
- Submitter: Thorsten Ottosen Date: 2007-07-08
    
+
    789. xor_combine_engine(result_type) should be explicit
    
+
    Section: 26.4.4.4 [rand.adapt.xor] Status: WP
+ Submitter: P.J. Plauger Date: 2008-02-09
    
+
    View all other issues in [rand.adapt.xor].
    
 
    View all issues with WP status.
    
 
    Discussion:
    
 
    
-The current working draft has a type-trait decay in 20.4.7 [meta.trans.other].
+xor_combine_engine(result_type) should be explicit. (Obvious oversight.)
 
    
 
-
    
-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.
-
    
+
    [
+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:
    
 
    
-In 20.4.7 [meta.trans.other] change the last sentence:
+Remove xor_combine_engine from synopsis of 26.4.2 [rand.synopsis].
 
    
-
-
    
-Otherwise the  member typedef type equals remove_cv<U>::type.
-
    
-
 
    
-In 20.3.1.3 [tuple.creation]/1 change:
+Remove 26.4.4.4 [rand.adapt.xor] xor_combine_engine.
 
    
 
-
    
-where each Vi in VTypes is X& if, for the
-corresponding type Ti in Types,
-remove_cv<remove_reference<Ti>::type>::type equals
-reference_wrapper<X>, otherwise Vi is
-decay<Ti>::type.
-Let Ui be decay<Ti>::type for each
-Ti in Types. Then each Vi in VTypes
-is X& if Ui equals
-reference_wrapper<X>, otherwise Vi is
-Ui.
-
    
-
-
 
 
 
 
 
    
-
    706. make_pair() should behave as make_tuple() wrt. reference_wrapper()
    
-
    Section: 20.2.3 [pairs] Status: WP
- Submitter: Thorsten Ottosen Date: 2007-07-08
    
-
    View all other issues in [pairs].
    
+
    792. piecewise_constant_distribution is undefined for a range with just one endpoint
    
+
    Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: WP
+ Submitter: P.J. Plauger Date: 2008-02-09
    
+
    View other active issues in [rand.dist.samp.pconst].
    
+
    View all other issues in [rand.dist.samp.pconst].
    
 
    View all issues with WP status.
    
 
    Discussion:
    
 
    
-The current draft has make_pair() in 20.2.3 [pairs]/16
-and make_tuple() in 20.3.1.3 [tuple.creation].
-make_tuple() detects the presence of
-reference_wrapper<X> arguments and "unwraps" the reference in
-such cases. make_pair() would OTOH create a
-reference_wrapper<X> member. I suggest that the two
-functions are made to behave similar in this respect to minimize
-confusion.
+piecewise_constant_distribution is undefined for a range with just one
+endpoint. (Probably should be the same as an empty range.)
 
    
 
 
 
    Proposed resolution:
    
 
    
-In 20.2 [utility] change the synopsis for make_pair() to read
-
    
-
-
    template <class T1, class T2>
-  pair<typename decay<T1>::type V1, typename decay<T2>::type V2> make_pair(T1&&, T2&&);
-
    
-
-
    
-In 20.2.3 [pairs]/16 change the declaration to match the above synopsis.
-Then change the 20.2.3 [pairs]/17 to:
+Change 26.4.8.5.2 [rand.dist.samp.pconst] paragraph 3b:
 
    
 
 
    
-
    
-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.
-
    
+b) If firstB == lastB or the sequence w has the length zero,
 
    
 
 
 
 
 
-
 
    
-
    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].
    
+
    798. Refactoring of binders lead to interface breakage
    
+
    Section: D.8 [depr.lib.binders] Status: WP
+ Submitter: Daniel Krügler Date: 2008-02-14
    
+
    View all other issues in [depr.lib.binders].
    
 
    View all issues with WP status.
    
 
    Discussion:
    
 
    
-One of the motivations for incorporating seed_seq::size()
-was to simplify the wording
-in other parts of 26.4 [rand].
-As a side effect of resolving related issues,
-all such references
-to seed_seq::size() will have been excised.
-More importantly,
-the present specification is contradictory,
-as "The number of 32-bit units the object can deliver"
-is not the same as "the result of v.size()."
+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:
    
 
    
-See N2391 and
-N2423
-for some further discussion.
+Change D.8.1 [depr.lib.binder.1st]:
 
    
 
+
    
+
    template <class Fn> 
+class binder1st 
+  : public unary_function<typename Fn::second_argument_type, 
+                          typename Fn::result_type> { 
+protected: 
+  Fn fn op; 
+  typename Fn::first_argument_type value; 
+public: 
+  binder1st(const Fn& x, 
+            const typename Fn::first_argument_type& y); 
+  typename Fn::result_type 
+    operator()(const typename Fn::second_argument_type& x) const; 
+  typename Fn::result_type 
+    operator()(typename Fn::second_argument_type& x) const; 
+};
+
    
+
+
    
+
    
+-1- The constructor initializes fn op with x and value with y.
+
    
+
    
+-2- operator() returns fnop(value,x).
+
    
+
    
+
    
 
-
    Proposed resolution:
    
 
    
-Adopt the proposed resolution in
-N2423.
+Change D.8.3 [depr.lib.binder.2nd]:
 
    
 
+
    
+
    template <class Fn> 
+class binder2nd
+  : public unary_function<typename Fn::first_argument_type, 
+                          typename Fn::result_type> { 
+protected: 
+  Fn fn op; 
+  typename Fn::second_argument_type value; 
+public: 
+  binder2nd(const Fn& x, 
+            const typename Fn::second_argument_type& y); 
+  typename Fn::result_type 
+    operator()(const typename Fn::first_argument_type& x) const; 
+  typename Fn::result_type 
+    operator()(typename Fn::first_argument_type& x) const; 
+};
+
    
+
+
    
+
    
+-1- The constructor initializes fn op with x and value with y.
+
    
+
    
+-2- operator() returns fnop(value,x).
+
    
+
    
+
    
 
-
    [
-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.
-]
    
 
 
 
diff --git a/libstdc++-v3/doc/xml/manual/intro.xml b/libstdc++-v3/doc/xml/manual/intro.xml
index 8cca6f3..b64b969 100644
--- a/libstdc++-v3/doc/xml/manual/intro.xml
+++ b/libstdc++-v3/doc/xml/manual/intro.xml
@@ -611,7 +611,7 @@
     Follow the straightforward proposed resolution.
     
 
-    550:
+    550:
         What should the return type of pow(float,int) be?
     
     In C++0x mode, remove the pow(float,int), etc., signatures.
@@ -623,7 +623,7 @@
     Change it to be a formatted output function (i.e. catch exceptions).
     
 
-    596:
+    596:
         27.8.1.3 Table 112 omits "a+" and "a+b" modes
     
     Add the missing modes to fopen_mode.
@@ -654,13 +654,13 @@
     Make the member functions table and classic_table public.
     
 
-    761:
+    761:
         unordered_map needs an at() member function
     
     In C++0x mode, add at() and at() const.
     
 
-    775:
+    775:
         Tuple indexing should be unsigned?
     
     Implement the int -> size_t replacements.
@@ -672,14 +672,14 @@
     In C++0x mode, remove assign, add fill.
     
 
-    778:
+    778:
         std::bitset does not have any constructor taking a string 
 	          literal
     
     Add it.
     
 
-    781:
+    781:
         std::complex should add missing C99 functions
     
     In C++0x mode, add std::proj.